draft-ietf-v6ops-6204bis-09.txt   draft-ietf-v6ops-6204bis-10.txt 
Network Working Group H. Singh Network Working Group H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Obsoletes: 6204 (if approved) Cisco Systems, Inc. Obsoletes: 6204 (if approved) Cisco Systems, Inc.
Intended status: Informational C. Donley Intended status: Informational C. Donley
Expires: November 18, 2012 CableLabs Expires: February 17, 2013 CableLabs
B. Stark B. Stark
AT&T AT&T
May 17, 2012 August 16, 2012
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-09 draft-ietf-v6ops-6204bis-10
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. Two transition technologies in RFC 5969's 6rd and RFC technologies. Two transition technologies in RFC 5969's 6rd and RFC
6333's DS-Lite are covered in the document. The document obsoletes 6333's DS-Lite are covered in the document. The document obsoletes
RFC 6204, if approved. RFC 6204, if approved.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 November 18, 2012. This Internet-Draft will expire on February 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 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. Two transition The document also covers the IP transition technologies that were
available at the time this document was written. Two transition
technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
the document. the 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
skipping to change at page 6, line 20 skipping to change at page 6, line 20
Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic
multicast routing protocol. multicast routing protocol.
The IPv6 CE router may be manually configured in an arbitrary The IPv6 CE router may be manually configured in an arbitrary
topology with a dynamic routing protocol. Automatic provisioning and topology with a dynamic routing protocol. Automatic provisioning and
configuration are described for a single IPv6 CE router only. configuration are described for a single IPv6 CE router only.
3.2.1. Local Communication 3.2.1. Local Communication
Link-local IPv6 addresses are used by hosts communicating on a single Link-local IPv6 addresses are used by hosts communicating on a single
link. Unique Local IPv6 Unicast Addresses (ULA's) [RFC4193] are used link. Unique Local IPv6 Unicast Addresses (ULAs) [RFC4193] are used
by hosts communicating within the end-user network across multiple by hosts communicating within the end-user network across multiple
links, but without requiring the application to use a globally links, but without requiring the application to use a globally
routable address. The IPv6 CE router defaults to acting as the routable address. The IPv6 CE router defaults to acting as the
demarcation point between two networks by providing a ULA boundary, a demarcation point between two networks by providing a ULA boundary, a
multicast zone boundary, and ingress and egress traffic filters. multicast zone boundary, and ingress and egress traffic filters.
At the time of this writing, several host implementations do not At the time of this writing, several host implementations do not
handle the case where they have an IPv6 address configured and no handle the case where they have an IPv6 address configured and no
IPv6 connectivity, either because the address itself has a limited IPv6 connectivity, either because the address itself has a limited
topological reachability (e.g., ULA) or because the IPv6 CE router is topological reachability (e.g., ULA) or because the IPv6 CE router is
skipping to change at page 9, line 10 skipping to change at page 9, line 10
Link-layer requirements: Link-layer requirements:
WLL-1: If the WAN interface supports Ethernet encapsulation, then WLL-1: If the WAN interface supports Ethernet encapsulation, then
the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].
WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE WLL-2: If the WAN interface supports PPP encapsulation, the IPv6 CE
router MUST support IPv6 over PPP [RFC5072]. router MUST support IPv6 over PPP [RFC5072].
WLL-3: If the WAN interface supports PPP encapsulation, in a dual- WLL-3: If the WAN interface supports PPP encapsulation, in a dual-
stack environment with IPCP and IPV6CP running over one PPP stack environment with IPCP and IPV6CP running over one PPP
logical channel, the Network Control Protocols (NCP's) MUST logical channel, the Network Control Protocols (NCPs) MUST be
be treated as independent of each other and start and treated as independent of each other and start and terminate
terminate independently. independently.
Address assignment requirements: Address assignment requirements:
WAA-1: The IPv6 CE router MUST support Stateless Address WAA-1: The IPv6 CE router MUST support Stateless Address
Autoconfiguration (SLAAC) [RFC4862]. Autoconfiguration (SLAAC) [RFC4862].
WAA-2: The IPv6 CE router MUST follow the recommendations in WAA-2: The IPv6 CE router MUST follow the recommendations in
Section 4 of [RFC5942], and in particular the handling of Section 4 of [RFC5942], and in particular the handling of
the L flag in the Router Advertisement Prefix Information the L flag in the Router Advertisement Prefix Information
option. option.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
WAA-4: The IPv6 CE router MUST be able to support the following WAA-4: The IPv6 CE router MUST be able to support the following
DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and
DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to
support the DNS Search List DNSSL option as specified in support the DNS Search List DNSSL option as specified in
[RFC3646]. [RFC3646].
WAA-5: The IPv6 CE router SHOULD implement the Network Time WAA-5: The IPv6 CE router SHOULD implement the Network Time
Protocol (NTP) as specified in [RFC5905]. If the CE router Protocol (NTP) as specified in [RFC5905]. If the CE router
implements NTP, it requests the NTP Server DHCPv6 option implements NTP, it requests the NTP Server DHCPv6 option
[RFC5908] and uses the received list of servers as primary [RFC5908] and uses the received list of servers as primary
time reference, unless explicitly configured otherwise. time reference, unless explicitly configured otherwise. LAN
side support of NTP is out of scope for this document.
WAA-6: If the IPv6 CE router receives a Router Advertisement WAA-6: If the IPv6 CE router receives a Router Advertisement
message (described in [RFC4861]) with the M flag set to 1, message (described in [RFC4861]) with the M flag set to 1,
the IPv6 CE router MUST do DHCPv6 address assignment the IPv6 CE router MUST do DHCPv6 address assignment
(request an IA_NA option). (request an IA_NA 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 configured to require a global IPv6 interfaces, unless configured to require a global IPv6
address on the WAN interface. address on the WAN interface.
WAA-8: The CE Router MUST set its DHCPv6 SOL_MAX_RT parameter to WAA-8: The CE router must support the SOL_MAX_RT option
3600 by default. When the CE Router receives the DHCPv6 [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the
SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-solmaxrt-update] in SOL_MAX_RT option in an ORO.
a received DHCPv6 Advertise or Reply message it sets its
internal SOL_MAX_RT 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.
WAA-10: The IPv6 CE router SHOULD implement the Information Refresh WAA-10: The IPv6 CE router SHOULD implement the Information Refresh
Time option and associated client behavior as specified in Time option and associated client behavior as specified in
[RFC4242]. [RFC4242].
skipping to change at page 11, line 37 skipping to change at page 11, line 37
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.
An IPv6 CE router is expected to support an IPv6 end-user network and An IPv6 CE router is expected to support an IPv6 end-user network and
IPv6 hosts that exhibit the following characteristics: IPv6 hosts that exhibit the following characteristics:
1. Link-local addresses may be insufficient for allowing IPv6 1. Link-local addresses may be insufficient for allowing IPv6
applications to communicate with each other in the end-user applications to communicate with each other in the end-user
network. The IPv6 CE router will need to enable this network. The IPv6 CE router will need to enable this
communication by providing globally scoped unicast addresses or communication by providing globally scoped unicast addresses or
ULA's [RFC4193], whether or not WAN connectivity exists. ULAs [RFC4193], whether or not WAN connectivity exists.
2. IPv6 hosts should be capable of using SLAAC and may be capable of 2. IPv6 hosts should be capable of using SLAAC and may be capable of
using DHCPv6 for acquiring their addresses. using DHCPv6 for acquiring their addresses.
3. IPv6 hosts may use DHCPv6 for other configuration information, 3. IPv6 hosts may use DHCPv6 for other configuration information,
such as the DNS_SERVERS option for acquiring DNS information. such as the DNS_SERVERS option for acquiring DNS information.
Unless otherwise specified, the following requirements apply to the Unless otherwise specified, the following requirements apply to the
IPv6 CE router's LAN interfaces only. IPv6 CE router's LAN interfaces only.
skipping to change at page 12, line 45 skipping to change at page 12, line 45
independent of having or not having IPv6 connectivity on the independent of having or not having IPv6 connectivity on the
WAN interface. WAN interface.
L-4: An IPv6 CE router MUST NOT advertise itself as a default L-4: An IPv6 CE router MUST NOT advertise itself as a default
router with a Router Lifetime [RFC4861] greater than zero if router with a Router Lifetime [RFC4861] greater than zero if
it has no prefixes configured or delegated to it. it has no prefixes configured or delegated to it.
L-5: The IPv6 CE router MUST make each LAN interface an advertising L-5: The IPv6 CE router MUST make each LAN interface an advertising
interface according to [RFC4861]. interface according to [RFC4861].
L-6: In Router Advertisement messages, the Prefix Information L-6: In Router Advertisement messages ([RFC4861]), the Prefix
option's A and L flags MUST be set to 1 by default. Information option's A and L flags MUST be set to 1 by
default.
L-7: The A and L flags' settings SHOULD be user-configurable. L-7: The A and L flags' ([RFC4861]) settings SHOULD be user-
configurable.
L-8: The IPv6 CE router MUST support a DHCPv6 server capable of L-8: The IPv6 CE router MUST support a DHCPv6 server capable of
IPv6 address assignment according to [RFC3315] OR a stateless IPv6 address assignment according to [RFC3315] OR a stateless
DHCPv6 server according to [RFC3736] on its LAN interfaces. DHCPv6 server according to [RFC3736] on its LAN interfaces.
L-9: Unless the IPv6 CE router is configured to support the DHCPv6 L-9: Unless the IPv6 CE router is configured to support the DHCPv6
IA_NA option, it SHOULD set the M flag to 0 and the O flag to IA_NA option, it SHOULD set the M flag to 0 and the O flag to
1 in its Router Advertisement messages [RFC4861]. 1 in its Router Advertisement messages [RFC4861].
L-10: The IPv6 CE router MUST support providing DNS information in L-10: The IPv6 CE router MUST support providing DNS information in
the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646].
L-11: The IPv6 CE router MUST support providing DNS information in L-11: The IPv6 CE router MUST support providing DNS information in
the Router Advertisement Recursive DNS Server (RDNSS) and the Router Advertisement Recursive DNS Server (RDNSS) and DNS
DNSSL options. Search List options. Both options are specified in [RFC6106].
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
skipping to change at page 14, line 35 skipping to change at page 14, line 35
Relay. In effect, this requirement removes the "direct Relay. In effect, this requirement removes the "direct
connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. connect to 6rd" route defined in Section 7.1.1 of [RFC5969].
6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to 6RD-4: A CE router MUST allow 6rd and native IPv6 WAN interfaces to
be active alone as well as simultaneously in order to support be active alone as well as simultaneously in order to support
coexistence of the two technologies during an incremental coexistence of the two technologies during an incremental
migration period such as a migration from 6rd to native IPv6. migration period such as a migration from 6rd to native IPv6.
6RD-5: Each packet sent on a 6rd or native WAN interface MUST be 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the directed such that its source IP address is derived from the
delegated prefix associated with the upstream network the WAN delegated prefix associated with the particular interface
interface is connected to [Section 4.3 [RFC3704]]. from which the packet is being sent[Section 4.3 [RFC3704]].
6RD-6: The CE router MUST allow different as well as identical 6RD-6: The CE router MUST allow different as well as identical
delegated prefixes to be configured via each (6rd or native) delegated prefixes to be configured via each (6rd or native)
WAN interface. WAN interface.
6RD-7: In the event that forwarding rules produce a tie between 6rd 6RD-7: In the event that forwarding rules produce a tie between 6rd
and native IPv6, by default, the IPv6 CE Router MUST prefer and native IPv6, by default, the IPv6 CE Router MUST prefer
native IPv6. native IPv6.
4.4.2. Dual-Stack Lite (DS-Lite) 4.4.2. Dual-Stack Lite (DS-Lite)
skipping to change at page 15, line 18 skipping to change at page 15, line 18
WAN interface, and not encapsulated in another tunnel. WAN interface, and not encapsulated in another tunnel.
The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS- The IPv6 CE Router SHOULD implement DS-Lite functionality. If DS-
Lite is supported, it MUST be implemented according to [RFC6333]. Lite is supported, it MUST be implemented according to [RFC6333].
This document takes no position on simultaneous operation of Dual- This document takes no position on simultaneous operation of Dual-
Stack Lite and native IPv4. The following CE Router requirements Stack Lite and native IPv4. The following CE Router requirements
also apply: also apply:
WAN requirements: WAN requirements:
DLW-1: The CE Router MUST support DS-Lite via the DS-Lite DHCPv6 DLW-1: The CE Router MUST support configuration of DS-Lite via the
option [RFC6334]. The IPv6 CE Router MAY use other DS-Lite DHCPv6 option [RFC6334]. The IPv6 CE Router MAY use
mechanisms to configure DS-Lite parameters. Such mechanisms other mechanisms to configure DS-Lite parameters. Such
are outside the scope of this document. mechanisms are outside the scope of this document.
DLW-2: 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-3: 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.
4.5. Security Considerations 4.5. Security Considerations
skipping to change at page 16, line 6 skipping to change at page 16, line 6
Security requirements: Security requirements:
S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular,
the IPv6 CE router SHOULD support functionality sufficient for the IPv6 CE router SHOULD support functionality sufficient for
implementing the set of recommendations in [RFC6092], implementing the set of recommendations in [RFC6092],
Section 4. This document takes no position on whether such Section 4. This document takes no position on whether such
functionality is enabled by default or mechanisms by which functionality is enabled by default or mechanisms by which
users would configure it. users would configure it.
S-2: The IPv6 CE router SHOULD support ingress filtering in S-2: The IPv6 CE router SHOULD support ingress filtering in
accordance with BCP 38 [RFC2827]. accordance with BCP 38 [RFC2827]. Note that this requirement
was downgraded from a MUST from RFC 6204 due to the difficulty
of implementation in the CE router and the feature's redundancy
with upstream router ingress filtering.
S-3: If the IPv6 CE router firewall is configured to filter incoming S-3: If the IPv6 CE router firewall is configured to filter incoming
tunneled data, the firewall SHOULD provide the capability to tunneled data, the firewall SHOULD provide the capability to
filter decapsulated packets from a tunnel. filter decapsulated packets from a tunnel.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgements 6. Acknowledgements
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
guidance and feedback: guidance and feedback:
Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott Mikael Abrahamsson, Tore Anderson, Merete Asak, Rajiv Asati, Scott
Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos Beuker, Mohamed Boucadair, Rex Bullinger, Brian Carpenter, Tassos
Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Chatzithomaoglou, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering,
Alain Durand, Katsunori Fukuoka, Tony Hain, Thomas Herbst, Ray Alain Durand, Katsunori Fukuoka, Brian Haberman, Tony Hain, Thomas
Hunter, Kevin Johns, Erik Kline, Stephen Kramer, Victor Kuarsingh, Herbst, Ray Hunter, Kevin Johns, Joel Jaeggli, Erik Kline, Stephen
Francois-Xavier Le Bail, Arifumi Matsumoto, David Miles, Shin Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto,
Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos Pignataro, John David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery,
Pomeroy, Antonio Querubin, Daniel Roesen, Hiroki Sato, Teemu Carlos Pignataro, John Pomeroy, Antonio Querubin, Daniel Roesen,
Savolainen, Matt Schmitt, David Thaler, Mark Townsley, Bernie Volz, Hiroki Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark
Dan Wing, James Woodyatt, Carl Wuyts, and Cor Zwart. Townsley, Sean Turner, Bernie Volz, Dan Wing, Timothy Winters, James
Woodyatt, Carl Wuyts, and Cor Zwart.
This document is based in part on CableLabs' eRouter specification. This document is based in part on CableLabs' eRouter specification.
The authors wish to acknowledge the additional contributors from the The authors wish to acknowledge the additional contributors from the
eRouter team: eRouter team:
Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas,
Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego
Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur
Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan
Torbet, and Greg White. Torbet, and Greg White.
7. Contributors 7. Contributors
The following people have participated as co-authors or provided The following people have participated as co-authors or provided
substantial contributions to this document: Ralph Droms, Kirk substantial contributions to this document: Ralph Droms, Kirk
Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay,
Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Yiu Lee, John Jason Brzozowski, and Heather Kirksey. Thanks to Ole
Troan for editorship in the original RFC 6204 document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.droms-dhc-dhcpv6-solmaxrt-update] [I-D.droms-dhc-dhcpv6-solmaxrt-update]
Droms, R., "Modification to Default Value of SOL_MAX_RT", Droms, R., "Modification to Default Value of SOL_MAX_RT",
draft-droms-dhc-dhcpv6-solmaxrt-update-02 (work in draft-droms-dhc-dhcpv6-solmaxrt-update-03 (work in
progress), January 2012. progress), August 2012.
[I-D.ietf-dhc-pd-exclude] [I-D.ietf-dhc-pd-exclude]
Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", draft-ietf-dhc-pd-exclude-04 (work in Delegation", draft-ietf-dhc-pd-exclude-04 (work in
progress), December 2011. progress), December 2011.
[I-D.ietf-pcp-base] [I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-24 (work in progress), March 2012. draft-ietf-pcp-base-26 (work in progress), June 2012.
[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.
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 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", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. 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:
skipping to change at page 19, line 26 skipping to change at page 19, line 28
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011. Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011. RFC 6334, August 2011.
skipping to change at page 20, line 17 skipping to change at page 20, line 22
[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. Changes from RFC 6204 Appendix A. Changes from RFC 6204
1. Added IP transition technologies available in RFC form. 1. Added IP transition technologies available in RFC form.
2. Changed bullet G-5 to augment the condition of losing IPv6 2. Changed requirement G-5 to augment the condition of losing IPv6
default router(s) with loss of connectivity. default router(s) with loss of connectivity.
3. Removed bullet WAA-7 due to not reaching consensus by various 3. Removed requirement WAA-7 due to not reaching consensus by
service provider standards bodies. The removal of text does not various service provider standards bodies. The removal of text
remove any critical functionality from the CE specification. does not remove any critical functionality from the CE
specification.
4. Changed bullet WAA-8 to qualify WAN behavior only if not 4. Changed requirement 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 without conflicting with profile can mandate DHCPv6 numbered WAN without conflicting with
this document. this document.
5. Changed the WPD-2 bullet from MUST be configurable to SHOULD be 5. Changed the WPD-2 requirement from MUST be configurable to
configurable. SHOULD be configurable.
6. Changed bullet WPD-4 for a default behavior without compromising 6. Changed requirement WPD-4 for a default behavior without
any prior specification of the CE device. The change was needed compromising any prior specification of the CE device. The
by a specific layer 1 deployment which wanted to specify a MUST change was needed by a specific layer 2 deployment which wanted
for DHCPv6 in their layer 1 profile and not conflict with this to specify a MUST for DHCPv6 in their layer 2 profile and not
document. conflict with this document.
7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5 7. Changed requirement WPD-7 to qualify text for DHCPv6. Removed
and WPD-5 because the text does not have consensus from the IETF W-5 and WPD-5 because the text does not have consensus from the
DHC Working Group for what the final solution related to the IETF DHC Working Group for what the final solution related to
removed bullets will be. the removed requirements will be.
8. 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.
9. Changed bullet L-11 from SHOULD provide DNS options in the RA to 9. Changed requirement L-11 from SHOULD provide DNS options in the
MUST provide DNS option in the RA. RA to MUST provide DNS option in the RA.
10. New bullet added to the Security Considerations section due to 10. New requirement added to the Security Considerations section due
addition of transition technology. The CE router filters to addition of transition technology. The CE router filters
decapsulated 6rd data. decapsulated 6rd data.
11. Minor change involved changing ICMP to ICMPv6. 11. Minor change involved changing ICMP to ICMPv6.
12. Added PCP client requirement for the WAN. 12. Added PCP client requirement for the WAN.
13. Added a requirement for the DHCPv6 pd-exclude option. 13. Added a requirement for the DHCPv6 pd-exclude option.
Authors' Addresses Authors' Addresses
 End of changes. 30 change blocks. 
63 lines changed or deleted 71 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/