draft-ietf-softwire-hs-framework-l2tpv2-02.txt   draft-ietf-softwire-hs-framework-l2tpv2-03.txt 
Softwires Working Group B. Storer, Ed. Softwires Working Group B. Storer, Ed.
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: May 21, 2007 Cisco Systems Expires: August 18, 2007 Cisco Systems
J. Tremblay J. Tremblay
Hexago Hexago
B. Stevant, Ed. B. Stevant, Ed.
GET/ENST Bretagne GET/ENST Bretagne
November 17, 2006 February 14, 2007
Softwires Hub & Spoke Deployment Framework with L2TPv2 Softwires Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-02 draft-ietf-softwire-hs-framework-l2tpv2-03
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 May 21, 2007. This Internet-Draft will expire on August 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
to achieve inter-operability among different vendor implementations. to achieve inter-operability among different vendor implementations.
Table of Contents Table of Contents
skipping to change at page 2, line 23 skipping to change at page 2, line 29
2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7 2. Applicability of L2TPv2 for Softwire Requirements . . . . . . 7
2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 7 2.1. Network and Port Address Translation (NAT/PAT) . . . . . . 7
2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Authentication, Authorization and Accounting . . . . . . . 7 2.4. Authentication, Authorization and Accounting . . . . . . . 7
2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8 2.5. Privacy, Integrity, and Replay Protection . . . . . . . . 8
2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8 2.6. Operations and Management (OAM) . . . . . . . . . . . . . 8
2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 8
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 8 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 10
3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 9 3.1. IPv6 over IPv4 Softwire with L2TPv2 . . . . . . . . . . . 10
3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 9 3.1.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 10
3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 10 3.1.2. Router CPE as Softwire Initiator . . . . . . . . . . . 11
3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 11 3.1.3. Host behind CPE as Softwire Initiator . . . . . . . . 12
3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 12 3.1.4. Router behind CPE as Softwire Initiator . . . . . . . 13
3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 13 3.2. IPv4 over IPv6 Softwire with L2TPv2 . . . . . . . . . . . 14
3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 13 3.2.1. Host CPE as Softwire Initiator . . . . . . . . . . . . 14
3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 14 3.2.2. Router CPE as Softwire Initiator . . . . . . . . . . . 15
3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 15 3.2.3. Host behind CPE as Softwire Initiator . . . . . . . . 16
3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 16 3.2.4. Router behind CPE as Softwire Initiator . . . . . . . 17
4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 17 4. Standardisation Status . . . . . . . . . . . . . . . . . . . . 19
4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 17 4.1. Softwire Transport Related . . . . . . . . . . . . . . . . 19
4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. L2TPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Authentication Authorization Accounting . . . . . . . . . 18 4.3. Authentication Authorization Accounting . . . . . . . . . 19
4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 18 4.5. Softwire Payload Related . . . . . . . . . . . . . . . . . 19
4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 18 4.5.1. For IPv6 Payloads . . . . . . . . . . . . . . . . . . 19
4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 18 4.5.2. For IPv4 Payloads . . . . . . . . . . . . . . . . . . 20
5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 18 5. Softwire Establishment . . . . . . . . . . . . . . . . . . . . 21
5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 20 5.1. L2TPv2 Tunnel Setup . . . . . . . . . . . . . . . . . . . 22
5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 21 5.1.1. Tunnel Establishment . . . . . . . . . . . . . . . . . 23
5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 23 5.1.1.1. AVPs Required for Softwires . . . . . . . . . . . 25
5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 24 5.1.1.2. AVPs Optional for Softwires . . . . . . . . . . . 26
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 24 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 26
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 24 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 26
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 24 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 24 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 25 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 27
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 25 5.2.4.1. IPv6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 25 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 25 5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27
5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.1. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4.2. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Considerations about the Address Provisioning Model . . . . . 27 6. Considerations about the Address Provisioning Model . . . . . 30
6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 27 6.1. Softwire Endpoints Addresses . . . . . . . . . . . . . . . 30
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 27 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 27 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 28 6.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31
6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 28 6.3. Possible scenarios . . . . . . . . . . . . . . . . . . . . 31
6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 28 6.3.1. Scenarios for IPv6 . . . . . . . . . . . . . . . . . . 31
6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 28 6.3.2. Scenarios for IPv4 . . . . . . . . . . . . . . . . . . 31
7. Considerations about Address Stability . . . . . . . . . . . . 29 7. Considerations about Address Stability . . . . . . . . . . . . 33
8. Considerations about RADIUS Integration . . . . . . . . . . . 29 8. Considerations about RADIUS Integration . . . . . . . . . . . 34
8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 29 8.1. Softwires Endpoints . . . . . . . . . . . . . . . . . . . 34
8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 30 8.1.1. IPv6 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 30 8.1.2. IPv4 Softwires . . . . . . . . . . . . . . . . . . . . 34
8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 30 8.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 34
8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 8.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 35
8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 31 8.2.2. IPv4 Prefixes . . . . . . . . . . . . . . . . . . . . 35
9. Considerations for Maintenance and Statistics . . . . . . . . 31 9. Considerations for Maintenance and Statistics . . . . . . . . 36
9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 31 9.1. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 36
9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 48
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 49 skipping to change at page 5, line 49
authentication which allows both SI and SC to validate each other's authentication which allows both SI and SC to validate each other's
identity at the initial phase of hand-shaking before proceeding with identity at the initial phase of hand-shaking before proceeding with
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 may send L2TPv2 During the life of the Softwire, both SI and SC send L2TPv2 keepalive
keepalive HELLO messages to monitor the health of the Softwire and HELLO messages to monitor the health of the Softwire and the peer
the peer LCCE or to refresh the NAT/PAT translation entry at the CPE LCCE or to refresh the NAT/PAT translation entry at the CPE or at the
or at the other end of the access link. In the event of keepalive other end of the access link. Optionally, LCP ECHO messages can be
used as keepalives for the same purposes. In the event of keepalive
timeout or administrative shutdown of the Softwire, either SI or SC timeout or administrative shutdown of the Softwire, either SI or SC
may tear down the Softwire by tearing down the L2TPv2 Control Channel may tear down the Softwire by tearing down the L2TPv2 Control Channel
and Session as specified in [RFC2661]. and Session as specified in [RFC2661].
1.1. Abbreviations 1.1. Abbreviations
LCCE L2TP Control Connection Endpoint (See [RFC3931]) LCCE L2TP Control Connection Endpoint (See [RFC3931])
SC Softwire Concentrator, the node terminating the Softwire in SC Softwire Concentrator, the node terminating the Softwire in
the service provider network (See the service provider network (See
skipping to change at page 8, line 24 skipping to change at page 8, line 24
inherited PPP authentication and PPP Encryption Control Protocol can inherited PPP authentication and PPP Encryption Control Protocol can
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 can be used to monitor 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/PAT
translation entry along the access link. translation entry along the access link.
LCP ECHO offers a similar mechanism to monitor the connectivity
status, as described in [RFC1661]. Softwires implementations SHOULD
use L2TPv2 Hello keepalives and in addition MAY use PPP LCP Echo
messages to ensure Dead End Detection and/or to refresh NAT/PAT
translation entries. The combination of these two mechanisms can be
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
L2TPv2 supports the following encapsulations: L2TPv2 supports the following encapsulations:
skipping to change at page 24, line 27 skipping to change at page 26, line 27
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 transit a message to the SC to maintain NAT Periodically, the SI MUST transmit a message to the SC to maintain
context and detect tunnel failure. The L2TPv2 HELLO message provides NAT/PAT contexts and detect tunnel failure. The L2TPv2 HELLO message
a simple, low overhead method of doing this. However, using the provides a simple, low overhead method of doing this.
default values specified in [RFC2661] could result in a dead end
detection time of 83 seconds. If this is not acceptable, LCP Echo The default values specified in [RFC2661] for L2TPv2 HELLO messages
Request and Reply messages may be used for quicker dead end could result in a dead end detection time of 83 seconds. Although
detection. these retransmission timers and counters SHOULD be configurable (see
[RFC2661]), these values may not be adapted for all situations, where
a quicker dead end detection is required, or where NAT/PAT context
needs to be refreshed more frequently. In such cases, the SI MAY
use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo-
Request and Echo-Reply codes) described in [RFC1661] which timeout
could be configured to a lower value. When used, LCP ECHO messages
SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO
hello messages.
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
skipping to change at page 25, line 16 skipping to change at page 27, line 26
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]. ACFC
[RFC1662] SHOULD be rejected. [RFC1662] 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 PAP Softwire Concentrator. Other authentication methods such as MS-
[RFC1994], MS-CHAP [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
skipping to change at page 32, line 42 skipping to change at page 40, line 23
[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, [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994. July 1994.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995.
[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
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.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998. RFC 2472, December 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001. "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two [RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base", Tunneling Protocol "L2TP" Management Information Base",
RFC 3371, August 2002. RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006. August 2006.
13.2. Informative References 13.2. Informative References
skipping to change at page 34, line 31 skipping to change at page 41, line 42
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-09 (work in progress), draft-ietf-ipv6-2461bis-10 (work in progress),
October 2006. 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-02 (work in progress),
June 2005. June 2005.
[I-D.ietf-radext-delegated-prefix] [I-D.ietf-radext-delegated-prefix]
Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", draft-ietf-radext-delegated-prefix-05 (work in Attribute", draft-ietf-radext-delegated-prefix-05 (work in
progress), October 2006. progress), October 2006.
skipping to change at page 35, line 6 skipping to change at page 42, line 17
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-01 (work in
progress), October 2006. progress), October 2006.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication [RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol (CHAP)", RFC 1994, August 1996. Protocol Extensions for Name Server Addresses", RFC 1877,
December 1995.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
Appendix A. Revision History Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the [Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to corresponding entries in the table of contents, prior to
publication.] publication.]
Changes between -02 and -03:
o Boiler changes in support of RFC 4748.
o Added text about L2TPv2 HELLO and LCP ECHO usage in Section 1,
Section 2.6 and Section 5.1.2.
o Moved some downref to Informative ([RFC1877], [RFC2433],
[RFC2867], [RFC2868], and [RFC3748]), and moved CHAP reference to
Normative ([RFC1994]).
o Removed the mention and citation for PAP authentication.
Changes between -01 and -02: Changes between -01 and -02:
o Renamed all "Best Current Practices" sections as o Renamed all "Best Current Practices" sections as
"Recommendations". See for example Section 1.4. "Recommendations". See for example Section 1.4.
o Moved Provisioning in Section 6. Removed intro text to new o Moved Provisioning in Section 6. Removed intro text to new
Section 7. Section 7.
o Removed all normative language from Section 6, Section 7, o Removed all normative language from Section 6, Section 7,
Section 8, and Section 9. Section 8, and Section 9.
skipping to change at page 40, line 7 skipping to change at page 48, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). 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
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 32 change blocks. 
115 lines changed or deleted 144 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/