v6ops Working Group                                      G. Van de Velde
Internet-Draft                                              C. Popoviciu
Intended status: Informational                                   T. Hain
Expires: February 17, 2011                                     S. Venaas
                                                           Cisco Systems
                                                         k. Chittimaneni
                                                              Google Inc
                                                         August 16, 2010


   Network signaling for IPv4/IPv6 protocol selection for end-systems
                <draft-vandevelde-v6ops-pref-ps-00.txt>

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 17, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Van de Velde, et al.    Expires February 17, 2011               [Page 1]


Internet-Draft  Network signaling for protocol selection     August 2010


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

































Van de Velde, et al.    Expires February 17, 2011               [Page 2]


Internet-Draft  Network signaling for protocol selection     August 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Components  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  IPv6 deployment model . . . . . . . . . . . . . . . . . . . 4
     2.2.  Policy table  . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Considerations for IPv4 and IPv6 selection on end-systems . . . 5
     3.1.  Dynamics of end-system configuration  . . . . . . . . . . . 5
     3.2.  Hosts with multiple interfaces  . . . . . . . . . . . . . . 5
     3.3.  Backward compatibility  . . . . . . . . . . . . . . . . . . 5
     3.4.  Network based learning  . . . . . . . . . . . . . . . . . . 5
     3.5.  Impact on RFC3484 . . . . . . . . . . . . . . . . . . . . . 6
     3.6.  Influence of IPv4/IPv6 protocol preference on
           applications  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.7.  Dynamic tunneling . . . . . . . . . . . . . . . . . . . . . 6
   4.  Considerations for IPv4 and IPv6 selection on network
       infrastructure elements . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Signaling IPv4/IPv6 preference  . . . . . . . . . . . . . . 6
     4.2.  Influence of IPv4/IPv6 preference on network
           infrastructure elements . . . . . . . . . . . . . . . . . . 7
     4.3.  IPv4/IPv6 policy table location . . . . . . . . . . . . . . 7
     4.4.  Backward compatibility  . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7






















Van de Velde, et al.    Expires February 17, 2011               [Page 3]


Internet-Draft  Network signaling for protocol selection     August 2010


1.  Introduction

   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.

   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.

   Note that this procedure is applicable to end-systems and their
   applications only; the forwarding algorithm used by routers is not
   affected.


2.  Components

2.1.  IPv6 deployment model

   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.

   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.




Van de Velde, et al.    Expires February 17, 2011               [Page 4]


Internet-Draft  Network signaling for protocol selection     August 2010


2.2.  Policy table

   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.


3.  Considerations for IPv4 and IPv6 selection on end-systems

   This section will detail considerations for an end-system with
   respect to IPv4/IPv6 protocol preference.

3.1.  Dynamics of end-system configuration

   An end-system is usually configured in three possible ways:

   (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

3.2.  Hosts with multiple interfaces

   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.

3.3.  Backward compatibility

   A solution for the IPv4/IPv6 preference shouldn't have an impact on
   end-systems not capable to understand this functionality.

3.4.  Network based learning

   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.



Van de Velde, et al.    Expires February 17, 2011               [Page 5]


Internet-Draft  Network signaling for protocol selection     August 2010


3.5.  Impact on RFC3484

   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.

3.6.  Influence of IPv4/IPv6 protocol preference on applications

   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.

3.7.  Dynamic tunneling

   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.


4.  Considerations for IPv4 and IPv6 selection on network infrastructure
    elements

   This section will detail considerations for network infrastructure
   devices with respect to IPv4/IPv6 protocol preference.

4.1.  Signaling IPv4/IPv6 preference

   The IPv4/IPv6 preference signal can be sent by four methods.

   (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.







Van de Velde, et al.    Expires February 17, 2011               [Page 6]


Internet-Draft  Network signaling for protocol selection     August 2010


4.2.  Influence of IPv4/IPv6 preference on network infrastructure
      elements

   The IPv4/IPv6 preference selection should only have impact on the
   end-systems and the network infrastructure devices should be ignoring
   the preference signal.

4.3.  IPv4/IPv6 policy table location

   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.

4.4.  Backward compatibility

   There should be no impact on either the network infrastructure when
   end-systems do not understand the IPv4/IPv6 protocol preference
   solution.


5.  IANA Considerations

   There are no extra IANA consideration for this document.


6.  Security Considerations


7.  Acknowledgements


8.  References

8.1.  Normative References

8.2.  Informative References










Van de Velde, et al.    Expires February 17, 2011               [Page 7]


Internet-Draft  Network signaling for protocol selection     August 2010


Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: +32 476 476 022
   Email: gvandeve@cisco.com


   Ciprian Popoviciu
   Cisco Systems
   7025-6 Kit Creek Road
   Research Triangle Park,   North Carolina  NC 27709-4987
   United States

   Phone: +1 919 392-3723
   Email: cpopovic@cisco.com


   Tony Hain
   Cisco Systems
   500 108th Ave. NE
   Bellevue, Wa.
   USA

   Email: alh-ietf@tndh.net


   Stig Venaas
   Cisco Systems
   Tasman Drive
   San Jose,   CA 95134
   USA

   Phone:
   Email: stig@cisco.com












Van de Velde, et al.    Expires February 17, 2011               [Page 8]


Internet-Draft  Network signaling for protocol selection     August 2010


   Kiran Kumar Chittimaneni
   Google Inc
   1600 Amphitheatre Parkway
   Mountain View,   CA 94043
   USA

   Phone: +1 650 253 6185
   Email: kk@google.com











































Van de Velde, et al.    Expires February 17, 2011               [Page 9]