draft-ietf-softwire-hs-framework-l2tpv2-07.txt   draft-ietf-softwire-hs-framework-l2tpv2-08.txt 
Softwires Working Group B. Storer Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: March 29, 2008 Cisco Systems Expires: August 1, 2008 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne TELECOM Bretagne
J. Tremblay J. Tremblay
Trellia Networks Trellia Networks
September 26, 2007 January 29, 2008
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwire Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-07 draft-ietf-softwire-hs-framework-l2tpv2-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 29, 2008. This Internet-Draft will expire on August 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes the framework of the Softwire "Hub and Spoke" This document describes the framework of the Softwire "Hub and Spoke"
solution with Layer 2 Tunneling Protocol (L2TPv2), and the solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). The
implementation details specified in this document should be followed implementation details specified in this document should be followed
to achieve inter-operability among different vendor implementations. to achieve interoperability among different vendor implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6
1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Network Address Translation (NAT and NAPT) . . . . . . . . 7 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 9
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 14 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 14
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17 4. Standardization Status . . . . . . . . . . . . . . . . . . . . 17
4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18
4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.3. Authentication Authorization Accounting . . . . . . . . . 18
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 21 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Considerations about the Address Provisioning Model . . . . . 28 6. Considerations about the Address Provisioning Model . . . . . 29
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 29 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 30 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 30
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 30 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31
7. Considerations about Address Stability . . . . . . . . . . . . 31 7. Considerations about Address Stability . . . . . . . . . . . . 31
8. Considerations about RADIUS Integration . . . . . . . . . . . 31 8. Considerations about RADIUS Integration . . . . . . . . . . . 31
8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 31 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 32
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 31 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 32
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 33
9. Considerations for Maintenance and Statistics . . . . . . . . 32 9. Considerations for Maintenance and Statistics . . . . . . . . 33
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 32 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 33
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 35 13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Introduction 1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol The Softwires Working Group has selected Layer Two Tunneling Protocol
version 2 (L2TPv2) as the phase 1 protocol to be deployed in the version 2 (L2TPv2) as the phase 1 protocol to be deployed in the
Softwires "Hubs and Spokes" solution space. This document describes Softwire "Hubs and Spokes" solution space. This document describes
the framework for the L2TPv2 "Hubs and Spokes" solution, and the the framework for the L2TPv2 "Hubs and Spokes" solution, and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations. to achieve interoperability among different vendor implementations.
In the "Hubs and Spokes" solution space, a Softwire is established to In the "Hubs and Spokes" solution space, a Softwire is established to
provide the home network with IPv4 connectivity across an IPv6-only provide the home network with IPv4 connectivity across an IPv6-only
access network or IPv6 connectivity across an IPv4-only access access network, or IPv6 connectivity across an IPv4-only access
network. When L2TPv2 is used in the Softwire context, the voluntary network. When L2TPv2 is used in the Softwire context, the voluntary
tunneling model applies. The Softwire Initiator (SI) at the home tunneling model applies. The Softwire Initiator (SI) at the home
network takes the role of the L2TP Access Concentrator (LAC) client network takes the role of the L2TP Access Concentrator (LAC) client
(initiating both the L2TP tunnel/session and PPP link) while the (initiating both the L2TP tunnel/session and the PPP link) while the
Softwire Concentrator (SC) at the ISP takes the role of the L2TP Softwire Concentrator (SC) at the ISP takes the role of the L2TP
Network Server (LNS). Since L2TPv2 compulsory tunneling model does Network Server (LNS). Since L2TPv2 compulsory tunneling model does
not apply to Softwires, it should not be requested or honored. This not apply to Softwires, it should not be requested or honored. This
document identifies all the voluntary tunneling related L2TPv2 document identifies all the voluntary tunneling related L2TPv2
attributes that apply to Softwires and specifies the handling attributes that apply to Softwires and specifies the handling
mechanism for such attributes in order to avoid ambiguities in mechanism for such attributes in order to avoid ambiguities in
implementations. This document also identifies the set of L2TPv2 implementations. This document also identifies the set of L2TPv2
attributes specific to compulsory tunneling model that do not apply attributes specific to compulsory tunneling model that do not apply
to Softwires and specifies the mechanism to ignore or nullify their to Softwires and specifies the mechanism to ignore or nullify their
effect within the Softwires context. effect within the Softwire context.
The SI and SC must follow the L2TPv2 operations described in The SI and SC must follow the L2TPv2 operations described in
[RFC2661] when performing Softwire establishment, tear-down and OAM. [RFC2661] when performing Softwire establishment, tear-down and OAM.
With L2TPv2, a Softwire consists of an L2TPv2 Control Channel, a With L2TPv2, a Softwire consists of an L2TPv2 Control Connection
single Session, and the PPP link negotiated over the Session. To (also referred to as Control Channel), a single L2TPv2 Session, and
establish the Softwire, the SI first initiates an L2TPv2 Control the PPP link negotiated over the Session. To establish the Softwire,
Channel to the SC which accepts the request and terminates the the SI first initiates an L2TPv2 Control Channel to the SC which
Control Channel. L2TPv2 supports an optional mutual Control Channel accepts the request and terminates the Control Channel. L2TPv2
authentication which allows both SI and SC to validate each other's supports an optional mutual Control Channel authentication which
identity at the initial phase of hand-shaking before proceeding with allows both SI and SC to validate each other's identity at the
Control Channel establishment. After the L2TPv2 Control Channel is initial phase of hand-shaking before proceeding with Control Channel
established between the SI and SC, the SI initiates an L2TPv2 Session establishment. After the L2TPv2 Control Channel is established
to the SC. Then the PPP/IP link is negotiated over the L2TPv2 between the SI and SC, the SI initiates an L2TPv2 Session to the SC.
Session between the SI and SC. After the PPP/IP link is established, Then the PPP/IP link is negotiated over the L2TPv2 Session between
it acts as the Softwire between the SI and SC for tunneling IP the SI and SC. After the PPP/IP link is established, it acts as the
traffic of one Address Family across the access network of another Softwire between the SI and SC for tunneling IP traffic of one
Address Family. Address Family (AF) across the access network of another Address
Family.
During the life of the Softwire, both SI and SC send L2TPv2 keepalive During the life of the Softwire, both SI and SC send L2TPv2 keepalive
HELLO messages to monitor the health of the Softwire and the peer HELLO messages to monitor the health of the Softwire and the peer
LCCE, and to potentially refresh the NAT/NAPT translation entry at LCCE, and to potentially refresh the NAT/NAPT translation entry at
the CPE or at the other end of the access link. Optionally, LCP ECHO the CPE or at the other end of the access link. Optionally, LCP ECHO
messages can be used as keepalives for the same purposes. In the messages can be used as keepalives for the same purposes. In the
event of keepalive timeout or administrative shutdown of the event of keepalive timeout or administrative shutdown of the
Softwire, either SI or SC may tear down the Softwire by tearing down Softwire, either SI or SC may tear down the Softwire by tearing down
the L2TPv2 Control Channel and Session as specified in [RFC2661]. the L2TPv2 Control Channel and Session as specified in [RFC2661].
1.1. Abbreviations 1.1. Abbreviations
LCCE L2TP Control Connection Endpoint (See [RFC3931]) AF Address Family, IPv4 or IPv6.
SC Softwire Concentrator, the node terminating the Softwire in SC Softwire Concentrator, the node terminating the Softwire in
the service provider network (See [RFC4925]) the service provider network (See [RFC4925]).
SI Softwire Initiator, the node initiating the Softwire within SI Softwire Initiator, the node initiating the Softwire within
the customer network (See [RFC4925]) the customer network (See [RFC4925]).
STH Softwire Transport Header, the outermost IP header of a LCCE L2TP Control Connection Endpoint, an L2TP node that exists at
softwire (See [RFC4925]) either end of an L2TP Control Connection (See [RFC3931]).
SPH Softwire Payload Header, the IP headers being carried within a SPH Softwire Payload Header, the IP headers being carried within a
softwire (See [RFC4925]) softwire (See [RFC4925]).
STH Softwire Transport Header, the outermost IP header of a
softwire (See [RFC4925]).
SW Softwire, a shared-state "tunnel" created between the SC and
SI. (See [RFC4925]).
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
Following is the complete list of contributors to this document. Following is the complete list of contributors to this document.
Maria Alice Dos Santos Maria Alice Dos Santos, Cisco Systems
Carlos Pignataro Carlos Pignataro, Cisco Systems
Bill Storer Bill Storer, Cisco Systems
Cisco Systems Jean-Francois Tremblay, Trellia Networks
Jean-Francois Tremblay Laurent Toutain, GET/ENST Bretagne
Trellia Networks Bruno Stevant, TELECOM Bretagne
Laurent Toutain
Bruno Stevant
GET/ENST Bretagne
1.4. Considerations 1.4. Considerations
Some sections of this document contain considerations that are not Some sections of this document contain considerations that are not
required for interoperability and correct operation of Softwire required for interoperability and correct operation of Softwire
implementations. These sections are marked as "Considerations". implementations. These sections are marked as "Considerations".
2. Applicability of L2TPv2 for Softwire Requirements 2. Applicability of L2TPv2 for Softwire Requirements
A list of Softwire "Hubs and Spokes" requirements have been A list of Softwire "Hubs and Spokes" requirements has been identified
identified by the Softwire Problem Statement [RFC4925]. The by the Softwire Problem Statement [RFC4925]. The following sub-
following section describes how L2TPv2 fulfills each of them. sections describe how L2TPv2 fulfills each of them.
2.1. Network Address Translation (NAT and NAPT) 2.1. Traditional Network Address Translation (NAT and NAPT)
A "Hubs and Spokes" Softwire must be able to traverse Network Address A "Hubs and Spokes" Softwire must be able to traverse Network Address
Translation and Network Address Port Translation (NAT and NAPT) Translation (NAT) and Network Address Port Translation (NAPT, also
devices [RFC3022] in case the scenario in question involves a non- referred to as Port Address Translation or PAT) devices [RFC3022] in
upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some case the scenario in question involves a non-upgradable pre-existing
carrier equipment at the other end of the access link performing NAT/ IPv4 home gateway performing NAT/NAPT or some carrier equipment at
NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is the other end of the access link performing NAT/NAPT. The L2TPv2
capable of NAT/NAPT traversal since L2TPv2 can run over UDP. Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT
traversal since L2TPv2 can run over UDP.
Since L2TPv2 does not "autodetect" NAT/NAPT along the path, L2TPv2 Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not
does not offer UDP bypass regardless of NAT/NAPT presence. Both NAT/ offer the option of disabling UDP. The UDP encapsulation is present
NAPT "autodetect" and UDP bypass are optional requirements. regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP
"bypass" are optional requirements in Section 2.3 of [RFC4925].
2.2. Scalability 2.2. Scalability
In the "Hubs and Spokes" model, a carrier must be able to scale the In the "Hubs and Spokes" model, a carrier must be able to scale the
solution to millions of Softwire initiators by adding more hubs solution to millions of Softwire Initiators by adding more hubs
(i.e., Softwire concentrators). L2TPv2 is a widely deployed protocol (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol
in broadband services, and its scalability has been proven in in broadband services, and its scalability has been proven in
multiple large-scale IPv4 Virtual Private Network deployments which multiple large-scale IPv4 Virtual Private Network deployments which
scale up to millions of subscribers each. scale up to millions of subscribers each.
2.3. Multicast 2.3. Routing
There are no dynamic routing protocols between the SC and SI. A
default route from the SI to the SC is used.
2.4. Multicast
Multicast protocols simply run over L2TPv2 Softwires transparently Multicast protocols simply run over L2TPv2 Softwires transparently
together with other regular IP traffic. together with other regular IP traffic.
2.4. Authentication, Authorization and Accounting 2.5. Authentication, Authorization and Accounting (AAA)
L2TPv2 supports optional mutual Control Channel authentication and L2TPv2 supports optional mutual Control Channel authentication and
leverages the optional mutual PPP per-session authentication. L2TPv2 leverages the optional mutual PPP per-session authentication. L2TPv2
is well integrated with AAA solutions (such as RADIUS) for both is well integrated with AAA solutions (such as RADIUS) for both
authentication and authorization. Most L2TPv2 implementations authentication and authorization. Most L2TPv2 implementations
available in the market support logging of authentication and available in the market support logging of authentication and
authorization events. authorization events.
L2TPv2 integration with RADIUS accounting (RADIUS Accounting L2TPv2 integration with RADIUS accounting (RADIUS Accounting
extension for tunnel [RFC2867]) allows the collection and reporting extension for tunnel [RFC2867]) allows the collection and reporting
of L2TPv2 Softwire usage statistics. of L2TPv2 Softwire usage statistics.
2.5. Privacy, Integrity, and Replay Protection 2.6. Privacy, Integrity, and Replay Protection
Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec ESP can
be used in conjunction to provide per-packet authentication, be used in conjunction to provide per-packet authentication,
integrity, replay protection and confidentiality for both L2TPv2 integrity, replay protection and confidentiality for both L2TPv2
control and data traffic [RFC3193] and [RFC3948]. control and data traffic [RFC3193] and [RFC3948].
For Softwire deployments in which full payload security is not For Softwire deployments in which full payload security is not
required, the L2TPv2 built-in Control Channel authentication and the required, the L2TPv2 built-in Control Channel authentication and the
inherited PPP authentication and PPP Encryption Control Protocol can inherited PPP authentication and PPP Encryption Control Protocol can
be considered. be considered.
2.6. Operations and Management (OAM) 2.7. Operations and Management (OAM)
L2TPv2 supports an optional in-band keepalive mechanism which injects L2TPv2 supports an optional in-band keepalive mechanism which injects
HELLO control messages after a specified period of time has elapsed HELLO control messages after a specified period of time has elapsed
since the last data or control message was received on a tunnel. If since the last data or control message was received on a tunnel (see
the HELLO control message is not reliably delivered, then the Control Section 5.5 of [RFC2661]). If the HELLO control message is not
Channel and its session will be torn down. In the Softwire context, reliably delivered, then the Control Channel and its Session will be
the L2TPv2 keepalive is used to monitor the connectivity status torn down. In the Softwire context, the L2TPv2 keepalive is used to
between the SI and SC and/or as a refresh mechanism for any NAT/NAPT monitor the connectivity status between the SI and SC and/or as a
translation entry along the access link. refresh mechanism for any NAT/NAPT translation entry along the access
link.
LCP ECHO offers a similar mechanism to monitor the connectivity LCP ECHO offers a similar mechanism to monitor the connectivity
status, as described in [RFC1661]. Softwires implementations SHOULD status, as described in [RFC1661]. Softwire implementations SHOULD
use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo
messages to ensure Dead End Detection and/or to refresh NAT/NAPT messages to ensure Dead End Detection and/or to refresh NAT/NAPT
translation entries. The combination of these two mechanisms can be translation entries. The combination of these two mechanisms can be
used as an optimization. used as an optimization.
L2TPv2 MIB [RFC3371] supports the complete suite of management L2TPv2 MIB [RFC3371] supports the complete suite of management
operations such as configuration of Control Channel and Session, operations such as configuration of Control Channel and Session,
polling of Control Channel and Session status and their traffic polling of Control Channel and Session status and their traffic
statistics and notifications of Control Channel and Session UP/DOWN statistics and notifications of Control Channel and Session UP/DOWN
events. events.
2.7. Encapsulations 2.8. Encapsulations
L2TPv2 supports the following encapsulations: L2TPv2 supports the following encapsulations:
o IPv6/PPP/L2TPv2/UDP/IPv4 o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv6 o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv4 o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6 o IPv6/PPP/L2TPv2/UDP/IPv6
skipping to change at page 9, line 14 skipping to change at page 9, line 28
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not
support "autodetect" of NAT/NAPT. support "autodetect" of NAT/NAPT.
3. Deployment Scenarios 3. Deployment Scenarios
For the "Hubs and Spokes" problem space, four scenarios have been For the "Hubs and Spokes" problem space, four scenarios have been
identified. In each of these four scenarios, different home identified. In each of these four scenarios, different home
equipment plays the role of the Softwire Initiator. This section equipment plays the role of the Softwire Initiator. This section
elaborates each scenario with L2TPv2 as the Softwire protocol and elaborates each scenario with L2TPv2 as the Softwire protocol and
other possible protocols involved to complete the solution. This other possible protocols involved to complete the solution. This
section examines the four scenarios for both IPv6 over IPv4 and IPv4 section examines the four scenarios for both IPv6 over IPv4
over IPv6 encapsulations. (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations.
3.1. IPv6 over IPv4 Softwire with L2TPv2 3.1. IPv6 over IPv4 Softwires with L2TPv2
The following subsections cover IPv6 connectivity across an IPv4-only The following subsections cover IPv6 connectivity (SPH) across an
access network (STH) using a Softwire. IPv4-only access network (STH) using a Softwire.
3.1.1. Host CPE as Softwire Initiator 3.1.1. Host CPE as Softwire Initiator
The Softwire Initiator (SI) is the host CPE (directly connected to a The Softwire Initiator (SI) is the host CPE (directly connected to a
modem), which is dual-stack. There is no other gateway device. The modem), which is dual-stack. There is no other gateway device. The
IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1. IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------| |------------------||-----------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | T | | | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| host CPE | E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE |
R [network] | | [ network ] | | R [network] | | [ network ] | |
N | LNS | |LAC Client| N | LNS | |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH) PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire Softwire
<------------------> <------------------>
IPV6CP: capable of /64 Intf-Id assignment or IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check uniqueness check
|------------------>/64 prefix |------------------>/64 prefix
RA RA
|------------------>DNS, etc. |------------------>DNS, etc.
DHCPv6/v4 DHCPv6
Figure 1: Host CPE as Softwire Initiator Figure 1: Host CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign the 64-bit Interface-Identifier establishment and PPP LCP negotiation (and optionally PPP
to the host CPE or perform uniqueness validation for the two Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is also provides the capability for the ISP to assign the 64-bit
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS Interface-Identifier to the host CPE or perform uniqueness validation
can assign a 64-bit global prefix to the host CPE via Router for the two interface identifiers at the two PPP ends [RFC5072].
Advertisement (RA) while other configuration options (such as DNS) After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration /
can be conveyed to the host CPE via DHCPv6/v4. Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
inform the host CPE of a prefix to use for stateless address
autoconfiguration through a Router Advertisement (RA) while other
nonaddress configuration options (such as DNS [RFC3646] or other
servers' addresses that might be available) can be conveyed to the
host CPE via DHCPv6.
3.1.2. Router CPE as Softwire Initiator 3.1.2. Router CPE as Softwire Initiator
The Softwire Initiator (SI) is the router CPE, which is a dual-stack The Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv4 traffic SHOULD NOT traverse the Softwire. See device. The IPv4 traffic SHOULD NOT traverse the Softwire. See
Figure 2. Figure 2.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||---------------------| |------------------||-----------------||---------------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | +-----+ T | | | v4/v6 | +-----+
E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| CPE |----|v4/v6| E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6|
R [network] | | [ network ] | | | host| R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+ N | LNS | |LAC Client| +-----+
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic ()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH) PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire Softwire
<------------------> <------------------>
IPV6CP: capable of /64 Intf-Id assignment or IPV6CP: capable of /64 Intf-Id assignment or
skipping to change at page 11, line 36 skipping to change at page 11, line 36
|------------------>/48 prefix, |------------------>/48 prefix,
DHCPv6 DNS, etc. DHCPv6 DNS, etc.
|------->/64 prefix |------->/64 prefix
RA RA
|-------> DNS, etc. |-------> DNS, etc.
DHCPv4/v6 DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator Figure 2: Router CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign the 64-bit Interface-Identifier establishment and PPP LCP negotiation (and optionally PPP
to the router CPE or perform uniqueness validation for the two Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is also provides the capability for the ISP to assign the 64-bit
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS Interface-Identifier to the router CPE or perform uniqueness
can assign a 64-bit global prefix to the router CPE via Router validation for the two interface identifiers at the two PPP ends
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address
Delegation (e.g., delegating a 48-bit prefix to be used within the Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP
home network) and convey other configuration options (such as DNS) to link, and the LNS can inform the router CPE of a prefix to use for
the router CPE. stateless address autoconfiguration through a Router Advertisement
(RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g.,
delegating a prefix to be used within the home network [RFC3633]) and
convey other nonaddress configuration options (such as DNS [RFC3646])
to the router CPE.
3.1.3. Host behind CPE as Softwire Initiator 3.1.3. Host behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The
IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------| |------------------||----------------------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....|v4-only|--| host | E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host |
R [network] | | [ network ] | CPE | | | R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client| N | LNS | +-------+ |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH) Softwire (SPH)
<------------------------------> <------------------------------>
IPV6CP: capable of /64 Intf-Id assignment or IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check uniqueness check
|------------------------------>/64 prefix |------------------------------>/64 prefix
RA RA
|------------------------------>DNS, etc. |------------------------------>DNS, etc.
DHCPv4/v6 DHCPv6
Figure 3: Host behind CPE as Softwire Initiator Figure 3: Host behind CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign the 64-bit Interface-Identifier establishment and PPP LCP negotiation (and optionally PPP
to the host or perform uniqueness validation for the two Interface- Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is up, also provides the capability for the ISP to assign the 64-bit
Interface-Identifier to the host or perform uniqueness validation for
the two interface identifiers at the two PPP ends [RFC5072]. After
IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration /
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can 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 inform the host of a prefix to use for stateless address
(RA) while other configuration options (such as DNS) can be conveyed autoconfiguration through a Router Advertisement (RA) while other
to the host via DHCPv6/v4. nonaddress configuration options (such as DNS [RFC3646]) can be
conveyed to the host via DHCPv6.
3.1.4. Router behind CPE as Softwire Initiator 3.1.4. Router behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside
the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. the home network. The IPv4 traffic SHOULD NOT traverse the Softwire.
See Figure 4. See Figure 4.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||-------------------------||-------------| |------------------||-------------------------||-------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|..[IPv4~only]..|v4-only|---| router | E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router |
R [network] | | [ network ] | CPE | | | | R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client| N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+ E +-----+ | +----------+
T | T |
---------+-----+ ---------+-----+
|v4/v6| |v4/v6|
| host| | host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic PPP o L2TPv2 o UDP o IPv4 traffic
skipping to change at page 13, line 36 skipping to change at page 13, line 43
uniqueness check uniqueness check
|--------------------------->/64 prefix |--------------------------->/64 prefix
RA RA
|--------------------------->/48 prefix, |--------------------------->/48 prefix,
DHCPv6 DNS, etc. DHCPv6 DNS, etc.
|----> /64 |----> /64
RA prefix RA prefix
|----> DNS, |----> DNS,
DHCPv4/v6 etc. DHCPv6 etc.
Figure 4: Router behind CPE as Softwire Initiator Figure 4: Router behind CPE as Softwire Initiator
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign the 64-bit Interface-Identifier establishment and PPP LCP negotiation (and optionally PPP
to the v4/v6 router or perform uniqueness validation for the two Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
Interface-IDs at the two PPP ends [RFC5072]. After IPv6 over PPP is also provides the capability for the ISP to assign the 64-bit
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS Interface-Identifier to the v4/v6 router or perform uniqueness
can assign a 64-bit global prefix to the v4/v6 router via Router validation for the two interface identifiers at the two PPP ends
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address
Delegation (e.g., delegating a 48-bit prefix to be used within the Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP
home network) and convey other configuration options (such as DNS) to link, and the LNS can inform the v4/v6 router of a prefix to use for
the v4/v6 router. stateless address autoconfiguration through a Router Advertisement
(RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g.,
delegating a prefix to be used within the home network [RFC3633]) and
convey other nonaddress configuration options (such as DNS [RFC3646])
to the v4/v6 router.
3.2. IPv4 over IPv6 Softwire with L2TPv2 3.2. IPv4 over IPv6 Softwires with L2TPv2
The following subsections cover IPv4 connectivity across an IPv6-only The following subsections cover IPv4 connectivity (SPH) across an
access network (STH) using a Softwire. IPv6-only access network (STH) using a Softwire.
3.2.1. Host CPE as Softwire Initiator 3.2.1. Host CPE as Softwire Initiator
The Softwire Initiator (SI) is the host CPE (directly connected to a The Softwire Initiator (SI) is the host CPE (directly connected to a
modem), which is dual-stack. There is no other gateway device. The modem), which is dual-stack. There is no other gateway device. The
IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5. IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||---------| |------------------||-----------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | T | | | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| host CPE | E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE |
R [network] | | [ network ] | | R [network] | | [ network ] | |
N | LNS | |LAC Client| N | LNS | |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH) PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire Softwire
<------------------> <------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
and DNS, etc. and DNS, etc.
Figure 5: Host CPE as Softwire Initiator Figure 5: Host CPE as Softwire Initiator
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign a global IPv4 address to the establishment and PPP LCP negotiation (and optionally PPP
host CPE. A global IPv4 address can also be assigned via DHCP. Authentication) are successful, IPCP negotiates IPv4 over PPP which
Other configuration options (such as DNS) can be conveyed to the host also provides the capability for the ISP to assign a global IPv4
CPE via IPCP [RFC1877] or DHCP. address to the host CPE. A 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 [RFC2132].
3.2.2. Router CPE as Softwire Initiator 3.2.2. Router CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The IPv4 connectivity across an IPv6-only access network (STH). The
Softwire Initiator (SI) is the router CPE, which is a dual-stack Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv6 traffic SHOULD NOT traverse the Softwire. See device. The IPv6 traffic SHOULD NOT traverse the Softwire. See
Figure 6. Figure 6.
IPv4 or dual-stack IPv6-only dual-stack Home IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------| |------------------||-----------------||-------------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | +-----+ T | | | v4/v6 | +-----+
E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| CPE |--|v4/v6| E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6|
R [network] | | [ network ] | | | host| R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+ N | LNS | |LAC Client| +-----+
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH) PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire Softwire
<------------------> <------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
skipping to change at page 15, line 34 skipping to change at page 15, line 43
|------------------> |------------------>
DHCPv4: prefix, mask, PD DHCPv4: prefix, mask, PD
private/ private/
|------> global |------> global
DHCP IP, DNS, DHCP IP, DNS,
etc. etc.
Figure 6: Router CPE as Softwire Initiator Figure 6: Router CPE as Softwire Initiator
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign a global IPv4 address to the establishment and PPP LCP negotiation (and optionally PPP
router CPE. A global IPv4 address can also be assigned via DHCP. Authentication) are successful, IPCP negotiates IPv4 over PPP which
Other configuration options (such as DNS) can be conveyed to the also provides the capability for the ISP to assign a global IPv4
router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation address to the router CPE. A global IPv4 address can also be
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. assigned via DHCP. Other configuration options (such as DNS) can be
conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For
IPv4 Prefix Delegation for the home network, DHCP
[I-D.ietf-dhc-subnet-alloc] can be used.
3.2.3. Host behind CPE as Softwire Initiator 3.2.3. Host behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. The Softwire Initiator (SI) is a dual-stack host is IPv6-only. The Softwire Initiator (SI) is a dual-stack host
(behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6
traffic SHOULD NOT traverse the Softwire. See Figure 7. traffic SHOULD NOT traverse the Softwire. See Figure 7.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------| |------------------||----------------------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....|v6-only|--| host | E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host |
R [network] | | [ network ] | CPE | | | R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client| N | LNS | +-------+ |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
PPP o L2TPv2 o UDP o IPv6 traffic PPP o L2TPv2 o UDP o IPv6 traffic
Softwire (SPH) Softwire (SPH)
<------------------------------> <------------------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
and DNS, etc. and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiator Figure 7: Host behind CPE as Softwire Initiator
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign a global IPv4 address to the establishment and PPP LCP negotiation (and optionally PPP
host. A global IPv4 address can also be assigned via DHCP. Other Authentication) are successful, IPCP negotiates IPv4 over PPP which
configuration options (such as DNS) can be conveyed to the host CPE also provides the capability for the ISP to assign a global IPv4
via IPCP [RFC1877] or DHCP. address to the host. A 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 [RFC2132].
3.2.4. Router 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 IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. The Softwire Initiator (SI) is a dual-stack device is IPv6-only. The Softwire Initiator (SI) is a dual-stack device
(behind the IPv6-only CPE) acting as an IPv4 CPE router inside the (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the
home network. The IPv6 traffic SHOULD NOT traverse the Softwire. home network. The IPv6 traffic SHOULD NOT traverse the Softwire.
See Figure 8. See Figure 8.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------| |------------------||-------------------------||------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|..[IPv6~only]..|v6-only|---| router | E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router |
R [network] | | [ network ] | CPE | | | | R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client| N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+ E +-----+ | +----------+
T | T |
--------+-----+ --------+-----+
|v4/v6| |v4/v6|
| host| | host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
PPP o L2TPv2 o UDP o IPv4 traffic PPP o L2TPv2 o UDP o IPv4 traffic
skipping to change at page 17, line 37 skipping to change at page 17, line 37
|---------------------------> |--------------------------->
DHCPv4: prefix, mask, PD DHCPv4: prefix, mask, PD
private/ private/
|----> global |----> global
DHCP IP, DNS, DHCP IP, DNS,
etc. etc.
Figure 8: Router behind CPE as Softwire Initiator Figure 8: Router behind CPE as Softwire Initiator
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, after the L2TPv2 Control Channel and Session
the capability for the ISP to assign a global IPv4 address to the establishment and PPP LCP negotiation (and optionally PPP
v4/v6 router. A global IPv4 address can also be assigned via DHCP. Authentication) are successful, IPCP negotiates IPv4 over PPP which
Other configuration options (such as DNS) can be conveyed to the also provides the capability for the ISP to assign a global IPv4
v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation address to the v4/v6 router. A global IPv4 address can also be
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. assigned via DHCP. Other configuration options (such as DNS) can be
conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132].
For IPv4 Prefix Delegation for the home network, DHCP
[I-D.ietf-dhc-subnet-alloc] can be used.
4. Standardisation Status 4. Standardization Status
This section groups various Internet standards documents and other This section groups various Internet standards documents and other
publications used in Softwires. publications used in Softwires.
4.1. L2TPv2 4.1. L2TPv2
RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661]. RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661].
* For both IPv4 and IPv6 payloads (SPH), support is * For both IPv4 and IPv6 payloads (SPH), support is
complete. complete.
* For both IPv4 and IPv6 transports (STH), support is * For both IPv4 and IPv6 transports (STH), support is
complete. complete.
4.2. Securing the Softwire Transport 4.2. Securing the Softwire Transport
RFC 3193 "Securing L2TP using IPsec" [RFC3193]. RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948]. RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
* IPSec supports both IPv4 and IPv6 transports. * IPsec supports both IPv4 and IPv6 transports.
4.3. Authentication Authorization Accounting 4.3. Authentication Authorization Accounting
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
[RFC2865]. [RFC2865].
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
Support" [RFC2867]. Support" [RFC2867].
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
skipping to change at page 19, line 11 skipping to change at page 19, line 11
RFC 4087 "IP Tunnel MIB" [RFC4087]. RFC 4087 "IP Tunnel MIB" [RFC4087].
* Both IPv4 and IPv6 transports are supported. * Both IPv4 and IPv6 transports are supported.
4.5. Softwire Payload Related 4.5. Softwire Payload Related
4.5.1. For IPv6 Payloads 4.5.1. For IPv6 Payloads
RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861]. RFC 4861 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC4861].
RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862].
RFC 5072 "IP Version 6 over PPP" [RFC5072]. RFC 5072 "IP Version 6 over PPP" [RFC5072].
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315]. [RFC3315].
RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6" [RFC3633].
RFC 3646 "DNS Configuration options for Dynamic Host Configuration RFC 3646 "DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)" [RFC3646]. Protocol for IPv6 (DHCPv6)" [RFC3646].
RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6" [RFC3736].
4.5.2. For IPv4 Payloads 4.5.2. For IPv4 Payloads
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)"
[RFC1332]. [RFC1332].
RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661]. RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
RFC 1877 "PPP Internet Protocol Control Protocol Extensions for RFC 1877 "PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses" [RFC1877]. Name Server Addresses" [RFC1877].
RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131].
RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132].
DHCP Subnet Allocation "Subnet Allocation Option". DHCP Subnet Allocation "Subnet Allocation Option".
* Work in progress, see [I-D.ietf-dhc-subnet-alloc]. * Work in progress, see [I-D.ietf-dhc-subnet-alloc].
5. Softwire Establishment 5. Softwire Establishment
A Softwire is established in three distinct steps (see Figure 9). A Softwire is established in three distinct steps (see Figure 9).
First an L2TPv2 tunnel with a single session is established from the First an L2TPv2 tunnel with a single session is established from the
SI to the SC. Second a PPP session is established over the L2TPv2 SI to the SC. Second a PPP session is established over the L2TPv2
session and the SI obtains an address. Third the SI optionally gets session and the SI obtains an address. Third the SI optionally gets
skipping to change at page 20, line 20 skipping to change at page 20, line 21
|<-------------PPP--------------->| Step 2 |<-------------PPP--------------->| Step 2
|<----End Point Configuration---->| PPP and End Point |<----End Point Configuration---->| PPP and End Point
| | configuration | | configuration
| | | |
|<------Router Configuration----->| Step 3 |<------Router Configuration----->| Step 3
| | Additional configuration | | Additional configuration
| | (optional) | | (optional)
Figure 9: Steps for the Establishment of a Softwire Figure 9: Steps for the Establishment of a Softwire
In the following diagram (see Figure 10), each of the three steps Figure 10 depicts details of each of the three steps required to
required to establish a Softwire is described in detail. establish a Softwire.
SC SI SC SI
| | | |
| | Step 1 | | Step 1
|<------------SCCRQ---------------| - |<------------SCCRQ---------------| -
|-------------SCCRP-------------->| | |-------------SCCRP-------------->| |
|<------------SCCCN---------------| | |<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2 |<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| | |-------------ICRP--------------->| |
|<------------ICCN----------------| - |<------------ICCN----------------| -
| | | |
| | Step 2 | | Step 2
|<-----Configuration-Request------| - |<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP |------Configuration-Request----->| | PPP
|<-------Configuration-Ack--------| | LCP |--------Configuration-Ack------->| | LCP
|--------Configuration-Ack------->| - |<-------Configuration-Ack--------| -
| | | |
|-----------Challenge------------>| - PPP Authentication |-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP) |<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| - |------------Success------------->| -
| | | |
|<-----Configuration-Request------| - |<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP |------Configuration-Request----->| | PPP NCP
|<-------Configuration-Ack--------| | (IPV6CP or IPCP) |--------Configuration-Ack------->| | (IPV6CP or IPCP)
|--------Configuration-Ack------->| - |<-------Configuration-Ack--------| -
| | | |
|<------Router-Solicitation-------| - Neighbor Discovery |<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only) |-------Router-Advertisement----->| | (IPv6 only)
| | - | | -
| | | |
| | Step3 | | Step3
|<-----------Solicit--------------| - | | DHCP (Optional)
|-----------Advertise------------>| | DHCP |<-----------SOLICIT--------------| -
|<---------- Request--------------| | (Optional) |-----------ADVERTISE------------>| | DHCPv6
|-------------Reply-------------->| - |<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| -
| | or
|<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire Figure 10: Detailed Steps in the Establishment of a Softwire
The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4
Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP
negitiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and
DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over
IPv4 Softwires, the DHCPv6 exchange for nonaddress configuration
(such as DNS) can use a two message exchange with Information-Request
and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]).
5.1. L2TPv2 Tunnel Setup 5.1. L2TPv2 Tunnel Setup
L2TPv2 [RFC2661] was originally designed to provide private network L2TPv2 [RFC2661] was originally designed to provide private network
access to end users connected to a public network. In the L2TPv2 access to end users connected to a public network. In the L2TPv2
model, the end user makes a connection to an L2TP Access Concentrator incoming call model, the end user makes a connection to an L2TP
(LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel
Server (LNS). The LNS then transfers end user traffic between the to an L2TP Network Server (LNS). The LNS then transfers end user
L2TPv2 tunnel and the private network. traffic between the L2TPv2 tunnel and the private network.
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
assumes the role of the LAC and the Softwire Concentrator assumes the assumes the role of the LAC Client and the Softwire Concentrator (SC)
role of the LNS. assumes the role of the LNS.
In the Softwire model, an L2TPv2 packet MUST be carried over UDP. In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
The underlying version of the IP protocol may be IPv4 or IPv6, The underlying version of the IP protocol may be IPv4 or IPv6,
depending on the Softwires scenario. depending on the Softwire scenario.
In the following sections, the term "Tunnel" follows the definition In the following sections, the term "Tunnel" follows the definition
from [RFC2661], namely: "The Tunnel consists of a Control Connection from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a
and zero or more L2TP Sessions". Control Connection and zero or more L2TP Sessions".
5.1.1. Tunnel Establishment 5.1.1. Tunnel Establishment
Figure 11 describes the messages exchanged and AVPs used to establish Figure 11 describes the messages exchanged and Attribute Value Pairs
a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs (AVPs) used to establish a tunnel between an SI (LAC) and an SC
described here are only a subset of those defined in [RFC2661]. This (LNS). The messages and AVPs described here are only a subset of
is because Softwires uses only a subset of the L2TPv2 functionality. those defined in [RFC2661]. This is because Softwires use only a
The subset of L2TP Control Connection Management AVPs that is subset of the L2TPv2 functionality. The subset of L2TP Control
applicable to Softwires is grouped into Mandatory AVPs and Optional Connection Management AVPs that is applicable to Softwires is grouped
AVPs (see Figure 11). Note that in the Softwires environment, the SI into Mandatory AVPs and Optional AVPs (see Figure 11). Note that in
always initiates the tunnel. L2TPv2 attributes SHOULD NOT be hidden. the Softwire environment, the SI always initiates the tunnel. L2TPv2
AVPs SHOULD NOT be hidden.
SCCRQ SC SI
Mandatory AVP |<--------SCCRQ---------|
Mandatory AVPs:
Message Type Message Type
Protocol Version Protocol Version
Host Name Host Name
Framing Capabilities Framing Capabilities
Assigned Tunnel ID Assigned Tunnel ID
Optional AVP: Optional AVPs:
Receive Window Size Receive Window Size
Challenge
Firmware Revision Firmware Revision
Vendor Name Vendor Name
Challenge
SCCRP |---------SCCRP-------->|
Mandatory AVP: Mandatory AVPs:
Message Type Message Type
Protocol Version Protocol Version
Framing Capabilities Framing Capabilities
Host Name Host Name
Assigned Tunnel ID Assigned Tunnel ID
Optional AVP: Optional AVPs:
Firmware Revision Firmware Revision
Vendor Name Vendor Name
Receive Window Size Receive Window Size
Challenge Response
Challenge Challenge
Challenge Response
SCCCN |<--------SCCCN---------|
Mandatory AVP: Mandatory AVPs:
Message Type Message Type
Optional AVP: Optional AVPs:
Challenge Response Challenge Response
Figure 11: Control Connection Establishment Figure 11: Control Connection Establishment
In L2TPv2, the tunnel between an LAC and LNS may carry the data of In L2TPv2, generally, the tunnel between an LAC and LNS may carry the
multiple users. Each of these user's is represented by an L2TPv2 data of multiple users. Each of these users is represented by an
session within the tunnel. In the Softwires environment, the tunnel L2TPv2 session within the tunnel. In the Softwire environment, the
carries the information of a single user. So, there is only one tunnel carries the information of a single user. Consequently, there
L2TPv2 session per tunnel. Figure 12 describes the messages is only one L2TPv2 session per tunnel. Figure 12 describes the
exchanged and the AVPs used to establish a session between an SI messages exchanged and the AVPs used to establish a session between
(LAC) and an SC (LNS). The messages and AVPs described here are only an SI (LAC) and an SC (LNS). The messages and AVPs described here
a subset of those defined in [RFC2661]. This is because Softwires are only a subset of those defined in [RFC2661]. This is because
uses only a subset of the L2TPv2 functionality. The subset of L2TP Softwires use only a subset of the L2TPv2 functionality. The subset
Call Management AVPs that is applicable to Softwires is grouped into of L2TP Call Management AVPs that is applicable to Softwires is
Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the grouped into Mandatory AVPs and Optional AVPs (see Figure 12). Note
Softwires environment, the SI always initiates the session. No that in the Softwire environment, the SI always initiates the
outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT session. No outgoing or analog calls are permitted. L2TPv2 AVPs
be hidden. SHOULD NOT be hidden.
ICRQ SC SI
Mandatory AVP: |<--------ICRQ---------|
Mandatory AVPs:
Message Type Message Type
Assigned Session ID Assigned Session ID
Call Serial Number Call Serial Number
ICRP |---------ICRP-------->|
Mandatory AVP: Mandatory AVPs:
Message Type Message Type
Assigned Session ID Assigned Session ID
ICCN |<--------ICCN---------|
Mandatory AVP: Mandatory AVPs:
Message Type Message Type
(Tx) Connect Speed (Tx) Connect Speed
Framing Type Framing Type
Figure 12: Session Establishment Figure 12: Session Establishment
5.1.1.1. AVPs Required for Softwires 5.1.1.1. AVPs Required for Softwires
This section prescribes specific values for AVPs used in the This section prescribes specific values for AVPs used in the Softwire
Softwires context that are Mandatory. context that are Mandatory.
Host Name AVP Host Name AVP
This AVP is mandatory and is present in SCCRQ and SCCRP messages. This AVP is mandatory in SCCRQ and SCCRP messages. This AVP may
This AVP may be used to authenticate users, in which case it would be used to authenticate users, in which case it would contain a
contain a user identification. If this AVP is not used to user identification. If this AVP is not used to authenticate
authenticate users, it may be used for logging purposes. users, it may be used for logging purposes.
Framing Capabilities AVP Framing Capabilities AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. Both the synchronous (S) and asynchronous (A) bits SHOULD be set
This AVP SHOULD be ignored by the receiver. to 1. This AVP SHOULD be ignored by the receiver.
Framing Type AVP Framing Type AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. The synchronous bit SHOULD be set to 1 and the asynchronous bit to
This AVP SHOULD be ignored by the receiver. 0. This AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed (Tx) Connect Speed
(Tx) Connect Speed is a mandatory AVP but is not meaningful in the (Tx) Connect Speed is a mandatory AVP but is not meaningful in the
Softwires context. It SHOULD be left to 0 and ignored by the Softwire context. Its value SHOULD be set to 0 and ignored by the
receiver. receiver.
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call
Serial Number AVP, and Assigned Session ID AVP Serial Number AVP, and Assigned Session ID AVP
As defined in [RFC2661] As defined in [RFC2661].
5.1.1.2. AVPs Optional for Softwires 5.1.1.2. AVPs Optional for Softwires
This section prescribes specific values for AVPs used in the This section prescribes specific values for AVPs used in the Softwire
Softwires context that are Optional. context that are Optional.
Challenge AVP and Challenge Response AVP Challenge AVP and Challenge Response AVP
These AVPs are not required, but are necessary to implement tunnel These AVPs are not required, but are necessary to implement tunnel
authentication. Since tunnel authentication happens at the authentication. Since tunnel authentication happens at the
beginning of L2TPv2 tunnel creation, it can be helpful in beginning of L2TPv2 tunnel creation, it can be helpful in
preventing DoS attacks. preventing DoS attacks. See Section 5.1.1 of [RFC2661].
The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD
be implemented in the SC.
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP
As defined in [RFC2661] As defined in [RFC2661].
5.1.1.3. AVPs not Relevant for Softwires 5.1.1.3. AVPs not Relevant for Softwires
L2TPv2 specifies numerous AVPs that, while allowed for a given L2TPv2 specifies numerous AVPs that, while allowed for a given
command, are irrelevant to a Softwires. Softwires implementations message, are irrelevant to Softwires. Softwire implementations
SHOULD NOT send these AVPs. However, they SHOULD ignore them when SHOULD NOT send these AVPs. However, they SHOULD ignore them when
they are received. This will make it easier to create Softwires they are received. This will simplify the creation of Softwire
applications on top of existing L2TPv2 implementations. applications that build upon existing L2TPv2 implementations.
5.1.2. Tunnel Maintenance 5.1.2. Tunnel Maintenance
Periodically, the SI MUST transmit a message to the SC to maintain Periodically, the SI/SC MUST transmit a message to the peer to detect
NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2
message provides a simple, low overhead method of doing this. HELLO message provides a simple, low overhead method of doing this.
The default values specified in [RFC2661] for L2TPv2 HELLO messages The default values specified in [RFC2661] for L2TPv2 HELLO messages
could result in a dead end detection time of 83 seconds. Although could result in a dead end detection time of 83 seconds. Although
these retransmission timers and counters SHOULD be configurable (see these retransmission timers and counters SHOULD be configurable (see
Section 5.8 of [RFC2661]), these values may not be adapted for all Section 5.8 of [RFC2661]), these values may not be adapted for all
situations, where a quicker dead end detection is required, or where situations, where a quicker dead end detection is required, or where
NAT/NAPT context needs to be refreshed more frequently. In such NAT/NAPT context needs to be refreshed more frequently. In such
cases, the SI MAY use, in combination with L2TPv2 HELLO, LCP ECHO cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO
messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. messages (Echo-Request and Echo-Reply codes) described in [RFC1661].
When used, LCP ECHO messages SHOULD have a re-emission timer lower When used, LCP ECHO messages SHOULD have a re-emission timer lower
than the value for L2TPv2 HELLO hello messages. The default value than the value for L2TPv2 HELLO hello messages. The default value
recommended in Section 6.5 of [RFC2661] for the HELLO message recommended in Section 6.5 of [RFC2661] for the HELLO message
retransmission interval is 60 seconds. When used, a set of suggested retransmission interval is 60 seconds. When used, a set of suggested
values (included here only for guidance) for the LCP ECHO message values (included here only for guidance) for the LCP ECHO message
request interval is a default of 30 seconds, a minimum of 10 seconds, request interval is a default of 30 seconds, a minimum of 10 seconds,
and a maximum of the lesser of the configured L2TPv2 HELLO and a maximum of the lesser of the configured L2TPv2 HELLO
retransmisison interval and 60 seconds. retransmisison interval and 60 seconds.
5.1.3. Tunnel Teardown 5.1.3. Tunnel Teardown
Either the SI or SC can teardown the session and tunnel. This is Either the SI or SC can teardown the session and tunnel. This is
done as specified in [RFC2661]. There is no action specific to done as specified in Section 5.7 of [RFC2661], by sending a StopCCN
Softwires in this case. control message. There is no action specific to Softwires in this
case.
5.2. PPP Connection 5.2. PPP Connection
This section describes the PPP negotiations between the SI and SC in
the Softwire context.
5.2.1. MTU 5.2.1. MTU
The MTU of the PPP link SHOULD be the link MTU minus the size of the The MTU of the PPP link presented to the SPH SHOULD be the link MTU
IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an minus the size of the IP, UDP, L2TPv2, and PPP headers together. On
MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460 an IPv4 link with an MTU equal to 1500 bytes, this could tipically
bytes. When the link is managed by IPsec, this MTU should be lowered mean a PPP MTU of 1460 bytes. When the link is managed by IPsec,
to take into account the ESP encapsulation (see this MTU should be lowered to take into account the ESP encapsulation
[I-D.ietf-softwire-security-requirements]). The value for the MTU (see [I-D.ietf-softwire-security-requirements]). The value for the
may also vary according to the size of the L2TP header, as defined by MTU may also vary according to the size of the L2TP header, as
the leading bits of the L2TP message header (see [RFC2661]). defined by the leading bits of the L2TP message header (see
Additionally, see [RFC4623] for a detailed discussion of [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of
fragmentation issues. fragmentation issues.
5.2.2. LCP 5.2.2. LCP
Once the L2TPv2 session is established, the SI and SC initiate the Once the L2TPv2 session is established, the SI and SC initiate the
PPP connection by negotiating LCP as described in [RFC1661]. The PPP connection by negotiating LCP as described in [RFC1661]. The
Address-and-Control-Field-Compression configuration option (ACFC) Address-and-Control-Field-Compression configuration option (ACFC)
[RFC1661] SHOULD be rejected. [RFC1661] MAY be rejected.
5.2.3. Authentication 5.2.3. Authentication
After completing LCP negotiation, the SI and SC may optionally After completing LCP negotiation, the SI and SC may optionally
perform authentication. If authentication is chosen, CHAP [RFC1994] perform authentication. If authentication is chosen, CHAP [RFC1994]
authentication MUST be supported by both the Softwire Initiator and authentication MUST be supported by both the Softwire Initiator and
Softwire Concentrator. Other authentication methods such as MS- Softwire Concentrator. Other authentication methods such as MS-
CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported.
A detailed discussion of Softwires security is contained in A detailed discussion of Softwire security is contained in
[I-D.ietf-softwire-security-requirements]. [I-D.ietf-softwire-security-requirements].
5.2.4. IPCP 5.2.4. IPCP
The only Network Control Protocol (NCP) negotiated in the Softwire
context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP
(see Section 5.2.4.2) for IPv4 as SPH.
5.2.4.1. IPV6CP 5.2.4.1. IPV6CP
In the IPv6 over IPv4 scenarios (see Section 3.1), after the In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional
authentication phase, the Softwire Initiator MUST negotiate IPV6CP as authentication phase, the Softwire Initiator MUST negotiate IPV6CP as
defined in [RFC5072]. IPV6CP provides a way to negotiate a unique defined in [RFC5072]. IPV6CP provides a way to negotiate a unique
64-bit Interface-Identifier to be used for the address 64-bit Interface-Identifier to be used for the address
autoconfiguration at the local end of the link. autoconfiguration at the local end of the link.
5.2.4.2. IPv4CP 5.2.4.2. IPv4CP
In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire
Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain
an IPv4 address from the SC. IPCP may also be used to obtain DNS an IPv4 address from the SC. IPCP may also be used to obtain DNS
information as described in [RFC1877]. information as described in [RFC1877].
5.3. Global IPv6 Address Assignement to Endpoints 5.3. Global IPv6 Address Assignement to Endpoints
In several scenarios defined in Section 3, Global IPv6 addresses are In several scenarios defined in Section 3.1, Global IPv6 addresses
expected to be allocated to Softwires end points. Since IPV6CP only are expected to be allocated to Softwire endpoints (in addition to
provide Link-Local addresses (see [RFC5072]), IPv6 Neighbor Discovery the Link-Local addresses autoconfigured using the IPV6CP negotiated
[RFC4862] or DHCPv6 [RFC3315] SHOULD be used to configure these interface identifier). The Softwire Initiator assigns global IPv6
addresses. addresses using the IPV6CP negotiated interface identifier and using
Stateless Address Autoconfiguration [RFC4862], and/or using Privacy
Extensions for Stateless Address Autoconfiguration [RFC4941], (as
described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315].
The Softwire Initiator of an IPv6 Softwire MUST send a Router The Softwire Initiator of an IPv6 Softwire MUST send a Router
Solicitation message to the Softwire Concentrator after IPV6CP is Solicitation message to the Softwire Concentrator after IPV6CP is
completed. The Softwire Concentrator MUST answer with a Router completed. The Softwire Concentrator MUST answer with a Router
Advertisement. This message MUST contains the global IPv6 prefix of Advertisement. This message MUST contains the global IPv6 prefix of
the PPP link if Neighbor discovery is used to configure addresses of the PPP link if Neighbor Discovery is used to configure addresses of
Softwire end points. Softwire end points.
If DHCPv6 is available for address delegation, the M bits of the If DHCPv6 is available for address delegation, the M bits of the
Router Advertisement SHOULD be set. The Softwire Initiator MUST then Router Advertisement SHOULD be set. The Softwire Initiator MUST then
send a DHCPv6 Request to configure the address of the Softwire send a DHCPv6 Request to configure the address of the Softwire
endpoint. endpoint.
Duplicate Address Detection ([RFC4861]) MUST be performed on the Duplicate Address Detection ([RFC4861]) MUST be performed on the
Softwire in both cases. Softwire in both cases.
5.4. DHCP 5.4. DHCP
The Softwire Initiator MAY use DHCP to get additional information The Softwire Initiator MAY use DHCP to get additional information
such as delegated prefix and DNS servers. If the SI supports DHCP, such as delegated prefix and DNS servers.
it SHOULD send a Solicit message to verify if more information is
available.
When delegating an IPv4 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire.
5.4.1. DHCPv6 5.4.1. DHCPv6
In the scenarions in Section 3.1, if the SI supports DHCPv6, it
SHOULD send a Solicit message to verify if more information is
available.
If an SI establishing an IPv6 Softwire acts as a router (i.e., in the If an SI establishing an IPv6 Softwire acts as a router (i.e., in the
scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the
IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in
order to request an IPv6 prefix. order to request an IPv6 prefix.
When delegating an IPv6 prefix to the SI, the SC SHOULD inject a When delegating an IPv6 prefix to the SI by returning a DHCPv6
route for this prefix in the IPv4 routing table in order to forward Advertise message with the IA_PD and IP_PD Prefix options [RFC3633],
the traffic to the relevant Softwire. the SC SHOULD inject a route for this prefix in the IPv6 routing
table in order to forward the traffic to the relevant Softwire.
Configuration of DNS MUST be done as specified in [RFC3646] and
transmitted according to [RFC3315] and [RFC3736]. In general, all
DHCPv6 options MUST be transmitted according to [RFC3315] and
[RFC3736].
5.4.2. DHCPv4 5.4.2. DHCPv4
An SI establishing an IPv4 Softwire MAY send a DHCP request An SI establishing an IPv4 Softwire MAY send a DHCP request
containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].
This practice is not common but may be used to connect IPv4 subnets This practice is not common but may be used to connect IPv4 subnets
using Softwires, as defined in Section 3.2.2 and Section 3.2.4. using Softwires, as defined in Section 3.2.2 and Section 3.2.4.
One Subnet-Request suboption MUST be configured with the 'h' bit set 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. 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 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, first time a prefix is requested and to '1' on subsequent requests,
if a prefix has been allocated. The Prefix length suboption SHOULD if a prefix has been allocated. The Prefix length suboption SHOULD
be 0 by default. If the SI is configured to support only specific be 0 by default. If the SI is configured to support only specific
prefix lengths, it SHOULD specify the longest (smallest) prefix prefix lengths, it SHOULD specify the longest (smallest) prefix
length it supports. length it supports.
If the SI was previously assigned a prefix from that same SC, it If the SI was previously assigned a prefix from that same SC, it
SHOULD include the Subnet Information suboption with the prefix it SHOULD include the Subnet-Information suboption with the prefix it
was previously assigned. The 'c' and 's' bits of the suboption was previously assigned. The 'c' and 's' bits of the suboption
SHOULD be set to '0'. SHOULD be set to '0'.
In the scenarions in Section 3.2, when delegating an IPv4 prefix to
the SI, the SC SHOULD inject a route for this prefix in the IPv4
routing table in order to forward the traffic to the relevant
Softwire.
6. Considerations about the Address Provisioning Model 6. Considerations about the Address Provisioning Model
This section describes how a Softwire Concentrator may manage This section describes how a Softwire Concentrator may manage
delegated addresses for Softwire endpoints and for subnets behind the delegated addresses for Softwire endpoints and for subnets behind the
Softwire Initiator. One common practice is to aggregate endpoints Softwire Initiator. One common practice is to aggregate endpoints'
addresses and delegated prefixes into one prefix routed to the SC. addresses and delegated prefixes into one prefix routed to the SC.
The main benefit is to ease the routing scheme by isolating on the SC The main benefit is to ease the routing scheme by isolating on the SC
succeeding route injections (when delegating new prefixes for SI). succeeding route injections (when delegating new prefixes for SI).
6.1. Softwire Endpoints Addresses 6.1. Softwire Endpoints' Addresses
6.1.1. IPv6 6.1.1. IPv6
A Softwire Concentrator should provide globally routable addresses to A Softwire Concentrator should provide globally routable addresses to
Softwire endpoints. Other types of addresses such as Unique Local Softwire endpoints. Other types of addresses such as Unique Local
Addresses [RFC4193] may be used to address Softwire end points in a Addresses [RFC4193] may be used to address Softwire end points in a
private network with no global connectivity. A single /64 should be private network with no global connectivity. A single /64 should be
assigned to the Softwire to address both Softwire endpoints. assigned to the Softwire to address both Softwire endpoints.
Global or ULA addresses must be assigned to endpoints when the Global or ULA addresses must be assigned to endpoints when the
skipping to change at page 29, line 34 skipping to change at page 30, line 7
on the endpoints, it is not recommended to delegate an IPv4 private on the endpoints, it is not recommended to delegate an IPv4 private
prefix to the SI, as it can lead to a nested-NAT situations. prefix to the SI, as it can lead to a nested-NAT situations.
The endpoints of the PPP link use host addresses (i.e., /32), The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP. negotiated using IPCP.
6.2. Delegated Prefixes 6.2. Delegated Prefixes
6.2.1. IPv6 Prefixes 6.2.1. IPv6 Prefixes
Delegated IPv6 should be of global scope if the IPv6 addresses Delegated IPv6 prefixes should be of global scope if the IPv6
assigned to endpoints are global. Using ULA addresses is not addresses assigned to endpoints are global. Using ULA addresses is
recommended when the subnet is connected to the global IPv6 Internet. not recommended when the subnet is connected to the global IPv6
When using ULA IPv6 address for endpoint, the delegated IPv6 prefix Internet. When using ULA IPv6 address for endpoint, the delegated
may be either of Global or ULA scope. IPv6 prefix may be either of Global or ULA scope.
Delegated IPv6 prefixes are between /48 and /64 in length. When an Delegated IPv6 prefixes are between /48 and /64 in length. When an
SI receives a prefix shorter than 64, it can assign different /64 SI receives a prefix shorter than 64, it can assign different /64
prefixes to each of its interfaces. An SI receiving a single /64 is prefixes to each of its interfaces. An SI receiving a single /64 is
expected to perform bridging if more than one interface are available expected to perform bridging if more than one interface are available
(wired and wireless for example). (e.g., wired and wireless).
6.2.2. IPv4 Prefixes 6.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be routable within the address space Delegated IPv4 prefixes should be routable within the address space
used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes
(i.e. private IPv4 prefix over public IPv4 addresses or another class (i.e., private IPv4 prefix over public IPv4 addresses or another
of private IPv4 addresses) is not recommended as a practice for class of private IPv4 addresses) is not recommended as a practice for
provisioning and address translation should be considered in these provisioning and address translation should be considered in these
cases. The prefix length is between /8 and /30. cases. The prefix length is between /8 and /30.
6.3. Possible scenarios 6.3. Possible Address Provisioning Scenarios
This section summarizes the differents scenarios for address This section summarizes the differents scenarios for address
provisioning with the considerations given in the previous sections. provisioning with the considerations given in the previous sections.
6.3.1. Scenarios for IPv6 6.3.1. Scenarios for IPv6
This table describes the possible combination of IPv6 address scope This table describes the possible combination of IPv6 address scope
for endpoints and delegated prefixes. for endpoints and delegated prefixes.
+------------------+-----------------------+------------------------+ +------------------+-----------------------+------------------------+
skipping to change at page 31, line 28 skipping to change at page 31, line 48
routing table. The routing fragmentation issue may be limited if the routing table. The routing fragmentation issue may be limited if the
prefixes are aggregated in a location topologically close to the SC. 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 This would be the case for example if several SCs are put in parallel
for load-balancing purpose. for load-balancing purpose.
8. Considerations about RADIUS Integration 8. Considerations about RADIUS Integration
The Softwire Concentrator is expected to act as a client to a AAA The Softwire Concentrator is expected to act as a client to a AAA
server, for example a RADIUS server. During the PPP authentication server, for example a RADIUS server. During the PPP authentication
phase, the RADIUS server may return additional informations in the phase, the RADIUS server may return additional informations in the
form of attributes in the Access Accept message. form of attributes in the Access-Accept message.
The Softwire Concentrator may include the Tunnel-Type and Tunnel- The Softwire Concentrator may include the Tunnel-Type and Tunnel-
Medium-Type attributes [RFC2868] in the Access Request messages to Medium-Type attributes [RFC2868] in the Access-Request messages to
provide a hint of the type of Softwire being configured. provide a hint of the type of Softwire being configured.
8.1. Softwires Endpoints 8.1. Softwire Endpoints
8.1.1. IPv6 Softwires 8.1.1. IPv6 Softwires
If the RADIUS server includes a Framed-Interface-Id attribute If the RADIUS server includes a Framed-Interface-Id attribute
[RFC3162], the Softwire Concentrator must send it to the Softwire [RFC3162], the Softwire Concentrator must send it to the Softwire
Initiator in the Interface-Identifier field of its IPV6CP Initiator in the Interface-Identifier field of its IPV6CP
Configuration Request message. Configuration Request message.
If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that If the Framed-IPv6-Prefix attribute [RFC3162] is included, that
prefix must be used in the router advertisements sent to the SI. If 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 Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
must choose a prefix with that pool to send RAs. must choose a prefix with that pool to send RAs.
If none of the attributes above are included but the AAA server If none of the attributes above are included but the AAA server
returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
attributes [RFC2868] with the correct address family, these must be attributes [RFC2868] with the correct address family, these must be
used in the IPV6CP Interface-Identifier and for the router used in the IPV6CP Interface-Identifier and for the Router
advertisements. Advertisements.
8.1.2. IPv4 Softwires 8.1.2. IPv4 Softwires
If the Framed-IP-Address attribute [RFC2865] is present, the Softwire If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
Concentrator must provide that address to the Softwire Initiator Concentrator must provide that address to the Softwire Initiator
during IPCP address negotiation. That is, when the Softwire during IPCP address negotiation. That is, when the Softwire
Initiator requests an IP address from the Softwire Concentrator, the Initiator requests an IP address from the Softwire Concentrator, the
address provided should be the Framed-IP-Address. address provided should be the Framed-IP-Address.
If the Framed-IP-Address attribute is not present and the Tunnel- If the Framed-IP-Address attribute is not present and the Tunnel-
Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
present and of the correct address family, these should be used in present and of the correct address family, these should be used in
the IPCP IP-Address configuration option. the IPCP IP-Address configuration option.
8.2. Delegated Prefixes 8.2. Delegated Prefixes
8.2.1. IPv6 Prefixes 8.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
RADIUS Access Accept message, it must be used by the Softwire RADIUS Access-Accept message, it must be used by the Softwire
Concentrator for the delegation of the IPv6 prefix. Since the prefix Concentrator for the delegation of the IPv6 prefix. Since the prefix
delegation is performed by DHCPv6 and the attribute is linked to a delegation is performed by DHCPv6 and the attribute is linked to a
username, the SC must associate the DHCP Unique Identifier (DUID) of username, the SC must associate the DHCP Unique Identifier (DUID) of
a DHCPv6 request to the tunnel it came from and its user. a DHCPv6 request to the tunnel it came from and its user.
Interaction between RADIUS, PPP and DHCPv6 server may follow the Interaction between RADIUS, PPP and DHCPv6 server may follow the
mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case,
Softwire authentication phase, PPP collects the RADIUS attributes for during the Softwire authentication phase, PPP collects the RADIUS
the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is attributes for the user such as Delegated-IPv6-Prefix. A specific
assigned to the Softwire. The DHCPv6 relay fills in these attributes DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in
in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, these attributes in the Relay agent RADIUS Attribute Option (RRAO)
before forwarding the DHCPv6 requests to the DHCPv6 server. DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6
server.
8.2.2. IPv4 Prefixes 8.2.2. IPv4 Prefixes
The combination of the Framed-IP-Address and Framed-IP-Netmask The combination of the Framed-IP-Address and Framed-IP-Netmask
attributes [RFC2865] may be used by the Softwire Concentrator to attributes [RFC2865] may be used by the Softwire Concentrator to
delegate an IPv4 prefix to the Softwire Initiator. delegate an IPv4 prefix to the Softwire Initiator.
9. Considerations for Maintenance and Statistics 9. Considerations for Maintenance and Statistics
9.1. RADIUS Accounting 9.1. RADIUS Accounting
RADIUS Accounting for L2TP and PPP are documented (see Section 4.3). RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
When deploying Softwires solutions, operators may experience When deploying Softwire solutions, operators may experience
difficulties to differentiate the address family of the traffic difficulties to differentiate the address family of the traffic
reported in accounting information from RADIUS. This problem and reported in accounting information from RADIUS. This problem and
some potential solutions are described in some potential solutions are described in
[I-D.stevant-softwire-accounting]. [I-D.stevant-softwire-accounting].
9.2. MIBs 9.2. MIBs
MIB support for L2TPv2 and PPP are documented (see Section 4.4). MIB support for L2TPv2 and PPP are documented (see Section 4.4).
Also see [RFC4293]. Also see [RFC4293].
10. Security Considerations 10. Security Considerations
A detailed discussion of Softwires security is contained in A detailed discussion of Softwire security is contained in
[I-D.ietf-softwire-security-requirements]. [I-D.ietf-softwire-security-requirements].
The L2TPv2 Softwires solution provides the following tools for The L2TPv2 Softwire solution provides the following tools for
security: security:
o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of
security. [RFC3193] describes interaction between IPsec and security. [RFC3193] describes interaction between IPsec and
L2TPv2. L2TPv2.
o PPP CHAP [RFC1994] provides basic user authentication. o PPP CHAP [RFC1994] provides basic user authentication.
o L2TP Tunnel Authentication [RFC2661] provides authentication at o L2TP Tunnel Authentication [RFC2661] provides authentication at
tunnel setup. It may be used to limit DoS attacks by tunnel setup. It may be used to limit DoS attacks by
skipping to change at page 33, line 42 skipping to change at page 34, line 19
11. IANA Considerations 11. IANA Considerations
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following contributors who The authors would like to acknowledge the following contributors who
provided helpful input on this document: Florent Parent, Jordi Palet provided helpful input on this document: Florent Parent, Jordi Palet
Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley,
Francis Dupont. Francis Dupont and Ralph Droms.
The authors would also like to acknowledge the participants in the The authors would also like to acknowledge the participants in the
Softwires interim meetings held in Hong Kong, China and Barcelona, Softwires interim meetings held in Hong Kong, China and Barcelona,
Spain. The minutes for the interim meeting at the China University - Spain. The minutes for the interim meeting at the China University -
Hong Kong (February 23-24, 2006) are at Hong Kong (February 23-24, 2006) are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The
minutes for the interim meeting at Polytechnic University of minutes for the interim meeting at Polytechnic University of
Catalonia - Barcelona (September 14-15, 2006) are reachable at <http: Catalonia - Barcelona (September 14-15, 2006) are reachable at <http:
//bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>. //bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>.
skipping to change at page 35, line 13 skipping to change at page 35, line 35
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base", Tunneling Protocol "L2TP" Management Information Base",
RFC 3371, August 2002. RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
skipping to change at page 35, line 36 skipping to change at page 36, line 12
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dhc-subnet-alloc] [I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option", Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-05 (work in progress), draft-ietf-dhc-subnet-alloc-06 (work in progress),
June 2007. November 2007.
[I-D.ietf-dhc-v6-relay-radius] [I-D.ietf-dhc-v6-relay-radius]
Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
draft-ietf-dhc-v6-relay-radius-02 (work in progress), draft-ietf-dhc-v6-relay-radius-02 (work in progress),
February 2006. February 2006.
[I-D.ietf-softwire-security-requirements] [I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and Yamamoto, S., Williams, C., Parent, F., and H. Yokota,
Requirements", "Softwire Security Analysis and Requirements",
draft-ietf-softwire-security-requirements-03 (work in draft-ietf-softwire-security-requirements-05 (work in
progress), July 2007. progress), December 2007.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point Protocol", the Link Control Protocol of the Point-to-Point Protocol",
RFC 1471, June 1993. RFC 1471, June 1993.
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for [RFC1473] Kastenholz, F., "The Definitions of Managed Objects for
the IP Network Control Protocol of the Point-to-Point the IP Network Control Protocol of the Point-to-Point
Protocol", RFC 1473, June 1993. Protocol", RFC 1473, June 1993.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877, Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995. December 1995.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998. RFC 2433, October 1998.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, Modifications for Tunnel Protocol Support", RFC 2867,
June 2000. June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
skipping to change at page 37, line 16 skipping to change at page 37, line 45
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006. August 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007. Problem Statement", RFC 4925, July 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
Appendix A. Revision History Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the [Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to corresponding entries in the table of contents, prior to
publication.] publication.]
Changes between -07 and -08:
o Corrected the usage of Softwire vs. Softwires throughout the
document, esp. when used as an adjective.
o Editorial: Re-arranged "Contributing Authors" (Section 1.3).
o Miscellaneous editorial corrections, readability improvements,
completed the Abbreviations Section 1.1.
o Added Section 2.3 about "Routing".
o In all the Deployment Scenarios (Section 3), clarified that the
description is after successful LCP negotiation and optional PPP
Authentication. Corrected "DHCPv6" in Figure 1 and Figure 3.
o Removed /48 example from Section 3.1.2 and Section 3.1.4.
o Added reference and corresponding citations to [RFC2132] in
Section 3.2.
o Completed the citations on Section 4.5, adding [RFC4862],
[RFC3633], [RFC2131], and [RFC2132].
o Moved the last two sentences of Section 5.4 to Section 5.4.1 and
Section 5.4.2 respectively.
o Completed the first paragraph of Section 5.3, adding an
informational reference to [RFC4941].
o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added
a follow-on clarifying paragraph about PPP NCP and DHCP versions
used in each softwire scenario.
o Clarification of implementation versus usage of the optional AVPs
in Section 5.1.1.2.
o Added text including [RFC3736] for DHCPv6.
Changes between -06 and -07: Changes between -06 and -07:
o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861], o Changed RFC numbers: RFC2461 and I-D 2461(bis) to [RFC4861],
RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to RFC2462 to [RFC4862], and RFC2472 and I-D.ietf-ipv6-over-ppp-v2 to
[RFC5072]. [RFC5072].
Changes between -05 and -06: Changes between -05 and -06:
o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to
"Securing the Softwire Transport". "Securing the Softwire Transport".
skipping to change at page 38, line 50 skipping to change at page 40, line 28
o Moved the Softwire Problem Statement reference [RFC4925] to o Moved the Softwire Problem Statement reference [RFC4925] to
Informative. Informative.
o Some additional purely editorial changes. o Some additional purely editorial changes.
Changes between -02 and -03: Changes between -02 and -03:
o Boiler changes in support of RFC 4748. o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.6 and Section 5.1.2. Section 2.7 and Section 5.1.2.
o Moved some downref to Informative ([RFC1877], [RFC2433], o Moved some downref to Informative ([RFC1877], [RFC2433],
[RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to
Normative ([RFC1994]). Normative ([RFC1994]).
o Removed the mention and citation for PAP authentication. o Removed the mention and citation for PAP authentication.
Changes between -01 and -02: Changes between -01 and -02:
o Renamed all "Best Current Practices" sections as o Renamed all "Best Current Practices" sections as
skipping to change at page 43, line 4 skipping to change at page 44, line 31
Email: cpignata@cisco.com Email: cpignata@cisco.com
Maria Alice Dos Santos Maria Alice Dos Santos
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: mariados@cisco.com Email: mariados@cisco.com
Bruno Stevant (editor) Bruno Stevant (editor)
GET/ENST Bretagne TELECOM Bretagne
2 rue de la Chataigneraie CS17607 2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576 Cesson Sevigne, 35576
France France
Email: bruno.stevant@enst-bretagne.fr Email: bruno.stevant@telecom-bretagne.eu
Jean-Francois Tremblay Jean-Francois Tremblay
Trellia Networks Trellia Networks
100, Alexis-Nihon, Suite 770 100, Alexis-Nihon, Suite 770
Montreal, QC H4M 2P3 Montreal, QC H4M 2P3
Canada Canada
Email: jf@jftremblay.com Email: jf@jftremblay.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 163 change blocks. 
334 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/