idnits 2.17.1 draft-carpenter-6man-uri-zoneid-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 : ---------------------------------------------------------------------------- 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 (December 7, 2011) is 4518 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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, 4007 (if approved) R. Hinden 5 Intended status: Standards Track Check Point 6 Expires: June 9, 2012 December 7, 2011 8 Representing IPv6 Zone Identifiers in Uniform Resource Identifiers 9 draft-carpenter-6man-uri-zoneid-00 11 Abstract 13 This document describes how the Zone Identifier of an IPv6 scoped 14 address can be represented in a Uniform Resource Identifier that 15 includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 9, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 [RFC3986] defined how a literal IPv6 address can be represented in 65 the "host" part of a Uniform Resource Identifier (URI). 66 Subsequently, [RFC4007] extended the text representation of limited- 67 scope IPv6 addresses such that a zone identifier may be concatenated 68 to an address, for purposes described in that RFC. Zone identifiers 69 are especially useful in contexts where literal addresses are 70 typically used, for example during fault diagnosis, when it may be 71 essential to specify which interface is used for sending to a link 72 local address. It should be noted that zone identifiers have purely 73 local meaning within the host where they are defined, and they are 74 completely meaningless for any other host. 76 RFC 4007 does not specify how zone identifiers are to be represented 77 in URIs. Practical experience has shown that this feature is useful, 78 in particular when using a web browser for debugging with link local 79 addresses, but as it is undefined, it is not implemented consistently 80 in URI parsers or in browsers. 82 This document updates [RFC3986] by adding syntax to allow a zone 83 identifier to be included in a literal IPv6 address. It also 84 clarifies some statements in [RFC4007]. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Specification 92 According to RFC 4007, a zone identifier is attached to the textual 93 representation of an IPv6 address by concatenating "%" followed by 94 , where is a string identifying the zone of the 95 address. However, RFC 4007 gives no precise definition of the 96 character set allowed in . There are no rules or de facto 97 standards for this. For example, the first Ethernet interface in a 98 host might be called %0, %1, %en1, %eth0, or whatever the implementer 99 happened to choose. 101 In a URI, a literal IPv6 address is always embedded between "[" and 102 "]". This document specifies that may contain any ASCII 103 character classified in RFC 3986 as "unreserved", which conveniently 104 excludes "]" in order to simplify parsing. 106 There is an additional complication in that "%" is always treated as 107 an escape character in a URI, and according to RFC 3986 it must 108 therefore itself be escaped in a URI, in the form "%25". Thus, the 109 scoped address fe80::a%en1 would appear in a produced URI as 110 http://[fe80::a%25en1]. 112 In RFC 3986, the IPv6 literal format is formally defined in ABNF 113 [RFC5234] by the following rule: 115 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 117 To provide support for a zone identifier, firstly a new rule is 118 added: 120 ZoneID = 1*15unreserved 122 Then two options are possible (to be discussed). 124 OPTION 1: 126 The existing syntax of IPv6address is extended by adding a specific 127 option for the case of link-local addresses. The following 128 definition of IPv6address replaces that given in RFC 3986: 130 IPv6address = 6( h16 ":" ) ls32 131 / "::" 5( h16 ":" ) ls32 132 / [ h16 ] "::" 4( h16 ":" ) ls32 133 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 134 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 135 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 136 / [ *4( h16 ":" ) h16 ] "::" ls32 137 / [ *5( h16 ":" ) h16 ] "::" h16 138 / [ *6( h16 ":" ) h16 ] "::" 139 / "fe80::" [ *3( h16 ":" ) h16 ] "%" ZoneID 141 OPTION 2: 143 The existing syntax of IPv6address is retained, and a zone identifier 144 may be added optionally to any literal address. This allows 145 flexibility for unknown future uses. The rule quoted above from RFC 146 3986 is replaced by two rules: 148 IP-literal = "[" ( IPv6addrz / IPvFuture ) "]" 150 IPv6addrz = IPv6address [ "%" ZoneID ] 152 The rules in [RFC5952] SHOULD be applied in producing URIs, and the 153 user MUST replace "%" by "%25" when manually constructing such a URI. 155 3. Security Considerations 157 The security considerations of [RFC3986] and [RFC4007] apply. In 158 particular, this URI format creates a specific pathway by which a 159 deceitful zone index might be communicated, as mentioned in the final 160 security consideration of RFC 4007. It is emphasised that the format 161 is intended only for debugging purposes, but of course this intention 162 does not prevent misuse. 164 IF OPTION 2 IS CHOSEN: 166 To limit this risk, implementations SHOULD NOT allow use of the 167 format except for link local addresses under prefix fe80::/10. 169 4. IANA Considerations 171 This document requests no action by IANA. 173 5. Acknowledgements 175 The lack of this format was pointed out by Kerry Lynn. Valuable 176 comments and contributions were made by... 178 This document was produced using the xml2rfc tool [RFC2629]. 180 6. Change log [RFC Editor: Please remove] 182 draft-carpenter-v6ops-label-balance-00: original version, 2011-12-07. 184 7. References 186 7.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 192 Resource Identifier (URI): Generic Syntax", STD 66, 193 RFC 3986, January 2005. 195 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 196 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 197 March 2005. 199 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 200 Specifications: ABNF", STD 68, RFC 5234, January 2008. 202 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 203 Address Text Representation", RFC 5952, August 2010. 205 7.2. Informative References 207 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 208 June 1999. 210 Authors' Addresses 212 Brian Carpenter 213 Department of Computer Science 214 University of Auckland 215 PB 92019 216 Auckland, 1142 217 New Zealand 219 Email: brian.e.carpenter@gmail.com 221 Robert M. Hinden 222 Check Point Software Technologies, Inc. 223 800 Bridge Parkway 224 Redwood City, CA 94065 225 US 227 Email: bob.hinden@gmail.com