draft-ietf-softwire-hs-framework-l2tpv2-09.txt   draft-ietf-softwire-hs-framework-l2tpv2-10.txt 
Softwires Working Group B. Storer Softwires Working Group B. Storer
Internet-Draft C. Pignataro, Ed. Internet-Draft C. Pignataro, Ed.
Intended status: Standards Track M. Dos Santos Intended status: Standards Track M. Dos Santos
Expires: January 11, 2009 Cisco Systems Expires: May 2, 2009 Cisco Systems
B. Stevant, Ed. B. Stevant, Ed.
TELECOM Bretagne TELECOM Bretagne
J. Tremblay J. Tremblay
Trellia Networks Trellia Networks
July 10, 2008 October 29, 2008
Softwire Hub & Spoke Deployment Framework with L2TPv2 Softwire Hub & Spoke Deployment Framework with L2TPv2
draft-ietf-softwire-hs-framework-l2tpv2-09 draft-ietf-softwire-hs-framework-l2tpv2-10
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 January 11, 2009. This Internet-Draft will expire on May 2, 2009.
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 the Layer 2 Tunneling Protocol version 2 (L2TPv2). The solution with the Layer 2 Tunneling Protocol version 2 (L2TPv2). 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.
Table of Contents Table of Contents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25 5.1.1.3. AVPs not Relevant for Softwires . . . . . . . . . 25
5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25 5.1.2. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 25
5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26 5.1.3. Tunnel Teardown . . . . . . . . . . . . . . . . . . . 26
5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26 5.2. PPP Connection . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.1. MTU . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2. LCP . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26 5.2.3. Authentication . . . . . . . . . . . . . . . . . . . . 26
5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4. IPCP . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.1. IPV6CP . . . . . . . . . . . . . . . . . . . . . . 27
5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27 5.2.4.2. IPv4CP . . . . . . . . . . . . . . . . . . . . . . 27
5.3. Global IPv6 Address Assignement to Endpoints . . . . . . . 27 5.3. Global IPv6 Address Assignment to Endpoints . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Considerations about the Address Provisioning Model . . . . . 29 6. Considerations about the Address Provisioning Model . . . . . 29
6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29 6.1. Softwire Endpoints' Addresses . . . . . . . . . . . . . . 29
6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.2. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29 6.2. Delegated Prefixes . . . . . . . . . . . . . . . . . . . . 29
6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30 6.2.1. IPv6 Prefixes . . . . . . . . . . . . . . . . . . . . 30
skipping to change at page 4, line 4 skipping to change at page 4, line 4
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . . . 45
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
Softwire "Hubs and Spokes" solution space. This document describes Softwire "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 10, line 41 skipping to change at page 10, line 41
In this scenario, after the L2TPv2 Control Channel and Session In this scenario, after the L2TPv2 Control Channel and Session
establishment and PPP LCP negotiation (and optionally PPP establishment and PPP LCP negotiation (and optionally PPP
Authentication) are successful, IPV6CP negotiates IPv6 over PPP which Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
also provides the capability for the ISP to assign the 64-bit also provides the capability for the ISP to assign the 64-bit
Interface-Identifier to the host CPE or perform uniqueness validation Interface-Identifier to the host CPE or perform uniqueness validation
for the two interface identifiers at the two PPP ends [RFC5072]. for the two interface identifiers at the two PPP ends [RFC5072].
After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / After IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration /
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
inform the host CPE of a prefix to use for stateless address inform the host CPE of a prefix to use for stateless address
autoconfiguration through a Router Advertisement (RA) while other autoconfiguration through a Router Advertisement (RA) while other
nonaddress configuration options (such as DNS [RFC3646] or other non-address configuration options (such as DNS [RFC3646] or other
servers' addresses that might be available) can be conveyed to the servers' addresses that might be available) can be conveyed to the
host CPE via DHCPv6. host CPE via DHCPv6.
3.1.2. Router CPE as Softwire Initiator 3.1.2. Router CPE as Softwire Initiator
The Softwire Initiator (SI) is the router CPE, which is a dual-stack The Softwire Initiator (SI) is the router CPE, which is a dual-stack
device. The IPv4 traffic SHOULD NOT traverse the Softwire. See device. The IPv4 traffic SHOULD NOT traverse the Softwire. See
Figure 2. Figure 2.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
skipping to change at page 11, line 48 skipping to change at page 11, line 48
Authentication) are successful, IPV6CP negotiates IPv6 over PPP which Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
also provides the capability for the ISP to assign the 64-bit also provides the capability for the ISP to assign the 64-bit
Interface-Identifier to the router CPE or perform uniqueness Interface-Identifier to the router CPE or perform uniqueness
validation for the two interface identifiers at the two PPP ends validation for the two interface identifiers at the two PPP ends
[RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address
Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP
link, and the LNS can inform the router CPE of a prefix to use for link, and the LNS can inform the router CPE of a prefix to use for
stateless address autoconfiguration through a Router Advertisement stateless address autoconfiguration through a Router Advertisement
(RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g.,
delegating a prefix to be used within the home network [RFC3633]) and delegating a prefix to be used within the home network [RFC3633]) and
convey other nonaddress configuration options (such as DNS [RFC3646]) convey other non-address configuration options (such as DNS
to the router CPE. [RFC3646]) to the router CPE.
3.1.3. Host behind CPE as Softwire Initiator 3.1.3. Host behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The
IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3. IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------| |------------------||----------------------------||----------|
skipping to change at page 12, line 47 skipping to change at page 12, line 47
In this scenario, after the L2TPv2 Control Channel and Session In this scenario, after the L2TPv2 Control Channel and Session
establishment and PPP LCP negotiation (and optionally PPP establishment and PPP LCP negotiation (and optionally PPP
Authentication) are successful, IPV6CP negotiates IPv6 over PPP which Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
also provides the capability for the ISP to assign the 64-bit also provides the capability for the ISP to assign the 64-bit
Interface-Identifier to the host or perform uniqueness validation for Interface-Identifier to the host or perform uniqueness validation for
the two interface identifiers at the two PPP ends [RFC5072]. After the two interface identifiers at the two PPP ends [RFC5072]. After
IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration / IPv6 over PPP is up, IPv6 Stateless Address Autoconfiguration /
Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can Neighbor Discovery runs over the IPv6 over PPP link, and the LNS can
inform the host of a prefix to use for stateless address inform the host of a prefix to use for stateless address
autoconfiguration through a Router Advertisement (RA) while other autoconfiguration through a Router Advertisement (RA) while other
nonaddress configuration options (such as DNS [RFC3646]) can be non-address configuration options (such as DNS [RFC3646]) can be
conveyed to the host via DHCPv6. conveyed to the host via DHCPv6.
3.1.4. Router behind CPE as Softwire Initiator 3.1.4. Router behind CPE as Softwire Initiator
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack
device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside
the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. the home network. The IPv4 traffic SHOULD NOT traverse the Softwire.
See Figure 4. See Figure 4.
IPv6 or dual-stack IPv4-only dual-stack IPv6 or dual-stack IPv4-only dual-stack
skipping to change at page 14, line 11 skipping to change at page 14, line 11
Authentication) are successful, IPV6CP negotiates IPv6 over PPP which Authentication) are successful, IPV6CP negotiates IPv6 over PPP which
also provides the capability for the ISP to assign the 64-bit also provides the capability for the ISP to assign the 64-bit
Interface-Identifier to the v4/v6 router or perform uniqueness Interface-Identifier to the v4/v6 router or perform uniqueness
validation for the two interface identifiers at the two PPP ends validation for the two interface identifiers at the two PPP ends
[RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address [RFC5072]. After IPv6 over PPP is up, IPv6 Stateless Address
Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP Autoconfiguration / Neighbor Discovery runs over the IPv6 over PPP
link, and the LNS can inform the v4/v6 router of a prefix to use for link, and the LNS can inform the v4/v6 router of a prefix to use for
stateless address autoconfiguration through a Router Advertisement stateless address autoconfiguration through a Router Advertisement
(RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g.,
delegating a prefix to be used within the home network [RFC3633]) and delegating a prefix to be used within the home network [RFC3633]) and
convey other nonaddress configuration options (such as DNS [RFC3646]) convey other non-address configuration options (such as DNS
to the v4/v6 router. [RFC3646]) to the v4/v6 router.
3.2. IPv4 over IPv6 Softwires with L2TPv2 3.2. IPv4 over IPv6 Softwires with L2TPv2
The following subsections cover IPv4 connectivity (SPH) across an The following subsections cover IPv4 connectivity (SPH) across an
IPv6-only access network (STH) using a Softwire. IPv6-only access network (STH) using a Softwire.
3.2.1. Host CPE as Softwire Initiator 3.2.1. Host CPE as Softwire Initiator
The Softwire Initiator (SI) is the host CPE (directly connected to a The Softwire Initiator (SI) is the host CPE (directly connected to a
modem), which is dual-stack. There is no other gateway device. The modem), which is dual-stack. There is no other gateway device. The
skipping to change at page 21, line 50 skipping to change at page 21, line 50
| | or | | or
|<---------DHCPDISCOVER-----------| - |<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4 |-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional) |<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| - |------------DHCPACK------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire Figure 10: Detailed Steps in the Establishment of a Softwire
The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4 The PPP NCP negotiations in step 2 use IPV6CP for IPv6 over IPv4
Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP Softwires, and IPCP for IPv4 over IPv6 Softwires. The optional DHCP
negitiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and negotiations in step 3 use DHCPv6 for IPv6 over IPv4 Softwires, and
DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over DHCPv4 for IPv4 over IPv6 Softwires. Additionally, for IPv6 over
IPv4 Softwires, the DHCPv6 exchange for nonaddress configuration IPv4 Softwires, the DHCPv6 exchange for non-address configuration
(such as DNS) can use a two message exchange with Information-Request (such as DNS) can use Stateless DHCPv6, the two message exchange with
and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]). Information-Request and Reply messages (see Section 1.2 of [RFC3315]
and [RFC3736]).
5.1. L2TPv2 Tunnel Setup 5.1. L2TPv2 Tunnel Setup
L2TPv2 [RFC2661] was originally designed to provide private network L2TPv2 [RFC2661] was originally designed to provide private network
access to end users connected to a public network. In the L2TPv2 access to end users connected to a public network. In the L2TPv2
incoming call model, the end user makes a connection to an L2TP incoming call model, the end user makes a connection to an L2TP
Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel
to an L2TP Network Server (LNS). The LNS then transfers end user to an L2TP Network Server (LNS). The LNS then transfers end user
traffic between the L2TPv2 tunnel and the private network. traffic between the L2TPv2 tunnel and the private network.
skipping to change at page 26, line 7 skipping to change at page 26, line 7
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
Section 5.8 of [RFC2661]), these values may not be adapted for all Section 5.8 of [RFC2661]), these values may not be adapted for all
situations, where a quicker dead end detection is required, or where situations, where a quicker dead end detection is required, or where
NAT/NAPT context needs to be refreshed more frequently. In such NAT/NAPT context needs to be refreshed more frequently. In such
cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO
messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. messages (Echo-Request and Echo-Reply codes) described in [RFC1661].
When used, LCP ECHO messages SHOULD have a re-emission timer lower When used, LCP ECHO messages SHOULD have a re-emission timer lower
than the value for L2TPv2 HELLO hello messages. The default value than the value for L2TPv2 HELLO messages. The default value
recommended in Section 6.5 of [RFC2661] for the HELLO message recommended in Section 6.5 of [RFC2661] for the HELLO message
retransmission interval is 60 seconds. When used, a set of suggested retransmission interval is 60 seconds. When used, a set of suggested
values (included here only for guidance) for the LCP ECHO message values (included here only for guidance) for the LCP ECHO message
request interval is a default of 30 seconds, a minimum of 10 seconds, request interval is a default of 30 seconds, a minimum of 10 seconds,
and a maximum of the lesser of the configured L2TPv2 HELLO and a maximum of the lesser of the configured L2TPv2 HELLO
retransmisison interval and 60 seconds. retransmission interval and 60 seconds.
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 Section 5.7 of [RFC2661], by sending a StopCCN done as specified in Section 5.7 of [RFC2661], by sending a StopCCN
control message. There is no action specific to Softwires in this control message. There is no action specific to Softwires in this
case. case.
5.2. PPP Connection 5.2. PPP Connection
This section describes the PPP negotiations between the SI and SC in This section describes the PPP negotiations between the SI and SC in
the Softwire context. the Softwire context.
5.2.1. MTU 5.2.1. MTU
The MTU of the PPP link presented to the SPH SHOULD be the link MTU The MTU of the PPP link presented to the SPH SHOULD be the link MTU
minus the size of the IP, UDP, L2TPv2, and PPP headers together. On minus the size of the IP, UDP, L2TPv2, and PPP headers together. On
an IPv4 link with an MTU equal to 1500 bytes, this could tipically an IPv4 link with an MTU equal to 1500 bytes, this could typically
mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, mean a PPP MTU of 1460 bytes. When the link is managed by IPsec,
this MTU should be lowered to take into account the ESP encapsulation this MTU should be lowered to take into account the ESP encapsulation
(see [I-D.ietf-softwire-security-requirements]). The value for the (see [I-D.ietf-softwire-security-requirements]). The value for the
MTU may also vary according to the size of the L2TP header, as MTU may also vary according to the size of the L2TP header, as
defined by the leading bits of the L2TP message header (see defined by the leading bits of the L2TP message header (see
[RFC2661]). Additionally, see [RFC4623] for a detailed discussion of [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of
fragmentation issues. fragmentation issues.
5.2.2. LCP 5.2.2. LCP
skipping to change at page 27, line 31 skipping to change at page 27, line 31
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 Assignment to Endpoints
In several scenarios defined in Section 3.1, Global IPv6 addresses In several scenarios defined in Section 3.1, Global IPv6 addresses
are expected to be allocated to Softwire endpoints (in addition to are expected to be allocated to Softwire endpoints (in addition to
the Link-Local addresses autoconfigured using the IPV6CP negotiated the Link-Local addresses autoconfigured using the IPV6CP negotiated
interface identifier). The Softwire Initiator assigns global IPv6 interface identifier). The Softwire Initiator assigns global IPv6
addresses using the IPV6CP negotiated interface identifier and using addresses using the IPV6CP negotiated interface identifier and using
Stateless Address Autoconfiguration [RFC4862], and/or using Privacy Stateless Address Autoconfiguration [RFC4862], and/or using Privacy
Extensions for Stateless Address Autoconfiguration [RFC4941], (as Extensions for Stateless Address Autoconfiguration [RFC4941], (as
described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315]. described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315].
skipping to change at page 28, line 16 skipping to change at page 28, line 16
Duplicate Address Detection ([RFC4861]) MUST be performed on the Duplicate Address Detection ([RFC4861]) MUST be performed on the
Softwire in both cases. Softwire in both cases.
5.4. DHCP 5.4. DHCP
The Softwire Initiator MAY use DHCP to get additional information The Softwire Initiator MAY use DHCP to get additional information
such as delegated prefix and DNS servers. such as delegated prefix and DNS servers.
5.4.1. DHCPv6 5.4.1. DHCPv6
In the scenarions in Section 3.1, if the SI supports DHCPv6, it In the scenarios in Section 3.1, if the SI supports DHCPv6, it SHOULD
SHOULD send a Solicit message to verify if more information is send a Solicit message to verify if more information is available.
available.
If an SI establishing an IPv6 Softwire acts as a router (i.e., in the If an SI establishing an IPv6 Softwire acts as a router (i.e., in the
scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the scenarios in Section 3.1.2 and Section 3.1.4) it MUST include the
IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in IA_PD option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in
order to request an IPv6 prefix. order to request an IPv6 prefix.
When delegating an IPv6 prefix to the SI by returning a DHCPv6 When delegating an IPv6 prefix to the SI by returning a DHCPv6
Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], Advertise message with the IA_PD and IP_PD Prefix options [RFC3633],
the SC SHOULD inject a route for this prefix in the IPv6 routing the SC SHOULD inject a route for this prefix in the IPv6 routing
table in order to forward the traffic to the relevant Softwire. table in order to forward the traffic to the relevant Softwire.
skipping to change at page 29, line 8 skipping to change at page 29, line 7
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'.
In the scenarions in Section 3.2, when delegating an IPv4 prefix to In the scenarios in Section 3.2, when delegating an IPv4 prefix to
the SI, the SC SHOULD inject a route for this prefix in the IPv4 the SI, the SC SHOULD inject a route for this prefix in the IPv4
routing table in order to forward the traffic to the relevant routing table in order to forward the traffic to the relevant
Softwire. Softwire.
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
delegated addresses for Softwire endpoints and for subnets behind the delegated addresses for Softwire endpoints and for subnets behind the
Softwire Initiator. One common practice is to aggregate endpoints' Softwire Initiator. One common practice is to aggregate endpoints'
addresses and delegated prefixes into one prefix routed to the SC. addresses and delegated prefixes into one prefix routed to the SC.
skipping to change at page 30, line 30 skipping to change at page 30, line 30
Delegated IPv4 prefixes should be routable within the address space Delegated IPv4 prefixes should be routable within the address space
used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes
(i.e., private IPv4 prefix over public IPv4 addresses or another (i.e., private IPv4 prefix over public IPv4 addresses or another
class of private IPv4 addresses) is not recommended as a practice for class of private IPv4 addresses) is not recommended as a practice for
provisioning and address translation should be considered in these provisioning and address translation should be considered in these
cases. The prefix length is between /8 and /30. cases. The prefix length is between /8 and /30.
6.3. Possible Address Provisioning Scenarios 6.3. Possible Address Provisioning Scenarios
This section summarizes the differents scenarios for address This section summarizes the different 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.
+------------------+-----------------------+------------------------+ +------------------+-----------------------+------------------------+
| Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 | | Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 |
| Address | Prefix | Prefix | | Address | Prefix | Prefix |
skipping to change at page 31, line 47 skipping to change at page 31, line 47
different Softwire Concentrators at the cost of a more fragmented different Softwire Concentrators at the cost of a more fragmented
routing table. The routing fragmentation issue may be limited if the routing table. The routing fragmentation issue may be limited if the
prefixes are aggregated in a location topologically close to the SC. prefixes are aggregated in a location topologically close to the SC.
This would be the case for example if several SCs are put in parallel This would be the case for example if several SCs are put in parallel
for load-balancing purpose. for load-balancing purpose.
8. Considerations about RADIUS Integration 8. Considerations about RADIUS Integration
The Softwire Concentrator is expected to act as a client to a AAA The Softwire Concentrator is expected to act as a client to a AAA
server, for example a RADIUS server. During the PPP authentication server, for example a RADIUS server. During the PPP authentication
phase, the RADIUS server may return additional informations in the phase, the RADIUS server may return additional information in the
form of attributes in the Access-Accept message. form of attributes in the Access-Accept message.
The Softwire Concentrator may include the Tunnel-Type and Tunnel- The Softwire Concentrator may include the Tunnel-Type and Tunnel-
Medium-Type attributes [RFC2868] in the Access-Request messages to Medium-Type attributes [RFC2868] in the Access-Request messages to
provide a hint of the type of Softwire being configured. provide a hint of the type of Softwire being configured.
8.1. Softwire Endpoints 8.1. Softwire Endpoints
8.1.1. IPv6 Softwires 8.1.1. IPv6 Softwires
skipping to change at page 34, line 21 skipping to change at page 34, line 21
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
This document creates no new requirements on IANA namespaces. This document creates no new requirements on IANA namespaces.
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, Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley,
Francis Dupont and Ralph Droms. Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand.
The authors would also like to acknowledge the participants in the The authors would also like to acknowledge the participants in the
Softwires interim meetings held in Hong Kong, China and Barcelona, Softwires interim meetings held in Hong Kong, China and Barcelona,
Spain. The minutes for the interim meeting at the China University - Spain. The minutes for the interim meeting at the China University -
Hong Kong (February 23-24, 2006) are at Hong Kong (February 23-24, 2006) are at
<http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The <http://www3.ietf.org/proceedings/06mar/minutes/isoftwire.html>. The
minutes for the interim meeting at Polytechnic University of minutes for the interim meeting at Polytechnic University of
Catalonia - Barcelona (September 14-15, 2006) are reachable at <http: Catalonia - Barcelona (September 14-15, 2006) are reachable at <http:
//bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>. //bgp.nu/~dward/softwires/InterimmeetingBarcelonaSeptember2006.htm>.
skipping to change at page 36, line 22 skipping to change at page 36, line 22
[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-softwire-security-requirements] [I-D.ietf-softwire-security-requirements]
Yamamoto, S., Williams, C., Parent, F., and H. Yokota, Yamamoto, S., Williams, C., Parent, F., and H. Yokota,
"Softwire Security Analysis and Requirements", "Softwire Security Analysis and Requirements",
draft-ietf-softwire-security-requirements-06 (work in draft-ietf-softwire-security-requirements-06 (work in
progress), February 2008. progress), October 2008.
[I-D.stevant-softwire-accounting] [I-D.stevant-softwire-accounting]
Stevant, B., "Accounting on Softwires", Stevant, B., "Accounting on Softwires",
draft-stevant-softwire-accounting-01 (work in progress), draft-stevant-softwire-accounting-01 (work in progress),
October 2006. October 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for [RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point Protocol", the Link Control Protocol of the Point-to-Point Protocol",
RFC 1471, June 1993. RFC 1471, June 1993.
skipping to change at page 38, line 7 skipping to change at page 38, line 7
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
Appendix A. Revision History Appendix A. Revision History
[Note to RFC Editor: please remove this entire appendix, and the [Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to corresponding entries in the table of contents, prior to
publication.] publication.]
Changes between -09 and -10:
o Fixed a number of typos.
Changes between -08 and -09: Changes between -08 and -09:
o Refresh version about to expire, no other changes. o Refresh version about to expire, no other changes.
Changes between -07 and -08: Changes between -07 and -08:
o Corrected the usage of Softwire vs. Softwires throughout the o Corrected the usage of Softwire vs. Softwires throughout the
document, esp. when used as an adjective. document, esp. when used as an adjective.
o Editorial: Re-arranged "Contributing Authors" (Section 1.3). o Editorial: Re-arranged "Contributing Authors" (Section 1.3).
 End of changes. 23 change blocks. 
28 lines changed or deleted 32 lines changed or added

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