draft-ietf-v6ops-6204bis-04.txt   draft-ietf-v6ops-6204bis-05.txt 
Network Working Group H. Singh Network Working Group H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Updates: 6204 (if approved) Cisco Systems, Inc. Obsoletes: 6204 (if approved) Cisco Systems, Inc.
Intended status: Informational C. Donley Intended status: Informational C. Donley
Expires: June 7, 2012 CableLabs Expires: June 24, 2012 CableLabs
B. Stark B. Stark
AT&T AT&T
O. Troan, Ed. O. Troan, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
December 5, 2011 December 22, 2011
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-04 draft-ietf-v6ops-6204bis-05
Abstract Abstract
This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it. The document also covers IP transition of IPv6 hosts attached to it. The document also covers IP transition
technologies and transition technologies coexistence. Two transition technologies. Two transition technologies in RFC 5969's 6rd and RFC
technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in 6333's DS-Lite. are covered in the document. The document obsoletes
the document. RFC 6204, if approved.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on June 7, 2012. This Internet-Draft will expire on June 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4 3.1. Current IPv4 End-User Network Architecture . . . . . . . . 4
3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5 3.2. IPv6 End-User Network Architecture . . . . . . . . . . . . 5
3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6 3.2.1. Local Communication . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7
4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7
4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11
4.4. Transition Technologies Support . . . . . . . . . . . . . 13 4.4. Transition Technologies Support . . . . . . . . . . . . . 13
4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Dual-Stack Lite(DS-Lite) . . . . . . . . . . . . . . . 14 4.4.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 14
4.4.3. Transition Technologies Coexistence . . . . . . . . . 15 4.5. Security Considerations . . . . . . . . . . . . . . . . . 14
4.5. Security Considerations . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19
Appendix A. DS-Lite Sunsetting . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Changes from RFC 6204 . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document defines basic IPv6 features for a residential or small- This document defines basic IPv6 features for a residential or small-
office router, referred to as an IPv6 CE router. Typically, these office router, referred to as an IPv6 CE router. Typically, these
routers also support IPv4. routers also support IPv4.
Mixed environments of dual-stack hosts and IPv6-only hosts (behind Mixed environments of dual-stack hosts and IPv6-only hosts (behind
the CE router) can be more complex if the IPv6-only devices are using the CE router) can be more complex if the IPv6-only devices are using
a translator to access IPv4 servers [RFC6144]. Support for such a translator to access IPv4 servers [RFC6144]. Support for such
skipping to change at page 3, line 26 skipping to change at page 3, line 26
This document specifies how an IPv6 CE router automatically This document specifies how an IPv6 CE router automatically
provisions its WAN interface, acquires address space for provisioning provisions its WAN interface, acquires address space for provisioning
of its LAN interfaces, and fetches other configuration information of its LAN interfaces, and fetches other configuration information
from the service provider network. Automatic provisioning of more from the service provider network. Automatic provisioning of more
complex topology than a single router with multiple LAN interfaces is complex topology than a single router with multiple LAN interfaces is
out of scope for this document. out of scope for this document.
See [RFC4779] for a discussion of options available for deploying See [RFC4779] for a discussion of options available for deploying
IPv6 in service provider access networks. IPv6 in service provider access networks.
The document also covers IP transition technologies and transition The document also covers IP transition technologies. Two transition
technologies coexistence. Two transition technologies in 6rd technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
[RFC5969] and DS-Lite [RFC6333] are covered in the document. At the the document. At the time of writing this document these were the
time of writing this document these were the only two transition only two transition technologies available in RFC form to be included
technologies available in RFC form to be included in this document. in this document.
1.1. Requirements Language 1.1. 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
End-User Network one or more links attached to the IPv6 CE End-User Network one or more links attached to the IPv6 CE
skipping to change at page 9, line 34 skipping to change at page 9, line 34
WAA-6: If the IPv6 CE router receives a Router Advertisement message WAA-6: If the IPv6 CE router receives a Router Advertisement message
(described in [RFC4861]) with the M flag set to 1, the IPv6 (described in [RFC4861]) with the M flag set to 1, the IPv6
CE router MUST do DHCPv6 address assignment (request an IA_NA CE router MUST do DHCPv6 address assignment (request an IA_NA
option). option).
WAA-7: If the IPv6 CE router does not acquire global IPv6 WAA-7: If the IPv6 CE router does not acquire global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create address(es) from either SLAAC or DHCPv6, then it MUST create
global IPv6 address(es) from its delegated prefix(es) and global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network configure those on one of its internal virtual network
interfaces, unless explicitly configured to require a global interfaces, unless configured to require a global IPv6
IPv6 address on the WAN interface. address on the WAN interface.
WAA-8: The CE Router MUST parse the DHCPv6 SOL_MAX_RT option WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option
[I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
Advertise or Reply message and set its internal SOL_MAX_RT Advertise or Reply message and set its internal SOL_MAX_RT
parameter to the value contained in the SOL_MAX_RT option. parameter to the value contained in the SOL_MAX_RT option.
WAA-9: As a router, the IPv6 CE router MUST follow the weak host WAA-9: As a router, the IPv6 CE router MUST follow the weak host
(Weak ES) model [RFC1122]. When originating packets from an (Weak ES) model [RFC1122]. When originating packets from an
interface, it will use a source address from another one of interface, it will use a source address from another one of
its interfaces if the outgoing interface does not have an its interfaces if the outgoing interface does not have an
address of suitable scope. address of suitable scope.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
reachable [RFC4632]. reachable [RFC4632].
(a) The IPv6 CE router SHOULD send an ICMPv6 Destination (a) The IPv6 CE router SHOULD send an ICMPv6 Destination
Unreachable message in accordance with Section 3.1 of Unreachable message in accordance with Section 3.1 of
[RFC4443] back to the source of the packet, if the [RFC4443] back to the source of the packet, if the
packet is to be dropped due to this rule. packet is to be dropped due to this rule.
WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD
option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6
Advertise/Reply messages, even if the message does not Advertise/Reply messages, even if the message does not
contain any addresses, unless explicitly configured to only contain any addresses, unless configured to only obtain its
obtain its WAN IPv6 address via DHCPv6. WAN IPv6 address via DHCPv6.
WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic
routing protocol on its WAN interface. routing protocol on its WAN interface.
4.3. LAN-Side Configuration 4.3. LAN-Side Configuration
The IPv6 CE router distributes configuration information obtained The IPv6 CE router distributes configuration information obtained
during WAN interface provisioning to IPv6 hosts and assists IPv6 during WAN interface provisioning to IPv6 hosts and assists IPv6
hosts in obtaining IPv6 addresses. It also supports connectivity of hosts in obtaining IPv6 addresses. It also supports connectivity of
these devices in the absence of any working WAN interface. these devices in the absence of any working WAN interface.
skipping to change at page 13, line 9 skipping to change at page 13, line 9
L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6
options (as listed in Section 5.3 of [RFC3736]) received from options (as listed in Section 5.3 of [RFC3736]) received from
the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 the DHCPv6 client on its WAN interface to its LAN-side DHCPv6
server. server.
L-13: If the delegated prefix changes, i.e., the current prefix is L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero and a Valid old prefix with a Preferred Lifetime of zero and a Valid
Lifetime of the lower of the current Valid Lifetime and two Lifetime of either a) zero, or b) the lower of the current
hours (which must be decremented in real time) in a Router Valid Lifetime and two hours (which must be decremented in
Advertisement message as described in Section 5.5.3, (e) of real time) in a Router Advertisement message as described in
[RFC4862]. Section 5.5.3, (e) of [RFC4862].
L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
message, code 5 (Source address failed ingress/egress policy) message, code 5 (Source address failed ingress/egress policy)
for packets forwarded to it that use an address from a prefix for packets forwarded to it that use an address from a prefix
that has been deprecated. that has been deprecated.
4.4. Transition Technologies Support 4.4. Transition Technologies Support
4.4.1. 6rd 4.4.1. 6rd
The IPv6 CE Router can be used to offer IPv6 service to a LAN, even 6rd [RFC5969] specifies an automatic tunneling mechanism tailored to
when the WAN access network only supports IPv4. One technology that advance deployment of IPv6 to end users via a service provider's IPv4
supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment network infrastructure. Key aspects include automatic IPv6 prefix
(6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside delegation to sites, stateless operation, simple provisioning, and
IPv4 at the IPv6 CE Router and sends it to a Service Provider Border service that is equivalent to native IPv6 at the sites that are
Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6 served by the mechanism. It is expected that such traffic is
prefix during 6rd configuration, and sub-delegates the 6rd delegated forwarded over the CE Router's native IPv4 WAN interface, and not
prefix to devices in the LAN. encapsulated in another tunnel.
The IPv6 CE Router SHOULD implement 6rd functionality as specified in The CE Router SHOULD support 6rd functionality. If 6rd is supported,
[RFC5969]. it MUST be implemented according to [RFC5969]. The following CE
Requirements also apply:
.
6rd requirements: 6rd requirements:
6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE 6RD-1: The IPv6 CE router MUST support 6rd configuration via the 6rd
Router WAN interface MUST support at least one 6rd Virtual DHCPv4 Option (212). If the CE router has obtained an IPv4
Interface. network address through some other means such PPP, it SHOULD
use the DHCPINFORM request message [RFC2131] to request the
6rd DHCPv4 Option. The IPv6 CE router MAY use other
mechanisms to configure 6rd parameters. Such mechanisms are
outside the scope of this document.
6RD-2: If the IPv6 CE router implements 6rd functionality, it MUST 6RD-2: If the IPv6 CE router is capable of automated configuration
support 6rd configuration via the 6rd DHCPv4 Option (212) and
if the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd. The IPv6 CE support user-entered configuration of 6rd.
router MAY use other mechanisms to configure 6rd parameters.
Such mechanisms are outside the scope of this document.
6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether IPv6 traffic to other destinations
within the same 6rd domain are routed directly to those
destinations. The CE router MAY use other mechanisms to
configure this. Such mechanisms are outside the scope of
this document.
6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data
MUST NOT be sent on any 6rd tunnel.
6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite
([RFC6333]) tunnel.
6RD-6: 6rd MUST NOT be initiated if the WAN-side interface has a CE
IPv4 address [RFC5969] that is not unique within the 6rd
domain.
4.4.2. Dual-Stack Lite(DS-Lite) 6RD-3: If the CE router supports configuration mechanisms other than
the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE
router MUST support 6rd in "hub and spoke" mode. 6rd in "hub
and spoke" requires all IPv6 traffic to go to the 6rd Border
Relay. In effect, this requirement removes the "direct
connect to 6rd" route defined in Section 7.1.1 of [RFC5969].
Even as users migrate from IPv4 to IPv6 addressing, a significant 4.4.2. Dual-Stack Lite (DS-Lite)
percentage of Internet resources and content will remain accessible
only through IPv4. Also, many end-user devices will only support
IPv4. As a consequence, Service Providers require mechanisms to
allow customers to continue to access content and resources using
IPv4 even after the last IPv4 allocations have been fully depleted.
One technology that can be used for IPv4 address extension is DS-
Lite.
DS-Lite enables a Service Provider to share IPv4 addresses among Dual-Stack Lite [RFC6333] enables both continued support for IPv4
multiple customers by combining two well-known technologies: IP in IP services and incentives for the deployment of IPv6. It also de-
(IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically, couples IPv6 deployment in the Service Provider network from the rest
Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at of the Internet, making incremental deployment easier. Dual-Stack
the IPv6 CE Router and sends it to a Service Provider Address Family Lite enables a broadband service provider to share IPv4 addresses
Transition Router (AFTR). Configuration of the IPv6 CE Router to among customers by combining two well-known technologies: IP in IP
support IPv4 LAN traffic is outside the scope of this document. (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected
that DS-Lite traffic is forwarded over the CE Router's native IPv6
WAN interface, and not encapsulated in another tunnel.
The IPv6 CE Router SHOULD implement DS-Lite functionality as The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS-
specified in [RFC6333]. Lite is supported, it MUST be implemented according to [RFC6333].
The following CE Router requirements also apply:
WAN requirements: WAN requirements:
DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE DLW-1: The CE Router MUST support DS-Lite via the DS-Lite DHCPv6
Router supports DS-Lite functionality, the CE Router WAN option [RFC6334]. The IPv6 CE Router MAY use other
interface MUST implement a B4 Interface as specified in mechanisms to configure DS-Lite parameters. Such mechanisms
[RFC6333]. are outside the scope of this document.
DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the
CE Router MUST support using a DS-Lite DHCPv6 option
[RFC6334] to configure the DS-Lite tunnel. The IPv6 CE
Router MAY use other mechanisms to configure DS-Lite
parameters. Such mechanisms are outside the scope of this
document.
DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address DLW-2: IPv6 CE Router MUST NOT perform IPv4 Network Address
Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. Translation (NAT) on IPv4 traffic encapsulated using DS-Lite.
DLW-4: If the IPv6 CE Router is configured with an IPv4 address on DLW-3: If the IPv6 CE Router is configured with an IPv4 address on
its WAN interface then the IPv6 CE Router SHOULD disable the its WAN interface then the IPv6 CE Router SHOULD disable the
DS-Lite B4 element. DS-Lite B4 element.
DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast
data MUST NOT be sent on any DS-Lite tunnel.
DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD
tunnel.
4.4.3. Transition Technologies Coexistence
Supporting transition technologies that may coexist with native
service requires control over provisioning and sunsetting. Some
guidelines follow:
1. Initiate native IPv4/IPv6 provisioning (e.g. via DHCP)
simultaneously.
2. After IPv4 provisioning completes, if 6rd parameters are obtained
from the DHCPv4 transaction or configured on the device, initiate
6rd.
3. After IPv6 provisioning completes, if DS-Lite parameters are
obtained from the DHCPv6 transaction or configured on the device,
initiate DS-Lite.
4. Routes over the DS-Lite tunnel always have a higher
administrative distance than native IPv4 routes.
5. Selection of 6rd tunnel or native IPv6 output interface on the CE
router is determined by the source IPv6 address of the packet
from a host, when different prefixes are available over 6rd vs.
native IPv6. If the two interfaces provide the CE router with
the same prefix, then the CE router prefers the native IPv6
interface to the 6rd interface for forwarding traffic out the WAN
when both 6rd and native IPv6 interfaces are active.
6. The CE router messages to the host the use of native IPv6 in
preference to 6rd, in the case where the two interfaces use
different prefixes.
During a sunsetting activity such as deprecating 6rd and moving to
native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
lower of the current Valid Lifetime and two hours (which must be
decremented in real time) in a Router Advertisement message as
described in Section 5.5.3, (e) of [RFC4862]. Due to the two hours
rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
coexist in the home network. The two hours rule specified in section
5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
even when an RA has sent a Preferred Lifetime of zero to expire the
prefix to the node. During such coexistence of multiple prefixes,
the CE router sends an ICMPv6 error for packets sourced or destined
related to the deprecated prefix. Note this document already
includes text in bullet L-14 in section 4.3 for such a provision.
4.5. Security Considerations 4.5. Security Considerations
It is considered a best practice to filter obviously malicious It is considered a best practice to filter obviously malicious
traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus, traffic (e.g., spoofed packets, "Martian" addresses, etc.). Thus,
the IPv6 CE router ought to support basic stateless egress and the IPv6 CE router ought to support basic stateless egress and
ingress filters. The CE router is also expected to offer mechanisms ingress filters. The CE router is also expected to offer mechanisms
to filter traffic entering the customer network; however, the method to filter traffic entering the customer network; however, the method
by which vendors implement configurable packet filtering is beyond by which vendors implement configurable packet filtering is beyond
the scope of this document. the scope of this document.
skipping to change at page 18, line 8 skipping to change at page 16, line 30
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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.
[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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[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.
skipping to change at page 20, line 28 skipping to change at page 19, line 5
Translation", Work in Progress, December 2010. Translation", Work in Progress, December 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, March 2011. IPv4/IPv6 Translation", RFC 6144, March 2011.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001, Gateway Device (IGD)", November 2001,
<http://www.upnp.org/>. <http://www.upnp.org/>.
Appendix A. DS-Lite Sunsetting Appendix A. Changes from RFC 6204
Two deployment scenarios of interest are:
1. DHCPv4 address configured on the WAN without DS-Lite configured,
2. and no DHCPv4 address configured on the WAN and DS-Lite
configured.
The service provider enables transitions between these two scenarios
as follows:
From scenario 1 to scenario 2:
a) CE router performs a DHCPv4 message exchange and receives no
address from the service provider.
b) CE router performs a DHCPv6 message exchange and receives an
IA_ADDRESS in an IA_NA and DS-Lite configuration.
c) When DS-Lite is configured, the CE router turns off DHCPv4.
From scenario 2 to scenario 1:
a) CE router performs a DHCPv6 message exchange and receives no
DS-Lite configuration.
b) CE router continues performing a DHCPv4 message exchange until
it receives an address.
Proposed rules (under discussion) to add to the Coexistence section:
1. If the CE router performs a DHCPv6 message exchange and receives
DS-Lite configuration, stop any ongoing DHCPv4 operation.
2. If the CE router performs a DHCPv6 message exchange and does not
receive DS-Lite configuration, perform a DHCPv4 message exchange
to receive an address.
Appendix B. Changes from RFC 6204
1. Added IP transition technologies available in RFC form. 1. Added IP transition technologies available in RFC form.
2. Added IP transition technologies coexistence. 2. Changed bullet G-5 to augment the condition of losing IPv6
3. Changed bullet G-5 to augment the condition of losing IPv6
default router(s) with loss of connectivity. default router(s) with loss of connectivity.
4. Removed bullet WAA-7 due to not reaching consensus by various 3. Removed bullet WAA-7 due to not reaching consensus by various
service provider standards bodies. The removal of text does not service provider standards bodies. The removal of text does not
remove any critical functionality from the CE specification. remove any critical functionality from the CE specification.
5. Changed bullet WAA-8 to qualify WAN behavior only if not 4. Changed bullet WAA-8 to qualify WAN behavior only if not
configured to perform DHCPv6. This way a deployment specific configured to perform DHCPv6. This way a deployment specific
profile can mandate DHCPv6 numbered WAN wihout conflicting with profile can mandate DHCPv6 numbered WAN wihout conflicting with
this document. this document.
6. Changed the WPD-2 bullet from MUST be configurable to SHOULD be 5. Changed the WPD-2 bullet from MUST be configurable to SHOULD be
configurable. configurable.
7. Changed bullet WPD-4 for a default behavior without compromising 6. Changed bullet WPD-4 for a default behavior without compromising
any prior specification of the CE device. The change was needed any prior specification of the CE device. The change was needed
by a specific layer 1 deployment which wanted to specify a MUST by a specific layer 1 deployment which wanted to specify a MUST
for DHCPv6 in their layer 1 profile and not conflict with this for DHCPv6 in their layer 1 profile and not conflict with this
document. document.
8. Changed bullet WPD-7 to qualify text for DHCPv6. 7. Changed bullet WPD-7 to qualify text for DHCPv6.
9. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so 8. Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
that if an service provider does not have DHCPv6 service enabled that if an service provider does not have DHCPv6 service enabled
CE routers do not send too frequent DHCPv6 requests to the CE routers do not send too frequent DHCPv6 requests to the
service provider DHCPv6 server. service provider DHCPv6 server.
10. Changed bullet L-11 from SHOULD provide DNS options in the RA to 9. Changed bullet L-11 from SHOULD provide DNS options in the RA to
MUST provide DNS option in the RA. MUST provide DNS option in the RA.
11. New bullet added to the Security Considerations section due to 10. New bullet added to the Security Considerations section due to
addition of transition technology. The CE router filters addition of transition technology. The CE router filters
decapsulated 6rd data. decapsulated 6rd data.
12. Minor change involved changing ICMP to ICMPv6. 11. Minor change involved changing ICMP to ICMPv6.
Authors' Addresses Authors' Addresses
Hemant Singh Hemant Singh
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 1622 Phone: +1 978 936 1622
 End of changes. 37 change blocks. 
206 lines changed or deleted 92 lines changed or added

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