draft-ietf-v6ops-6204bis-06.txt   draft-ietf-v6ops-6204bis-07.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: September 7, 2012 CableLabs Expires: September 9, 2012 CableLabs
B. Stark B. Stark
AT&T AT&T
O. Troan, Ed. O. Troan, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
March 6, 2012 March 8, 2012
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-06 draft-ietf-v6ops-6204bis-07
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 42 skipping to change at page 1, line 42
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 September 7, 2012. This Internet-Draft will expire on September 9, 2012.
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 2, line 30 skipping to change at page 2, line 30
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.5. Security Considerations . . . . . . . . . . . . . . . . . 14 4.5. Security Considerations . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19 Appendix A. Changes from RFC 6204 . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
explicitly addressed to itself. The IPv6 explicitly addressed to itself. The IPv6
CE router connects the end-user network to CE router connects the end-user network to
a service provider network. a service provider network.
IPv6 Host any device implementing an IPv6 stack IPv6 Host any device implementing an IPv6 stack
receiving IPv6 connectivity through the receiving IPv6 connectivity through the
IPv6 CE router. IPv6 CE router.
LAN Interface an IPv6 CE router's attachment to a link in LAN Interface an IPv6 CE router's attachment to a link in
the end-user network. Examples are the end-user network. Examples are
Ethernets (simple or bridged), 802.11 Ethernet (simple or bridged), 802.11
wireless, or other LAN technologies. An wireless, or other LAN technologies. An
IPv6 CE router may have one or more IPv6 CE router may have one or more
network-layer LAN interfaces. network-layer LAN interfaces.
Service Provider an entity that provides access to the Service Provider an entity that provides access to the
Internet. In this document, a service Internet. In this document, a service
provider specifically offers Internet provider specifically offers Internet
access using IPv6, and may also offer IPv4 access using IPv6, and may also offer IPv4
Internet access. The service provider can Internet access. The service provider can
provide such access over a variety of provide such access over a variety of
skipping to change at page 6, line 23 skipping to change at page 6, line 23
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 (ULAs) [RFC4193] are used link. Unique Local IPv6 Unicast Addresses (ULA's) [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 8, line 50 skipping to change at page 8, line 50
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 (NCPs) MUST be logical channel, the Network Control Protocols (NCP's) MUST
treated as independent of each other and start and terminate be treated as independent of each other and start and
independently. terminate 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 Section WAA-2: The IPv6 CE router MUST follow the recommendations in Section
4 of [RFC5942], and in particular the handling of the L flag 4 of [RFC5942], and in particular the handling of the L flag
in the Router Advertisement Prefix Information option. in the Router Advertisement Prefix Information option.
skipping to change at page 11, line 19 skipping to change at page 11, line 19
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
ULAs [RFC4193], whether or not WAN connectivity exists. ULA's [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 15, line 19 skipping to change at page 15, line 19
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].
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. Acknowledgements 5. IANA Considerations
This document has no actions for IANA.
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, Scott Beuker, Mohamed Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker, Mohamed
Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou, Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou,
Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand, Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand,
Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline, Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline,
Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi
Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael
skipping to change at page 15, line 44 skipping to change at page 16, line 5
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.
6. 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.
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.droms-dhc-dhcpv6-maxsolrt-update] [I-D.droms-dhc-dhcpv6-maxsolrt-update]
Droms, R., "Modification to Default Value of MAX_SOL_RT", Droms, R., "Modification to Default Value of MAX_SOL_RT",
draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in
progress), November 2011. progress), November 2011.
[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]
Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
Penno, "Port Control Protocol (PCP)", Penno, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-23 (work in progress), February 2012. draft-ietf-pcp-base-23 (work in progress), February 2012.
[RFC1102] Clark, D., "Policy routing in Internet protocols",
RFC 1102, May 1989.
[RFC1104] Braun, H., "Models of policy based routing", RFC 1104,
June 1989.
[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
E. Lear, "Address Allocation for Private Internets",
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", [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:
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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
skipping to change at page 18, line 29 skipping to change at page 18, line 25
[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.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 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.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
7.2. Informative References 8.2. Informative References
[MULTIHOMING-WITHOUT-NAT] [MULTIHOMING-WITHOUT-NAT]
Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
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]
skipping to change at page 19, line 28 skipping to change at page 19, line 18
2. Changed bullet G-5 to augment the condition of losing IPv6 2. 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.
3. 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.
4. 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 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 bullet from MUST be configurable to SHOULD be
configurable. configurable.
6. 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.
7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5 7. Changed bullet WPD-7 to qualify text for DHCPv6. Removed W-5
and WPD-5 beause the text does not have consensus from the IETF and WPD-5 because the text does not have consensus from the IETF
DHC Working Group for what the final solution related to the DHC Working Group for what the final solution related to the
removed bullets is. removed bullets 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 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.
10. New bullet added to the Security Considerations section due to 10. New bullet added to the Security Considerations section due to
 End of changes. 21 change blocks. 
44 lines changed or deleted 28 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/