[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5571

Softwires Working Group                                   B. Storer, Ed.
Internet-Draft                                         C. Pignataro, Ed.
Intended status: Standards Track                      M. Dos Santos, Ed.
Expires: February 26, 2007                                 Cisco Systems
                                                        J. Tremblay, Ed.
                                                                  Hexago
                                                         L. Toutain, Ed.
                                                       GET/ENST Bretagne
                                                         August 25, 2006


         Softwires Hub & Spoke Deployment Framework with L2TPv2
             draft-ietf-softwire-hs-framework-l2tpv2-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the framework of the Softwire "Hubs and
   Spokes" solution with Layer 2 Tunneling Protocol (L2TPv2), and the
   implementation details specified in this document should be followed



Storer, et al.          Expires February 26, 2007               [Page 1]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   to achieve inter-operability among different vendor implementations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  6
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  6
     1.4.  Best Current Practices . . . . . . . . . . . . . . . . . .  6

   2.  Applicability of L2TPv2 for Softwire Requirements  . . . . . .  7
     2.1.  Network and Port Address Translation (NAT/PAT) . . . . . .  7
     2.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Authentication, Authorization and Accounting . . . . . . .  7
     2.5.  Privacy, Integrity, and Replay Protection  . . . . . . . .  8
     2.6.  Operations and Management (OAM)  . . . . . . . . . . . . .  8
     2.7.  Encapsulations . . . . . . . . . . . . . . . . . . . . . .  8

   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  IPv6 over IPv4 Softwire with L2TPv2  . . . . . . . . . . .  9
       3.1.1.  Host CPE as Softwire Initiator . . . . . . . . . . . .  9
       3.1.2.  Router CPE as Softwire Initiator . . . . . . . . . . . 10
       3.1.3.  Host behind CPE as Softwire Initiator  . . . . . . . . 11
       3.1.4.  Router behind CPE as Softwire Initiator  . . . . . . . 12
     3.2.  IPv4 over IPv6 Softwire with L2TPv2  . . . . . . . . . . . 13
       3.2.1.  Host CPE as Softwire Initiator . . . . . . . . . . . . 13
       3.2.2.  Router CPE as Softwire Initiator . . . . . . . . . . . 14
       3.2.3.  Host behind CPE as Softwire Initiator  . . . . . . . . 15
       3.2.4.  Router behind CPE as Softwire Initiator  . . . . . . . 16

   4.  Standardisation Status . . . . . . . . . . . . . . . . . . . . 17
     4.1.  Softwire Transport Related . . . . . . . . . . . . . . . . 17
     4.2.  L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  Authentication Authorization Accounting  . . . . . . . . . 18
     4.4.  MIB  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     4.5.  Softwire Payload Related . . . . . . . . . . . . . . . . . 18
       4.5.1.  For IPv6 Payloads  . . . . . . . . . . . . . . . . . . 18
       4.5.2.  For IPv4 Payloads  . . . . . . . . . . . . . . . . . . 18

   5.  Provisioning Model - Best Current Practices  . . . . . . . . . 19
     5.1.  Link Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.1.  IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.2.  IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.2.  Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 20
       5.2.1.  IPv6 Prefixes  . . . . . . . . . . . . . . . . . . . . 20
       5.2.2.  IPv4 Prefixes  . . . . . . . . . . . . . . . . . . . . 20



Storer, et al.          Expires February 26, 2007               [Page 2]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   6.  Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
     6.1.  L2TP Tunnel Setup  . . . . . . . . . . . . . . . . . . . . 22
       6.1.1.  Tunnel Establishment . . . . . . . . . . . . . . . . . 23
         6.1.1.1.  AVPs Required for Sotftwires . . . . . . . . . . . 25
         6.1.1.2.  AVPs Optional for Sotftwires . . . . . . . . . . . 26
         6.1.1.3.  AVPs not Required for Softwires  . . . . . . . . . 26
       6.1.2.  Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
       6.1.3.  Tunnel Teardown  . . . . . . . . . . . . . . . . . . . 27
     6.2.  PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
       6.2.1.  MTU  . . . . . . . . . . . . . . . . . . . . . . . . . 27
       6.2.2.  LCP  . . . . . . . . . . . . . . . . . . . . . . . . . 27
       6.2.3.  Authentication . . . . . . . . . . . . . . . . . . . . 28
       6.2.4.  IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 28
         6.2.4.1.  IPv6CP . . . . . . . . . . . . . . . . . . . . . . 28
         6.2.4.2.  IPv4CP . . . . . . . . . . . . . . . . . . . . . . 29
     6.3.  Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 29
     6.4.  DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
       6.4.1.  DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29
       6.4.2.  DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29

   7.  AAA - Best Current Practices . . . . . . . . . . . . . . . . . 30
     7.1.  Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . 30
       7.1.1.  IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30
       7.1.2.  IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30
     7.2.  Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 31
       7.2.1.  IPv6 Prefixes  . . . . . . . . . . . . . . . . . . . . 31
       7.2.2.  IPv4 Prefixes  . . . . . . . . . . . . . . . . . . . . 31

   8.  Maintenance and Statistics - Best Current Practices  . . . . . 31
     8.1.  Radius Accounting  . . . . . . . . . . . . . . . . . . . . 31
     8.2.  MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31

   10. Implementation status  . . . . . . . . . . . . . . . . . . . . 32

   11. Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 32
     11.1. Fragmentation and MTU  . . . . . . . . . . . . . . . . . . 32
     11.2. AAA Accounting (other draft) . . . . . . . . . . . . . . . 32

   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32

   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32

   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     14.2. Informative References . . . . . . . . . . . . . . . . . . 34




Storer, et al.          Expires February 26, 2007               [Page 3]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   Appendix A.  Revision History  . . . . . . . . . . . . . . . . . . 35

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 38















































Storer, et al.          Expires February 26, 2007               [Page 4]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


1.  Introduction

   The Softwires Working Group has selected Layer Two Tunneling Protocol
   (L2TPv2) as the phase I protocol to be deployed in the Softwires
   "Hubs and Spokes" solution space.  This document describes the
   framework for the L2TPv2 "Hubs and Spokes" solution, and the
   implementation details specified in this document should be followed
   to achieve interoperability among different vendor implementations.

   In the "Hubs and Spokes" solution space, a Softwire is established to
   provide the home network with IPv4 connectivity across an IPv6-only
   access network or IPv6 connectivity across an IPv4-only access
   network.  When L2TPv2 is used in the Softwire context, the voluntary
   tunneling model applies.  The Softwire Initiator (SI) at the home
   network takes the role of the L2TP Access Concentrator (LAC) client
   (initiating both the L2TP tunnel/session and PPP link) while the
   Softwire Concentrator (SC) at the ISP takes the role of the L2TP
   Network Server (LNS).  Since L2TPv2 compulsory tunneling model does
   not apply to Softwires, it should not be requested or honored.  This
   document identifies all the voluntary tunneling related L2TPv2
   attributes that apply to Softwires and specifies the handling
   mechanism for such attributes in order to avoid ambiguities in
   implementations.  This document also identifies the set of L2TPv2
   attributes specific to compulsory tunneling model that do not apply
   to Softwires and specifies the mechanism to ignore or nullify their
   effect within the Softwires context.

   The SI and SC must follow the L2TPv2 operations described in
   [RFC2661] when performing Softwire establishment, tear-down and OAM.
   With L2TPv2, a Softwire consists of an L2TPv2 Control Channel, a
   single Session, and the PPP link negotiated over the Session.  To
   establish the Softwire, the SI first initiates an L2TPv2 Control
   Channel to the SC which accepts the request and terminates the
   Control Channel.  L2TPv2 supports an optional mutual Control Channel
   authentication which allows both SI and SC to validate each other's
   identity at the initial phase of hand-shaking before proceeding with
   Control Channel establishment.  After the L2TPv2 Control Channel is
   established between the SI and SC, the SI initiates an L2TPv2 Session
   to the SC.  Then the PPP/IP link is negotiated over the L2TPv2
   Session between the SI and SC.  After the PPP/IP link is established,
   it acts as the Softwire between the SI and SC for tunneling IP
   traffic of one Address Family across the access network of another
   Address Family.

   During the life of the Softwire, both SI and SC may send L2TPv2
   keepalive HELLO messages to monitor the health of the Softwire and
   the peer LCCE or to refresh the NAT/PAT translation entry at the CPE
   or at the other end of the access link.  In the event of keepalive



Storer, et al.          Expires February 26, 2007               [Page 5]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   timeout or administrative shutdown of the Softwire, either SI or SC
   may tear down the Softwire by tearing down the L2TPv2 Control Channel
   and Session as specified in [RFC2661].

1.1.  Abbreviations

   LCCE   L2TP Control Connection Endpoint (See [RFC3931])

   SC     Softwire Concentrator, the node terminating the softwire in
          the service provider network (See
          [I-D.ietf-softwire-problem-statement])

   SI     Softwire Initiator, the node initiating the softwire within
          the customer network (See
          [I-D.ietf-softwire-problem-statement])

   STH    Softwire Transport Header (See
          [I-D.ietf-softwire-problem-statement])

   SPH    Softwire Payload Header (See
          [I-D.ietf-softwire-problem-statement])

1.2.  Requirements Language

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

1.3.  Contributing Authors

   Following is the complete list of contributors to this document.

      Maria Alice Dos Santos
      Carlos Pignataro
      Bill Storer
      Cisco Systems
      Jean-Francois Tremblay
      Hexago
      Laurent Toutain
      GET/ENST Bretagne

1.4.  Best Current Practices

   Some sections of this document contain recommendations that are not
   required for interoperability and correct operation of softwires
   implementations.  These sections are marked as "Best Current
   Practices".




Storer, et al.          Expires February 26, 2007               [Page 6]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


2.  Applicability of L2TPv2 for Softwire Requirements

   A list of Softwire "Hubs and Spokes" requirements have been
   identified by the Softwire Problem Statement
   [I-D.ietf-softwire-problem-statement].  The following section
   describes how L2TPv2 fulfills each of them.

2.1.  Network and Port Address Translation (NAT/PAT)

   A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case
   the scenario in question involves a non-upgradable pre-existing IPv4
   home gateway performing NAT/PAT or some carrier equipment at the
   other end of the access link performing NAT/PAT.  The L2TPv2 Softwire
   (i.e.  Control Channel and Session) is capable of NAT/PAT traversal
   since L2TPv2 can run over UDP.

   Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2
   does not offer UDP bypass regardless of NAT/PAT presence.  Both NAT/
   PAT "autodetect" and UDP bypass are optional requirements.

2.2.  Scalability

   In the "Hubs and Spokes" model, a carrier must be able to scale the
   solution to millions of softwire initiators by adding more hubs (i.e.
   softwire concentrators).  L2TPv2 is a widely deployed protocol in
   broadband services, and its scalability has been proven in multiple
   large-scale IPv4 Virtual Private Network deployments which scale up
   to millions of subscribers each.

2.3.  Multicast

   Multicast protocols simply run over L2TPv2 Softwires transparently
   together with other regular IP traffic.

2.4.  Authentication, Authorization and Accounting

   L2TPv2 supports optional mutual Control Channel authentication and
   leverages the optional mutual PPP per-session authentication.  L2TPv2
   is well integrated with AAA solutions (such as RADIUS) for both
   authentication and authorization.  Most L2TPv2 implementations
   available in the market support logging of authentication and
   authorization events.

   L2TPv2 integration with RADIUS accounting (RADIUS Accounting
   extension for tunnel [RFC2867]) allows the collection and reporting
   of L2TPv2 Softwire usage statistics.





Storer, et al.          Expires February 26, 2007               [Page 7]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


2.5.  Privacy, Integrity, and Replay Protection

   Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can
   be used in conjunction to provide per-packet authentication,
   integrity, replay protection and confidentiality for both L2TPv2
   control and data traffic [RFC3193] and [RFC3948].

   For Softwire deployments in which full payload security is not
   required, the L2TPv2 built-in Control Channel authentication and the
   inherited PPP authentication and PPP Encryption Control Protocol can
   be considered.

2.6.  Operations and Management (OAM)

   L2TPv2 supports an optional in-band keepalive mechanism which injects
   HELLO control messages after a specified period of time has elapsed
   since the last data or control message was received on a tunnel.  If
   the HELLO control message is not reliably delivered, then the Control
   Channel and its session will be torn down.  In the Softwire context,
   the L2TPv2 keepalive can be used to monitor connectivity status
   between the SI and SC and/or as a refresh mechanism for any NAT/PAT
   translation entry along the access link.

   L2TPv2 MIB [RFC3371] supports the complete suite of management
   operations such as configuration of Control Channel and Session,
   polling of Control Channel and Session status and their traffic
   statistics and notifications of Control Channel and Session UP/DOWN
   events.

2.7.  Encapsulations

   L2TPv2 supports the following encapsulations:

   o  IPv6/PPP/L2TPv2/UDP/IPv4

   o  IPv4/PPP/L2TPv2/UDP/IPv6

   o  IPv4/PPP/L2TPv2/UDP/IPv4

   o  IPv6/PPP/L2TPv2/UDP/IPv6

   Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not
   support "autodetect" of NAT/PAT.


3.  Deployment Scenarios

   For the "Hubs and Spokes" problem space, four scenarios have been



Storer, et al.          Expires February 26, 2007               [Page 8]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   identified.  In each of these four scenarios, different home
   equipment plays the role of the Softwire Initiator.  This section
   elaborates each scenario with L2TPv2 as the Softwire protocol and
   other possible protocols involved to complete the solution.  This
   section examines the four scenarios for both IPv6 over IPv4 and IPv4
   over IPv6 encapsulations.

3.1.  IPv6 over IPv4 Softwire with L2TPv2

3.1.1.  Host CPE as Softwire Initiator

   IPv6 connectivity across an IPv4-only access network Softwire
   Transport Header (STH).  Softwire initiator is the host CPE (directly
   connected to a modem), which is dual-stack.  There is no other
   gateway device.  The IPv4 traffic should not traverse the softwire.

   In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
   the capability for the ISP to assign the 64-bit Interface Id to the
   host CPE or perform uniqueness validation for the two Interface Ids
   at the two PPP ends [RFC2472].  After IPv6 over PPP is up, Neighbor
   Discovery runs over the IPv6 over PPP link, and the LNS can assign a
   64-bit global prefix to the host CPE via Router Advertisement (RA)
   while other configuration options (such as DNS) can be conveyed to
   the host CPE via DHCPv6/v4.



























Storer, et al.          Expires February 26, 2007               [Page 9]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


             IPv6 or dual-stack      IPv4-only      dual-stack
            |------------------||-----------------||----------|

      I                    SC                          SI
      N                  +-----+                   +----------+
      T                  |     |                   |  v4/v6   |
      E  <==[ IPv6  ]....|v4/v6|....[IPv4-only]....| host CPE |
      R     [network]    |     |    [ network ]    |          |
      N                  | LNS |                   |LAC Client|
      E                  +-----+                   +----------+
      T                          _ _ _ _ _ _ _ _ _
                               ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
                             PPP o L2TPv2 o UDP o IPv4
                                     "softwire"

                               <------------------>
                    IPv6CP: capable of /64 intf Id assignment or
                                 uniqueness check

                               |------------------>/64 prefix
                                        RA
                               |------------------>DNS, etc.
                                     DHCPv6/v4

                 Figure 1: Host CPE as Softwire Initiator

3.1.2.  Router CPE as Softwire Initiator

   IPv6 connectivity across an IPv4-only access network (STH).  Softwire
   initiator is the router CPE, which is a dual-stack device.  The IPv4
   traffic should not traverse the softwire.

   In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
   the capability for the ISP to assign the 64-bit Interface Id to the
   router CPE or perform uniqueness validation for the two Interface Ids
   at the two PPP ends [RFC2472].  After IPv6 over PPP is up, Neighbor
   Discovery runs over the IPv6 over PPP link, and the LNS can assign a
   64-bit global prefix to the router CPE via Router Advertisement (RA).
   DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating
   a 48-bit prefix to be used within the home network) and convey other
   configuration options (such as DNS) to the router CPE.










Storer, et al.          Expires February 26, 2007              [Page 10]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


          IPv6 or dual-stack      IPv4-only           dual-stack
         |------------------||-----------------||---------------------|

   I                    SC                          SI
   N                  +-----+                   +----------+
   T                  |     |                   |  v4/v6   |    +-----+
   E  <==[ IPv6  ]....|v4/v6|....[IPv4-only]....|   CPE    |----|v4/v6|
   R     [network]    |     |    [ network ]    |          |    | host|
   N                  | LNS |                   |LAC Client|    +-----+
   E                  +-----+                   +----------+
   T                          _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic
                          PPP o L2TPv2 o UDP o IPv4
                                  "softwire"

                            <------------------>
                    IPv6CP: capable of /64 intf Id assignment or
                                uniqueness check

                            |------------------>/64 prefix
                                     RA
                            |------------------>/48 prefix,
                                   DHCPv6       DNS, etc.

                                                     |------->/64 prefix
                                                         RA
                                                     |-------> DNS, etc.
                                                      DHCPv4/v6

                Figure 2: Router CPE as Softwire Initiator

3.1.3.  Host behind CPE as Softwire Initiator

   IPv6 connectivity across an IPv4-only access network (STH).  The CPE
   is IPv4-only.  Softwire initiator is a dual-stack host (behind IPv4-
   only CPE), which acts as an IPv6 host CPE.  The IPv4 traffic should
   not traverse the softwire.

   In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
   the capability for the ISP to assign the 64-bit Interface Id to the
   host or perform uniqueness validation for the two Interface Ids at
   the two PPP ends [RFC2472].  After IPv6 over PPP is up, Neighbor
   Discovery runs over the IPv6 over PPP link, and the LNS can assign a
   64-bit global prefix to the host via Router Advertisement (RA) while
   other configuration options (such as DNS) can be conveyed to the host
   via DHCPv6/v4.





Storer, et al.          Expires February 26, 2007              [Page 11]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


          IPv6 or dual-stack            IPv4-only         dual-stack
         |------------------||----------------------------||----------|

    I                   SC                                    SI
    N                 +-----+                              +----------+
    T                 |     |                   +-------+  |   v4/v6  |
    E <==[ IPv6  ]....|v4/v6|....[IPv4-only]....|v4-only|--|   host   |
    R    [network]    |     |    [ network ]    |  CPE  |  |          |
    N                 | LNS |                   +-------+  |LAC Client|
    E                 +-----+                              +----------+
    T                         _ _ _ _ _ _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
                               PPP o L2TPv2 o UDP o IPv4        traffic
                                       "softwire"

                            <------------------------------>
                     IPv6CP: capable of /64 intf Id assignment or
                                   uniqueness check

                            |------------------------------>/64 prefix
                                           RA
                            |------------------------------>DNS, etc.
                                        DHCPv4/v6

              Figure 3: Host behind CPE as Softwire Initiator

3.1.4.  Router behind CPE as Softwire Initiator

   IPv6 connectivity across an IPv4-only access network (STH).  The CPE
   is IPv4-only.  Softwire initiator is a dual-stack device (behind the
   IPv4-only CPE) acting as an IPv6 CPE router inside the home network.
   The IPv4 traffic should not traverse the softwire.

   In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
   the capability for the ISP to assign the 64-bit Interface Id to the
   v4/v6 router or perform uniqueness validation for the two Interface
   Ids at the two PPP ends [RFC2472].  After IPv6 over PPP is up,
   Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
   assign a 64-bit global prefix to the v4/v6 router via Router
   Advertisement (RA).  DHCPv6 can be used to perform IPv6 Prefix
   Delegation (for example, delegating a 48-bit prefix to be used within
   the home network) and convey other configuration options (such as
   DNS) to the v4/v6 router.








Storer, et al.          Expires February 26, 2007              [Page 12]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


         IPv6 or dual-stack           IPv4-only            dual-stack
        |------------------||-------------------------||-------------|

   I                   SC                                 SI
   N                 +-----+                           +----------+
   T                 |     |               +-------+   |  v4/v6   |
   E <==[ IPv6  ]....|v4/v6|..[IPv4-only]..|v4-only|---|  router  |
   R    [network]    |     |  [ network ]  |  CPE  | | |          |
   N                 | LNS |               +-------+ | |LAC Client|
   E                 +-----+                         | +----------+
   T                                                 |
                                                     ---------+-----+
                                                              |v4/v6|
                                                              | host|
                             _ _ _ _ _ _ _ _ _ _ _ _ _        +-----+
                           ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--IPv6 traffic
                              PPP o L2TPv2 o UDP o IPv4
                                      "softwire"

                           <--------------------------->
                  IPv6CP: capable of /64 intf Id assignment or
                                 uniqueness check

                           |--------------------------->/64 prefix
                                         RA
                           |--------------------------->/48 prefix,
                                       DHCPv6           DNS, etc.

                                                           |----> /64
                                                             RA   prefix
                                                           |----> DNS,
                                                       DHCPv4/v6  etc.

             Figure 4: Router behind CPE as Softwire Initiator

3.2.  IPv4 over IPv6 Softwire with L2TPv2

3.2.1.  Host CPE as Softwire Initiator

   IPv4 connectivity across an IPv6-only access network (STH).  Softwire
   initiator is the host CPE (directly connected to a modem), which is
   dual-stack.  There is no other gateway device.  The IPv6 traffic
   should not traverse the softwire.

   In this scenario, IPCP negotiates IPv4 over PPP which also provides
   the capability for the ISP to assign a global IPv4 address to the
   host CPE.  Global IPv4 address can also be assigned via DHCP.  Other
   configuration options (such as DNS) can be conveyed to the host CPE



Storer, et al.          Expires February 26, 2007              [Page 13]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   via IPCP [RFC1877] or DHCP.


             IPv4 or dual-stack      IPv6-only      dual-stack
            |------------------||-----------------||---------|

       I                   SC                          SI
       N                 +-----+                   +----------+
       T                 |     |                   |  v4/v6   |
       E <==[ IPv4  ]....|v4/v6|....[IPv6-only]....| host CPE |
       R    [network]    |     |    [ network ]    |          |
       N                 | LNS |                   |LAC Client|
       E                 +-----+                   +----------+
       T                         _ _ _ _ _ _ _ _ _
                               ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
                             PPP o L2TPv2 o UDP o IPv6
                                     "softwire"

                               <------------------>
                       IPCP: capable of global IP assignment
                                    and DNS, etc.

                 Figure 5: Host CPE as Softwire Initiator

3.2.2.  Router CPE as Softwire Initiator

   IPv4 connectivity across an IPv6-only access network (STH).  Softwire
   initiator is the router CPE, which is a dual-stack device.  The IPv6
   traffic should not traverse the softwire.

   In this scenario, IPCP negotiates IPv4 over PPP which also provides
   the capability for the ISP to assign a global IPv4 address to the
   router CPE.  Global IPv4 address can also be assigned via DHCP.
   Other configuration options (such as DNS) can be conveyed to the
   router CPE via IPCP [RFC1877] or DHCP.  For IPv4 Prefix Delegation
   for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.















Storer, et al.          Expires February 26, 2007              [Page 14]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


         IPv4 or dual-stack      IPv6-only       dual-stack Home
        |------------------||-----------------||-------------------|

   I                   SC                          SI
   N                 +-----+                   +----------+
   T                 |     |                   |  v4/v6   |  +-----+
   E <==[ IPv4  ]....|v4/v6|....[IPv6-only]....|   CPE    |--|v4/v6|
   R    [network]    |     |    [ network ]    |          |  | host|
   N                 | LNS |                   |LAC Client|  +-----+
   E                 +-----+                   +----------+
   T                         _ _ _ _ _ _ _ _ _
                           ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
                         PPP o L2TPv2 o UDP o IPv6
                                 "softwire"

                           <------------------>
                   IPCP: capable of global IP assignment
                               and DNS, etc.

                           |------------------>
                         DHCPv4: prefix, mask, PD

                                                             private/
                                                    |------> global
                                                      DHCP   IP, DNS,
                                                             etc.

                Figure 6: Router CPE as Softwire Initiator

3.2.3.  Host behind CPE as Softwire Initiator

   IPv4 connectivity across an IPv6-only access network (STH).  The CPE
   is IPv6-only.  Softwire initiator is a dual-stack host (behind the
   IPv6 CPE), which acts as an IPv4 host CPE.  The IPv6 traffic should
   not traverse the softwire.

   In this scenario, IPCP negotiates IPv4 over PPP which also provides
   the capability for the ISP to assign a global IPv4 address to the
   host.  Global IPv4 address can also be assigned via DHCP.  Other
   configuration options (such as DNS) can be conveyed to the host CPE
   via IPCP [RFC1877] or DHCP.










Storer, et al.          Expires February 26, 2007              [Page 15]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


          IPv4 or dual-stack            IPv6-only           dual-stack
         |------------------||----------------------------||----------|

    I                   SC                                      SI
    N                 +-----+                              +----------+
    T                 |     |                   +-------+  |   v4/v6  |
    E <==[ IPv4  ]....|v4/v6|....[IPv6-only]....|v6-only|--|   host   |
    R    [network]    |     |    [ network ]    |  CPE  |  |          |
    N                 | LNS |                   +-------+  |LAC Client|
    E                 +-----+                              +----------+
    T                         _ _ _ _ _ _ _ _ _ _ _ _ _ _
                            ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
                               PPP o L2TPv2 o UDP o IPv6        traffic
                                       "softwire"

                            <------------------------------>
                        IPCP: capable of global IP assignment
                                    and DNS, etc.

              Figure 7: Host behind CPE as Softwire Initiator

3.2.4.  Router behind CPE as Softwire Initiator

   IPv4 connectivity across an IPv6-only access network (STH).  The CPE
   is IPv6-only.  Softwire initiator is a dual-stack device (behind the
   IPv6-only CPE) acting as an IPv4 CPE router inside the home network.
   The IPv6 traffic should not traverse the softwire.

   In this scenario, IPCP negotiates IPv4 over PPP which also provides
   the capability for the ISP to assign a global IPv4 IP address to the
   v4/v6 router.  Global IPv4 address can also be assigned via DHCP.
   Other configuration options (such as DNS) can be conveyed to the
   v4/v6 router via IPCP [RFC1877] or DHCP.  For IPv4 Prefix Delegation
   for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.

















Storer, et al.          Expires February 26, 2007              [Page 16]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


         IPv4 or dual-stack          IPv6-only           dual-stack
        |------------------||-------------------------||------------|

   I                   SC                                 SI
   N                 +-----+                           +----------+
   T                 |     |               +-------+   |  v4/v6   |
   E <==[ IPv4  ]....|v4/v6|..[IPv6-only]..|v6-only|---|  router  |
   R    [network]    |     |  [ network ]  |  CPE  | | |          |
   N                 | LNS |               +-------+ | |LAC Client|
   E                 +-----+                         | +----------+
   T                                                 |
                                                     --------+-----+
                                                             |v4/v6|
                                                             | host|
                             _ _ _ _ _ _ _ _ _ _ _ _ _       +-----+
                           ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
                             PPP o L2TPv2 o UDP o IPv4        traffic
                                     "softwire"

                           <--------------------------->
                   IPCP: assigns global IP address and DNS, etc.

                           |--------------------------->
                              DHCPv4: prefix, mask, PD

                                                                private/
                                                         |----> global
                                                          DHCP  IP, DNS,
                                                                etc.

             Figure 8: Router behind CPE as Softwire Initiator


4.  Standardisation Status

4.1.  Softwire Transport Related

   RFC 3193   Securing L2TP using IPsec.

   RFC 3948   UDP Encapsulation of IPsec ESP Packets.
              IPSec supports both IPv4 and IPv6 transports.

4.2.  L2TPv2








Storer, et al.          Expires February 26, 2007              [Page 17]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   RFC 2661   Layer Two Tunneling Protocol "L2TP".
              For both IPv4 and IPv6 payloads, support is complete.
              For both IPv4 and IPv6 transport, support is complete.

4.3.  Authentication Authorization Accounting

   RFC 2867   RADIUS Accounting Modifications for Tunnel Protocol
              Support.
              Need new extensions for IPv6 traffic accounting
              [I-D.stevant-softwire-accounting].

   RFC 2865   Remote Authentication Dial In User Service (RADIUS).

   RFC 3162   RADIUS and IPv6.

4.4.  MIB

   RFC 3371   Layer Two Tunneling Protocol "L2TP" Management Information
              Base.

   RFC 4087   IP Tunnel MIB.
              Both IPv4 and IPv6 transport is supported.

              Do we need a new set of counters for IPv6 Payloads?
              l2tpDomainStatsPayloadHCRxOctets
              l2tpDomainStatsPayloadHCRxPkts
              l2tpDomainStatsPayloadHCRxDiscs
              l2tpDomainStatsPayloadHCTxOctets
              l2tpDomainStatsPayloadHCTxPkts

4.5.  Softwire Payload Related

4.5.1.  For IPv6 Payloads

   RFC 2472   IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2].

   RFC 3315   Dynamic Host Configuration Protocol for IPv6 (DHCPv6).

   RFC 3646   DNS Configuration options for Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6).

   RFC 2461   Neighbor Discovery for IP Version 6 (IPv6).

4.5.2.  For IPv4 Payloads







Storer, et al.          Expires February 26, 2007              [Page 18]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   RFC 1661   The Point-to-Point Protocol (PPP).

   RFC 1332   The PPP Internet Protocol Control Protocol (IPCP).

   DHCP Subnet Allocation
              Work in progress [I-D.ietf-dhc-subnet-alloc].


5.  Provisioning Model - Best Current Practices

   A softwire can provide stable addressing even if the underlying
   addressing scheme changes, by opposition to automatic tunneling.  A
   Softwire Concentrator SHOULD always provide the same address and
   prefix to a reconnecting user.  However, if the goal of the softwire
   service is to provide a temporary address for a roaming user, it MAY
   be provisioned to provide only a temporary address.

   The address and prefix is expected to change when reconnecting to a
   different Softwire Concentrator.  However an organization providing a
   softwire service MAY provide the same address and prefix across
   different Softwire Concentrators at the cost of a more fragmented
   routing table.  The routing fragmentation issue may be limited if the
   prefixes are aggregated in a location topologically close to the SC.
   This would be the case for example if several SCs are put in parallel
   for load-balancing purpose.

5.1.  Link Addresses

5.1.1.  IPv6

   A Softwire Concentrator SHOULD provide globally routable addresses
   and prefixes to Softwire Initiators.  Other types of addresses such
   as Unique Local Addresses [RFC4193] MAY be used to connect to a
   private network with no global connectivity.

   A single /64 SHOULD be reserved for the PPP link.

5.1.2.  IPv4

   A Softwire Concentrator MAY provide either globally routable or
   private IPv4 addresses.  If private addresses are used, the delegated
   prefix should be in the same address space than the PPP endpoint to
   avoid nested NAT configurations.  A globally routable address is
   preferable, since in most cases, it is expected the CPE device will
   perform the IPv4 NAT function.

   The endpoints of the PPP link use host addresses (i.e., /32),
   negotiated using IPCP.



Storer, et al.          Expires February 26, 2007              [Page 19]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


5.2.  Delegated Prefixes

5.2.1.  IPv6 Prefixes

   Delegated IPv6 prefixes are between /48 and /64 in length.  A CPE
   device receiving a /64 is expected to perform bridging if more than
   one interface is available (wired and wireless for example).

   The length of delegated IPv6 prefixes SHOULD be a multiple of 4.
   Reverse DNS delegation of IPv6 prefixes that are not multiples of 4
   is more complex since more than one record must be inserted in the
   zone file.  In the worst case, up to 8 records have to be entered for
   one prefix if the prefix length is equal to a multiple of 4 plus 1
   (/61 for example).

   Example:

      One NS record is required for the reverse DNS delegation of 2001:
      db8:1:10::/60

         NS 1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

      Several (8) NS records are required for the reverse DNS delegation
      of 2001:db8:1:10::/61

         NS 0.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 1.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 2.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 3.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 4.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 5.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 6.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

         NS 7.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com

5.2.2.  IPv4 Prefixes

   Delegated IPv4 prefixes should be of the same scope than the assigned
   IPv4 addresses and be routable within that address space.  Prefix
   length is between /8 and /30.  However, the DNS reverse delegation of
   prefixes that are not multiples of 8 may be problematic.  In the
   worst case of a one bit difference, for example a /25, 128 NS records



Storer, et al.          Expires February 26, 2007              [Page 20]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   must be configured in the reverse zone file.


6.  Softwire Establishment

   A softwire is established in 3 distinct steps (Figure 9).  First a
   L2TP tunnel with a single session is established from the SI to the
   SC.  Second a PPP session is established over the L2TP session and
   the SI get an address.  Third the SI optionally gets other
   information through DHCP such as a delegated prefix and DNS servers.


             SC                                 SI
              |                                 |
              |<-------------L2TP-------------->| L2TP
              |                                 |
              |<-------------PPP--------------->| PPP and
              |<-------Neighbor Discovery------>| configuration
              |                                 |
              |<-------------DHCP-------------->| Additional
              |                                 | configuration
              |                                 | (optional)

            Figure 9: Steps for the Establishment of a Softwire



























Storer, et al.          Expires February 26, 2007              [Page 21]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


         SC                                 SI
          |                                 |
          |<------------SCCRQ---------------| -
          |-------------SCCRP-------------->| |
          |<------------SCCCN---------------| |
          |<------------ICRQ----------------| | L2TP
          |-------------ICRP--------------->| |
          |<------------ICCN----------------| -
          |                                 |
          |<-----Configuration-Request------| -
          |------Configuration-Request----->| | PPP
          |<-------Configuration-Ack--------| | LCP
          |--------Configuration-Ack------->| -
          |                                 |
          |-----------Challenge------------>| - PPP Authentication
          |<----------Response--------------| | (Optional - CHAP)
          |------------Success------------->| -
          |                                 |
          |<-----Configuration-Request------| -
          |------Configuration-Request----->| | PPP NCP
          |<-------Configuration-Ack--------| | (IPV6CP or IPCP)
          |--------Configuration-Ack------->| -
          |                                 |
          |<------Router-Solicitation-------| - Neighbor Discovery
          |-------Router-Advertisement----->| | (IPv6 only)
          |                                 | -
          |                                 |
          |<-----------Solicit--------------| -
          |-----------Advertise------------>| | DHCP
          |<---------- Request--------------| | (Optional)
          |-------------Reply-------------->| -

       Figure 10: Detailed Steps in the Establishment of a Softwire

6.1.  L2TP Tunnel Setup

   L2TPv2 [RFC2661] was initially designed to connect a Network Access
   Server (NAS) concentrating traffic from multiple users to different
   Internet Access Providers (IAP).  In L2TP terminology, an L2TP
   Network Server (LNS) is a device concentrating L2TP connections
   coming from an L2TP Access Concentrator (LAC) dispatched on the IP
   network.  In the Softwires Hub and Spoke model, the LAC will act as
   the Softwires Initiator (SI) and the LNS as the Softwires
   Concentrator (SC).  The SI can be located on the end user equipment,
   a special gateway dedicated to handle IPv6 traffic, or directly on
   the home gateway.

   An L2TP packet, in the softwires model, MUST be carried over UDP.



Storer, et al.          Expires February 26, 2007              [Page 22]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   The underlying version of the IP protocol may be IPv4 or IPv6,
   depending on the transition scenario deployed.

6.1.1.  Tunnel Establishment

   The following diagram describes messages exchanged and AVPs used to
   establish communication between an SI (LAC) and an SC (LNS).  They
   represent a subset of exchanges defined in [RFC2661] mostly to limit
   implementation complexity on the SI side.  One session per tunnel is
   only needed, since the LAC does not act as a PPP session
   concentrator.  The LAC MUST always establish the session.  No
   outgoing or analog calls are permitted.  L2TP attributes SHOULD NOT
   be hidden.






































Storer, et al.          Expires February 26, 2007              [Page 23]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


                  LAC (SI)        LAC (SC)
                  ----------      ----------
                  SCCRQ ->
                  Mandatory AVP
                     Message Type
                     Protocol Version
                     Host Name
                     Framing Capabilities
                     Assigned Tunnel ID
                  Optional AVP:
                     Receive Window Size
                     Firmware Revision
                     Vendor Name
                     (Challenge)

                                  <- SCCRP
                                  Mandatory AVP:
                                     Message Type
                                     Protocol Version
                                     Framing Capabilities
                                     Host Name
                                     Assigned Tunnel ID
                                  Optional AVP:
                                     Firmware Revision
                                     Vendor Name
                                     Receive Window Size
                                     (Challenge Response)
                                     (Challenge)

                  SCCCN ->
                  Mandatory AVP:
                     Message Type
                     (Challenge Response)

                                  <- ZLB ACK

                      Figure 11: Tunnel Establishment














Storer, et al.          Expires February 26, 2007              [Page 24]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


                   LAC (SI)        LAC (SC)
                   ----------      ----------
                   ICRQ ->
                   Mandatory AVP:
                      Message Type
                      Assigned Session ID
                      Call Serial Number

                                   <- ICRP
                                   Mandatory AVP:
                                      Message Type
                                      Assigned Session ID

                   ICCN ->
                   Mandatory AVP:
                      Message Type
                      (Tx) Connect Speed
                      Framing Type

                                   <- ZLB ACK

                     Figure 12: Session Establishment

   This paragraph specifies specific values for AVPs used in the
   Softwires context.

6.1.1.1.  AVPs Required for Sotftwires

   Host Name AVP

      This AVP is mandatory and is present in SCCRQ and SCCRP messages.
      This AVP MAY be used to authenticate users.

      For the LNS, the hostname COULD be the server name with the fully
      qualified domain.  For the LAC, the name COULD be
      user-id@name.fully-qualified-domain.  If name or fully-qualified-
      domain is not configured (since the equipment is in the bootstrap
      phase) this part CAN be left blank.  User-id is the value used to
      authenticate the user.  If user-id is not defined, "Softwires"
      COULD be used.

   Framing Capabilities AVP

      Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
      This AVP MUST be ignored by the receiver.

   Framing Type AVP




Storer, et al.          Expires February 26, 2007              [Page 25]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


      Synchronous bit MUST be set to 1 and Asynchronous bit to 0.  This
      AVP SHOULD be ignored by the receiver.

   (Tx) Connect Speed

      (Tx) Connect Speed is a mandatory AVP but is not meaningful in
      Softwires context.  Value should be left to 0 and ignored by the
      receiver.

   Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor
   Name, Call Serial Number, and Assigned Session ID

      As defined in [RFC2661]

6.1.1.2.  AVPs Optional for Sotftwires

   Challenge and Challenge Response AVPs

      Session authentication as defined in [RFC2661] is based on a
      shared secret known by LACs and LNSs, and is not designed to
      authenticate a specific user.  This AVP is not required since
      security enhancement is not guaranteed.

      While user authentication is typically done at the PPP level,
      tunnel authentication may be helpful in preventing DoS attacks.

6.1.1.3.  AVPs not Required for Softwires

   L2TP specifies numerous AVPs that, while allowed for a given command,
   are irrelevant to a Softwires.  Softwires implementations should not
   send these AVPs.  However, they should ignore them when they are
   received.  This will make it easier to create Softwires applications
   on top of existing L2TP implementations.

6.1.2.  Tunnel Maintenance

   Periodically, the SI must transit a message to the SC to maintain
   context in the NAT and detect tunnel failure.  The LNS and LAC SHOULD
   use L2TPv2 HELLO messages for this purpose.  As specified in
   [RFC2661] HELLO messages SHOULD be generated if no other messages are
   sent for a period of time.  The value of 60 seconds recommended by
   [RFC2661] fulfills Softwires constraints.  LCP Echo Request and Reply
   messages SHOULD NOT be used for this purpose.  The use of both LCP
   Echo and L2TPv2 HELLO messages is redundant in the Softwires
   environment.






Storer, et al.          Expires February 26, 2007              [Page 26]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


6.1.3.  Tunnel Teardown

   Either the SI and SC can teardown the session and then the tunnel.
   No change or specific parameter are required compared to [RFC2661].
   The SI or the SC sends an CDN message, acknowledged by ZLB message.
   The initiator of the tunnel teardown, MUST immediately after close
   the tunnel by sending a StopCCN message, acknowledged by a ZLB
   message.

6.2.  PPP Connection

6.2.1.  MTU

   The MTU of the PPP link SHOULD be the link MTU minus the size of the
   IP, UDP, L2TP, and PPP headers together.  On an IPv4 link with an MTU
   equal to 1500 bytes, this would usually mean a PPP MTU of 1460 bytes.
   This may vary according to the size of the L2TP header.

   In order to optimize the link efficiency and prevent fragmentation, a
   path MTU discovery algorithm may be used to detect the maximum MTU on
   the path between the SI and the SC.  However path MTU discovery is
   out of scope for this document.

6.2.2.  LCP

   Once the L2TP session is established, the SI initiates the PPP
   connection by sending a LCP Configuration Request message.  The SC
   also sends a LCP Configuration Request containing at least the
   Maximum Receive Unit option, authentication protocol and Magic
   Number.  If no authentication protocol option is present, the SI
   considers the service as unauthenticated (see Section 6.2.3).  Each
   party answers with a Configuration Ack message to finish the link
   configuration.

   Negotiations in both directions MUST reject compression of the
   Protocol field (PFC), and compression of the Address and Control
   fields (ACFC).  Link Quality Report SHOULD be disabled on both sides.
   The Magic Number option MAY be part of the negotiation.  The MRU
   value is by default 1500 and can be changed by negotiation.

   Figure 13 gives an example of the LCP exchange between an SI and an
   SC; the message order is not significant since both negotiations may
   start concurrently.








Storer, et al.          Expires February 26, 2007              [Page 27]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


     SC:                                     SI:
     --                                      --
     LCP Conf-Request
        MRU 1500
        Magic Number 0x5c35721e

                                             LCP Conf-Ack
                                                MRU 1500
                                                Magic Number 0x5c35721e

                                             LCP Conf-Request
                                                MRU  1500,
                                                Magic-Num  0xcd7f0041,
                                                Auth-Prot  CHAP, MD5
     LCP Conf-ack
        MRU  1500,
        Magic-Num  0xcd7f0041,
        Auth-Prot  CHAP, MD5

                 Figure 13: LCP Exchange between SI and SC

6.2.3.  Authentication

   After sending the LCP Configuration Ack, the SC proceeds with the PPP
   authentication phase.  CHAP [RFC1994] authentication MUST be
   supported by both the Softwire Initiator and Softwire Concentrator.
   Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
   be supported.

   The Softwire Concentrator MAY allow non-authenticated connection.  In
   that case, the SC acts as a gateway for anonymous connections.  This
   approach is better than an open relay implementation since ingress
   filtering is performed on established tunnels (see Section 9).  If
   non-authenticated connections are supported by the SC, enabling this
   function MUST be configurable by the SC administrator.

6.2.4.  IPCP

6.2.4.1.  IPv6CP

   After the authentication phase, the Softwire Initiator MUST send an
   IPV6CP Configuration-Request message [RFC2472] containing an
   Interface Identifier.  The Interface Identifier SHOULD be of the IEEE
   EUI-64 format.  A Configuration-Request message is also sent by the
   SC.  If that message constrains a different Interface Identifier, it
   MUST be accepted through a Configure-Ack message.





Storer, et al.          Expires February 26, 2007              [Page 28]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


6.2.4.2.  IPv4CP

   A Softwire Initiator establishing an IPv4 softwire SHOULD send a
   Configuration-Request with all four octets of the IP-Address
   configuration option set to 0 (see [RFC1332]).  If the Softwire
   Concentrator does not assign an address to the Softwire Initiator,
   the SI MUST request an address through DHCP.  The SC may indicate a
   failure to assign an address by sending back an address with all
   octets set to 0 or by sending a protocol reject in response to the
   IPCP CONFREQ.

6.3.  Neighbor Discovery

   The Softwire Initiator of an IPv6 softwire MUST send a Router
   Sollicitation message to the Softwire Concentrator after IPV6CP is
   completed.  The Softwire Concentrator MUST answer with a Router
   Advertisement containing the global IPv6 prefix of the PPP link.

   Duplicate Address Detection (DAD) is redundant in that context and
   doesn't have to be performed.  For that purpose,
   DupAddrDetectTransmits autoconfiguration variable to zero [RFC2472]
   [RFC2462].

   If DHCPv6 is available, the M bits of the Router Advertisement SHOULD
   be set.

6.4.  DHCP

   The Softwire Initiator MAY use DHCP to get additional information
   such as delegated prefix and DNS servers.  If the SI supports DHCP,
   it SHOULD send a Solicit message to verify if more information is
   available.

6.4.1.  DHCPv6

   IF a SI establishing an IPv6 Softwire acts as a router (scenarios
   3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the
   DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.

6.4.2.  DHCPv4

   A SI establishing an IPv4 softwire MAY send a DHCP request containing
   the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].  One
   Subnet-Request suboption MUST be configured with the 'h' bit set to
   '1', as the SI is expected to perform the DHCP server function.  The
   'i' bit of the Subnet-Request suboption should be set to '0' the
   first time a prefix is requested and to '1' on subsequent requests,
   if a prefix has been allocated.  The Prefix length suboption SHOULD



Storer, et al.          Expires February 26, 2007              [Page 29]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   be 0 by default.  If the SI is configured to support only specific
   prefix lengths, it should specify the longest (smallest) prefix
   length it supports.

   If the SI was previously assigned a prefix from that same SC, it
   SHOULD include the Subnet Information suboption with the prefix it
   was previously assigned.  The 'c' and 's' bits of the suboption
   SHOULD be set to '0'.


7.  AAA - Best Current Practices

   The Softwire Concentrator is expected to act as a client to a AAA
   server, for example a Radius server.  During the PPP authentication
   phase, the AAA server may return additional information in the form
   of attributes in the Access Accept message.

   The Softwire Concentrator MAY include the Tunnel-Type and Tunnel-
   Medium-Type attributes [RFC2868] in the Access Request messages to
   provide a hint of the type of softwire being configured.

7.1.  Tunnel Endpoints

7.1.1.  IPv6 Softwires

   If the AAA server includes a Framed-Interface-Id attribute [RFC3162],
   the Softwire Concentrator MUST send it to the Softwire Initiator in
   the Interface Identifier field of its IPV6CP Configuration Request
   message.

   If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that
   prefix MUST be used in the router advertisements sent to the SI.  If
   Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
   MUST choose a prefix with that pool to send router advertisements.

   If none of the attributes above are included but the AAA server
   returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
   attributes [RFC2868] are present and of the correct address family,
   these MUST be used in the IPV6CP Interface Identifier and for the
   router advertisements.

7.1.2.  IPv4 Softwires

   If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
   Concentrator MUST provide that address to the Softwire Initiator
   during IPCP address negotiation.  That is, when the Softwire
   Initiator requests an IP address from the Softwire Concentrator, the
   address provided should be the Framed-IP-Address.



Storer, et al.          Expires February 26, 2007              [Page 30]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   If the Framed-IP-Address attribute is not present and the Tunnel-
   Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
   present and of the correct address family, these SHOULD be used in
   the IPCP IP-Address configuration option.

7.2.  Delegated Prefixes

7.2.1.  IPv6 Prefixes

   If the attribute Delegated-IPv6-Prefix
   [I-D.ietf-radext-delegated-prefix] is present in the Radius Access
   Accept message, it must be used by the Softwire Concentrator for the
   delegation of the IPv6 prefix.  Since the prefix delegation is
   performed by DHCPv6 and the attribute is linked to a username, the SC
   MUST associate the DUID of a DHCPv6 request to tunnel it came from
   and its user.

7.2.2.  IPv4 Prefixes

   The combination of the Framed-IP-Address and Framed-IP-Netmask
   attributes [RFC2865] MAY be used by the Softwire Concentrator to
   delegate an IPv4 prefix to the Softwire Initiator.


8.  Maintenance and Statistics - Best Current Practices

8.1.  Radius Accounting

   Radius Accounting for L2TPv2 is well documented (see Section 4.3).
   Softwires implementers may use the existing RFCs as appropriate for
   their business environment.

8.2.  MIBs

   MIB support for L2TPv2 is well documented (see Section 4.4).
   Softwires implementers may use the existing RFCs as appropriate for
   their business environment.  Also see [RFC4293]


9.  Security Considerations

   The L2PTv2 softwires solution provides the following tools for
   security:

   o  IPsec [RFC3193] provides the highest level of security.

   o  PPP CHAP [RFC1994] provides basic user authentication.




Storer, et al.          Expires February 26, 2007              [Page 31]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   o  L2TP Tunnel Authentication [RFC2661] provides authentication at
      tunnel setup.  It may be used to limit DoS attacks by
      authenticating the tunnel before L2TP session and PPP resources
      are allocated.

   A detailed discussion of softwires security is contained in
   [I-D.ietf-softwire-security-requirements].


10.  Implementation status


11.  Open issues

11.1.  Fragmentation and MTU

11.2.  AAA Accounting (other draft)


12.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].


13.  Acknowledgements

   The authors would like to acknowledge the following contributors who
   provided helpful input on this document: Florent Parent, Jordi Palet
   Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley,
   Francis Dupont, and Bruno Stevant.

   The authors would also like to acknowledge the participants in the
   Softwires interim meeting at China University - Hong Kong (February
   23-24, 2006).  The minutes for this meeting are at
   <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>.


14.  References

14.1.  Normative References

   [I-D.ietf-dhc-subnet-alloc]
              Johnson, R., "Subnet Allocation Option",
              draft-ietf-dhc-subnet-alloc-03 (work in progress),
              June 2005.

   [I-D.ietf-radext-delegated-prefix]



Storer, et al.          Expires February 26, 2007              [Page 32]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


              Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
              Attribute", draft-ietf-radext-delegated-prefix-02 (work in
              progress), July 2006.

   [I-D.ietf-softwire-problem-statement]
              Li, X., "Softwire Problem Statement",
              draft-ietf-softwire-problem-statement-02 (work in
              progress), May 2006.

   [I-D.ietf-softwire-security-requirements]
              Yamamoto, S., "Softwire Security Analysis and
              Requirements",
              draft-ietf-softwire-security-requirements-00 (work in
              progress), June 2006.

   [RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
              (IPCP)", RFC 1332, May 1992.

   [RFC1877]  Cobb, S. and F. Baker, "PPP Internet Protocol Control
              Protocol Extensions for Name Server Addresses", RFC 1877,
              December 1995.

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

   [RFC2472]  Haskin, D. and E. Allen, "IP Version 6 over PPP",
              RFC 2472, December 1998.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
              G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
              RFC 2661, August 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2867]  Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
              Modifications for Tunnel Protocol Support", RFC 2867,
              June 2000.

   [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,



Storer, et al.          Expires February 26, 2007              [Page 33]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


              M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
              Support", RFC 2868, June 2000.

   [RFC3162]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
              RFC 3162, August 2001.

   [RFC3193]  Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
              "Securing L2TP using IPsec", RFC 3193, November 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3371]  Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
              Tunneling Protocol "L2TP" Management Information Base",
              RFC 3371, August 2002.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

14.2.  Informative References

   [I-D.ietf-ipv6-over-ppp-v2]
              Varada, S., "IP Version 6 over PPP",
              draft-ietf-ipv6-over-ppp-v2-02 (work in progress),
              June 2005.

   [I-D.stevant-softwire-accounting]
              Stevant, B., "Accounting on Softwires",
              draft-stevant-softwire-accounting-00 (work in progress),
              February 2006.

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4293]  Routhier, S., "Management Information Base for the
              Internet Protocol (IP)", RFC 4293, April 2006.



Storer, et al.          Expires February 26, 2007              [Page 34]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


Appendix A.  Revision History

   [Note to RFC Editor: please remove this entire appendix, and the
   corresponding entries in the table of contents, prior to
   publication.]

   Changes between -00 and -01:

   o  Changed alignment in all figures to be centered, and fixed
      Figure 9 reference.

   o  Section 1.4: Added new section with "Best Current Practices"
      definition.

   o  Marked the following sections as "Best Current Practices":
      Section 5, Section 7, and Section 8.

   o  Section 5.1.1, last paragraph: Removed sentence on IPv6 link
      address on the PPP link.  Mailing list comment from Florent
      Parent, 13-Jul-2006.

   o  Section 5.1.2, last paragraph: Changed IPv4 PPP link address to
      use host addresses (/32) negotiated with IPCP instead of /30.
      Mailing list comment from Bill Storer, 5-Jul-2006.

   o  Section 6, Figure 10: Correction, s/SCCSN/SCCCN/; added missing
      ICRP, and changed direction of ICCN; typo correction s/IPV6P/
      IPV6CP/.  Mailing list comment from Bill Storer, 5-Jul-2006.

   o  Section 6, Figure 10: Marked CHAP as "Optional - CHAP".

   o  Section 6.1, Section 6.1.1, and Section 6.1.3: Minor typographical
      error correction and rewording of some sentences for grammar.

   o  Section 6.1.1.1, Host Name AVP: Removed "for debugging purposes"
      and added that MAY be used to authenticate users.

   o  Section 6.1.1.1, Framing Capabilities AVP: Swapped SHOULD and
      MUST.  Mailing list comment from Bill Storer, 5-Jul-2006, text
      from Laurent Toutain.

   o  Section 6.1.1.1, (Tx) Connect Speed: Correction: "but is *not*
      meaningful".

   o  Section 6.1.1.2, Challenge and Challenge Response AVPs: Removed
      the last sentence of the first paragraph.  Mailing list comment
      from Bill Storer, 5-Jul-2006, text from Laurent Toutain.




Storer, et al.          Expires February 26, 2007              [Page 35]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   o  Section 6.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and
      not LCP Echo Request and Reply messages to detect tunnel failure,
      as redundant in Softwires.  Mailing list comment from Florent
      Parent, 10-Jul-2006, text from Bill Storer.

   o  Section 6.2.1, first paragraph: Fixed PPP MTU calculation.
      Mailing list comment from Florent Parent, 10-Jul-2006.

   o  Section 6.2.2: Updated and augmented the text, and added
      Figure 13.

   o  Section 6.2.4.2: Rewrote to generalize the address assignment
      failure, to be an all-zeroes address or a protocol reject in
      response to the IPCP CONFREQ.  Mailing list comment from Bill
      Storer, 5-Jul-2006, text from JF Tremblay.

   o  Section 7, second paragraph: s/Tunnel-Medium /Tunnel-Type /.
      Mailing list comment from Bill Storer, 5-Jul-2006.

   o  Section 7.1.2: Added usage of Framed-IP-Address attribute, and if
      not present then use the Tunnel-Client-Endpoint and Tunnel-Server-
      Endpoint attributes.  Mailing list comment from Bill Storer,
      5-Jul-2006, text from JF Tremblay and Bill Storer.

   o  Completed Section 7.2.2, Section 8.1, Section 8.2, and Section 9.

   Revision -00:

   o  Initial revision.


Authors' Addresses

   Bill Storer (editor)
   Cisco Systems
   170 W Tasman Dr
   San Jose, CA  95134
   USA

   Email: bstorer@cisco.com











Storer, et al.          Expires February 26, 2007              [Page 36]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


   Carlos Pignataro (editor)
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com


   Maria Alice Dos Santos (editor)
   Cisco Systems
   170 W Tasman Dr
   San Jose, CA  95134
   USA

   Email: mariados@cisco.com


   Jean-Francois Tremblay (editor)
   Hexago
   1470 Peel, suite 910
   Montreal, QC  J4B 2Z5
   Canada

   Email: jean-francois.tremblay@hexago.com


   Laurent Toutain (editor)
   GET/ENST Bretagne

   Email: Laurent.Toutain@enst-bretagne.fr



















Storer, et al.          Expires February 26, 2007              [Page 37]

Internet-Draft    Softwires H & S Framework with L2TPv2      August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Storer, et al.          Expires February 26, 2007              [Page 38]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/