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