Summary

  • RFC 5118 includes a SIP URI whose intended port sits inside the closing IPv6 bracket. The parser can accept it, yet the port becomes the final IPv6 octet pair and the request names a different destination.
  • The document also asks robust implementations to accept a bracketed received value that strict RFC 3261 grammar does not permit, while emitting the unbracketed form. Acceptance is therefore contextual, not a universal verdict on validity.
  • A trustworthy test record must preserve exact message bytes, the parser build and parse tree, intended host and port, normalized output, chosen next hop, SIP transaction and observed service outcome as separate receipts.

The request looks plausible:

REGISTER sip:[2001:db8::10:5070] SIP/2.0

An operator meant to contact the IPv6 host 2001:db8::10 on port 5070. But the closing bracket comes after 5070. Under the grammar, everything inside those brackets belongs to the IPv6 address. The parser has not lost the port; it has never seen one. It has accepted a different address.

This is the sharpest test in RFC 5118 because it overturns a familiar control habit. Syntax validation is usually treated as the gate between malformed input and trustworthy structure. Here the structure is trustworthy as syntax and wrong as intention. The verified erratum matters: the digits become the final IPv6 octet pair, not one octet. That small correction is exactly the kind of custody detail an operational dashboard tends to discard.

Square brackets assign meaning

SIP borrowed a necessary URI convention. Colons separate pieces of an IPv6 literal, while another colon can introduce a port. Square brackets tell the grammar where the literal ends. RFC 3261 represents the distinction as a host followed by an optional colon and port; its IPv6 reference places the address inside brackets. RFC 3986 uses the same architectural boundary for an IP literal in a URI authority.

Move the bracket and the meaning changes:

REGISTER sip:[2001:db8::10]:5070 SIP/2.0

Now the host is 2001:db8::10 and the port is 5070. Both strings can pass a parser. Only one expresses the operator's stated destination. A conformance report that records parse=true for the first form has answered a real but narrow question. It has not shown that the request will leave through the intended socket.

RFC 5118 also supplies the opposite case. A SIP URI without required brackets around an IPv6 literal is invalid and should receive a 400 response. The corpus therefore does not preach indiscriminate tolerance. It distinguishes an invalid URI, a valid but semantically surprising URI, and a field where historical interoperability supports bounded tolerance.

The received exception is a named exception

The top Via field can contain both sent-by and received information. In RFC 3261, sent-by uses the bracketed IPv6-reference production, while received was defined using the bare IPv6-address production. RFC 5118 recorded an interoperability split: implementations had made different assumptions about whether a received value could carry brackets.

Its advice is asymmetric. A receiver should parse the received address with or without brackets, but a sender should emit the grammar-conforming unbracketed form. This is not a philosophical endorsement of malformed input. It is a repair rule for one known seam, coupled to a canonical output.

That distinction must survive implementation. If a product turns the rule into “strip brackets anywhere,” it creates new ambiguity. If it rejects every noncanonical received value, it converts a documented compatibility choice into an outage. The relevant receipt is not simply accepted or rejected. It is: field, exact bytes, exception invoked, structured value produced, canonical value emitted and next hop selected.

The same address has different grammar in the body

Context changes the delimiter rule again. RFC 5118 shows an IPv6 address in a SIP URI with brackets and IPv6 connection addresses in the SDP body without them. It also constructs messages with mixed IPv4 and IPv6 Via fields, separate address families for audio and video lines, and IPv4-mapped IPv6 values in signaling and SDP.

A scanner that looks for colons and adds brackets everywhere will damage valid SDP. A scanner that removes all brackets will damage SIP URIs. The bytes do not carry a universal visual rule; the enclosing production assigns their role.

This is a useful governance limit. A central normalization service may promise consistency, but it cannot safely act without retaining the original field and grammar context. Uniform appearance is not interoperability. Sometimes it is the destruction of the distinction the protocol needs.

Page layout is not a packet fixture

SIP is text, but the RFC page is not the wire. Long lines had to fit a publication format. RFC 5118 reuses the allOneLine convention from RFC 4475: lines inside the marker are reconstructed by concatenation under precise whitespace rules. It also embeds an encoded archive containing bit-exact versions of the examples.

This changes the evidence burden for a laboratory. Copying a visually wrapped example into a text file is not source custody. A space inserted at a fold, a removed carriage return or a recalculated Content-Length can turn the exercise into a different test. The laboratory should record the fixture hash, extraction method and exact octets before recording the outcome.

Bit-exact custody still does not make the result universal. RFC 5118 calls itself Informational, says it is non-normative on every aspect of SIP and says it is not comprehensive. Some examples stress only the parser; others reach the application above it. Passing all examples is evidence that a named build handled those examples under a named configuration. It is not a certificate for every SIP grammar path, every intermediary or every IPv6 deployment.

Acceptance, forwarding and service are different events

An intermediary can accept a curious input and serialize a safer form before forwarding it. RFC 5118 discusses an extra-colon construction inherited through the RFC 3261 ABNF. A receiver may accept it for robustness; if it forwards the message, it should remove the extra colon. The input parse tree and output bytes are therefore two separate observations.

After that come still more boundaries. The chosen address must resolve to a usable route. A SIP transaction must receive and interpret a response. A dialog may or may not form. SDP may name reachable media endpoints. Media may or may not flow. A user may or may not experience a successful call.

None of those outcomes is in a parser's gift. Conversely, a call that happens to connect does not prove that every intermediary parsed the message the same way. Fallback, alternate contacts or permissive hops can conceal a differential until the topology changes.

A test corpus is a map of seams

The durable value of RFC 5118 is not a pass percentage. It identifies seams where representations change authority: page to bytes, header to body, host to port, received input to canonical output, parser to application, signaling to media. Those seams are the places where a compact operational status most readily becomes a false claim.

The correct control plane keeps the layers visible. Store the input. Name the production. Capture the component tree. Record the intended host and port independently. Compare forwarded bytes. Observe the next hop. Then record transaction, dialog, media and user outcome without compressing them into “IPv6 supported.”

Sources