draft-ietf-softwire-hs-framework-l2tpv2-10.txt   draft-ietf-softwire-hs-framework-l2tpv2-11.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: May 2, 2009 Cisco Systems Expires: August 13, 2009 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
TELECOM Bretagne TELECOM Bretagne
J. Tremblay J. Tremblay
Trellia Networks Videotron Ltd.
October 29, 2008 February 9, 2009
Softwire Hub & Spoke Deployment Framework with L2TPv2 Softwire Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-10 draft-ietf-softwire-hs-framework-l2tpv2-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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 May 2, 2009. This Internet-Draft will expire on August 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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
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 . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 7
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Traditional Network Address Translation (NAT and NAPT) . . 7 2.1. Traditional Network Address Translation (NAT and NAPT) . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Authentication, Authorization and Accounting (AAA) . . . . 8 2.5. Authentication, Authorization and Accounting (AAA) . . . . 8
2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.6. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.7. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.7. Operations and Management . . . . . . . . . . . . . . . . 8
2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 9
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9
3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 9 3.1. IPv6 over IPv4 Softwires with L2TPv2 . . . . . . . . . . . 10
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 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 . . . . . . . . . . . 14 3.2. IPv4 over IPv6 Softwires with L2TPv2 . . . . . . . . . . . 15
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 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 . . . . . . . 16 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17
4. Standardization Status . . . . . . . . . . . . . . . . . . . . 17 4. Standardization Status . . . . . . . . . . . . . . . . . . . . 18
4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 19
4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.3. Authentication Authorization Accounting . . . . . . . . . 19
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 20
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 23
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 26
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 27
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 27
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 28
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 5.1.4. Additional L2TPv2 Considerations . . . . . . . . . . . 28
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 28
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 29
5.3. Global IPv6 Address Assignment to Endpoints . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 29
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Global IPv6 Address Assignment to Endpoints . . . . . . . 29
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Considerations about the Address Provisioning Model . . . . . 29 6. Considerations about the Address Provisioning Model . . . . . 31
6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 31
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 32
6.3. Possible Address Provisioning Scenarios . . . . . . . . . 30 6.3. Possible Address Provisioning Scenarios . . . . . . . . . 32
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 32
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 33
7. Considerations about Address Stability . . . . . . . . . . . . 31 7. Considerations about Address Stability . . . . . . . . . . . . 33
8. Considerations about RADIUS Integration . . . . . . . . . . . 31 8. Considerations about RADIUS Integration . . . . . . . . . . . 34
8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 32 8.1. Softwire Endpoints . . . . . . . . . . . . . . . . . . . . 34
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 32 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 33 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35
9. Considerations for Maintenance and Statistics . . . . . . . . 33 9. Considerations for Maintenance and Statistics . . . . . . . . 35
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 33 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 35
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
Softwire "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 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). Since L2TPv2 compulsory tunneling model does Network Server (LNS). The terms voluntary tunneling and compulsory
not apply to Softwires, it should not be requested or honored. This tunneling are defined in Section 1.1 of [RFC3193]. Since L2TPv2
document identifies all the voluntary tunneling related L2TPv2 compulsory tunneling model does not apply to Softwires, it SHOULD NOT
attributes that apply to Softwires and specifies the handling be requested or honored. This document identifies all the voluntary
mechanism for such attributes in order to avoid ambiguities in tunneling related L2TPv2 attributes that apply to Softwires and
implementations. This document also identifies the set of L2TPv2 specifies the handling mechanism for such attributes in order to
attributes specific to compulsory tunneling model that do not apply avoid ambiguities in implementations. This document also identifies
to Softwires and specifies the mechanism to ignore or nullify their the set of L2TPv2 attributes specific to compulsory tunneling model
effect within the Softwire context. that do not apply to Softwires and specifies the mechanism to ignore
or nullify their 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 Connection With L2TPv2, a Softwire consists of an L2TPv2 Control Connection
(also referred to as Control Channel), a single L2TPv2 Session, and (also referred to as Control Channel), a single L2TPv2 Session, and
the PPP link negotiated over the Session. To establish the Softwire, the PPP link negotiated over the Session. To establish the Softwire,
the SI first initiates an L2TPv2 Control Channel to the SC which the SI first initiates an L2TPv2 Control Channel to the SC which
accepts the request and terminates the Control Channel. L2TPv2 accepts the request and terminates the Control Channel. L2TPv2
supports an optional mutual Control Channel authentication which supports an optional mutual Control Channel authentication which
allows both SI and SC to validate each other's identity at the allows both SI and SC to validate each other's identity at the
initial phase of hand-shaking before proceeding with Control Channel initial phase of hand-shaking before proceeding with Control Channel
establishment. After the L2TPv2 Control Channel is established establishment. After the L2TPv2 Control Channel is established
skipping to change at page 6, line 7 skipping to change at page 6, line 8
Softwire between the SI and SC for tunneling IP traffic of one Softwire between the SI and SC for tunneling IP traffic of one
Address Family (AF) across the access network of another Address Address Family (AF) across the access network of another Address
Family. 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
AF Address Family, IPv4 or IPv6. AF Address Family, IPv4 or IPv6.
CPE Customer Premises Equipment.
LCCE L2TP Control Connection Endpoint, an L2TP node that exists at
either end of an L2TP Control Connection. (See [RFC3931].)
LNS L2TP Network Server, a node that acts as one side of an L2TP
tunnel (Control Connection) endpoint. The LNS is the logical
termination point of a PPP session that is being tunneled from
the remote system by the peer LCCE. (See [RFC2661].)
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].)
LCCE L2TP Control Connection Endpoint, an L2TP node that exists at
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 STH Softwire Transport Header, the outermost IP header of a
softwire (See [RFC4925]). Softwire. (See [RFC4925].)
SW Softwire, a shared-state "tunnel" created between the SC and SW Softwire, a shared-state "tunnel" created between the SC and
SI. (See [RFC4925]). 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, Cisco Systems Maria Alice Dos Santos, Cisco Systems
Carlos Pignataro, Cisco Systems Carlos Pignataro, Cisco Systems
Bill Storer, Cisco Systems Bill Storer, Cisco Systems
Jean-Francois Tremblay, Trellia Networks Jean-Francois Tremblay, Videotron Ltd.
Laurent Toutain, GET/ENST Bretagne Laurent Toutain, TELECOM Bretagne
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
skipping to change at page 7, line 33 skipping to change at page 7, line 40
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
regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP
"bypass" are optional requirements in Section 2.3 of [RFC4925]. "bypass" are optional requirements in Section 2.3 of [RFC4925].
As mentioned in Section 8.1 of [RFC2661] and Section 4 of [RFC3193],
an L2TP SCCRP responder (SC) can chose a different IP address and/or
UDP port than those from the initiator's SCCRQ (SI). This may or may
not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering
Behavior (see Section 5 of [RFC4787]). Specifically, any IP address
and port combination will work with Endpoint-Independent Filtering,
but changing IP address and port will not work through Address-
Dependent or Address and Port-Dependent Filtering. Given this,
responding from a different IP address and/or UDP port is NOT
RECOMMENDED.
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. Routing 2.3. Routing
skipping to change at page 8, line 30 skipping to change at page 8, line 49
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.7. Operations and Management (OAM) 2.7. Operations and Management
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 (see since the last data or control message was received on a tunnel (see
Section 5.5 of [RFC2661]). If the HELLO control message is not Section 5.5 of [RFC2661]). If the HELLO control message is not
reliably delivered, then the Control Channel and its Session will be reliably delivered, then the Control Channel and its Session will be
torn down. In the Softwire context, the L2TPv2 keepalive is used to torn down. In the Softwire context, the L2TPv2 keepalive is used to
monitor the connectivity status between the SI and SC and/or as a monitor the connectivity status between the SI and SC and/or as a
refresh mechanism for any NAT/NAPT translation entry along the access refresh mechanism for any NAT/NAPT translation entry along the access
link. link.
skipping to change at page 9, line 40 skipping to change at page 10, line 14
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
IPv4-only 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|
skipping to change at page 18, line 28 skipping to change at page 19, line 28
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].
* Updated by [RFC2868], [RFC3575], and [RFC5080].
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].
RFC 3162 "RADIUS and IPv6" [RFC3162]. RFC 3162 "RADIUS and IPv6" [RFC3162].
4.4. MIB 4.4. MIB
RFC 1471 "The Definitions of Managed Objects for the Link Control RFC 1471 "The Definitions of Managed Objects for the Link Control
skipping to change at page 22, line 37 skipping to change at page 23, line 37
Control Connection 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 Attribute Value Pairs Figure 11 describes the messages exchanged and Attribute Value Pairs
(AVPs) used to establish a tunnel between an SI (LAC) and an SC (AVPs) used to establish a tunnel between an SI (LAC) and an SC
(LNS). The messages and AVPs described here are only a subset of (LNS). The messages and AVPs described here are only a subset of
those defined in [RFC2661]. This is because Softwires use only a those defined in [RFC2661]. This is because Softwires use only a
subset of the L2TPv2 functionality. The subset of L2TP Control subset of the L2TPv2 functionality. The subset of L2TP Control
Connection Management AVPs that is applicable to Softwires is grouped Connection Management AVPs that is applicable to Softwires is grouped
into Mandatory AVPs and Optional AVPs (see Figure 11). Note that in into Required AVPs and Optional AVPs on a per control message basis
the Softwire environment, the SI always initiates the tunnel. L2TPv2 (see Figure 11). For each control message, Required AVPs include all
AVPs SHOULD NOT be hidden. the "MUST be present" AVPs from [RFC2661] for that control message,
and Optional AVPs include the "MAY be present" AVPs from [RFC2661]
that are used in the Softwire context on that control message. Note
that in the Softwire environment, the SI always initiates the tunnel.
L2TPv2 AVPs SHOULD NOT be hidden.
SC SI SC SI
|<--------SCCRQ---------| |<--------SCCRQ---------|
Mandatory AVPs: Required AVPs:
Message Type Message Type
Protocol Version Protocol Version
Host Name Host Name
Framing Capabilities Framing Capabilities
Assigned Tunnel ID Assigned Tunnel ID
Optional AVPs: Optional AVPs:
Receive Window Size Receive Window Size
Challenge Challenge
Firmware Revision Firmware Revision
Vendor Name Vendor Name
|---------SCCRP-------->| |---------SCCRP-------->|
Mandatory AVPs: Required AVPs:
Message Type Message Type
Protocol Version Protocol Version
Framing Capabilities Framing Capabilities
Host Name Host Name
Assigned Tunnel ID Assigned Tunnel ID
Optional AVPs: Optional AVPs:
Firmware Revision Firmware Revision
Vendor Name Vendor Name
Receive Window Size Receive Window Size
Challenge Challenge
Challenge Response Challenge Response
|<--------SCCCN---------| |<--------SCCCN---------|
Mandatory AVPs: Required AVPs:
Message Type Message Type
Optional AVPs: Optional AVPs:
Challenge Response Challenge Response
Figure 11: Control Connection Establishment Figure 11: Control Connection Establishment
In L2TPv2, generally, the tunnel between an LAC and LNS may carry the In L2TPv2, generally, the tunnel between an LAC and LNS may carry the
data of multiple users. Each of these users is represented by an data of multiple users. Each of these users is represented by an
L2TPv2 session within the tunnel. In the Softwire environment, the L2TPv2 session within the tunnel. In the Softwire environment, the
tunnel carries the information of a single user. Consequently, there tunnel carries the information of a single user. Consequently, there
is only one L2TPv2 session per tunnel. Figure 12 describes the is only one L2TPv2 session per tunnel. Figure 12 describes the
messages exchanged and the AVPs used to establish a session between messages exchanged and the AVPs used to establish a session between
an SI (LAC) and an SC (LNS). The messages and AVPs described here an SI (LAC) and an SC (LNS). The messages and AVPs described here
are only a subset of those defined in [RFC2661]. This is because are only a subset of those defined in [RFC2661]. This is because
Softwires use only a subset of the L2TPv2 functionality. The subset Softwires use only a subset of the L2TPv2 functionality. The subset
of L2TP Call Management AVPs that is applicable to Softwires is of L2TP Call Management (i.e., Session Management) AVPs that is
grouped into Mandatory AVPs and Optional AVPs (see Figure 12). Note applicable to Softwires is grouped into Required AVPs and Optional
that in the Softwire environment, the SI always initiates the AVPs on a per control message basis (see Figure 12). For each
session. No outgoing or analog calls are permitted. L2TPv2 AVPs control message, Required AVPs include all the "MUST be present" AVPs
SHOULD NOT be hidden. from [RFC2661] for that control message, and Optional AVPs include
the "MAY be present" AVPs from [RFC2661] that are used in the
Softwire context on that control message. Note that in the Softwire
environment, the SI always initiates the session. An L2TPv2 session
setup for a softwire uses only the incoming call model. No outgoing
or analog calls (sessions) are permitted. L2TPv2 AVPs SHOULD NOT be
hidden.
SC SI SC SI
|<--------ICRQ---------| |<--------ICRQ---------|
Mandatory AVPs: Required AVPs:
Message Type Message Type
Assigned Session ID Assigned Session ID
Call Serial Number Call Serial Number
|---------ICRP-------->| |---------ICRP-------->|
Mandatory AVPs: Required AVPs:
Message Type Message Type
Assigned Session ID Assigned Session ID
|<--------ICCN---------| |<--------ICCN---------|
Mandatory AVPs: Required AVPs:
Message Type Message Type
(Tx) Connect Speed (Tx) Connect Speed
Framing Type Framing Type
Figure 12: Session Establishment Figure 12: Session Establishment
The following sub-sections 5.1.1.1 through 5.1.1.3 describe in more
detail the Control Connection and Session establishment AVPs (see
message flows in Figures 11 and 12 respectively) that are required,
optional and not relevant for the L2TPv2 Tunnel establishment of a
Softwire. Specific L2TPv2 protocol messages and flows that are not
explicitly described in these sections are handled as defined in
[RFC2661].
The mechanism for hiding AVP Attribute values is used, as describred
in Section 4.3 of [RFC2661], to hide sensitive control message data
such as usernames, user passwords or IDs, instead of sending the AVP
contents in the clear. Since AVPs used in L2TP messages for the
Softwire establishment do not transport such sensitive data, L2TPv2
AVPs SHOULD NOT be hidden.
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 Softwire This section prescribes specific values for AVPs that are required
context that are Mandatory. (by [RFC2661]) to be present in one or more of the messages used for
the Softwire establishment, as they are used in the Softwire context.
It combines all the Required AVPs from all the control messages on
Section 5.1.1, and provides Softwire-specific use guidance.
Host Name AVP Host Name AVP
This AVP is mandatory in SCCRQ and SCCRP messages. This AVP may This AVP is required in SCCRQ and SCCRP messages. This AVP MAY be
be used to authenticate users, in which case it would contain a used to authenticate users, in which case it would contain a user
user identification. If this AVP is not used to authenticate identification. If this AVP is not used to authenticate users, it
users, it may be used for logging purposes. may be used for logging purposes.
Framing Capabilities AVP Framing Capabilities AVP
Both the synchronous (S) and asynchronous (A) bits SHOULD be set Both the synchronous (S) and asynchronous (A) bits SHOULD be set
to 1. This AVP SHOULD be ignored by the receiver. to 1. This AVP SHOULD be ignored by the receiver.
Framing Type AVP Framing Type AVP
The synchronous bit SHOULD be set to 1 and the asynchronous bit to The synchronous bit SHOULD be set to 1 and the asynchronous bit to
0. 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 required AVP but is not meaningful in the
Softwire context. Its value SHOULD be set 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 Softwire This section prescribes specific values for AVPs that are Optional
context that are Optional. (not required by [RFC2661]) but used in the Softwire context. It
combines all the Optional AVPs from all the control messages on
Section 5.1.1, and provides Softwire-specific use guidance.
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. See Section 5.1.1 of [RFC2661]. preventing DoS attacks. See Section 5.1.1 of [RFC2661].
The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD
be implemented in the SC. 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
message, are irrelevant to Softwires. Softwire implementations message, are irrelevant to Softwires. They can be irrelevant to
SHOULD NOT send these AVPs. However, they SHOULD ignore them when Softwires because they do not apply to the Softwire establishment
they are received. This will simplify the creation of Softwire flow (e.g., they are only used in the Outgoing Call establishment
applications that build upon existing L2TPv2 implementations. message exchange, while Softwires only use the Incoming Call message
flow), or because they are Optional AVPs that are not used. L2TPv2
AVPs that are relevant to Softwires were covered in Section 5.1.1,
Section 5.1.1.1, and Section 5.1.1.2. Softwire implementations
SHOULD NOT send AVPs that are not relevant to Softwires. However,
they SHOULD ignore them when they are received. This will simplify
the creation of Softwire applications that build upon existing L2TPv2
implementations.
5.1.2. Tunnel Maintenance 5.1.2. Tunnel Maintenance
Periodically, the SI/SC MUST transmit a message to the peer to detect Periodically, the SI/SC MUST transmit a message to the peer to detect
tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2
HELLO 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
skipping to change at page 26, line 22 skipping to change at page 28, line 12
and a maximum of the lesser of the configured L2TPv2 HELLO and a maximum of the lesser of the configured L2TPv2 HELLO
retransmission interval and 60 seconds. retransmission 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 Section 5.7 of [RFC2661], by sending a StopCCN done as specified in Section 5.7 of [RFC2661], by sending a StopCCN
control message. There is no action specific to Softwires in this control message. There is no action specific to Softwires in this
case. case.
5.1.4. Additional L2TPv2 Considerations
In the Softwire "Hub and Spoke" framework, L2TPv2 is layered on top
of UDP, as part of an IP-in-IP tunnel; Section 8.1 of [RFC2661]
describes L2TP over UDP/IP. Therefore, the UDP guidelines specified
in [RFC5405] apply, as they pertain to the UDP tunneling scenarios
carrying IP-based traffic. Section 3.1.3 of [RFC5405] specifies that
for this case, specific congestion control mechanisms for the tunnel
are not necessary. Additionally, Section 3.2 of [RFC5405] provides
message size guidelines for the encapsulating (outer) datagrams,
including the recommendation to implement Path MTU Discovery (PMTUD).
5.2. PPP Connection 5.2. PPP Connection
This section describes the PPP negotiations between the SI and SC in This section describes the PPP negotiations between the SI and SC in
the Softwire context. the Softwire context.
5.2.1. MTU 5.2.1. MTU
The MTU of the PPP link presented to the SPH SHOULD be the link MTU The MTU of the PPP link presented to the SPH SHOULD be the link MTU
minus the size of the IP, UDP, L2TPv2, and PPP headers together. On minus the size of the IP, UDP, L2TPv2, and PPP headers together. On
an IPv4 link with an MTU equal to 1500 bytes, this could typically an IPv4 link with an MTU equal to 1500 bytes, this could typically
mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, mean a PPP MTU of 1460 bytes. When the link is managed by IPsec,
this MTU should be lowered to take into account the ESP encapsulation this MTU SHOULD be lowered to take into account the ESP encapsulation
(see [I-D.ietf-softwire-security-requirements]). The value for the (see [I-D.ietf-softwire-security-requirements]). The value for the
MTU may also vary according to the size of the L2TP header, as MTU may also vary according to the size of the L2TP header, as
defined by the leading bits of the L2TP message header (see defined by the leading bits of the L2TP message header (see
[RFC2661]). 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] MAY 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 Softwire 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
skipping to change at page 27, line 28 skipping to change at page 29, line 29
In the IPv6 over IPv4 scenarios (see Section 3.1), after the optional 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 Assignment to Endpoints 5.3. Global IPv6 Address Assignment to Endpoints
In several scenarios defined in Section 3.1, Global IPv6 addresses In several scenarios defined in Section 3.1, Global IPv6 addresses
are expected to be allocated to Softwire endpoints (in addition to are expected to be allocated to Softwire endpoints (in addition to
the Link-Local addresses autoconfigured using the IPV6CP negotiated the Link-Local addresses autoconfigured using the IPV6CP negotiated
interface identifier). The Softwire Initiator assigns global IPv6 interface identifier). The Softwire Initiator assigns global IPv6
addresses using the IPV6CP negotiated interface identifier and using addresses using the IPV6CP negotiated interface identifier and using
Stateless Address Autoconfiguration [RFC4862], and/or using Privacy Stateless Address Autoconfiguration [RFC4862], and/or using Privacy
skipping to change at page 29, line 27 skipping to change at page 31, line 28
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 endpoints in a Addresses (ULA) [RFC4193] may be used to address Softwire endpoints
private network with no global connectivity. A single /64 should be in a private network with no global connectivity. A single /64
assigned to the Softwire to address both Softwire endpoints. should be 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
scenario "Host CPE as Softwire Initiator" (described in scenario "Host CPE as Softwire Initiator" (described in
Section 3.1.1) is considered to be deployed. For other scenarios, Section 3.1.1) is considered to be deployed. For other scenarios,
this may be optional and link local addresses should be used. link local addresses may also be used.
6.1.2. IPv4 6.1.2. IPv4
A Softwire Concentrator may provide either globally routable or A Softwire Concentrator may provide either globally routable or
private IPv4 addresses. When using IPv4 private addresses [RFC1918] private IPv4 addresses. When using IPv4 private addresses [RFC1918]
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.
skipping to change at page 32, line 19 skipping to change at page 34, line 32
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 [RFC3162] is included, 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 from 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
skipping to change at page 33, line 20 skipping to change at page 35, line 34
server. 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
Existing protocol mechanics for conveying adjunct or accessory
information for logging purposes, including L2TPv2 and RADIUS
methods, can include informational text that the behavior is
according to the Softwire "Hub and Spoke" framework (following the
implementation details specified in this document).
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 Softwire 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].
skipping to change at page 33, line 47 skipping to change at page 36, line 22
A detailed discussion of Softwire 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 Softwire 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. Other
authentication protocols may additionally be supported (see
Section 5.2.3).
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 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
authenticating the tunnel before L2TP session and PPP resources authenticating the tunnel before L2TP session and PPP resources
are allocated. are allocated.
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
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, Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley,
Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand. Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand.
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://www.ietf.org/proceedings/06mar/isoftwire.html>. The minutes
minutes for the interim meeting at Polytechnic University of for the interim meeting at Polytechnic University of Catalonia -
Catalonia - Barcelona (September 14-15, 2006) are reachable at <http: Barcelona (September 14-15, 2006) are reachable at
//bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>. <http://www.ietf.org/proceedings/06nov/isoftwire.html>. The
Softwires auxiliary page at <http://bgp.nu/~dward/softwires/>
contains additional meeting information.
During and after the IETF Last Call, useful comments and discussion
were provided by Jari Arkko, David Black, Lars Eggert, Pasi Eronen,
and Dan Romascanu.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
skipping to change at page 37, line 14 skipping to change at page 39, line 46
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.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
skipping to change at page 37, line 37 skipping to change at page 40, line 25
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006. August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
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 -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: Changes between -09 and -10:
o Fixed a number of typos. o Fixed a number of typos.
Changes between -08 and -09: Changes between -08 and -09:
o Refresh version about to expire, no other changes. o Refresh version about to expire, no other changes.
Changes between -07 and -08: Changes between -07 and -08:
skipping to change at page 38, line 47 skipping to change at page 42, line 4
[RFC3633], [RFC2131], and [RFC2132]. [RFC3633], [RFC2131], and [RFC2132].
o Moved the last two sentences of Section 5.4 to Section 5.4.1 and o Moved the last two sentences of Section 5.4 to Section 5.4.1 and
Section 5.4.2 respectively. Section 5.4.2 respectively.
o Completed the first paragraph of Section 5.3, adding an o Completed the first paragraph of Section 5.3, adding an
informational reference to [RFC4941]. informational reference to [RFC4941].
o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added o Added DHCPv4 to Figure 10 for the IPv4 over IPv6 scenarios. Added
a follow-on clarifying paragraph about PPP NCP and DHCP versions a follow-on clarifying paragraph about PPP NCP and DHCP versions
used in each softwire scenario. used in each Softwire scenario.
o Clarification of implementation versus usage of the optional AVPs o Clarification of implementation versus usage of the optional AVPs
in Section 5.1.1.2. in Section 5.1.1.2.
o Added text including [RFC3736] for DHCPv6. 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
skipping to change at page 44, line 39 skipping to change at page 48, line 4
Email: mariados@cisco.com Email: mariados@cisco.com
Bruno Stevant (editor) Bruno Stevant (editor)
TELECOM 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@telecom-bretagne.eu Email: bruno.stevant@telecom-bretagne.eu
Jean-Francois Tremblay Jean-Francois Tremblay
Trellia Networks Videotron Ltd.
100, Alexis-Nihon, Suite 770 612 Saint-Jacques
Montreal, QC H4M 2P3 Montreal, QC H3C 4M8
Canada Canada
Email: jf@jftremblay.com Email: jf@jftremblay.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 68 change blocks. 
145 lines changed or deleted 265 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/