Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos
Expires: December 10, 2007 Cisco Systems
B. Stevant, Ed.
GET/ENST Bretagne
J. Tremblay
Trellia Networks
June 8, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-04
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 10, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Storer, et al. Expires December 10, 2007 [Page 1]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Abstract
This document describes the framework of the Softwire "Hub and Spoke"
solution with Layer 2 Tunneling Protocol (L2TPv2), and the
implementation details specified in this document should be followed
to achieve inter-operability among different vendor implementations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6
1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 6
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Network Address Translation (NAT and NAPT) . . . . . . . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 10
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10
3.1.1. Host 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.4. Router behind CPE as Softwire Initiator . . . . . . . 13
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 15
3.2.1. Host 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.4. Router behind CPE as Softwire Initiator . . . . . . . 17
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Authentication Authorization Accounting . . . . . . . . . 19
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22
Storer, et al. Expires December 10, 2007 [Page 2]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 28
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Considerations about the Address Provisioning Model . . . . . 30
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31
7. Considerations about Address Stability . . . . . . . . . . . . 33
8. Considerations about RADIUS Integration . . . . . . . . . . . 34
8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 34
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 34
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35
9. Considerations for Maintenance and Statistics . . . . . . . . 36
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 36
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
Storer, et al. Expires December 10, 2007 [Page 3]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50
Storer, et al. Expires December 10, 2007 [Page 4]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol
version 2 (L2TPv2) as the phase 1 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 send L2TPv2 keepalive
HELLO messages to monitor the health of the Softwire and the peer
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
Storer, et al. Expires December 10, 2007 [Page 5]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
messages can be used as keepalives for the same purposes. In the
event of keepalive 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, the outermost IP header of a
softwire (See [I-D.ietf-softwire-problem-statement])
SPH Softwire Payload Header, the IP headers being carried within a
softwire (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
Trellia Networks
Laurent Toutain
Bruno Stevant
GET/ENST Bretagne
1.4. Considerations
Some sections of this document contain considerations that are not
required for interoperability and correct operation of Softwire
implementations. These sections are marked as "Considerations".
Storer, et al. Expires December 10, 2007 [Page 6]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
2. Applicability of L2TPv2 for Softwire Requirements
A list of Softwire "Hubs and Spokes" requirements have been
identified by the Softwire Problem Statement
[I-D.ietf-softwire-problem-statement]. The following section
describes how L2TPv2 fulfills each of them.
2.1. Network Address Translation (NAT and NAPT)
A "Hubs and Spokes" Softwire must be able to traverse Network Address
Translation and Network Address Port Translation (NAT and NAPT)
devices [RFC3022] in case the scenario in question involves a non-
upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some
carrier equipment at the other end of the access link performing NAT/
NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is
capable of NAT/NAPT traversal since L2TPv2 can run over UDP.
Since L2TPv2 does not "autodetect" NAT/NAPT along the path, L2TPv2
does not offer UDP bypass regardless of NAT/NAPT presence. Both NAT/
NAPT "autodetect" and UDP bypass are optional requirements.
2.2. Scalability
In the "Hubs and Spokes" model, a carrier must be able to scale the
solution to millions of Softwire initiators by adding more hubs
(i.e., Softwire concentrators). L2TPv2 is a widely deployed protocol
in broadband services, and its scalability has been proven in
multiple large-scale IPv4 Virtual Private Network deployments which
scale up to millions of subscribers each.
2.3. Multicast
Multicast protocols simply run over L2TPv2 Softwires transparently
together with other regular IP traffic.
2.4. Authentication, Authorization and Accounting
L2TPv2 supports optional mutual Control Channel authentication and
leverages the optional mutual PPP per-session authentication. L2TPv2
is well integrated with AAA solutions (such as RADIUS) for both
authentication and authorization. Most L2TPv2 implementations
available in the market support logging of authentication and
authorization events.
L2TPv2 integration with RADIUS accounting (RADIUS Accounting
extension for tunnel [RFC2867]) allows the collection and reporting
of L2TPv2 Softwire usage statistics.
Storer, et al. Expires December 10, 2007 [Page 7]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
2.5. Privacy, Integrity, and Replay Protection
Since L2TPv2 runs over IP/UDP in the Softwire context, IPSec ESP can
be used in conjunction to provide per-packet authentication,
integrity, replay protection and confidentiality for both L2TPv2
control and data traffic [RFC3193] and [RFC3948].
For Softwire deployments in which full payload security is not
required, the L2TPv2 built-in Control Channel authentication and the
inherited PPP authentication and PPP Encryption Control Protocol can
be considered.
2.6. Operations and Management (OAM)
L2TPv2 supports an optional in-band keepalive mechanism which injects
HELLO control messages after a specified period of time has elapsed
since the last data or control message was received on a tunnel. If
the HELLO control message is not reliably delivered, then the Control
Channel and its session will be torn down. In the Softwire context,
the L2TPv2 keepalive is used to monitor the connectivity status
between the SI and SC and/or as a refresh mechanism for any NAT/NAPT
translation entry along the access link.
LCP ECHO offers a similar mechanism to monitor the connectivity
status, as described in [RFC1661]. Softwires implementations SHOULD
use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo
messages to ensure Dead End Detection and/or to refresh NAT/NAPT
translation entries. The combination of these two mechanisms can be
used as an optimization.
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
Storer, et al. Expires December 10, 2007 [Page 8]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not
support "autodetect" of NAT/NAPT.
Storer, et al. Expires December 10, 2007 [Page 9]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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.
3.1. IPv6 over IPv4 Softwire with L2TPv2
The following subsections cover IPv6 connectivity across an IPv4-only
access network (STH) using a Softwire.
3.1.1. Host CPE as Softwire Initiator
The Softwire Initiator (SI) 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. See Figure 1.
Storer, et al. Expires December 10, 2007 [Page 10]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
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
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
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.
3.1.2. Router CPE as Softwire Initiator
The Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv4 traffic SHOULD NOT traverse the Softwire. See
Figure 2.
Storer, et al. Expires December 10, 2007 [Page 11]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
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
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
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.
3.1.3. Host behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The
IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
Storer, et al. Expires December 10, 2007 [Page 12]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
<------------------------------>
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
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
to the host or perform uniqueness validation for the two Interface-
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.
3.1.4. Router behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside
the home network. The IPv4 traffic SHOULD NOT traverse the Softwire.
See Figure 4.
Storer, et al. Expires December 10, 2007 [Page 13]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<--------------------------->
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
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
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 (e.g., 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 10, 2007 [Page 14]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
3.2. IPv4 over IPv6 Softwire with L2TPv2
The following subsections cover IPv4 connectivity across an IPv6-only
access network (STH) using a Softwire.
3.2.1. Host CPE as Softwire Initiator
The Softwire Initiator (SI) 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. See Figure 5.
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 (SPH)
Softwire
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 5: Host CPE as Softwire Initiator
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. A global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the host
CPE via IPCP [RFC1877] or DHCP.
3.2.2. Router CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The
Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv6 traffic SHOULD NOT traverse the Softwire. See
Figure 6.
Storer, et al. Expires December 10, 2007 [Page 15]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
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
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. A 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.
3.2.3. Host behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. The Softwire Initiator (SI) is a dual-stack host
(behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6
traffic SHOULD NOT traverse the Softwire. See Figure 7.
Storer, et al. Expires December 10, 2007 [Page 16]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
<------------------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiator
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. A global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP.
3.2.4. Router behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. The Softwire Initiator (SI) is a dual-stack device
(behind the IPv6-only CPE) acting as an IPv4 CPE router inside the
home network. The IPv6 traffic SHOULD NOT traverse the Softwire.
See Figure 8.
Storer, et al. Expires December 10, 2007 [Page 17]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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 (SPH)
<--------------------------->
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
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
v4/v6 router. A global IPv4 address can also be 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 10, 2007 [Page 18]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
4. Standardisation Status
This section groups various Internet standards documents and other
publications used in Softwires.
4.1. Softwire Transport Related
RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
* IPSec supports both IPv4 and IPv6 transports.
4.2. L2TPv2
RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661].
* For both IPv4 and IPv6 payloads (SPH), support is
complete.
* For both IPv4 and IPv6 transports (STH), support is
complete.
4.3. Authentication Authorization Accounting
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
[RFC2865].
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
Support" [RFC2867].
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 3162 "RADIUS and IPv6" [RFC3162].
4.4. MIB
RFC 1471 "The Definitions of Managed Objects for the Link Control
Protocol of the Point-to-Point Protocol" [RFC1471].
RFC 1473 "The Definitions of Managed Objects for the IP Network
Control Protocol of the Point-to-Point Protocol"
[RFC1473].
RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management
Information Base" [RFC3371].
Storer, et al. Expires December 10, 2007 [Page 19]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
RFC 4087 "IP Tunnel MIB" [RFC4087].
* Both IPv4 and IPv6 transports are supported.
4.5. Softwire Payload Related
4.5.1. For IPv6 Payloads
RFC 2461 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC2461].
RFC 2472 "IP Version 6 over PPP" [RFC2472].
* See also [I-D.ietf-ipv6-over-ppp-v2].
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315].
RFC 3646 "DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)" [RFC3646].
4.5.2. For IPv4 Payloads
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)"
[RFC1332].
RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
RFC 1877 "PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses" [RFC1877].
DHCP Subnet Allocation "Subnet Allocation Option".
* Work in progress, see [I-D.ietf-dhc-subnet-alloc].
Storer, et al. Expires December 10, 2007 [Page 20]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
5. Softwire Establishment
A Softwire is established in three distinct steps (see Figure 9).
First an L2TPv2 tunnel with a single session is established from the
SI to the SC. Second a PPP session is established over the L2TPv2
session and the SI obtains an address. Third the SI optionally gets
other information through DHCP such as a delegated prefix and DNS
servers.
SC SI
| |
|<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment
| |
|<-------------PPP--------------->| Step 2
|<----End Point Configuration---->| PPP and End Point
| | configuration
| |
|<------Router Configuration----->| Step 3
| | Additional configuration
| | (optional)
Figure 9: Steps for the Establishment of a Softwire
In the following diagram (see Figure 10), each of the three steps
required to establish a Softwire is described in detail.
Storer, et al. Expires December 10, 2007 [Page 21]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
SC SI
| |
| | Step 1
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| |
|<------------ICCN----------------| -
| |
| | Step 2
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|<-------Configuration-Ack--------| | LCP
|--------Configuration-Ack------->| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|<-------Configuration-Ack--------| | (IPV6CP or IPCP)
|--------Configuration-Ack------->| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
| | Step3
|<-----------Solicit--------------| -
|-----------Advertise------------>| | DHCP
|<---------- Request--------------| | (Optional)
|-------------Reply-------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire
5.1. L2TPv2 Tunnel Setup
L2TPv2 [RFC2661] was originally designed to provide private network
access to end users connected to a public network. In the L2TPv2
model, the end user makes a connection to an L2TP Access Concentrator
(LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network
Server (LNS). The LNS then transfers end user traffic between the
L2TPv2 tunnel and the private network.
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
assumes the role of the LAC and the Softwire Concentrator assumes the
Storer, et al. Expires December 10, 2007 [Page 22]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
role of the LNS.
In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
The underlying version of the IP protocol may be IPv4 or IPv6,
depending on the Softwires scenario.
In the following sections, the term "Tunnel" follows the definition
from [RFC2661], namely: "The Tunnel consists of a Control Connection
and zero or more L2TP Sessions".
5.1.1. Tunnel Establishment
Figure 11 describes the messages exchanged and 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 those defined in [RFC2661]. This
is because Softwires uses only a subset of the L2TPv2 functionality.
The subset of L2TP Control Connection Management AVPs that is
applicable to Softwires is grouped into Mandatory AVPs and Optional
AVPs (see Figure 11). Note that in the Softwires environment, the SI
always initiates the tunnel. L2TPv2 attributes SHOULD NOT be hidden.
Storer, et al. Expires December 10, 2007 [Page 23]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
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
Optional AVP:
Challenge Response
Figure 11: Control Connection Establishment
In L2TPv2, the tunnel between an LAC and LNS may carry the data of
multiple users. Each of these user's is represented by an L2TPv2
session within the tunnel. In the Softwires environment, the tunnel
carries the information of a single user. So, there is only one
L2TPv2 session per tunnel. Figure 12 describes the messages
exchanged and the AVPs used to establish a session between 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 Softwires
uses only a subset of the L2TPv2 functionality. The subset of L2TP
Call Management AVPs that is applicable to Softwires is grouped into
Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the
Softwires environment, the SI always initiates the session. No
outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT
Storer, et al. Expires December 10, 2007 [Page 24]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
be hidden.
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
Figure 12: Session Establishment
5.1.1.1. AVPs Required for Softwires
This section prescribes specific values for AVPs used in the
Softwires context that are Mandatory.
Host Name AVP
This AVP is mandatory and is present in SCCRQ and SCCRP messages.
This AVP may be used to authenticate users, in which case it would
contain a user identification. If this AVP is not used to
authenticate users, it may be used for documentation.
Framing Capabilities AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1.
This AVP SHOULD be ignored by the receiver.
Framing Type AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
This AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed
(Tx) Connect Speed is a mandatory AVP but is not meaningful in the
Softwires context. It SHOULD be left to 0 and ignored by the
Storer, et al. Expires December 10, 2007 [Page 25]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
receiver.
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call
Serial Number AVP, and Assigned Session ID AVP
As defined in [RFC2661]
5.1.1.2. AVPs Optional for Softwires
This section prescribes specific values for AVPs used in the
Softwires context that are Optional.
Challenge AVP and Challenge Response AVP
These AVPs are not required, but are necessary to implement tunnel
authentication. Since tunnel authentication happens at the
beginning of L2TPv2 tunnel creation, it can be helpful in
preventing DoS attacks.
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP
As defined in [RFC2661]
5.1.1.3. AVPs not Relevant for Softwires
L2TPv2 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 L2TPv2 implementations.
5.1.2. Tunnel Maintenance
Periodically, the SI MUST transmit a message to the SC to maintain
NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO
message provides a simple, low overhead method of doing this.
The default values specified in [RFC2661] for L2TPv2 HELLO messages
could result in a dead end detection time of 83 seconds. Although
these retransmission timers and counters SHOULD be configurable (see
[RFC2661]), these values may not be adapted for all situations, where
a quicker dead end detection is required, or where NAT/NAPT context
needs to be refreshed more frequently. In such cases, the SI MAY
use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo-
Request and Echo-Reply codes) described in [RFC1661] which timeout
could be configured to a lower value. When used, LCP ECHO messages
SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO
hello messages.
Storer, et al. Expires December 10, 2007 [Page 26]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
5.1.3. Tunnel Teardown
Either the SI or SC can teardown the session and tunnel. This is
done as specified in [RFC2661]. There is no action specific to
Softwires in this case.
5.2. PPP Connection
5.2.1. MTU
The MTU of the PPP link SHOULD be the link MTU 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 tipically mean a PPP MTU of 1460
bytes. This may vary according to the size of the L2TP header, as
defined by the leading bits of the L2TP message header (see
[RFC2661]). Additionally, see [RFC4623] for a detailed discussion of
fragmentation issues.
5.2.2. LCP
Once the L2TPv2 session is established, the SI and SC initiate the
PPP connection by negotiating LCP as described in [RFC1661]. The
Address-and-Control-Field-Compression configuration option (ACFC)
[RFC1661] SHOULD be rejected.
5.2.3. Authentication
After completing LCP negotiation, the SI and SC may optionally
perform authentication. If authentication is chosen, CHAP [RFC1994]
authentication MUST be supported by both the Softwire Initiator and
Softwire Concentrator. Other authentication methods such as MS-
CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported.
A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements].
5.2.4. IPCP
5.2.4.1. IPV6CP
In the IPv6 over IPv4 scenarios (see Section 3.1), after the
authentication phase, the Softwire Initiator MUST negotiate IPV6CP as
defined in [RFC2472]. IPV6CP provides a way to negotiate a unique
64-bit Interface-Identifier to be used for the address
autoconfiguration at the local end of the link.
Storer, et al. Expires December 10, 2007 [Page 27]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
5.2.4.2. IPv4CP
In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire
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
information as described in [RFC1877].
5.3. Global IPv6 Address Assignement to Endpoints
In several scenarios defined in Section 3, Global IPv6 addresses are
expected to be allocated to Softwires end points. Since IPV6CP only
provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery
[RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these
addresses.
The Softwire Initiator of an IPv6 Softwire MUST send a Router
Solicitation message to the Softwire Concentrator after IPV6CP is
completed. The Softwire Concentrator MUST answer with a Router
Advertisement. This message MUST contains the global IPv6 prefix of
the PPP link if Neighbor discovery is used to configure addresses of
Softwire end points.
If DHCPv6 is available for address delegation, the M bits of the
Router Advertisement SHOULD be set. The Softwire Initiator MUST then
send a DHCPv6 Request to configure the address of the Softwire
endpoint.
Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be
performed on the Softwire in both cases.
5.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.
When delegating an IPv4 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire.
5.4.1. DHCPv6
If an SI establishing an IPv6 Softwire acts as a router (i.e., in the
scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the
IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in
order to request an IPv6 prefix.
Storer, et al. Expires December 10, 2007 [Page 28]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
When delegating an IPv6 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire.
5.4.2. DHCPv4
An SI establishing an IPv4 Softwire MAY send a DHCP request
containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].
This practice is not common but may be used to connect IPv4 subnets
using Softwires, as defined in Section 3.2.2 and Section 3.2.4.
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'.
Storer, et al. Expires December 10, 2007 [Page 29]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
6. Considerations about the Address Provisioning Model
This section describes how a Softwire Concentrator may manage
delegated addresses for Softwire endpoints and for subnets behind the
Softwire Initiator. One common practice is to aggregate endpoints
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
succeeding route injections (when delegating new prefixes for SI).
6.1. Softwire Endpoints Addresses
6.1.1. IPv6
A Softwire Concentrator should provide globally routable addresses to
Softwire endpoints. Other types of addresses such as Unique Local
Addresses [RFC4193] may be used to address Softwire end points in a
private network with no global connectivity. A single /64 should be
assigned to the Softwire to address both Softwire endpoints.
Global or ULA addresses must be assigned to endpoints when the
scenario "Host CPE as Softwire Initiator" (described in
Section 3.1.1) is considered to be deployed. For other scenarios,
this may be optional and link local addresses should be used.
6.1.2. IPv4
A Softwire Concentrator may provide either globally routable or
private IPv4 addresses. When using IPv4 private addresses [RFC1918]
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.
The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP.
6.2. Delegated Prefixes
6.2.1. IPv6 Prefixes
Delegated IPv6 should be of global scope if the IPv6 addresses
assigned to endpoints are global. Using ULA addresses is not
recommended when the subnet is connected to the global IPv6 Internet.
When using ULA IPv6 address for endpoint, the delegated IPv6 prefix
may be either of Global or ULA scope.
Delegated IPv6 prefixes are between /48 and /64 in length. When an
SI receives a prefix shorter than 64, it can assign different /64
prefixes to each of its interfaces. An SI receiving a single /64 is
expected to perform bridging if more than one interface are available
Storer, et al. Expires December 10, 2007 [Page 30]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
(wired and wireless for example).
6.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be routable within the address space
used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes
(i.e. private IPv4 prefix over public IPv4 addresses or another class
of private IPv4 addresses) is not recommended as a practice for
provisioning and address translation should be considered in these
cases. The prefix length is between /8 and /30.
6.3. Possible scenarios
This section summarizes the differents scenarios for address
provisioning with the considerations given in the previous sections.
6.3.1. Scenarios for IPv6
This table describes the possible combination of IPv6 address scope
for endpoints and delegated prefixes.
+------------------+-----------------------+------------------------+
| Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 |
| Address | Prefix | Prefix |
+------------------+-----------------------+------------------------+
| Link Local | Possible | Possible |
| | | |
| ULA | Possible | Possible |
| | | |
| Global | Possible | Possible, but Not |
| | | Recommended |
+------------------+-----------------------+------------------------+
Table 1: Scenarios for IPv6
6.3.2. Scenarios for IPv4
This table describes the possible combination of IPv4 address scope
for endpoints and delegated prefixes.
Storer, et al. Expires December 10, 2007 [Page 31]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
+-------------+-----------------+-----------------------------------+
| Endpoint | Delegated | Delegated Private IPv4 Prefix |
| IPv4 | Public IPv4 | |
| Address | Prefix | |
+-------------+-----------------+-----------------------------------+
| Private | Possible | Possible, but Not Recommended |
| IPv4 | | when using NAT (cf. |
| | | Section 6.1.2) |
| | | |
| Public IPv4 | Possible | Possible, but NAT usage is |
| | | recommended (cf. Section 6.2.2) |
+-------------+-----------------+-----------------------------------+
Table 2: Scenarios for IPv4
Storer, et al. Expires December 10, 2007 [Page 32]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
7. Considerations about Address Stability
A Softwire can provide stable addresses 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 are 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.
Storer, et al. Expires December 10, 2007 [Page 33]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
8. Considerations about RADIUS Integration
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 RADIUS server may return additional informations in the
form of attributes in the Access Accept message.
The Softwire Concentrator may include the Tunnel-Type and Tunnel-
Medium-Type attributes [RFC2868] in the Access Request messages to
provide a hint of the type of Softwire being configured.
8.1. Softwires Endpoints
8.1.1. IPv6 Softwires
If the RADIUS 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 RAs.
If none of the attributes above are included but the AAA server
returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
attributes [RFC2868] with the correct address family, these must be
used in the IPV6CP Interface-Identifier and for the router
advertisements.
8.1.2. IPv4 Softwires
If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
Concentrator must provide that address to the Softwire Initiator
during IPCP address negotiation. That is, when the Softwire
Initiator requests an IP address from the Softwire Concentrator, the
address provided should be the Framed-IP-Address.
If the Framed-IP-Address attribute is not present and the Tunnel-
Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
present and of the correct address family, these should be used in
the IPCP IP-Address configuration option.
8.2. Delegated Prefixes
Storer, et al. Expires December 10, 2007 [Page 34]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
8.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix [RFC4818] 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 DHCP Unique Identifier (DUID) of
a DHCPv6 request to the tunnel it came from and its user.
Interaction between RADIUS, PPP and DHCPv6 server may follow the
mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the
Softwire authentication phase, PPP collects the RADIUS attributes for
the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is
assigned to the Softwire. The DHCPv6 relay fills in these attributes
in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option,
before forwarding the DHCPv6 requests to the DHCPv6 server.
8.2.2. IPv4 Prefixes
The combination of the Framed-IP-Address and Framed-IP-Netmask
attributes [RFC2865] may be used by the Softwire Concentrator to
delegate an IPv4 prefix to the Softwire Initiator.
Storer, et al. Expires December 10, 2007 [Page 35]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
9. Considerations for Maintenance and Statistics
9.1. RADIUS Accounting
RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
When deploying Softwires solutions, operators may experience
difficulties to differentiate the address family of the traffic
reported in accounting information from RADIUS. This problem and
some potential solutions are described in
[I-D.stevant-softwire-accounting].
9.2. MIBs
MIB support for L2TPv2 and PPP are documented (see Section 4.4).
Also see [RFC4293].
Storer, et al. Expires December 10, 2007 [Page 36]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
10. Security Considerations
A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements].
The L2TPv2 Softwires solution provides the following tools for
security:
o IPsec [RFC3193] provides the highest level of security.
o PPP CHAP [RFC1994] provides basic user authentication.
o L2TP Tunnel Authentication [RFC2661] provides authentication at
tunnel setup. It may be used to limit DoS attacks by
authenticating the tunnel before L2TP session and PPP resources
are allocated.
Storer, et al. Expires December 10, 2007 [Page 37]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
11. IANA Considerations
This document creates no new requirements on IANA namespaces
[RFC2434].
Storer, et al. Expires December 10, 2007 [Page 38]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
12. 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 meetings held in Hong Kong, China and Barcelona,
Spain. The minutes for the interim meeting at the China University -
Hong Kong (February 23-24, 2006) are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The
minutes for the interim meeting at Polytechnic University of
Catalonia - Barcelona (September 14-15, 2006) are reachable at <http:
//bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>.
Storer, et al. Expires December 10, 2007 [Page 39]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
13. References
13.1. Normative References
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[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.
Storer, et al. Expires December 10, 2007 [Page 40]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base",
RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
13.2. Informative References
[I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-04 (work in progress),
October 2006.
[I-D.ietf-dhc-v6-relay-radius]
Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
draft-ietf-dhc-v6-relay-radius-02 (work in progress),
February 2006.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
[I-D.ietf-ipv6-over-ppp-v2]
Varada, S., "IP Version 6 over PPP",
draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
May 2007.
[I-D.ietf-softwire-problem-statement]
Dawkins, S., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-03 (work in
progress), March 2007.
[I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and
Requirements",
draft-ietf-softwire-security-requirements-02 (work in
progress), March 2007.
[I-D.stevant-softwire-accounting]
Storer, et al. Expires December 10, 2007 [Page 41]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress),
October 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point Protocol",
RFC 1471, June 1993.
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for
the IP Network Control Protocol of the Point-to-Point
Protocol", RFC 1473, June 1993.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[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.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
Storer, et al. Expires December 10, 2007 [Page 42]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
[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.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
Storer, et al. Expires December 10, 2007 [Page 43]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to
publication.]
Changes between -03 and -04:
o Added missing references to [RFC4087], [RFC2461], and [RFC3646],
moved [RFC4623] to Informative.
o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and
Section 6.2.2 in Table 2.
o Added citations (and corresponding references) to [RFC1471] and
[RFC1473] in Section 4.4, since Section 9.2 explicitly mentions:
"MIB support for L2TPv2 and PPP are documented."
o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2,
Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2,
Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and
Section 8.1.1.
o Added [RFC2868] to Section 4.3, and added missing citations to
Section 4.
o Added missing "Optional AVP" to Figure 11.
o Updated the text in Section 6.2.2.
o Added some clarifying sentences in Section 5.1.1, and completed
Section 5.1.1.1 and Section 5.1.1.2.
o Added an Informative reference to [RFC3022] for NAT/NAPT.
o Corrected reference to [RFC1661] in Section 5.2.2, removed
reference and citation to RFC1662.
o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved
to Normative.
o Added new address and email for J.F. Tremblay.
o Added an acknowledgement to the participants, and pointer to the
minutes, for the Barcelona interim meeting.
o Moved the Softwire Problem Statement reference
[I-D.ietf-softwire-problem-statement] to Informative.
Storer, et al. Expires December 10, 2007 [Page 44]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
o Some additional purely editorial changes.
Changes between -02 and -03:
o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.6 and Section 5.1.2.
o Moved some downref to Informative ([RFC1877], [RFC2433],
[RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to
Normative ([RFC1994]).
o Removed the mention and citation for PAP authentication.
Changes between -01 and -02:
o Renamed all "Best Current Practices" sections as
"Recommendations". See for example Section 1.4.
o Moved Provisioning in Section 6. Removed intro text to new
Section 7.
o Removed all normative language from Section 6, Section 7,
Section 8, and Section 9.
o Removed empty sections "Implementation Status", and "Open Issues".
o Fixed "Phase 0" in Section 1.
o Small changes to Section 3.1.
o Change L2TP -> L2TPv2 in some sections, including Section 6.
o Small additions and typo fixes in Section 5.1.1.1 and
Section 5.1.1.2.
o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS.
o New paragraph in Section 9.1.
o New paragraph in Section 8.2.1, including a pointer to
[I-D.ietf-dhc-v6-relay-radius].
o Moved last paragraph to start of Section 10.
o Moved some references from Normative to Informative.
Storer, et al. Expires December 10, 2007 [Page 45]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
o Label the steps in Figure 9 and Figure 10.
o Reword paragraph of Section 5.1.
o Describe more messages than flows in Figure 11 and Figure 12.
o Add text about Session Establishment between Figure 11 and
Figure 12.
o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP,
Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and
Challenge and Challenge Response AVPs.
o Retitled Section 5.1.1.3.
o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End
peer detection, and allow LCP.
o Rewording in Section 5.1.3.
o Section 5.2.1: Add a pointer to [RFC4623] and small updates.
o Clarifications on PFC and ACFC, remove Figure 13.
o Section 5.2.3: make references to RFCs for PAP, CHAP, etc.
o Rewordings in Section 5.2.4.1 and Section 5.2.4.2.
o Added Informative references to [RFC4623], [RFC1661], [RFC2433],
and [RFC3748].
o Renamed the title and added more details on Section 5.3 and IPv6
ND, including a pointer to [I-D.ietf-ipv6-2461bis].
o Added text in Section 5.4 about IPv4 PD is non-trivial and non
commonly done.
o Added B. Stevant as Editor.
o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the
scope of the MUST (to the specific scenarios).
o Removed considerations about reverse DNS from Section 6, agreed on
Barcelona.
o Clarified the NAT case in Section 6.1.2
Storer, et al. Expires December 10, 2007 [Page 46]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
o Added first paragraph in Section 6.2.1 regarding delegated IPv6
prefixes.
o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing
the scenarios for address allocation.
Changes between -00 and -01:
o Changed alignment in all figures to be centered, and fixed
Figure 9 reference.
o Section 1.4: Added new section with "Best Current Practices"
definition.
o Marked the following sections as "Best Current Practices":
Section 6, Section 8, and Section 9.
o Section 6.1.1, last paragraph: Removed sentence on IPv6 link
address on the PPP link. Mailing list comment from Florent
Parent, 13-Jul-2006.
o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to
use host addresses (/32) negotiated with IPCP instead of /30.
Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing
ICRP, and changed direction of ICCN; typo correction s/IPV6P/
IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 5, Figure 10: Marked CHAP as "Optional - CHAP".
o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical
error correction and rewording of some sentences for grammar.
o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes"
and added that MAY be used to authenticate users.
o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and
MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text
from Laurent Toutain.
o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not*
meaningful".
o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed
the last sentence of the first paragraph. Mailing list comment
from Bill Storer, 5-Jul-2006, text from Laurent Toutain.
Storer, et al. Expires December 10, 2007 [Page 47]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and
not LCP Echo Request and Reply messages to detect tunnel failure,
as redundant in Softwires. Mailing list comment from Florent
Parent, 10-Jul-2006, text from Bill Storer.
o Section 5.2.1, first paragraph: Fixed PPP MTU calculation.
Mailing list comment from Florent Parent, 10-Jul-2006.
o Section 5.2.4.2: Rewrote to generalize the address assignment
failure, to be an all-zeroes address or a protocol reject in
response to the IPCP CONFREQ. Mailing list comment from Bill
Storer, 5-Jul-2006, text from JF Tremblay.
o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /.
Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if
not present then use the Tunnel-Client-Endpoint and Tunnel-Server-
Endpoint attributes. Mailing list comment from Bill Storer,
5-Jul-2006, text from JF Tremblay and Bill Storer.
o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10.
Revision -00:
o Initial revision.
Storer, et al. Expires December 10, 2007 [Page 48]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Authors' Addresses
Bill Storer
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
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
Email: mariados@cisco.com
Bruno Stevant (editor)
GET/ENST Bretagne
2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576
France
Email: bruno.stevant@enst-bretagne.fr
Jean-Francois Tremblay
Trellia Networks
100, Alexis-Nihon, Suite 770
Montreal, QC H4M 2P3
Canada
Email: jf@jftremblay.com
Storer, et al. Expires December 10, 2007 [Page 49]
Internet-Draft Softwires H & S Framework with L2TPv2 June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Storer, et al. Expires December 10, 2007 [Page 50]
