draft-ietf-softwire-hs-framework-l2tpv2-01.txt   draft-ietf-softwire-hs-framework-l2tpv2-02.txt 
Softwires Working Group B. Storer, Ed. Softwires Working Group B. Storer, Ed.
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos, Ed. Intended status: Standards Track M. Dos Santos
Expires: February 26, 2007 Cisco Systems Expires: May 21, 2007 Cisco Systems
J. Tremblay, Ed. J. Tremblay
Hexago Hexago
L. Toutain, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
August 25, 2006 November 17, 2006
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-01.txt draft-ietf-softwire-hs-framework-l2tpv2-02
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 February 26, 2007. This Internet-Draft will expire on May 21, 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 "Hub and Spoke"
Spokes" 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
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 1.4. Considerations . . . . . . . . . . . . . . . . . . . . . . 6
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 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 . . . . . . . . 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
skipping to change at page 2, line 44 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 - Best Current Practices . . . . . . . . . 19 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 18
5.1. Link Addresses . . . . . . . . . . . . . . . . . . . . . . 19 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 20
5.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 21
5.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 23
5.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 24
5.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 24
5.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 20 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 24
6. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 24
6.1. L2TP Tunnel Setup . . . . . . . . . . . . . . . . . . . . 22 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1.1. AVPs Required for Sotftwires . . . . . . . . . . . 25 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1.2. AVPs Optional for Sotftwires . . . . . . . . . . . 26 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 25
6.1.1.3. AVPs not Required for Softwires . . . . . . . . . 26 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26 5.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 25
6.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 25
6.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 25
6.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 28 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 28
6.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 29
6.3. Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 29
6.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
7. AAA - Best Current Practices . . . . . . . . . . . . . . . . . 30 6. Considerations about the Address Provisioning Model . . . . . 27
7.1. Tunnel Endpoints . . . . . . . . . . . . . . . . . . . . . 30 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 27
7.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 27
7.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 27
7.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 28
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 28
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 28
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 28
8. Maintenance and Statistics - Best Current Practices . . . . . 31 7. Considerations about Address Stability . . . . . . . . . . . . 29
8.1. Radius Accounting . . . . . . . . . . . . . . . . . . . . 31
8.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Considerations about RADIUS Integration . . . . . . . . . . . 29
8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 29
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
10. Implementation status . . . . . . . . . . . . . . . . . . . . 32 9. Considerations for Maintenance and Statistics . . . . . . . . 31
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 31
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11.1. Fragmentation and MTU . . . . . . . . . . . . . . . . . . 32
11.2. AAA Accounting (other draft) . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 40
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 version 2 (L2TPv2) as the phase 1 protocol to be deployed in the
"Hubs and Spokes" solution space. This document describes the Softwires "Hubs and Spokes" solution space. This document describes
framework for the L2TPv2 "Hubs and Spokes" solution, and the the framework for the L2TPv2 "Hubs and Spokes" solution, and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations. to achieve interoperability among different vendor implementations.
In the "Hubs and Spokes" solution space, a Softwire is established to In the "Hubs and Spokes" solution space, a Softwire is established to
provide the home network with IPv4 connectivity across an IPv6-only provide the home network with IPv4 connectivity across an IPv6-only
access network or IPv6 connectivity across an IPv4-only access access network or IPv6 connectivity across an IPv4-only access
network. When L2TPv2 is used in the Softwire context, the voluntary network. When L2TPv2 is used in the Softwire context, the voluntary
tunneling model applies. The Softwire Initiator (SI) at the home tunneling model applies. The Softwire Initiator (SI) at the home
network takes the role of the L2TP Access Concentrator (LAC) client network takes the role of the L2TP Access Concentrator (LAC) client
(initiating both the L2TP tunnel/session and PPP link) while the (initiating both the L2TP tunnel/session and PPP link) while the
skipping to change at page 6, line 12 skipping to change at page 6, line 12
the peer LCCE or to refresh the NAT/PAT translation entry at the CPE the peer LCCE or to refresh the NAT/PAT translation entry at the CPE
or at the other end of the access link. In the event of keepalive 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 the service provider network (See
[I-D.ietf-softwire-problem-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 the customer network (See
[I-D.ietf-softwire-problem-statement]) [I-D.ietf-softwire-problem-statement])
STH Softwire Transport Header (See STH Softwire Transport Header (See
[I-D.ietf-softwire-problem-statement]) [I-D.ietf-softwire-problem-statement])
SPH Softwire Payload Header (See SPH Softwire Payload Header (See
[I-D.ietf-softwire-problem-statement]) [I-D.ietf-softwire-problem-statement])
1.2. Requirements Language 1.2. Requirements Language
skipping to change at page 6, line 43 skipping to change at page 6, line 43
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
Bruno Stevant
GET/ENST Bretagne GET/ENST Bretagne
1.4. Best Current Practices 1.4. Considerations
Some sections of this document contain recommendations that are not Some sections of this document contain considerations that are not
required for interoperability and correct operation of softwires required for interoperability and correct operation of Softwire
implementations. These sections are marked as "Best Current implementations. These sections are marked as "Considerations".
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 identified by the Softwire Problem Statement
[I-D.ietf-softwire-problem-statement]. The following section [I-D.ietf-softwire-problem-statement]. The following section
describes how L2TPv2 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)
skipping to change at page 7, line 28 skipping to change at page 7, line 28
(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.
Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2 Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2
does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/ does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/
PAT "autodetect" and UDP bypass are optional requirements. PAT "autodetect" and UDP bypass are optional requirements.
2.2. Scalability 2.2. Scalability
In the "Hubs and Spokes" model, a carrier must be able to scale the In the "Hubs and Spokes" model, a carrier must be able to scale the
solution to millions of softwire initiators by adding more hubs (i.e. solution to millions of Softwire initiators by adding more hubs (i.e.
softwire concentrators). L2TPv2 is a widely deployed protocol in Softwire concentrators). L2TPv2 is a widely deployed protocol in
broadband services, and its scalability has been proven in multiple broadband services, and its scalability has been proven in multiple
large-scale IPv4 Virtual Private Network deployments which scale up large-scale IPv4 Virtual Private Network deployments which scale up
to millions of subscribers each. to millions of subscribers each.
2.3. Multicast 2.3. Multicast
Multicast protocols simply run over L2TPv2 Softwires transparently Multicast protocols simply run over L2TPv2 Softwires transparently
together with other regular IP traffic. together with other regular IP traffic.
2.4. Authentication, Authorization and Accounting 2.4. Authentication, Authorization and Accounting
skipping to change at page 9, line 13 skipping to change at page 9, line 13
For the "Hubs and Spokes" problem space, four scenarios have been For the "Hubs and Spokes" problem space, four scenarios have been
identified. In each of these four scenarios, different home identified. In each of these four scenarios, different home
equipment plays the role of the Softwire Initiator. This section equipment plays the role of the Softwire Initiator. This section
elaborates each scenario with L2TPv2 as the Softwire protocol and elaborates each scenario with L2TPv2 as the Softwire protocol and
other possible protocols involved to complete the solution. This other possible protocols involved to complete the solution. This
section examines the four scenarios for both IPv6 over IPv4 and IPv4 section examines the four scenarios for both IPv6 over IPv4 and IPv4
over IPv6 encapsulations. over IPv6 encapsulations.
3.1. IPv6 over IPv4 Softwire with L2TPv2 3.1. IPv6 over IPv4 Softwire with L2TPv2
The following subsections cover IPv6 connectivity across an IPv4-only
access network using a Softwire.
3.1.1. Host CPE as Softwire Initiator 3.1.1. Host CPE as Softwire Initiator
IPv6 connectivity across an IPv4-only access network Softwire Softwire initiator is the host CPE (directly connected to a modem),
Transport Header (STH). Softwire initiator is the host CPE (directly which is dual-stack. There is no other gateway device. The IPv4
connected to a modem), which is dual-stack. There is no other traffic should not traverse the softwire.
gateway device. The IPv4 traffic should not traverse the softwire.
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.
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 +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- 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 Softwire initiator is the router CPE, which is a dual-stack device.
initiator is the router CPE, which is a dual-stack device. The IPv4 The IPv4 traffic should not traverse the Softwire.
traffic should not traverse the softwire.
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
router CPE or perform uniqueness validation for the two Interface Ids router 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 router CPE via Router Advertisement (RA). 64-bit global prefix to the router CPE via Router Advertisement (RA).
DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating
a 48-bit prefix to be used within the home network) and convey other a 48-bit prefix to be used within the home network) and convey other
configuration options (such as DNS) to the router CPE. configuration options (such as DNS) to the router CPE.
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]....| CPE |----|v4/v6| E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....| CPE |----|v4/v6|
R [network] | | [ network ] | | | host| R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+ N | LNS | |LAC Client| +-----+
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-------- 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
|------------------>/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 The CPE is IPv4-only. Softwire initiator is a dual-stack host
is IPv4-only. Softwire initiator is a dual-stack host (behind IPv4- (behind IPv4- only CPE), which acts as an IPv6 host CPE. The IPv4
only CPE), which acts as an IPv6 host CPE. The IPv4 traffic should traffic should not traverse the Softwire.
not traverse the softwire.
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 or perform uniqueness validation for the two Interface Ids at host or perform uniqueness validation for the two Interface Ids at
the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor 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 via Router Advertisement (RA) while 64-bit global prefix to the host via Router Advertisement (RA) while
other configuration options (such as DNS) can be conveyed to the host other configuration options (such as DNS) can be conveyed to the host
via DHCPv6/v4. via DHCPv6/v4.
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]....|v4-only|--| host | E <==[ IPv6 ]....|v4/v6|....[IPv4~only]....|v4-only|--| host |
R [network] | | [ network ] | CPE | | | R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client| N | LNS | +-------+ |LAC Client|
E +-----+ +----------+ E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _ T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- 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 The CPE is IPv4-only. Softwire initiator is a dual-stack device
is IPv4-only. Softwire initiator is a dual-stack device (behind the (behind the IPv4-only CPE) acting as an IPv6 CPE router inside the
IPv4-only CPE) acting as an IPv6 CPE router inside the home network. home network. The IPv4 traffic should not traverse the Softwire.
The IPv4 traffic should not traverse the softwire.
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
v4/v6 router or perform uniqueness validation for the two Interface v4/v6 router or perform uniqueness validation for the two Interface
Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up,
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
assign a 64-bit global prefix to the v4/v6 router via Router assign a 64-bit global prefix to the v4/v6 router via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (for example, delegating a 48-bit prefix to be used within Delegation (for example, delegating a 48-bit prefix to be used within
the home network) and convey other configuration options (such as the home network) and convey other configuration options (such as
DNS) to the v4/v6 router. DNS) to the v4/v6 router.
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]..|v4-only|---| router | E <==[ IPv6 ]....|v4/v6|..[IPv4~only]..|v4-only|---| router |
R [network] | | [ network ] | CPE | | | | R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client| N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+ E +-----+ | +----------+
T | T |
---------+-----+ ---------+-----+
|v4/v6| |v4/v6|
| host| | host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+ _ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--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
|--------------------------->/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
The following subsections cover IPv4 connectivity across an IPv6-only
access network using a Softwire.
3.2.1. Host CPE as Softwire Initiator 3.2.1. Host CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). Softwire Softwire initiator is the host CPE (directly connected to a modem),
initiator is the host CPE (directly connected to a modem), which is which is dual-stack. There is no other gateway device. The IPv6
dual-stack. There is no other gateway device. The IPv6 traffic traffic should not traverse the Softwire.
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
the capability for the ISP to assign a global IPv4 address to the the capability for the ISP to assign a global IPv4 address to the
host CPE. Global IPv4 address can also be assigned via DHCP. Other host CPE. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP. via IPCP [RFC1877] or DHCP.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||---------| |------------------||-----------------||---------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | T | | | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE | E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| host CPE |
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
the capability for the ISP to assign a global IPv4 address to the the capability for the ISP to assign a global IPv4 address to the
router CPE. Global IPv4 address can also be assigned via DHCP. router CPE. 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
router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used. for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
IPv4 or dual-stack IPv6-only dual-stack Home IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------| |------------------||-----------------||-------------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | | v4/v6 | +-----+ T | | | v4/v6 | +-----+
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6| E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....| CPE |--|v4/v6|
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
3.2.3. Host behind CPE as Softwire Initiator 3.2.3. Host 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 host (behind the is IPv6-only. Softwire initiator is a dual-stack host (behind the
IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should
not traverse the softwire. 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
the capability for the ISP to assign a global IPv4 address to the the capability for the ISP to assign a global IPv4 address to the
host. Global IPv4 address can also be assigned via DHCP. Other host. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP. via IPCP [RFC1877] or DHCP.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------| |------------------||----------------------------||----------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host | E <==[ IPv4 ]....|v4/v6|....[IPv6~only]....|v6-only|--| host |
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.
In this scenario, IPCP negotiates IPv4 over PPP which also provides In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 IP address to the the capability for the ISP to assign a global IPv4 IP address to the
v4/v6 router. Global IPv4 address can also be assigned via DHCP. v4/v6 router. 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.
IPv4 or dual-stack IPv6-only dual-stack IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------| |------------------||-------------------------||------------|
I SC SI I SC SI
N +-----+ +----------+ N +-----+ +----------+
T | | +-------+ | v4/v6 | T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router | E <==[ IPv4 ]....|v4/v6|..[IPv6~only]..|v6-only|---| router |
R [network] | | [ network ] | CPE | | | | R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client| N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+ E +-----+ | +----------+
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,
skipping to change at page 18, line 12 skipping to change at page 18, line 12
4.2. L2TPv2 4.2. L2TPv2
RFC 2661 Layer Two Tunneling Protocol "L2TP". RFC 2661 Layer Two Tunneling Protocol "L2TP".
For both IPv4 and IPv6 payloads, support is complete. For both IPv4 and IPv6 payloads, support is complete.
For both IPv4 and IPv6 transport, support is complete. For both IPv4 and IPv6 transport, support is complete.
4.3. Authentication Authorization Accounting 4.3. Authentication Authorization Accounting
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol
Support. Support.
Need new extensions for IPv6 traffic accounting
[I-D.stevant-softwire-accounting].
RFC 2865 Remote Authentication Dial In User Service (RADIUS). RFC 2865 Remote Authentication Dial In User Service (RADIUS).
RFC 3162 RADIUS and IPv6. RFC 3162 RADIUS and IPv6.
4.4. MIB 4.4. MIB
RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information
Base. Base.
RFC 4087 IP Tunnel MIB. RFC 4087 IP Tunnel MIB.
Both IPv4 and IPv6 transport is supported. Both IPv4 and IPv6 transport is supported.
Do we need a new set of counters for IPv6 Payloads?
l2tpDomainStatsPayloadHCRxOctets
l2tpDomainStatsPayloadHCRxPkts
l2tpDomainStatsPayloadHCRxDiscs
l2tpDomainStatsPayloadHCTxOctets
l2tpDomainStatsPayloadHCTxPkts
4.5. Softwire Payload Related 4.5. Softwire Payload Related
4.5.1. For IPv6 Payloads 4.5.1. For IPv6 Payloads
RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]. RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2].
RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC 3646 DNS Configuration options for Dynamic Host Configuration RFC 3646 DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). Protocol for IPv6 (DHCPv6).
skipping to change at page 19, line 4 skipping to change at page 18, line 39
RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]. RFC 2472 IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2].
RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC 3646 DNS Configuration options for Dynamic Host Configuration RFC 3646 DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6). Protocol for IPv6 (DHCPv6).
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 - Best Current Practices 5. Softwire Establishment
A softwire can provide stable addressing even if the underlying
addressing scheme changes, by opposition to automatic tunneling. A
Softwire Concentrator SHOULD always provide the same address and
prefix to a reconnecting user. However, if the goal of the softwire
service is to provide a temporary address for a roaming user, it MAY
be provisioned to provide only a temporary address.
The address and prefix is expected to change when reconnecting to a
different Softwire Concentrator. However an organization providing a
softwire service MAY provide the same address and prefix across
different Softwire Concentrators at the cost of a more fragmented
routing table. The routing fragmentation issue may be limited if the
prefixes are aggregated in a location topologically close to the SC.
This would be the case for example if several SCs are put in parallel
for load-balancing purpose.
5.1. Link Addresses
5.1.1. IPv6
A Softwire Concentrator SHOULD provide globally routable addresses
and prefixes to Softwire Initiators. Other types of addresses such
as Unique Local Addresses [RFC4193] MAY be used to connect to a
private network with no global connectivity.
A single /64 SHOULD be reserved for the PPP link.
5.1.2. IPv4
A Softwire Concentrator MAY provide either globally routable or
private IPv4 addresses. If private addresses are used, the delegated
prefix should be in the same address space than the PPP endpoint to
avoid nested NAT configurations. A globally routable address is
preferable, since in most cases, it is expected the CPE device will
perform the IPv4 NAT function.
The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP.
5.2. Delegated Prefixes
5.2.1. IPv6 Prefixes
Delegated IPv6 prefixes are between /48 and /64 in length. A CPE
device receiving a /64 is expected to perform bridging if more than
one interface is available (wired and wireless for example).
The length of delegated IPv6 prefixes SHOULD be a multiple of 4.
Reverse DNS delegation of IPv6 prefixes that are not multiples of 4
is more complex since more than one record must be inserted in the
zone file. In the worst case, up to 8 records have to be entered for
one prefix if the prefix length is equal to a multiple of 4 plus 1
(/61 for example).
Example:
One NS record is required for the reverse DNS delegation of 2001:
db8:1:10::/60
NS 1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
Several (8) NS records are required for the reverse DNS delegation
of 2001:db8:1:10::/61
NS 0.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 1.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 2.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 3.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 4.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 5.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 6.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
NS 7.1.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.example.com
5.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be of the same scope than the assigned
IPv4 addresses and be routable within that address space. Prefix
length is between /8 and /30. However, the DNS reverse delegation of
prefixes that are not multiples of 8 may be problematic. In the
worst case of a one bit difference, for example a /25, 128 NS records
must be configured in the reverse zone file.
6. Softwire Establishment
A softwire is established in 3 distinct steps (Figure 9). 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 L2TPv2 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 L2TPv2 session and
the SI get an address. Third the SI optionally gets other the SI obtains 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 |<-------------L2TPv2------------>| Step 1
| | | | L2TPv2 Tunnel establishment
|<-------------PPP--------------->| PPP and
|<-------Neighbor Discovery------>| configuration
| | | |
|<-------------DHCP-------------->| Additional |<-------------PPP--------------->| Step 2
|<----End Point Configuration---->| PPP and End Point
| | configuration | | configuration
| |
|<------Router Configuration----->| Step 3
| | Additional configuration
| | (optional) | | (optional)
Figure 9: Steps for the Establishment of a Softwire Figure 9: Steps for the Establishment of a Softwire
In the following diagram (Figure 10), each of the three steps
required to establish a Softwire is described in detail.
SC SI SC SI
| | | |
| | Step 1
|<------------SCCRQ---------------| - |<------------SCCRQ---------------| -
|-------------SCCRP-------------->| | |-------------SCCRP-------------->| |
|<------------SCCCN---------------| | |<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TP |<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| | |-------------ICRP--------------->| |
|<------------ICCN----------------| - |<------------ICCN----------------| -
| | | |
| | Step 2
|<-----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--------------| | (Optional - CHAP) |<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| - |------------Success------------->| -
| | | |
|<-----Configuration-Request------| - |<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP |------Configuration-Request----->| | PPP NCP
|<-------Configuration-Ack--------| | (IPV6CP 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)
| | - | | -
| | | |
| | Step3
|<-----------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 5.1. L2TPv2 Tunnel Setup
L2TPv2 [RFC2661] was initially designed to connect a Network Access L2TPv2 [RFC2661] was originally designed to provide private network
Server (NAS) concentrating traffic from multiple users to different access to end users connected to a public network. In the L2TPv2
Internet Access Providers (IAP). In L2TP terminology, an L2TP model, the end user makes a connection to an L2TP Access Concentrator
Network Server (LNS) is a device concentrating L2TP connections (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network
coming from an L2TP Access Concentrator (LAC) dispatched on the IP Server (LNS). The LNS then transfers end user traffic between the
network. In the Softwires Hub and Spoke model, the LAC will act as L2TPv2 tunnel and the private network.
the Softwires Initiator (SI) and the LNS as the Softwires
Concentrator (SC). The SI can be located on the end user equipment,
a special gateway dedicated to handle IPv6 traffic, or directly on
the home gateway.
An L2TP packet, in the softwires model, MUST be carried over UDP. In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
assumes the role of the LAC and the Softwire Concentrator assumes the
role of the LNS.
In the Softwire model, an L2TPv2 packet MUST be carried over UDP.
The underlying version of the IP protocol may be IPv4 or IPv6, The underlying version of the IP protocol may be IPv4 or IPv6,
depending on the transition scenario deployed. depending on the Softwires scenario.
6.1.1. Tunnel Establishment 5.1.1. Tunnel Establishment
The following diagram describes messages exchanged and AVPs used to The following diagram, (Figure 11), describes messages exchanged and
establish communication between an SI (LAC) and an SC (LNS). They AVPs used to establish a tunnel between an SI (LAC) and an SC (LNS).
represent a subset of exchanges defined in [RFC2661] mostly to limit The messages and AVPs described here are only a subset of those
implementation complexity on the SI side. One session per tunnel is defined in [RFC2661]. This is because Softwires uses only a subset
only needed, since the LAC does not act as a PPP session of the L2TPv2 functionality. One session per tunnel is needed. Note
concentrator. The LAC MUST always establish the session. No that in the Softwires environment, the SI always initiates the
outgoing or analog calls are permitted. L2TP attributes SHOULD NOT tunnel. No outgoing or analog calls are permitted. L2TPv2
be hidden. attributes SHOULD NOT be hidden.
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
Optional AVP: Optional AVP:
Receive Window Size Receive Window Size
Firmware Revision Firmware Revision
Vendor Name Vendor Name
(Challenge) (Challenge)
<- SCCRP SCCRP
Mandatory AVP: Mandatory AVP:
Message Type Message Type
Protocol Version Protocol Version
Framing Capabilities Framing Capabilities
Host Name Host Name
Assigned Tunnel ID Assigned Tunnel ID
Optional AVP: Optional AVP:
Firmware Revision Firmware Revision
Vendor Name Vendor Name
Receive Window Size Receive Window Size
(Challenge Response) (Challenge Response)
(Challenge) (Challenge)
SCCCN -> SCCCN
Mandatory AVP: Mandatory AVP:
Message Type Message Type
(Challenge Response) (Challenge Response)
<- ZLB ACK
Figure 11: Tunnel Establishment Figure 11: Tunnel Establishment
LAC (SI) LAC (SC)
---------- ---------- In L2TPv2, the tunnel between a LAC and LNS may carry the data of
ICRQ -> multiple users. Each of these user's is represented by an L2TPv2
session within the tunnel. In the Softwires environment, the tunnel
carries the information of a single user. So, there is only one
L2TPv2 session per tunnel. The following diagram, (Figure 12),
describes messages exchanged and AVPs used to establish a session
between an SI (LAC) and an SC (LNS). The messages and AVPs described
here are only a subset of those defined in [RFC2661]. This is
because Softwires uses only a subset of the L2TPv2 functionality.
Note that in the Softwires environment, the SI always initiates the
session. No outgoing or analog calls are permitted. L2TPv2
attributes SHOULD NOT be hidden.
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:
Message Type Message Type
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
Figure 12: Session Establishment Figure 12: Session Establishment
5.1.1.1. AVPs Required for Softwires
This paragraph specifies specific values for AVPs 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
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 MAY be used to authenticate users. This AVP may be used to authenticate users, in which case it would
contain a user identification. If this AVP is not used to
For the LNS, the hostname COULD be the server name with the fully authenticate users, it may be used for documention.
qualified domain. For the LAC, the name COULD be
user-id@name.fully-qualified-domain. If name or fully-qualified-
domain is not configured (since the equipment is in the bootstrap
phase) this part CAN be left blank. User-id is the value used to
authenticate the user. If user-id is not defined, "Softwires"
COULD be used.
Framing Capabilities AVP Framing Capabilities AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1.
This AVP MUST be ignored by the receiver. This AVP SHOULD be ignored by the receiver.
Framing Type AVP Framing Type AVP
Synchronous bit MUST be set to 1 and Asynchronous bit to 0. This
AVP SHOULD be ignored by the receiver. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
This AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed (Tx) Connect Speed
(Tx) Connect Speed is a mandatory AVP but is not meaningful in (Tx) Connect Speed is a mandatory AVP but is not meaningful in the
Softwires context. Value should be left to 0 and ignored by the Softwires context. It 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 5.1.1.2. AVPs Optional for Softwires
Challenge and Challenge Response AVPs Challenge and Challenge Response AVPs
Session authentication as defined in [RFC2661] is based on a These AVPs are not required, but are necessary to implement tunnel
shared secret known by LACs and LNSs, and is not designed to authentication. Since tunnel authentication happens at the
authenticate a specific user. This AVP is not required since beginning of L2TPv2 tunnel creation, it can be helpful in
security enhancement is not guaranteed. preventing DoS attacks.
While user authentication is typically done at the PPP level,
tunnel authentication may be helpful in preventing DoS attacks.
6.1.1.3. AVPs not Required for Softwires 5.1.1.3. AVPs not Relevant for Softwires
L2TP specifies numerous AVPs that, while allowed for a given command, L2TPv2 specifies numerous AVPs that, while allowed for a given
are irrelevant to a Softwires. Softwires implementations should not command, are irrelevant to a Softwires. Softwires implementations
send these AVPs. However, they should ignore them when they are should not send these AVPs. However, they should ignore them when
received. This will make it easier to create Softwires applications they are received. This will make it easier to create Softwires
on top of existing L2TP implementations. applications on top of existing L2TPv2 implementations.
6.1.2. Tunnel Maintenance 5.1.2. Tunnel Maintenance
Periodically, the SI must transit a message to the SC to maintain Periodically, the SI must transit a message to the SC to maintain NAT
context in the NAT and detect tunnel failure. The LNS and LAC SHOULD context and detect tunnel failure. The L2TPv2 HELLO message provides
use L2TPv2 HELLO messages for this purpose. As specified in a simple, low overhead method of doing this. However, using the
[RFC2661] HELLO messages SHOULD be generated if no other messages are default values specified in [RFC2661] could result in a dead end
sent for a period of time. The value of 60 seconds recommended by detection time of 83 seconds. If this is not acceptable, LCP Echo
[RFC2661] fulfills Softwires constraints. LCP Echo Request and Reply Request and Reply messages may be used for quicker dead end
messages SHOULD NOT be used for this purpose. The use of both LCP detection.
Echo and L2TPv2 HELLO messages is redundant in the Softwires
environment.
6.1.3. Tunnel Teardown 5.1.3. Tunnel Teardown
Either the SI and SC can teardown the session and then the tunnel. Either the SI or SC can teardown the session and tunnel. This is
No change or specific parameter are required compared to [RFC2661]. done as specified in [RFC2661]. There is no action specific to
The SI or the SC sends an CDN message, acknowledged by ZLB message. Softwires in this case.
The initiator of the tunnel teardown, MUST immediately after close
the tunnel by sending a StopCCN message, acknowledged by a ZLB
message.
6.2. PPP Connection 5.2. PPP Connection
6.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, L2TP, and PPP headers together. On an IPv4 link with an MTU IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an
equal to 1500 bytes, this would usually mean a PPP MTU of 1460 bytes. MTU equal to 1500 bytes, this would usually mean a PPP MTU of 1460
This may vary according to the size of the L2TP header. bytes. This may vary according to the size of the L2TP header. See
[RFC4623] for a detailed discussion of fragmentation issues.
In order to optimize the link efficiency and prevent fragmentation, a
path MTU discovery algorithm may be used to detect the maximum MTU on
the path between the SI and the SC. However path MTU discovery is
out of scope for this document.
6.2.2. LCP
Once the L2TP session is established, the SI initiates the PPP
connection by sending a LCP Configuration Request message. The SC
also sends a LCP Configuration Request containing at least the
Maximum Receive Unit option, authentication protocol and Magic
Number. If no authentication protocol option is present, the SI
considers the service as unauthenticated (see Section 6.2.3). Each
party answers with a Configuration Ack message to finish the link
configuration.
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 5.2.2. LCP
MRU 1500
Magic Number 0x5c35721e
LCP Conf-Request Once the L2TPv2 session is established, the SI and SC initiate the
MRU 1500, PPP connection by negotiating LCP as described in [RFC1661]. ACFC
Magic-Num 0xcd7f0041, [RFC1662] SHOULD be rejected.
Auth-Prot CHAP, MD5
LCP Conf-ack
MRU 1500,
Magic-Num 0xcd7f0041,
Auth-Prot CHAP, MD5
Figure 13: LCP Exchange between SI and SC 5.2.3. Authentication
6.2.3. Authentication After completing LCP negotiation, the SI and SC may optionally
perform authentication. If authentication is chosen, CHAP [RFC1994]
authentication MUST be supported by both the Softwire Initiator and
Softwire Concentrator. Other authentication methods such as PAP
[RFC1994], MS-CHAP [RFC2433], and EAP [RFC3748] MAY be supported.
After sending the LCP Configuration Ack, the SC proceeds with the PPP A detailed discussion of Softwires security is contained in
authentication phase. CHAP [RFC1994] authentication MUST be [I-D.ietf-softwire-security-requirements]
supported by both the Softwire Initiator and Softwire Concentrator.
Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
be supported.
The Softwire Concentrator MAY allow non-authenticated connection. In 5.2.4. IPCP
that case, the SC acts as a gateway for anonymous connections. This
approach is better than an open relay implementation since ingress
filtering is performed on established tunnels (see Section 9). If
non-authenticated connections are supported by the SC, enabling this
function MUST be configurable by the SC administrator.
6.2.4. IPCP 5.2.4.1. IPv6CP
6.2.4.1. IPv6CP In the IPv6 over IPv4 scenarios (see Section 3.1), after the
authentication phase, the Softwire Initiator MUST negotiate IPv6CP as
defined in [RFC2472]. IPv6CP provides a way to negotiate a unique
64-bit interface identifier to be used for the address
autoconfiguration at the local end of the link.
After the authentication phase, the Softwire Initiator MUST send an 5.2.4.2. IPv4CP
IPV6CP Configuration-Request message [RFC2472] containing an
Interface Identifier. The Interface Identifier SHOULD be of the IEEE
EUI-64 format. A Configuration-Request message is also sent by the
SC. If that message constrains a different Interface Identifier, it
MUST be accepted through a Configure-Ack message.
6.2.4.2. IPv4CP In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire
Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain
an IPv4 address from the SC. IPCP may also be used to obtain DNS
information as described in [RFC1877].
A Softwire Initiator establishing an IPv4 softwire SHOULD send a 5.3. Global IPv6 Address Assignement to Endpoints
Configuration-Request with all four octets of the IP-Address
configuration option set to 0 (see [RFC1332]). If the Softwire
Concentrator does not assign an address to the Softwire Initiator,
the SI MUST request an address through DHCP. The SC may indicate a
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 In several scenario defined in Section 3, Global IPv6 addresses are
expected to be allocated to Softwires end points. Since IPv6CP only
provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery
[RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these
addresses.
The Softwire Initiator of an IPv6 softwire MUST send a Router The Softwire Initiator of an IPv6 Softwire MUST send a Router
Sollicitation message to the Softwire Concentrator after IPV6CP is Solicitation 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. This message MUST contains the global IPv6 prefix of
the PPP link if Neighbor discovery is used to configure addresses of
Softwire end points.
Duplicate Address Detection (DAD) is redundant in that context and If DHCPv6 is available for address delegation, the M bits of the
doesn't have to be performed. For that purpose, Router Advertisement SHOULD be set. The Softwire Initiator MUST then
DupAddrDetectTransmits autoconfiguration variable to zero [RFC2472] send a DHCPv6 Request to configure the address of the Softwire
[RFC2462]. endpoint.
If DHCPv6 is available, the M bits of the Router Advertisement SHOULD Duplicate Address Detection ([I-D.ietf-ipv6-2461bis]) MUST be
be set. performed on the Softwire in both cases.
6.4. DHCP 5.4. DHCP
The Softwire Initiator MAY use DHCP to get additional information The Softwire Initiator MAY use DHCP to get additional information
such as delegated prefix and DNS servers. If the SI supports DHCP, such as delegated prefix and DNS servers. If the SI supports DHCP,
it SHOULD send a Solicit message to verify if more information is it SHOULD send a Solicit message to verify if more information is
available. available.
6.4.1. DHCPv6 When delegating an IPv4 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire.
5.4.1. DHCPv6
IF a SI establishing an IPv6 Softwire acts as a router (scenarios IF a SI establishing an IPv6 Softwire acts as a router (scenarios
3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the 3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the
DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix. DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.
6.4.2. DHCPv4 When delegating an IPv6 prefix to the SI, the SC SHOULD inject a
route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire.
A SI establishing an IPv4 softwire MAY send a DHCP request containing 5.4.2. DHCPv4
the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. One
Subnet-Request suboption MUST be configured with the 'h' bit set to A SI establishing an IPv4 Softwire MAY send a DHCP request containing
'1', as the SI is expected to perform the DHCP server function. The the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. This
'i' bit of the Subnet-Request suboption should be set to '0' the practice is not common but may be used to connect IPv4 subnets using
Softwires, as defined in Section 3.2.2 and Section 3.2.4.
One Subnet-Request suboption MUST be configured with the 'h' bit set
to '1', as the SI is expected to perform the DHCP server function.
The 'i' bit of the Subnet-Request suboption should be set to '0' the
first time a prefix is requested and to '1' on subsequent requests, first time a prefix is requested and to '1' on subsequent requests,
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 - Best Current Practices 6. Considerations about the Address Provisioning Model
This section describes how a Softwire Concentrator may manage
delegated addresses for Softwire endpoints and for subnets behind the
Softwire Initiator. One common practice is to aggregate endpoints
addresses and delegated prefixes into one prefix routed to the SC.
The main benefit is to ease the routing scheme by isolating on the SC
succeeding route injections (when delegating new prefixes for SI).
6.1. Softwire Endpoints Addresses
6.1.1. IPv6
A Softwire Concentrator should provide globally routable addresses to
Softwire endpoints. Other types of addresses such as Unique Local
Addresses [RFC4193] may be used to address Softwire end points in a
private network with no global connectivity. A single /64 should be
assigned to the Softwire to address both Softwire endpoints.
Global or ULA addresses must be assigned to endpoints when the
scenario "Host CPE as Softwire Initiator" (described in
Section 3.1.1) is considered to be deployed. For other scenarios,
this may be optional and link local addresses should be used.
6.1.2. IPv4
A Softwire Concentrator may provide either globally routable or
private IPv4 addresses. When using IPv4 private addresses [RFC1918]
on the endpoints, it is not not recommended to delegate an IPv4
private prefix to the SI, as it can lead to a nested-NAT situations.
The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP.
6.2. Delegated Prefixes
6.2.1. IPv6 Prefixes
Delegated IPv6 should be of global scope if assigned IPv6 addresses
for endpoints are global. Using ULA addresses is not recommended
when subnet is connected to the global IPv6 Internet. When using ULA
IPv6 address for endpoint, Delegated IPv6 prefix may be either of
Global or ULA scope.
Delegated IPv6 prefixes are between /48 and /64 in length. When a SI
receives a prefix shorter than 64, it can assign different /64
prefixes to each of its interfaces. A SI receiving a single /64 is
expected to perform bridging if more than one interface are available
(wired and wireless for example).
6.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be of the same scope than the assigned
IPv4 addresses and be routable within that address space. Prefix
length is between /8 and /30.
6.3. Possible scenarios
This section summarizes the differents scenarios for address
provisioning with the considerations given in the previous sections.
6.3.1. Scenarios for IPv6
This table describes the possible combination of IPv6 address scope
for endpoints and delegated prefixes.
+------------------+-----------------------+------------------------+
| Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 |
| Address | Prefix | Prefix |
+------------------+-----------------------+------------------------+
| Link Local | Possible | Possible |
| | | |
| ULA | Possible | Possible |
| | | |
| Global | Possible | Possible, but Not |
| | | Recommended |
+------------------+-----------------------+------------------------+
Table 1: Scenarios for IPv6
6.3.2. Scenarios for IPv4
This table describes the possible combination of IPv6 address scope
for endpoints and delegated prefixes.
+------------------+-----------------------+------------------------+
| Endpoint IPv4 | Delegated Public IPv4 | Delegated Private IPv4 |
| Address | Prefix | Prefix |
+------------------+-----------------------+------------------------+
| Private IPv4 | Possible | Possible, but Not |
| | | Recommended |
| | | |
| Public IPv4 | Possible | Possible |
+------------------+-----------------------+------------------------+
Table 2: Scenarios for IPv4
7. Considerations about Address Stability
A Softwire can provide stable addresses even if the underlying
addressing scheme changes, by opposition to automatic tunneling. A
Softwire Concentrator should always provide the same address and
prefix to a reconnecting user. However, if the goal of the Softwire
service is to provide a temporary address for a roaming user, it may
be provisioned to provide only a temporary address.
The address and prefix are expected to change when reconnecting to a
different Softwire Concentrator. However an organization providing a
Softwire service may provide the same address and prefix across
different Softwire Concentrators at the cost of a more fragmented
routing table. The routing fragmentation issue may be limited if the
prefixes are aggregated in a location topologically close to the SC.
This would be the case for example if several SCs are put in parallel
for load-balancing purpose.
8. Considerations about RADIUS Integration
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 RADIUS server may return additional informations in the
of attributes in the Access Accept message. form of attributes in the Access Accept message.
The Softwire Concentrator MAY include the Tunnel-Type 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 8.1. Softwires Endpoints
7.1.1. IPv6 Softwires 8.1.1. IPv6 Softwires
If the AAA server includes a Framed-Interface-Id attribute [RFC3162], If the RADIUS server includes a Framed-Interface-Id attribute
the Softwire Concentrator MUST send it to the Softwire Initiator in [RFC3162], the Softwire Concentrator must send it to the Softwire
the Interface Identifier field of its IPV6CP Configuration Request Initiator in the Interface Identifier field of its IPV6CP
message. Configuration Request message.
If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that If the Framed-IPv6-Prefix attribute is mentioned [RFC3162], that
prefix MUST be used in the router advertisements sent to the SI. If prefix MUST be used in the router advertisements sent to the SI. If
Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC
MUST choose a prefix with that pool to send router advertisements. must choose a prefix with that pool to send RAs.
If none of the attributes above are included but the AAA server If none of the attributes above are included but the AAA server
returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint
attributes [RFC2868] 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 8.1.2. IPv4 Softwires
If the Framed-IP-Address attribute [RFC2865] is present, the Softwire If the Framed-IP-Address attribute [RFC2865] is present, the Softwire
Concentrator MUST provide that address to the Softwire Initiator Concentrator must provide that address to the Softwire Initiator
during IPCP address negotiation. That is, when the Softwire during IPCP address negotiation. That is, when the Softwire
Initiator requests an IP address from the Softwire Concentrator, the Initiator requests an IP address from the Softwire Concentrator, the
address provided should be the Framed-IP-Address. address provided should be the Framed-IP-Address.
If the Framed-IP-Address attribute is not present and the Tunnel- If the Framed-IP-Address attribute is not present and the Tunnel-
Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are
present and of the correct address family, these SHOULD be used in present and of the correct address family, these should be used in
the IPCP IP-Address configuration option. the IPCP IP-Address configuration option.
7.2. Delegated Prefixes 8.2. Delegated Prefixes
7.2.1. IPv6 Prefixes 8.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix If the attribute Delegated-IPv6-Prefix
[I-D.ietf-radext-delegated-prefix] is present in the Radius Access [I-D.ietf-radext-delegated-prefix] is present in the RADIUS Access
Accept message, it must be used by the Softwire Concentrator for the Accept message, it must be used by the Softwire Concentrator for the
delegation of the IPv6 prefix. Since the prefix delegation is delegation of the IPv6 prefix. Since the prefix delegation is
performed by DHCPv6 and the attribute is linked to a username, the SC performed by DHCPv6 and the attribute is linked to a username, the SC
MUST associate the DUID of a DHCPv6 request to tunnel it came from must associate the DUID of a DHCPv6 request to tunnel it came from
and its user. and its user.
7.2.2. IPv4 Prefixes Interaction between RADIUS, PPP and DHCPv6 server may follow the
mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the
Softwire authentication phase, PPP collects the RADIUS attributes for
the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is
assigned to the Softwire and fill these attributes in RRAO (Relay
Agent RADIUS Attribute Option) into succeeding DHCPv6 requests from
the client before forwarding them to the DHCPv6 server.
8.2.2. IPv4 Prefixes
The combination of the Framed-IP-Address and Framed-IP-Netmask The combination of the Framed-IP-Address and Framed-IP-Netmask
attributes [RFC2865] MAY be used by the Softwire Concentrator to attributes [RFC2865] may be used by the Softwire Concentrator to
delegate an IPv4 prefix to the Softwire Initiator. delegate an IPv4 prefix to the Softwire Initiator.
8. Maintenance and Statistics - Best Current Practices 9. Considerations for Maintenance and Statistics
8.1. Radius Accounting 9.1. RADIUS Accounting
Radius Accounting for L2TPv2 is well documented (see Section 4.3). RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
Softwires implementers may use the existing RFCs as appropriate for
their business environment.
8.2. MIBs When deploying Softwires solutions, operators may experience
difficulties to differentiate the address family of the traffic
reported in accounting information from RADIUS. This problem and
some potential solutions are described in
[I-D.stevant-softwire-accounting].
MIB support for L2TPv2 is well documented (see Section 4.4). 9.2. MIBs
Softwires implementers may use the existing RFCs as appropriate for
their business environment. Also see [RFC4293]
9. Security Considerations MIB support for L2TPv2 and PPP are documented (see Section 4.4).
Also see [RFC4293]
The L2PTv2 softwires solution provides the following tools for 10. Security Considerations
A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements].
The L2TPv2 Softwires solution provides the following tools for
security: security:
o IPsec [RFC3193] provides the highest level of security. o IPsec [RFC3193] provides the highest level of security.
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.
A detailed discussion of softwires security is contained in 11. IANA Considerations
[I-D.ietf-softwire-security-requirements].
10. Implementation status
11. Open issues
11.1. Fragmentation and MTU
11.2. AAA Accounting (other draft)
12. IANA Considerations
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
13. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following contributors who The authors would like to acknowledge the following contributors who
provided helpful input on this document: Florent Parent, Jordi Palet provided helpful input on this document: Florent Parent, Jordi Palet
Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and
Francis Dupont, and Bruno Stevant. Francis Dupont.
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 ### Point to minutes of Barcelona meeting
14.1. Normative References
[I-D.ietf-dhc-subnet-alloc] 13. References
Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-03 (work in progress),
June 2005.
[I-D.ietf-radext-delegated-prefix] 13.1. Normative References
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-02 (work in
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.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[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.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[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.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[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.
skipping to change at page 34, line 25 skipping to change at page 34, line 5
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base", Tunneling Protocol "L2TP" Management Information Base",
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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[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.
14.2. Informative References [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
13.2. Informative References
[I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-04 (work in progress),
October 2006.
[I-D.ietf-dhc-v6-relay-radius]
Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
draft-ietf-dhc-v6-relay-radius-02 (work in progress),
February 2006.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-09 (work in progress),
October 2006.
[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-02 (work in progress), draft-ietf-ipv6-over-ppp-v2-02 (work in progress),
June 2005. June 2005.
[I-D.ietf-radext-delegated-prefix]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-05 (work in
progress), October 2006.
[I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and
Requirements",
draft-ietf-softwire-security-requirements-01 (work in
progress), October 2006.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-00 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
February 2006. October 2006.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996. Protocol (CHAP)", RFC 1994, August 1996.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[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.
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 -01 and -02:
o Renamed all "Best Current Practices" sections as
"Recommendations". See for example Section 1.4.
o Moved Provisioning in Section 6. Removed intro text to new
Section 7.
o Removed all normative language from Section 6, Section 7,
Section 8, and Section 9.
o Removed empty sections "Implementation Status", and "Open Issues".
o Fixed "Phase 0" in Section 1.
o Small changes to Section 3.1.
o Change L2TP -> L2TPv2 in some sections, including Section 6.
o Small additions and typo fixes in Section 5.1.1.1 and
Section 5.1.1.2.
o Retitled Section 8 and Section 8.1, changed AAA -> RADIUS.
o New paragraph in Section 9.1.
o New paragraph in Section 8.2.1, including a pointer to
[I-D.ietf-dhc-v6-relay-radius].
o Moved last paragraph to start of Section 10.
o Moved some references from Normative to Informative.
o Label the steps in Figure 9 and Figure 10.
o Reword paragraph of Section 5.1.
o Describe more messages than flows in Figure 11 and Figure 12.
o Add text about Session Establishment between Figure 11 and
Figure 12.
o Section 5.1.1.1 and Section 5.1.1.2: Updates on Hostname AVP,
Framing Capabilities AVP, Framing Type AVP, Connect Speed AVP and
Challenge and Challenge Response AVPs.
o Retitled Section 5.1.1.3.
o Updates on the use of L2TP HELLO versus LCP, delay for Dead-End
peer detection, and allow LCP.
o Rewording in Section 5.1.3.
o Section 5.2.1: Add a pointer to [RFC4623] and small updates.
o Clarifications on PFC and ACFC, remove Figure 13.
o Section 5.2.3: make references to RFCs for PAP, CHAP, etc.
o Rewordings in Section 5.2.4.1 and Section 5.2.4.2.
o Added Informative references to [RFC4623], [RFC1661], [RFC1662],
[RFC2433], and [RFC3748].
o Renamed the title and added more details on Section 5.3 and IPv6
ND, including a pointer to [I-D.ietf-ipv6-2461bis].
o Added text in Section 5.4 about IPv4 PD is non-trivial and non
commonly done.
o Added B. Stevant as Editor.
o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the
scope of the MUST (to the specific scenarios).
o Removed considerations about reverse DNS from Section 6, agreed on
Barcelona.
o Clarified the NAT case in Section 6.1.2
o Added first paragraph in Section 6.2.1 regarding delegated IPv6
prefixes.
o Added new Section 6.3, Section 6.3.1 and Section 6.3.2 summarizing
the scenarios for address allocation.
Changes between -00 and -01: Changes between -00 and -01:
o Changed alignment in all figures to be centered, and fixed o Changed alignment in all figures to be centered, and fixed
Figure 9 reference. Figure 9 reference.
o Section 1.4: Added new section with "Best Current Practices" o Section 1.4: Added new section with "Best Current Practices"
definition. definition.
o Marked the following sections as "Best Current Practices": o Marked the following sections as "Best Current Practices":
Section 5, Section 7, and Section 8. Section 6, Section 8, and Section 9.
o Section 5.1.1, last paragraph: Removed sentence on IPv6 link o Section 6.1.1, last paragraph: Removed sentence on IPv6 link
address on the PPP link. Mailing list comment from Florent address on the PPP link. Mailing list comment from Florent
Parent, 13-Jul-2006. Parent, 13-Jul-2006.
o Section 5.1.2, last paragraph: Changed IPv4 PPP link address to o Section 6.1.2, last paragraph: Changed IPv4 PPP link address to
use host addresses (/32) negotiated with IPCP instead of /30. use host addresses (/32) negotiated with IPCP instead of /30.
Mailing list comment from Bill Storer, 5-Jul-2006. Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 6, Figure 10: Correction, s/SCCSN/SCCCN/; added missing o Section 5, Figure 10: Correction, s/SCCSN/SCCCN/; added missing
ICRP, and changed direction of ICCN; typo correction s/IPV6P/ ICRP, and changed direction of ICCN; typo correction s/IPV6P/
IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006. IPV6CP/. Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 6, Figure 10: Marked CHAP as "Optional - CHAP". o Section 5, Figure 10: Marked CHAP as "Optional - CHAP".
o Section 6.1, Section 6.1.1, and Section 6.1.3: Minor typographical o Section 5.1, Section 5.1.1, and Section 5.1.3: Minor typographical
error correction and rewording of some sentences for grammar. error correction and rewording of some sentences for grammar.
o Section 6.1.1.1, Host Name AVP: Removed "for debugging purposes" o Section 5.1.1.1, Host Name AVP: Removed "for debugging purposes"
and added that MAY be used to authenticate users. and added that MAY be used to authenticate users.
o Section 6.1.1.1, Framing Capabilities AVP: Swapped SHOULD and o Section 5.1.1.1, Framing Capabilities AVP: Swapped SHOULD and
MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text MUST. Mailing list comment from Bill Storer, 5-Jul-2006, text
from Laurent Toutain. from Laurent Toutain.
o Section 6.1.1.1, (Tx) Connect Speed: Correction: "but is *not* o Section 5.1.1.1, (Tx) Connect Speed: Correction: "but is *not*
meaningful". meaningful".
o Section 6.1.1.2, Challenge and Challenge Response AVPs: Removed o Section 5.1.1.2, Challenge and Challenge Response AVPs: Removed
the last sentence of the first paragraph. Mailing list comment the last sentence of the first paragraph. Mailing list comment
from Bill Storer, 5-Jul-2006, text from Laurent Toutain. from Bill Storer, 5-Jul-2006, text from Laurent Toutain.
o Section 6.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and o Section 5.1.2: Rewrote paragraph to use L2TPv2 HELLO messages and
not LCP Echo Request and Reply messages to detect tunnel failure, not LCP Echo Request and Reply messages to detect tunnel failure,
as redundant in Softwires. Mailing list comment from Florent as redundant in Softwires. Mailing list comment from Florent
Parent, 10-Jul-2006, text from Bill Storer. Parent, 10-Jul-2006, text from Bill Storer.
o Section 6.2.1, first paragraph: Fixed PPP MTU calculation. o Section 5.2.1, first paragraph: Fixed PPP MTU calculation.
Mailing list comment from Florent Parent, 10-Jul-2006. Mailing list comment from Florent Parent, 10-Jul-2006.
o Section 6.2.2: Updated and augmented the text, and added o Section 5.2.4.2: Rewrote to generalize the address assignment
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 failure, to be an all-zeroes address or a protocol reject in
response to the IPCP CONFREQ. Mailing list comment from Bill response to the IPCP CONFREQ. Mailing list comment from Bill
Storer, 5-Jul-2006, text from JF Tremblay. Storer, 5-Jul-2006, text from JF Tremblay.
o Section 7, second paragraph: s/Tunnel-Medium /Tunnel-Type /. o Section 8, second paragraph: s/Tunnel-Medium /Tunnel-Type /.
Mailing list comment from Bill Storer, 5-Jul-2006. Mailing list comment from Bill Storer, 5-Jul-2006.
o Section 7.1.2: Added usage of Framed-IP-Address attribute, and if o Section 8.1.2: Added usage of Framed-IP-Address attribute, and if
not present then use the Tunnel-Client-Endpoint and Tunnel-Server- not present then use the Tunnel-Client-Endpoint and Tunnel-Server-
Endpoint attributes. Mailing list comment from Bill Storer, Endpoint attributes. Mailing list comment from Bill Storer,
5-Jul-2006, text from JF Tremblay and 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. o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10.
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
skipping to change at page 37, line 13 skipping to change at page 39, line 13
Email: bstorer@cisco.com Email: bstorer@cisco.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 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 (editor) 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
Jean-Francois Tremblay (editor) Jean-Francois Tremblay
Hexago Hexago
1470 Peel, suite 910 1470 Peel, suite 910
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) Bruno Stevant (editor)
GET/ENST Bretagne GET/ENST Bretagne
2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576
France
Email: Laurent.Toutain@enst-bretagne.fr Email: bruno.stevant@enst-bretagne.fr
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 176 change blocks. 
491 lines changed or deleted 601 lines changed or added

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