idnits 2.17.1 draft-ietf-6man-uri-zoneid-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 10, 2012) is 4238 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) == Unused Reference: 'I-D.iab-identifier-comparison' is defined on line 288, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-iab-identifier-comparison-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 3 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 Updates: 3986 (if approved) R. Hinden 5 Intended status: Standards Track Check Point 6 Expires: March 14, 2013 September 10, 2012 8 Representing IPv6 Zone Identifiers in Address Literals and Uniform 9 Resource Identifiers 10 draft-ietf-6man-uri-zoneid-03 12 Abstract 14 This document describes how the Zone Identifier of an IPv6 scoped 15 address can be represented in a literal IPv6 address and in a Uniform 16 Resource Identifier that includes such a literal address. It updates 17 RFC 3986 accordingly. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 14, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 [RFC3986] defined how a literal IPv6 address can be represented in 69 the "host" part of a Uniform Resource Identifier (URI). 70 Subsequently, [RFC4007] extended the text representation of limited- 71 scope IPv6 addresses such that a zone identifier may be concatenated 72 to a literal address, for purposes described in that RFC. Zone 73 identifiers are especially useful in contexts where literal addresses 74 are typically used, for example during fault diagnosis, when it may 75 be essential to specify which interface is used for sending to a link 76 local address. It should be noted that zone identifiers have purely 77 local meaning within the host where they are defined, and they are 78 completely meaningless for any other host. Today, they are only 79 meaningful when attached to addresses with less than global scope, 80 but it is possible that other uses might be defined in the future. 82 RFC 4007 does not specify how zone identifiers are to be represented 83 in URIs. Practical experience has shown that this feature is useful, 84 in particular when using a web browser for debugging with link local 85 addresses, but as it is undefined, it is not implemented consistently 86 in URI parsers or in browsers. 88 Some versions of some browsers accept the RFC 4007 syntax for scoped 89 IPv6 addresses embedded in URIs, i.e., they have been coded to 90 interpret the "%" sign according to RFC 4007 instead of RFC 3986. 91 Clearly this approach is very convenient for users, although it 92 formally breaches the syntax rules of RFC 3986. The present document 93 defines an alternative approach that respects and extends the rules 94 of URI syntax, and IPv6 literals in general, to be consistent. 96 Thus, this document updates [RFC3986] by adding syntax to allow a 97 zone identifier to be included in a literal IPv6 address within a 98 URI. 100 It should be noted that in other contexts than a user interface, a 101 zone identifier is mapped into a numeric zone index or interface 102 number. The MIB textual convention [RFC4001] and the socket 103 interface [RFC3493] define this as a 32 bit unsigned integer. The 104 mapping between the human-readable zone identifier string and the 105 numeric value is a host-specific function that varies between 106 operating systems. The present document is concerned only with the 107 human-readable string. 109 Several alternative solutions were considered while this document was 110 developed. The Appendix briefly describes the alternatives and their 111 advantages and disadvantages. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Specification 119 According to RFC 4007, a zone identifier is attached to the textual 120 representation of an IPv6 address by concatenating "%" followed by 121 , where is a string identifying the zone of the 122 address. However, RFC 4007 gives no precise definition of the 123 character set allowed in . There are no rules or de facto 124 standards for this. For example, the first Ethernet interface in a 125 host might be called %0, %1, %en1, %eth0, or whatever the implementer 126 happened to choose. 128 In a URI, a literal IPv6 address is always embedded between "[" and 129 "]". This document specifies how a can be appended to the 130 address. A SHOULD contain only ASCII characters classified 131 in RFC 3986 as "unreserved", which conveniently excludes "]" in order 132 to simplify parsing. 134 Unfortunately "%" is always treated as an escape character in a URI, 135 and according to RFC 3986 it MUST therefore itself be escaped in a 136 URI, in the form "%25". Thus, the scoped address fe80::a%en1 would 137 appear in a URI as http://[fe80::a%25en1]. 139 If an operating system uses any other characters in zone or interface 140 identifiers that are not in the "unreserved" character set, they MUST 141 be escaped with a "%" sign according to RFC 3986. 143 We now present the necessary formal syntax. 145 In RFC 3986, the IPv6 literal format is formally defined in ABNF 146 [RFC5234] by the following rule: 148 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 150 To provide support for a zone identifier, the existing syntax of 151 IPv6address is retained, and a zone identifier may be added 152 optionally to any literal address. This allows flexibility for 153 unknown future uses. The rule quoted above from RFC 3986 is replaced 154 by three rules: 156 IP-literal = "[" ( IPv6addrz / IPvFuture ) "]" 158 ZoneID = 1*( unreserved / pct-encoded ) 160 IPv6addrz = IPv6address [ "%" ZoneID ] 162 The rules in [RFC5952] SHOULD be applied in producing URIs. 164 RFC 3986 states that URIs have a global scope, but that in some cases 165 their interpretation depends on the end-user's context. URIs 166 including a ZoneID are to be interpreted only in the context of the 167 host where they originate, since the ZoneID is of local signifance 168 only. 170 The 6man WG discussed and rejected an alternative in which the 171 existing syntax of IPv6address would be extended by an option to add 172 the ZoneID only for the case of link-local addresses. It was felt 173 that the present solution offers more flexibility for future uses and 174 is more straightforward to implement. 176 RFC 4007 offers guidance on how the ZoneID affects interface/address 177 selection inside the IPv6 stack. Note that the behaviour of an IPv6 178 stack if passed a non-zero zone index for an address other than link- 179 local is undefined. 181 3. Web Browsers 183 Due to the lack of a standard in this area, web browsers have been 184 inconsistent in providing for ZoneIDs. Many have no support, but 185 there are examples of ad hoc support. For example, older versions of 186 Firefox allowed the use of a ZoneID preceded by an unescaped "%" 187 character, but this was removed for consistency with RFC 3986. As 188 another example, recent versions of Internet Explorer allow use of a 189 ZoneID preceded by a "%" character escaped as "%25", still beyond the 190 syntax allowed by RFC 3986. This syntax extension is in fact used 191 internally in the Windows operating system and some of its APIs. 193 This document implies that all browsers should recognise a ZoneID 194 preceded by an escaped "%". In the spirit of "be liberal with what 195 you accept", we also recommend that URI parsers accept bare "%" signs 196 (i.e., a "%" not followed by two valid hexadecimal characters). This 197 makes it easy for a user to copy and paste a string such as 198 "fe80::a%en1" from the output of a "ping" command and have it work. 200 4. Security Considerations 202 The security considerations of [RFC3986] and [RFC4007] apply. In 203 particular, this URI format creates a specific pathway by which a 204 deceitful zone index might be communicated, as mentioned in the final 205 security consideration of RFC 4007. It is emphasised that the format 206 is intended only for debugging purposes, but of course this intention 207 does not prevent misuse. 209 To limit this risk, implementations SHOULD NOT allow use of this 210 format except for well-defined usages such as sending to link local 211 addresses under prefix fe80::/10. 213 An HTTP server or proxy MUST ignore any ZoneID attached to an 214 incoming URI, as it only has local significance at the sending host. 216 5. IANA Considerations 218 This document requests no action by IANA. 220 6. Acknowledgements 222 The lack of this format was first pointed out by Margaret Wasserman 223 some years ago, and more recently by Kerry Lynn. A previous draft 224 document by Martin Duerst and Bill Fenner [I-D.fenner-literal-zone] 225 discussed this topic but was not finalised. 227 Valuable comments and contributions were made by Karl Auer, Carsten 228 Bormann, Brian Haberman, Tatuya Jinmei, Tom Petch, Tomoyuki Sahara, 229 Juergen Schoenwaelder, Dave Thaler, and Ole Troan. 231 Stuart Cheshire suggested the current approach taken by this 232 document. 234 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 235 University during part of this work. 237 This document was produced using the xml2rfc tool [RFC2629]. 239 7. Change log [RFC Editor: Please remove] 241 draft-ietf-6man-uri-zoneid-03: reverted to percent-encoded model 242 following WGLC, 2012-09-10. 244 draft-ietf-6man-uri-zoneid-02: additional WG comments, 2012-07-11. 246 draft-ietf-6man-uri-zoneid-01: use "-" instead of %25, listed 247 alternatives in Appendix, according to WG debate, added suggestion 248 for browser developers, 2012-05-29. 250 draft-ietf-6man-uri-zoneid-00: adopted by WG, fixed syntax to allow 251 for % encoded characters, 2012-02-17. 253 draft-carpenter-6man-uri-zoneid-01: chose Option 2, removed 15 254 character limit, added explanation of ID/number mapping and other 255 clarifications, 2012-02-08. 257 draft-carpenter-6man-uri-zoneid-00: original version, 2011-12-07. 259 8. References 261 8.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 267 Resource Identifier (URI): Generic Syntax", STD 66, 268 RFC 3986, January 2005. 270 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 271 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 272 March 2005. 274 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 275 Specifications: ABNF", STD 68, RFC 5234, January 2008. 277 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 278 Address Text Representation", RFC 5952, August 2010. 280 8.2. Informative References 282 [I-D.fenner-literal-zone] 283 Fenner, B. and M. Duerst, "Formats for IPv6 Scope Zone 284 Identifiers in Literal Address Formats", 285 draft-fenner-literal-zone-02 (work in progress), 286 October 2005. 288 [I-D.iab-identifier-comparison] 289 Thaler, D., "Issues in Identifier Comparison for Security 290 Purposes", draft-iab-identifier-comparison-03 (work in 291 progress), July 2012. 293 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 294 June 1999. 296 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 297 Stevens, "Basic Socket Interface Extensions for IPv6", 298 RFC 3493, February 2003. 300 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 302 Schoenwaelder, "Textual Conventions for Internet Network 303 Addresses", RFC 4001, February 2005. 305 [chrome] Google, "Use the address bar (omnibox)", 2012, . 308 Appendix A. Alternatives Considered 310 1. Leave the problem unsolved. 312 This would mean that per-interface diagnostics would still have 313 to be performed using ping or ping6: 315 ping fe80::a%en1 317 Advantage: works today. 319 Disadvantage: less convenient than using a browser. 321 2. Simply using the percent character. 323 http://[fe80::a%en1] 325 Advantage: allows use of browser, allows cut and paste. 327 Disadvantage: invalid syntax under RFC 3986; not acceptable to 328 URI community. 330 3. Escaping the escape character as allowed by RFC 3986: 332 http://[fe80::a%25en1] 334 Advantage: allows use of browser, consistent with general URI 335 syntax. 337 Disadvantage: somewhat ugly and confusing, doesn't allow simple 338 cut and paste. 340 4. Alternative separator 342 http://[fe80::a-en1] 344 Advantage: allows use of browser, simple syntax 346 Disadvantage: Requires all IPv6 address literal parsers and 347 generators to be updated in order to allow simple cut and paste; 348 inconsistent with existing tools and practice. 350 Note: the initial proposal for this choice was to use an 351 underscore as the separator, but it was noted that this becomes 352 effectively invisible when a user interface automatically 353 underlines URLs. 355 5. With the "IPvFuture" syntax left open in RFC 3986: 357 http://[v6.fe80::a_en1] 359 Advantage: allows use of browser. 361 Disadvantage: ugly and redundant, doesn't allow simple cut and 362 paste. 364 Authors' Addresses 366 Brian Carpenter 367 Department of Computer Science 368 University of Auckland 369 PB 92019 370 Auckland, 1142 371 New Zealand 373 Email: brian.e.carpenter@gmail.com 375 Robert M. Hinden 376 Check Point Software Technologies, Inc. 377 800 Bridge Parkway 378 Redwood City, CA 94065 379 US 381 Email: bob.hinden@gmail.com