idnits 2.17.1 draft-carpenter-6man-rfc6874bis-02.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 (17 August 2021) is 984 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 456, but not defined -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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) S. Cheshire 5 Updates: 3986 (if approved) Apple Inc. 6 Intended status: Standards Track R. Hinden 7 Expires: 18 February 2022 Check Point Software 8 17 August 2021 10 Representing IPv6 Zone Identifiers in Address Literals and Uniform 11 Resource Identifiers 12 draft-carpenter-6man-rfc6874bis-02 14 Abstract 16 This document describes how the zone identifier of an IPv6 scoped 17 address, defined as in the IPv6 Scoped Address Architecture 18 (RFC 4007), can be represented in a literal IPv6 address and in a 19 Uniform Resource Identifier that includes such a literal address. It 20 updates the URI Generic Syntax specification (RFC 3986) accordingly, 21 and obsoletes RFC 6874. 23 Discussion Venue 25 This note is to be removed before publishing as an RFC. 27 Discussion of this document takes place on the 6MAN mailing list 28 (ipv6@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/ipv6/ 30 (https://mailarchive.ietf.org/arch/browse/ipv6/). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 18 February 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Issues with Implementing RFC 6874 . . . . . . . . . . . . . . 4 67 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Options Considered . . . . . . . . . . . . . . . . . 9 75 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The Uniform Resource Identifier (URI) syntax specification [RFC3986] 81 defined how a literal IPv6 address can be represented in the "host" 82 part of a URI. Two months later, the IPv6 Scoped Address 83 Architecture specification [RFC4007] extended the text representation 84 of limited-scope IPv6 addresses such that a zone identifier may be 85 concatenated to a literal address, for purposes described in that 86 specification. Zone identifiers are especially useful in contexts in 87 which literal addresses are typically used, for example, during fault 88 diagnosis, when it may be essential to specify which interface is 89 used for sending to a link-local address. It should be noted that 90 zone identifiers have purely local meaning within the node in which 91 they are defined, often being the same as IPv6 interface names. They 92 are completely meaningless for any other node. Today, they are 93 meaningful only when attached to addresses with less than global 94 scope, but it is possible that other uses might be defined in the 95 future. 97 The IPv6 Scoped Address Architecture specification [RFC4007] does not 98 specify how zone identifiers are to be represented in URIs. 99 Practical experience has shown that this feature is useful or 100 necessary, in at least three use cases: 102 1. When using a web browser for simple debugging actions involving 103 link-local addresses on a host with more than one active link 104 interface. 106 2. When using a web browser to reconfigure a misconfigured device 107 which only has a link local address and whose only configuration 108 tool is a web server, again from a host with more than one active 109 link interface. 111 3. When using an HTTP-based protocol for establishing link- local 112 relationships, such as the Apple CUPS printing mechanism [CUPS]. 114 It should be noted that whereas some operating systems and network 115 APIs support a default zone identifier as described in [RFC4007], 116 others do not, and for them an appropriate URI syntax is particularly 117 important. 119 In the past, some browser versions directly accepted the IPv6 Scoped 120 Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, 121 i.e., they were coded to interpret a "%" sign following the literal 122 address as introducing a zone identifier [RFC4007], instead of 123 introducing two hexadecimal characters representing some percent- 124 encoded octet [RFC3986]. Clearly, interpreting the "%" sign as 125 introducing a zone identifier is very convenient for users, although 126 it formally breaches the established URI syntax [RFC3986]. This 127 document defines an alternative approach that respects and extends 128 the rules of URI syntax, and IPv6 literals in general, to be 129 consistent. 131 Thus, this document updates the URI syntax specification [RFC3986] by 132 adding syntax to allow a zone identifier to be included in a literal 133 IPv6 address within a URI. 135 It should be noted that in contexts other than a user interface, a 136 zone identifier is mapped into a numeric zone index or interface 137 number. The MIB textual convention InetZoneIndex [RFC4001] and the 138 socket interface [RFC3493] define this as a 32-bit unsigned integer. 139 The mapping between the human-readable zone identifier string and the 140 numeric value is a host-specific function that varies between 141 operating systems. The present document is concerned only with the 142 human-readable string. 144 Several alternative solutions were considered while this document was 145 developed. Appendix A briefly describes the various options and 146 their advantages and disadvantages. 148 This document obsoletes its predecessor [RFC6874] by greatly 149 simplifying its recommendations and requirements for web browsers. 150 Its effect on the formal URI syntax [RFC3986] is exactly the same as 151 that of RFC 6874. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 2. Issues with Implementing RFC 6874 161 Several issues prevented RFC 6874 being implemented in browsers: 163 1. There was some disagreement with requiring percent-encoding of 164 the "%" sign preceding a zone identifier. This requirement is 165 retained in the present document. 167 2. The requirement to delete any zone identifier before emitting a 168 URI from the host in an HTTP message was considered both too 169 complex to implement and in violation of normal HTTP practice 170 [RFC7230]. This requirement has been dropped from the present 171 document. 173 3. The suggestion to pragmatically allow a bare "%" sign when this 174 would be unambiguous was considered both too complex to implement 175 and confusing for users. This suggestion has been dropped from 176 the present document. 178 3. Specification 180 According to IPv6 Scoped Address syntax [RFC4007], a zone identifier 181 is attached to the textual representation of an IPv6 address by 182 concatenating "%" followed by , where is a string 183 identifying the zone of the address. However, the IPv6 Scoped 184 Address Architecture specification gives no precise definition of the 185 character set allowed in . There are no rules or de facto 186 standards for this. For example, the first Ethernet interface in a 187 host might be called %0, %1, %en1, %eth0, or whatever the implementer 188 happened to choose. Also, %25 would be valid. 190 In a URI, a literal IPv6 address is always embedded between "[" and 191 "]". This document specifies how a can be appended to the 192 address. According to Section 2.4 of [RFC3986], "%" must be percent- 193 encoded to be used as data within a URI, so any occurrences of 194 literal "%" symbols in a URI MUST be percent-encoded and represented 195 in the form "%25". Thus, the scoped address fe80::abcd%en1 would 196 appear in a URI as http://[fe80::abcd%25en1]. 198 * Open Issue 1: This choice needs to be re-discussed as there is an 199 argument that URI parsers could be coded to avoid percent-encoding 200 here if so directed by the ABNF syntax. This depends on the exact 201 interpretation of Section 2.4 of [RFC3986] 203 * Open Issue 2: Depending on the outcome of the previous issue, 204 there is an argument that an alternative separator (specifically 205 "-") would be preferable to "%25". 207 A SHOULD contain only ASCII characters classified as 208 "unreserved" for use in URIs [RFC3986]. This excludes characters 209 such as "]" or even "%" that would complicate parsing. However, the 210 syntax described below does allow such characters to be percent- 211 encoded, for compatibility with existing devices that use them. 213 If an operating system uses any other characters in zone or interface 214 identifiers that are not in the "unreserved" character set, they MUST 215 be represented using percent encoding [RFC3986]. 217 We now present the necessary formal syntax. 219 The URI syntax specification [RFC3986] formally defined the IPv6 220 literal format in ABNF [RFC5234] by the following rule: 222 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 224 To provide support for a zone identifier, the existing syntax of 225 IPv6address is retained, and a zone identifier may be added 226 optionally to any literal address. This syntax allows flexibility 227 for unknown future uses. The rule quoted above from the previous URI 228 syntax specification [RFC3986] is replaced by three rules: 230 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" 232 ZoneID = 1*( unreserved / pct-encoded ) 234 IPv6addrz = IPv6address "%25" ZoneID 236 Alternative rules for Issue 1 above: 238 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" 240 ZoneID = 1*( unreserved ) 242 IPv6addrz = IPv6address "%" ZoneID 244 Alternative rules for Issue 2 above: 246 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" 248 ZoneID = 1*( unreserved ) 250 IPv6addrz = IPv6address "-" ZoneID 252 This syntax fills the gap that is described at the end of 253 Section 11.7 of the IPv6 Scoped Address Architecture specification 254 [RFC4007]. 256 The established rules for textual representation of IPv6 addresses 257 [RFC5952] SHOULD be applied in producing URIs. 259 The URI syntax specification [RFC3986] states that URIs have a global 260 scope, but that in some cases their interpretation depends on the 261 end-user's context. URIs including a ZoneID are to be interpreted 262 only in the context of the host at which they originate, since the 263 ZoneID is of local significance only. 265 The IPv6 Scoped Address Architecture specification [RFC4007] offers 266 guidance on how the ZoneID affects interface/address selection inside 267 the IPv6 stack. Note that the behaviour of an IPv6 stack, if it is 268 passed a non-null zone index for an address other than link-local, is 269 undefined. 271 4. Web Browsers 273 This section discusses how web browsers might handle this syntax 274 extension. Unfortunately, there is no formal distinction between the 275 syntax allowed in a browser's input dialogue box and the syntax 276 allowed in URIs. For this reason, no normative statements are made 277 in this section. 279 Due to the lack of defined syntax, web browsers have been 280 inconsistent in providing for ZoneIDs. Most have no support, but 281 there have been examples of ad hoc support. For example, some 282 versions of Firefox allowed the use of a ZoneID preceded by a bare 283 "%" character, but this feature was removed for consistency with 284 established syntax [RFC3986]. As another example, some versions of 285 Internet Explorer allowed use of a ZoneID preceded by a "%" character 286 encoded as "%25", still beyond the syntax allowed by the established 287 rules [RFC3986]. This syntax extension is in fact used internally in 288 the Windows operating system and some of its APIs. 290 It is desirable for all browsers to recognise a ZoneID according to 291 the above syntax. 293 URIs including a ZoneID have no meaning outside the originating HTTP 294 client node. However, in some use cases, such as CUPS mentioned 295 above, the URI will be reflected back to the client. 297 The normal diagnostic usage for the ZoneID syntax will cause it to be 298 entered in the browser's input dialogue box. Thus, URIs including a 299 ZoneID are unlikely to be encountered in HTML documents. However, if 300 they do (for example, in a diagnostic script coded in HTML), it would 301 be appropriate to treat them exactly as above. 303 5. Security Considerations 305 The security considerations from the URI syntax specification 306 [RFC3986] and the IPv6 Scoped Address Architecture specification 307 [RFC4007] apply. In particular, this URI format creates a specific 308 pathway by which a deceitful zone index might be communicated, as 309 mentioned in the final security consideration of the Scoped Address 310 Architecture specification. 312 To limit this risk, implementations MUST NOT allow use of this format 313 except for well-defined usages, such as sending to link-local 314 addresses under prefix fe80::/10. At the time of writing, this is 315 the only well-defined usage known. 317 6. Acknowledgements 319 The lack of this format was first pointed out by Margaret Wasserman 320 and later by Kerry Lynn. A previous draft document by Martin Duerst 321 and Bill Fenner [LITERAL-ZONE] discussed this topic but was not 322 finalised. Michael Sweet and Andrew Cady explained some of the 323 difficulties caused by RFC 6874. 325 Valuable comments and contributions were made by Karl Auer, Carsten 326 Bormann, Benoit Claise, Stephen Farrell, Brian Haberman, Ted Hardie, 327 Philip Homburg, Tatuya Jinmei, Yves Lafon, Barry Leiba, Radia 328 Perlman, Tom Petch, Michael Richardson, Tomoyuki Sahara, Juergen 329 Schoenwaelder, Nico Schottelius, Dave Thaler, Martin Thomson, Ole 330 Troan, and others. 332 7. References 333 7.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 341 Resource Identifier (URI): Generic Syntax", STD 66, 342 RFC 3986, DOI 10.17487/RFC3986, January 2005, 343 . 345 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 346 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 347 DOI 10.17487/RFC4007, March 2005, 348 . 350 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 351 Specifications: ABNF", STD 68, RFC 5234, 352 DOI 10.17487/RFC5234, January 2008, 353 . 355 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 356 Address Text Representation", RFC 5952, 357 DOI 10.17487/RFC5952, August 2010, 358 . 360 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 361 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 362 May 2017, . 364 7.2. Informative References 366 [CUPS] Apple, "CUPS open source printing system", 2021, 367 . 369 [LITERAL-ZONE] 370 Fenner, B. and M. Duerst, "Formats for IPv6 Scope Zone 371 Identifiers in Literal Address Formats", Work in Progress, 372 October 2005. 374 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 375 Stevens, "Basic Socket Interface Extensions for IPv6", 376 RFC 3493, DOI 10.17487/RFC3493, February 2003, 377 . 379 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 380 Schoenwaelder, "Textual Conventions for Internet Network 381 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 382 . 384 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 385 IPv6 Zone Identifiers in Address Literals and Uniform 386 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 387 February 2013, . 389 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 390 Protocol (HTTP/1.1): Message Syntax and Routing", 391 RFC 7230, DOI 10.17487/RFC7230, June 2014, 392 . 394 Appendix A. Options Considered 396 This section will be updated as necessary after the open issues are 397 resolved. 399 The syntax defined above allows a ZoneID to be added to any IPv6 400 address. The 6man WG discussed and rejected an alternative in which 401 the existing syntax of IPv6address would be extended by an option to 402 add the ZoneID only for the case of link-local addresses. It was 403 felt that the solution presented in this document offers more 404 flexibility for future uses and is more straightforward to implement. 406 The various syntax options considered are now briefly described. 408 1. Leave the problem unsolved. 410 This would mean that per-interface diagnostics would still have 411 to be performed using ping or ping6: 413 ping fe80::abcd%en1 415 Advantage: works today. 417 Disadvantage: less convenient than using a browser. Leaves some 418 use cases unsatisfied. 420 2. Simply use the percent character: 422 http://[fe80::abcd%en1] 424 Advantage: allows use of browser; allows cut and paste. 426 Disadvantage: invalid syntax under RFC 3986; not acceptable to 427 URI community. 429 3. Simply use an alternative separator: 431 http://[fe80::abcd-en1] 433 Advantage: allows use of browser; simple syntax. 435 Disadvantage: Requires all IPv6 address literal parsers and 436 generators to be updated in order to allow simple cut and paste; 437 inconsistent with existing tools and practice. 439 Note: The initial proposal for this choice was to use an 440 underscore as the separator, but it was noted that this becomes 441 effectively invisible when a user interface automatically 442 underlines URLs. 444 4. Simply use the "IPvFuture" syntax left open in RFC 3986: 446 http://[v6.fe80::abcd_en1] 448 Advantage: allows use of browser. 450 Disadvantage: ugly and redundant; doesn't allow simple cut and 451 paste. 453 5. Retain the percent character already specified for introducing 454 zone identifiers for IPv6 Scoped Addresses [RFC4007], and then 455 percent-encode it when it appears in a URI, according to the 456 already-established URI syntax rules [RFC 3986]: 458 http://[fe80::abcd%25en1] 460 Advantage: allows use of browser; consistent with general URI 461 syntax. 463 Disadvantage: somewhat ugly and confusing; doesn't allow simple 464 cut and paste. 466 This is the option chosen for standardisation. 468 Appendix B. Change log 470 This section is to be removed before publishing as an RFC. 472 * draft-carpenter-6man-rfc6874bis-02, 2021-08-12: 474 - Give details of open issues 476 - Update authorship 478 - Editorial fixes 480 * draft-carpenter-6man-rfc6874bis-01, 2021-07-11: 482 - Added section on issues with RFC6874 484 - Removed suggested heuristic for bare % signs 486 - Editorial fixes 488 * draft-carpenter-6man-rfc6874bis-00, 2021-07-05: 490 - Initial version 492 Authors' Addresses 494 Brian Carpenter 495 School of Computer Science 496 University of Auckland 497 PB 92019 498 Auckland 1142 499 New Zealand 501 Email: brian.e.carpenter@gmail.com 503 Stuart Cheshire 504 Apple Inc. 505 1 Infinite Loop 506 Cupertino, CA 95014 507 United States of America 509 Email: cheshire@apple.com 511 Robert M. Hinden 512 Check Point Software 513 959 Skyway Road 514 San Carlos, CA 94070 515 United States of America 517 Email: bob.hinden@gmail.com