draft-ietf-v6ops-ipv6-cpe-router-01.txt   draft-ietf-v6ops-ipv6-cpe-router-02.txt 
Network Working Group H. Singh Internet Engineering Task Force H. Singh
Internet-Draft W. Beebee Internet-Draft W. Beebee
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: February 19, 2010 August 18, 2009 Expires: April 29, 2010 C. Donley
CableLabs
B. Stark
AT&T
O. Troan, Ed.
Cisco Systems, Inc.
October 26, 2009
IPv6 CPE Router Recommendations Requirements for IPv6 Customer Edge Routers
draft-ietf-v6ops-ipv6-cpe-router-01 draft-ietf-v6ops-ipv6-cpe-router-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document recommends IPv6 behavior for Customer Premises This document specifies requirements for an IPv6 Customer Edge (CE)
Equipment (CPE) routers in Internet-enabled homes and small offices. router. Specifically, the current version of this document focuses
The CPE Router may be a standalone device. The CPE Router may also on the provisioning of an IPv6 CE router and the provisioning of IPv6
be embedded in a device such as a cable modem, DSL modem, cellular hosts attached to it.
phone, etc. This document describes the router portion of such a
device. The purpose behind this document is to provide minimal
functionality for interoperability and create consistency in the
customer experience and satisfy customer expectations for the device.
Further, the document also provide some guidance for implementers to
expedite availability of IPv6 CPE router products in the marketplace.
It is expected that standards bodies other than the IETF developing
standards for specific products in this area (e.g. CableLabs
eRouter, Broadband Forum, Home Gateway Initiative, etc.) may
reference this work for basic functionality and provide value-added
or linktype-specific customizations and enhancements which are beyond
the scope of this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Operational Behavior . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Conceptual Configuration Variables . . . . . . . . . . . . 5 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Router Initialization . . . . . . . . . . . . . . . . . . . . 6 3.1. Current IPv4 end-user network architecture . . . . . . . . 4
5. Basic IPv6 Provisioning . . . . . . . . . . . . . . . . . . . 6 3.2. IPv6 end-user network architecture . . . . . . . . . . . . 5
5.1. Construct Link-Local Address (CORE) . . . . . . . . . . . 7 4. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 6
5.2. Process RAs (CORE) . . . . . . . . . . . . . . . . . . . . 7 4.1. WAN side configuration . . . . . . . . . . . . . . . . . . 6
5.3. Acquire IPv6 Address and Other Configuration 4.2. LAN side configuration . . . . . . . . . . . . . . . . . . 8
Parameters (CORE) . . . . . . . . . . . . . . . . . . . . 7 4.3. General requirements . . . . . . . . . . . . . . . . . . . 9
5.3.1. Numbered Model (CORE) . . . . . . . . . . . . . . . . 8 4.4. Security Considerations . . . . . . . . . . . . . . . . . 10
5.3.2. Unnumbered Model (MEDIUM) . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.3. Both Models . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Details for DHCPv6 Address Acquisition (CORE) . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.5. IPv6 Provisioning of Home Devices (CORE) . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
5.5.1. LAN Initialization before WAN Initialization . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5.2. WAN initialization before LAN Initialization . . . . . 11
5.6. IPv6 over PPP . . . . . . . . . . . . . . . . . . . . . . 11
5.7. Stateful DHCPv6 Server (CORE) . . . . . . . . . . . . . . 12
6. CPE Router Behavior in a routed network (MEDIUM) . . . . . . . 12
7. IPv6 Data Forwarding (CORE) . . . . . . . . . . . . . . . . . 12
7.1. IPv6 ND Proxy Behavior (MEDIUM) . . . . . . . . . . . . . 13
7.2. IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . . 14
8. Other IPv6 Features . . . . . . . . . . . . . . . . . . . . . 14
8.1. Path MTU Discovery Support (MEDIUM) . . . . . . . . . . . 14
8.2. Optional RIPng Support (CORE) . . . . . . . . . . . . . . 15
8.3. Automated Tunneling (MEDIUM) . . . . . . . . . . . . . . . 15
8.4. DNS Support (CORE) . . . . . . . . . . . . . . . . . . . . 16
8.5. Quality Of Service(QoS) . . . . . . . . . . . . . . . . . 16
9. IPv4 Support (CORE) . . . . . . . . . . . . . . . . . . . . . 16
10. DEVICE Constants . . . . . . . . . . . . . . . . . . . . . . . 16
11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines IPv6 features for a residential or small office This document defines IPv6 features for a residential or small office
router referred to as a CPE Router. Typically, CPE Router devices router referred to as an IPv6 CE router. Typically these routers
support IPv4, as discussed in the "IPv4 Support" section. Also, this also support IPv4.
document does not go into configuration details for the CPE Router.
A CPE Router is an IPv6 Node and, therefore, MUST follow IPv6 Node
Requirements draft-ietf-6man-node-req-bis-01
[I-D.ietf-6man-node-req-bis].
The document discusses IPv6 implications for the attached Service
Provider network. The document notes that the CPE Router may be
deployed in home in one of two ways. Either the Service Provider or
the home user may manage this device. When the CPE Router is managed
by the Service Provider, the router may need additional management
and routing properties like a new MIB definition and routing
protocols communicating between the CPE Router and the Service
Provider network. The CPE router has one or more WAN interface(s) to
connect to the Service Provider and zero or more LAN interfaces to
the home network devices. In the case of zero LAN interfaces, any
LAN-applicable initialization and behavior is skipped. The WAN
interface is preferred to be Ethernet encapsulated but it may support
other encapsulations such as PPP.
Technologies are labeled as: CORE (widely deployed in the field, many
years of operational experience, one or more standards-track RFC's
exist), MEDIUM (standards-track RFC exists, but is a recent
development and/or has limited deployments. Technologies under
DEVelopment (no standards-track RFC exists and/or has not yet been
deployed) have been moved to a bis(updates) version of this document.
2. Terminology and Abbreviations
Host - this is a personal computer or any other network device in
a home that connects to the Internet via the CPE Router. A more
formal definition of a host exists in the Terminology section of
[RFC2460].
LAN interface(s) - an optional set of network interfaces on the
CPE Router that are used to connect hosts in the home. This set
of ports could be switched, bridged, or routed. If no LAN
interface is present, then there is no need for the CPE router to
provide LAN side services such as DHCPv6 PD or ULA's.
WLAN interface - an optional wireless access point interface on
the CPE Router used to connect wireless hosts in the home in
either managed or ad-hoc modes.
WAN interface - usually a single physical network interface on the
standalone CPE Router that is used to connect the router to the
access network of the Service Provider. When the CPE Router is
embedded in a device that connects to the WAN, this interface is a
logical network interface that bridges the device to the CPE
Router. Some devices which can have an embedded CPE router are: a
cable or DSL modem, or a cellular telephone, etc. A CPE router
with more than one WAN interface will need a more complicated
provisioning and multicast model than is described in this
document.
GRE tunnel - Generic Routing Encapsulation tunnel.
SLAAC - StateLess Address Auto Configuration.
IPTV - Internet Protocol TeleVision.
3. Operational Behavior
The CPE Router is a gateway to the Internet for a home. The router
is also intended to provide home networking functionality. The CPE
Router may have a console or web interface for configuration. This
document defines the core set of features that are supported by the
CPE Router, however individual implementations may include value-
added features such as WLAN capability.
The core set of IPv6 features for the CPE Router includes
provisioning the CPE Router for IPv6, IPv6 data forwarding including
IPv6 multicast, CPE Router provisioning hosts on its LAN
interface(s), firewall, and QoS behavior.
3.1. Conceptual Configuration Variables
The CPE Router maintains such a list of conceptual optional
configuration variables.
1. Loopback interface enable.
2. PPPOE enable.
3. RIPng enable.
4. If DHCPv6 fails, the CPE Router may initiate PPPOE, L2TPv2
tunnel, and 6rd draft-townsley-ipv6-6rd [I-D.townsley-ipv6-6rd]
operation. If 6rd is attempted and fails, then 6to4 [RFC3056]
operation is attempted.
4. Router Initialization
Before the CPE Router is initialized, the device must have IPv6
enabled. The CPE Router SHOULD support the ability to disable its
IPv6 stack. The CPE Router also has the ability to block or forward
IPv6 traffic to and from the router's LAN interface(s). [RFC2669]
includes a MIB definition to block the IPv4 or IPv6 Ethertype in the
upstream or downstream interface(s) of a device such as the CPE
Router. Some portion of this MIB may need to be modified for use
with the CPE Router.
The CPE Router supports at least one of two modes of initialization:
either the LAN interface(s) become operational first or the WAN
interface becomes operational first. More details have been provided
in the Basic IPv6 Provisioning section.
5. Basic IPv6 Provisioning
The CPE Router MUST support at least one of two WAN interface models,
one of which will be active on the CPE Router at any given time. In
the Numbered model, the WAN interface acquires a global unicast
address (GUA) using a combination of SLAAC and stateful DHCPv6 for
IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA) and
IA_PD. IA_PD is acquired using stateful DHCPv6 as described in
[RFC3633]. Assigning a stable global unicast address to a loopback
interface (which can be used as a stable peering point for routing
protocols or to respond to the anycast address) is optional. If
stateful DHCPv6 is not used to obtain other IPv6 configuration, then
stateless DHCPv6 [RFC3736] must be initiated by the WAN interface to
obtain other IPv6 configuration. Further, in the numbered model, we
recommend the CPE Router WAN interface acquire its global IPv6
address using stateful DHCPv6 for administrative control of the
router. Manual configuration may be supported by the CPE router for
IPv6 address configuration of the WAN interface. However, manual
configuration is beyond the scope of this document.
In the Unnumbered model, the WAN interface only constructs a Link- This document specifies how an IPv6 CE router automatically
Local Address, then the WAN interface initiates stateful DHCPv6 for provisions its WAN interface, acquires an address block for
IA_PD. The IA_PD is sub-delegated to the LAN interface(s) and an provisioning of its LAN interfaces and fetches other configuration
optional Loopback interface (or the addresses for the LAN/Loopback information from the service provider network. Automatic
interfaces could come from IA_NAs). Either the Loopback or the LAN provisioning of more complex topology than a single router with
interface can be used to source WAN-facing traffic. Other IPv6 multiple LAN interfaces is out of scope for this document.
configuration information is obtained using stateless DHCPv6.
The CPE Router acquires its IPv6 addresses from the Service Provider See [RFC4779] for a discussion of options available for deploying
along with any other IPv6 configuration any time the WAN interface is IPv6 in service provider access networks.
connected to the Service Provider network. Thereafter the CPE Router
provisions its LAN interface(s) for IPv6 router functionality
including provisioning global IPv6 addresses on the LAN interface(s).
Even if LAN interface(s) have been operational and provisioned
earlier, the global IPv6 configuration of LAN interface(s) is still
required. More details for provisioning the CPE Router are given in
the following sections.
5.1. Construct Link-Local Address (CORE) 1.1. Requirements Language
If an interface of the CPE Router is configured for IPv6, when the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
interface initializes itself, as per [RFC4862], the CPE Router must "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
create a link-local address for the interface. We recommend the CPE document are to be interpreted as described in RFC 2119 [RFC2119].
Router use the EUI-64 identifier as a link-local address for each of
its interfaces. Refer to EUI-64 details in [RFC4291]. Further, as
per [RFC4862], the CPE Router must perform Duplicate Address
Detection (DAD) on all unicast addresses unless a layer 2-specific
document specifies that DupAddrDetectTransmits is zero for that
linktype. If the CPE Router detects a duplicate address assigned to
an interface, the CPE Router must not send IPv6 packets from the
interface.
5.2. Process RAs (CORE) 2. Terminology
The CPE Router must process incoming RAs received on the WAN End-user Network one or more links attached to the IPv6 CE
interface as specified in section 6.3 of [RFC4861]. The CPE Router router that connect IPv6 hosts.
locates routers that reside on the attached WAN link from the
received RAs. With respect to RS behavior, the WAN interface of the
CPE Router acts as a host. Section 4.1 of [RFC4861] states that
hosts MAY send RS's to solicit an RA quickly. The WAN interface(s)
of a CPE Router SHOULD send an RS after link-local address
construction.
5.3. Acquire IPv6 Address and Other Configuration Parameters (CORE) IPv6 Customer Edge router a node intended for home or small office
use which forwards IPv6 packets not explicitly
addressed to itself. The IPv6 CE router
connects the end-user network to a service
provider network.
The CPE Router must process RAs received on the WAN interface. As IPv6 host any device implementing an IPv6 stack receiving
per [RFC4861] if the M bit is set in the RA, the WAN interface must IPv6 Internet connectivity through the IPv6 CE
perform stateful DHCPv6- if the O bit is set in the RA, the WAN router
interface acquires other configuration information. If stateful
DHCPv6 is not used to obtain other IPv6 configuration, then stateless
must be initiated by the WAN interface to obtain other IPV6
configuration. If the A bit in the RA is clear or the RA does not
include any Prefix Information Option (PIO), the WAN interface must
not perform SLAAC. IPv6 deployments that configure RA to not include
any PIO are discussed in draft-ietf-6man-ipv6-subnet-model
[I-D.ietf-6man-ipv6-subnet-model].
5.3.1. Numbered Model (CORE) LAN interface an IPv6 CE router's attachment to a link in the
end-user network. Examples are Ethernets
(simple or bridged), 802.11 wireless or other
LAN technologies. An IPv6 CE router may have
one or more LAN Interfaces.
As instructed by the RA message, the WAN interface acquires global Service Provider a company that offers its customers access to
IPv6 address using stateful DHCPv6 or SLAAC. the Internet. In this document, a Service
Provider specifically offers Internet access
using IPv6, and may also offer IPv4 Internet
access. The Service Provider can provide such
access over a variety of different transport
methods such as DSL, cable, wireless, and
others.
5.3.2. Unnumbered Model (MEDIUM) WAN interface an IPv6 CE router's attachment to a link used
to provide connectivity to the Service Provider
network; example link technologies include
Ethernets (simple or bridged), PPP links, X.25,
Frame Relay, or ATM networks as well as
Internet-layer (or higher-layer) "tunnels",
such as tunnels over IPv4 or IPv6 itself.
When the CPE router is configured for Unnumbered model, the WAN 3. Architecture
interface only constructs a Link-Local-Address, then the WAN
interface initiates stateful DHCPv6 for IA_PD. Then the IA_PD is
sub-delegated to the LAN interface(s) and an optional Loopback
interface (or the addresses for the LAN/Loopback interfaces could
come from IA_NAs). Either the Loopback or the LAN interface can be
used to source WAN-facing traffic. When the Loopback or the LAN
interface is used to source WAN-facing traffic, both the CPE Router
and the Service Provider Router must consider the traffic to be off-
link to the link connecting the CPE Router with the Service Provider
Router. Other IPv6 configuration information is obtained using
stateless DHCPv6. A CPE Router acts as a host for packets
originating from or destined for the CPE Router. Such packets may
include SNMP or web-based router configuration, tunnel encapsulation/
decapsulation, or PPP endpoint packets. The Unnumbered model is
incompatible with the strong host model [RFC1122] on the CPE router
(such as a personal computer running PPP and routing code). The
unnumbered model may be inappropriate for use with certain
deployments where a device that uses the strong host model can
operate as a CPE Router.
5.3.3. Both Models 3.1. Current IPv4 end-user network architecture
At any instance in time of the CPE Router operation, the router does An end-user network will likely have to support both IPv4 and IPv6.
not forward any traffic between its WAN and LAN interface(s) if the It is not expected that an end-user will change their existing
router has not completed IPv6 provisioning process that involves the network topology with the introduction of IPv6. There are some
acquisition of a global IPv6 address by the WAN or if the WAN is differences in how IPv6 works and is provisioned which has
unnumbered and there is no GUA available to source WAN packets. The implications for the network architecture. A typical IPv4 end-user
LAN interface(s) must also be provisioned for a global or Unique network consist of a "plug and play" NAT box connected to the ISP.
Local Address. The assumption is a single NAT device with a single link behind it.
The NAT provides stable addressing allowing for manually configured
addresses on the nodes in the end-user network.
5.4. Details for DHCPv6 Address Acquisition (CORE) A typical IPv4 NAT deployment by default blocks all incoming
connections. Opening of ports is typically allowed using UPnP or
some other firewall control protocol.
If the WAN interface uses stateful DHCPv6, the interface sends a Another consequence of using private address space in the end-user
DHCPv6 Solicit message as described in section 17.1.1 of [RFC3315]. network is that it provides stable addressing, i.e. it never changes
The Solicit message must include an IA_NA option as specified by even when you change ISPs, and the addresses are always there even
[RFC3315]. If the WAN interfaces uses stateless DHCPv6, the WAN when the WAN interface is down or the customer edge router has not
interface sends an Information Request. Both the DHCPv6 SOLICIT and yet been provisioned.
Information Request also include other options like a Reconfigure
Accept option to inform the server that client is willing to accept
Reconfigure message from server, and the Options Request option that
includes the DNS Recursive Name server option as specified in
[RFC3646]. The Solicit may also include the Rapid Commit option if
the CPE Router is willing to accept a 2-message DHCPv6 exchange with
the server.
When the CPE Router processes a DHCPv6 response from the server, if Rewriting addresses on the edge of the network also allows for some
the response message (e.g. ADVERTISE or REPLY) received does not rudimentary multi-homing; even though using NATs for multi-homing
include an IA_PD option (if stateful DHCPv6 was initiated), or does not preserve connections during fail-overs [RFC4864].
Reconfigure Accept option, then the CPE Router has failed DHCPv6
address acquisition. If stateful DHCPv6 succeeds, the CPE Router
must perform DAD for any IPv6 address acquired from DHCPv6. If the
CPE Router detects a duplicate, the CPE Router must send a DHCPv6
Decline message to the DHCPv6 server.
The CPE Router may support the Reconfigure Key Authentication Many existing routers support dynamic routing, and advanced end users
Protocol, as described in section 21.5 of [RFC3315]. The CPE Router can build arbitrary, complex networks using manual configuration of
may also support prefix sub-delegation as described in address prefixes combined with a dynamic routing protocol.
draft-baker-ipv6-prefix-subdelegation
[I-D.baker-ipv6-prefix-subdelegation]. Prefix sub-delegation
involves DHCPv6 server support with IA_PD on the CPE router and the
ability to provision the server from a DHCPv6 REPLY with IA_PD option
received on the WAN interface.
5.5. IPv6 Provisioning of Home Devices (CORE) 3.2. IPv6 end-user network architecture
The CPE Router may include a stateful DHCPv6 server to assign The end-user network architecture for IPv6 should provide equivalent
addresses to home devices connected via the LAN interface(s) of the or better capabilities and functionality than the equivalent IPv4
CPE Router. The home devices can also acquire addresses via SLAAC. architecture.
If the LAN interface(s) are switched or bridged ports, then the CPE The end-user network is a stub network. Figure 1 illustrates the
Router assigns a single global IPv6 address to a conceptual virtual model topology for the end-user network.
interface serving all the LAN interface(s). If each LAN interface is
a routed port, then the CPE router will assign a global IPv6 address
and unique subnet to each LAN interface . In either case, when the
CPE Router needs to assign a single IPv6 address to LAN interface(s)
or multiple IPv6 addresses, the CPE Router redistributes the
addresses and subnets from the prefix received in IA_PD option by the
WAN interface. If the IA_PD changes, the CPE Router must reconfigure
the LAN interface(s) with new IPv6 addresses derived from the new
IA_PD and then also renumber the IPv6 ND RA configuration on the LAN
interface(s).
This document recommends the RA sent out by LAN Interface(S) to be An example of a typical end-user network.
configured for SLAAC so that the prefix advertised in the RA is
derived from the IA_PD assigned to the CPE Router by the Service
Provider; the O-bit is also set so that the CPE Router can pass
Domain Name Server(s) IPv6 address(es) to home devices. The CPE
Router obtained the Domain Name Server(s) in OPTION_DNS_SERVERS
option from the DHCPv6 server when the CPE Router WAN interface
completed DHCPv6.
5.5.1. LAN Initialization before WAN Initialization +-------+-------+ \
| Service | \
| Provider | | ISP
| Router | | network
+-------+-------+ |
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+---+-------+-+-+ /
Network A | | Network B | Customer
---+-------------+----+- --+--+-------------+--- |network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+/
On power up, the LAN interface(s) of the CPE Router may become Figure 1
operational before the WAN interface. This mode is appropriate for
manual user configuration of the CPE Router. After any LAN interface
has constructed a link-local address, the address can be used for
user configuration via the network. The interface MAY assign itself
a Unique Local Address automatically through the pseudo-random number
generation algorithm described in [RFC4193]. Once the IPv6 address
configuration of the LAN interface(s) is complete with a ULA, as per
[RFC4862], the CPE Router sends Router Advertisements (RA) to devices
in the home. Hosts receiving the RA from LAN interface(s) will
process the RA and perform IPv6 address acquisition. After all the
LAN interface(s) have become operational, if the WAN interface is
connected to the Service Provider network, then the WAN interface
provisions itself and may acquire an IA_PD. If an IA_PD is acquired,
it may be sub-delegated to any cascaded routers or used for SLAAC
provisioning of hosts in the home. Based on the IA_PD, the CPE
Router configures global address(es) on the LAN interface(s) and
sends an RA containing the global address and unique local prefixes
out the LAN interface(s) . After this process, every LAN interface
has a link-local unicast address, a ULA, and a GUA. Therefore, the
interface has to apply source address selection to determine which
address to use as a source for outgoing packets. Since the GUA and
ULA have a larger scope than the link-local address (rule #2 of
[RFC3484]), the GUA or ULA will be used as a source address of
outgoing packets that are not subject to rule #1. For source address
selection between a GUA and ULA, rule #8 of [RFC3484] will be
used. If a user desires to keep CPE Router configuration traffic
local to the home network, the user can do the following:
Use the ULA of the CPE Router as the destination of the This architecture describes the:
configuration traffic.
Use access control lists (ACL)s to block any ULA sourced packet o Basic capabilities of an IPv6 CE router
from being sent out the WAN interface.
Rule #1 of [RFC3484] and the ACLs ensure that the traffic does not o Provisioning of the WAN interface connecting to the ISP
escape the home network.
After the WAN interface initializes, then the LAN interface(s) can o Provisioning of the LAN interfaces
acquire global unicast addresses.
If the residential/SOHO network has multiple LANs, the CPE Router The IPv6 CE router defaults to acting as the demarcation point
MUST calculate and distribute a ULA with different subnets on the between two networks by providing a ULA boundary, a multicast zone
different LANs, and the ULA MUST be saved in non-volatile memory in boundary and ingress and egress traffic filters.
order to make it consistent across reboots. The ULA provides for
intra-site connectivity when global addresses are unavailable such as
during an uplink outage. It is RECOMMENDED that the ULA on each LAN
be displayed in a user interface and be configurable. The CPE Router
MAY calculate a ULA when the network consists of one LAN, perhaps
under configuration control, although Link Local addresses may
suffice in the case.
5.5.2. WAN initialization before LAN Initialization For IPv6 multicast traffic the IPv6 CE router may act as an MLD proxy
[RFC4605] and may support a dynamic multicast routing protocol.
On power up, the WAN interface of the CPE Router may become IPv6 CE router may be manually configured in an arbitrary topology
operational before the LAN interface(s). This mode is appropriate with a dynamic routing protocol. Automatic provisioning and
for Service Provider configuration of the CPE Router (such as a Cable configuration is described for a single IPv6 CE router only.
DOCSIS eRouter). After the IPv6 address configuration for WAN
interface is completed, the CPE Router configures IPv6 address for
LAN interface(s) .
Once IPv6 address configuration of the LAN interface(s) is complete, 4. Use Cases and Requirements
as per [RFC4862], the CPE Router sends Router Advertisements (RA) to
devices in the home. Hosts receiving the RA from LAN interface(s)
will process the RA and perform IPv6 address acquisition.
5.6. IPv6 over PPP 4.1. WAN side configuration
In some deployments IPv6 over PPP is preferred to connect the home to The IPv6 CE router will need to support connectivity to one or more
the Service Provider. For such a deployment, another configuration access network architectures. This document describes an IPv6 CE
variable on the CPE Router enables optional IPv6 over PPP support. router that is not specific to any particular architecture or Service
After IPv6CP negotiates IPv6 over PPP and the WAN interface has Provider, and supports all commonly used architectures.
constructed a Link-Local Address, steps mentioned in the "Acquire
IPv6 Address and Other Configuration Parameters" section above are
followed to acquire a GUA for WAN interface and also an IA_PD. If an
IA_PD is acquired by the WAN interface, the CPE Router assigns global
address(es) to its LAN interface(s) and sub-delegates the IA_PD to
hosts connected to the LAN interface(s) . IPv6 over PPP follows
[RFC5072]. As per [RFC5072], the CPE router does not initiate any
DAD for unicast IPv6 addresses since DupAddrDetectTransmits variable
from [RFC4862] is zero for IPv6 over PPP.
If the Service Provider deployment supports dual-stack PPP support, IPv6 Neighbor Discovery and DHCP protocols operate over any type of
then the CPE Router WAN interface may initiate one PPP logical IPv6 supported link-layer and there is no need for a link-layer
channel and support NCP IPv4 and IPv6 control protocols over one PPP specific configuration protocol for IPv6 network layer configuration
logical channel. [RFC4241] describes such behavior. The IPv4 and options like what's e.g. in PPP IPCP for IPv4. This section makes
IPv6 NCP's are independent of each other and start and terminate the assumption that the same mechanism will work for any link-layer,
independently. be it Ethernet, DOCSIS, PPP/PPPoE or others.
5.7. Stateful DHCPv6 Server (CORE) When the router is attached to the WAN interface link it must act as
an IPv6 host for the purposes of IPv6 interface initialisation, ND
Router Discovery, Prefix Discovery and interface address assignment
([RFC4861]/[RFC4862]). The router acts as a requesting router for
the purposes of DHCP prefix delegation ([RFC3633]).
The CPE Router may support a stateful DHCPv6 server to serve clients DHCP address assignment (IA_NA) and DHCP prefix delegation (IA_PD)
on the CPE Router LAN interface(s) . If the CPE Router needs to should be done as a single DHCP session.
support a stateful DHCPv6 server, then more details will be added to
this section specifying the minimal functionality that the stateful
DHCPv6 server needs to support.
6. CPE Router Behavior in a routed network (MEDIUM) Link-layer requirements:
One example of the CPE Router use in the home is shown below. The WLL-1: The IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].
home has a broadband modem combined with a CPE Router, all in one
device. The LAN interface of the device is connected to another
standalone CPE Router that supports a wireless access point. To
support such a network, this document recommends using prefix sub-
delegation of the prefix obtained either via IA_PD from WAN interface
or a ULA from the LAN interface . The network interface of the
downstream router may obtain an IA_PD via stateful DHCPv6. If the
CPE router supports the routed network through automatic prefix sub-
delegation, the CPE router MUST support a DHCPv6 server or DHCPv6
relay agent. Further, if an IA_PD is used, the Service Provider or
user MUST allocate an IA_PD or ULA prefix short enough to be sub-
delegated and subsequently used for SLAAC. Therefore, a prefix
length shorter than /64 is needed. The CPE Router MAY support RIPng
in the home network.
/-------+------------\ /------------+-----\ WLL-2: The IPv6 CE router MUST support IPv6 over PPP [RFC5072]. It
SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC MUST support use of IPv6 over PPP within PPPoE.
\-------+------------/ \------------+-----/
WAP = Wireless Access Point Address assignment requirements:
Figure 1. WAA-1: The IPv6 CE router MUST support SLAAC ([RFC4862]).
7. IPv6 Data Forwarding (CORE) WAA-2: The IPv6 CE router MUST follow the recommendation in
[I-D.ietf-6man-ipv6-subnet-model] and in particular the
handling of the L-bit in the Router Advertisement Prefix
Information Option.
Each of the WAN and LAN interface(s) of the CPE Router must have its WAA-3: The IPv6 CE router MUST support DHCP [RFC3315] client
own L2 (e.g. MAC) address. The CPE Router supports ND protocol on behavior. It MUST be able to support the following DHCP
both the WAN interface and LAN interface(s) and sends Router options: IA_NA, Reconfigure Accept([RFC3315]), DNS_SERVERS
Solicitations (RS) on the WAN interface and sends Router ([RFC3646]).
Advertisement(s) (RA) on the LAN interface(s).
The CPE Router forwards packets between the Service Provider and the WAA-4: Th IPv6 CE router SHOULD support the DHCP SNTP option
home network. To do this, the CPE Router looks up the destination ([RFC4075]) and the Information Refresh Time Option
address of the packet in the routing table and decide which route to ([RFC4242].
use to forward the packet. The CPE Router routing table will be
initialized during CPE Router initialization. The routing table is
filled by directly connected, static, and routing protocol routes.
The CPE Router consumes any packet destined to its WAN or LAN WAA-5: If the IPv6 CE router receives an RA message (described in
interface. The CPE Router forwards other packets destined to hosts [RFC4861]) with the M-bit set to 1, the IPv6 CE router MUST
attached to CPE Router LAN interface(s). Any packet that is not request an IA_NA. If the IPv6 CE router is unable to assign
routable by the CPE Router must be dropped. an address through SLAAC it MAY request an IA_NA even if the
M-bit is set to 0.
The CPE Router must support the ND protocol specified by [RFC4861]. WAA-6: If the IPv6 CE router does not acquire a global IPv6 address
Proxy Neighbor Advertisements as described in Section 7.2.8 of from either SLAAC or DHCP, then it MUST create a global IPv6
[RFC4861] as applicable to the CPE Router are discussed in the IPv6 address from its delegated prefix and configure that on one
ND Proxy Behavior section. Also note, as per section 6.2.8 of of its internal virtual network interfaces.
[RFC4861] the link-local address on a router should rarely change, if
ever. As per [RFC2460], the CPE Router decrements the Hop Limit by 1
for any packet it forwards. The packet is discarded if Hop Limit is
decremented to zero and the CPE Router also sends an ICMP Time
Exceeded message to the source of the packet.
A null route SHOULD be added to the routing table (to prevent routing Prefix Delegation requirements:
loops) that is lower priority than any route except the default
route. The choice to drop the packet or send an ICMPv6 Destination
Unreachable to the source address of the packet is implementation-
dependent. The installation of this null route MAY be automatic.
7.1. IPv6 ND Proxy Behavior (MEDIUM) WPD-1: The IPv6 CE router MUST support DHCP prefix delegation
requesting router behaviour as specified in [RFC3633] (IA_PD
option). The IPv6 CE router MUST ask for a prefix large
enough to cover all of its LAN interfaces.
If the CPE Router has only one /64 prefix to be used across multiple WPD-2: The IPv6 CE router MUST always initiate DHCP prefix
LAN interfaces and the CPE Router supports any two LAN interfaces delegation, regardless of the M and O-bits in a received
that cannot bridge data between them because the two interfaces have Router Advertisement. If the IPv6 CE Router initiates DHCP
disparate MAC layers, then the CPE Router MUST support ND Proxy before receiving a Router Advertisement it MUST also request
[RFC4389]. If any two LAN interfaces support bridging between the an IA_NA.
interfaces, then ND Proxy is not necessary between the two
interfaces. Legacy 3GPP networks have the following requirements:
1. No DHCPv6 prefix is delegated to the CPE Router. WPD-3: If the delegated prefix is an aggregate route of multiple,
more-specific routes the IPv6 CE router MUST discard packets
that match the aggregate route, but not any of the more-
specific routes. In other words, the "next-hop" for the
aggregate route should be the null destination. This is
necessary to prevent forwarding loops when some addresses
covered by the aggregate are not reachable. [RFC4632]
2. Only one /64 is available on the WAN link. WPD-4: If the IPv6 CE router requests both an IA_NA and an IA_PD in
DHCP, it MUST accept an IA_PD in DHCP Advertise/Reply
messages, even if the message does not contain any addresses
(IA_NA options with status code NoAddrsAvail).
3. The link types between the WAN interface and LAN interface(s) are WPD-5: An IPv6 CE router MUST not by default initiate any dynamic
disparate and, therefore, can't be bridged. routing protocol on its WAN interface.
4. No NAT66 is to be used. 4.2. LAN side configuration
5. Each LAN interface needs global connectivity. The IPv6 CE router distributes configuration information obtained
during WAN interface provisioning to IPv6 hosts and assists IPv6
hosts in obtaining IPv6 addresses. It also supports connectivity of
these devices in the absence of any working WAN interface.
6. Uses SLAAC to configure LAN interface addresses. An IPv6 CE router will be expected to support an IPv6 end-user
network and IPv6 hosts that exhibit the following characteristics:
For these legacy 3GPP networks, the CPE Router MUST support ND Proxy 1. Link-local addresses are insufficient for allowing IPv6
between the WAN and LAN interface(s). However, if the CPE Router has applications to communicate with each other in the end-user
multiple prefixes available for use on LAN interfaces(s), then ND network. The IPv6 CE router will need to enable this
Proxy is not necessary. communication by providing globally-scoped unicast addresses or
ULAs whether or not WAN connectivity exists.
7.2. IPv6 Multicast Behavior (CORE) 2. IPv6 hosts will be capable of using SLAAC and may be capable of
using DHCP for acquiring their addresses.
The CPE Router SHOULD follow the model described for MLD Proxy in 3. IPv6 hosts will use DHCP for other configuration information,
[RFC4605] to implement multicast. The MLD Proxy model was chosen such as the DNS_SERVERS option for acquiring DNS information.
because it is simpler to implement than more complicated multicast
routing functionality.
Querier Election rules as described in section 7.6.2 of [RFC3810] do Unless otherwise specified these requirements only apply to the IPv6
not apply to the CPE Router (even when the home has multiple cascaded CE router's LAN interfaces.
routers) since every CPE Router in the cascade is the only router in
its own multicast domain. Every CPE Router in the cascade will send
MLDv2 Reports with aggregated multicast Group Membership information
to the next upstream router.
If the CPE Router hardware includes a network bridge between the WAN Requirements:
interface and the LAN interface(s), then the CPE Router MUST support
MLDv2 snooping as per [RFC4541].
Consistent with [RFC4605], the CPE Router must not implement the L-1: The IPv6 CE router MUST support ULA addressing ([RFC4193]).
router portion of MLDv2 for the WAN interface. Likewise, the LAN
interfaces on the CPE router must not implement an MLDv2 Multicast
Listener. However, if a user at home wants to create a new multicast
group and send multicast data to other nodes on the Service Provider
network, then Protocol Independent Multicast-Source Specific
Multicast (PIM-SSM) [RFC3569] is recommended to handle multicast
traffic flowing in the upstream direction as a one-to-many multicast
flow.
8. Other IPv6 Features L-2: The IPv6 CE router MUST have a ULA prefix that it maintains
consistently across reboots. The value of the ULA prefix
SHOULD be user configurable.
8.1. Path MTU Discovery Support (MEDIUM) L-3: The IPv6 CE router by default MUST act as a site border router
according to section 4.3 of RFC4193 and filter packets with
Local IPv6 source or destination addresses accordingly.
GRE tunnels, such as IPv6 to IPv4 tunnels (which may be terminated on L-4: The IPv6 CE router MUST support router behavior of Neighbor
the CPE Router), can modify the default Ethernet MTU of 1500 bytes. Discovery for IPv6 ([RFC4861]).
Also, in the future, Ethernet Jumbo frames (> 1500 bytes) may also be
supported. Since the MTU can vary, a newly initiated TCP stream must
detect the largest packet that can be sent to the destination without
fragmentation. This can be detected using Path MTU Discovery
[RFC1981]. Routers which may encounter a packet too large to be L-5: The IPv6 CE router must assign a separate /64 from its
forwarded from source to destination may drop the packet and send an delegated prefix (and ULA prefix if configured to provide ULA
ICMPv6 Packet Too Big message to the source. The CPE Router must addressing) for each of its LAN interfaces. The IPV6 CE router
route back to the source any ICMPv6 Packet Too Big messages generated MUST make the interface an advertising interface according to
anywhere on this path. Issues and solutions to problems with MTUs RFC4861. In router advertisements messages, the Prefix
and tunnels are described more fully in [RFC4459]. Information Option's A/L-bits MUST be set to 1 by default; the
A/L bits setting SHOULD be user configurable.
8.2. Optional RIPng Support (CORE) L-6: The IPv6 CE router MUST support a DHCP server ([RFC3315]) on
its LAN interfaces. It SHOULD support DHCP address assignment
(IA_NA).
The CPE Router may support RIPng routing protocol [RFC2080] so that L-7: Unless the IPv6 CE router is configured to support DHCP IA_NA,
RIPng operates between the CPE Router and the Service Provider it SHOULD set M=0 and O=1 in its RA messages.
network. RIPng has scaling and security implications for the Service
Provider network where one Service Provider router may terminate
several tens of thousands of CPE routers. However, RIPng does
provide one solution from the CPE Router to the Service Provider
network for prefix route injection.
8.3. Automated Tunneling (MEDIUM) L-8: The IPv6 CE router MUST support providing DNS information in
the DHCP DNS_SERVERS option ([RFC3646]).
If the IPv4 address assigned to the WAN interface of the CPE Router L-9: The IPv6 CE router SHOULD pass the additional set of DHCP
is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire options received from the DHCP client on its WAN interface from
an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring the Service Provider to IPv6 hosts.
the IPv4 address, then the 6rd tunneling protocol SHOULD be enabled
(if supported). If 6rd fails to find a usable relay, then 6to4
tunneling protocol [RFC3056] SHOULD be enabled automatically,
allowing tunneling of IPv6 packets over IPv4 without requiring user
configuration. If both IPv6 and IPv4 addresses are acquired within
WAN_IP_ACQUIRE_TIMEOUT seconds of each other, then the CPE Router
operates in dual stack mode, and does not need 6rd or 6to4. If no
IPv4 and no IPv6 address has been acquired, then the CPE Router
retries address acquisition.
6to4 can be useful in the scenario where the Service Provider does 4.3. General requirements
not yet support IPv6, but devices in the home use IPv6. An IPv6
address is constructed automatically from the IPv4 address (V4ADDR)
configured on the interface using the prefix 2002:V4ADDR::/48. A
6to4 tunnel can be automatically created using a pre-configured 6to4
gateway end-point for the tunnel.
6rd is similar to 6to4, however it uses a service provider prefix The IPv6 CE router is responsible for implementing IPv6 routing; that
instead of a well-known prefix. The 6rd relay is typically managed is, the IPv6 CE router must look up the IPv6 Destination address in
by the service provider. The 6rd protocol is described more fully in its routing table to decide to which interface it should send the
draft-townsley-ipv6-6rd [I-D.townsley-ipv6-6rd]. A deployment of 6rd packet.
is described in draft-despres-6rd [I-D.despres-6rd].
Several proposals are being considered by IETF related to the problem In this role, the IPv6 CE router is responsible for ensuring that
of IPv4 address depletion, but have not yet achieved working group traffic using its ULA addressing does not go out the WAN interface,
consensus for publication as an RFC. Dual-stack lite ietf-softwire- and does not originate from the WAN interface.
dual-stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] requires the
CPE Router to support features such as v4 in v6 encapsulation and
softwires. Since Dual-stack lite ietf-softwire-dual-stack-lite-00
[I-D.ietf-softwire-dual-stack-lite] is under development in the IETF,
it has been moved to the bis version of this document.
8.4. DNS Support (CORE) Requirements:
For local DNS queries for configuration, the CPE Router may include a G-1: An IPv6 CE router is an IPv6 node and MUST follow the IPv6 Node
DNS server to handle local queries. Non-local queries can be Requirements [RFC4294] specification.
forwarded unchanged to a DNS server specified in the DNS server
DHCPv6 option. The local DNS server MAY also handle renumbering from
the Service Provider provided prefix for local names used exclusively
inside the home (the local AAAA and PTR records are updated). This
capability provides connectivity using local DNS names in the home
after a Service Provider renumbering.
8.5. Quality Of Service(QoS) G-2: The IPV6 CE router SHOULD support the following RFCs:
The CPE router MAY support differentiated services [RFC2474]. * Internet Protocol, Version 6 (IPv6) Specification [RFC2460]
9. IPv4 Support (CORE) * Stateless Dynamic Host Configuration Protocol (DHCP) Service
for IPv6 [RFC3736]
IPv4 support is largely out of scope for this document. However, a * Default Router Preferences and More-Specific Routes
brief overview of current practice in the market may be helpful since [RFC4191]
the CPE Router may support both IPv4 and IPv6. This section does NOT
require the CPE Router to support IPv4. For background information
on IPv4 routing capabilities, please refer to [RFC1812]. Typically,
CPE Routers which support IPv4, also support IPv4 NAT for translating
private [RFC1918] addresses (e.g. 192.168.x.x) into a single non-
[RFC1918] WAN address assigned through DHCPv4 or manually configured.
In addition to NAT, CPE Routers that support IPv4 typically also
support Application Layer Gateway functionality (ALG), such as the
FTP ALG. The IPv4 NAT functionality typically has a built-in DHCPv4
server. A CPE Router which supports IPv4 also supports ARP and basic
unicast IPv4 forwarding. Some CPE Routers which support IPv4 also
support IPv4 multicast forwarding ([RFC5135]) and basic firewall
capabilities. A stateful firewall can enhance security by examining
the state of each connection and only allow traffic which conforms to
an expected packet flow.
10. DEVICE Constants * IP Version 6 Addressing Architecture [RFC4291]
1. WAN_IP_ACQUIRE_TIMEOUT 180 seconds. * IPv6 Subnet Model: the Relationship between Links and Subnet
Prefixes [I-D.ietf-6man-ipv6-subnet-model]
The default value of WAN_IP_ACQUIRE_TIMEOUT can be overidden by link- G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between
type specific documents. its LAN Interface(s) and its WAN Interface until the router has
successfully completed the IPv6 address acquisition process.
11. Future Work 4.4. Security Considerations
All of the future work has been moved to a bis(updates) version of It is considered a best practice to filter obviously malicious
this document. traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, the
IPv6 CE router should support basic stateless egress and ingress
filters. The CE router should also offer mechanisms to filter
traffic entering the customer network; however, the method by which
vendors implement configurable packet filtering is beyond the scope
of this document.
12. Security Considerations Security requirements:
Security considerations of a CPE router are covered by S-1: The IPv6 CE router SHOULD support
draft-ietf-v6ops-cpe-simple-security [I-D.ietf-v6ops-cpe-simple-security].
[I-D.ietf-v6ops-cpe-simple-security].
13. IANA Considerations S-2: The IPv6 CE router MUST support ingress filtering in accordance
with [RFC2827](BCP 38)
None. 5. Acknowledgements
14. Acknowledgements Thanks to the following people (in alphabetical order) for their
guidance and feedback:
Thanks (in alphabetical order) to Antonio Querubin, Barbara Stark, Mikael Abrahamsson, Scott Beuker, Rex Bullinger, Brian Carpenter,
Bernie Volz, Brian Carpenter, Carlos Pignataro, Dan Wing, David Remi Denis-Courmont, Alain Durand, Katsunori Fukuoka, Tony Hain,
Miles, Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark Thomas Herbst, Kevin Johns, Stephen Kramer, Victor Kuarsingh,
Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, Shin Francois-Xavier Le Bail, David Miles, Shin Miyakawa, Jean-Francois
Miyakawa, Teemu Savolainen, Thomas Herbst, and Tony Hain for their Mule, Carlos Pignataro, John Pomeroy, Antonio Querubin, Teemu
input on the document. Savolainen, Matt Schmitt, Mark Townsley, Bernie Volz, James Woodyatt,
Dan Wing and Cor Zwart
15. References This draft is based in part on CableLabs' eRouter specification. The
authors wish to acknowledge the additional contributors from the
eRouter team:
15.1. Normative References Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas,
Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego
Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur
Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan
Torbet and Greg White
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6. Contributors
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless The following people have participated as co-authors or provided
Address Autoconfiguration", RFC 4862, September 2007. substantial contributions to this document: Ralph Droms, Kirk
Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay,
Yiu Lee, John Jason Brzozowski and Heather Kirksey.
15.2. Informative References 7. IANA Considerations
[I-D.baker-ipv6-prefix-subdelegation] This memo includes no request to IANA.
Baker, F., "Prefix Sub-delegation in a SOHO/SMB
Environment", draft-baker-ipv6-prefix-subdelegation-00
(work in progress), July 2009.
[I-D.despres-6rd] 8. Normative References
Despres, R., "IPv6 Rapid Deployment on IPv4
infrastructures (6rd)", draft-despres-6rd-03 (work in
progress), April 2009.
[I-D.ietf-6man-ipv6-subnet-model] [I-D.ietf-6man-ipv6-subnet-model]
Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: the Relationship between Links and Subnet Model: the Relationship between Links and Subnet
Prefixes", draft-ietf-6man-ipv6-subnet-model-05 (work in Prefixes", draft-ietf-6man-ipv6-subnet-model-05 (work in
progress), May 2009. progress), May 2009.
[I-D.ietf-6man-node-req-bis]
Loughney, J. and T. Narten, "IPv6 Node Requirements RFC
4294-bis", draft-ietf-6man-node-req-bis-03 (work in
progress), July 2009.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-stack lite broadband deployments
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-01 (work in progress),
July 2009.
[I-D.ietf-v6ops-cpe-simple-security] [I-D.ietf-v6ops-cpe-simple-security]
Woodyatt, J., "Recommended Simple Security Capabilities in Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment for Providing Residential Customer Premises Equipment for Providing Residential
IPv6 Internet Service", IPv6 Internet Service",
draft-ietf-v6ops-cpe-simple-security-07 (work in draft-ietf-v6ops-cpe-simple-security-08 (work in
progress), July 2009. progress), October 2009.
[I-D.townsley-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks", draft-townsley-ipv6-6rd-01 (work in progress),
July 2009.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
November 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
"Definition of the Differentiated Services Field (DS Networks", RFC 2464, December 1998.
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2669] St. Johns, M., "DOCSIS Cable Device MIB Cable Device
Management Information Base for DOCSIS compliant Cable
Modems and Cable Modem Termination Systems", RFC 2669,
August 1999.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
via IPv4 Clouds", RFC 3056, February 2001. Defeating Denial of Service Attacks which employ IP Source
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.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 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.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Delegation", RFC 3769, June 2004. Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet Time Option for Dynamic Host Configuration Protocol for
Access Service", RFC 4241, December 2005. IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
Proxies (ND Proxy)", RFC 4389, April 2006. April 2006.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
J. Palet, "ISP IPv6 Deployment Scenarios in Broadband J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", RFC 4779, January 2007. Access Networks", RFC 4779, January 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
Authors' Addresses Authors' Addresses
Hemant Singh Hemant Singh
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 1622 Phone: +1 978 936 1622
Email: shemant@cisco.com Email: shemant@cisco.com
skipping to change at line 926 skipping to change at page 13, line 30
Wes Beebee Wes Beebee
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 2030 Phone: +1 978 936 2030
Email: wbeebee@cisco.com Email: wbeebee@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: c.donley@cablelabs.com
Barbara Stark
AT&T
725 W Peachtree St
Atlanta, GA 30308
USA
Email: barbara.stark@att.com
Ole Troan (editor)
Cisco Systems, Inc.
Veversmauet 8
BERGEN, 5017
Norway
Phone:
Email: ot@cisco.com
 End of changes. 118 change blocks. 
704 lines changed or deleted 349 lines changed or added

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