[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04                                                
Network Working Group                                      Dayong Guo
Internet Draft                                            Sheng Jiang
Intended status: Standards Track          Huawei Technologies Co., Ltd
Expires: January 14, 2011                              Brian Carpenter
                                                University of Auckland
                                                         July 12, 2010



               Softwire Concentrator Discovery Using DHCP

                 draft-guo-softwire-sc-discovery-04.txt


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 January 14, 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
   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.








Guo, et al.           Expires January 14, 2011                [Page 1]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010




Abstract

   Several types of Carrier Grade NATs have been proposed to simplify
   IPv4/IPv6 transition of the edge network by integrating tunnels and
   NAT. A very common scenario is that many users set up softwires to a
   softwire concentrator for public or private access services. In order
   to establish softwires successfully, a new mechanism is required to
   enable users in the edge network to discover the information of the
   concentrator. This document describes how a host or Customer Premises
   Equipment discovers the remote softwire concentrator or CGN in a hub
   and spoke network using DHCP. Based on two new Softwire Concentrator
   Discovery DHCP Options, proposed in the document, a user can obtain
   the information of the softwire concentrator or CGN and then set up a
   tunnel to it.



Table of Contents

   1. Introduction................................................3
   2. Terminology.................................................4
   3. DHCP Solution Overview for Softwire Concentrator Discovery....4
   4. DHCPv4 Softwire Concentrator Discovery (SCD) Option...........5
      4.1. Suboptions in DHCPv4 SCD Option.........................6
         4.1.1. Protocol Type Suboption............................7
         4.1.2. GRE Key Suboption..................................7
   5. DHCPv6 Softwire Concentrator Discovery (SCD) Option...........7
      5.1. Suboptions in DHCPv6 SCD Option.........................8
         5.1.1. Protocol Type Suboption............................9
         5.1.2. Prefix Suboption..................................10
         5.1.3. GRE Key Suboption.................................10
   6. Illustration Examples.......................................11
      6.1. Example 1: Incremental CGN scenario....................11
      6.2. Example 2: two CGN in DS lite scenario.................11
   7. Security Considerations.....................................11
   8. IANA Considerations........................................12
      8.1. Tunnel Types..........................................12
      8.2. DHCPv4 SCD Suboption Types.............................12
      8.3. DHCPv6 SCD Suboption Types.............................13
   9. Acknowledgments............................................13
   10. Change Log [RFC Editor please remove]......................13
   11. References................................................13
      11.1. Normative References..................................13
      11.2. Informative References................................14



Guo, et al.           Expires January 14, 2011                [Page 2]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010



1. Introduction

   Transition is an important factor for user experience in IPv4 and
   IPv6 coexistence phase. The transition of the edge network is the
   most complicated because it is near lots of users and uses multiple
   network technologies. Recently, several types of Carrier-Grade-NATs
   (CGNs) have been proposed to simplify IPv4/IPv6 transition of the
   edge network by integrating tunnels and NAT. Incremental CGN
   [I-D.ietf-v6ops-incremental-cgn] and 6rd [I-D.ietf-softwire-ipv6-6rd]
   and describes how dispersed IPv6 users bridge with the IPv6 Internet
   by tunnel spanning ipv4 infrastructure. The dual-stack lite
   technology [I-D.ietf-softwire-dual-stack-lite] is intended for
   maintaining connectivity to legacy IPv4 devices and networks using
   IPv4-over-IPv6 softwires while a service provider deploys an IPv6-
   only network. A very common scenario is that many users set up
   softwires or tunnels to a softwire concentrator for public or private
   access services.

   The aforementioned scenarios have been abstracted as hub and spoke
   networks in the IETF Softwire working group, and several
   encapsulation techniques have been defined [RFC4925] [RFC5512].
   [RFC5571] discloses a mechanism in mesh network by BGP extension for
   users to discover the information of a tunnel end point. However, the
   nodes in an edge network do not have BGP capability generally. Manual
   configuration is not suitable because the address and other attribute
   of the concentrator may change. A new mechanism is required to enable
   users in edge network to discover the information of the concentrator
   automatically.

   In order to establish a softwire successfully, users must know the
   information of a softwire concentrator or CGN, such as address,
   tunnel type. Additionally, the discovery process may also support
   multiple protocol type in tunnel, load-sharing and recovery from a
   single point of failure.

   Since ISPs may use different softwire technologies, an ISP-
   independent CPE should support as many as possible potential softwire
   technologies and be able to auto discovery which softwire
   technologies is in use. Even within a single ISP, different softwire
   technologies may also use to differentiate customers, e.g., support
   of secured encapsulation for some customers and plain IP-in-IP
   encapsulation for others.

   For scalability and stability purposes, customers may be assigned
   different/multiple softwire concentrators through the discovery
   mechanism.


Guo, et al.           Expires January 14, 2011                [Page 3]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   The Dynamic Host Configuration Protocol (DHCP [RFC2131], [RFC3315])
   is widely used in edge networks to enable auto-configuration. This
   document extends DHCP to support discovery of a softwire concentrator
   or CGN. This mechanism is general for 6rd, incremental CGN, DS-Lite
   and Port-range Router [I-D.boucadair-port-rang]. It can also be
   extended to support the discovery of other concentrators with
   tunnels.

   In the absence of DHCP, PPP or Router Advertisements could be used to
   find a softwire concentrator or CGN automatically, but this document
   does not discuss these methods in detail.

2. Terminology

   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 RFC2119 [RFC2119].

3. DHCP Solution Overview for Softwire Concentrator Discovery

   In order to support softwire concentrator or CGN discovery, two new
   DHCP options are defined respectively for DHCPv4 and DHCPv6. They
   have the identical structure apart from address length.

   When a DHCP server answers a client request message, softwire
   concentrator information can be carried in a DHCP reply message. Thus
   a client is configured the address and other attributes of a softwire
   concentrator or CGN and can automatically set up a tunnel.

   DHCP server decides to attach SCD option based on policy. One choice
   is to respond only if the client requests the SCD option; another is
   to append it to every reply no matter the client requests the SCD
   option or not.

   For load sharing or single-point failure recovery purposes, a DHCPv4
   reply message may carry multiple instances in a single DHCPv4 SCD
   option; a DHCPv6 reply message may carry more than one DHCPv6 SCP
   options.

   Section 4 defines a new DHCPv4 Softwire Concentrator Discovery (SCD)
   option while Section 5 defines DHCPv6 SCD option. Section 4.1 defines
   sub-options that apply to DHCPv4 SCD option while Section 5.1 defines
   sub-options that apply to DHCPv6 SCD option.






Guo, et al.           Expires January 14, 2011                [Page 4]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


4. DHCPv4 Softwire Concentrator Discovery (SCD) Option

   The DHCPv4 Softwire Concentrator Discovery (SCD) Option is mainly
   used when an IPv6 host or CPE in an IPv4 ISP network wants to obtain
   an IPv4 address of an IPv6 access point or an incremental CGN. The
   Option is carried in DHCPv4.

   A DHCPv4 message can carry only one DHCPv4 SCD Option. Multiple
   instances can be concatenated in the DHCPv4 SCD Option, as follow:

                    |<----Instance1---->|<----Instance2---->|
       Code    Len     Len        Data    Len       Data
      +------+------+------+------------+------+------------+--
      | TBD1 |   n  |  n1  |  data1...  |  n2  |  data2...  | ...
      +------+------+------+------------+------+------------+--

   The DHCPv4 SCD Option is structured as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Code     |      Len      | Instance1-Len |  Tunnel Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Preference   | Softwire Concentrator or CGN Address          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    cont.      |                                               |
      +-+-+-+-+-+-+-+-+      Instance1's Suboptions                   |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Instance2-Len |                                               |
      +-+-+-+-+-+-+-+-+      Instance2-Data                           |
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                        Instance n                             .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Code          TBD1.

      Len           n + Len1 + Len2 + ... + Len n.

      Instance-Len  6 + length of Instance's sub options in octets.

      Tunnel Type   Tunnel type which users connect to softwire
                    concentrators or CGN. A few initial value
                    assignments, like L2TPv2, GRE, ISATAP, 6to4, 6rd,
                    IPSec and other IP in IP, is listed in Section 8
                    IANA consideration.


Guo, et al.           Expires January 14, 2011                [Page 5]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


      Preference    This indicates the preference level for a softwire
                    concentrator or CGN. 0 is the highest. When
                    receiving multiple instances, the user chooses a
                    primary softwire concentrator among them based on
                    the preference. The others are backup softwire
                    concentrators. The service provider assigns
                    different preference for each softwire concentrator
                    to support traffic engineering.

      Softwire Concentrator or CGN Address   The outer layer IPv4
                    address of softwire concentrator, which is used to
                    establish tunnel.

      Sub Options   An optional, variable length field which is defined
                    in Section 4.1.

4.1. Suboptions in DHCPv4 SCD Option

   The suboptions defined in this section can be applied to DHCPv4 SCD
   option, defined above. They are used to configure the complementary
   tunnel information.

   The DHCPv4 SCD suboption is structured in TLV style as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Suboption Type| Suboption Len |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      .               Suboption Value (Variable)                      .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       * DHCPv4 SCD Suboption Type (1 octet): each suboption type
         defines a certain property about the tunnel. The following are
         the types defined in this document:

          - Protocol Type: suboption type = 0

          - GRE Key: suboption type = 1

         New suboptions may be defined in the future. Any unknown
         suboptions MUST be ignored and skipped.

       * Suboption Length (1 octet): the total number of octets of the
         suboption value field.




Guo, et al.           Expires January 14, 2011                [Page 6]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


       * Suboption Value (variable): encodings of the value field depend
         on the suboption type as enumerated above.

   The following sub-sections define the encoding in detail.

4.1.1. Protocol Type Suboption

   This suboption designates which protocol is encapsulated in tunnel.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0    |    Len = 2    |        Protocol Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   The Protocol Type field is defined in [IANA-ET] as ETHER TYPEs. The
   most used protocols are IPv4 (0x0800) and IPv6 (0x86dd).

4.1.2. GRE Key Suboption

   When the tunnel type is GRE, this suboption may be contained.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 1    |   Len = 4     |           GRE Key             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         GRE Key (cont.)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        GRE Key: 4-octet field [RFC2890] that is generated by the
        Softwire Concentrator or CGN. If the client receives the GRE Key
        suboption, the key MUST be inserted into the GRE encapsulation
        header of the payload packets sent by the client to the Softwire
        Concentrator or CGN. It is used for identifying extra context
        information about the received payload. The payload packets
        without the correspondent GRE key or with an unmatched GRE Key
        will be silently dropped.

5. DHCPv6 Softwire Concentrator Discovery (SCD) Option

   The DHCPv6 Softwire Concentrator Discovery (SCD) Option is mainly
   used when an IPv4 host or CPE in an IPv6 ISP network wants to learn
   an IPv6 address of an IPv4 access point or a DS-lite CGN. The Option
   is carried in DHCPv6.

   A DHCPv6 Reply message can carry more than one SCD Options.


Guo, et al.           Expires January 14, 2011                [Page 7]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   The DHCPv6 SCD Option is structured as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Option_SCD          |      Option-len               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |             Softwire Concentrator or CGN Address              |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Tunnel Type  |   Preference  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      .                          Sub Options                          .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option-code   Option_SCD (TBD2).

      Option-len    18 + length of sub options in octets.

      Softwire Concentrator or CGN Address   The outer layer IPv6
                    address of softwire concentrator, which is used to
                    establish tunnel.

      Tunnel Type   Tunnel type which users connect to softwire
                    concentrators or CGN. A few initial value
                    assignments, like L2TPv2, GRE, IPSec and IP in IP,
                    is listed in Section 8 IANA consideration.

      Preference    This indicates the preference level for a softwire
                    concentrator or CGN. 0 is the highest. When
                    receiving multiple options, user chooses a primary
                    softwire concentrator among them based on the
                    preference. The others are backup softwire
                    concentrators. The service provider assigns
                    different preference of each softwire concentrator
                    to support traffic engineering.

      Sub Options   An optional, variable length field is defined in
                    Section 5.1.

5.1. Suboptions in DHCPv6 SCD Option

   The suboptions defined in this section can be applied to DHCPv6 SCD
   option, defined above. They are used to configure the complementary
   tunnel information.


Guo, et al.           Expires January 14, 2011                [Page 8]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   The DHCPv6 SCD suboption is structured in TLV style as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Suboption Type         |         Suboption Len         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .               Suboption Value (Variable)                      .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       * DHCPv4 SCD Suboption Type (2 octet): each suboption type
         defines a certain property about the tunnel. The following are
         the types defined in this document:

          - Protocol Type: suboption type = 0

          - Prefix: suboption type = 1

          - GRE Key: suboption type = 2

         New suboptions may be defined in the future. Any unknown
         suboptions MUST be ignored and skipped.

       * Suboption Length (2 octet): the total number of octets of the
         suboption value field.

       * Suboption Value (variable): encodings of the value field depend
         on the suboption type as enumerated above.

   The following sub-sections define the encoding in detail.

5.1.1. Protocol Type Suboption

   This suboption designates which protocol is encapsulated in tunnel.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Type = 0           |            Len = 2            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Protocol Type            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Protocol Type field is defined in [IANA-ET] as ETHER TYPEs. The
   most used protocols are IPv4 (0x0800) and IPv6 (0x86dd).




Guo, et al.           Expires January 14, 2011                [Page 9]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


5.1.2. Prefix Suboption

   This suboption designates IPv6 prefix which is used to construct
   internal address of the tunnel.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Type = 1           |               Len             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Prefix Len          |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+
      .              IPv6 Prefix                      |    Padding    .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Len: total length of the prefix and padding fields in octets.

        Prefix Len: Length for this prefix in bits.

        IPv6 Prefix: IPv6 prefix allocated to the client to construct
        internal address of the tunnel.

        Padding: additional 0~7 bits MUST be padded at the end of IPv6
        Prefix field when the value in Prefix Len field is not a
        multiple of 8-bit. The padding bits SHOULD be set as 0.

   The semantics of the value field is determined by the tunnel type.
   For example, a client can obtain IPv6 Prefix of ISATAP tunnel by this
   suboption in DHCPv6 SDC Option.

5.1.3. GRE Key Suboption

   When the tunnel type is GRE, this suboption may be contained.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Type = 2           |             Len = 4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            GRE Key                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        GRE Key: 4-octet field [RFC2890] that is generated by the
        Softwire Concentrator or CGN. If the client receives the GRE Key
        suboption, the key MUST be inserted into the GRE encapsulation
        header of the payload packets sent by the client to the Softwire
        Concentrator or CGN. It is used for identifying extra context


Guo, et al.           Expires January 14, 2011               [Page 10]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


        information about the received payload. The payload packets
        without the correspondent GRE key or with an unmatched GRE Key
        will be silently dropped.

6. Illustration Examples

6.1. Example 1: Incremental CGN scenario

   As an example, an incremental CGN with IP address 192.0.2.1 and
   L2TPv2 tunnel support is deployed in an IPv4 ISP network. The CGN
   information is stored in a DHCPv4 server. When a dual stack user in
   the network wants to connect IPv6 Internet, it will send a DHCPv4
   request message to the DHCP server to obtain the CGN information. The
   DHCP server replies with a SCD option. The parameters in the SCD
   option are "CGN address = 192.0.2.1, tunnel type = 1, preference =
   80". After the user receives the option, it can set up an L2TPv2
   tunnel with the CGN.

6.2. Example 2: two CGN in DS lite scenario

   In another example scenario, there are two DS lite CGNs deployed in
   order to provide redundancy and load balancing. DS lite CGN1 is
   2001:db8:a::1, the other CGN2 is 2001:db8:b::1. Both of them support
   IPv4 in IPv6 tunnel. The preference of each CGN is decided by the
   network management policy. A user may get two SCD options, one
   describes CGN1 "CGN address = 2001:db8:a::1, tunnel type = 3,
   preference = 80" and the other describes CGN2 "CGN address =
   2001:db8:b::1, tunnel type = 3, preference = 255". The user should
   establish an IPv4 in IPv6 tunnel with the CGN1, which has higher
   preference. When the CGN1 is down, the user may re-establish tunnel
   to the CGN2.

   For the load balancing purpose, another user may receive the options,
   in which CGN2 has the higher preference value. The user may set CGN2
   as its primary CGN.

7. Security Considerations

   There are two forms of attack using bogus SCD options should be
   noticeable:

       1. A wiretap attack, in which a bogus concentrator observes the
       traffic before pretending to be the real client and sending the
       traffic to the real concentrator.

       2. A DoS attack, in which a bogus concentrator is used in some
       way to create a loop or simply to act as a source of DoS packets.


Guo, et al.           Expires January 14, 2011               [Page 11]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   The mechanisms based on DHCPv6 are all vulnerable by man-in-middle
   attacks. Proper use of DHCPv6 auto-configuration facilities
   [RFC3315], such as AUTH option or Secure DHCPv6
   [I-D.ietf-dhc-secure-dhcpv6] can prevent these threats, provided that
   a configuration token is known to both the client and the server.

8. IANA Considerations

   IANA is requested to allocate one DHCPv4 SCD Option code TBD1 and one
   DHCPv6 Option code TBD2.

   This document defines three new namespaces:

      - Tunnel Types
      - DHCPv4 SCD Suboption Types
      - DHCPv6 SCD Suboption Types

8.1. Tunnel Types

   Section 4 & 5 defines the following Tunnel Types, which should
   assigned by IANA for use within DHCPv4 & DHCPv6 SCD Option. IANA set
   up a registry for "Tunnel Types for DHCP SCD Option". This is a
   registry of one-octet values (0-255), to be assigned on a first-come,
   first-served basis. The initial assignments are as follows:

      Tunnel Name                             Type
      ---------------                         -----
      Reserved                                  0
      L2TPv2                                    1
      GRE                                       2
      IP-in-IP                                  3
      ISATAP                                    4
      6to4                                      5
      6rd                                       6
      IPsec                                     7

8.2. DHCPv4 SCD Suboption Types

   Section 4.1 defines the following SCD Suboption Types, which should
   assigned by IANA for use within DHCPv4 SCD Option. IANA set up a
   registry for "DHCPv4 SCD Suboption Types". This is a registry of one-
   octet values (0-255), to be assigned on a first-come, first-served
   basis. The initial assignments are as follows:






Guo, et al.           Expires January 14, 2011               [Page 12]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


      Tunnel Name                             Type
      ---------------                         -----
      Protocol Type                             0
      GRE Key                                   1

8.3. DHCPv6 SCD Suboption Types

   Section 5.1 defines the following SCD Suboption Types, which should
   assigned by IANA for use within DHCPv6 SCD Option. IANA set up a
   registry for "DHCPv6 SCD Suboption Types". This is a registry of one-
   octet values (0-255), to be assigned on a first-come, first-served
   basis. The initial assignments are as follows:

      Tunnel Name                             Type
      ---------------                         -----
      Protocol Type                             0
      Prefix                                    1
      GRE Key                                   2

9. Acknowledgments

   The authors would like to thank Wei Cao, Huawei, Bernie Volz, Cisco
   for valuable comments.

10. Change Log [RFC Editor please remove]

   draft-guo-softwire-sc-discovery-00, original version, 2009-06-23.

   draft-guo-softwire-sc-discovery-01, revised for protocol type, 2009-
   07-13.

   draft-guo-softwire-sc-discovery-02, revised after comments at IETF75
   and comments on the maillist, 2009-10-26.

   draft-guo-softwire-sc-discovery-03, minor update, 2010-03-05.

   draft-guo-softwire-sc-discovery-04, revised after comments at IETF77
   and comments on the maillist, 2010-07-12.

11. References

11.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.




Guo, et al.           Expires January 14, 2011               [Page 13]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997.

   [RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE",
             RFC 2890, September 2000.

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC3315, July 2003.

   [RFC5512] P. Mohapatra, E. and Rosen, "The BGP Encapsulation
             Subsequent Address Family Identifier (SAFI) and the BGP
             Tunnel Encapsulation Attribute", RFC 5512, April 2009.

   [RFC5571] B. Storer, et al., "Softwire Hub & Spoke Deployment
             Framework with L2TPv2", RFC 5571, June 2009.

11.2. Informative References

   [RFC4925] X. Li, S. Dawkins, D. Ward, and A. Durand, "Softwire
             Problem Statement", RFC 4925, July 2007.

   [I-D.ietf-softwire-dual-stack-lite]
             A. Durand, R. Droms, B. Haberman, and J. Woodyatt, "Dual-
             stack lite broadband deployments post IPv4 exhaustion",
             draft-ietf-softwire-dual-stack-lite, work in progress,
             March 2010.

   [I-D.ietf-v6ops-incremental-cgn]
             S. Jiang, D. Guo, and B. Carpenter, "An Incremental
             Carrier-Grade NAT (CGN) for IPv6 Transition" draft-ietf-
             v6ops-incremental-cgn, work in progress, June 2010.

   [I-D.ietf-dhc-secure-dhcpv6]
             S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft-
             ietf-dhc-secure-dhcpv6, work in progress, June 2010.

   [I-D.ietf-softwire-ipv6-6rd]
             Townsley W., et al., "IPv6 via IPv4 Service Provider
             Networks (6rd)", draft-ietf-softwire-ipv6-6rd, (work in
             progress), March 2010.

   [I-D.boucadair-port-rang]
             B. Storer, et al., "IPv4 Connectivity Access in the Context
             of IPv4 Address Exhaustion", draft-boucadair-port-range-
             02.txt, work in progress, July 2009.




Guo, et al.           Expires January 14, 2011               [Page 14]


Internet-Draft   draft-guo-softwire-sc-discovery-04          July 2010


   [IANA-ET] "Ether Types", http://www.iana.org/assignments/ethernet-
             numbers.



   Author's Addresses

   Dayong Guo
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: guoseu@huawei.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: shengjiang@huawei.com

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland, 1142
   New Zealand
   Email: brian.e.carpenter@gmail.com




















Guo, et al.           Expires January 14, 2011               [Page 15]