draft-ietf-softwire-hs-framework-l2tpv2-03.txt   draft-ietf-softwire-hs-framework-l2tpv2-04.txt 
Softwires Working Group B. Storer, Ed. Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: August 18, 2007 Cisco Systems Expires: December 10, 2007 Cisco Systems
J. Tremblay
Hexago
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
February 14, 2007 J. Tremblay
Trellia Networks
June 8, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-03 draft-ietf-softwire-hs-framework-l2tpv2-04
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 August 18, 2007. This Internet-Draft will expire on December 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the framework of the Softwire "Hub and Spoke" This document describes the framework of the Softwire "Hub and Spoke"
solution with Layer 2 Tunneling Protocol (L2TPv2), and the solution with Layer 2 Tunneling Protocol (L2TPv2), and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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. Considerations . . . . . . . . . . . . . . . . . . . . . . 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 Address Translation (NAT and NAPT) . . . . . . . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7 2.4. Authentication, Authorization and Accounting . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 10 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 10
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 14 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 15
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 15
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19 4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Authentication Authorization Accounting . . . . . . . . . 19 4.3. Authentication Authorization Accounting . . . . . . . . . 19
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 20
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 20
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 27
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 28
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 29
6. Considerations about the Address Provisioning Model . . . . . 30 6. Considerations about the Address Provisioning Model . . . . . 30
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31
skipping to change at page 4, line 8 skipping to change at page 4, line 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 40 13.1. Normative References . . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 43 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Introduction 1. Introduction
The Softwires Working Group has selected Layer Two Tunneling Protocol The Softwires Working Group has selected Layer Two Tunneling Protocol
version 2 (L2TPv2) as the phase 1 protocol to be deployed in the version 2 (L2TPv2) as the phase 1 protocol to be deployed in the
Softwires "Hubs and Spokes" solution space. This document describes Softwires "Hubs and Spokes" solution space. This document describes
the framework for the L2TPv2 "Hubs and Spokes" solution, and the the framework for the L2TPv2 "Hubs and Spokes" solution, and the
implementation details specified in this document should be followed implementation details specified in this document should be followed
to achieve interoperability among different vendor implementations. to achieve interoperability among different vendor implementations.
skipping to change at page 5, line 51 skipping to change at page 5, line 51
Control Channel establishment. After the L2TPv2 Control Channel is Control Channel establishment. After the L2TPv2 Control Channel is
established between the SI and SC, the SI initiates an L2TPv2 Session established between the SI and SC, the SI initiates an L2TPv2 Session
to the SC. Then the PPP/IP link is negotiated over the L2TPv2 to the SC. Then the PPP/IP link is negotiated over the L2TPv2
Session between the SI and SC. After the PPP/IP link is established, Session between the SI and SC. After the PPP/IP link is established,
it acts as the Softwire between the SI and SC for tunneling IP it acts as the Softwire between the SI and SC for tunneling IP
traffic of one Address Family across the access network of another traffic of one Address Family across the access network of another
Address Family. Address Family.
During the life of the Softwire, both SI and SC send L2TPv2 keepalive During the life of the Softwire, both SI and SC send L2TPv2 keepalive
HELLO messages to monitor the health of the Softwire and the peer HELLO messages to monitor the health of the Softwire and the peer
LCCE or to refresh the NAT/PAT translation entry at the CPE or at the LCCE, and to potentially refresh the NAT/NAPT translation entry at
other end of the access link. Optionally, LCP ECHO messages can be the CPE or at the other end of the access link. Optionally, LCP ECHO
used as keepalives for the same purposes. In the event of keepalive messages can be used as keepalives for the same purposes. In the
timeout or administrative shutdown of the Softwire, either SI or SC event of keepalive timeout or administrative shutdown of the
may tear down the Softwire by tearing down the L2TPv2 Control Channel Softwire, either SI or SC may tear down the Softwire by tearing down
and Session as specified in [RFC2661]. the L2TPv2 Control Channel and Session as specified in [RFC2661].
1.1. Abbreviations 1.1. Abbreviations
LCCE L2TP Control Connection Endpoint (See [RFC3931]) LCCE L2TP Control Connection Endpoint (See [RFC3931])
SC Softwire Concentrator, the node terminating the Softwire in SC Softwire Concentrator, the node terminating the Softwire in
the service provider network (See the service provider network (See
[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, the outermost IP header of a
[I-D.ietf-softwire-problem-statement]) softwire (See [I-D.ietf-softwire-problem-statement])
SPH Softwire Payload Header (See SPH Softwire Payload Header, the IP headers being carried within a
[I-D.ietf-softwire-problem-statement]) softwire (See [I-D.ietf-softwire-problem-statement])
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Contributing Authors 1.3. Contributing Authors
Following is the complete list of contributors to this document. Following is the complete list of contributors to this document.
Maria Alice Dos Santos Maria Alice Dos Santos
Carlos Pignataro Carlos Pignataro
Bill Storer Bill Storer
Cisco Systems Cisco Systems
Jean-Francois Tremblay Jean-Francois Tremblay
Hexago Trellia Networks
Laurent Toutain Laurent Toutain
Bruno Stevant Bruno Stevant
GET/ENST Bretagne GET/ENST Bretagne
1.4. Considerations 1.4. Considerations
Some sections of this document contain considerations that are not Some sections of this document contain considerations that are not
required for interoperability and correct operation of Softwire required for interoperability and correct operation of Softwire
implementations. These sections are marked as "Considerations". implementations. These sections are marked as "Considerations".
2. Applicability of L2TPv2 for Softwire Requirements 2. Applicability of L2TPv2 for Softwire Requirements
A list of Softwire "Hubs and Spokes" requirements have been A list of Softwire "Hubs and Spokes" requirements have been
identified by the Softwire Problem Statement identified by the Softwire Problem Statement
[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 Address Translation (NAT and NAPT)
A "Hubs and Spokes" Softwire must be able to traverse NAT/PAT in case A "Hubs and Spokes" Softwire must be able to traverse Network Address
the scenario in question involves a non-upgradable pre-existing IPv4 Translation and Network Address Port Translation (NAT and NAPT)
home gateway performing NAT/PAT or some carrier equipment at the devices [RFC3022] in case the scenario in question involves a non-
other end of the access link performing NAT/PAT. The L2TPv2 Softwire upgradable pre-existing IPv4 home gateway performing NAT/NAPT or some
(i.e. Control Channel and Session) is capable of NAT/PAT traversal carrier equipment at the other end of the access link performing NAT/
since L2TPv2 can run over UDP. NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is
capable of NAT/NAPT traversal since L2TPv2 can run over UDP.
Since L2TPv2 does not "autodetect" NAT/PAT along the path, L2TPv2 Since L2TPv2 does not "autodetect" NAT/NAPT along the path, L2TPv2
does not offer UDP bypass regardless of NAT/PAT presence. Both NAT/ does not offer UDP bypass regardless of NAT/NAPT presence. Both NAT/
PAT "autodetect" and UDP bypass are optional requirements. NAPT "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
Softwire concentrators). L2TPv2 is a widely deployed protocol in (i.e., Softwire concentrators). L2TPv2 is a widely deployed protocol
broadband services, and its scalability has been proven in multiple in broadband services, and its scalability has been proven in
large-scale IPv4 Virtual Private Network deployments which scale up multiple large-scale IPv4 Virtual Private Network deployments which
to millions of subscribers each. scale up 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
L2TPv2 supports optional mutual Control Channel authentication and L2TPv2 supports optional mutual Control Channel authentication and
leverages the optional mutual PPP per-session authentication. L2TPv2 leverages the optional mutual PPP per-session authentication. L2TPv2
skipping to change at page 8, line 25 skipping to change at page 8, line 25
be considered. be considered.
2.6. Operations and Management (OAM) 2.6. Operations and Management (OAM)
L2TPv2 supports an optional in-band keepalive mechanism which injects L2TPv2 supports an optional in-band keepalive mechanism which injects
HELLO control messages after a specified period of time has elapsed HELLO control messages after a specified period of time has elapsed
since the last data or control message was received on a tunnel. If since the last data or control message was received on a tunnel. If
the HELLO control message is not reliably delivered, then the Control the HELLO control message is not reliably delivered, then the Control
Channel and its session will be torn down. In the Softwire context, Channel and its session will be torn down. In the Softwire context,
the L2TPv2 keepalive is used to monitor the connectivity status the L2TPv2 keepalive is used to monitor the connectivity status
between the SI and SC and/or as a refresh mechanism for any NAT/PAT between the SI and SC and/or as a refresh mechanism for any NAT/NAPT
translation entry along the access link. translation entry along the access link.
LCP ECHO offers a similar mechanism to monitor the connectivity LCP ECHO offers a similar mechanism to monitor the connectivity
status, as described in [RFC1661]. Softwires implementations SHOULD status, as described in [RFC1661]. Softwires implementations SHOULD
use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo
messages to ensure Dead End Detection and/or to refresh NAT/PAT messages to ensure Dead End Detection and/or to refresh NAT/NAPT
translation entries. The combination of these two mechanisms can be translation entries. The combination of these two mechanisms can be
used as an optimization. used as an optimization.
L2TPv2 MIB [RFC3371] supports the complete suite of management L2TPv2 MIB [RFC3371] supports the complete suite of management
operations such as configuration of Control Channel and Session, operations such as configuration of Control Channel and Session,
polling of Control Channel and Session status and their traffic polling of Control Channel and Session status and their traffic
statistics and notifications of Control Channel and Session UP/DOWN statistics and notifications of Control Channel and Session UP/DOWN
events. events.
2.7. Encapsulations 2.7. Encapsulations
skipping to change at page 9, line 5 skipping to change at page 9, line 5
L2TPv2 supports the following encapsulations: L2TPv2 supports the following encapsulations:
o IPv6/PPP/L2TPv2/UDP/IPv4 o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv6 o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv4 o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6 o IPv6/PPP/L2TPv2/UDP/IPv6
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not
support "autodetect" of NAT/PAT. support "autodetect" of NAT/NAPT.
3. Deployment Scenarios 3. Deployment Scenarios
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 The following subsections cover IPv6 connectivity across an IPv4-only
access network using a Softwire. access network (STH) using a Softwire.
3.1.1. Host CPE as Softwire Initiator 3.1.1. Host CPE as Softwire Initiator
Softwire initiator is the host CPE (directly connected to a modem), The Softwire Initiator (SI) is the host CPE (directly connected to a
which is dual-stack. There is no other gateway device. The IPv4 modem), which is dual-stack. There is no other gateway device. The
traffic should not traverse the softwire. IPv4 traffic SHOULD NOT traverse the softwire. See Figure 1.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface Id to the
host CPE or perform uniqueness validation for the two Interface Ids
at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the host CPE via Router Advertisement (RA)
while other configuration options (such as DNS) can be conveyed to
the host CPE via DHCPv6/v4.
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 (SPH)
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 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
to the host CPE or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the host CPE via Router
Advertisement (RA) while other configuration options (such as DNS)
can be conveyed to the host CPE via DHCPv6/v4.
Softwire initiator is the router CPE, which is a dual-stack device. 3.1.2. Router CPE as Softwire Initiator
The IPv4 traffic should not traverse the Softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides The Softwire Initiator (SI) is the router CPE, which is a dual-stack
the capability for the ISP to assign the 64-bit Interface Id to the device. The IPv4 traffic SHOULD NOT traverse the Softwire. See
router CPE or perform uniqueness validation for the two Interface Ids Figure 2.
at the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the router CPE via Router Advertisement (RA).
DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g. delegating
a 48-bit prefix to be used within the home network) and convey other
configuration options (such as DNS) to the router CPE.
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 (SPH)
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 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
to the router CPE or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the router CPE via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (e.g., delegating a 48-bit prefix to be used within the
home network) and convey other configuration options (such as DNS) to
the router CPE.
The CPE is IPv4-only. Softwire initiator is a dual-stack host 3.1.3. Host behind CPE as Softwire Initiator
(behind IPv4- only CPE), which acts as an IPv6 host CPE. The IPv4
traffic should not traverse the Softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
the capability for the ISP to assign the 64-bit Interface Id to the host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The
host or perform uniqueness validation for the two Interface Ids at IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
the two PPP ends [RFC2472]. After IPv6 over PPP is up, Neighbor
Discovery runs over the IPv6 over PPP link, and the LNS can assign a
64-bit global prefix to the host via Router Advertisement (RA) while
other configuration options (such as DNS) can be conveyed to the host
via DHCPv6/v4.
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 (SPH)
<------------------------------> <------------------------------>
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 In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
to the host or perform uniqueness validation for the two Interface-
IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is up,
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
assign a 64-bit global prefix to the host via Router Advertisement
(RA) while other configuration options (such as DNS) can be conveyed
to the host via DHCPv6/v4.
The CPE is IPv4-only. Softwire initiator is a dual-stack device 3.1.4. Router behind CPE as Softwire Initiator
(behind the IPv4-only CPE) acting as an IPv6 CPE router inside the
home network. The IPv4 traffic should not traverse the Softwire.
In this scenario, IPv6CP negotiates IPv6 over PPP which also provides The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
the capability for the ISP to assign the 64-bit Interface Id to the device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside
v4/v6 router or perform uniqueness validation for the two Interface the home network. The IPv4 traffic SHOULD NOT traverse the Softwire.
Ids at the two PPP ends [RFC2472]. After IPv6 over PPP is up, See Figure 4.
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
assign a 64-bit global prefix to the v4/v6 router via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (for example, delegating a 48-bit prefix to be used within
the home network) and convey other configuration options (such as
DNS) to the v4/v6 router.
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
PPP o L2TPv2 o UDP o IPv4 PPP o L2TPv2 o UDP o IPv4 traffic
Softwire Softwire (SPH)
<---------------------------> <--------------------------->
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
In this scenario, IPV6CP negotiates IPv6 over PPP which also provides
the capability for the ISP to assign the 64-bit Interface-Identifier
to the v4/v6 router or perform uniqueness validation for the two
Interface-IDs at the two PPP ends [RFC2472]. After IPv6 over PPP is
up, Neighbor Discovery runs over the IPv6 over PPP link, and the LNS
can assign a 64-bit global prefix to the v4/v6 router via Router
Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix
Delegation (e.g., delegating a 48-bit prefix to be used within the
home network) and convey other configuration options (such as DNS) to
the v4/v6 router.
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 The following subsections cover IPv4 connectivity across an IPv6-only
access network using a Softwire. access network (STH) using a Softwire.
3.2.1. Host CPE as Softwire Initiator 3.2.1. Host CPE as Softwire Initiator
Softwire initiator is the host CPE (directly connected to a modem), The Softwire Initiator (SI) is the host CPE (directly connected to a
which is dual-stack. There is no other gateway device. The IPv6 modem), which is dual-stack. There is no other gateway device. The
traffic should not traverse the Softwire. IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
host CPE. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
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 (SPH)
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
IPv4 connectivity across an IPv6-only access network (STH). Softwire
initiator is the router CPE, which is a dual-stack device. The IPv6
traffic should not traverse the Softwire.
In this scenario, IPCP negotiates IPv4 over PPP which also provides 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. host CPE. A global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the Other configuration options (such as DNS) can be conveyed to the host
router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation CPE via IPCP [RFC1877] or DHCP.
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
3.2.2. Router CPE as Softwire Initiator
IPv4 connectivity across an IPv6-only access network (STH). The
Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv6 traffic SHOULD NOT traverse the Softwire. See
Figure 6.
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 (SPH)
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
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
router CPE. A global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the
router CPE via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
3.2.3. Host behind CPE as Softwire Initiator 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. The Softwire Initiator (SI) is a dual-stack host
IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic should (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6
not traverse the Softwire. traffic SHOULD NOT traverse the Softwire. See Figure 7.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
host. Global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP.
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 (SPH)
<------------------------------> <------------------------------>
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
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
host. A global IPv4 address can also be assigned via DHCP. Other
configuration options (such as DNS) can be conveyed to the host CPE
via IPCP [RFC1877] or DHCP.
3.2.4. Router behind CPE as Softwire Initiator 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. The Softwire Initiator (SI) is a dual-stack device
IPv6-only CPE) acting as an IPv4 CPE router inside the home network. (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the
The IPv6 traffic should not traverse the Softwire. home network. The IPv6 traffic SHOULD NOT traverse the Softwire.
See Figure 8.
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 IP address to the
v4/v6 router. Global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the
v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
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 (SPH)
<---------------------------> <--------------------------->
IPCP: assigns global IP address and DNS, etc. IPCP: assigns global IP address and DNS, etc.
|---------------------------> |--------------------------->
DHCPv4: prefix, mask, PD DHCPv4: prefix, mask, PD
private/ private/
|----> global |----> global
DHCP IP, DNS, DHCP IP, DNS,
etc. etc.
Figure 8: Router behind CPE as Softwire Initiator Figure 8: Router behind CPE as Softwire Initiator
In this scenario, IPCP negotiates IPv4 over PPP which also provides
the capability for the ISP to assign a global IPv4 address to the
v4/v6 router. A global IPv4 address can also be assigned via DHCP.
Other configuration options (such as DNS) can be conveyed to the
v4/v6 router via IPCP [RFC1877] or DHCP. For IPv4 Prefix Delegation
for the home network, DHCP [I-D.ietf-dhc-subnet-alloc] can be used.
4. Standardisation Status 4. Standardisation Status
This section groups various Internet standards documents and other
publications used in Softwires.
4.1. Softwire Transport Related 4.1. Softwire Transport Related
RFC 3193 Securing L2TP using IPsec. RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3948 UDP Encapsulation of IPsec ESP Packets. RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
IPSec supports both IPv4 and IPv6 transports.
* IPSec supports both IPv4 and IPv6 transports.
4.2. L2TPv2 4.2. L2TPv2
RFC 2661 Layer Two Tunneling Protocol "L2TP". RFC 2661 "Layer Two Tunneling Protocol "L2TP"" [RFC2661].
For both IPv4 and IPv6 payloads, support is complete.
For both IPv4 and IPv6 transport, support is complete. * For both IPv4 and IPv6 payloads (SPH), support is
complete.
* For both IPv4 and IPv6 transports (STH), support is
complete.
4.3. Authentication Authorization Accounting 4.3. Authentication Authorization Accounting
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol RFC 2865 "Remote Authentication Dial In User Service (RADIUS)"
Support. [RFC2865].
RFC 2865 Remote Authentication Dial In User Service (RADIUS). RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol
Support" [RFC2867].
RFC 3162 RADIUS and IPv6. RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 3162 "RADIUS and IPv6" [RFC3162].
4.4. MIB 4.4. MIB
RFC 3371 Layer Two Tunneling Protocol "L2TP" Management Information RFC 1471 "The Definitions of Managed Objects for the Link Control
Base. Protocol of the Point-to-Point Protocol" [RFC1471].
RFC 4087 IP Tunnel MIB. RFC 1473 "The Definitions of Managed Objects for the IP Network
Both IPv4 and IPv6 transport is supported. Control Protocol of the Point-to-Point Protocol"
[RFC1473].
RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management
Information Base" [RFC3371].
RFC 4087 "IP Tunnel MIB" [RFC4087].
* Both IPv4 and IPv6 transports are supported.
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 2461 "Neighbor Discovery for IP Version 6 (IPv6)" [RFC2461].
RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). RFC 2472 "IP Version 6 over PPP" [RFC2472].
RFC 3646 DNS Configuration options for Dynamic Host Configuration * See also [I-D.ietf-ipv6-over-ppp-v2].
Protocol for IPv6 (DHCPv6).
RFC 2461 Neighbor Discovery for IP Version 6 (IPv6). RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
[RFC3315].
RFC 3646 "DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)" [RFC3646].
4.5.2. For IPv4 Payloads 4.5.2. For IPv4 Payloads
RFC 1661 The Point-to-Point Protocol (PPP). RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)"
[RFC1332].
RFC 1332 The PPP Internet Protocol Control Protocol (IPCP). RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
DHCP Subnet Allocation RFC 1877 "PPP Internet Protocol Control Protocol Extensions for
Work in progress [I-D.ietf-dhc-subnet-alloc]. Name Server Addresses" [RFC1877].
DHCP Subnet Allocation "Subnet Allocation Option".
* Work in progress, see [I-D.ietf-dhc-subnet-alloc].
5. Softwire Establishment 5. Softwire Establishment
A Softwire is established in 3 distinct steps (Figure 9). First a A Softwire is established in three distinct steps (see Figure 9).
L2TPv2 tunnel with a single session is established from the SI to the First an L2TPv2 tunnel with a single session is established from the
SC. Second a PPP session is established over the L2TPv2 session and SI to the SC. Second a PPP session is established over the L2TPv2
the SI obtains an address. Third the SI optionally gets other session and the SI obtains an address. Third the SI optionally gets
information through DHCP such as a delegated prefix and DNS servers. other information through DHCP such as a delegated prefix and DNS
servers.
SC SI SC SI
| | | |
|<-------------L2TPv2------------>| Step 1 |<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment | | L2TPv2 Tunnel establishment
| | | |
|<-------------PPP--------------->| Step 2 |<-------------PPP--------------->| Step 2
|<----End Point Configuration---->| PPP and End Point |<----End Point Configuration---->| PPP and End Point
| | configuration | | configuration
| | | |
|<------Router Configuration----->| Step 3 |<------Router Configuration----->| Step 3
| | Additional configuration | | 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 In the following diagram (see Figure 10), each of the three steps
required to establish a Softwire is described in detail. required to establish a Softwire is described in detail.
SC SI SC SI
| | | |
| | Step 1 | | Step 1
|<------------SCCRQ---------------| - |<------------SCCRQ---------------| -
|-------------SCCRP-------------->| | |-------------SCCRP-------------->| |
|<------------SCCCN---------------| | |<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2 |<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| | |-------------ICRP--------------->| |
skipping to change at page 23, line 10 skipping to change at page 23, line 10
L2TPv2 tunnel and the private network. L2TPv2 tunnel and the private network.
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI)
assumes the role of the LAC and the Softwire Concentrator assumes the assumes the role of the LAC and the Softwire Concentrator assumes the
role of the LNS. role of the LNS.
In the Softwire model, an L2TPv2 packet MUST be carried over UDP. 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 Softwires scenario. depending on the Softwires scenario.
In the following sections, the term "Tunnel" follows the definition
from [RFC2661], namely: "The Tunnel consists of a Control Connection
and zero or more L2TP Sessions".
5.1.1. Tunnel Establishment 5.1.1. Tunnel Establishment
The following diagram, (Figure 11), describes messages exchanged and Figure 11 describes the messages exchanged and AVPs used to establish
AVPs used to establish a tunnel between an SI (LAC) and an SC (LNS). a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs
The messages and AVPs described here are only a subset of those described here are only a subset of those defined in [RFC2661]. This
defined in [RFC2661]. This is because Softwires uses only a subset is because Softwires uses only a subset of the L2TPv2 functionality.
of the L2TPv2 functionality. One session per tunnel is needed. Note The subset of L2TP Control Connection Management AVPs that is
that in the Softwires environment, the SI always initiates the applicable to Softwires is grouped into Mandatory AVPs and Optional
tunnel. No outgoing or analog calls are permitted. L2TPv2 AVPs (see Figure 11). Note that in the Softwires environment, the SI
attributes SHOULD NOT be hidden. always initiates the tunnel. L2TPv2 attributes SHOULD NOT be hidden.
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) Optional AVP:
Challenge Response
Figure 11: Tunnel Establishment Figure 11: Control Connection Establishment
In L2TPv2, the tunnel between a LAC and LNS may carry the data of In L2TPv2, the tunnel between an LAC and LNS may carry the data of
multiple users. Each of these user's is represented by an L2TPv2 multiple users. Each of these user's is represented by an L2TPv2
session within the tunnel. In the Softwires environment, the tunnel session within the tunnel. In the Softwires environment, the tunnel
carries the information of a single user. So, there is only one carries the information of a single user. So, there is only one
L2TPv2 session per tunnel. The following diagram, (Figure 12), L2TPv2 session per tunnel. Figure 12 describes the messages
describes messages exchanged and AVPs used to establish a session exchanged and the AVPs used to establish a session between an SI
between an SI (LAC) and an SC (LNS). The messages and AVPs described (LAC) and an SC (LNS). The messages and AVPs described here are only
here are only a subset of those defined in [RFC2661]. This is a subset of those defined in [RFC2661]. This is because Softwires
because Softwires uses only a subset of the L2TPv2 functionality. uses only a subset of the L2TPv2 functionality. The subset of L2TP
Note that in the Softwires environment, the SI always initiates the Call Management AVPs that is applicable to Softwires is grouped into
session. No outgoing or analog calls are permitted. L2TPv2 Mandatory AVPs and Optional AVPs (see Figure 12). Note that in the
attributes SHOULD NOT be hidden. Softwires environment, the SI always initiates the session. No
outgoing or analog calls are permitted. L2TPv2 attributes SHOULD NOT
be hidden.
ICRQ ICRQ
Mandatory AVP: Mandatory AVP:
Message Type Message Type
Assigned Session ID Assigned Session ID
Call Serial Number Call Serial Number
ICRP ICRP
Mandatory AVP: Mandatory AVP:
Message Type Message Type
skipping to change at page 25, line 26 skipping to change at page 25, line 27
ICCN ICCN
Mandatory AVP: Mandatory AVP:
Message Type Message Type
(Tx) Connect Speed (Tx) Connect Speed
Framing Type Framing Type
Figure 12: Session Establishment Figure 12: Session Establishment
5.1.1.1. AVPs Required for Softwires 5.1.1.1. AVPs Required for Softwires
This paragraph specifies specific values for AVPs used in the This section prescribes specific values for AVPs used in the
Softwires context. Softwires context that are Mandatory.
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, in which case it would This AVP may be used to authenticate users, in which case it would
contain a user identification. If this AVP is not used to contain a user identification. If this AVP is not used to
authenticate users, it may be used for documention. authenticate users, it may be used for documentation.
Framing Capabilities AVP Framing Capabilities AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 1.
This AVP SHOULD be ignored by the receiver. This AVP SHOULD be ignored by the receiver.
Framing Type AVP Framing Type AVP
Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0. Synchronous bit SHOULD be set to 1 and Asynchronous bit to 0.
This AVP SHOULD be ignored by the receiver. 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 the (Tx) Connect Speed is a mandatory AVP but is not meaningful in the
Softwires context. It SHOULD be left to 0 and ignored by the Softwires context. It SHOULD be left to 0 and ignored by the
receiver. receiver.
Assigned Tunnel ID, Receive Window Size, Firmware Revision, Vendor Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call
Name, Call Serial Number, and Assigned Session ID Serial Number AVP, and Assigned Session ID AVP
As defined in [RFC2661] As defined in [RFC2661]
5.1.1.2. AVPs Optional for Softwires 5.1.1.2. AVPs Optional for Softwires
Challenge and Challenge Response AVPs This section prescribes specific values for AVPs used in the
Softwires context that are Optional.
Challenge AVP and Challenge Response AVP
These AVPs are not required, but are necessary to implement tunnel These AVPs are not required, but are necessary to implement tunnel
authentication. Since tunnel authentication happens at the authentication. Since tunnel authentication happens at the
beginning of L2TPv2 tunnel creation, it can be helpful in beginning of L2TPv2 tunnel creation, it can be helpful in
preventing DoS attacks. preventing DoS attacks.
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP
As defined in [RFC2661]
5.1.1.3. AVPs not Relevant for Softwires 5.1.1.3. AVPs not Relevant for Softwires
L2TPv2 specifies numerous AVPs that, while allowed for a given L2TPv2 specifies numerous AVPs that, while allowed for a given
command, are irrelevant to a Softwires. Softwires implementations command, are irrelevant to a Softwires. Softwires implementations
should not send these AVPs. However, they should ignore them when SHOULD NOT send these AVPs. However, they SHOULD ignore them when
they are received. This will make it easier to create Softwires they are received. This will make it easier to create Softwires
applications on top of existing L2TPv2 implementations. applications on top of existing L2TPv2 implementations.
5.1.2. Tunnel Maintenance 5.1.2. Tunnel Maintenance
Periodically, the SI MUST transmit a message to the SC to maintain Periodically, the SI MUST transmit a message to the SC to maintain
NAT/PAT contexts and detect tunnel failure. The L2TPv2 HELLO message NAT/NAPT contexts and detect tunnel failure. The L2TPv2 HELLO
provides a simple, low overhead method of doing this. message provides a simple, low overhead method of doing this.
The default values specified in [RFC2661] for L2TPv2 HELLO messages The default values specified in [RFC2661] for L2TPv2 HELLO messages
could result in a dead end detection time of 83 seconds. Although could result in a dead end detection time of 83 seconds. Although
these retransmission timers and counters SHOULD be configurable (see these retransmission timers and counters SHOULD be configurable (see
[RFC2661]), these values may not be adapted for all situations, where [RFC2661]), these values may not be adapted for all situations, where
a quicker dead end detection is required, or where NAT/PAT context a quicker dead end detection is required, or where NAT/NAPT context
needs to be refreshed more frequently. In such cases, the SI MAY needs to be refreshed more frequently. In such cases, the SI MAY
use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo- use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo-
Request and Echo-Reply codes) described in [RFC1661] which timeout Request and Echo-Reply codes) described in [RFC1661] which timeout
could be configured to a lower value. When used, LCP ECHO messages could be configured to a lower value. When used, LCP ECHO messages
SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO
hello messages. hello messages.
5.1.3. Tunnel Teardown 5.1.3. Tunnel Teardown
Either the SI or SC can teardown the session and tunnel. This is Either the SI or SC can teardown the session and tunnel. This is
done as specified in [RFC2661]. There is no action specific to done as specified in [RFC2661]. There is no action specific to
Softwires in this case. Softwires in this case.
5.2. PPP Connection 5.2. PPP Connection
5.2.1. MTU 5.2.1. MTU
The MTU of the PPP link SHOULD be the link MTU minus the size of the The MTU of the PPP link SHOULD be the link MTU minus the size of the
IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an
MTU equal to 1500 bytes, this would usually mean a PPP MTU of 1460 MTU equal to 1500 bytes, this could tipically mean a PPP MTU of 1460
bytes. This may vary according to the size of the L2TP header. See bytes. This may vary according to the size of the L2TP header, as
[RFC4623] for a detailed discussion of fragmentation issues. defined by the leading bits of the L2TP message header (see
[RFC2661]). Additionally, see [RFC4623] for a detailed discussion of
fragmentation issues.
5.2.2. LCP 5.2.2. LCP
Once the L2TPv2 session is established, the SI and SC initiate the Once the L2TPv2 session is established, the SI and SC initiate the
PPP connection by negotiating LCP as described in [RFC1661]. ACFC PPP connection by negotiating LCP as described in [RFC1661]. The
[RFC1662] SHOULD be rejected. Address-and-Control-Field-Compression configuration option (ACFC)
[RFC1661] SHOULD be rejected.
5.2.3. Authentication 5.2.3. Authentication
After completing LCP negotiation, the SI and SC may optionally After completing LCP negotiation, the SI and SC may optionally
perform authentication. If authentication is chosen, CHAP [RFC1994] perform authentication. If authentication is chosen, CHAP [RFC1994]
authentication MUST be supported by both the Softwire Initiator and authentication MUST be supported by both the Softwire Initiator and
Softwire Concentrator. Other authentication methods such as MS- Softwire Concentrator. Other authentication methods such as MS-
CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported. CHAPv1 [RFC2433], and EAP [RFC3748] MAY be supported.
A detailed discussion of Softwires security is contained in A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements] [I-D.ietf-softwire-security-requirements].
5.2.4. IPCP 5.2.4. IPCP
5.2.4.1. IPv6CP 5.2.4.1. IPV6CP
In the IPv6 over IPv4 scenarios (see Section 3.1), after the In the IPv6 over IPv4 scenarios (see Section 3.1), after the
authentication phase, the Softwire Initiator MUST negotiate IPv6CP as authentication phase, the Softwire Initiator MUST negotiate IPV6CP as
defined in [RFC2472]. IPv6CP provides a way to negotiate a unique defined in [RFC2472]. IPV6CP provides a way to negotiate a unique
64-bit interface identifier to be used for the address 64-bit Interface-Identifier to be used for the address
autoconfiguration at the local end of the link. autoconfiguration at the local end of the link.
5.2.4.2. IPv4CP 5.2.4.2. IPv4CP
In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire In the IPv4 over IPv6 scenarios (see Section 3.2), a Softwire
Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain 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 an IPv4 address from the SC. IPCP may also be used to obtain DNS
information as described in [RFC1877]. information as described in [RFC1877].
5.3. Global IPv6 Address Assignement to Endpoints 5.3. Global IPv6 Address Assignement to Endpoints
In several scenario defined in Section 3, Global IPv6 addresses are In several scenarios defined in Section 3, Global IPv6 addresses are
expected to be allocated to Softwires end points. Since IPv6CP only expected to be allocated to Softwires end points. Since IPV6CP only
provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery provide Link-Local addresses (see [RFC2472]), IPv6 Neighbor Discovery
[RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these [RFC2462] or DHCPv6 [RFC3315] SHOULD be used to configure these
addresses. addresses.
The Softwire Initiator of an IPv6 Softwire MUST send a Router The Softwire Initiator of an IPv6 Softwire MUST send a Router
Solicitation 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. This message MUST contains the global IPv6 prefix of Advertisement. This message MUST contains the global IPv6 prefix of
the PPP link if Neighbor discovery is used to configure addresses of the PPP link if Neighbor discovery is used to configure addresses of
Softwire end points. Softwire end points.
skipping to change at page 28, line 36 skipping to change at page 28, line 48
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.
When delegating an IPv4 prefix to the SI, the SC SHOULD inject a 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 route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire. the traffic to the relevant Softwire.
5.4.1. DHCPv6 5.4.1. DHCPv6
IF a SI establishing an IPv6 Softwire acts as a router (scenarios If an SI establishing an IPv6 Softwire acts as a router (i.e., in the
3.1.2 and 3.1.4) it MUST include the IA_PD option [RFC3633] in the scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the
DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix. IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in
order to request an IPv6 prefix.
When delegating an IPv6 prefix to the SI, the SC SHOULD inject a 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 route for this prefix in the IPv4 routing table in order to forward
the traffic to the relevant Softwire. the traffic to the relevant Softwire.
5.4.2. DHCPv4 5.4.2. DHCPv4
A SI establishing an IPv4 Softwire MAY send a DHCP request containing An SI establishing an IPv4 Softwire MAY send a DHCP request
the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc]. This containing the Subnet Allocation option [I-D.ietf-dhc-subnet-alloc].
practice is not common but may be used to connect IPv4 subnets using This practice is not common but may be used to connect IPv4 subnets
Softwires, as defined in Section 3.2.2 and Section 3.2.4. 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 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. 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 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'.
6. Considerations about the Address Provisioning Model 6. Considerations about the Address Provisioning Model
This section describes how a Softwire Concentrator may manage This section describes how a Softwire Concentrator may manage
skipping to change at page 30, line 33 skipping to change at page 30, line 33
Global or ULA addresses must be assigned to endpoints when the Global or ULA addresses must be assigned to endpoints when the
scenario "Host CPE as Softwire Initiator" (described in scenario "Host CPE as Softwire Initiator" (described in
Section 3.1.1) is considered to be deployed. For other scenarios, Section 3.1.1) is considered to be deployed. For other scenarios,
this may be optional and link local addresses should be used. this may be optional and link local addresses should be used.
6.1.2. IPv4 6.1.2. IPv4
A Softwire Concentrator may provide either globally routable or A Softwire Concentrator may provide either globally routable or
private IPv4 addresses. When using IPv4 private addresses [RFC1918] private IPv4 addresses. When using IPv4 private addresses [RFC1918]
on the endpoints, it is not not recommended to delegate an IPv4 on the endpoints, it is not recommended to delegate an IPv4 private
private prefix to the SI, as it can lead to a nested-NAT situations. 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), The endpoints of the PPP link use host addresses (i.e., /32),
negotiated using IPCP. negotiated using IPCP.
6.2. Delegated Prefixes 6.2. Delegated Prefixes
6.2.1. IPv6 Prefixes 6.2.1. IPv6 Prefixes
Delegated IPv6 should be of global scope if assigned IPv6 addresses Delegated IPv6 should be of global scope if the IPv6 addresses
for endpoints are global. Using ULA addresses is not recommended assigned to endpoints are global. Using ULA addresses is not
when subnet is connected to the global IPv6 Internet. When using ULA recommended when the subnet is connected to the global IPv6 Internet.
IPv6 address for endpoint, Delegated IPv6 prefix may be either of When using ULA IPv6 address for endpoint, the delegated IPv6 prefix
Global or ULA scope. may be either of Global or ULA scope.
Delegated IPv6 prefixes are between /48 and /64 in length. When a SI Delegated IPv6 prefixes are between /48 and /64 in length. When an
receives a prefix shorter than 64, it can assign different /64 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 prefixes to each of its interfaces. An SI receiving a single /64 is
expected to perform bridging if more than one interface are available expected to perform bridging if more than one interface are available
(wired and wireless for example). (wired and wireless for example).
6.2.2. IPv4 Prefixes 6.2.2. IPv4 Prefixes
Delegated IPv4 prefixes should be of the same scope than the assigned Delegated IPv4 prefixes should be routable within the address space
IPv4 addresses and be routable within that address space. Prefix used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes
length is between /8 and /30. (i.e. private IPv4 prefix over public IPv4 addresses or another class
of private IPv4 addresses) is not recommended as a practice for
provisioning and address translation should be considered in these
cases. The prefix length is between /8 and /30.
6.3. Possible scenarios 6.3. Possible scenarios
This section summarizes the differents scenarios for address This section summarizes the differents scenarios for address
provisioning with the considerations given in the previous sections. provisioning with the considerations given in the previous sections.
6.3.1. Scenarios for IPv6 6.3.1. Scenarios for IPv6
This table describes the possible combination of IPv6 address scope This table describes the possible combination of IPv6 address scope
for endpoints and delegated prefixes. for endpoints and delegated prefixes.
skipping to change at page 31, line 38 skipping to change at page 31, line 41
| ULA | Possible | Possible | | ULA | Possible | Possible |
| | | | | | | |
| Global | Possible | Possible, but Not | | Global | Possible | Possible, but Not |
| | | Recommended | | | | Recommended |
+------------------+-----------------------+------------------------+ +------------------+-----------------------+------------------------+
Table 1: Scenarios for IPv6 Table 1: Scenarios for IPv6
6.3.2. Scenarios for IPv4 6.3.2. Scenarios for IPv4
This table describes the possible combination of IPv6 address scope This table describes the possible combination of IPv4 address scope
for endpoints and delegated prefixes. for endpoints and delegated prefixes.
+------------------+-----------------------+------------------------+ +-------------+-----------------+-----------------------------------+
| Endpoint IPv4 | Delegated Public IPv4 | Delegated Private IPv4 | | Endpoint | Delegated | Delegated Private IPv4 Prefix |
| Address | Prefix | Prefix | | IPv4 | Public IPv4 | |
+------------------+-----------------------+------------------------+ | Address | Prefix | |
| Private IPv4 | Possible | Possible, but Not | +-------------+-----------------+-----------------------------------+
| | | Recommended | | Private | Possible | Possible, but Not Recommended |
| IPv4 | | when using NAT (cf. |
| | | Section 6.1.2) |
| | | | | | | |
| Public IPv4 | Possible | Possible | | Public IPv4 | Possible | Possible, but NAT usage is |
+------------------+-----------------------+------------------------+ | | | recommended (cf. Section 6.2.2) |
+-------------+-----------------+-----------------------------------+
Table 2: Scenarios for IPv4 Table 2: Scenarios for IPv4
7. Considerations about Address Stability 7. Considerations about Address Stability
A Softwire can provide stable addresses even if the underlying A Softwire can provide stable addresses even if the underlying
addressing scheme changes, by opposition to automatic tunneling. A addressing scheme changes, by opposition to automatic tunneling. A
Softwire Concentrator should always provide the same address and Softwire Concentrator should always provide the same address and
prefix to a reconnecting user. However, if the goal of the Softwire prefix to a reconnecting user. However, if the goal of the Softwire
service is to provide a temporary address for a roaming user, it may service is to provide a temporary address for a roaming user, it may
skipping to change at page 34, line 22 skipping to change at page 34, line 22
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.
8.1. Softwires Endpoints 8.1. Softwires Endpoints
8.1.1. IPv6 Softwires 8.1.1. IPv6 Softwires
If the RADIUS server includes a Framed-Interface-Id attribute If the RADIUS server includes a Framed-Interface-Id attribute
[RFC3162], the Softwire Concentrator must send it to the Softwire [RFC3162], the Softwire Concentrator must send it to the Softwire
Initiator in the Interface Identifier field of its IPV6CP Initiator in the Interface-Identifier field of its IPV6CP
Configuration Request 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 RAs. 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] with the correct address family, these must be
these must be used in the IPV6CP Interface Identifier and for the used in the IPV6CP Interface-Identifier and for the router
router advertisements. advertisements.
8.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.
8.2. Delegated Prefixes 8.2. Delegated Prefixes
8.2.1. IPv6 Prefixes 8.2.1. IPv6 Prefixes
If the attribute Delegated-IPv6-Prefix If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the
[I-D.ietf-radext-delegated-prefix] is present in the RADIUS Access RADIUS Access Accept message, it must be used by the Softwire
Accept message, it must be used by the Softwire Concentrator for the Concentrator for the delegation of the IPv6 prefix. Since the prefix
delegation of the IPv6 prefix. Since the prefix delegation is delegation is performed by DHCPv6 and the attribute is linked to a
performed by DHCPv6 and the attribute is linked to a username, the SC username, the SC must associate the DHCP Unique Identifier (DUID) of
must associate the DUID of a DHCPv6 request to tunnel it came from a DHCPv6 request to the tunnel it came from and its user.
and its user.
Interaction between RADIUS, PPP and DHCPv6 server may follow the Interaction between RADIUS, PPP and DHCPv6 server may follow the
mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. During the
Softwire authentication phase, PPP collects the RADIUS attributes for Softwire authentication phase, PPP collects the RADIUS attributes for
the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is
assigned to the Softwire and fill these attributes in RRAO (Relay assigned to the Softwire. The DHCPv6 relay fills in these attributes
Agent RADIUS Attribute Option) into succeeding DHCPv6 requests from in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option,
the client before forwarding them to the DHCPv6 server. before forwarding the DHCPv6 requests to the DHCPv6 server.
8.2.2. IPv4 Prefixes 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.
9. Considerations for Maintenance and Statistics 9. Considerations for Maintenance and Statistics
9.1. RADIUS Accounting 9.1. RADIUS Accounting
skipping to change at page 36, line 20 skipping to change at page 36, line 20
When deploying Softwires solutions, operators may experience When deploying Softwires solutions, operators may experience
difficulties to differentiate the address family of the traffic difficulties to differentiate the address family of the traffic
reported in accounting information from RADIUS. This problem and reported in accounting information from RADIUS. This problem and
some potential solutions are described in some potential solutions are described in
[I-D.stevant-softwire-accounting]. [I-D.stevant-softwire-accounting].
9.2. MIBs 9.2. MIBs
MIB support for L2TPv2 and PPP are documented (see Section 4.4). MIB support for L2TPv2 and PPP are documented (see Section 4.4).
Also see [RFC4293] Also see [RFC4293].
10. Security Considerations 10. Security Considerations
A detailed discussion of Softwires security is contained in A detailed discussion of Softwires security is contained in
[I-D.ietf-softwire-security-requirements]. [I-D.ietf-softwire-security-requirements].
The L2TPv2 Softwires solution provides the following tools for The L2TPv2 Softwires solution provides the following tools for
security: security:
o IPsec [RFC3193] provides the highest level of security. o IPsec [RFC3193] provides the highest level of security.
skipping to change at page 39, line 13 skipping to change at page 39, line 13
[RFC2434]. [RFC2434].
12. 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, and Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, and
Francis Dupont. 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 meetings held in Hong Kong, China and Barcelona,
23-24, 2006). The minutes for this meeting are at Spain. The minutes for the interim meeting at the China University -
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. Hong Kong (February 23-24, 2006) are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The
### Point to minutes of Barcelona meeting minutes for the interim meeting at Polytechnic University of
Catalonia - Barcelona (September 14-15, 2006) are reachable at <http:
//bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-softwire-problem-statement]
Li, X., "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-02 (work in
progress), May 2006.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol [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, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 41, line 24 skipping to change at page 41, line 17
RFC 3371, August 2002. RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Attribute", RFC 4818, April 2007.
August 2006.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dhc-subnet-alloc] [I-D.ietf-dhc-subnet-alloc]
Johnson, R., "Subnet Allocation Option", Johnson, R., "Subnet Allocation Option",
draft-ietf-dhc-subnet-alloc-04 (work in progress), draft-ietf-dhc-subnet-alloc-04 (work in progress),
October 2006. October 2006.
[I-D.ietf-dhc-v6-relay-radius] [I-D.ietf-dhc-v6-relay-radius]
Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
draft-ietf-dhc-v6-relay-radius-02 (work in progress), draft-ietf-dhc-v6-relay-radius-02 (work in progress),
February 2006. February 2006.
[I-D.ietf-ipv6-2461bis] [I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-10 (work in progress), draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
January 2007.
[I-D.ietf-ipv6-over-ppp-v2] [I-D.ietf-ipv6-over-ppp-v2]
Varada, S., "IP Version 6 over PPP", Varada, S., "IP Version 6 over PPP",
draft-ietf-ipv6-over-ppp-v2-02 (work in progress), draft-ietf-ipv6-over-ppp-v2-03 (work in progress),
June 2005. May 2007.
[I-D.ietf-radext-delegated-prefix] [I-D.ietf-softwire-problem-statement]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Dawkins, S., "Softwire Problem Statement",
Attribute", draft-ietf-radext-delegated-prefix-05 (work in draft-ietf-softwire-problem-statement-03 (work in
progress), October 2006. progress), March 2007.
[I-D.ietf-softwire-security-requirements] [I-D.ietf-softwire-security-requirements]
Yamamoto, S., "Softwire Security Analysis and Yamamoto, S., "Softwire Security Analysis and
Requirements", Requirements",
draft-ietf-softwire-security-requirements-01 (work in draft-ietf-softwire-security-requirements-02 (work in
progress), October 2006. progress), March 2007.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point Protocol",
RFC 1471, June 1993.
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for
the IP Network Control Protocol of the Point-to-Point
Protocol", RFC 1473, June 1993.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control [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.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998. RFC 2433, October 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, Modifications for Tunnel Protocol Support", RFC 2867,
June 2000. June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[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.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 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.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 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 -03 and -04:
o Added missing references to [RFC4087], [RFC2461], and [RFC3646],
moved [RFC4623] to Informative.
o Rephrasing in Section 6.2.2. Added pointers Section 6.1.2 and
Section 6.2.2 in Table 2.
o Added citations (and corresponding references) to [RFC1471] and
[RFC1473] in Section 4.4, since Section 9.2 explicitly mentions:
"MIB support for L2TPv2 and PPP are documented."
o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2,
Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2,
Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section 5.4.2, and
Section 8.1.1.
o Added [RFC2868] to Section 4.3, and added missing citations to
Section 4.
o Added missing "Optional AVP" to Figure 11.
o Updated the text in Section 6.2.2.
o Added some clarifying sentences in Section 5.1.1, and completed
Section 5.1.1.1 and Section 5.1.1.2.
o Added an Informative reference to [RFC3022] for NAT/NAPT.
o Corrected reference to [RFC1661] in Section 5.2.2, removed
reference and citation to RFC1662.
o Updated references, Delegated-IPv6-Prefix became [RFC4818] moved
to Normative.
o Added new address and email for J.F. Tremblay.
o Added an acknowledgement to the participants, and pointer to the
minutes, for the Barcelona interim meeting.
o Moved the Softwire Problem Statement reference
[I-D.ietf-softwire-problem-statement] to Informative.
o Some additional purely editorial changes.
Changes between -02 and -03: Changes between -02 and -03:
o Boiler changes in support of RFC 4748. o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1, o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.6 and Section 5.1.2. Section 2.6 and Section 5.1.2.
o Moved some downref to Informative ([RFC1877], [RFC2433], o Moved some downref to Informative ([RFC1877], [RFC2433],
[RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to [RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to
Normative ([RFC1994]). Normative ([RFC1994]).
skipping to change at page 44, line 37 skipping to change at page 46, line 33
o Rewording in Section 5.1.3. o Rewording in Section 5.1.3.
o Section 5.2.1: Add a pointer to [RFC4623] and small updates. o Section 5.2.1: Add a pointer to [RFC4623] and small updates.
o Clarifications on PFC and ACFC, remove Figure 13. o Clarifications on PFC and ACFC, remove Figure 13.
o Section 5.2.3: make references to RFCs for PAP, CHAP, etc. 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 Rewordings in Section 5.2.4.1 and Section 5.2.4.2.
o Added Informative references to [RFC4623], [RFC1661], [RFC1662], o Added Informative references to [RFC4623], [RFC1661], [RFC2433],
[RFC2433], and [RFC3748]. and [RFC3748].
o Renamed the title and added more details on Section 5.3 and IPv6 o Renamed the title and added more details on Section 5.3 and IPv6
ND, including a pointer to [I-D.ietf-ipv6-2461bis]. 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 o Added text in Section 5.4 about IPv4 PD is non-trivial and non
commonly done. commonly done.
o Added B. Stevant as Editor. o Added B. Stevant as Editor.
o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the o Clarification in Section 5.2.4.1 and Section 5.2.4.2 regarding the
skipping to change at page 47, line 7 skipping to change at page 49, line 7
5-Jul-2006, text from JF Tremblay and Bill Storer. 5-Jul-2006, text from JF Tremblay and Bill Storer.
o Completed Section 8.2.2, Section 9.1, Section 9.2, and Section 10. 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
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: bstorer@cisco.com Email: bstorer@cisco.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
skipping to change at page 47, line 32 skipping to change at page 49, line 32
Email: cpignata@cisco.com Email: cpignata@cisco.com
Maria Alice Dos Santos Maria Alice Dos Santos
Cisco Systems Cisco Systems
170 W Tasman Dr 170 W Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: mariados@cisco.com Email: mariados@cisco.com
Jean-Francois Tremblay
Hexago
1470 Peel, suite 910
Montreal, QC J4B 2Z5
Canada
Email: jean-francois.tremblay@hexago.com
Bruno Stevant (editor) Bruno Stevant (editor)
GET/ENST Bretagne GET/ENST Bretagne
2 rue de la Chataigneraie CS17607 2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576 Cesson Sevigne, 35576
France France
Email: bruno.stevant@enst-bretagne.fr Email: bruno.stevant@enst-bretagne.fr
Jean-Francois Tremblay
Trellia Networks
100, Alexis-Nihon, Suite 770
Montreal, QC H4M 2P3
Canada
Email: jf@jftremblay.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 132 change blocks. 
310 lines changed or deleted 430 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/