A Lightweight UDP Transfer Protocol for the Internet Registry Information Service
Extracted elements (28)
IRIS-LWZ uses a single UDP packet per request and response (rather than a connection-oriented transport) to minimize overhead for simple, public IRIS lookups. Compression via DEFLATE is optional and negotiated per-packet using header flags, allowing lightweight exchanges while accommodating larger payloads when possible.
If a client intends multiple requests to the same server in a short period, IRIS-LWZ offers no real advantage over IRIS-XPC; IRIS-XPC is RECOMMENDED in that case as it is similarly or more efficient and supports greater response sizes and better security.
Requests requiring authentication, confidentiality, or other security MUST use a different transfer protocol; IRIS-XPC (RFC 4992) is RECOMMENDED. If a request exceeds the maximum packet size even when compressed, or yields a size error, IRIS-XPC is likewise RECOMMENDED.
Clients MUST NOT have more than one outstanding (unanswered, not timed out) request at a time unless they have allocated dedicated network bandwidth and resources for that purpose.
Clients not following the retransmission timeout recommendations MUST allocate or have allocated dedicated network resources ensuring fairness and avoiding network congestion.
Clients SHOULD NOT use sequential transaction ID values and MUST NOT set all bits to 1 (0xFFFF), which is reserved for server use. Randomizing transaction IDs reduces spoofed-packet attack success.
Clients SHOULD retransmit unanswered requests with an initial timeout of 1 second, doubling on each retransmission, and SHOULD NOT retransmit once the timeout reaches 60 seconds.
If the path MTU is unknown, the maximum packet size MUST be 1500 octets. If known, it MUST NOT exceed the path MTU and MUST NOT exceed 4000 octets.
Reserved bit 5 in the payload header MUST be 0; receipt of a non-zero value in that bit SHOULD trigger a descriptor error response.
Servers MUST be prepared to accept packets as large as 4000 octets; clients MUST NOT send packets larger than 4000 octets.
Servers MUST send a payload error when they receive an XML payload (PT='xml') that cannot be parsed.
When a response transaction ID cannot be read due to truncation, or the request transaction ID is 0xFFFF, the server MUST respond with transaction ID 0xFFFF and send a descriptor error. Otherwise, the response transaction ID MUST equal the request transaction ID.
When the DS flag is 0 in a request (sender does not support DEFLATE), the server's response payload MUST NOT be compressed with DEFLATE. Servers MUST send 'no-inflation-support-error' when they receive a DEFLATE-compressed request they cannot decompress.
XML payloads used in IRIS-LWZ MUST NOT use character encodings other than UTF-8 or UTF-16.
Four payload types are defined via bits 6–7 of the header: 00 = XML payload ('xml'), 01 = version info ('vi'), 10 = size info ('si'), 11 = other info ('oi'). Types 'si' and 'oi' are descriptor errors when present in request packets.
Other information ('oi') payloads MUST conform to RFC 4991 XML and use <other> as root. The 'type' attribute takes values: 'descriptor-error', 'payload-error', 'system-error', 'authority-error', and 'no-inflation-support-error', each with defined trigger conditions.
Size information ('si') payloads MUST conform to RFC 4991 XML and use <size> as root. Octet counts represent the total UDP packet length (UDP header + payload descriptor + XML payload). Servers send this when they cannot satisfy the client's requested maximum response length.
Version information ('vi') payloads MUST conform to RFC 4991 XML and use <versions> as the root element. The <transferProtocol> identifier for IRIS-LWZ is 'iris.lwz1'; it MUST only describe protocols on the same socket as the responding server.
IANA assigned well-known UDP port 715 to IRIS-LWZ (short name: iris.lwz). The port carries single-packet IRIS XML request/response exchanges as defined in Sections 3 and 3.1.
IANA registered the S-NAPTR application protocol label 'iris.lwz' for locating IRIS servers using XML over UDP via the Dynamic Delegation Discovery Service (DDDS).
IANA registered the URI scheme 'iris.lwz' (permanent) for identifying IRIS entities available via XML over UDP. Syntax is defined in RFC 3981; security considerations are in Section 8 of this document.
Because IRIS-LWZ is UDP-based, servers can be exploited in reflection-based distributed denial-of-service attacks similar to DNS reflection. Operators should apply DNS-equivalent mitigation techniques and follow BCP 38 (RFC 2827) for ingress filtering.
IRIS-LWZ provides no in-band authentication or confidentiality and is intended only for public data. Applications needing security must use out-of-band mechanisms (e.g., IPsec) or switch to IRIS-XPC. Attackers can alter IRIS-LWZ messages, enabling denial of service or delivery of false information.
Transaction IDs should be randomized (not sequential) to reduce the probability that spoofed packets succeed in matching a legitimate transaction. Clients MUST take appropriate measures if they ignore this advice.
An IRIS-LWZ packet consists of a binary payload descriptor (3 octets in responses, 6–261 octets in requests) followed by a payload of 0..n octets. The payload may be DEFLATE-compressed.
The 1-octet payload header encodes: bits 0–1 = version ('V'), bit 2 = request/response flag ('RR'), bit 3 = payload deflated ('PD'), bit 4 = deflate supported ('DS'), bit 5 = reserved (MUST be 0), bits 6–7 = payload type ('PT').
The request payload descriptor is 6–261 octets: 1-octet header, 2-octet transaction ID, 2-octet maximum response length, 1-octet authority length, and 0–255 octets of authority string.
The response payload descriptor is always exactly 3 octets: a 1-octet payload header followed by a 2-octet transaction ID. The value 0xFFFF is reserved for server use.