draft-ietf-softwire-hs-framework-l2tpv2-05.txt   draft-ietf-softwire-hs-framework-l2tpv2-06.txt 
Softwires Working Group B. Storer Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: December 30, 2007 Cisco Systems Expires: February 16, 2008 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
J. Tremblay J. Tremblay
Trellia Networks Trellia Networks
June 28, 2007 August 15, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-05 draft-ietf-softwire-hs-framework-l2tpv2-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2007. This Internet-Draft will expire on February 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the framework of the Softwire "Hub and Spoke" This document describes the framework of the Softwire "Hub and Spoke"
solution with Layer 2 Tunneling Protocol (L2TPv2), and the solution with Layer 2 Tunneling Protocol (L2TPv2), and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
skipping to change at page 2, line 29 skipping to change at page 2, line 23
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Network Address Translation (NAT and NAPT) . . . . . . . . 7 2.1. Network Address Translation (NAT and NAPT) . . . . . . . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7 2.4. Authentication, Authorization and Accounting . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 10 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 9
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 15 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 14
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 15 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19 4.1. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Securing the Softwire Transport . . . . . . . . . . . . . 18
4.3. Authentication Authorization Accounting . . . . . . . . . 19 4.3. Authentication Authorization Accounting . . . . . . . . . 18
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 19
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 19
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 21
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 22
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 24
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 25
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 28 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Considerations about the Address Provisioning Model . . . . . 30 6. Considerations about the Address Provisioning Model . . . . . 28
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 29
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 29
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 29
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 30
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 30
7. Considerations about Address Stability . . . . . . . . . . . . 33 7. Considerations about Address Stability . . . . . . . . . . . . 31
8. Considerations about RADIUS Integration . . . . . . . . . . . 34 8. Considerations about RADIUS Integration . . . . . . . . . . . 31
8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 34 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 31
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 31
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 32
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 34 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 32
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 32
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 32
9. Considerations for Maintenance and Statistics . . . . . . . . 36 9. Considerations for Maintenance and Statistics . . . . . . . . 32
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 36 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 32
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol The Softwires Working Group has selected Layer Two Tunneling Protocol
version 2 (L2TPv2) as the phase 1 protocol to be deployed in the version 2 (L2TPv2) as the phase 1 protocol to be deployed in the
Softwires "Hubs and Spokes" solution space. This document describes Softwires "Hubs and Spokes" solution space. This document describes
the framework for the L2TPv2 "Hubs and Spokes" solution, and the the framework for the L2TPv2 "Hubs and Spokes" solution, and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations. to achieve interoperability among different vendor implementations.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
messages can be used as keepalives for the same purposes. In the messages can be used as keepalives for the same purposes. In the
event of keepalive timeout or administrative shutdown of the event of keepalive timeout or administrative shutdown of the
Softwire, either SI or SC may tear down the Softwire by tearing down Softwire, either SI or SC may tear down the Softwire by tearing down
the L2TPv2 Control Channel and Session as specified in [RFC2661]. the L2TPv2 Control Channel and Session as specified in [RFC2661].
1.1. Abbreviations 1.1. Abbreviations
LCCE L2TP Control Connection Endpoint (See [RFC3931]) LCCE L2TP Control Connection Endpoint (See [RFC3931])
SC Softwire Concentrator, the node terminating the Softwire in SC Softwire Concentrator, the node terminating the Softwire in
the service provider network (See the service provider network (See [RFC4925])
[I-D.ietf-softwire-problem-statement])
SI Softwire Initiator, the node initiating the Softwire within SI Softwire Initiator, the node initiating the Softwire within
the customer network (See the customer network (See [RFC4925])
[I-D.ietf-softwire-problem-statement])
STH Softwire Transport Header, the outermost IP header of a STH Softwire Transport Header, the outermost IP header of a
softwire (See [I-D.ietf-softwire-problem-statement]) softwire (See [RFC4925])
SPH Softwire Payload Header, the IP headers being carried within a SPH Softwire Payload Header, the IP headers being carried within a
softwire (See [I-D.ietf-softwire-problem-statement]) softwire (See [RFC4925])
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
Following is the complete list of contributors to this document. Following is the complete list of contributors to this document.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
1.4. Considerations 1.4. Considerations
Some sections of this document contain considerations that are not Some sections of this document contain considerations that are not
required for interoperability and correct operation of Softwire required for interoperability and correct operation of Softwire
implementations. These sections are marked as "Considerations". implementations. These sections are marked as "Considerations".
2. Applicability of L2TPv2 for Softwire Requirements 2. Applicability of L2TPv2 for Softwire Requirements
A list of Softwire "Hubs and Spokes" requirements have been A list of Softwire "Hubs and Spokes" requirements have been
identified by the Softwire Problem Statement identified by the Softwire Problem Statement [RFC4925]. The
[I-D.ietf-softwire-problem-statement]. The following section following section describes how L2TPv2 fulfills each of them.
describes how L2TPv2 fulfills each of them.
2.1. Network Address Translation (NAT and NAPT) 2.1. Network Address Translation (NAT and NAPT)
A "Hubs and Spokes" Softwire must be able to traverse Network Address A "Hubs and Spokes" Softwire must be able to traverse Network Address
Translation and Network Address Port Translation (NAT and NAPT) Translation and Network Address Port Translation (NAT and NAPT)
devices [RFC3022] in case the scenario in question involves a non- devices [RFC3022] in case the scenario in question involves a non-
upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some
carrier equipment at the other end of the access link performing NAT/ carrier equipment at the other end of the access link performing NAT/
NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is
capable of NAT/NAPT traversal since L2TPv2 can run over UDP. capable of NAT/NAPT traversal since L2TPv2 can run over UDP.
skipping to change at page 19, line 10 skipping to change at page 18, line 5
v4/v6 router. A global IPv4 address can also be assigned via DHCP. v4/v6 router. A global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the Other configuration options (such as DNS) can be conveyed to the
v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation 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. for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
4. Standardisation Status 4. Standardisation Status
This section groups various Internet standards documents and other This section groups various Internet standards documents and other
publications used in Softwires. publications used in Softwires.
4.1. Softwire Transport Related 4.1. L2TPv2
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]. RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661].
* For both IPv4 and IPv6 payloads (SPH), support is * For both IPv4 and IPv6 payloads (SPH), support is
complete. complete.
* For both IPv4 and IPv6 transports (STH), support is * For both IPv4 and IPv6 transports (STH), support is
complete. complete.
4.2. Securing the Softwire Transport
RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
* IPSec supports both IPv4 and IPv6 transports.
4.3. Authentication Authorization Accounting 4.3. Authentication Authorization Accounting
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
[RFC2865]. [RFC2865].
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
Support" [RFC2867]. Support" [RFC2867].
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868]. RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
skipping to change at page 27, line 23 skipping to change at page 26, line 23
done as specified in [RFC2661]. There is no action specific to done as specified in [RFC2661]. There is no action specific to
Softwires in this case. Softwires in this case.
5.2. PPP Connection 5.2. PPP Connection
5.2.1. MTU 5.2.1. MTU
The MTU of the PPP link SHOULD be the link MTU minus the size of the The MTU of the PPP link SHOULD be the link MTU minus the size of the
IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an 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 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 bytes. When the link is managed by IPsec, this MTU should be lowered
defined by the leading bits of the L2TP message header (see to take into account the ESP encapsulation (see
[RFC2661]). Additionally, see [RFC4623] for a detailed discussion of [I-D.ietf-softwire-security-requirements]). The value for the MTU
may also 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. fragmentation issues.
5.2.2. LCP 5.2.2. LCP
Once the L2TPv2 session is established, the SI and SC initiate the Once the L2TPv2 session is established, the SI and SC initiate the
PPP connection by negotiating LCP as described in [RFC1661]. The PPP connection by negotiating LCP as described in [RFC1661]. The
Address-and-Control-Field-Compression configuration option (ACFC) Address-and-Control-Field-Compression configuration option (ACFC)
[RFC1661] SHOULD be rejected. [RFC1661] SHOULD be rejected.
5.2.3. Authentication 5.2.3. Authentication
skipping to change at page 37, line 13 skipping to change at page 33, line 22
Also see [RFC4293]. Also see [RFC4293].
10. Security Considerations 10. Security Considerations
A detailed discussion of Softwires security is contained in A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements]. [I-D.ietf-softwire-security-requirements].
The L2TPv2 Softwires solution provides the following tools for The L2TPv2 Softwires solution provides the following tools for
security: security:
o IPsec [RFC3193] provides the highest level of security. o IPsec [RFC4301] with IKEv2 [RFC4306] provides the highest level of
security. [RFC3193] describes interaction between IPsec and
L2TPv2.
o PPP CHAP [RFC1994] provides basic user authentication. o PPP CHAP [RFC1994] provides basic user authentication.
o L2TP Tunnel Authentication [RFC2661] provides authentication at o L2TP Tunnel Authentication [RFC2661] provides authentication at
tunnel setup. It may be used to limit DoS attacks by tunnel setup. It may be used to limit DoS attacks by
authenticating the tunnel before L2TP session and PPP resources authenticating the tunnel before L2TP session and PPP resources
are allocated. are allocated.
11. IANA Considerations 11. IANA Considerations
skipping to change at page 41, line 17 skipping to change at page 35, line 22
RFC 3371, August 2002. RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007. Attribute", RFC 4818, April 2007.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dhc-subnet-alloc] [I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option", Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-05 (work in progress), draft-ietf-dhc-subnet-alloc-05 (work in progress),
June 2007. June 2007.
skipping to change at page 41, line 41 skipping to change at page 36, line 5
[I-D.ietf-ipv6-2461bis] [I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
[I-D.ietf-ipv6-over-ppp-v2] [I-D.ietf-ipv6-over-ppp-v2]
Varada, S., "IP Version 6 over PPP", Varada, S., "IP Version 6 over PPP",
draft-ietf-ipv6-over-ppp-v2-03 (work in progress), draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
May 2007. 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] [I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and Yamamoto, S., "Softwire Security Analysis and
Requirements", Requirements",
draft-ietf-softwire-security-requirements-02 (work in draft-ietf-softwire-security-requirements-03 (work in
progress), March 2007. progress), July 2007.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point Protocol", the Link Control Protocol of the Point-to-Point Protocol",
RFC 1471, June 1993. RFC 1471, June 1993.
skipping to change at page 44, line 5 skipping to change at page 37, line 21
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006. August 2006.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
Appendix A. Revision History Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the [Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to corresponding entries in the table of contents, prior to
publication.] publication.]
Changes between -05 and -06:
o Swapped Section 4.1 and Section 4.2. Renamed Section 4.2 to
"Securing the Softwire Transport".
o In Section 5.2.1, added a mention that the MTU should be lower
that 1460 when using IPsec.
o In Section 10, added pointers to [RFC4301] and [RFC4306].
Changes between -04 and -05: Changes between -04 and -05:
o Replaced "documentation" with "logging purposes" in o Replaced "documentation" with "logging purposes" in
Section 5.1.1.1. Section 5.1.1.1.
o Added suggested values (only as guidance) for Keepalives in o Added suggested values (only as guidance) for Keepalives in
Section 5.1.2. Section 5.1.2.
Changes between -03 and -04: Changes between -03 and -04:
skipping to change at page 45, line 10 skipping to change at page 38, line 43
reference and citation to RFC1662. reference and citation to RFC1662.
o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved
to Normative. to Normative.
o Added new address and email for J.F. Tremblay. o Added new address and email for J.F. Tremblay.
o Added an acknowledgement to the participants, and pointer to the o Added an acknowledgement to the participants, and pointer to the
minutes, for the Barcelona interim meeting. minutes, for the Barcelona interim meeting.
o Moved the Softwire Problem Statement reference o Moved the Softwire Problem Statement reference [RFC4925] to
[I-D.ietf-softwire-problem-statement] to Informative. Informative.
o Some additional purely editorial changes. o Some additional purely editorial changes.
Changes between -02 and -03: Changes between -02 and -03:
o Boiler changes in support of RFC 4748. o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.6 and Section 5.1.2. Section 2.6 and Section 5.1.2.
skipping to change at page 49, line 17 skipping to change at page 42, line 36
Bill Storer Bill Storer
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: bstorer@cisco.com Email: bstorer@cisco.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems Cisco Systems
7025 Kit Creek Road 7200 Kit Creek Road
PO Box 14987 PO Box 14987
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Email: cpignata@cisco.com Email: cpignata@cisco.com
Maria Alice Dos Santos Maria Alice Dos Santos
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: mariados@cisco.com Email: mariados@cisco.com
Bruno Stevant (editor) Bruno Stevant (editor)
GET/ENST Bretagne GET/ENST Bretagne
 End of changes. 34 change blocks. 
103 lines changed or deleted 118 lines changed or added

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