<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
    <!-- try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>    <!-- items used when reviewing the document -->
<?rfc comments="no" ?>  <!-- controls display of <cref> elements -->
<?rfc inline="no" ?>    <!-- when no, put comments at end in comments section,
                                otherwise, put inline -->
<?rfc editing="no" ?>   <!-- when yes, insert editing marks -->

    <!-- create table of contents (set it options).
           Note the table of contents may be omitted
         for very short documents -->

<?rfc toc="yes"?><?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>

    <!-- choose the options for the references. Some like
         symbolic tags in the references (and citations)
         and others prefer numbers. --> 
<?rfc symrefs="yes"?><?rfc sortrefs="yes" ?>
    <!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes" ?><?rfc subcompact="no" ?>
<!-- end of list of processing instructions -->
    <!-- Information about the document.
         categories values: std, bcp, info, exp, and historic
         For Internet-Drafts, specify attribute "ipr".
         (ipr values are: full3667, noModification3667, noDerivatives3667),
         Also for Internet-Drafts, can specify values for
         attributes "iprExtract", and "docName".  Note
         that the value for iprExtract is the anchor attribute
         value of a section that can be extracted, and is only
         useful when the value of "ipr" is not "full3667". -->
    <!-- TODO: verify which attributes are specified only
            by the RFC editor.  It appears that attributes
            "number", "obsoletes", "updates", and "seriesNo"
            are specified by the RFC editor (and not by
            the document author). -->

<rfc category="info" ipr="trust200902" docName="draft-klatsky-dispatch-ipv6-impact-ipv4-03">
<front>
    <title abbrev="IPv4/IPv6 Interoperability in SIP">Interoperability Impacts of IPv6 Interworking with&nbsp;Existing&nbsp;IPv4&nbsp;SIP&nbsp;Implementations</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->    

    <author fullname="Carl Klatsky" initials="C" surname="Klatsky" role="editor">
      <organization>Comcast</organization>

      <address>
        <postal>
          <street>1717 Arch St.</street>
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19103</code>
          <country>US</country>
        </postal>
        <email>carl_klatsky@cable.comcast.com</email>
      </address>
    </author>

    <author fullname="Olle E. Johansson" initials="O" surname="Johansson">
      <organization>Edvina</organization>

      <address>
        <postal>
          <street>Runbovägen 10</street>
          <city>Sollentuna</city>
          <code>SE-192 48</code>
          <country>SE</country>
        </postal>
        <email>oej@edvina.net</email>
      </address>
    </author>
   
    <author fullname="Rifaat Shekh-Yusef" initials="R" surname="Shekh-Yusef">
      <organization>Avaya</organization>

      <address>
        <postal>
          <street>250 Sidney Street</street>
          <city>Belleville</city>
          <region>Ontario</region>
          <country>Canada</country>
        </postal>
        <email>rifatyu@avaya.com</email>
      </address>
    </author>

    <author fullname="Andrew Hutton" initials="A" surname="Hutton">
      <organization>Siemens Enterprise Communications</organization>

      <address>
        <postal>
          <street>Technology Drive</street>
          <city>Nottingham</city>
          <code>NG9 1LA</code>
          <country>UK</country>
        </postal>
        <email>andrew.hutton@siemens-enterprise.com</email>
      </address>
    </author>

     <author fullname="Gonzalo Salgueiro" initials="G" surname="Salgueiro">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>US</country>
        </postal>
        <email>gsalguei@cisco.com</email>
      </address>
    </author>    
    
    <date year="2014" />
<!-- month="May" is no longer necessary note also, day="30" is optional -->
    
    <area>Real Time Applications and Infrastructure (RAI)</area>    
    
    <!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->
    
    <workgroup>DISPATCH</workgroup>
    
    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>
	
    <abstract>
      <t>This document captures potential impacts to IPv4 SIP implementations when interworking with IPv6 SIP implementations.  Although some amount of interworking translation will occur at the network and application layers, an IPv4 SIP application may still encounter a SIP message with some IPv6 values in it, resulting in unforeseen error conditions.  Such potential scenarios will be identified in this document so that SIP application developers can define solutions to handle these cases.  Note, this document is not intended to be an exhaustive list, rather to provide an overview of some of the more commonly encountered potential scenarios.</t>
    </abstract>

</front>

<middle>

    <section anchor="Introduction" title="Introduction">
		<t>The continued proliferation of IPv6 infrastructure deployments has resulted in more IPv6 Session Initiation Protocol (SIP) User Agents (UAs) being turned up on the network.  Considering the large deployed install base of IPv4 SIP UAs developed prior to the widespread deployment of IPv6, it is a well known fact that not all IPv4 SIP UAs have taken into account all possible IPv4 SIP-to-IPv6 SIP interoperability considerations at the time of their development.  The scenarios outlined in this document are intended as guidance for application developers to help identify solutions to resolve the identified interoperability challenges.</t>
    </section>

    <section anchor="Conventions" title="Terminology and Conventions Used in This Document">
		<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 RFC 2119 <xref target="RFC2119"/>.</t>
		
		<t>RFC 3261 <xref target="RFC3261"/> defines additional terms used in this document that are specific to the SIP domain such as "proxy"; "registrar"; "redirect server"; "user agent server" or "UAS"; "user agent client" or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; "transaction"; "server transaction".</t>

   		<t>This document uses the term "SIP Server" that is defined to include the following SIP entities: user agent server, registrar, redirect server, a SIP proxy in the role of user agent server, and a B2BUA in the role of a user agent server.</t>
   		
		<t>This document also uses the following terminology to make clear distinction between SIP entities supporting only IPv4, only IPv6 or supporting both IPv4 and IPv6.</t>

        <t>
        <list style="hanging">  		   
   		<t hangText="IPv4-only UA/UAC/UAS:">  An IPv4-only UA/UAC/UAS supports SIP signaling and media only on the IPv4 network.  It does not understand IPv6 addresses.</t>

		<t hangText="IPv6-only UA/UAC/UAS:">  An IPv6-only UA/UAC/UAS supports SIP signaling and media only on the IPv6 network.  It does not understand IPv4 addresses.</t>

		<t hangText="IPv4/IPv6 UA/UAC/UAS:">  A UA/UAC/UAS that supports SIP signaling and media on both IPv4 and IPv6 networks; such a UA/UAC/UAS is known (and will be referred to in this document) as a "dual-stack" <xref target="RFC4213"/> UA/UAC/UAS.</t>
		</list>
		</t>
		

	</section>
	
	<section anchor="Interop_scenarios" title="Potential IPv4/IPv6 Interoperability Failure Scenarios">
		
		<section anchor="via_headers" title="IPv6 Address Handling in Via Headers">
			<t>As an IPv6 SIP message makes its way through the network, the Via header is updated and includes specific IPv6 addresses of IPv6 nodes that it has traversed.  If the message arrives at an IPv4-only UAS it may still contain those IPv6 addresses in the Via header.  Presumably the topmost Via header references an IPv4 address or a Fully Qualified Domain Name (FQDN) resolvable to any IPv4 address. In this case the IPv4-only UAS is able to send its response on to its next hop, otherwise the message would not have made it to the IPv4-only UA at all.  The challenge for the IPv4-only UA then becomes to not generate an error even if the other Via headers that it does not need to act upon contain IPv6 addresses.</t>
		</section>
		
		<section anchor="route_headers" title="IPv6 Address Handling in Record-Route and Route Headers">
			<t>Similar to the concerns of having IPv6 addresses in the Via headers, IPv4 SIP UAS may also encounter Record-Route headers that contain IPv6 addresses of IPv6 nodes the SIP message has traversed.  It is again assumed that if the SIP message arrives at an IPv4-only UA that the topmost Record-Route header references an IPv4 address or a FQDN resolvable to any IPv4 address, such that the response may be routed back to a node reachable by the IPv4-only UAS.  In this instance the IPv4-only UA should not generate an error when parsing the IPv6 addresses.  Additionally, the IPv4-only UA may also need to populate the Route header in the response that includes the IPv6 addresses learned from previously received Record-Route header, and again do so without generating an error.</t>
		</section>

		<section anchor="contact" title="IPv6 Address Handling in From / To / Contact Headers">
			<t>Another scenario with possible IPv6-to-IPv4 interoperability implications is the case where the IPv4-only UAS receives an IPv6 address in the Contact header and no Record-Route header.  Since this represents the peer's reachable contact IP, it may not have been modified by any interworking element in the communications path.  The IPv4-only UAS will have to send its requests through its outbound SIP server, and not generate an error upon receipt of a message with this IPv6 information.</t>
      <t>In addition, using an IP address instead of domain in To and/or From headers may impact communication, as the From header is used for other communication sessions or added to a phone book.</t>
    </section>

		<section anchor="sdp" title="IPv6 Address Handling in SDP Body">
			<t>IPv4-only UASs may also receive SDP offers with IPv6 addresses in the Session Description Protocol (SDP) <xref target="RFC4566"/> portion of the message.  An IPv6 address can appear in multiple places in the SDP, such as the o= line, c= line or a= lines (for Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/> attributes).  A working assumption is that minimally the c= line will reference an IPv4 address of a media interworking element to allow the media communications being established by this session to work.  Nonetheless the IPv4-only UAS needs be aware and properly handle any IPv6 addresses that may be within the received SDP.</t>
		</section>

		<section anchor="reginfo" title="IPv6 Address Handling in 'reginfo' XML Registration Information Document">
			<t>There may be instances where an IPv4-only UAC subscribes to the registration event package <xref target="RFC3680"/> as a "watcher" for a specific entity, to be informed of registration state changes for that entity.  The "watcher" may have no knowledge of the IP address family in use on the "watched" entity, and it is possible that a NOTIFY indicating an IPv6 address in the Extensible Markup Language (XML) <xref target="XML"/> body is received.  The "watcher" needs to properly parse such a NOTIFY and provide the status update of the "watched" entity to the user or system that requested the information.  This would be the case when an IPv6 SIP client registration is being "watched".</t>
		</section>

		<section anchor="redirect" title="IPv6 Address Handling in 30x Redirect">
			<t>There may be scenarios where an IPv4-only UAC receives a 30x redirect message in response to a request it has sent.  This 30x message may contain a Contact header with an IPv6 address.  This is the case where the call is being redirected to an IPv6-only UAS.  Since this represents the peer's reachable contact IP, it may not have been modified by any interworking element in the communications path.</t>
      <t>If the UAC has a configured outbound proxy the new call will be setup to that proxy. If that proxy is not dual stack, the call will fail. If there's no outbound proxy configured, the call will fail. If the UAC is a soft phone or hard phone, an error message should be displayed.</t>
		</section>

		<section anchor="refer" title="IPv6 Address Handling in REFER-based Transfer">
			<t>After establishing a call between two IPv4-only UAs, one of the parties in the call may attempt to transfer the other party to a 3rd party using the REFER method <xref target="RFC5589"/>.  This transfer may be to an IPv6-only UAS.  The implication is that both IPv4-only UASs involved in the call transfer need to be able to handle a REFER with an IPv6 address in the Refer-To header.  The transferor needs to be able to form the proper REFER message with the IPv6 Contact and the transferee needs to be able to process the REFER message and attempt to establish a call with the transfer target.</t>
		</section>

		<section anchor="dns" title="DNS Resolution of IPv4/IPv6 in SRV Records">
			<t>A dual-stack UA may use the Domain Name System (DNS) SRV mechanism to resolve addresses of proxies that it needs to communicate with.  In such a case it needs to be able to locate both IPv4 proxies and IPv6 proxies.  This implies that the DNS server has been updated with both A and AAAA records for the SIP server, and that the dual-stack UA requests for both IPv4 and IPv6 SIP server addresses.</t>
		</section>

		<section anchor="reg_req" title="IPv6 Address Handling in Multiple Contact Registrations">
			<t>A 200 OK to a REGISTER request might include multiple Contact headers because the user has registered his or her Address of Record (AOR) on multiple clients.  Some of these Contact headers might have IPv6 addresses. An IPv4-only UAC must be able to handle the IPv6 information properly.</t>
		</section>

		<section anchor="unsuported_add" title="Unsupported Address">
			<t>If the endpoint is an IPv4-only client and it receives a request with an SDP offer that has IPv6 address(es) only, the IPv4-only client should decline the request by returning 488 “Not Acceptable Here” (as defined in section 13.3.1.2 of RFC3261) with Warning header that has warning code of 301 “Incompatible Network Address Formats” (as defined in section 20.43 of RFC3261).
         If the ipv4-only client receives a request with an SDP offer that has a mixed set of IPv4 and IPv6 addresses, then the IPv4-only client should accept the IPv4 address(es) and decline the IPv6 address(es) by setting the port number in the m-line to zero.
      </t>
		</section>
	
	</section>
	
	<section anchor="Security" title="Security Considerations"> 
		<t>This document merely describes the potential impacts of IPv6 on IPv4 SIP implementations.  The scenarios discussed in this informational document do not introduce any new security threats.  The specific security vulnerabilities, attacks, threat models of the various protocols discussed in this document (SIP, SDP, ICE, etc.) are well documented in their respective documents.</t>
	</section>
	
	<section anchor="IANA" title="IANA Considerations"> 
  		<t>This document does not require actions by IANA.</t>
	</section>

	<section anchor="Acknowledgements" title="Acknowledgements">
    	<t>The authors would like to acknowledge the support and contribution of the SIP Forum IPv6 Working Group.  Mohamed Boucadair has contributed significant ideas and text.  Dan Wing, Hadriel Kaplan, Paul Kyzivat, Dale Worley, and Neel Neelakantan have all provided a detailed review of the document and thoughtful comments.</t>
	</section>
    
</middle>

<back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
	 	 
    </references>
    
    <references title="Informative References">
      <?rfc include="reference.RFC.3261" ?>
      <?rfc include="reference.RFC.3680" ?>
      <?rfc include="reference.RFC.4213" ?>
      <?rfc include="reference.RFC.4566" ?>
      <?rfc include="reference.RFC.5118" ?>
      <?rfc include="reference.RFC.5245" ?>
      <?rfc include="reference.RFC.5589" ?>
      <reference anchor="XML" target="http://www.w3.org/TR/2008/REC-xml-20081126">
         <front>
            <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
            <author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
            <organization/></author><author initials="F." surname="Yergeau" fullname="François Yergeau">
            <organization/></author><author initials="T." surname="Bray" fullname="Tim Bray">
            <organization/></author><author initials="E." surname="Maler" fullname="Eve Maler">
            <organization/></author><author initials="J." surname="Paoli" fullname="Jean Paoli">
            <organization/></author><date month="November" day="26" year="2008"/>
         </front>
         <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
         <format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-20081126"/>
    </reference>


	</references>
      
  <section anchor="Appendix_A" title="Additional Guidelines">
      <t>Some additional interoperability guidelines are presented in this section.</t>
      	<section anchor="A.1" title="IPv6 Implementation Guidelines"> 
  		    <t>This section lists basic IPv6 recommendations for SIP implementations:</t>
            
            <t>To avoid parsing errors, IPv6 address MUST be delimited by “[” and “
            ]” in the following cases:</t>
            <t>*	If an IPv6 address is included in a SIP Request URI
            <vspace blankLines='0' />
            *	If an IPv6 address is included in a SIP “Via” header
            <vspace blankLines='0' />            
            *	If an IPv6 address is included in a SIP “Contact” header</t>

            <t>No delimiters are needed for other SIP tags such as “received” or even at the 
            SDP level.
            <vspace blankLines='1' />
            The SIP ABNF for IPv6 reference defined in [RFC3261] MUST NOT be used. 
            Instead, rules defined in [RFC3986] MUST be supported.
            <vspace blankLines='1' />
            To compare SIP URIs, [RFC5954] MUST be used instead of [RFC3261].
            <vspace blankLines='1' />
            [RFC5952] MUST be supported for IPv6 textual representation purposes.
            <vspace blankLines='1' />
            An IPv6-enabled SIP MUST NOT include any loopback address (::1) or link local 
            address (fe80) in SIP headers and SDP body.
            <vspace blankLines='1' />
            The offer/answer does not include IP Address in negotiation aspects and doesn't distinguish IPv4/IPv6.
            If the dual stack IPv4/IPv6 UAS receives an INVITE from IPv4 endpoint, based on Contact information, 
            it should respond using the offer (IPv4/IPv6) in media/c= for better interoperability.
            <vspace blankLines='1' />
            A IPv6 implementation parsers can be checked by running the test cases defined in [RFC5118]</t>
	      </section>
        <section anchor="A.2" title="IPv6/IPv4 Interworking Function: Avoid IPv6 address Leakage?"> 
  		    <t>The introduction of IPv6-enabled SIP UAs may lead to some failure issues of 
             the legacy (IPv4-only) UA are unable to parse IPv6 addresses. To prevent 
             those failure cases, an IPv6/IPv4 Interworking Function may be deployed in 
             the SIP infrastructure to adapt SIP messages. In particular, this 
             interworking function may be configured to avoid leaking any IPv6 address to 
             a legacy IPv4-only SIP UA (and vice versa). An IPv6-only SIP UA will be seen 
             by a remote IPv4-only SIP UA as any legacy IPv4-only SIP UA. Leaking IPv6 
             addresses in headers is a concern only for headers used for session routing 
             purposes (e.g., topmost via, contact, etc.). </t>

          <t>Within managed SIP networks, the impact of leaking addresses of distinct 
             address family should be assessed through testing campaigns. If no failures 
             are experienced, enabling the function which prevents leaking addresses of 
             distinct address family may be avoided.</t>
          
          <t>In order to promote the use of IPv6 transfer capabilities and avoid extensive 
             usage of IPv4/IPv6 interworking resources, leaking IPv6 addresses in a 
             backward compatible manner should be encouraged. For instance, the SDP offer 
             can include both IPv4 and IPv6 addresses (e.g., [RFC6947]). The address 
             family to be used to place the session will be decided by the remote peer.</t>
             
          <t>When both IPv4 and IPv6 SIP UA are deployed in a network, the SIP Proxy 
             Server will need a trigger to decide whether invoking IPv4/IPv6 Interworking 
             function is required; otherwise IPv4/IPv6 IWF resources won’t be optimized. A 
             potential solution for this problem is discussed in [I-D.boucadair-dispatch-
             ipv6-atypes]. Relying on the address of contact is not deterministic since a 
             dual-stack SIP UA may be registered with its IPv4 address while it supports 
             also IPv6.</t>   
	      </section>
  </section>
  
  </back>
</rfc>