ietf-corpus

rfc-5954

Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261

V. Gurbani (Editor), B. Carpenter (Editor), B. Tate (Editor)
date2010-08 streamIETF arearai wgsip statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc5954 doi10.17487/RFC5954 errataview
This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]

updates

Extracted elements (12)

design-rationale §3.1

The flawed ABNF in RFC 3261 was historically derived from Appendix B of RFC 2373, which was itself erroneous. RFC 2373 has since been obsoleted by RFC 4291. This explains why the error propagated into SIP.

sip, ip

design-rationale §4.2

URI equality for IP-address hosts is determined by binary equivalence rather than textual identity because IPv6 compressed notation and hybrid (IPv4-mapped) address forms admit multiple valid textual representations of the same address. Examples: sip:bob@[2001:db8::9:1] equals sip:bob@[2001:db8::9:01].

sip, ip

errata §3.1

The ABNF for generating IPv6 literals in RFC 3261 is incorrect: when generating IPv4-mapped IPv6 addresses, the <IPv6address> production rule may produce a construct with an extra colon before the IPv4 address (e.g., [2001:db8:::192.0.2.1]) because <hexpart> alternatives already include '::'. The correct form uses only two colons.

sip, ip

interoperability-note §4.1

Adopting the RFC 3986 IPv4address production rule eliminates syntactically valid but semantically invalid SIP URIs such as 'sip:bob@444.555.666.777', tightening the set of accepted addresses relative to the original RFC 3261 grammar.

sip, ip

interoperability-note §3.2

RFC 3261 Section 19.1.4 requires host components to match for URI equality but provides no rule for URIs containing different textual representations of IPv6 addresses that are binary equivalents, e.g., sip:bob@[::ffff:192.0.2.128] vs sip:bob@[::ffff:c000:280]. This ambiguity also affects IPv4 (e.g., 192.0.2.128 vs 192.00.02.128) but is more acute for IPv6 due to compressed notation and hybrid address forms.

sip, ip

normative-requirement §5 SHOULD

Implementers SHOULD generate IPv6 text representations as defined in RFC 5952 to produce a canonical form and reduce comparison ambiguity.

ip, sip

normative-requirement §4.1 MUST NOT

The <hexpart>, <hexseq>, and <hex4> production rules from RFC 3261 MUST NOT be used, as they are rendered obsolete by adoption of the RFC 3986 IPv6address grammar.

sip, ip

normative-requirement §4.1 MUST NOT

The <IPv6address> and <IPv4address> production rules from RFC 3261 MUST NOT be used. Instead, the production rules of the same name from RFC 3986 MUST be used.

sip, ip

normative-requirement §4.2 MUST

The URI comparison rule in RFC 3261 Section 19.1.4 MUST be modified: if the host component contains a textual representation of an IP address, the host components are considered to match if the different textual representations yield the same binary IP address.

sip, ip

protocol-element §3.1

IPv6reference is defined as a bracket-enclosed IPv6address: '[' IPv6address ']'. After this correction, the enclosed IPv6address MUST conform to the RFC 3986 grammar, not the RFC 3261 grammar.

sip, ip

security-consideration §6

This document does not introduce any new security considerations beyond those described in RFC 3261. The ABNF correction and URI comparison clarification are purely syntactic and semantic fixes.

sip, security

wire-format §4.1

The corrected IPv6address ABNF (from RFC 3986) enumerates all nine legal forms of a 128-bit IPv6 address using h16 (1–4 hex digits) and ls32 (either two h16 groups or an IPv4address). It replaces the flawed hexpart/hexseq/hex4 grammar from RFC 3261 and prevents generation of the extra-colon construct.

ip, sip