One document matched: draft-ietf-sip-ipv6-abnf-fix-00.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY rfc2373 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2373.xml">
<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY I-D.drage-sip-essential-correction SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.drage-sip-essential-correction.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc comments='yes' ?>
<?rfc inline='no' ?>

<rfc docName="DOCNAME"
     category="std"
     ipr="full3978"
     updates="3261">
<front>

<title abbrev="SIP IPv6 ABNF">
 Essential correction for IPv6 ABNF and URI comparison in RFC3261</title>


<author initials="V.K." 
        surname="Gurbani" 
        fullname="Vijay K. Gurbani"
        role="editor">
 <organization>Bell Laboratories, Alcatel-Lucent</organization>
 <address>
  <postal>
   <street>2701 Lucent Lane</street>
   <street>Room 9F-546</street>
   <city>Lisle</city>
   <region>IL</region>
   <code>60532</code>
   <country>USA</country>
  </postal>
  <phone>+1 630 224-0216</phone>
  <email>vkg@alcatel-lucent.com</email>
 </address>
</author>


<author initials= "B.E." surname="Carpenter" fullname="Brian E. Carpenter"
        role="editor">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <country>New Zealand</country>
        <code>1142</code>
        <region></region>
        <city>Auckland</city>
      </postal>
      <email>brian.e.carpenter@gmail.com</email>
    </address> 
</author>


<author initials="B." surname="Tate" fullname="Brett Tate" role="editor">
   <organization>BroadSoft</organization>
   <address>
        <email>brett@broadsoft.com</email>
   </address>
</author>

<date year="2008"/>

<area>Realtime Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>

<abstract>
<t>This memo corrects the Augmented Backus-Naur Form (ABNF) production
rule associated with generating IPv6 literals in RFC3261.  It also
clarifies the rule for Uniform Resource Identifier (URI) comparison 
when the URIs contain textual representation of IP addresses.</t>
</abstract> 

</front>

<middle>

<section title="Terminology" >
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119">RFC 2119</xref>. </t>
</section>

<section title="Problem statement" anchor="problem">

<section title="Extra colon in IPv4-mapped IPv6 address"
         anchor="problem-1">
<t>The ABNF <xref target="RFC5234"/> for generating IPv6 literals in RFC3261 
<xref target="RFC3261"/> is incorrect.  When generating IPv4-mapped IPv6 
addresses, the production rule may actually generate the following 
construct:</t>

<t>[2001:db8:::192.0.2.1] - Note the extra colon before the IPv4 address.</t>

<t>The correct construct, of course, would only include two colons before the
IPv4 address.</t>

<t><list style="empty">
 <t>Historically, the ABNF pertaining to IPv6 references in RFC3261 was 
 derived from Appendix B of RFC 2373 <xref target="RFC2373"/>, which 
 was flawed to begin with (see also RFC2373 errata at 
 http://www.rfc-editor.org/cgi-bin/errataSearch.pl?rfc=2373.)  RFC2373 has 
 been subsequently obsoleted by  RFC 4291 <xref target="RFC4291"/>.</t>
</list></t>

<t>The ABNF for IPv6 reference is reproduced from RFC3261 below:</t>

  <figure><artwork><![CDATA[
    IPv6reference  =  "[" IPv6address "]"
    IPv6address    =  hexpart [ ":" IPv4address ]
    IPv4address    =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
    hexpart        =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
    hexseq         =  hex4 *( ":" hex4)
    hex4           =  1*4HEXDIG
  ]]></artwork></figure>

<t>Note that the ambiguity occurs in the "IPv6address" production rule
where the "IPv4address" non-terminal is prefixed by ":" token.  Because 
the "hexpart" production rule is defined such that two of its alternatives
already include the "::" token, this may yield to the faulty construction 
of an IPv6-mapped IPv4 address with an extra colon when expanding those
alternatives.</t>

</section> <!-- problem-1 -->

<section title="Comparing URIs with textual representation of IP addresses"
         anchor="problem-2">

<t>In SIP, URIs are compared for a variety of reasons.  Registrars 
compare URIs when they receive a binding update request, for instance.
Section 19.1.4 of RFC3261 <xref target="RFC3261"/> provides the rules for
comparing URIs.  Among other rules, it states that:

 <list style="empty">
  <t>For two URIs to be equal, the user, password, host, and port
     components must match.</t>
 </list>

Does the above rule then imply that the following URIs are equal:

 <list style="empty">
  <t>sip:bob@[::ffff:192.0.2.128] = sip:bob@[::ffff:c000:280]?</t>
  <t>sip:bob@[2001:db8::9:1] = sip:bob@[2001:db8::9:01]?</t>
  <t>sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] = 
     sip:bob@[::FFFF:129.144.52.38]?</t>
  </list>
</t>

<t>In all of the above examples, the textual representation of the 
IPv6 address is different, but these addresses are binary equivalent.
Section 19.1.4 of RFC3261 does not provide any rule for URIs
containing different textual representations of IPv6 addresses that 
all correspond to the same binary equivalent.

 <list style="empty">
  <t>Note that the same ambiguity occurs for IPv4 addresses, i.e.,
  is 192.0.2.128 = 192.00.02.128?  However, IPv6, with its 
  compressed notation and the need to represent hybrid addresses 
  (like IPv4-mapped IPv6 addresses) makes the representation issue 
  more acute.  The resolution discussed in <xref target="resolution-2"/>
  applies to textual representations of both IPv6 and IPv4 addresses.</t>
 </list>
</t>


</section> <!-- problem-2 -->

</section> <!-- Problem statement -->

<section title="Resolution" anchor="resolution">

<section title="Resolution for extra colon in IPv4-mapped IPv6 address"
         anchor="resolution-1">

<t>The resolution to this ambiguity is simply to use the correct ABNF
for the "IPv6address" production rule from Appendix A of RFC3986
<xref target="RFC3986"/>.  For the sake of completeness, it is reproduced
below:</t>

  <figure><artwork><![CDATA[
  IPv6address   =                             6( h16 ":" ) ls32
                 /                       "::" 5( h16 ":" ) ls32
                 / [               h16 ] "::" 4( h16 ":" ) ls32
                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                 / [ *4( h16 ":" ) h16 ] "::"              ls32
                 / [ *5( h16 ":" ) h16 ] "::"              h16
                 / [ *6( h16 ":" ) h16 ] "::"

   h16           = 1*4HEXDIG
   ls32          = ( h16 ":" h16 ) / IPv4address
   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
   dec-octet     = DIGIT                 ; 0-9
                 / %x31-39 DIGIT         ; 10-99
                 / "1" 2DIGIT            ; 100-199
                 / "2" %x30-34 DIGIT     ; 200-249
                 / "25" %x30-35          ; 250-255

  ]]></artwork></figure>

<t>Accordingly, following the SIP essential corrections process
<xref target="I-D.drage-sip-essential-correction"/>, this memo RECOMMENDS 
that the "IPv6address" and "IPv4address" production rules be deleted from 
RFC3261 and replaced with the production rules of the same name in RFC3986 
(and reproduced above.)  These changes, when made to RFC3261, will make 
"hexpart", "hexseq", and "hex4" production rules obsolete.  Thus this 
memo RECOMMENDS that the "hexpart", "hexseq", and "hex4" production rules 
be deleted from the ABNF of RFC3261.</t>

</section> <!-- resolution-1 -->

<section title="Clarification for comparison of URIs with textual
                representation of IP addresses"
         anchor="resolution-2">

<t>The resolution to this ambiguity is a simple clarification 
acknowledging that the textual representation of an IP addresses varies,
but it is the binary equivalence of the IP address that must be
taken into consideration when comparing two URIs that contain 
varying textual representation of an IP address.</t>

<t>Accordingly, following the SIP essential corrections process
<xref target="I-D.drage-sip-essential-correction"/>, this memo RECOMMENDS 
that the an existing rule from the bulleted list in Section 19.1.4 
of RFC3216 be modified as follows:
<vspace blankLines="60"/>
</t>

<t>OLD:

 <list style="symbols">
  <t>For two URIs to be equal, the user, password, host, and port
     components must match.</t>
 </list></t>

<t>NEW:

 <list style="symbols">
  <t>For two URIs to be equal, the user, password, host, and port
  components must match.  If the host component contains
  textual representation of IP addresses, then the representation of 
  those IP addresses may vary.  If so, the host components are considered 
  to match if the different textual representations yield the same
  binary IP address.</t>
 </list></t>

<t>In addition, this memo RECOMMENDS that the text in the following
paragraph  be added to the existing list of examples in Section 19.1.4 
of RFC3261 in order to demonstrate the intent of the modified rule:</t>

<t>The following URIs are equivalent because the underlying binary
representation of the IP addresses are the same although their
textual representations vary:

 <list style="empty">
  <t>sip:bob@[::ffff:192.0.2.128] <vspace blankLines="0"/>
  sip:bob@[::ffff:c000:280]</t>

  <t>sip:bob@[2001:db8::9:1] <vspace blankLines="0"/>
  sip:bob@[2001:db8::9:01]</t>

  <t>sip:bob@[0:0:0:0:0:FFFF:129.144.52.38] <vspace blankLines="0"/>
  sip:bob@[::FFFF:129.144.52.38]</t>
</list></t>

</section> <!-- resolution-2 -->

</section> <!-- Resolution -->

<section title="Security Considerations" anchor="sec-cons">

<t>This document does not introduce any new security considerations.</t>

</section> <!-- Security Considerations -->

<section title="IANA Considerations" anchor="iana-cons">

<t>This document does not include any IANA considerations.</t>

</section> <!-- iana-cons -->

<section title="Acknowledgments">

<t>The correct ABNF for IPv6 was developed by Andrew Main 
(draft-main-ipaddr-text-rep) in 2005 and published in RFC3986.</t>

<t>Jeroen van Bemmel, Peter Blatherwick, Gonzalo Camarillo, Paul Kyzivat, 
Jonathan Rosenberg, Michael Thomas, and Dale Worley provided invaluable 
discussion points on the SIP WG mailing list on the URI equivalency 
problem.</t>

</section>

</middle>  

<back>

<references title= "Normative References" >

   &rfc3261;
   &rfc2119;
   &rfc3986;
   &rfc5234;

</references>

<references title= "Informative References" >

   &rfc4291;
   &rfc2373;
   &I-D.drage-sip-essential-correction;

</references>

</back>
</rfc>