draft-ietf-v6ops-6204bis-00.txt   draft-ietf-v6ops-6204bis-01.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. Updates: 6204 (if approved) Cisco Systems, Inc.
Intended status: Standards Track C. Donley Intended status: Standards Track C. Donley
Expires: April 9, 2012 CableLabs Expires: April 20, 2012 CableLabs
B. Stark B. Stark
ATT AT&T
O. Troan, Ed. O. Troan, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 7, 2011 October 18, 2011
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-00 draft-ietf-v6ops-6204bis-01
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. of IPv6 hosts attached to it. The document also covers IP transition
technologies and transition technologies coexistence. Two transition
technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
the document.
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 April 9, 2012. This Internet-Draft will expire on April 20, 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 21 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 8
4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 10 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(DS)-Lite . . . . . . . . . . . . . . . . . 14 4.4.2. Dual-Stack(DS)-Lite . . . . . . . . . . . . . . . . . 14
4.4.3. Transition Technologies Coexistence . . . . . . . . . 15 4.4.3. Transition Technologies Coexistence . . . . . . . . . 15
4.5. Security Considerations . . . . . . . . . . . . . . . . . 15 4.5. Security Considerations . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 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
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
technologies coexistence. Two transition technologies in 6rd
[RFC5969] and DS-Lite [RFC6333] are covered in the document. At the
time of writing this document these were the only two transition
technologies available in RFC form to be included 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
router that connect IPv6 hosts. router that connect IPv6 hosts.
skipping to change at page 7, line 21 skipping to change at page 7, line 26
its routing table to decide to which interface it should send the its routing table to decide to which interface it should send the
packet. packet.
In this role, the IPv6 CE router is responsible for ensuring that In this role, the IPv6 CE router is responsible for ensuring that
traffic using its ULA addressing does not go out the WAN interface, traffic using its ULA addressing does not go out the WAN interface,
and does not originate from the WAN interface. and does not originate from the WAN interface.
G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node
Requirements [RFC4294] specification. Requirements [RFC4294] specification.
G-2: The IPv6 CE router MUST implement ICMP according to [RFC4443]. G-2: The IPv6 CE router MUST implement ICMPv6 according to
In particular, point-to-point links MUST be handled as [RFC4443]. In particular, point-to-point links MUST be handled
described in Section 3.1 of [RFC4443]. as described in Section 3.1 of [RFC4443].
G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
its LAN interface(s) and its WAN interface until the router has its LAN interface(s) and its WAN interface until the router has
successfully completed the IPv6 address acquisition process. successfully completed the IPv6 address acquisition process.
G-4: By default, an IPv6 CE router that has no default router(s) on G-4: By default, an IPv6 CE router that has no default router(s) on
its WAN interface MUST NOT advertise itself as an IPv6 default its WAN interface MUST NOT advertise itself as an IPv6 default
router on its LAN interfaces. That is, the "Router Lifetime" router on its LAN interfaces. That is, the "Router Lifetime"
field is set to zero in all Router Advertisement messages it field is set to zero in all Router Advertisement messages it
originates [RFC4861]. originates [RFC4861].
skipping to change at page 13, line 5 skipping to change at page 13, line 14
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 the lower of the current Valid Lifetime and two
hours (which must be decremented in real time) in a Router hours (which must be decremented in real time) in a Router
Advertisement message as described in Section 5.5.3, (e) of Advertisement message as described in Section 5.5.3, (e) of
[RFC4862]. [RFC4862].
L-14: The IPv6 CE router MUST send an ICMP 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 The IPv6 CE Router can be used to offer IPv6 service to a LAN, even
when the WAN access network only supports IPv4. One technology that when the WAN access network only supports IPv4. One technology that
skipping to change at page 13, line 40 skipping to change at page 13, line 49
Interface and 6rd CE functionality as specified in [RFC5969]. Interface and 6rd CE functionality as specified in [RFC5969].
6RD-2: If the IPv6 CE Router implements 6rd CE functionality, it 6RD-2: If the IPv6 CE Router implements 6rd CE functionality, it
MUST support user-entered configuration and using the 6rd MUST support user-entered configuration and using the 6rd
DHCPv4 Option (212) for 6rd configuration. The IPv6 CE DHCPv4 Option (212) for 6rd configuration. The IPv6 CE
Router MAY use other mechanisms to configure 6rd parameters. Router MAY use other mechanisms to configure 6rd parameters.
Such mechanisms are outside the scope of this document. Such mechanisms are outside the scope of this document.
6RD-3: If the CE router implements 6rd functionality, it MUST allow 6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether other destinations within the same Border Relay, or whether IPv6 traffic to other destinations
6rd domain are routed directly to those destinations. The CE within the same 6rd domain are routed directly to those
router MAY use other mechanisms to configure this. Such destinations. The CE router MAY use other mechanisms to
mechanisms are outside the scope of this document. configure this. Such mechanisms are outside the scope of
this document.
6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data 6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data
MUST NOT be sent on any 6rd tunnel. MUST NOT be sent on any 6rd tunnel.
6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite 6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite
([RFC6333]) tunnel. ([RFC6333]) tunnel.
4.4.2. Dual-Stack(DS)-Lite 4.4.2. Dual-Stack(DS)-Lite
Even as users migrate from IPv4 to IPv6 addressing, a significant Even as users migrate from IPv4 to IPv6 addressing, a significant
skipping to change at page 14, line 21 skipping to change at page 14, line 28
allow customers to continue to access content and resources using allow customers to continue to access content and resources using
IPv4 even after the last IPv4 allocations have been fully depleted. IPv4 even after the last IPv4 allocations have been fully depleted.
One technology that can be used for IPv4 address extension is DS- One technology that can be used for IPv4 address extension is DS-
Lite. Lite.
DS-Lite enables a Service Provider to share IPv4 addresses among DS-Lite enables a Service Provider to share IPv4 addresses among
multiple customers by combining two well-known technologies: IP in IP multiple customers by combining two well-known technologies: IP in IP
(IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically, (IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically,
Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
the IPv6 CE Router and sends it to a Service Provider Address Family the IPv6 CE Router and sends it to a Service Provider Address Family
Translation Router (AFTR). Configuration of the IPv6 CE Router to Transition Router (AFTR). Configuration of the IPv6 CE Router to
support IPv4 LAN traffic is outside the scope of this document. support IPv4 LAN traffic is outside the scope of this document.
The IPv6 CE Router SHOULD implement DS-Lite functionality as The IPv6 CE Router SHOULD implement DS-Lite functionality as
specified in [RFC6333]. specified in [RFC6333].
WAN requirements: WAN requirements:
DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE
Router supports DS-Lite functionality, the CE Router WAN Router supports DS-Lite functionality, the CE Router WAN
interface MUST implement a B4 Interface as specified in interface MUST implement a B4 Interface as specified in
[RFC6333]. [RFC6333].
DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the
CE Router MUST support using a DS-Lite DHCPv6 option CE Router MUST support using a DS-Lite DHCPv6 option
[I-D.ietf-softwire-ds-lite-tunnel-option] to configure the [RFC6334] to configure the DS-Lite tunnel. The IPv6 CE
DS-Lite tunnel. The IPv6 CE Router MAY use other mechanisms Router MAY use other mechanisms to configure DS-Lite
to configure DS-Lite parameters. Such mechanisms are outside parameters. Such mechanisms are outside the scope of this
the scope of this document. document.
DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address DLW-3: 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 a public IPv4 DLW-4: If the IPv6 CE Router is configured with a public IPv4
address on its WAN interface, where public IPv4 address is address on its WAN interface, where public IPv4 address is
defined as any address which is not in the private IP address defined as any address which is not in the private IP address
space specified in [RFC1918] and also not in the reserved IP space specified in [RFC1918] and also not in the reserved IP
address space specified in [RFC6333], then the IPv6 CE Router address space specified in [RFC6333], then the IPv6 CE Router
MUST disable the DS-Lite B4 element. MUST disable the DS-Lite B4 element.
DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast
data MUST NOT be sent on any DS-Lite tunnel. data MUST NOT be sent on any DS-Lite tunnel.
DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD
tunnel. tunnel.
4.4.3. Transition Technologies Coexistence 4.4.3. Transition Technologies Coexistence
Run the following four in parallel to provision CPE router 1. Initiate native IPv4/IPv6 provisioning (e.g. via DHCP)
connectivity to the Service Provider: simultaneously.
1. Initiate IPv4 address acquisition. 2. After IPv4 provisioning completes, if 6rd parameters are obtained
from the DHCPv4 transaction or configured on the device, initiate
6rd.
2. Initiate IPv6 address acquisition as specified by [RFC6204]. 3. After IPv6 provisioning completes, if DS-Lite parameters are
obtained from the DHCPv6 transaction or configured on the device,
initiate DS-Lite.
3. If 6rd is provisioned, initiate 6rd. 4. Routes over the DS-Lite tunnel always have a higher
administrative distance than native IPv4 routes.
4. If DS-Lite is provisioned, initiate DS-Lite. 5. Routing between 6rd and native IPv6 uses Policy Based Routing
(PBR). PBR is specified in [RFC1102] and [RFC1104]. A small
subset of PBR MUST be implemented by the device. The small
subset matches source IPv6 prefix to route packets over 6rd or
native IPv6. With 6rd and native IPv6 upstream links, the hosts
in the home LAN also need to be provided a Source Address
Selection (SAS) Policy Table specified in [RFC3484]. Both the
SAS Policy Table and PBR can be automatically configured to
prefer native IPv6 connectivity instead of 6rd if both are
available. One way of distributing a SAS Policy Table is
described in [SAS-POLICY-TABLE].
The default route for IPv6 through the native physical interface has During a sunsetting activity such as deprecating 6rd and moving to
preference over the 6rd tunnel interface. The default route for IPv4 native IPv6, due to the two hours rule specified in [RFC4862], the
through the native physical interface has preference over the DS-Lite 6rd and the native IPv6 prefix will coexist in the home network. The
tunnel interface. 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
Valid 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 16, line 5 skipping to change at page 16, line 30
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 MUST support ingress filtering in accordance S-2: The IPv6 CE router MUST support ingress filtering in accordance
with BCP 38 [RFC2827]. with BCP 38 [RFC2827].
S-3: When 6rd is enabled on the device, a firewall SHOULD provide
the capability to filter decapsulated packets from the 6rd
tunnel.
5. Acknowledgements 5. 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, Lorenzo Colitti, Remi Boucadair, Rex Bullinger, Brian Carpenter, Tassos Chatzithomaoglou,
Denis-Courmont, Gert Doering, Alain Durand, Katsunori Fukuoka, Tony Lorenzo Colitti, Remi Denis-Courmont, Gert Doering, Alain Durand,
Hain, Thomas Herbst, Kevin Johns, Erik Kline, Stephen Kramer, Victor Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, Erik Kline,
Kuarsingh, Francois-Xavier Le Bail, Arifumi Matsumoto, David Miles, Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, Arifumi
Shin Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos Pignataro, Matsumoto, David Miles, Shin Miyakawa, Jean-Francois Mule, Michael
John Pomeroy, Antonio Querubin, Hiroki Sato, Teemu Savolainen, Matt Newbery, Carlos Pignataro, John Pomeroy, Antonio Querubin, Hiroki
Schmitt, David Thaler, Mark Townsley, Bernie Volz, Dan Wing, James Sato, Teemu Savolainen, Matt Schmitt, David Thaler, Mark Townsley,
Woodyatt, and Cor Zwart. Bernie Volz, Dan Wing, James Woodyatt, 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.
skipping to change at page 16, line 41 skipping to change at page 17, line 23
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 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-softwire-ds-lite-tunnel-option] [RFC1102] Clark, D., "Policy routing in Internet protocols",
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration RFC 1102, May 1989.
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-10 (work in [RFC1104] Braun, H., "Models of policy based routing", RFC 1104,
progress), March 2011. 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 [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.
skipping to change at page 17, line 21 skipping to change at page 18, line 5
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 19, line 9 skipping to change at page 19, line 42
RFC 6106, November 2010. RFC 6106, November 2010.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011. 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
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, August 2011.
7.2. Informative References 7.2. Informative References
[HAPPY-EYEBALLS] [HAPPY-EYEBALLS]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
Towards Success with Dual-Stack Hosts", Work in Progress, Towards Success with Dual-Stack Hosts", Work in Progress,
March 2011. March 2011.
[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.
[SAS-POLICY-TABLE]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6", Work
in Progress, June 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/>.
Authors' Addresses Authors' Addresses
Hemant Singh Hemant Singh
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
skipping to change at page 20, line 13 skipping to change at page 21, line 13
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Chris Donley Chris Donley
CableLabs CableLabs
858 Coal Creek Circle 858 Coal Creek Circle
Louisville, CO 80027 Louisville, CO 80027
USA USA
EMail: c.donley@cablelabs.com EMail: c.donley@cablelabs.com
Barbara Stark Barbara Stark
ATT AT&T
725 W Peachtree St. 725 W Peachtree St.
Atlanta, GA 30308 Atlanta, GA 30308
USA USA
EMail: barbara.stark@att.com EMail: barbara.stark@att.com
Ole Troan (editor) Ole Troan (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Telemarksvingen 20 Telemarksvingen 20
N-0655 OSLO, N-0655 OSLO,
 End of changes. 29 change blocks. 
50 lines changed or deleted 97 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/