draft-ietf-softwire-hs-framework-l2tpv2-00.txt   draft-ietf-softwire-hs-framework-l2tpv2-01.txt 
Softwires Working Group B. Storer, Ed. Softwires Working Group B. Storer, Ed.
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Expires: December 18, 2006 M. Dos Santos, Ed. Intended status: Standards Track M. Dos Santos, Ed.
Cisco Systems Expires: February 26, 2007 Cisco Systems
J. Tremblay, Ed. J. Tremblay, Ed.
Hexago Hexago
L. Toutain, Ed. L. Toutain, Ed.
GET/ENST Bretagne GET/ENST Bretagne
June 16, 2006 August 25, 2006
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-00.txt draft-ietf-softwire-hs-framework-l2tpv2-01.txt
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 18, 2006. This Internet-Draft will expire on February 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the framework of the Softwire "Hubs and This document describes the framework of the Softwire "Hubs and
Spokes" solution with Layer 2 Tunneling Protocol (L2TPv2), and the Spokes" 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
to achieve inter-operability among different vendor implementations. to achieve inter-operability among different vendor implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6
1.4. Best Current Practices . . . . . . . . . . . . . . . . . . 6
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 6 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 7 2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 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 . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 13 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 13
skipping to change at page 2, line 43 skipping to change at page 2, line 44
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 17 4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 17
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.3. Authentication Authorization Accounting . . . . . . . . . 18
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18
5. Provisioning Model . . . . . . . . . . . . . . . . . . . . . . 19 5. Provisioning Model - Best Current Practices . . . . . . . . . 19
5.1. Link Addresses . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Link Addresses . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 20
5.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 20
5.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 20
6. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 6. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
6.1. L2TP Tunnel Setup . . . . . . . . . . . . . . . . . . . . 22 6.1. L2TP Tunnel Setup . . . . . . . . . . . . . . . . . . . . 22
6.1.1. Tunnel Establishement . . . . . . . . . . . . . . . . 23 6.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
6.1.1.1. AVPs Required for Sotftwires . . . . . . . . . . . 25 6.1.1.1. AVPs Required for Sotftwires . . . . . . . . . . . 25
6.1.1.2. AVPs Optional for Sotftwires . . . . . . . . . . . 26 6.1.1.2. AVPs Optional for Sotftwires . . . . . . . . . . . 26
6.1.1.3. AVPs not Required for Softwires . . . . . . . . . 26 6.1.1.3. AVPs not Required for Softwires . . . . . . . . . 26
6.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26 6.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
6.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27 6.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27
6.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 6.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27 6.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 28
6.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 28 6.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28 6.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 28 6.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 29
6.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29 6.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
7. AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. AAA - Best Current Practices . . . . . . . . . . . . . . . . . 30
7.1. Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . 29 7.1. Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . 30
7.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 29 7.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30
7.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30 7.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30
7.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 7.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 31
7.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 7.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 31
7.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 30 7.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
8. Maintenance and Statistics . . . . . . . . . . . . . . . . . . 30
8.1. Radius Accounting . . . . . . . . . . . . . . . . . . . . 30
8.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Maintenance and Statistics - Best Current Practices . . . . . 31
9.1. Comparison with softwire security analysis . . . . . . . . 30 8.1. Radius Accounting . . . . . . . . . . . . . . . . . . . . 31
9.2. Additional security issues introduced by the 8.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
integration of the different protocols . . . . . . . . . . 30
10. Implementation status . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Implementation status . . . . . . . . . . . . . . . . . . . . 32
11.1. Fragmentation and MTU . . . . . . . . . . . . . . . . . . 31
11.2. AAA Accounting (other draft) . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Fragmentation and MTU . . . . . . . . . . . . . . . . . . 32
11.2. AAA Accounting (other draft) . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol The Softwires Working Group has selected Layer Two Tunneling Protocol
(L2TPv2) as the phase I protocol to be deployed in the Softwires (L2TPv2) as the phase I protocol to be deployed in the Softwires
"Hubs and Spokes" solution space. This document describes the "Hubs and Spokes" solution space. This document describes the
framework for the L2TPv2 "Hubs and Spokes" solution, and 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 13 skipping to change at page 6, line 13
or at the other end of the access link. In the event of keepalive or at the other end of the access link. In the event of keepalive
timeout or administrative shutdown of the Softwire, either SI or SC timeout or administrative shutdown of the Softwire, either SI or SC
may tear down the Softwire by tearing down the L2TPv2 Control Channel may tear down the Softwire by tearing down the L2TPv2 Control Channel
and Session as specified in [RFC2661]. 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 [I-D.ietf-softwire-problem- the service provider network (See
statement]) [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 [I-D.ietf-softwire-problem- the customer network (See
statement]) [I-D.ietf-softwire-problem-statement])
STH Softwire Transport Header (See [I-D.ietf-softwire-problem- STH Softwire Transport Header (See
statement]) [I-D.ietf-softwire-problem-statement])
SPH Softwire Payload Header (See [I-D.ietf-softwire-problem- SPH Softwire Payload Header (See
statement]) [I-D.ietf-softwire-problem-statement])
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
Following is the complete list of contributors to this document. Following is the complete list of contributors to this document.
Maria Alice Dos Santos Maria Alice Dos Santos
Carlos Pignataro Carlos Pignataro
Bill Storer Bill Storer
Cisco Systems Cisco Systems
Jean-Francois Tremblay Jean-Francois Tremblay
Hexago Hexago
Laurent Toutain Laurent Toutain
GET/ENST Bretagne GET/ENST Bretagne
1.4. Best Current Practices
Some sections of this document contain recommendations that are not
required for interoperability and correct operation of softwires
implementations. These sections are marked as "Best Current
Practices".
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 [I-D.ietf-softwire- identified by the Softwire Problem Statement
problem-statement]. The following section describes how L2TPv2 [I-D.ietf-softwire-problem-statement]. The following section
fulfills each of them. describes how L2TPv2 fulfills each of them.
2.1. Network and Port Address Translation (NAT/PAT) 2.1. Network and Port Address Translation (NAT/PAT)
A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case
the scenario in question involves a non-upgradable pre-existing IPv4 the scenario in question involves a non-upgradable pre-existing IPv4
home gateway performing NAT/PAT or some carrier equipment at the home gateway performing NAT/PAT or some carrier equipment at the
other end of the access link performing NAT/PAT. The L2TPv2 Softwire other end of the access link performing NAT/PAT. The L2TPv2 Softwire
(i.e. Control Channel and Session) is capable of NAT/PAT traversal (i.e. Control Channel and Session) is capable of NAT/PAT traversal
since L2TPv2 can run over UDP. since L2TPv2 can run over UDP.
skipping to change at page 9, line 23 skipping to change at page 10, line 5
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the the capability for the ISP to assign the 64-bit Interface Id to the
host CPE or perform uniqueness validation for the two Interface Ids host CPE or perform uniqueness validation for the two Interface Ids
at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 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 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) 64-bit global prefix to the host CPE via Router Advertisement (RA)
while other configuration options (such as DNS) can be conveyed to while other configuration options (such as DNS) can be conveyed to
the host CPE via DHCPv6/v4. the host CPE via DHCPv6/v4.
#### Get more details on DHCPv6/v4 attributes.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------| |------------------||-----------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | T | | | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE | E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE |
R [network] | | [ network ] | | R [network] | | [ network ] | |
N | LNS | |LAC Client| N | LNS | |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
skipping to change at page 10, line 26 skipping to change at page 10, line 26
()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic ()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 PPP o L2TPv2 o UDP o IPv4
"softwire" "softwire"
<------------------> <------------------>
IPv6CP: capable of /64 intf Id assignment or IPv6CP: capable of /64 intf Id assignment or
uniqueness check uniqueness check
|------------------>/64 prefix |------------------>/64 prefix
RA RA
|------------------>DNS, etc |------------------>DNS, etc.
DHCPv6/v4 DHCPv6/v4
Figure 1: Host CPE as Softwire Initiator Figure 1: Host CPE as Softwire Initiator
3.1.2. Router CPE as Softwire Initiator 3.1.2. Router CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). Softwire IPv6 connectivity across an IPv4-only access network (STH). Softwire
initiator is the router CPE, which is a dual-stack device. The IPv4 initiator is the router CPE, which is a dual-stack device. The IPv4
traffic should not traverse the softwire. traffic should not traverse the softwire.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
PPP o L2TPv2 o UDP o IPv4 PPP o L2TPv2 o UDP o IPv4
"softwire" "softwire"
<------------------> <------------------>
IPv6CP: capable of /64 intf Id assignment or IPv6CP: capable of /64 intf Id assignment or
uniqueness check uniqueness check
|------------------>/64 prefix |------------------>/64 prefix
RA RA
|------------------>/48 prefix, |------------------>/48 prefix,
DHCPv6 DNS, etc DHCPv6 DNS, etc.
|------->/64 prefix |------->/64 prefix
RA RA
|-------> DNS, etc |-------> DNS, etc.
DHCPv4/v6 DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator Figure 2: Router CPE as Softwire Initiator
3.1.3. Host behind CPE as Softwire Initiator 3.1.3. Host behind CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). The CPE IPv6 connectivity across an IPv4-only access network (STH). The CPE
is IPv4-only. Softwire initiator is a dual-stack host (behind IPv4- is IPv4-only. Softwire initiator is a dual-stack host (behind IPv4-
only CPE), which acts as an IPv6 host CPE. The IPv4 traffic should only CPE), which acts as an IPv6 host CPE. The IPv4 traffic should
not traverse the softwire. not traverse the softwire.
skipping to change at page 12, line 26 skipping to change at page 12, line 26
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic PPP o L2TPv2 o UDP o IPv4 traffic
"softwire" "softwire"
<------------------------------> <------------------------------>
IPv6CP: capable of /64 intf Id assignment or IPv6CP: capable of /64 intf Id assignment or
uniqueness check uniqueness check
|------------------------------>/64 prefix |------------------------------>/64 prefix
RA RA
|------------------------------>DNS, etc |------------------------------>DNS, etc.
DHCPv4/v6 DHCPv4/v6
Figure 3: Host behind CPE as Softwire Initiator Figure 3: Host behind CPE as Softwire Initiator
3.1.4. Router behind CPE as Softwire Initiator 3.1.4. Router behind CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network (STH). The CPE IPv6 connectivity across an IPv4-only access network (STH). The CPE
is IPv4-only. Softwire initiator is a dual-stack device (behind the is IPv4-only. Softwire initiator is a dual-stack device (behind the
IPv4-only CPE) acting as an IPv6 CPE router inside the home network. IPv4-only CPE) acting as an IPv6 CPE router inside the home network.
The IPv4 traffic should not traverse the softwire. The IPv4 traffic should not traverse the softwire.
skipping to change at page 13, line 31 skipping to change at page 13, line 31
PPP o L2TPv2 o UDP o IPv4 PPP o L2TPv2 o UDP o IPv4
"softwire" "softwire"
<---------------------------> <--------------------------->
IPv6CP: capable of /64 intf Id assignment or IPv6CP: capable of /64 intf Id assignment or
uniqueness check uniqueness check
|--------------------------->/64 prefix |--------------------------->/64 prefix
RA RA
|--------------------------->/48 prefix, |--------------------------->/48 prefix,
DHCPv6 DNS, etc DHCPv6 DNS, etc.
|----> /64 |----> /64
RA prefix RA prefix
|----> DNS, |----> DNS,
DHCPv4/v6 etc. DHCPv4/v6 etc.
Figure 4: Router behind CPE as Softwire Initiator Figure 4: Router behind CPE as Softwire Initiator
3.2. IPv4 over IPv6 Softwire with L2TPv2 3.2. IPv4 over IPv6 Softwire with L2TPv2
skipping to change at page 14, line 23 skipping to change at page 14, line 23
R [network] | | [ network ] | | R [network] | | [ network ] | |
N | LNS | |LAC Client| N | LNS | |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic ()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 PPP o L2TPv2 o UDP o IPv6
"softwire" "softwire"
<------------------> <------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
and DNS, etc and DNS, etc.
Figure 5: Host CPE as Softwire Initiator Figure 5: Host CPE as Softwire Initiator
3.2.2. Router CPE as Softwire Initiator 3.2.2. Router CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). Softwire IPv4 connectivity across an IPv6-only access network (STH). Softwire
initiator is the router CPE, which is a dual-stack device. The IPv6 initiator is the router CPE, which is a dual-stack device. The IPv6
traffic should not traverse the softwire. traffic should not traverse the softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, IPCP negotiates IPv4 over PPP which also provides
skipping to change at page 15, line 22 skipping to change at page 15, line 22
R [network] | | [ network ] | | | host| R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+ N | LNS | |LAC Client| +-----+
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic ()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 PPP o L2TPv2 o UDP o IPv6
"softwire" "softwire"
<------------------> <------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
and DNS, etc and DNS, etc.
|------------------> |------------------>
DHCPv4: prefix, mask, PD DHCPv4: prefix, mask, PD
private/ private/
|------> global |------> global
DHCP IP, DNS, DHCP IP, DNS,
etc. etc.
Figure 6: Router CPE as Softwire Initiator Figure 6: Router CPE as Softwire Initiator
skipping to change at page 16, line 22 skipping to change at page 16, line 22
R [network] | | [ network ] | CPE | | | R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client| N | LNS | +-------+ |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4 ()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
PPP o L2TPv2 o UDP o IPv6 traffic PPP o L2TPv2 o UDP o IPv6 traffic
"softwire" "softwire"
<------------------------------> <------------------------------>
IPCP: capable of global IP assignment IPCP: capable of global IP assignment
and DNS, etc and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiator Figure 7: Host behind CPE as Softwire Initiator
3.2.4. Router behind CPE as Softwire Initiator 3.2.4. Router behind CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The CPE IPv4 connectivity across an IPv6-only access network (STH). The CPE
is IPv6-only. Softwire initiator is a dual-stack device (behind the is IPv6-only. Softwire initiator is a dual-stack device (behind the
IPv6-only CPE) acting as an IPv4 CPE router inside the home network. IPv6-only CPE) acting as an IPv4 CPE router inside the home network.
The IPv6 traffic should not traverse the softwire. The IPv6 traffic should not traverse the softwire.
skipping to change at page 17, line 25 skipping to change at page 17, line 25
T | T |
--------+-----+ --------+-----+
|v4/v6| |v4/v6|
| host| | host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4 ()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
PPP o L2TPv2 o UDP o IPv4 traffic PPP o L2TPv2 o UDP o IPv4 traffic
"softwire" "softwire"
<---------------------------> <--------------------------->
IPCP: assigns global IP address and DNS, etc IPCP: assigns global IP address and DNS, etc.
|---------------------------> |--------------------------->
DHCPv4: prefix, mask, PD DHCPv4: prefix, mask, PD
private/ private/
|----> global |----> global
DHCP IP, DNS, DHCP IP, DNS,
etc. etc.
Figure 8: Router behind CPE as Softwire Initiator Figure 8: Router behind CPE as Softwire Initiator
skipping to change at page 19, line 11 skipping to change at page 19, line 11
RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). RFC 2461 Neighbor Discovery for IP Version 6 (IPv6).
4.5.2. For IPv4 Payloads 4.5.2. For IPv4 Payloads
RFC 1661 The Point-to-Point Protocol (PPP). RFC 1661 The Point-to-Point Protocol (PPP).
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP). RFC 1332 The PPP Internet Protocol Control Protocol (IPCP).
DHCP Subnet Allocation DHCP Subnet Allocation
Work in progress [I-D.ietf-dhc-subnet-alloc]. Work in progress [I-D.ietf-dhc-subnet-alloc].
5. Provisioning Model 5. Provisioning Model - Best Current Practices
A softwire can provide stable addressing even if the underlying A softwire can provide stable addressing even if the underlying
addressing scheme changes, by opposition to automatic tunneling. A addressing scheme changes, by opposition to automatic tunneling. A
Softwire Concentrator SHOULD always provide the same address and Softwire Concentrator SHOULD always provide the same address and
prefix to a reconnecting user. However, if the goal of the softwire 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 service is to provide a temporary address for a roaming user, it MAY
be provisioned to provide only a temporary address. be provisioned to provide only a temporary address.
The address and prefix is expected to change when reconnecting to a The address and prefix is expected to change when reconnecting to a
different Softwire Concentrator. However an organization providing a different Softwire Concentrator. However an organization providing a
skipping to change at page 19, line 38 skipping to change at page 19, line 38
5.1. Link Addresses 5.1. Link Addresses
5.1.1. IPv6 5.1.1. IPv6
A Softwire Concentrator SHOULD provide globally routable addresses A Softwire Concentrator SHOULD provide globally routable addresses
and prefixes to Softwire Initiators. Other types of addresses such and prefixes to Softwire Initiators. Other types of addresses such
as Unique Local Addresses [RFC4193] MAY be used to connect to a as Unique Local Addresses [RFC4193] MAY be used to connect to a
private network with no global connectivity. private network with no global connectivity.
A single /64 SHOULD be reserved for the PPP link. That /64 MAY be A single /64 SHOULD be reserved for the PPP link.
part of the prefix delegated to the SI.
5.1.2. IPv4 5.1.2. IPv4
A Softwire Concentrator MAY provide either globally routable or A Softwire Concentrator MAY provide either globally routable or
private IPv4 addresses. If private addresses are used, the delegated private IPv4 addresses. If private addresses are used, the delegated
prefix should be in the same address space than the PPP endpoint to prefix should be in the same address space than the PPP endpoint to
avoid nested NAT configurations. A globally routable address is avoid nested NAT configurations. A globally routable address is
preferable, since in most cases, it is expected the CPE device will preferable, since in most cases, it is expected the CPE device will
perform the IPv4 NAT function. perform the IPv4 NAT function.
The PPP link for the IPv4 softwire SHOULD be assigned a /30. The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP.
5.2. Delegated Prefixes 5.2. Delegated Prefixes
5.2.1. IPv6 Prefixes 5.2.1. IPv6 Prefixes
Delegated IPv6 prefixes are between /48 and /64 in length. A CPE Delegated IPv6 prefixes are between /48 and /64 in length. A CPE
device receiving a /64 is expected to perform bridging if more than device receiving a /64 is expected to perform bridging if more than
one interface is available (wired and wireless for example). one interface is available (wired and wireless for example).
The length of delegated IPv6 prefixes SHOULD be a multiple of 4. The length of delegated IPv6 prefixes SHOULD be a multiple of 4.
skipping to change at page 21, line 8 skipping to change at page 21, line 8
Delegated IPv4 prefixes should be of the same scope than the assigned Delegated IPv4 prefixes should be of the same scope than the assigned
IPv4 addresses and be routable within that address space. Prefix IPv4 addresses and be routable within that address space. Prefix
length is between /8 and /30. However, the DNS reverse delegation of length is between /8 and /30. However, the DNS reverse delegation of
prefixes that are not multiples of 8 may be problematic. In the prefixes that are not multiples of 8 may be problematic. In the
worst case of a one bit difference, for example a /25, 128 NS records worst case of a one bit difference, for example a /25, 128 NS records
must be configured in the reverse zone file. must be configured in the reverse zone file.
6. Softwire Establishment 6. Softwire Establishment
A softwire is established in 3 distinct steps (figure 1). First a A softwire is established in 3 distinct steps (Figure 9). First a
L2TP tunnel with a single session is established from the SI to the L2TP tunnel with a single session is established from the SI to the
SC. Second a PPP session is established over the L2TP session and SC. Second a PPP session is established over the L2TP session and
the SI get an address. Third the SI optionally gets other the SI get an address. Third the SI optionally gets other
information through DHCP such as a delegated prefix and DNS servers. information through DHCP such as a delegated prefix and DNS servers.
SC SI SC SI
| | | |
|<-------------L2TP-------------->| L2TP |<-------------L2TP-------------->| L2TP
| | | |
|<-------------PPP--------------->| PPP and |<-------------PPP--------------->| PPP and
skipping to change at page 22, line 8 skipping to change at page 22, line 8
| | | |
|<-------------DHCP-------------->| Additional |<-------------DHCP-------------->| Additional
| | configuration | | configuration
| | (optional) | | (optional)
Figure 9: Steps for the Establishment of a Softwire Figure 9: Steps for the Establishment of a Softwire
SC SI SC SI
| | | |
|<------------SCCRQ---------------| - |<------------SCCRQ---------------| -
|-------------SCCRP-------------->| | |-------------SCCRP-------------->| |
|<------------SCCSN---------------| | L2TP |<------------SCCCN---------------| |
|<------------ICRQ----------------| | |<------------ICRQ----------------| | L2TP
|-------------ICCN--------------->| - |-------------ICRP--------------->| |
|<------------ICCN----------------| -
| | | |
|<-----Configuration-Request------| - |<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP |------Configuration-Request----->| | PPP
|<-------Configuration-Ack--------| | LCP |<-------Configuration-Ack--------| | LCP
|--------Configuration-Ack------->| - |--------Configuration-Ack------->| -
| | | |
|-----------Challenge------------>| - PPP Authentication |-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (CHAP) |<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| - |------------Success------------->| -
| | | |
|<-----Configuration-Request------| - |<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP |------Configuration-Request----->| | PPP NCP
|<-------Configuration-Ack--------| | (IPV6P or IPCP) |<-------Configuration-Ack--------| | (IPV6CP or IPCP)
|--------Configuration-Ack------->| - |--------Configuration-Ack------->| -
| | | |
|<------Router-Solicitation-------| - Neighbor Discovery |<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only) |-------Router-Advertisement----->| | (IPv6 only)
| | - | | -
| | | |
|<-----------Solicit--------------| - |<-----------Solicit--------------| -
|-----------Advertise------------>| | DHCP |-----------Advertise------------>| | DHCP
|<---------- Request--------------| | (Optional) |<---------- Request--------------| | (Optional)
|-------------Reply-------------->| - |-------------Reply-------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire Figure 10: Detailed Steps in the Establishment of a Softwire
6.1. L2TP Tunnel Setup 6.1. L2TP Tunnel Setup
L2TPv2 [RFC2661] was initially designed to connect Network Access L2TPv2 [RFC2661] was initially designed to connect a Network Access
Server (NAS) concentrating traffic from multiple equipments and Server (NAS) concentrating traffic from multiple users to different
Internet Access Providers (IAP). In L2TP terminology, an L2TP Internet Access Providers (IAP). In L2TP terminology, an L2TP
Network Server (LNS) is an equipment concentrating L2TP connection Network Server (LNS) is a device concentrating L2TP connections
coming from L2TP Access Concentrator (LAC) dispatched on the IP coming from an L2TP Access Concentrator (LAC) dispatched on the IP
network. In the Softwires Hub and Spoke model, LAC will act as the network. In the Softwires Hub and Spoke model, the LAC will act as
Softwires Initiator (SI) and LNS as the Softwires Concentrator (SC). the Softwires Initiator (SI) and the LNS as the Softwires
SI can be located on the end user equipment, a special gateway Concentrator (SC). The SI can be located on the end user equipment,
dedicated to handle IPv6 traffic or directly on the home gateway. a special gateway dedicated to handle IPv6 traffic, or directly on
the home gateway.
L2TP packet, in the softwires model MUST be carried over UDP, An L2TP packet, in the softwires model, MUST be carried over UDP.
underlying version of the IP protocol may be IPv4 or IPv6, depending
on the transition scenario deployed.
6.1.1. Tunnel Establishement The underlying version of the IP protocol may be IPv4 or IPv6,
depending on the transition scenario deployed.
The following diagram resumes messages exchange and AVP used to 6.1.1. Tunnel Establishment
establish a communication between a SI (LAC) and a SC (LNS). They
The following diagram describes messages exchanged and AVPs used to
establish communication between an SI (LAC) and an SC (LNS). They
represent a subset of exchanges defined in [RFC2661] mostly to limit represent a subset of exchanges defined in [RFC2661] mostly to limit
implementation complexity on the SI side. One session per tunnel is implementation complexity on the SI side. One session per tunnel is
only needed, since the LAC does not act as a PPP session only needed, since the LAC does not act as a PPP session
concentrator. The LAC MUST always establishes the session and no concentrator. The LAC MUST always establish the session. No
outgoing nor analogical calls are specified. L2TP attributes SHOULD outgoing or analog calls are permitted. L2TP attributes SHOULD NOT
NOT be hidden. be hidden.
LAC (SI) LAC (SC) LAC (SI) LAC (SC)
---------- ---------- ---------- ----------
SCCRQ -> SCCRQ ->
Mandatory AVP Mandatory AVP
Message Type Message Type
Protocol Version Protocol Version
Host Name Host Name
Framing Capabilities Framing Capabilities
Assigned Tunnel ID Assigned Tunnel ID
skipping to change at page 24, line 41 skipping to change at page 24, line 41
(Challenge Response) (Challenge Response)
(Challenge) (Challenge)
SCCCN -> SCCCN ->
Mandatory AVP: Mandatory AVP:
Message Type Message Type
(Challenge Response) (Challenge Response)
<- ZLB ACK <- ZLB ACK
Figure 11: Tunnel Establishement Figure 11: Tunnel Establishment
LAC (SI) LAC (SC) LAC (SI) LAC (SC)
---------- ---------- ---------- ----------
ICRQ -> ICRQ ->
Mandatory AVP: Mandatory AVP:
Message Type Message Type
Assigned Session ID Assigned Session ID
Call Serial Number Call Serial Number
<- ICRP <- ICRP
Mandatory AVP: Mandatory AVP:
skipping to change at page 25, line 25 skipping to change at page 25, line 25
Assigned Session ID Assigned Session ID
ICCN -> ICCN ->
Mandatory AVP: Mandatory AVP:
Message Type Message Type
(Tx) Connect Speed (Tx) Connect Speed
Framing Type Framing Type
<- ZLB ACK <- ZLB ACK
Figure 12: Session Establishement Figure 12: Session Establishment
This paragraph specifies specific values for AVP used in the This paragraph specifies specific values for AVPs used in the
Softwires context. Softwires context.
6.1.1.1. AVPs Required for Sotftwires 6.1.1.1. AVPs Required for Sotftwires
Host Name AVP Host Name AVP
This AVP is mandatory and is present in SCCRQ and SCCRP messages. This AVP is mandatory and is present in SCCRQ and SCCRP messages.
This AVP is for debugging purpose and should not be used to This AVP MAY be used to authenticate users.
authenticate users.
For the LNS, the hostname COULD be the server name with the fully For the LNS, the hostname COULD be the server name with the fully
qualified domain. For the LAC, the name COULD be qualified domain. For the LAC, the name COULD be
user-id@name.fully-qualified-domain. If name or fully-qualified- user-id@name.fully-qualified-domain. If name or fully-qualified-
domain is not configured (since the equipment is in the bootstrap domain is not configured (since the equipment is in the bootstrap
phase) this part CAN be left blank. User-id is the value used to phase) this part CAN be left blank. User-id is the value used to
authenticate the user. If user-id is not defined, "Softwires" authenticate the user. If user-id is not defined, "Softwires"
COULD be used. COULD be used.
Framing Capabilities AVP Framing Capabilities AVP
Synchronous bit MUST be set to 1 and Asynchronous bit to 0. This Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
AVP SHOULD be ignored by the receiver. This AVP MUST be ignored by the receiver.
Framing Type AVP Framing Type AVP
Synchronous bit MUST be set to 1and Asynchronous bit to 0. This Synchronous bit MUST be set to 1and Asynchronous bit to 0. This
AVP SHOULD be ignored by the receiver. AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed (Tx) Connect Speed
(Tx) Connect Speed is a mandatory AVP but is meaningful in (Tx) Connect Speed is a mandatory AVP but is not meaningful in
Softwires context. Value should be left to 0 and ignored by the Softwires context. Value should be left to 0 and ignored by the
receiver. receiver.
Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor
Name, Call Serial Number, and Assigned Session ID Name, Call Serial Number, and Assigned Session ID
As defined in [RFC2661] As defined in [RFC2661]
6.1.1.2. AVPs Optional for Sotftwires 6.1.1.2. AVPs Optional for Sotftwires
Challenge and Challenge Response AVPs Challenge and Challenge Response AVPs
Session authentication as defined in [RFC2661] is based on a Session authentication as defined in [RFC2661] is based on a
shared secret known by LACs and LNSs, and is not designed to shared secret known by LACs and LNSs, and is not designed to
authenticate a specific user. This AVP is not required since authenticate a specific user. This AVP is not required since
security enhancement is not guaranteed. It can be used to limit security enhancement is not guaranteed.
DoS attack but since this secret has to be known by all users
accessing the service, an attacker can learn it easily.
While user authentication is typically done at the PPP level, While user authentication is typically done at the PPP level,
tunnel authentication may be helpful in preventing DoS attacks. tunnel authentication may be helpful in preventing DoS attacks.
6.1.1.3. AVPs not Required for Softwires 6.1.1.3. AVPs not Required for Softwires
L2TP specifies numerous AVPs that, while allowed for a given command, L2TP specifies numerous AVPs that, while allowed for a given command,
are irrelevant to a Softwires. Softwires implementations should not are irrelevant to a Softwires. Softwires implementations should not
send these AVPs. However, they should ignore them when they are send these AVPs. However, they should ignore them when they are
received. This will make it easier to create Softwires applications received. This will make it easier to create Softwires applications
on top of existing L2TP implementations. on top of existing L2TP implementations.
6.1.2. Tunnel Maintenance 6.1.2. Tunnel Maintenance
Periodically, SI must transit some message to the SC to maintain Periodically, the SI must transit a message to the SC to maintain
context in the NAT and can be used to detected tunnel failure (but context in the NAT and detect tunnel failure. The LNS and LAC SHOULD
PPP/LCP may be more reactive). LNS and LAC can generate HELLO use L2TPv2 HELLO messages for this purpose. As specified in
messages. As specified in [RFC2661] HELLO messages SHOULD be [RFC2661] HELLO messages SHOULD be generated if no other messages are
generated if no other messages are sent for a period of time. The sent for a period of time. The value of 60 seconds recommended by
value of 60 seconds recommended by [RFC2661] fulfills Softwires [RFC2661] fulfills Softwires constraints. LCP Echo Request and Reply
constraints. messages SHOULD NOT be used for this purpose. The use of both LCP
Echo and L2TPv2 HELLO messages is redundant in the Softwires
environment.
6.1.3. Tunnel Teardown 6.1.3. Tunnel Teardown
SI and SC can teardown the session and then the tunnel. No change or Either the SI and SC can teardown the session and then the tunnel.
specific parameter are required compared to [RFC2661]. The SI or the No change or specific parameter are required compared to [RFC2661].
SC sends an CDN message, acknowledged by ZLB message. The initiator The SI or the SC sends an CDN message, acknowledged by ZLB message.
of the tunnel teardown, MUST immediately after close the tunnel by The initiator of the tunnel teardown, MUST immediately after close
sending a StopCCN message, acknowledged by a ZLB message. the tunnel by sending a StopCCN message, acknowledged by a ZLB
message.
6.2. PPP Connection 6.2. PPP Connection
6.2.1. MTU 6.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 and L2TP headers together. On a link with a MTU equal to IP, UDP, L2TP, and PPP headers together. On an IPv4 link with an MTU
1500 bytes, this would usually mean a PPP MTU of 1472 bytes. This equal to 1500 bytes, this would usually mean a PPP MTU of 1460 bytes.
may vary according to the size of the L2TP header. This may vary according to the size of the L2TP header.
In order to optimize the link efficiency and prevent fragmentation, a In order to optimize the link efficiency and prevent fragmentation, a
path MTU discovery algorithm may be used to detect the maximum MTU on path MTU discovery algorithm may be used to detect the maximum MTU on
the path between the SI and the SC. However path MTU discovery is the path between the SI and the SC. However path MTU discovery is
out of scope for this document. out of scope for this document.
6.2.2. LCP 6.2.2. LCP
Once the L2TP session is established, the SI initiates the PPP Once the L2TP session is established, the SI initiates the PPP
connection by sending a LCP Configuration Request message. The SC connection by sending a LCP Configuration Request message. The SC
also sends a LCP Configuration Request containing at least the also sends a LCP Configuration Request containing at least the
Maximum Receive Unit option and and authentication protocol. If no Maximum Receive Unit option, authentication protocol and Magic
authentication protocol option is present, the SI considers the Number. If no authentication protocol option is present, the SI
service as un authenticated (see Section 6.2.3). Each party answers considers the service as unauthenticated (see Section 6.2.3). Each
with a Configuration Ack message to finish the link configuration. party answers with a Configuration Ack message to finish the link
configuration.
### Laurent, do you have an example for this section? Negotiations in both directions MUST reject compression of the
Protocol field (PFC), and compression of the Address and Control
fields (ACFC). Link Quality Report SHOULD be disabled on both sides.
The Magic Number option MAY be part of the negotiation. The MRU
value is by default 1500 and can be changed by negotiation.
Figure 13 gives an example of the LCP exchange between an SI and an
SC; the message order is not significant since both negotiations may
start concurrently.
SC: SI:
-- --
LCP Conf-Request
MRU 1500
Magic Number 0x5c35721e
LCP Conf-Ack
MRU 1500
Magic Number 0x5c35721e
LCP Conf-Request
MRU 1500,
Magic-Num 0xcd7f0041,
Auth-Prot CHAP, MD5
LCP Conf-ack
MRU 1500,
Magic-Num 0xcd7f0041,
Auth-Prot CHAP, MD5
Figure 13: LCP Exchange between SI and SC
6.2.3. Authentication 6.2.3. Authentication
After sending the LCP Configuration Ack, the SC proceeds with the PPP After sending the LCP Configuration Ack, the SC proceeds with the PPP
authentication phase. CHAP [RFC1994] authentication MUST be authentication phase. CHAP [RFC1994] authentication MUST be
supported by both the Softwire Initiator and Softwire Concentrator. supported by both the Softwire Initiator and Softwire Concentrator.
Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
be supported. be supported.
The Softwire Concentrator MAY allow non-authenticated connection. In The Softwire Concentrator MAY allow non-authenticated connection. In
skipping to change at page 28, line 20 skipping to change at page 29, line 9
IPV6CP Configuration-Request message [RFC2472] containing an IPV6CP Configuration-Request message [RFC2472] containing an
Interface Identifier. The Interface Identifier SHOULD be of the IEEE Interface Identifier. The Interface Identifier SHOULD be of the IEEE
EUI-64 format. A Configuration-Request message is also sent by the EUI-64 format. A Configuration-Request message is also sent by the
SC. If that message constrains a different Interface Identifier, it SC. If that message constrains a different Interface Identifier, it
MUST be accepted through a Configure-Ack message. MUST be accepted through a Configure-Ack message.
6.2.4.2. IPv4CP 6.2.4.2. IPv4CP
A Softwire Initiator establishing an IPv4 softwire SHOULD send a A Softwire Initiator establishing an IPv4 softwire SHOULD send a
Configuration-Request with all four octets of the IP-Address Configuration-Request with all four octets of the IP-Address
configuration option set to 0 (see [RFC1332]). If all four octets of configuration option set to 0 (see [RFC1332]). If the Softwire
the IP-Address option received from the Softwire Concentrator are set Concentrator does not assign an address to the Softwire Initiator,
to 0, the SI MUST request an address through DHCP, otherwise the the SI MUST request an address through DHCP. The SC may indicate a
address is accepted. failure to assign an address by sending back an address with all
octets set to 0 or by sending a protocol reject in response to the
IPCP CONFREQ.
6.3. Neighbor Discovery 6.3. Neighbor Discovery
The Softwire Initiator of an IPv6 softwire MUST send a Router The Softwire Initiator of an IPv6 softwire MUST send a Router
Sollicitation message to the Softwire Concentrator after IPV6CP is Sollicitation message to the Softwire Concentrator after IPV6CP is
completed. The Softwire Concentrator MUST answer with a Router completed. The Softwire Concentrator MUST answer with a Router
Advertisement containing the global IPv6 prefix of the PPP link. Advertisement containing the global IPv6 prefix of the PPP link.
Duplicate Address Detection (DAD) is redundant in that context and Duplicate Address Detection (DAD) is redundant in that context and
doesn't have to be performed. For that purpose, doesn't have to be performed. For that purpose,
skipping to change at page 29, line 23 skipping to change at page 30, line 13
if a prefix has been allocated. The Prefix length suboption SHOULD if a prefix has been allocated. The Prefix length suboption SHOULD
be 0 by default. If the SI is configured to support only specific be 0 by default. If the SI is configured to support only specific
prefix lengths, it should specify the longest (smallest) prefix prefix lengths, it should specify the longest (smallest) prefix
length it supports. length it supports.
If the SI was previously assigned a prefix from that same SC, it If the SI was previously assigned a prefix from that same SC, it
SHOULD include the Subnet Information suboption with the prefix it SHOULD include the Subnet Information suboption with the prefix it
was previously assigned. The 'c' and 's' bits of the suboption was previously assigned. The 'c' and 's' bits of the suboption
SHOULD be set to '0'. SHOULD be set to '0'.
7. AAA 7. AAA - Best Current Practices
The Softwire Concentrator is expected to act as a client to a AAA The Softwire Concentrator is expected to act as a client to a AAA
server, for example a Radius server. During the PPP authentication server, for example a Radius server. During the PPP authentication
phase, the AAA server may return additional information in the form phase, the AAA server may return additional information in the form
of attributes in the Access Accept message. of attributes in the Access Accept message.
The Softwire Concentrator MAY include the Tunnel-Medium and Tunnel- The Softwire Concentrator MAY include the Tunnel-Type and Tunnel-
Medium-Type attributes [RFC2868] in the Access Request messages to Medium-Type attributes [RFC2868] in the Access Request messages to
provide a hint of the type of softwire being configured. provide a hint of the type of softwire being configured.
7.1. Tunnel Endpoints 7.1. Tunnel Endpoints
7.1.1. IPv6 Softwires 7.1.1. IPv6 Softwires
If the AAA server includes a Framed-Interface-Id attribute [RFC3162], If the AAA server includes a Framed-Interface-Id attribute [RFC3162],
the Softwire Concentrator MUST send it to the Softwire Initiator in the Softwire Concentrator MUST send it to the Softwire Initiator in
the Interface Identifier field of its IPV6CP Configuration Request the Interface Identifier field of its IPV6CP Configuration Request
skipping to change at page 30, line 8 skipping to change at page 30, line 46
MUST choose a prefix with that pool to send router advertisements. MUST choose a prefix with that pool to send router advertisements.
If none of the attributes above are included but the AAA server If none of the attributes above are included but the AAA server
returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
attributes [RFC2868] are present and of the correct address family, attributes [RFC2868] are present and of the correct address family,
these MUST be used in the IPV6CP Interface Identifier and for the these MUST be used in the IPV6CP Interface Identifier and for the
router advertisements. router advertisements.
7.1.2. IPv4 Softwires 7.1.2. IPv4 Softwires
If the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
[RFC2868] are present and of the correct address family, these MUST Concentrator MUST provide that address to the Softwire Initiator
be used in the IPCP IP-Address configuration option. 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.
7.2. Delegated Prefixes 7.2. Delegated Prefixes
7.2.1. IPv6 Prefixes 7.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix [I-D.ietf-radext-delegated- If the attribute Delegated-IPv6-Prefix
prefix] is present in the Radius Access Accept message, it must be [I-D.ietf-radext-delegated-prefix] is present in the Radius Access
used by the Softwire Concentrator for the delegation of the IPv6 Accept message, it must be used by the Softwire Concentrator for the
prefix. Since the prefix delegation is performed by DHCPv6 and the delegation of the IPv6 prefix. Since the prefix delegation is
attribute is linked to a username, the SC MUST associate the DUID of performed by DHCPv6 and the attribute is linked to a username, the SC
a DHCPv6 request to tunnel it came from and its user. MUST associate the DUID of a DHCPv6 request to tunnel it came from
and its user.
7.2.2. IPv4 Prefixes 7.2.2. IPv4 Prefixes
### To complete 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.
8. Maintenance and Statistics 8. Maintenance and Statistics - Best Current Practices
8.1. Radius Accounting 8.1. Radius Accounting
### To complete Radius Accounting for L2TPv2 is well documented (see Section 4.3).
Softwires implementers may use the existing RFCs as appropriate for
their business environment.
8.2. MIBs 8.2. MIBs
See [RFC4293] MIB support for L2TPv2 is well documented (see Section 4.4).
### To complete Softwires implementers may use the existing RFCs as appropriate for
their business environment. Also see [RFC4293]
9. Security Considerations 9. Security Considerations
9.1. Comparison with softwire security analysis The L2PTv2 softwires solution provides the following tools for
security:
9.2. Additional security issues introduced by the integration of the o IPsec [RFC3193] provides the highest level of security.
different protocols
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.
A detailed discussion of softwires security is contained in
[I-D.ietf-softwire-security-requirements].
10. Implementation status 10. Implementation status
11. Open issues 11. Open issues
11.1. Fragmentation and MTU 11.1. Fragmentation and MTU
11.2. AAA Accounting (other draft) 11.2. AAA Accounting (other draft)
12. IANA Considerations 12. IANA Considerations
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
13. Acknowledgements 13. Acknowledgements
The authors would like to acknowledge the following contributors who The authors would like to acknowledge the following contributors who
provided helpful input on this document: Florent Parent, Jordi Palet provided helpful input on this document: Florent Parent, Jordi Palet
Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley,
Francis Dupont. Francis Dupont, and Bruno Stevant.
The authors would also like to acknowledge the participants in the The authors would also like to acknowledge the participants in the
Softwires interim meeting at China University - Hong Kong (February Softwires interim meeting at China University - Hong Kong (February
23-24, 2006). The minutes for this meeting are at 23-24, 2006). The minutes for this meeting are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>.
14. References 14. References
14.1. Normative References 14.1. Normative 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-03 (work in progress), draft-ietf-dhc-subnet-alloc-03 (work in progress),
June 2005. June 2005.
[I-D.ietf-radext-delegated-prefix] [I-D.ietf-radext-delegated-prefix]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-01 (work in Attribute", draft-ietf-radext-delegated-prefix-02 (work in
progress), May 2006. progress), July 2006.
[I-D.ietf-softwire-problem-statement] [I-D.ietf-softwire-problem-statement]
Li, X., "Softwire Problem Statement", Li, X., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-02 (work in draft-ietf-softwire-problem-statement-02 (work in
progress), May 2006. progress), May 2006.
[I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and
Requirements",
draft-ietf-softwire-security-requirements-00 (work in
progress), June 2006.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877, Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995. December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 32, line 26 skipping to change at page 33, line 43
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998. RFC 2472, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. 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.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, Modifications for Tunnel Protocol Support", RFC 2867,
June 2000. June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
skipping to change at page 33, line 38 skipping to change at page 35, line 11
[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.
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 -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 5, Section 7, and Section 8.
o Section 5.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 5.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 6, 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 6, Figure 10: Marked CHAP as "Optional - CHAP".
o Section 6.1, Section 6.1.1, and Section 6.1.3: Minor typographical
error correction and rewording of some sentences for grammar.
o Section 6.1.1.1, Host Name AVP: Removed "for debugging purposes"
and added that MAY be used to authenticate users.
o Section 6.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 6.1.1.1, (Tx) Connect Speed: Correction: "but is *not*
meaningful".
o Section 6.1.1.2, Challenge and Challenge Response AVPs: Removed
the last sentence of the first paragraph. Mailing list comment
from Bill Storer, 5-Jul-2006, text from Laurent Toutain.
o Section 6.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 6.2.1, first paragraph: Fixed PPP MTU calculation.
Mailing list comment from Florent Parent, 10-Jul-2006.
o Section 6.2.2: Updated and augmented the text, and added
Figure 13.
o Section 6.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 7, second paragraph: s/Tunnel-Medium /Tunnel-Type /.
Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 7.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 7.2.2, Section 8.1, Section 8.2, and Section 9.
Revision -00: Revision -00:
o Initial revision. o Initial revision.
Authors' Addresses Authors' Addresses
Bill Storer (editor) Bill Storer (editor)
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 35, line 5 skipping to change at page 38, line 5
Montreal, QC J4B 2Z5 Montreal, QC J4B 2Z5
Canada Canada
Email: jean-francois.tremblay@hexago.com Email: jean-francois.tremblay@hexago.com
Laurent Toutain (editor) Laurent Toutain (editor)
GET/ENST Bretagne GET/ENST Bretagne
Email: Laurent.Toutain@enst-bretagne.fr Email: Laurent.Toutain@enst-bretagne.fr
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 35, line 29 skipping to change at page 38, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 81 change blocks. 
164 lines changed or deleted 302 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/