Softwires Working Group B. Storer, Ed.
Internet-Draft C. Pignataro, Ed.
Expires: December 18, 2006 M. Dos Santos, Ed.
Cisco Systems
J. Tremblay, Ed.
Hexago
L. Toutain, Ed.
GET/ENST Bretagne
June 16, 2006
Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the framework of the Softwire "Hubs and
Spokes" solution with Layer 2 Tunneling Protocol (L2TPv2), and the
implementation details specified in this document should be followed
Storer, et al. Expires December 18, 2006 [Page 1]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
to achieve inter-operability among different vendor implementations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 6
2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 7
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 13
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 13
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 17
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Authentication Authorization Accounting . . . . . . . . . 18
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18
5. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Link Addresses . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 20
5.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 20
5.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 20
Storer, et al. Expires December 18, 2006 [Page 2]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
6. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
6.1. L2TP Tunnel Setup . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Tunnel Establishement . . . . . . . . . . . . . . . . 23
6.1.1.1. AVPs Required for Sotftwires . . . . . . . . . . . 25
6.1.1.2. AVPs Optional for Sotftwires . . . . . . . . . . . 26
6.1.1.3. AVPs not Required for Softwires . . . . . . . . . 26
6.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
6.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27
6.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27
6.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28
6.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 28
6.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
7. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 29
7.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30
7.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
7.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
7.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30
8. Maintenance and Statistics . . . . . . . . . . . . . . . . . . 30
8.1. Radius Accounting . . . . . . . . . . . . . . . . . . . . 30
8.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Comparison with softwire security analysis . . . . . . . . 30
9.2. Additional security issues introduced by the
integration of the different protocols . . . . . . . . . . 30
10. Implementation status . . . . . . . . . . . . . . . . . . . . 30
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Fragmentation and MTU . . . . . . . . . . . . . . . . . . 31
11.2. AAA Accounting (other draft) . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Storer, et al. Expires December 18, 2006 [Page 3]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
14.1. Normative References . . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Storer, et al. Expires December 18, 2006 [Page 4]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol
(L2TPv2) as the phase I protocol to be deployed in the Softwires
"Hubs and Spokes" solution space. This document describes the
framework for the L2TPv2 "Hubs and Spokes" solution, and the
implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations.
In the "Hubs and Spokes" solution space, a Softwire is established to
provide the home network with IPv4 connectivity across an IPv6-only
access network or IPv6 connectivity across an IPv4-only access
network. When L2TPv2 is used in the Softwire context, the voluntary
tunneling model applies. The Softwire Initiator (SI) at the home
network takes the role of the L2TP Access Concentrator (LAC) client
(initiating both the L2TP tunnel/session and PPP link) while the
Softwire Concentrator (SC) at the ISP takes the role of the L2TP
Network Server (LNS). Since L2TPv2 compulsory tunneling model does
not apply to Softwires, it should not be requested or honored. This
document identifies all the voluntary tunneling related L2TPv2
attributes that apply to Softwires and specifies the handling
mechanism for such attributes in order to avoid ambiguities in
implementations. This document also identifies the set of L2TPv2
attributes specific to compulsory tunneling model that do not apply
to Softwires and specifies the mechanism to ignore or nullify their
effect within the Softwires context.
The SI and SC must follow the L2TPv2 operations described in
[RFC2661] when performing Softwire establishment, tear-down and OAM.
With L2TPv2, a Softwire consists of an L2TPv2 Control Channel, a
single Session, and the PPP link negotiated over the Session. To
establish the Softwire, the SI first initiates an L2TPv2 Control
Channel to the SC which accepts the request and terminates the
Control Channel. L2TPv2 supports an optional mutual Control Channel
authentication which allows both SI and SC to validate each other's
identity at the initial phase of hand-shaking before proceeding with
Control Channel establishment. After the L2TPv2 Control Channel is
established between the SI and SC, the SI initiates an L2TPv2 Session
to the SC. Then the PPP/IP link is negotiated over the L2TPv2
Session between the SI and SC. After the PPP/IP link is established,
it acts as the Softwire between the SI and SC for tunneling IP
traffic of one Address Family across the access network of another
Address Family.
During the life of the Softwire, both SI and SC may send L2TPv2
keepalive HELLO messages to monitor the health of the Softwire and
the peer LCCE or to refresh the NAT/PAT translation entry at the CPE
or at the other end of the access link. In the event of keepalive
Storer, et al. Expires December 18, 2006 [Page 5]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
timeout or administrative shutdown of the Softwire, either SI or SC
may tear down the Softwire by tearing down the L2TPv2 Control Channel
and Session as specified in [RFC2661].
1.1. Abbreviations
LCCE L2TP Control Connection Endpoint (See [RFC3931])
SC Softwire Concentrator, the node terminating the softwire in
the service provider network (See [I-D.ietf-softwire-problem-
statement])
SI Softwire Initiator, the node initiating the softwire within
the customer network (See [I-D.ietf-softwire-problem-
statement])
STH Softwire Transport Header (See [I-D.ietf-softwire-problem-
statement])
SPH Softwire Payload Header (See [I-D.ietf-softwire-problem-
statement])
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Contributing Authors
Following is the complete list of contributors to this document.
Maria Alice Dos Santos
Carlos Pignataro
Bill Storer
Cisco Systems
Jean-Francois Tremblay
Hexago
Laurent Toutain
GET/ENST Bretagne
2. Applicability of L2TPv2 for Softwire Requirements
A list of Softwire "Hubs and Spokes" requirements have been
identified by the Softwire Problem Statement [I-D.ietf-softwire-
problem-statement]. The following section describes how L2TPv2
fulfills each of them.
Storer, et al. Expires December 18, 2006 [Page 6]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
2.1. Network and Port Address Translation (NAT/PAT)
A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case
the scenario in question involves a non-upgradable pre-existing IPv4
home gateway performing NAT/PAT or some carrier equipment at the
other end of the access link performing NAT/PAT. The L2TPv2 Softwire
(i.e. Control Channel and Session) is capable of NAT/PAT traversal
since L2TPv2 can run over UDP.
Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2
does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/
PAT "autodetect" and UDP bypass are optional requirements.
2.2. Scalability
In the "Hubs and Spokes" model, a carrier must be able to scale the
solution to millions of softwire initiators by adding more hubs (i.e.
softwire concentrators). L2TPv2 is a widely deployed protocol in
broadband services, and its scalability has been proven in multiple
large-scale IPv4 Virtual Private Network deployments which scale up
to millions of subscribers each.
2.3. Multicast
Multicast protocols simply run over L2TPv2 Softwires transparently
together with other regular IP traffic.
2.4. Authentication, Authorization and Accounting
L2TPv2 supports optional mutual Control Channel authentication and
leverages the optional mutual PPP per-session authentication. L2TPv2
is well integrated with AAA solutions (such as RADIUS) for both
authentication and authorization. Most L2TPv2 implementations
available in the market support logging of authentication and
authorization events.
L2TPv2 integration with RADIUS accounting (RADIUS Accounting
extension for tunnel [RFC2867]) allows the collection and reporting
of L2TPv2 Softwire usage statistics.
2.5. Privacy, Integrity, and Replay Protection
Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can
be used in conjunction to provide per-packet authentication,
integrity, replay protection and confidentiality for both L2TPv2
control and data traffic [RFC3193] and [RFC3948].
For Softwire deployments in which full payload security is not
Storer, et al. Expires December 18, 2006 [Page 7]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
required, the L2TPv2 built-in Control Channel authentication and the
inherited PPP authentication and PPP Encryption Control Protocol can
be considered.
2.6. Operations and Management (OAM)
L2TPv2 supports an optional in-band keepalive mechanism which injects
HELLO control messages after a specified period of time has elapsed
since the last data or control message was received on a tunnel. If
the HELLO control message is not reliably delivered, then the Control
Channel and its session will be torn down. In the Softwire context,
the L2TPv2 keepalive can be used to monitor connectivity status
between the SI and SC and/or as a refresh mechanism for any NAT/PAT
translation entry along the access link.
L2TPv2 MIB [RFC3371] supports the complete suite of management
operations such as configuration of Control Channel and Session,
polling of Control Channel and Session status and their traffic
statistics and notifications of Control Channel and Session UP/DOWN
events.
2.7. Encapsulations
L2TPv2 supports the following encapsulations:
o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not
support "autodetect" of NAT/PAT.
3. Deployment Scenarios
For the "Hubs and Spokes" problem space, four scenarios have been
identified. In each of these four scenarios, different home
equipment plays the role of the Softwire Initiator. This section
elaborates each scenario with L2TPv2 as the Softwire protocol and
other possible protocols involved to complete the solution. This
section examines the four scenarios for both IPv6 over IPv4 and IPv4
over IPv6 encapsulations.
Storer, et al. Expires December 18, 2006 [Page 8]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
3.1. IPv6 over IPv4 Softwire with L2TPv2
3.1.1. Host CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network Softwire
Transport Header (STH). Softwire initiator is the host CPE (directly
connected to a modem), which is dual-stack. There is no other
gateway device. The IPv4 traffic should not traverse the softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the
host CPE or perform uniqueness validation for the two Interface Ids
at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the host CPE via Router Advertisement (RA)
while other configuration options (such as DNS) can be conveyed to
the host CPE via DHCPv6/v4.
#### Get more details on DHCPv6/v4 attributes.
Storer, et al. Expires December 18, 2006 [Page 9]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4
"softwire"
<------------------>
IPv6CP: capable of /64 intf Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>DNS, etc
DHCPv6/v4
Figure 1: Host CPE as Softwire Initiator
3.1.2. Router CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). Softwire
initiator is the router CPE, which is a dual-stack device. The IPv4
traffic should not traverse the softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the
router CPE or perform uniqueness validation for the two Interface Ids
at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the router CPE via Router Advertisement (RA).
DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating
a 48-bit prefix to be used within the home network) and convey other
configuration options (such as DNS) to the router CPE.
Storer, et al. Expires December 18, 2006 [Page 10]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||---------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4
"softwire"
<------------------>
IPv6CP: capable of /64 intf Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>/48 prefix,
DHCPv6 DNS, etc
|------->/64 prefix
RA
|-------> DNS, etc
DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator
3.1.3. Host behind CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). The CPE
is IPv4-only. Softwire initiator is a dual-stack host (behind IPv4-
only CPE), which acts as an IPv6 host CPE. The IPv4 traffic should
not traverse the softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the
host or perform uniqueness validation for the two Interface Ids at
the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the host via Router Advertisement (RA) while
other configuration options (such as DNS) can be conveyed to the host
via DHCPv6/v4.
Storer, et al. Expires December 18, 2006 [Page 11]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic
"softwire"
<------------------------------>
IPv6CP: capable of /64 intf Id assignment or
uniqueness check
|------------------------------>/64 prefix
RA
|------------------------------>DNS, etc
DHCPv4/v6
Figure 3: Host behind CPE as Softwire Initiator
3.1.4. Router behind CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). The CPE
is IPv4-only. Softwire initiator is a dual-stack device (behind the
IPv4-only CPE) acting as an IPv6 CPE router inside the home network.
The IPv4 traffic should not traverse the softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the
v4/v6 router or perform uniqueness validation for the two Interface
Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up,
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
assign a 64-bit global prefix to the v4/v6 router via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (for example, delegating a 48-bit prefix to be used within
the home network) and convey other configuration options (such as
DNS) to the v4/v6 router.
Storer, et al. Expires December 18, 2006 [Page 12]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-------------------------||-------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
---------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--IPv6 traffic
PPP o L2TPv2 o UDP o IPv4
"softwire"
<--------------------------->
IPv6CP: capable of /64 intf Id assignment or
uniqueness check
|--------------------------->/64 prefix
RA
|--------------------------->/48 prefix,
DHCPv6 DNS, etc
|----> /64
RA prefix
|----> DNS,
DHCPv4/v6 etc.
Figure 4: Router behind CPE as Softwire Initiator
3.2. IPv4 over IPv6 Softwire with L2TPv2
3.2.1. Host CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). Softwire
initiator is the host CPE (directly connected to a modem), which is
dual-stack. There is no other gateway device. The IPv6 traffic
should not traverse the softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
host CPE. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
Storer, et al. Expires December 18, 2006 [Page 13]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
via IPCP [RFC1877] or DHCP.
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||---------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6
"softwire"
<------------------>
IPCP: capable of global IP assignment
and DNS, etc
Figure 5: Host CPE as Softwire Initiator
3.2.2. Router CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). Softwire
initiator is the router CPE, which is a dual-stack device. The IPv6
traffic should not traverse the softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
router CPE. Global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the
router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
Storer, et al. Expires December 18, 2006 [Page 14]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6
"softwire"
<------------------>
IPCP: capable of global IP assignment
and DNS, etc
|------------------>
DHCPv4: prefix, mask, PD
private/
|------> global
DHCP IP, DNS,
etc.
Figure 6: Router CPE as Softwire Initiator
3.2.3. Host behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. Softwire initiator is a dual-stack host (behind the
IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should
not traverse the softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
host. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP.
Storer, et al. Expires December 18, 2006 [Page 15]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
PPP o L2TPv2 o UDP o IPv6 traffic
"softwire"
<------------------------------>
IPCP: capable of global IP assignment
and DNS, etc
Figure 7: Host behind CPE as Softwire Initiator
3.2.4. Router behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. Softwire initiator is a dual-stack device (behind the
IPv6-only CPE) acting as an IPv4 CPE router inside the home network.
The IPv6 traffic should not traverse the softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 IP address to the
v4/v6 router. Global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the
v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
Storer, et al. Expires December 18, 2006 [Page 16]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
--------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
PPP o L2TPv2 o UDP o IPv4 traffic
"softwire"
<--------------------------->
IPCP: assigns global IP address and DNS, etc
|--------------------------->
DHCPv4: prefix, mask, PD
private/
|----> global
DHCP IP, DNS,
etc.
Figure 8: Router behind CPE as Softwire Initiator
4. Standardisation Status
4.1. Softwire Transport Related
RFC 3193 Securing L2TP using IPsec.
RFC 3948 UDP Encapsulation of IPsec ESP Packets.
IPSec supports both IPv4 and IPv6 transports.
4.2. L2TPv2
Storer, et al. Expires December 18, 2006 [Page 17]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
RFC 2661 Layer Two Tunneling Protocol "L2TP".
For both IPv4 and IPv6 payloads, support is complete.
For both IPv4 and IPv6 transport, support is complete.
4.3. Authentication Authorization Accounting
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol
Support.
Need new extensions for IPv6 traffic accounting
[I-D.stevant-softwire-accounting].
RFC 2865 Remote Authentication Dial In User Service (RADIUS).
RFC 3162 RADIUS and IPv6.
4.4. MIB
RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information
Base.
RFC 4087 IP Tunnel MIB.
Both IPv4 and IPv6 transport is supported.
Do we need a new set of counters for IPv6 Payloads?
l2tpDomainStatsPayloadHCRxOctets
l2tpDomainStatsPayloadHCRxPkts
l2tpDomainStatsPayloadHCRxDiscs
l2tpDomainStatsPayloadHCTxOctets
l2tpDomainStatsPayloadHCTxPkts
4.5. Softwire Payload Related
4.5.1. For IPv6 Payloads
RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2].
RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC 3646 DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6).
RFC 2461 Neighbor Discovery for IP Version 6 (IPv6).
4.5.2. For IPv4 Payloads
Storer, et al. Expires December 18, 2006 [Page 18]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
RFC 1661 The Point-to-Point Protocol (PPP).
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP).
DHCP Subnet Allocation
Work in progress [I-D.ietf-dhc-subnet-alloc].
5. Provisioning Model
A softwire can provide stable addressing even if the underlying
addressing scheme changes, by opposition to automatic tunneling. A
Softwire Concentrator SHOULD always provide the same address and
prefix to a reconnecting user. However, if the goal of the softwire
service is to provide a temporary address for a roaming user, it MAY
be provisioned to provide only a temporary address.
The address and prefix is expected to change when reconnecting to a
different Softwire Concentrator. However an organization providing a
softwire service MAY provide the same address and prefix across
different Softwire Concentrators at the cost of a more fragmented
routing table. The routing fragmentation issue may be limited if the
prefixes are aggregated in a location topologically close to the SC.
This would be the case for example if several SCs are put in parallel
for load-balancing purpose.
5.1. Link Addresses
5.1.1. IPv6
A Softwire Concentrator SHOULD provide globally routable addresses
and prefixes to Softwire Initiators. Other types of addresses such
as Unique Local Addresses [RFC4193] MAY be used to connect to a
private network with no global connectivity.
A single /64 SHOULD be reserved for the PPP link. That /64 MAY be
part of the prefix delegated to the SI.
5.1.2. IPv4
A Softwire Concentrator MAY provide either globally routable or
private IPv4 addresses. If private addresses are used, the delegated
prefix should be in the same address space than the PPP endpoint to
avoid nested NAT configurations. A globally routable address is
preferable, since in most cases, it is expected the CPE device will
perform the IPv4 NAT function.
The PPP link for the IPv4 softwire SHOULD be assigned a /30.
Storer, et al. Expires December 18, 2006 [Page 19]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
5.2. Delegated Prefixes
5.2.1. IPv6 Prefixes
Delegated IPv6 prefixes are between /48 and /64 in length. A CPE
device receiving a /64 is expected to perform bridging if more than
one interface is available (wired and wireless for example).
The length of delegated IPv6 prefixes SHOULD be a multiple of 4.
Reverse DNS delegation of IPv6 prefixes that are not multiples of 4
is more complex since more than one record must be inserted in the
zone file. In the worst case, up to 8 records have to be entered for
one prefix if the prefix length is equal to a multiple of 4 plus 1
(/61 for example).
Example:
One NS record is required for the reverse DNS delegation of 2001:
db8:1:10::/60
NS 1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
Several (8) NS records are required for the reverse DNS delegation
of 2001:db8:1:10::/61
NS 0.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 1.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 2.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 3.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 4.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 5.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 6.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 7.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
5.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be of the same scope than the assigned
IPv4 addresses and be routable within that address space. Prefix
length is between /8 and /30. However, the DNS reverse delegation of
prefixes that are not multiples of 8 may be problematic. In the
worst case of a one bit difference, for example a /25, 128 NS records
Storer, et al. Expires December 18, 2006 [Page 20]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
must be configured in the reverse zone file.
6. Softwire Establishment
A softwire is established in 3 distinct steps (figure 1). First a
L2TP tunnel with a single session is established from the SI to the
SC. Second a PPP session is established over the L2TP session and
the SI get an address. Third the SI optionally gets other
information through DHCP such as a delegated prefix and DNS servers.
SC SI
| |
|<-------------L2TP-------------->| L2TP
| |
|<-------------PPP--------------->| PPP and
|<-------Neighbor Discovery------>| configuration
| |
|<-------------DHCP-------------->| Additional
| | configuration
| | (optional)
Figure 9: Steps for the Establishment of a Softwire
Storer, et al. Expires December 18, 2006 [Page 21]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
SC SI
| |
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCSN---------------| | L2TP
|<------------ICRQ----------------| |
|-------------ICCN--------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|<-------Configuration-Ack--------| | LCP
|--------Configuration-Ack------->| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|<-------Configuration-Ack--------| | (IPV6P or IPCP)
|--------Configuration-Ack------->| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
|<-----------Solicit--------------| -
|-----------Advertise------------>| | DHCP
|<---------- Request--------------| | (Optional)
|-------------Reply-------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire
6.1. L2TP Tunnel Setup
L2TPv2 [RFC2661] was initially designed to connect Network Access
Server (NAS) concentrating traffic from multiple equipments and
Internet Access Providers (IAP). In L2TP terminology, an L2TP
Network Server (LNS) is an equipment concentrating L2TP connection
coming from L2TP Access Concentrator (LAC) dispatched on the IP
network. In the Softwires Hub and Spoke model, LAC will act as the
Softwires Initiator (SI) and LNS as the Softwires Concentrator (SC).
SI can be located on the end user equipment, a special gateway
dedicated to handle IPv6 traffic or directly on the home gateway.
L2TP packet, in the softwires model MUST be carried over UDP,
underlying version of the IP protocol may be IPv4 or IPv6, depending
on the transition scenario deployed.
Storer, et al. Expires December 18, 2006 [Page 22]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
6.1.1. Tunnel Establishement
The following diagram resumes messages exchange and AVP used to
establish a communication between a SI (LAC) and a SC (LNS). They
represent a subset of exchanges defined in [RFC2661] mostly to limit
implementation complexity on the SI side. One session per tunnel is
only needed, since the LAC does not act as a PPP session
concentrator. The LAC MUST always establishes the session and no
outgoing nor analogical calls are specified. L2TP attributes SHOULD
NOT be hidden.
Storer, et al. Expires December 18, 2006 [Page 23]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
LAC (SI) LAC (SC)
---------- ----------
SCCRQ ->
Mandatory AVP
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
Optional AVP:
Receive Window Size
Firmware Revision
Vendor Name
(Challenge)
<- SCCRP
Mandatory AVP:
Message Type
Protocol Version
Framing Capabilities
Host Name
Assigned Tunnel ID
Optional AVP:
Firmware Revision
Vendor Name
Receive Window Size
(Challenge Response)
(Challenge)
SCCCN ->
Mandatory AVP:
Message Type
(Challenge Response)
<- ZLB ACK
Figure 11: Tunnel Establishement
Storer, et al. Expires December 18, 2006 [Page 24]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
LAC (SI) LAC (SC)
---------- ----------
ICRQ ->
Mandatory AVP:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP:
Message Type
(Tx) Connect Speed
Framing Type
<- ZLB ACK
Figure 12: Session Establishement
This paragraph specifies specific values for AVP used in the
Softwires context.
6.1.1.1. AVPs Required for Sotftwires
Host Name AVP
This AVP is mandatory and is present in SCCRQ and SCCRP messages.
This AVP is for debugging purpose and should not be used to
authenticate users.
For the LNS, the hostname COULD be the server name with the fully
qualified domain. For the LAC, the name COULD be
user-id@name.fully-qualified-domain. If name or fully-qualified-
domain is not configured (since the equipment is in the bootstrap
phase) this part CAN be left blank. User-id is the value used to
authenticate the user. If user-id is not defined, "Softwires"
COULD be used.
Framing Capabilities AVP
Synchronous bit MUST be set to 1 and Asynchronous bit to 0. This
AVP SHOULD be ignored by the receiver.
Framing Type AVP
Storer, et al. Expires December 18, 2006 [Page 25]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
Synchronous bit MUST be set to 1and Asynchronous bit to 0. This
AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed
(Tx) Connect Speed is a mandatory AVP but is meaningful in
Softwires context. Value should be left to 0 and ignored by the
receiver.
Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor
Name, Call Serial Number, and Assigned Session ID
As defined in [RFC2661]
6.1.1.2. AVPs Optional for Sotftwires
Challenge and Challenge Response AVPs
Session authentication as defined in [RFC2661] is based on a
shared secret known by LACs and LNSs, and is not designed to
authenticate a specific user. This AVP is not required since
security enhancement is not guaranteed. It can be used to limit
DoS attack but since this secret has to be known by all users
accessing the service, an attacker can learn it easily.
While user authentication is typically done at the PPP level,
tunnel authentication may be helpful in preventing DoS attacks.
6.1.1.3. AVPs not Required for Softwires
L2TP specifies numerous AVPs that, while allowed for a given command,
are irrelevant to a Softwires. Softwires implementations should not
send these AVPs. However, they should ignore them when they are
received. This will make it easier to create Softwires applications
on top of existing L2TP implementations.
6.1.2. Tunnel Maintenance
Periodically, SI must transit some message to the SC to maintain
context in the NAT and can be used to detected tunnel failure (but
PPP/LCP may be more reactive). LNS and LAC can generate HELLO
messages. As specified in [RFC2661] HELLO messages SHOULD be
generated if no other messages are sent for a period of time. The
value of 60 seconds recommended by [RFC2661] fulfills Softwires
constraints.
Storer, et al. Expires December 18, 2006 [Page 26]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
6.1.3. Tunnel Teardown
SI and SC can teardown the session and then the tunnel. No change or
specific parameter are required compared to [RFC2661]. The SI or the
SC sends an CDN message, acknowledged by ZLB message. The initiator
of the tunnel teardown, MUST immediately after close the tunnel by
sending a StopCCN message, acknowledged by a ZLB message.
6.2. PPP Connection
6.2.1. MTU
The MTU of the PPP link SHOULD be the link MTU minus the size of the
IP, UDP and L2TP headers together. On a link with a MTU equal to
1500 bytes, this would usually mean a PPP MTU of 1472 bytes. This
may vary according to the size of the L2TP header.
In order to optimize the link efficiency and prevent fragmentation, a
path MTU discovery algorithm may be used to detect the maximum MTU on
the path between the SI and the SC. However path MTU discovery is
out of scope for this document.
6.2.2. LCP
Once the L2TP session is established, the SI initiates the PPP
connection by sending a LCP Configuration Request message. The SC
also sends a LCP Configuration Request containing at least the
Maximum Receive Unit option and and authentication protocol. If no
authentication protocol option is present, the SI considers the
service as un authenticated (see Section 6.2.3). Each party answers
with a Configuration Ack message to finish the link configuration.
### Laurent, do you have an example for this section?
6.2.3. Authentication
After sending the LCP Configuration Ack, the SC proceeds with the PPP
authentication phase. CHAP [RFC1994] authentication MUST be
supported by both the Softwire Initiator and Softwire Concentrator.
Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
be supported.
The Softwire Concentrator MAY allow non-authenticated connection. In
that case, the SC acts as a gateway for anonymous connections. This
approach is better than an open relay implementation since ingress
filtering is performed on established tunnels (see Section 9). If
non-authenticated connections are supported by the SC, enabling this
function MUST be configurable by the SC administrator.
Storer, et al. Expires December 18, 2006 [Page 27]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
6.2.4. IPCP
6.2.4.1. IPv6CP
After the authentication phase, the Softwire Initiator MUST send an
IPV6CP Configuration-Request message [RFC2472] containing an
Interface Identifier. The Interface Identifier SHOULD be of the IEEE
EUI-64 format. A Configuration-Request message is also sent by the
SC. If that message constrains a different Interface Identifier, it
MUST be accepted through a Configure-Ack message.
6.2.4.2. IPv4CP
A Softwire Initiator establishing an IPv4 softwire SHOULD send a
Configuration-Request with all four octets of the IP-Address
configuration option set to 0 (see [RFC1332]). If all four octets of
the IP-Address option received from the Softwire Concentrator are set
to 0, the SI MUST request an address through DHCP, otherwise the
address is accepted.
6.3. Neighbor Discovery
The Softwire Initiator of an IPv6 softwire MUST send a Router
Sollicitation message to the Softwire Concentrator after IPV6CP is
completed. The Softwire Concentrator MUST answer with a Router
Advertisement containing the global IPv6 prefix of the PPP link.
Duplicate Address Detection (DAD) is redundant in that context and
doesn't have to be performed. For that purpose,
DupAddrDetectTransmits autoconfiguration variable to zero [RFC2472]
[RFC2462].
If DHCPv6 is available, the M bits of the Router Advertisement SHOULD
be set.
6.4. DHCP
The Softwire Initiator MAY use DHCP to get additional information
such as delegated prefix and DNS servers. If the SI supports DHCP,
it SHOULD send a Solicit message to verify if more information is
available.
6.4.1. DHCPv6
IF a SI establishing an IPv6 Softwire acts as a router (scenarios
3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the
DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.
Storer, et al. Expires December 18, 2006 [Page 28]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
6.4.2. DHCPv4
A SI establishing an IPv4 softwire MAY send a DHCP request containing
the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. One
Subnet-Request suboption MUST be configured with the 'h' bit set to
'1', as the SI is expected to perform the DHCP server function. The
'i' bit of the Subnet-Request suboption should be set to '0' the
first time a prefix is requested and to '1' on subsequent requests,
if a prefix has been allocated. The Prefix length suboption SHOULD
be 0 by default. If the SI is configured to support only specific
prefix lengths, it should specify the longest (smallest) prefix
length it supports.
If the SI was previously assigned a prefix from that same SC, it
SHOULD include the Subnet Information suboption with the prefix it
was previously assigned. The 'c' and 's' bits of the suboption
SHOULD be set to '0'.
7. AAA
The Softwire Concentrator is expected to act as a client to a AAA
server, for example a Radius server. During the PPP authentication
phase, the AAA server may return additional information in the form
of attributes in the Access Accept message.
The Softwire Concentrator MAY include the Tunnel-Medium and Tunnel-
Medium-Type attributes [RFC2868] in the Access Request messages to
provide a hint of the type of softwire being configured.
7.1. Tunnel Endpoints
7.1.1. IPv6 Softwires
If the AAA server includes a Framed-Interface-Id attribute [RFC3162],
the Softwire Concentrator MUST send it to the Softwire Initiator in
the Interface Identifier field of its IPV6CP Configuration Request
message.
If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that
prefix MUST be used in the router advertisements sent to the SI. If
Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
MUST choose a prefix with that pool to send router advertisements.
If none of the attributes above are included but the AAA server
returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
attributes [RFC2868] are present and of the correct address family,
these MUST be used in the IPV6CP Interface Identifier and for the
Storer, et al. Expires December 18, 2006 [Page 29]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
router advertisements.
7.1.2. IPv4 Softwires
If the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes
[RFC2868] are present and of the correct address family, these MUST
be used in the IPCP IP-Address configuration option.
7.2. Delegated Prefixes
7.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix [I-D.ietf-radext-delegated-
prefix] is present in the Radius Access Accept message, it must be
used by the Softwire Concentrator for the delegation of the IPv6
prefix. Since the prefix delegation is performed by DHCPv6 and the
attribute is linked to a username, the SC MUST associate the DUID of
a DHCPv6 request to tunnel it came from and its user.
7.2.2. IPv4 Prefixes
### To complete
8. Maintenance and Statistics
8.1. Radius Accounting
### To complete
8.2. MIBs
See [RFC4293]
### To complete
9. Security Considerations
9.1. Comparison with softwire security analysis
9.2. Additional security issues introduced by the integration of the
different protocols
10. Implementation status
Storer, et al. Expires December 18, 2006 [Page 30]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
11. Open issues
11.1. Fragmentation and MTU
11.2. AAA Accounting (other draft)
12. IANA Considerations
This document creates no new requirements on IANA namespaces
[RFC2434].
13. Acknowledgements
The authors would like to acknowledge the following contributors who
provided helpful input on this document: Florent Parent, Jordi Palet
Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and
Francis Dupont.
The authors would also like to acknowledge the participants in the
Softwires interim meeting at China University - Hong Kong (February
23-24, 2006). The minutes for this meeting are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>.
14. References
14.1. Normative References
[I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-03 (work in progress),
June 2005.
[I-D.ietf-radext-delegated-prefix]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-01 (work in
progress), May 2006.
[I-D.ietf-softwire-problem-statement]
Li, X., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-02 (work in
progress), May 2006.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
Storer, et al. Expires December 18, 2006 [Page 31]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base",
RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Storer, et al. Expires December 18, 2006 [Page 32]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
14.2. Informative References
[I-D.ietf-ipv6-over-ppp-v2]
Varada, S., "IP Version 6 over PPP",
draft-ietf-ipv6-over-ppp-v2-02 (work in progress),
June 2005.
[I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-00 (work in progress),
February 2006.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006.
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.]
Revision -00:
o Initial revision.
Storer, et al. Expires December 18, 2006 [Page 33]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
Authors' Addresses
Bill Storer (editor)
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
Email: bstorer@cisco.com
Carlos Pignataro (editor)
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
Email: cpignata@cisco.com
Maria Alice Dos Santos (editor)
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
Email: mariados@cisco.com
Jean-Francois Tremblay (editor)
Hexago
1470 Peel, suite 910
Montreal, QC J4B 2Z5
Canada
Email: jean-francois.tremblay@hexago.com
Laurent Toutain (editor)
GET/ENST Bretagne
Email: Laurent.Toutain@enst-bretagne.fr
Storer, et al. Expires December 18, 2006 [Page 34]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Storer, et al. Expires December 18, 2006 [Page 35]
