idnits 2.17.00 (12 Aug 2021) /tmp/idnits5246/draft-ietf-6man-rfc6874bis-01.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: ---------------------------------------------------------------------------- (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 (5 April 2022) is 39 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 482, but not defined 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, 3987 (if approved) Apple Inc. 6 Intended status: Standards Track R. Hinden 7 Expires: 7 October 2022 Check Point Software 8 5 April 2022 10 Representing IPv6 Zone Identifiers in Address Literals and Uniform 11 Resource Identifiers 12 draft-ietf-6man-rfc6874bis-01 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 7 October 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. URI Parsers . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Options Considered . . . . . . . . . . . . . . . . . 10 76 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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, usually being the same as IPv6 interface names. 93 They are completely meaningless for any other node. Today, they are 94 meaningful only when attached to link-local addresses, but it is 95 possible that other uses might be defined in the 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 multiple use cases: 102 1. A web browser may be used for simple debugging actions involving 103 link-local addresses on a host with more than one active link 104 interface. 106 2. A web browser must sometimes be used to configure or reconfigure 107 a device which only has a link local address and whose only 108 configuration tool is a web server, again in a host with more 109 than one active link interface. 111 3. The Apple and open-source CUPS printing mechanism [CUPS] 112 [OP-CUPS] uses an HTTP-based protocol [RFC3510][RFC7472] to 113 establish link-local relationships, so requires the specification 114 of the relevant interface. 116 4. The Microsoft Web Services for Devices (WSD) virtual printer port 117 mechanism can generate an IPv6 Link Local URL in which the zone 118 identifier is present and necessary, but is not recognized by any 119 current browser. 121 It should be noted that whereas some operating systems and network 122 APIs support a default zone identifier as described in [RFC4007], 123 others do not, and for them an appropriate URI syntax is particularly 124 important. 126 In the past, some browser versions directly accepted the IPv6 Scoped 127 Address syntax [RFC4007] for scoped IPv6 addresses embedded in URIs, 128 i.e., they were coded to interpret a "%" sign following the literal 129 address as introducing a zone identifier [RFC4007], instead of 130 introducing two hexadecimal characters representing some percent- 131 encoded octet [RFC3986]. Clearly, interpreting the "%" sign as 132 introducing a zone identifier is very convenient for users, although 133 it is not supported by the URI syntax in [RFC3986] or the 134 Internationalized Resource Identifier (IRI) syntax in [RFC3987]. 135 Therefore, this document updates RFC 3986 and RFC 3987 by adding 136 syntax to allow a zone identifier to be included in a literal IPv6 137 address within a URI. 139 It should be noted that in contexts other than a user interface, a 140 zone identifier is mapped into a numeric zone index or interface 141 number. The MIB textual convention InetZoneIndex [RFC4001] and the 142 socket interface [RFC3493] define this as a 32-bit unsigned integer. 143 The mapping between the human-readable zone identifier string and the 144 numeric value is a host-specific function that varies between 145 operating systems. The present document is concerned only with the 146 human-readable string. 148 Several alternative solutions were considered while this document was 149 developed. Appendix A briefly describes the various options and 150 their advantages and disadvantages. 152 This document obsoletes its predecessor [RFC6874] by greatly 153 simplifying its recommendations and requirements for URI parsers. 154 Its effect on the formal URI syntax [RFC3986] is different from that 155 of RFC 6874. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in BCP 160 14 [RFC2119] [RFC8174] when, and only when, they appear in all 161 capitals, as shown here. 163 2. Issues with Implementing RFC 6874 165 Several issues prevented RFC 6874 being implemented in browsers: 167 1. There was some disagreement with requiring percent-encoding of 168 the "%" sign preceding a zone identifier. This requirement is 169 dropped in the present document. 171 2. The requirement to delete any zone identifier before emitting a 172 URI from the host in an HTTP message was considered both too 173 complex to implement and in violation of normal HTTP practice 174 [RFC7230]. This requirement has been dropped from the present 175 document. 177 3. The suggestion to pragmatically allow a bare "%" sign when this 178 would be unambiguous was considered both too complex to implement 179 and confusing for users. This suggestion has been dropped from 180 the present document since it is now irrelevant. 182 3. Specification 184 According to IPv6 Scoped Address syntax [RFC4007], a zone identifier 185 is attached to the textual representation of an IPv6 address by 186 concatenating "%" followed by , where is a string 187 identifying the zone of the address. However, the IPv6 Scoped 188 Address Architecture specification gives no precise definition of the 189 character set allowed in . There are no rules or de facto 190 standards for this. For example, the first Ethernet interface in a 191 host might be called %0, %1, %25, %en1, %eth0, or whatever the 192 implementer happened to choose. 194 In a URI, a literal IPv6 address is always embedded between "[" and 195 "]". This document specifies how a zone identifier can be appended 196 to the address. The URI syntax defined by [RFC3986] does not allow 197 the presence of a percent ("%") character within an IPv6 address 198 literal. For this reason, it is backwards compatible to allow the 199 use of "%" within an IPv6 address literal as a delimiter only, such 200 that the scoped address fe80::abcd%en1 would appear in a URI as 201 http://[fe80::abcd%en1] or https://[fe80::abcd%en1]. 203 This use of "%" as a delimiter applies only within an IPv6 address 204 literal, and is irrelevant to and exempt from the percent-encoding 205 mechanism [RFC3986]. 207 A zone identifier MUST 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. For the 210 avoidance of doubt, note that a zone identifier consisting of "25" or 211 starting with "25" is valid and is used in some operating systems. A 212 parser MUST NOT apply percent decoding to the IPv6 address literal in 213 a URI, including cases such as http://[fe80::abcd%25] and 214 http://[fe80::abcd%25xy]. 216 If an operating system uses any other characters in zone or interface 217 identifiers that are not in the "unreserved" character set, they 218 cannot be used in a URI. 220 We now present the corresponding formal syntax. 222 The URI syntax specification [RFC3986] formally defines the IPv6 223 literal format in ABNF [RFC5234] by the following rule: 225 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 227 To provide support for a zone identifier, the existing syntax of 228 IPv6address is retained, and a zone identifier may be added 229 optionally to any literal address. This syntax allows flexibility 230 for unknown future uses. The rule quoted above from [RFC3986] is 231 replaced by three rules: 233 IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]" 235 ZoneID = 1*( unreserved ) 237 IPv6addrz = IPv6address "%" ZoneID 239 This change also applies to [RFC3987]. 241 This syntax fills the gap that is described at the end of 242 Section 11.7 of the IPv6 Scoped Address Architecture specification 243 [RFC4007]. It replaces and obsoletes the syntax in Section 2 of 244 [RFC6874]. 246 The established rules for textual representation of IPv6 addresses 247 [RFC5952] SHOULD be applied in producing URIs. 249 The URI syntax specification [RFC3986] states that URIs have a global 250 scope, but that in some cases their interpretation depends on the 251 end-user's context. URIs including a zone identifier are to be 252 interpreted only in the context of the host at which they originate, 253 since the zone identifier is of local significance only. 255 The IPv6 Scoped Address Architecture specification [RFC4007] offers 256 guidance on how the zone identifier affects interface/address 257 selection inside the IPv6 stack. Note that the behaviour of an IPv6 258 stack, if it is passed a non-null zone index for an address other 259 than link-local, is undefined. 261 In cases where the RFC 6874 encoding is currently used between 262 specific software components rather than between a browser and a web 263 server, such usage MAY continue indefinitely. 265 4. URI Parsers 267 This section discusses how URI parsers, such as those embedded in web 268 browsers, might handle this syntax extension. Unfortunately, there 269 is no formal distinction between the syntax allowed in a browser's 270 input dialogue box and the syntax allowed in URIs. For this reason, 271 no normative statements are made in this section. 273 In practice, although parsers respect the established syntax, they 274 are coded pragmatically rather than being formally syntax-driven. 275 Typically, IP address literals are handled by an explicit code path. 276 Parsers have been inconsistent in providing for zone identifiers. 277 Most have no support, but there have been examples of ad hoc support. 278 For example, some versions of Firefox allowed the use of a zone 279 identifier preceded by a bare "%" character, but this feature was 280 removed for consistency with established syntax [RFC3986]. As 281 another example, some versions of Internet Explorer allowed use of a 282 zone identifier preceded by a "%" character encoded as "%25", still 283 beyond the syntax allowed by the established rules [RFC3986]. This 284 syntax extension is in fact used internally in the Windows operating 285 system and some of its APIs. 287 It is desirable for all URI parsers to recognise a zone identifier 288 according to the syntax defined in Section 3. Any code handling 289 percent-encoding or percent-decoding must be aware that the "%" 290 character preceding the zone identifier is never itself percent- 291 encoded, as specified by ABNF above. In terms of Section 2.4 of 292 [RFC3986], this "%" character is acting as a delimiter, not as data. 294 URIs including a zone identifier have no meaning outside the 295 originating HTTP client node. However, in some use cases, such as 296 CUPS mentioned above, the host address embedded in the URI will be 297 reflected back to the client, using exactly the representation of the 298 zone identifier that the client sent. 300 The various use cases for the zone identifier syntax will cause it to 301 be entered in a browser's input dialogue box. Thus, URIs including a 302 zone identifier are unlikely to occur in HTML documents. However, if 303 they do (for example, in a diagnostic script coded in HTML), it would 304 be appropriate to treat them exactly as above. 306 5. Security Considerations 308 The security considerations from the URI syntax specification 309 [RFC3986] and the IPv6 Scoped Address Architecture specification 310 [RFC4007] apply. In particular, this URI format creates a specific 311 pathway by which a deceitful zone index might be communicated, as 312 mentioned in the final security consideration of the Scoped Address 313 Architecture specification. 315 However, this format is only meaningful for link-local addresses 316 under prefix fe80::/10. It is not necessary for web browsers to 317 verify this, or to validate the zone identifier, because the 318 operating system will do so when the address is passed to the socket 319 API, and return an error code if the zone identifier is invalid. 321 It is conceivable that this format could be misused to probe a local 322 network configuration in some way. However, that would only be 323 possible for an attacker that had already gained sufficient control 324 of a host to originate HTTP messages. Such an attacker could more 325 easily probe using basic mechanisms such as the "ping" command. 327 6. Acknowledgements 329 The lack of this format was first pointed out by Margaret Wasserman 330 and later by Kerry Lynn. A previous draft document by Bill Fenner 331 and Martin Dürst [LITERAL-ZONE] discussed this topic but was not 332 finalised. Michael Sweet and Andrew Cady explained some of the 333 difficulties caused by RFC 6874. The ABNF syntax proposed above was 334 drafted by Andrew Cady. 336 Valuable comments and contributions were made by Karl Auer, Carsten 337 Bormann, Benoit Claise, Martin Dürst, Stephen Farrell, Brian 338 Haberman, Ted Hardie, Philip Homburg, Tatuya Jinmei, Yves Lafon, 339 Barry Leiba, Ben Maddison, Radia Perlman, Tom Petch, Michael 340 Richardson, Tomoyuki Sahara, Juergen Schoenwaelder, Nico Schottelius, 341 Dave Thaler, Martin Thomson, Ole Troan, Shang Ye, and others. 343 7. References 345 7.1. Normative References 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 353 Resource Identifier (URI): Generic Syntax", STD 66, 354 RFC 3986, DOI 10.17487/RFC3986, January 2005, 355 . 357 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 358 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 359 January 2005, . 361 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 362 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 363 DOI 10.17487/RFC4007, March 2005, 364 . 366 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 367 Specifications: ABNF", STD 68, RFC 5234, 368 DOI 10.17487/RFC5234, January 2008, 369 . 371 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 372 Address Text Representation", RFC 5952, 373 DOI 10.17487/RFC5952, August 2010, 374 . 376 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 377 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 378 May 2017, . 380 7.2. Informative References 382 [CUPS] Apple, "Apple CUPS", 2022, . 384 [LITERAL-ZONE] 385 Fenner, B. and M. Dürst, "Formats for IPv6 Scope Zone 386 Identifiers in Literal Address Formats", Work in Progress, 387 October 2005. 389 [OP-CUPS] Sweet, M., "OpenPrinting CUPS", 2022, 390 . 392 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 393 Stevens, "Basic Socket Interface Extensions for IPv6", 394 RFC 3493, DOI 10.17487/RFC3493, February 2003, 395 . 397 [RFC3510] Herriot, R. and I. McDonald, "Internet Printing 398 Protocol/1.1: IPP URL Scheme", RFC 3510, 399 DOI 10.17487/RFC3510, April 2003, 400 . 402 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 403 Schoenwaelder, "Textual Conventions for Internet Network 404 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 405 . 407 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 408 IPv6 Zone Identifiers in Address Literals and Uniform 409 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 410 February 2013, . 412 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 413 Protocol (HTTP/1.1): Message Syntax and Routing", 414 RFC 7230, DOI 10.17487/RFC7230, June 2014, 415 . 417 [RFC7472] McDonald, I. and M. Sweet, "Internet Printing Protocol 418 (IPP) over HTTPS Transport Binding and the 'ipps' URI 419 Scheme", RFC 7472, DOI 10.17487/RFC7472, March 2015, 420 . 422 Appendix A. Options Considered 424 The syntax defined above allows a zone identifier to be added to any 425 IPv6 address. The 6man WG discussed and rejected an alternative in 426 which the existing syntax of IPv6address would be extended by an 427 option to add the zone identifier only for the case of link-local 428 addresses. It was felt that the solution presented in this document 429 offers more flexibility for future uses and is more straightforward 430 to implement. 432 The various syntax options considered are now briefly described. 434 1. Leave the problem unsolved. 436 This would mean that per-interface diagnostics would still have 437 to be performed using ping or ping6: 439 ping fe80::abcd%en1 441 Advantage: works today. 443 Disadvantage: less convenient than using a browser. Leaves some 444 use cases unsatisfied. 446 2. Simply use the percent character: 448 http://[fe80::abcd%en1] 450 Advantage: allows use of browser; allows cut and paste. 452 Disadvantage: requires code changes to all URI parsers. 454 This is the option chosen for standardisation. 456 3. Simply use an alternative separator: 458 http://[fe80::abcd-en1] 459 Advantage: allows use of browser; simple syntax. 461 Disadvantage: Requires all IPv6 address literal parsers and 462 generators to be updated in order to allow simple cut and paste; 463 inconsistent with existing tools and practice. 465 Note: The initial proposal for this choice was to use an 466 underscore as the separator, but it was noted that this becomes 467 effectively invisible when a user interface automatically 468 underlines URLs. 470 4. Simply use the "IPvFuture" syntax left open in RFC 3986: 472 http://[v6.fe80::abcd_en1] 474 Advantage: allows use of browser. 476 Disadvantage: ugly and redundant; doesn't allow simple cut and 477 paste. 479 5. Retain the percent character already specified for introducing 480 zone identifiers for IPv6 Scoped Addresses [RFC4007], and then 481 percent-encode it when it appears in a URI, according to the 482 already-established URI syntax rules [RFC 3986]: 484 http://[fe80::abcd%25en1] 486 Advantage: allows use of browser; consistent with general URI 487 syntax. 489 Disadvantage: somewhat ugly and confusing; doesn't allow simple 490 cut and paste. 492 Appendix B. Change log 494 This section is to be removed before publishing as an RFC. 496 * draft-ietf-6man-rfc6874bis-01, 2022-04-07: 498 - Extended use cases 500 - Clarified relationship with RFC3986 language 502 - Allow for legacy use of RFC6874 format 504 - Augmented security considerations 506 - Editorial and reference improvements 508 * draft-ietf-6man-rfc6874bis-00, 2022-03-19: 510 - WG adoption 512 - Clarified security considerations 514 * draft-carpenter-6man-rfc6874bis-03, 2022-02-08: 516 - Changed to bare % signs. 518 - Added IRIs, RFC3987 520 - Editorial fixes 522 * draft-carpenter-6man-rfc6874bis-02, 2021-18-12: 524 - Give details of open issues 526 - Update authorship 528 - Editorial fixes 530 * draft-carpenter-6man-rfc6874bis-01, 2021-07-11: 532 - Added section on issues with RFC6874 534 - Removed suggested heuristic for bare % signs 536 - Editorial fixes 538 * draft-carpenter-6man-rfc6874bis-00, 2021-07-05: 540 - Initial version 542 Authors' Addresses 544 Brian Carpenter 545 School of Computer Science 546 University of Auckland 547 PB 92019 548 Auckland 1142 549 New Zealand 550 Email: brian.e.carpenter@gmail.com 551 Stuart Cheshire 552 Apple Inc. 553 1 Infinite Loop 554 Cupertino, CA 95014 555 United States of America 556 Email: cheshire@apple.com 558 Robert M. Hinden 559 Check Point Software 560 959 Skyway Road 561 San Carlos, CA 94070 562 United States of America 563 Email: bob.hinden@gmail.com