<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes" ?>
<?rfc toc="yes" ?>

 <!ENTITY rfc3484  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>

 
<rfc category="info" ipr="pre5378Trust200902" docName="<draft-vandevelde-v6ops-pref-ps-00.txt>">

<front>

<title abbrev="Network signaling for protocol selection">
Network signaling for IPv4/IPv6 protocol selection for end-systems 
</title>


     <author initials="G." surname="Van de Velde" fullname="Gunter Van de Velde">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <country>Belgium</country>
          <code>1831</code>
        </postal>
        <phone>+32 476 476 022</phone>
        <email>gvandeve@cisco.com</email>
      </address>
    </author>

     <author initials="C" surname="Popoviciu" fullname="Ciprian Popoviciu">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>7025-6 Kit Creek Road</street>
          <city>Research Triangle Park</city>
          <region></region>
          <country>United States</country>
          <code>North Carolina  NC 27709-4987</code>
        </postal>
        <phone>+1 919 392-3723</phone>
        <email>cpopovic@cisco.com</email>
      </address>
    </author>

<author fullname="Tony Hain" initials="T" surname="Hain">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>500 108th Ave. NE</street>
          <city>Bellevue</city>
          <region>Wa.</region>
          <country>USA</country>
          <code></code>
        </postal>
        <email>alh-ietf@tndh.net</email>
      </address>
    </author>


     <author initials="S" surname="Venaas" fullname="Stig Venaas">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Tasman Drive</street>
          <city>San Jose</city>
          <region></region>
          <country>USA</country>
          <code>CA 95134</code>
        </postal>
        <phone></phone>
        <email>stig@cisco.com</email>
      </address>
    </author>

    <author initials="k" surname="Chittimaneni" fullname="Kiran Kumar Chittimaneni">
     <organization>Google Inc</organization>
     <address>
       <postal>
         <street>1600 Amphitheatre Parkway</street>
         <city>Mountain View</city>
         <region></region>
         <country>USA</country>
         <code>CA 94043</code>
       </postal>
       <phone> +1 650 253 6185</phone>
       <email>kk@google.com</email>
     </address>
   </author>

<date day="16" month="August" year="2010"></date>
<workgroup>v6ops Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IPv6</keyword>
<keyword>protocol signaling</keyword>

<abstract>

   <t>Within an administrative realm, especially during an IPv6 
   implementation period, the network operator has interest to have 
   control on the IP protocol version (IPv4 or IPv6) used by the end systems and 
   network devices. This document provides a problem statement about 
   both protocol preference and protocol selection many network operators 
   face when implementing IPv6 in a controlled process.</t> 


</abstract>

</front>

<middle>

<section title="Introduction">

   <t>With IPv6 TCP/IP stacks preferring IPv6 over IPv4 for forwarding, network   
         administrators don't have control over which protocol end hosts use. Such lack of control 
         has the potential to negatively impact the end host, especially in cases where the network 
         is dual stacked well before the backend systems and/or applications are. It is thus 
         preferable to have control over the device preference or selection of IP4 or IPv6. This 
         control will allow network administrators to seamlessly implement IPv6 on the network 
         with the ability to carefully integrate IPv6 into production as and when all other critical 
         non-network components are found to be working as expected.
   </t>

   <t>This document describes a problem statement to control and potentially communicate the IPv4/IPv6
   protocol preference for devices. The document outlays the various considerations for protocol preference selection. This capability improves the ability of hosts to pick an appropriate protocol (IPv4 or IPv6) for 
   off-link and on-link destinations.
   </t>

   <t>Note that this procedure is applicable to end-systems and their applications only; the forwarding
   algorithm used by routers is not affected.  
   </t>

</section>

<section title="Components">

<section title="IPv6 deployment model">

   <t>When a network operator is in process of deploying a new technology on the network, the network operator will likely include a set of fallback mechanisms and will try to 
   place as much control as possible in each of the deployment steps. An element of control during the 
   integration of IPv6 is the management of IPv6 use by the 
   end-systems and the applications running on those systems. The protocol preference management is done thorough a signaling mechanism. This signaling allows the network operator to introduce IPv6 on the routers and other 
   network infrastructure elements without impacting existing IPv4 behavior of the end-systems. Once the network operator decides to activate IPv6 for end-systems, in order to allow each end-system 
   to include IPv6 as valid communication protocol following RFC3484 address selection.</t> 

   <t>This operational sequence will help the enablement of IPv6  
   in a controlled manner once the network infrastructure is found correctly working according 
   the expectations of the network operator. 
   </t>

</section>

<section title="Policy table">

   <t>The policy table references to an information database defining the expected behavior regarding 
   IPv4/IPv6 protocol preference and selection behavior for various parts of the administrative domain. 
   </t>

</section>

</section>


<section title="Considerations for IPv4 and IPv6 selection on end-systems">

   <t>This section will detail considerations for an end-system with respect to IPv4/IPv6 protocol 
   preference.
   </t>

<section title="Dynamics of end-system configuration">

   <t>An end-system is usually configured in three possible ways: 
   </t>

   <t>(a) Preset configuration: these end-systems have a configuration which has been defined during the 
        manufacturing of the device; (b) Manual configuration: In this case the end-systems are configured by a set of parameters and settings which are individually configured on the device through human interaction; 
     (c) Dynamic configuration: Some end-systems download through the network infrastructure a set of parameters 
        i.e. IP and DNS addresses through DHCP
   </t>
</section>  

<section title="Hosts with multiple interfaces">

   <t>Lots of end-systems are connected to the network infrastructure with only a single interface. 
   For these systems, the IPv4 and IPv6 preference can be quite simply defined, either 
   using or not-using IPv6. However, there are many end-systems connected through two or 
   more interfaces to the network infrastructure. These systems require a protocol preference to be defined for each interface independently. 
   These additional considerations also include aspects of conflicting information received through the 
   different interfaces regarding the IPv6 protocol preference.  
   </t>

</section>

<section title="Backward compatibility">

   <t>A solution for the IPv4/IPv6 preference shouldn't have an impact on end-systems not capable to 
   understand this functionality.
   </t>

</section>

<section title="Network based learning">

   <t>The IPv4/IPv6 protocol preference on an end-system should be signaled by the 'network' (network devices or other infrastructure components such as DHCP) to automate 
   the end-systems behavior, however the IP4/IPv6 protocol preference solution should not exclude 
   manual configuration on end-systems.
   </t>

</section>

<section title="Impact on RFC3484"> 

   <t>A solution for IPv4/IPv6 protocol preference may influence the availability or better the non-availability 
   of IPv6 parameters within the RFC3484 end-system address selection algorithm. This influence must be 
   understood very clearly for end-systems with single and with multiple interfaces attached to the network 
   infrastructure. 
   </t>

</section>

<section title="Influence of IPv4/IPv6 protocol preference on applications">

   <t>The IPv4/IPv6 protocol preference should be propagated by the end-system towards the applications 
   running on the end-system. It should not be excluded that a protocol preference solution may have 
   more specific information per application of importance to the end-systems. As consequence the 
   end system could use this information for IPv4/IPv6 protocol preference per application or session for example.
   </t>

</section>

<section title="Dynamic tunneling">

   <t>Some end systems make usage of dynamic tunnels for IPv6 even when the network infrastructure 
   does not support IPv6 as a native protocol. The IPv4/IPv6 preference signal could influence 
   the creation of these tunnels based upon the signaled IPv4/IPv6 protocol preference.
   </t>

</section>
</section>

<section title="Considerations for IPv4 and IPv6 selection on network infrastructure elements">

   <t>This section will detail considerations for network infrastructure devices with respect 
   to IPv4/IPv6 protocol preference.
   </t>

<section title="Signaling IPv4/IPv6 preference">

   <t>The IPv4/IPv6 preference signal can be sent by four methods.
   </t>

   <t>(a) The end-system is configured during manufacturing of the system; 
     (b) A network operator configures the end-system by the console of the end-system;
     (c) The network infrastructure could signal the end-systems the IPv4/IPv6 preference through 
        existing or new link-local packets;
     (d) The network infrastructure signals the end-system that there are elements that influence 
        protocol selection, and that the end-system may want to request the network infrastructure 
        what these elements exactly are.
   </t>
</section>

<section title="Influence of IPv4/IPv6 preference on network infrastructure elements">

   <t>The IPv4/IPv6 preference selection should only have impact on the end-systems and the network 
   infrastructure devices should be ignoring the preference signal. 
   </t>

</section>

<section title="IPv4/IPv6 policy table location">

   <t>The IPv4/IPv6 protocol preference needs to be stored somewhere within the network. 
   This could be done either centrally or distributed. Crucial is that the network infrastructure 
   device is directly connected to the end-system it wants to signal IPv4/IPv6 preference, so that 
   link-local communication between the end-system and the network infrastructure device can be used.
   Between the network infrastructure device and the policy table location non-link local addresses 
   may be utilized. </t>

</section>

<section title="Backward compatibility">

   <t>There should be no impact on either the network infrastructure when end-systems do not understand 
   the IPv4/IPv6 protocol preference solution.
   </t>

</section>
</section>


<section title="IANA Considerations">


   <t>There are no extra IANA consideration for this document.
   </t>

</section>

<section title="Security Considerations">

   
   <t>
   </t> 

</section>

<section title="Acknowledgements">

  <t>
  </t>

</section>


</middle>

<!-- =============================================================== -->

<back>

<references title='Normative References'>

</references>

<references title='Informative References'>


</references>

</back>

</rfc>


