idnits 2.17.1 draft-carpenter-6man-rfc6874bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC3986, but the abstract doesn't seem to directly say this. It does mention RFC3986 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3986, updated by this document, for RFC5378 checks: 2002-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 July 2021) is 1026 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3986' is mentioned on line 417, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Obsoletes: 6874 (if approved) R. Hinden 5 Updates: 3986 (if approved) Check Point 6 Intended status: Standards Track 4 July 2021 7 Expires: 5 January 2022 9 Representing IPv6 Zone Identifiers in Address Literals and Uniform 10 Resource Identifiers 11 draft-carpenter-6man-rfc6874bis-00 13 Abstract 15 This document describes how the zone identifier of an IPv6 scoped 16 address, defined as in the IPv6 Scoped Address Architecture 17 (RFC 4007), can be represented in a literal IPv6 address and in a 18 Uniform Resource Identifier that includes such a literal address. It 19 updates the URI Generic Syntax specification (RFC 3986) accordingly, 20 and obsoletes RFC 6874. 22 Discussion Venue 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the 6MAN mailing list 27 (ipv6@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/ipv6/ 29 (https://mailarchive.ietf.org/arch/browse/ipv6/). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 5 January 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 7.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Appendix A. Options Considered . . . . . . . . . . . . . . . . . 8 74 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Uniform Resource Identifier (URI) syntax specification [RFC3986] 80 defined how a literal IPv6 address can be represented in the "host" 81 part of a URI. Two months later, the IPv6 Scoped Address 82 Architecture specification [RFC4007] extended the text representation 83 of limited-scope IPv6 addresses such that a zone identifier may be 84 concatenated to a literal address, for purposes described in that 85 specification. Zone identifiers are especially useful in contexts in 86 which literal addresses are typically used, for example, during fault 87 diagnosis, when it may be essential to specify which interface is 88 used for sending to a link-local address. It should be noted that 89 zone identifiers have purely local meaning within the node in which 90 they are defined, often being the same as IPv6 interface names. They 91 are completely meaningless for any other node. Today, they are 92 meaningful only when attached to addresses with less than global 93 scope, but it is possible that other uses might be defined in the 94 future. 96 The IPv6 Scoped Address Architecture specification [RFC4007] does not 97 specify how zone identifiers are to be represented in URIs. 98 Practical experience has shown that this feature is useful, in at 99 least three use cases: 101 1. When using a web browser for simple debugging actions involving 102 link-local addresses on a host with more than one active link 103 interface. 105 2. When using a web browser to reconfigure a misconfigured device 106 which only has a link local address and whose only configuration 107 tool is a web server, again from a host with more than one active 108 link interface. 110 3. When using an HTTP-based protocol for establishing link- local 111 relationships, such as the Apple CUPS printing mechanism [CUPS]. 113 In the past, some browser versions directly accepted the IPv6 Scoped 114 Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, 115 i.e., they were coded to interpret a "%" sign following the literal 116 address as introducing a zone identifier [RFC4007], instead of 117 introducing two hexadecimal characters representing some percent- 118 encoded octet [RFC3986]. Clearly, interpreting the "%" sign as 119 introducing a zone identifier is very convenient for users, although 120 it formally breaches the established URI syntax [RFC3986]. This 121 document defines an alternative approach that respects and extends 122 the rules of URI syntax, and IPv6 literals in general, to be 123 consistent. 125 Thus, this document updates the URI syntax specification [RFC3986] by 126 adding syntax to allow a zone identifier to be included in a literal 127 IPv6 address within a URI. 129 It should be noted that in contexts other than a user interface, a 130 zone identifier is mapped into a numeric zone index or interface 131 number. The MIB textual convention InetZoneIndex [RFC4001] and the 132 socket interface [RFC3493] define this as a 32-bit unsigned integer. 133 The mapping between the human-readable zone identifier string and the 134 numeric value is a host-specific function that varies between 135 operating systems. The present document is concerned only with the 136 human-readable string. 138 Several alternative solutions were considered while this document was 139 developed. Appendix A briefly describes the various options and 140 their advantages and disadvantages. 142 This document obsoletes its predecessor [RFC6874] by greatly 143 simplifying its recommendations and requirements for web browsers. 144 Its effect on the formal URI syntax [RFC3986] is exactly the same as 145 that of RFC 6874. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 2. Specification 155 According to IPv6 Scoped Address syntax [RFC4007], a zone identifier 156 is attached to the textual representation of an IPv6 address by 157 concatenating "%" followed by , where is a string 158 identifying the zone of the address. However, the IPv6 Scoped 159 Address Architecture specification gives no precise definition of the 160 character set allowed in . There are no rules or de facto 161 standards for this. For example, the first Ethernet interface in a 162 host might be called %0, %1, %en1, %eth0, or whatever the implementer 163 happened to choose. 165 In a URI, a literal IPv6 address is always embedded between "[" and 166 "]". This document specifies how a can be appended to the 167 address. According to URI syntax [RFC3986], "%" is always treated as 168 an escape character in a URI, so, according to the established URI 169 syntax [RFC3986] any occurrences of literal "%" symbols in a URI MUST 170 be percent-encoded and represented in the form "%25". Thus, the 171 scoped address fe80::a%en1 would appear in a URI as 172 http://[fe80::a%25en1]. 174 A SHOULD contain only ASCII characters classified as 175 "unreserved" for use in URIs [RFC3986]. This excludes characters 176 such as "]" or even "%" that would complicate parsing. However, the 177 syntax described below does allow such characters to be percent- 178 encoded, for compatibility with existing devices that use them. 180 If an operating system uses any other characters in zone or interface 181 identifiers that are not in the "unreserved" character set, they MUST 182 be represented using percent encoding [RFC3986]. 184 We now present the necessary formal syntax. 186 The URI syntax specification [RFC3986] formally defined the IPv6 187 literal format in ABNF [RFC5234] by the following rule: 189 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 191 To provide support for a zone identifier, the existing syntax of 192 IPv6address is retained, and a zone identifier may be added 193 optionally to any literal address. This syntax allows flexibility 194 for unknown future uses. The rule quoted above from the previous URI 195 syntax specification [RFC3986] is replaced by three rules: 197 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" 199 ZoneID = 1*( unreserved / pct-encoded ) 201 IPv6addrz = IPv6address "%25" ZoneID 203 This syntax fills the gap that is described at the end of 204 Section 11.7 of the IPv6 Scoped Address Architecture specification 205 [RFC4007]. 207 The established rules for textual representation of IPv6 addresses 208 [RFC5952] SHOULD be applied in producing URIs. 210 The URI syntax specification [RFC3986] states that URIs have a global 211 scope, but that in some cases their interpretation depends on the 212 end-user's context. URIs including a ZoneID are to be interpreted 213 only in the context of the host at which they originate, since the 214 ZoneID is of local significance only. 216 The IPv6 Scoped Address Architecture specification [RFC4007] offers 217 guidance on how the ZoneID affects interface/address selection inside 218 the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is 219 passed a non-null zone index for an address other than link-local, is 220 undefined. 222 3. Web Browsers 224 This section discusses how web browsers might handle this syntax 225 extension. Unfortunately, there is no formal distinction between the 226 syntax allowed in a browser's input dialogue box and the syntax 227 allowed in URIs. For this reason, no normative statements are made 228 in this section. 230 Due to the lack of defined syntax, web browsers have been 231 inconsistent in providing for ZoneIDs. Many have no support, but 232 there are examples of ad hoc support. For example, some versions of 233 Firefox allowed the use of a ZoneID preceded by a bare "%" character, 234 but this feature was removed for consistency with established syntax 235 [RFC3986]. As another example, some versions of Internet Explorer 236 allowed use of a ZoneID preceded by a "%" character encoded as "%25", 237 still beyond the syntax allowed by the established rules [RFC3986]. 238 This syntax extension is in fact used internally in the Windows 239 operating system and some of its APIs. 241 It is desirable for all browsers to recognise a ZoneID preceded by a 242 percent-encoded "%". In the spirit of "be liberal with what you 243 accept", we also suggest that URI parsers accept bare "%" signs when 244 possible (i.e., a "%" not followed by two valid and meaningful 245 hexadecimal characters). This would make it possible for a user to 246 copy and paste a string such as "fe80::a%en1" from the output of a 247 "ping" command and have it work. On the other hand, "%ee1" would 248 need to be manually rewritten to "fe80::a%25ee1" to avoid any risk of 249 misinterpretation. 251 URIs including a ZoneID have no meaning outside the originating HTTP 252 client node. However, in some use cases, such as CUPS mentioned 253 above, the URI will be reflected back to the client. 255 The normal diagnostic usage for the ZoneID syntax will cause it to be 256 entered in the browser's input dialogue box. Thus, URIs including a 257 ZoneID are unlikely to be encountered in HTML documents. However, if 258 they do (for example, in a diagnostic script coded in HTML), it would 259 be appropriate to treat them exactly as above. 261 4. Security Considerations 263 The security considerations from the URI syntax specification 264 [RFC3986] and the IPv6 Scoped Address Architecture specification 265 [RFC4007] apply. In particular, this URI format creates a specific 266 pathway by which a deceitful zone index might be communicated, as 267 mentioned in the final security consideration of the Scoped Address 268 Architecture specification. 270 To limit this risk, implementations MUST NOT allow use of this format 271 except for well-defined usages, such as sending to link-local 272 addresses under prefix fe80::/10. At the time of writing, this is 273 the only well-defined usage known. 275 5. Acknowledgements 277 The lack of this format was first pointed out by Margaret Wasserman 278 and later by Kerry Lynn. A previous draft document by Martin Duerst 279 and Bill Fenner [LITERAL-ZONE] discussed this topic but was not 280 finalised. Michael Sweet and Andrew Cady explained some of the 281 difficulties caused by RFC 6874. 283 Valuable comments and contributions were made by Karl Auer, Carsten 284 Bormann, Benoit Claise, Stephen Farrell, Brian Haberman, Ted Hardie, 285 Tatuya Jinmei, Yves Lafon, Barry Leiba, Radia Perlman, Tom Petch, 286 Tomoyuki Sahara, Juergen Schoenwaelder, Dave Thaler, Martin Thomson, 287 and Ole Troan. 289 6. Contributor 291 A co-author of RFC 6874 was: 293 Stuart Cheshire 294 Apple Inc. 295 1 Infinite Loop 296 Cupertino, CA 95014 297 United States 299 Email: cheshire@apple.com 301 7. References 303 7.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 311 Resource Identifier (URI): Generic Syntax", STD 66, 312 RFC 3986, DOI 10.17487/RFC3986, January 2005, 313 . 315 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 316 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 317 DOI 10.17487/RFC4007, March 2005, 318 . 320 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 321 Specifications: ABNF", STD 68, RFC 5234, 322 DOI 10.17487/RFC5234, January 2008, 323 . 325 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 326 Address Text Representation", RFC 5952, 327 DOI 10.17487/RFC5952, August 2010, 328 . 330 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 331 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 332 May 2017, . 334 7.2. Informative References 336 [CUPS] Apple, "CUPS open source printing system", 2021, 337 . 339 [LITERAL-ZONE] 340 Fenner, B. and M. Duerst, "Formats for IPv6 Scope Zone 341 Identifiers in Literal Address Formats", Work in Progress, 342 October 2005. 344 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 345 Stevens, "Basic Socket Interface Extensions for IPv6", 346 RFC 3493, DOI 10.17487/RFC3493, February 2003, 347 . 349 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 350 Schoenwaelder, "Textual Conventions for Internet Network 351 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 352 . 354 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 355 IPv6 Zone Identifiers in Address Literals and Uniform 356 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 357 February 2013, . 359 Appendix A. Options Considered 361 The syntax defined above allows a ZoneID to be added to any IPv6 362 address. The 6man WG discussed and rejected an alternative in which 363 the existing syntax of IPv6address would be extended by an option to 364 add the ZoneID only for the case of link-local addresses. It was 365 felt that the solution presented in this document offers more 366 flexibility for future uses and is more straightforward to implement. 368 The various syntax options considered are now briefly described. 370 1. Leave the problem unsolved. 372 This would mean that per-interface diagnostics would still have 373 to be performed using ping or ping6: 375 ping fe80::a%en1 377 Advantage: works today. 379 Disadvantage: less convenient than using a browser. 381 2. Simply use the percent character: 383 http://[fe80::a%en1] 385 Advantage: allows use of browser; allows cut and paste. 387 Disadvantage: invalid syntax under RFC 3986; not acceptable to 388 URI community. 390 3. Simply use an alternative separator: 392 http://[fe80::a-en1] 394 Advantage: allows use of browser; simple syntax. 396 Disadvantage: Requires all IPv6 address literal parsers and 397 generators to be updated in order to allow simple cut and paste; 398 inconsistent with existing tools and practice. 400 Note: The initial proposal for this choice was to use an 401 underscore as the separator, but it was noted that this becomes 402 effectively invisible when a user interface automatically 403 underlines URLs. 405 4. Simply use the "IPvFuture" syntax left open in RFC 3986: 407 http://[v6.fe80::a_en1] 409 Advantage: allows use of browser. 411 Disadvantage: ugly and redundant; doesn't allow simple cut and 412 paste. 414 5. Retain the percent character already specified for introducing 415 zone identifiers for IPv6 Scoped Addresses [RFC4007], and then 416 percent-encode it when it appears in a URI, according to the 417 already-established URI syntax rules [RFC 3986]: 419 http://[fe80::a%25en1] 421 Advantage: allows use of browser; consistent with general URI 422 syntax. 424 Disadvantage: somewhat ugly and confusing; doesn't allow simple 425 cut and paste. 427 This is the option chosen for standardisation. 429 Appendix B. Change log 431 This section is to be removed before publishing as an RFC. 433 * draft-carpenter-6man-rfc6874bis-00, 2021-06-25: 435 - Initial version 437 Authors' Addresses 439 Brian Carpenter 440 School of Computer Science 441 University of Auckland 442 PB 92019 443 Auckland 1142 444 New Zealand 446 Email: brian.e.carpenter@gmail.com 448 Robert M. Hinden 449 Check Point Software Technologies, Inc. 450 800 Bridge Parkway 451 Redwood City, CA 94065 452 United States 454 Email: bob.hinden@gmail.com