RFC 6874

Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

📅 published February 2013, from ietf

RFC 6874 🌈 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

Okay bestie, here's the tea ☕💖 This is RFC 6874, published by the IETF (Internet Engineering Task Force) in February 2013. It's an Internet Standards Track document (ISSN 2070-1721) written by B. Carpenter of Univ. of Auckland, S. Cheshire of Apple Inc., and R. Hinden of Check Point. It updates RFC 3986 [RFC3986] and its header doesn't list anything it obsoletes 🎀

Abstract 💜

This doc explains how the zone identifier of an IPv6 scoped address, which is defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be written inside a literal IPv6 address and inside a Uniform Resource Identifier that holds one of those literal addresses. It updates the URI Generic Syntax spec (RFC 3986) to match ✨

Status of This Memo 📜

Okay so this one is an Internet Standards Track document 💅 It comes from the IETF, it represents the consensus of the IETF community, it got public review, and the IESG (Internet Engineering Steering Group) approved it for publication. If you want more info on Internet Standards, check out Section 2 of RFC 5741.

You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6874 🦋

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read them carefully, because they explain what you can and can't do with this doc 🫶 Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 🧚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Web Browsers  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Options Considered . . . . . . . . . . . . . . . . . . 8

1. Introduction ✨

Okay, the URI syntax spec [RFC3986] already said how a literal IPv6 address goes in the "host" part of a URI 🌐 Two months later, the IPv6 Scoped Address Architecture [RFC4007] came along and let you tack a zone identifier onto a literal address for the purposes it describes. Zone identifiers are super useful wherever literal addresses get used, like fault diagnosis, where it can be essential to say which interface you're using to send to a link-local address 🔍 Here's the thing: zone identifiers only have purely local meaning inside the node where they're defined, and they're often the same as IPv6 interface names. They're completely meaningless for any other node 🙈 Right now they only mean something when they're attached to addresses with less than global scope, but other uses might get defined later.

The IPv6 Scoped Address Architecture [RFC4007] doesn't say how zone identifiers should be written in URIs. Real-world experience shows the feature is useful, especially when someone uses a web browser to debug link-local addresses. But since nothing defines it, URI parsers and browsers don't handle it consistently 😭

Some versions of some browsers straight up accept the IPv6 Scoped Address syntax [RFC4007] for scoped IPv6 addresses inside URIs. They've been coded to read a "%" sign after the literal address as the start of a zone identifier [RFC4007], instead of reading it as the start of two hex characters representing a percent-encoded octet [RFC3986]. Honestly, reading "%" as a zone identifier is super convenient for users 💅 but it formally breaks the established URI syntax [RFC3986]. This doc takes a different route: one that respects the URI syntax rules, extends them, and stays consistent with IPv6 literals in general 🎀

So this doc updates the URI syntax spec [RFC3986] by adding syntax that lets a zone identifier show up inside a literal IPv6 address within a URI 🦋

Also, outside of a user interface, a zone identifier gets mapped to a numeric zone index or interface number. The MIB textual convention InetZoneIndex [RFC4001] and the socket interface [RFC3493] define that number as a 32-bit unsigned integer 🔢 The mapping from the human-readable zone identifier string to the numeric value is a host-specific function that changes between operating systems. This doc only cares about the human-readable string 💖

Several alternative solutions got considered while this doc was being written. Appendix A briefly covers the different options and their advantages and disadvantages 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119] 🫶

2. Specification 🎀

So, according to the IPv6 Scoped Address syntax [RFC4007], a zone identifier gets attached to the text form of an IPv6 address by putting "%" in front of <zone_id>, where <zone_id> is a string that identifies the zone of the address. The catch? The IPv6 Scoped Address Architecture spec doesn't give a precise definition of which characters are allowed in <zone_id> 🙃 There are no rules or de facto standards for this. For example, the first Ethernet interface on a host might be called %0, %1, %en1, %eth0, or whatever the implementer happened to pick 🤷‍♀️

In a URI, a literal IPv6 address is always wrapped between "[" and "]". This doc specifies how a <zone_id> gets appended to the address. Per URI syntax [RFC3986], "%" is always an escape character in a URI, so according to the established URI syntax [RFC3986], any literal "%" symbols in a URI MUST be percent-encoded and written as %25. So the scoped address fe80::a%en1 would show up in a URI as http://[fe80::a%25en1] ✨

A <zone_id> SHOULD contain only ASCII characters classed as "unreserved" for use in URIs [RFC3986]. That leaves out stuff like "]" or even "%", which would make parsing messy 🌀 That said, the syntax below does let those characters be percent-encoded, so it stays compatible with existing devices that use them 💜

If an operating system uses any other characters in zone or interface identifiers that aren't in the "unreserved" set, they MUST be represented using percent encoding [RFC3986] 🦋

Now for the formal syntax 📐

The URI syntax spec [RFC3986] formally defined the IPv6 literal format in ABNF [RFC5234] with this rule:

      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

To support a zone identifier, the existing IPv6address syntax is kept as is, and a zone identifier may be added optionally to any literal address. This leaves room for unknown future uses 🔮 The rule quoted above from the previous URI syntax spec [RFC3986] gets replaced by three rules:

      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

      ZoneID = 1*( unreserved / pct-encoded )

      IPv6addrz = IPv6address "%25" ZoneID

This syntax fills the gap described at the end of Section 11.7 of the IPv6 Scoped Address Architecture spec [RFC4007] 🧩

The established rules for the text representation of IPv6 addresses [RFC5952] SHOULD be applied when producing URIs 💅

The URI syntax spec [RFC3986] says URIs have a global scope, but that sometimes their interpretation depends on the end user's context. URIs that include a ZoneID are only meant to be interpreted in the context of the host where they originate, since the ZoneID only has local significance 🏠

The IPv6 Scoped Address Architecture spec [RFC4007] gives guidance on how the ZoneID affects interface and address selection inside the IPv6 stack. Heads up though: the behaviour of an IPv6 stack, if it gets passed a non-null zone index for an address that isn't link-local, is undefined 🚨

3. Web Browsers 🌐

This section talks about how web browsers might handle this syntax extension. Unfortunately, there's no formal distinction between the syntax allowed in a browser's input dialogue box and the syntax allowed in URIs 😩 Because of that, this section makes no normative statements 🙈

Since there's no defined syntax, browsers have been inconsistent about ZoneIDs. Lots of them have no support at all, but there are some examples of ad hoc support. For instance, some versions of Firefox allowed a ZoneID preceded by a bare "%" character, but that got removed for consistency with the established syntax [RFC3986] 🦊 Another example: some versions of Internet Explorer allow a ZoneID preceded by a "%" character encoded as %25, which is still beyond what the established rules allow [RFC3986]. Fun fact, this syntax extension is actually used internally in the Windows operating system and some of its APIs 🪟

It's desirable for all browsers to recognise a ZoneID preceded by a percent-encoded "%" 💖 In the spirit of "be liberal with what you accept", we also suggest that URI parsers accept bare "%" signs when possible (that means a "%" that isn't followed by two valid and meaningful hex characters). That would let a user copy and paste a string like "fe80::a%en1" from the output of a "ping" command and have it just work 🙌 On the other hand, "%ee1" would need to be manually rewritten to fe80::a%25ee1 to avoid any risk of misinterpretation ⚠️

Bare "%" signs are there for user interface convenience, and they need to be turned into properly encoded characters (where %25 encodes "%") before the URI gets used in any protocol or HTML document 🧼 URIs that include a ZoneID have no meaning outside the originating node, though. So it would be highly desirable for a browser to remove the ZoneID from a URI before including that URI in an HTTP request 🫶

The normal diagnostic use of the ZoneID syntax means it gets typed into the browser's input dialogue box. So URIs with a ZoneID are unlikely to show up in HTML documents. But if they do (for example, in a diagnostic script coded in HTML), it would be appropriate to treat them exactly as above 🧑‍💻

part 2 is coming next, stay tuned 🦋💅

4. Security Considerations 🔐

okay bestie, this section is SERIOUS but also kind of iconic 💅. The security considerations from the URI syntax spec [RFC3986] and the IPv6 Scoped Address Architecture spec [RFC4007] both apply here 🫶. Like, this URI format creates a specific pathway by which a deceitful zone index might be communicated, which is the thing the final security consideration of the Scoped Address Architecture spec warns about 😭. The format is intended only for debugging purposes, but ngl, that intention does not stop anybody from misusing it 💀.

To limit this risk, implementations MUST NOT allow use of this format except for well-defined usages, such as sending to link-local addresses under prefix fe80::/10 🌸. At the time of writing, that's the only well-defined usage known ✨.

An HTTP client, proxy, or other intermediary MUST remove any ZoneID attached to an outgoing URI, because it only has local significance at the sending host 🦋. Main character energy for the sending host, but the ZoneID stays home 🙈.

5. Acknowledgements 🎀

okay so the lack of this format was first pointed out by Margaret Wasserman some years ago, and more recently by Kerry Lynn 🍓. A previous draft document by Martin Duerst and Bill Fenner [LITERAL-ZONE] discussed this topic but was not finalised 🥲.

Valuable comments and contributions came from Karl Auer, Carsten Bormann, Benoit Claise, Stephen Farrell, Brian Haberman, Ted Hardie, Tatuya Jinmei, Yves Lafon, Barry Leiba, Radia Perlman, Tom Petch, Tomoyuki Sahara, Juergen Schoenwaelder, Dave Thaler, Martin Thomson, and Ole Troan 👑.

Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work 🧚.

6. References 📚

6.1. Normative References

[RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3986]       Berners-Lee, T., Fielding, R., and L. Masinter,
                "Uniform Resource Identifier (URI): Generic Syntax",
                STD 66, RFC 3986, January 2005.

[RFC4007]       Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
                and B. Zill, "IPv6 Scoped Address Architecture",
                RFC 4007, March 2005.

[RFC5234]       Crocker, D., Ed. and P. Overell, "Augmented BNF for
                Syntax Specifications: ABNF", STD 68, RFC 5234,
                January 2008.

[RFC5952]       Kawamura, S. and M. Kawashima, "A Recommendation for
                IPv6 Address Text Representation", RFC 5952,
                August 2010.

6.2. Informative References

[LITERAL-ZONE]  Fenner, B. and M. Duerst, "Formats for IPv6 Scope
                Zone Identifiers in Literal Address Formats", Work
                in Progress, October 2005.

[RFC3493]       Gilligan, R., Thomson, S., Bound, J., McCann, J., and
                W. Stevens, "Basic Socket Interface Extensions for
                IPv6", RFC 3493, February 2003.

[RFC4001]       Daniele, M., Haberman, B., Routhier, S., and J.
                Schoenwaelder, "Textual Conventions for Internet
                Network Addresses", RFC 4001, February 2005.

Appendix A. Options Considered 🧩

okay so the syntax defined above lets a ZoneID be added to any IPv6 address 💖. The 6man WG discussed and rejected an alternative where the existing syntax of IPv6address would be extended with an option to add the ZoneID only for link-local addresses. It was felt that the solution in this document offers more flexibility for future uses and is more straightforward to implement 🦋.

The various syntax options considered are now briefly described, so let's go through them bestie 🫶.

  1. Leave the problem unsolved.

This would mean per-interface diagnostics still have to be done using ping or ping6:

ping fe80::a%en1

Advantage: works today.

Disadvantage: less convenient than using a browser.

  1. Simply use the percent character:
http://[fe80::a%en1]

Advantage: allows use of browser; allows cut and paste.

Disadvantage: invalid syntax under RFC 3986; not acceptable to the URI community 🙅‍♀️.

  1. Simply use an alternative separator:
http://[fe80::a-en1]

Advantage: allows use of browser; simple syntax.

Disadvantage: requires all IPv6 address literal parsers and generators to be updated in order to allow simple cut and paste; inconsistent with existing tools and practice.

Note: The initial proposal for this choice was to use an underscore as the separator, but it was noted that this becomes effectively invisible when a user interface automatically underlines URLs 🙈.

  1. Simply use the "IPvFuture" syntax left open in RFC 3986:
http://[v6.fe80::a_en1]

Advantage: allows use of browser.

Disadvantage: ugly and redundant; doesn't allow simple cut and paste 💀.

  1. Retain the percent character already specified for introducing zone identifiers for IPv6 Scoped Addresses [RFC4007], and then percent-encode it when it appears in a URI, according to the already-established URI syntax rules [RFC 3986]:
http://[fe80::a%25en1]

Advantage: allows use of browser; consistent with general URI syntax.

Disadvantage: somewhat ugly and confusing; doesn't allow simple cut and paste.

This is the option chosen for standardisation 👑✨.

Authors' Addresses 🎀

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland,   1142
New Zealand

EMail: brian.e.carpenter@gmail.com


Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
United States

EMail: cheshire@apple.com


Robert M. Hinden
Check Point Software Technologies, Inc.
800 Bridge Parkway
Redwood City, CA  94065
United States

EMail: bob.hinden@gmail.com
📦 where this page comes from