draft-ietf-softwire-hs-framework-l2tpv2-11.txt   draft-ietf-softwire-hs-framework-l2tpv2-12.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: August 13, 2009 Cisco Systems Expires: September 7, 2009 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
TELECOM Bretagne TELECOM Bretagne
J. Tremblay J. Tremblay
Videotron Ltd. Videotron Ltd.
February 9, 2009 March 6, 2009
Softwire Hub & Spoke Deployment Framework with L2TPv2 Softwire Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-11 draft-ietf-softwire-hs-framework-l2tpv2-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 13, 2009. This Internet-Draft will expire on September 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 the Layer 2 Tunneling Protocol version 2 (L2TPv2). 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 interoperability among different vendor implementations. to achieve interoperability among different vendor implementations.
Table of Contents Table of Contents
skipping to change at page 2, line 42 skipping to change at page 2, line 50
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13
3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 15 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 15
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 15 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 15
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17
4. Standardization Status . . . . . . . . . . . . . . . . . . . . 18 4. References to standardization documents . . . . . . . . . . . 18
4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Securing the Softwire Transport . . . . . . . . . . . . . 19 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 19
4.3. Authentication Authorization Accounting . . . . . . . . . 19 4.3. Authentication Authorization Accounting . . . . . . . . . 19
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 20 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 23 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 23
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 26 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 26
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 27 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 27
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 27 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 27
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 28 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 28
5.1.4. Additional L2TPv2 Considerations . . . . . . . . . . . 28 5.1.4. Additional L2TPv2 Considerations . . . . . . . . . . . 28
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 28 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 3, line 51 skipping to change at page 4, line 12
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 35 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35
9. Considerations for Maintenance and Statistics . . . . . . . . 35 9. Considerations for Maintenance and Statistics . . . . . . . . 35
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 35 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 35
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . . 38 13.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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
Softwire "Hubs and Spokes" solution space. This document describes Softwire "Hub and Spoke" solution space. This document describes the
the framework for the L2TPv2 "Hubs and Spokes" solution, and the framework for the L2TPv2 "Hub and Spoke" 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 "Hub and Spoke" 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 the 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). The terms voluntary tunneling and compulsory Network Server (LNS). The terms voluntary tunneling and compulsory
tunneling are defined in Section 1.1 of [RFC3193]. Since L2TPv2 tunneling are defined in Section 1.1 of [RFC3193]. Since L2TPv2
compulsory tunneling model does not apply to Softwires, it SHOULD NOT compulsory tunneling model does not apply to Softwires, it SHOULD NOT
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Bruno Stevant, TELECOM Bretagne Bruno Stevant, TELECOM 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 has been identified A list of Softwire "Hub and Spoke" requirements has been identified
by the Softwire Problem Statement [RFC4925]. The following sub- by the Softwire Problem Statement [RFC4925]. The following sub-
sections describe how L2TPv2 fulfills each of them. sections describe how L2TPv2 fulfills each of them.
2.1. Traditional 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 "Hub and Spoke" Softwire must be able to traverse Network Address
Translation (NAT) and Network Address Port Translation (NAPT, also Translation (NAT) and Network Address Port Translation (NAPT, also
referred to as Port Address Translation or PAT) devices [RFC3022] in referred to as Port Address Translation or PAT) devices [RFC3022] in
case the scenario in question involves a non-upgradable pre-existing case the scenario in question involves a non-upgradable pre-existing
IPv4 home gateway performing NAT/NAPT or some carrier equipment at IPv4 home gateway performing NAT/NAPT or some carrier equipment at
the other end of the access link performing NAT/NAPT. The L2TPv2 the other end of the access link performing NAT/NAPT. The L2TPv2
Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT
traversal since L2TPv2 can run over UDP. traversal since L2TPv2 can run over UDP.
Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not
offer the option of disabling UDP. The UDP encapsulation is present offer the option of disabling UDP. The UDP encapsulation is present
skipping to change at page 8, line 7 skipping to change at page 8, line 7
not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering
Behavior (see Section 5 of [RFC4787]). Specifically, any IP address Behavior (see Section 5 of [RFC4787]). Specifically, any IP address
and port combination will work with Endpoint-Independent Filtering, and port combination will work with Endpoint-Independent Filtering,
but changing IP address and port will not work through Address- but changing IP address and port will not work through Address-
Dependent or Address and Port-Dependent Filtering. Given this, Dependent or Address and Port-Dependent Filtering. Given this,
responding from a different IP address and/or UDP port is NOT responding from a different IP address and/or UDP port is NOT
RECOMMENDED. RECOMMENDED.
2.2. Scalability 2.2. Scalability
In the "Hubs and Spokes" model, a carrier must be able to scale the In the "Hub and Spoke" 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. Routing 2.3. Routing
There are no dynamic routing protocols between the SC and SI. A There are no dynamic routing protocols between the SC and SI. A
default route from the SI to the SC is used. default route from the SI to the SC is used.
skipping to change at page 9, line 42 skipping to change at page 9, line 42
o IPv4/PPP/L2TPv2/UDP/IPv4 o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6 o IPv6/PPP/L2TPv2/UDP/IPv6
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 "Hub and Spoke" 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 section examines the four scenarios for both IPv6 over IPv4
(Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations. (Section 3.1) and IPv4 over IPv6 (Section 3.2) encapsulations.
3.1. IPv6 over IPv4 Softwires with L2TPv2 3.1. IPv6 over IPv4 Softwires with L2TPv2
The following subsections cover IPv6 connectivity (SPH) across an The following subsections cover IPv6 connectivity (SPH) across an
skipping to change at page 18, line 47 skipping to change at page 18, line 47
In this scenario, after the L2TPv2 Control Channel and Session In this scenario, after the L2TPv2 Control Channel and Session
establishment and PPP LCP negotiation (and optionally PPP establishment and PPP LCP negotiation (and optionally PPP
Authentication) are successful, IPCP negotiates IPv4 over PPP which Authentication) are successful, IPCP negotiates IPv4 over PPP which
also provides the capability for the ISP to assign a global IPv4 also provides the capability for the ISP to assign a global IPv4
address to the v4/v6 router. A global IPv4 address can also be address to the v4/v6 router. A global IPv4 address can also be
assigned via DHCP. Other configuration options (such as DNS) can be assigned via DHCP. Other configuration options (such as DNS) can be
conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132].
For IPv4 Prefix Delegation for the home network, DHCP For IPv4 Prefix Delegation for the home network, DHCP
[I-D.ietf-dhc-subnet-alloc] can be used. [I-D.ietf-dhc-subnet-alloc] can be used.
4. Standardization Status 4. References to standardization documents
This section groups various Internet standards documents and other This section lists and groups documents from the Internet
publications used in Softwires. standardization describing technologies used to design the framework
of the Softwire "Hub and Spoke" solution. This emphasizes the
motivation of Softwire to reuse as many existing standards as
possible. This list contains both Standards Track (Proposed
Standard, Draft Standard, and Internet Standard) and Informational
documents. The list of documents and their status should only be
only used for description purposes.
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.
skipping to change at page 20, line 47 skipping to change at page 21, line 7
RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131]. RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131].
RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132]. 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, potentially
First an L2TPv2 tunnel with a single session is established from the preceded by an optional IPsec-related step 0 (see Figure 9). First
SI to the SC. Second a PPP session is established over the L2TPv2 an L2TPv2 tunnel with a single session is established from the SI to
session and the SI obtains an address. Third the SI optionally gets the SC. Second a PPP session is established over the L2TPv2 session
other information through DHCP such as a delegated prefix and DNS and the SI obtains an address. Third the SI optionally gets other
servers. information through DHCP such as a delegated prefix and DNS servers.
SC SI SC SI
| | | |
|<-------------IKEv1------------->| Step 0
| | IPsec SA establishment
| | (optional)
| |
|<-------------L2TPv2------------>| Step 1 |<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment | | L2TPv2 Tunnel establishment
| | | |
|<-------------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
Figure 10 depicts details of each of the three steps required to Figure 10 depicts details of each of these steps required to
establish a Softwire. establish a Softwire.
SC SI SC SI
| | | |
| | Step 0
|<------------IKEv1-------------->| = IKEv1 (Optional)
| |
| | 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------| -
skipping to change at page 22, line 48 skipping to change at page 22, line 51
|<---------- REQUEST--------------| | (IPv6 SW, Optional) |<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| - |-------------REPLY-------------->| -
| | or | | or
|<---------DHCPDISCOVER-----------| - |<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4 |-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional) |<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| - |------------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 The IPsec-related negotiations in step 0 are optional. The L2TPv2
Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP negotiations in step 1 are described in Section 5.1. The PPP NCP
negotiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and negotiations in step 2 use IPV6CP for IPv6 over IPv4 Softwires, and
DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over IPCP for IPv4 over IPv6 Softwires (see Section 5.2.4). The optional
IPv4 Softwires, the DHCPv6 exchange for non-address configuration DHCP negotiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires,
(such as DNS) can use Stateless DHCPv6, the two message exchange with and DHCPv4 for IPv4 over IPv6 Softwires (see Section 5.4).
Information-Request and Reply messages (see Section 1.2 of [RFC3315] Additionally, for IPv6 over IPv4 Softwires, the DHCPv6 exchange for
and [RFC3736]). non-address configuration (such as DNS) can use Stateless DHCPv6, the
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
incoming call model, the end user makes a connection to an L2TP incoming call model, the end user makes a connection to an L2TP
Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel
to an L2TP Network Server (LNS). The LNS then transfers end user to an L2TP Network Server (LNS). The LNS then transfers end user
traffic between the L2TPv2 tunnel and the private network. traffic between the L2TPv2 tunnel and the private network.
skipping to change at page 36, line 12 skipping to change at page 36, line 12
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 Softwire security is contained in One design goal of the "Hub and Spoke" problem is to very strongly
[I-D.ietf-softwire-security-requirements]. consider the reuse of already deployed protocols (see [RFC4925]).
Another design goal is a solution with very high scaling properties.
L2TPv2 [RFC2661] is the phase 1 protocol used in the Softwire "Hub
and Spoke" solution space, and the L2TPv2 security considerations
apply to this document (see Section 9 of [RFC2661]).
The L2TPv2 Softwire solution provides the following tools for The L2TPv2 Softwire solution adds the following considerations:
security:
o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of o L2TP Tunnel Authentication (see Sections 5.1.1 and 9.1 of
security. [RFC3193] describes interaction between IPsec and [RFC2661]) provides authentication at tunnel setup. It may be
L2TPv2. used to limit DoS attacks by authenticating the tunnel before L2TP
and PPP resources are allocated.
o In a Softwire environment, L2TPv2 AVPs do not transport sensitive
data, and thus the L2TPv2 AVP hiding mechanism is not used (see
Section 5.1.1).
o PPP CHAP [RFC1994] provides basic user authentication. Other o PPP CHAP [RFC1994] provides basic user authentication. Other
authentication protocols may additionally be supported (see authentication protocols may additionally be supported (see
Section 5.2.3). Section 5.2.3).
o In a Softwire environment, L2TPv2 AVPs do not transport sensitive L2TPv2 can also be secured with IPsec, to provide privacy, integrity,
data, and thus the L2TPv2 AVP hiding mechanism is not used (see and replay protection. Currently, there are two different solutions
Section 5.1.1). for security L2TPv2 with IPsec:
o L2TP Tunnel Authentication [RFC2661] provides authentication at o Securing L2TPv2 using IPsec "version 2" (RFC 24xx/IKEv1) is
tunnel setup. It may be used to limit DoS attacks by specified in [RFC3193], [RFC3947] and [RFC3948]. When L2TPv2 is
authenticating the tunnel before L2TP session and PPP resources used in the Softwire context, the voluntary tunneling model
are allocated. applies. [RFC3193] describes the interaction between IPsec and
L2TPv2, and is deployed. [RFC3193] MUST be supported, given that
deployed technology must be very strongly considered [RFC4925] for
this 'time-to-market' solution.
o [I-D.ietf-softwire-security-requirements] also specifies a new
(incompatible) solution for securing L2TPv2 with IPsec "version 3"
(RFC 43xx/IKEv2). Section 3.5 of
[I-D.ietf-softwire-security-requirements] describes the
advantanges of using IKEv2, and this solution needs to be
considered for future phases.
Additional discussion of Softwire security is contained in
[I-D.ietf-softwire-security-requirements].
11. IANA Considerations 11. IANA Considerations
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
This document creates no new requirements on IANA namespaces. This document creates no new requirements on IANA namespaces.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following contributors who The authors would like to acknowledge the following contributors who
skipping to change at page 38, line 20 skipping to change at page 38, line 40
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 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[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
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007. Attribute", RFC 4818, April 2007.
[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, Haskin, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskin, 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
skipping to change at page 40, line 48 skipping to change at page 41, line 17
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007. Suggested Fixes", RFC 5080, December 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405,
November 2008. November 2008.
Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to
publication.]
Changes between -10 and -11:
o Addressing Gen-ART and IESG (Lars Eggert, Jari Arkko, Dan
Romascanu, and Pasi Eronen) review comments.
Changes between -09 and -10:
o Fixed a number of typos.
Changes between -08 and -09:
o Refresh version about to expire, no other changes.
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:
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
[RFC5072].
Changes between -05 and -06:
o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to
"Securing the Softwire Transport".
o In Section 5.2.1, added a mention that the MTU should be lower
that 1460 when using IPsec.
o In Section 10, added pointers to [RFC4301] and [RFC4306].
Changes between -04 and -05:
o Replaced "documentation" with "logging purposes" in
Section 5.1.1.1.
o Added suggested values (only as guidance) for Keepalives in
Section 5.1.2.
Changes between -03 and -04:
o Added missing references to [RFC4087], [RFC4861], and [RFC3646],
moved [RFC4623] to Informative.
o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and
Section 6.2.2 in Table 2.
o Added citations (and corresponding references) to [RFC1471] and
[RFC1473] in Section 4.4, since Section 9.2 explicitly mentions:
"MIB support for L2TPv2 and PPP are documented."
o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2,
Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2,
Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and
Section 8.1.1.
o Added [RFC2868] to Section 4.3, and added missing citations to
Section 4.
o Added missing "Optional AVP" to Figure 11.
o Updated the text in Section 6.2.2.
o Added some clarifying sentences in Section 5.1.1, and completed
Section 5.1.1.1 and Section 5.1.1.2.
o Added an Informative reference to [RFC3022] for NAT/NAPT.
o Corrected reference to [RFC1661] in Section 5.2.2, removed
reference and citation to RFC1662.
o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved
to Normative.
o Added new address and email for J.F. Tremblay.
o Added an acknowledgement to the participants, and pointer to the
minutes, for the Barcelona interim meeting.
o Moved the Softwire Problem Statement reference [RFC4925] to
Informative.
o Some additional purely editorial changes.
Changes between -02 and -03:
o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.7 and Section 5.1.2.
o Moved some downref to Informative ([RFC1877], [RFC2433],
[RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to
Normative ([RFC1994]).
o Removed the mention and citation for PAP authentication.
Changes between -01 and -02:
o Renamed all "Best Current Practices" sections as
"Recommendations". See for example Section 1.4.
o Moved Provisioning in Section 6. Removed intro text to new
Section 7.
o Removed all normative language from Section 6, Section 7,
Section 8, and Section 9.
o Removed empty sections "Implementation Status", and "Open Issues".
o Fixed "Phase 0" in Section 1.
o Small changes to Section 3.1.
o Change L2TP -> L2TPv2 in some sections, including Section 6.
o Small additions and typo fixes in Section 5.1.1.1 and
Section 5.1.1.2.
o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS.
o New paragraph in Section 9.1.
o New paragraph in Section 8.2.1, including a pointer to
[I-D.ietf-dhc-v6-relay-radius].
o Moved last paragraph to start of Section 10.
o Moved some references from Normative to Informative.
o Label the steps in Figure 9 and Figure 10.
o Reword paragraph of Section 5.1.
o Describe more messages than flows in Figure 11 and Figure 12.
o Add text about Session Establishment between Figure 11 and
Figure 12.
o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP,
Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and
Challenge and Challenge Response AVPs.
o Retitled Section 5.1.1.3.
o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End
peer detection, and allow LCP.
o Rewording in Section 5.1.3.
o Section 5.2.1: Add a pointer to [RFC4623] and small updates.
o Clarifications on PFC and ACFC, remove Figure 13.
o Section 5.2.3: make references to RFCs for PAP, CHAP, etc.
o Rewordings in Section 5.2.4.1 and Section 5.2.4.2.
o Added Informative references to [RFC4623], [RFC1661], [RFC2433],
and [RFC3748].
o Renamed the title and added more details on Section 5.3 and IPv6
ND, including a pointer to I-D.ietf-ipv6-2461bis.
o Added text in Section 5.4 about IPv4 PD is non-trivial and non
commonly done.
o Added B. Stevant as Editor.
o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the
scope of the MUST (to the specific scenarios).
o Removed considerations about reverse DNS from Section 6, agreed on
Barcelona.
o Clarified the NAT case in Section 6.1.2
o Added first paragraph in Section 6.2.1 regarding delegated IPv6
prefixes.
o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing
the scenarios for address allocation.
Changes between -00 and -01:
o Changed alignment in all figures to be centered, and fixed
Figure 9 reference.
o Section 1.4: Added new section with "Best Current Practices"
definition.
o Marked the following sections as "Best Current Practices":
Section 6, Section 8, and Section 9.
o Section 6.1.1, last paragraph: Removed sentence on IPv6 link
address on the PPP link. Mailing list comment from Florent
Parent, 13-Jul-2006.
o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to
use host addresses (/32) negotiated with IPCP instead of /30.
Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing
ICRP, and changed direction of ICCN; typo correction s/IPV6P/
IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 5, Figure 10: Marked CHAP as "Optional - CHAP".
o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical
error correction and rewording of some sentences for grammar.
o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes"
and added that MAY be used to authenticate users.
o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and
MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text
from Laurent Toutain.
o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not*
meaningful".
o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed
the last sentence of the first paragraph. Mailing list comment
from Bill Storer, 5-Jul-2006, text from Laurent Toutain.
o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and
not LCP Echo Request and Reply messages to detect tunnel failure,
as redundant in Softwires. Mailing list comment from Florent
Parent, 10-Jul-2006, text from Bill Storer.
o Section 5.2.1, first paragraph: Fixed PPP MTU calculation.
Mailing list comment from Florent Parent, 10-Jul-2006.
o Section 5.2.4.2: Rewrote to generalize the address assignment
failure, to be an all-zeroes address or a protocol reject in
response to the IPCP CONFREQ. Mailing list comment from Bill
Storer, 5-Jul-2006, text from JF Tremblay.
o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /.
Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if
not present then use the Tunnel-Client-Endpoint and Tunnel-Server-
Endpoint attributes. Mailing list comment from Bill Storer,
5-Jul-2006, text from JF Tremblay and Bill Storer.
o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10.
Revision -00:
o Initial revision.
Authors' Addresses Authors' Addresses
Bill Storer Bill Storer
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: bstorer@cisco.com Email: bstorer@cisco.com
 End of changes. 34 change blocks. 
361 lines changed or deleted 106 lines changed or added

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