idnits 2.17.1 draft-ietf-sip-ipv6-abnf-fix-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 Introduction section. -- The draft header indicates that this document updates RFC3261, but the abstract doesn't seem to directly say this. It does mention RFC3261 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 RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (April 30, 2010) is 5110 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 2373 (ref. '7') (Obsoleted by RFC 3513) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Updates: 3261 (if approved) B. Carpenter, Ed. 5 Intended status: Standards Track Univ. of Auckland 6 Expires: November 1, 2010 B. Tate, Ed. 7 BroadSoft 8 April 30, 2010 10 Essential correction for IPv6 ABNF and URI comparison in RFC3261 11 draft-ietf-sip-ipv6-abnf-fix-05 13 Abstract 15 This document corrects the Augmented Backus-Naur Form (ABNF) 16 production rule associated with generating IPv6 literals in RFC3261. 17 It also clarifies the rule for Uniform Resource Identifier (URI) 18 comparison when the URIs contain textual representation of IP 19 addresses. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on November 1, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Extra colon in IPv4-mapped IPv6 address . . . . . . . . . . 3 64 2.2. Comparing URIs with textual representation of IP 65 addresses . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Resolution for extra colon in IPv4-mapped IPv6 address . . 4 68 3.2. Clarification for comparison of URIs with textual 69 representation of IP addresses . . . . . . . . . . . . . . 5 70 4. Generating a Canonical IPv6 Textual Representation . . . . . . 6 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [2]. 85 2. Problem statement 87 2.1. Extra colon in IPv4-mapped IPv6 address 89 The ABNF [4] for generating IPv6 literals in RFC3261 [1] is 90 incorrect. When generating IPv4-mapped IPv6 addresses, the 91 production rule may actually generate the following construct: 93 [2001:db8:::192.0.2.1] - Note the extra colon before the IPv4 94 address. 96 The correct construct, of course, would only include two colons 97 before the IPv4 address. 99 Historically, the ABNF pertaining to IPv6 references in RFC3261 100 was derived from Appendix B of RFC 2373 [7], which was flawed to 101 begin with (see also RFC2373 errata at 102 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2373.) 103 RFC2373 has been subsequently obsoleted by RFC 4291 [6]. 105 The ABNF for IPv6 reference is reproduced from RFC3261 below: 107 IPv6reference = "[" IPv6address "]" 108 IPv6address = hexpart [ ":" IPv4address ] 109 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 110 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 111 hexseq = hex4 *( ":" hex4) 112 hex4 = 1*4HEXDIG 114 Note that the ambiguity occurs in the production rule 115 where the non-terminal is prefixed by the ":" token. 116 Because the production rule is defined such that two of its 117 alternatives already include the "::" token, this may yield to the 118 faulty construction of an IPv6-mapped IPv4 address with an extra 119 colon when expanding those alternatives. 121 2.2. Comparing URIs with textual representation of IP addresses 123 In SIP, URIs are compared for a variety of reasons. Registrars 124 compare URIs when they receive a binding update request, for 125 instance. Section 19.1.4 of RFC3261 [1] provides the rules for 126 comparing URIs. Among other rules, it states that: 128 For two URIs to be equal, the user, password, host, and port 129 components must match. 131 Does the above rule then imply that the following URIs are equal: 133 sip:bob@[::ffff:192.0.2.128] = sip:bob@[::ffff:c000:280]? 135 sip:bob@[2001:db8::9:1] = sip:bob@[2001:db8::9:01]? 137 sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] = sip:bob@ 138 [::FFFF:129.144.52.38]? 140 In all of the above examples, the textual representation of the IPv6 141 address is different, but these addresses are binary equivalent 142 (implementers are also urged to consult Section 4 of this document 143 for recommendations on IPv6 address text representations.) Section 144 19.1.4 of RFC3261 does not provide any rule for URIs containing 145 different textual representations of IPv6 addresses that all 146 correspond to the same binary equivalent. 148 Note that the same ambiguity occurs for IPv4 addresses, i.e., is 149 192.0.2.128 = 192.00.02.128? However, IPv6, with its compressed 150 notation and the need to represent hybrid addresses (like IPv4- 151 mapped IPv6 addresses) makes the representation issue more acute. 152 The resolution discussed in Section 3.2 applies to textual 153 representations of both IPv6 and IPv4 addresses. 155 3. Resolution 157 3.1. Resolution for extra colon in IPv4-mapped IPv6 address 159 The resolution to this ambiguity is simply to use the correct ABNF 160 for the production rule from Appendix A of RFC3986 [3]. 161 For the sake of completeness, it is reproduced below: 163 IPv6address = 6( h16 ":" ) ls32 164 / "::" 5( h16 ":" ) ls32 165 / [ h16 ] "::" 4( h16 ":" ) ls32 166 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 167 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 168 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 169 / [ *4( h16 ":" ) h16 ] "::" ls32 170 / [ *5( h16 ":" ) h16 ] "::" h16 171 / [ *6( h16 ":" ) h16 ] "::" 173 h16 = 1*4HEXDIG 174 ls32 = ( h16 ":" h16 ) / IPv4address 175 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 176 dec-octet = DIGIT ; 0-9 177 / %x31-39 DIGIT ; 10-99 178 / "1" 2DIGIT ; 100-199 179 / "2" %x30-34 DIGIT ; 200-249 180 / "25" %x30-35 ; 250-255 182 Accordingly, this document updates RFC3261 as follows: the 183 and production rules MUST be deleted from 184 RFC3261 and MUST be replaced with the production rules of the same 185 name in RFC3986 (and reproduced above.) These changes, when made to 186 RFC3261, will make , , and production rules 187 obsolete. Thus this document also mandates that the , 188 , and production rules MUST be deleted from the ABNF 189 of RFC3261. 191 3.2. Clarification for comparison of URIs with textual representation 192 of IP addresses 194 The resolution to this ambiguity is a simple clarification 195 acknowledging that the textual representation of an IP addresses 196 varies, but it is the binary equivalence of the IP address that must 197 be taken into consideration when comparing two URIs that contain 198 varying textual representations of an IP address. 200 Accordingly, the existing rule from the bulleted list in Section 201 19.1.4 of RFC3261 MUST be modified as follows: 203 OLD: 205 o For two URIs to be equal, the user, password, host, and port 206 components must match. 208 NEW: 210 o For two URIs to be equal, the user, password, host, and port 211 components must match. If the host component contains a textual 212 representation of IP addresses, then the representation of those 213 IP addresses may vary. If so, the host components are considered 214 to match if the different textual representations yield the same 215 binary IP address. 217 In addition, the text in the following paragraph MUST be added to the 218 existing list of examples in Section 19.1.4 of RFC3261 in order to 219 demonstrate the intent of the modified rule: 221 The following URIs are equivalent because the underlying binary 222 representation of the IP addresses are the same although their 223 textual representations vary: 225 sip:bob@[::ffff:192.0.2.128] 226 sip:bob@[::ffff:c000:280] 228 sip:bob@[2001:db8::9:1] 229 sip:bob@[2001:db8::9:01] 231 sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] 232 sip:bob@[::FFFF:129.144.52.38] 234 4. Generating a Canonical IPv6 Textual Representation 236 Implementers SHOULD generate IPv6 text representation as defined in 237 [5]. 239 5. Security Considerations 241 This document does not introduce any new security considerations. 243 6. IANA Considerations 245 This document does not include any IANA considerations. 247 7. Acknowledgments 249 The ABNF for IPv6 was developed by Roy T. Fielding and Andrew Main 250 and published in RFC3986. 252 Jeroen van Bemmel, Peter Blatherwick, Gonzalo Camarillo, Paul 253 Kyzivat, Jonathan Rosenberg, Michael Thomas, and Dale Worley provided 254 invaluable discussion points on the SIP WG mailing list on the URI 255 equivalency problem. Alfred Hoenes urged the use of angle brackets 256 (as specified in Section 2.1 of [4]) to denote productions. 258 8. References 260 8.1. Normative References 262 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 263 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 264 Session Initiation Protocol", RFC 3261, June 2002. 266 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 267 Levels", BCP 14, RFC 2119, March 1997. 269 [3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 270 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 271 January 2005. 273 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax 274 Specifications: ABNF", STD 68, RFC 5234, January 2008. 276 [5] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 277 Address Text Representation", 278 draft-ietf-6man-text-addr-representation-07 (work in progress), 279 February 2010. 281 8.2. Informative References 283 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing 284 Architecture", RFC 4291, February 2006. 286 [7] Hinden, R. and S. Deering, "IP Version 6 Addressing 287 Architecture", RFC 2373, July 1998. 289 Authors' Addresses 291 Vijay K. Gurbani (editor) 292 Bell Laboratories, Alcatel-Lucent 293 1960 Lucent Lane 294 Room 9C-533 295 Naperville, IL 60563 296 USA 298 Phone: +1 630 224-0216 299 Email: vkg@bell-labs.com 301 Brian E. Carpenter (editor) 302 Department of Computer Science 303 University of Auckland 304 PB 92019 305 Auckland, 1142 306 New Zealand 308 Email: brian.e.carpenter@gmail.com 310 Brett Tate (editor) 311 BroadSoft 313 Email: brett@broadsoft.com