draft-ietf-v6ops-6204bis-02.txt   draft-ietf-v6ops-6204bis-03.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: Informational C. Donley Intended status: Informational C. Donley
Expires: May 3, 2012 CableLabs Expires: May 25, 2012 CableLabs
B. Stark B. Stark
AT&T AT&T
O. Troan, Ed. O. Troan, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 31, 2011 November 22, 2011
Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-6204bis-02 draft-ietf-v6ops-6204bis-03
Abstract Abstract
This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses
on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning
of IPv6 hosts attached to it. The document also covers IP transition of IPv6 hosts attached to it. The document also covers IP transition
technologies and transition technologies coexistence. Two transition technologies and transition technologies coexistence. Two transition
technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
the document. the document.
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 May 3, 2012. This Internet-Draft will expire on May 25, 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 24 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 . . . . . . . . . . . . . . . . . . 8 4.2. WAN-Side Configuration . . . . . . . . . . . . . . . . . . 7
4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11 4.3. LAN-Side Configuration . . . . . . . . . . . . . . . . . . 11
4.4. Transition Technologies Support . . . . . . . . . . . . . 13 4.4. Transition Technologies Support . . . . . . . . . . . . . 13
4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. Dual-Stack Lite(DS-Lite) . . . . . . . . . . . . . . . 14 4.4.2. Dual-Stack Lite(DS-Lite) . . . . . . . . . . . . . . . 14
4.4.3. Transition Technologies Coexistence . . . . . . . . . 15 4.4.3. Transition Technologies Coexistence . . . . . . . . . 15
4.5. Security Considerations . . . . . . . . . . . . . . . . . 16 4.5. Security Considerations . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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 (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.
A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4
and IPv6 topologies may not be congruent, and different addresses may
have different reachability, e.g., ULAs. A host stack has to be able
to quickly fail over and try a different source address and
destination address pair if communication fails, as outlined in
[HAPPY-EYEBALLS].
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
not connected to the IPv6 network on its WAN interface. To support not connected to the IPv6 network on its WAN interface. To support
host implementations that do not handle multihoming in a multi-prefix host implementations that do not handle multihoming in a multi-prefix
environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not,
as detailed in the requirements below, advertise itself as a default as detailed in the requirements below, advertise itself as a default
router on the LAN interface(s) when it does not have IPv6 router on the LAN interface(s) when it does not have IPv6
connectivity on the WAN interface or when it is not provisioned with connectivity on the WAN interface or when it is not provisioned with
IPv6 addresses. For local IPv6 communication, the mechanisms IPv6 addresses. For local IPv6 communication, the mechanisms
specified in [RFC4191] are used. specified in [RFC4191] are used.
ULA addressing is useful where the IPv6 CE router has multiple LAN ULA addressing is useful where the IPv6 CE router has multiple LAN
interfaces with hosts that need to communicate with each other. If interfaces with hosts that need to communicate with each other. If
the IPv6 CE router has only a single LAN interface (IPv6 link), then the IPv6 CE router has only a single LAN interface (IPv6 link), then
link-local addressing can be used instead. link-local addressing can be used instead.
In the event that more than one IPv6 CE router is present on the LAN, In the event that more than one IPv6 CE router is present on the LAN,
then coexistence with IPv4 requires all of them to conform to these then coexistence with IPv4 requires any IPv6 CE router(s) on the LAN
recommendations, especially requirements ULA-5 and L-4 below. to conform to these recommendations, especially requirements ULA-5
and L-4 below.
4. Requirements 4. Requirements
4.1. General Requirements 4.1. General Requirements
The IPv6 CE router is responsible for implementing IPv6 routing; that The IPv6 CE router is responsible for implementing IPv6 routing; that
is, the IPv6 CE router must look up the IPv6 destination address in is, the IPv6 CE router must look up the IPv6 destination address in
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.
skipping to change at page 9, line 28 skipping to change at page 9, line 17
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.
WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client
behavior. behavior.
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]. DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to
support the DNS Search List DNSSL option as specfied in
[RFC6106].
WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network
Time Protocol (SNTP) option [RFC4075] and the Information Time Protocol (SNTP) option [RFC4075] and the Information
Refresh Time option [RFC4242]. Refresh Time option [RFC4242].
WAA-6: If the IPv6 CE router receives a Router Advertisement message WAA-6: If the IPv6 CE router receives a Router Advertisement message
(described in [RFC4861]) with the M flag set to 1, the IPv6 (described in [RFC4861]) with the M flag set to 1, the IPv6
CE router MUST do DHCPv6 address assignment (request an IA_NA CE router MUST do DHCPv6 address assignment (request an IA_NA
option). option).
WAA-7: If the IPv6 CE router does not acquire global IPv6 WAA-7: If the IPv6 CE router does not acquire global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create address(es) from either SLAAC or DHCPv6, then it MUST create
global IPv6 address(es) from its delegated prefix(es) and global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network configure those on one of its internal virtual network
interfaces unless configured to require a global IPv6 address interfaces unless configured to require a global IPv6 address
on the WAN interface. on the WAN interface.
WAA-8: The IPv6 CE router MUST set SOL_MAX_RT (specified by WAA-8: The CE Router MUST parse the DHCPv6 SOL_MAX_RT option
[RFC3315]) to 7200 seconds. [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
Advertise or Reply message and set 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.
Prefix delegation requirements: Prefix delegation requirements:
WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation
skipping to change at page 12, line 43 skipping to change at page 12, line 43
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 DNS the Router Advertisement Recursive DNS Server (RDNSS) and
Search List (DNSSL) options as specified in [RFC6106]. DNSSL options.
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 15, line 11 skipping to change at page 15, line 11
Router MAY use other mechanisms to configure DS-Lite Router MAY use other mechanisms to configure DS-Lite
parameters. Such mechanisms are outside the scope of this parameters. Such mechanisms are outside 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 [RFC5735] and also not in the reserved IP space specified in [RFC5735], then the IPv6 CE Router SHOULD
address space specified in [RFC6333], then the IPv6 CE Router 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
Supporting transition technologies that may coexist with native Supporting transition technologies that may coexist with native
skipping to change at page 15, line 43 skipping to change at page 15, line 42
3. After IPv6 provisioning completes, if DS-Lite parameters are 3. After IPv6 provisioning completes, if DS-Lite parameters are
obtained from the DHCPv6 transaction or configured on the device, obtained from the DHCPv6 transaction or configured on the device,
initiate DS-Lite. initiate DS-Lite.
4. Routes over the DS-Lite tunnel always have a higher 4. Routes over the DS-Lite tunnel always have a higher
administrative distance than native IPv4 routes. administrative distance than native IPv4 routes.
5. Selection of 6rd tunnel or native IPv6 output interface on the CE 5. Selection of 6rd tunnel or native IPv6 output interface on the CE
router is determined by the source IPv6 address of the packet router is determined by the source IPv6 address of the packet
from a host. from a host, when different prefixes are available over 6rd vs.
native IPv6. If the two interfaces provide the CE router with
the same prefix, then the CE router prefers the native IPv6
interface to the 6rd interface for forwarding traffic out the WAN
when both 6rd and native IPv6 interfaces are active.
6. The CE router messages to the host the use of native IPv6 in 6. The CE router messages to the host the use of native IPv6 in
preference to 6rd. preference to 6rd, in the case where the two interfaces use
different prefixes.
During a sunsetting activity such as deprecating 6rd and moving to During a sunsetting activity such as deprecating 6rd and moving to
native IPv6, the IPv6 CE router MUST immediately advertise the 6rd native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
prefix with a Preferred Lifetime of zero and a Valid Lifetime of the prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
lower of the current Valid Lifetime and two hours (which must be lower of the current Valid Lifetime and two hours (which must be
decremented in real time) in a Router Advertisement message as decremented in real time) in a Router Advertisement message as
described in Section 5.5.3, (e) of [RFC4862]. Due to the two hours described in Section 5.5.3, (e) of [RFC4862]. Due to the two hours
rule specified in [RFC4862], the 6rd and the native IPv6 prefix will rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
coexist in the home network. The two hours rule specified in section coexist in the home network. The two hours rule specified in section
5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node 5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
skipping to change at page 17, line 29 skipping to change at page 17, line 33
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.droms-dhc-dhcpv6-maxsolrt-update]
Droms, R., "Modification to Default Value of MAX_SOL_RT",
draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in
progress), November 2011.
[RFC1102] Clark, D., "Policy routing in Internet protocols", [RFC1102] Clark, D., "Policy routing in Internet protocols",
RFC 1102, May 1989. RFC 1102, May 1989.
[RFC1104] Braun, H., "Models of policy based routing", RFC 1104, [RFC1104] Braun, H., "Models of policy based routing", RFC 1104,
June 1989. 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
skipping to change at page 20, line 8 skipping to change at page 20, line 18
[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.
7.2. Informative References 7.2. Informative References
[HAPPY-EYEBALLS]
Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending
Towards Success with Dual-Stack Hosts", Work in Progress,
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.
[UPnP-IGD] [UPnP-IGD]
UPnP Forum, "Universal Plug and Play (UPnP) Internet UPnP Forum, "Universal Plug and Play (UPnP) Internet
 End of changes. 15 change blocks. 
29 lines changed or deleted 31 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/