Network Working Group
Internet Engineering Task Force                                 H. Singh
Internet-Draft                                                 W. Beebee
Intended status: Informational                       Cisco Systems, Inc.
Expires: February 19, April 29, 2010                               August 18,                                        C. Donley
                                                               CableLabs
                                                                B. Stark
                                                                    AT&T
                                                           O. Troan, Ed.
                                                     Cisco Systems, Inc.
                                                        October 26, 2009

              Requirements for IPv6 CPE Router Recommendations
                  draft-ietf-v6ops-ipv6-cpe-router-01 Customer Edge Routers
                  draft-ietf-v6ops-ipv6-cpe-router-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   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
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 19, April 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document recommends IPv6 behavior specifies requirements for an IPv6 Customer Premises
   Equipment (CPE) routers in Internet-enabled homes and small offices.
   The CPE Router may be a standalone device.  The CPE Router may also
   be embedded in a device such as a cable modem, DSL modem, cellular
   phone, etc.  This document describes Edge (CE)
   router.  Specifically, the router portion current version 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, focuses
   on the document also provide some guidance for implementers to
   expedite availability provisioning of an IPv6 CPE CE 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 provisioning of this document. IPv6
   hosts attached to it.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Abbreviations  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . .  4
   3.  Operational Behavior . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . .  5
     3.1.  Conceptual Configuration Variables . . . . . .  3
   3.  Architecture . . . . . .  5
   4.  Router Initialization . . . . . . . . . . . . . . . . . . .  4
     3.1.  Current IPv4 end-user network architecture .  6
   5.  Basic IPv6 Provisioning . . . . . . .  4
     3.2.  IPv6 end-user network architecture . . . . . . . . . . . .  6
     5.1.  Construct Link-Local Address (CORE)  5
   4.  Use Cases and Requirements . . . . . . . . . . .  7
     5.2.  Process RAs (CORE) . . . . . . .  6
     4.1.  WAN side configuration . . . . . . . . . . . . .  7
     5.3.  Acquire IPv6 Address and Other Configuration
           Parameters (CORE) . . . . .  6
     4.2.  LAN side configuration . . . . . . . . . . . . . . .  7
       5.3.1.  Numbered Model (CORE) . . .  8
     4.3.  General requirements . . . . . . . . . . . . .  8
       5.3.2.  Unnumbered Model (MEDIUM) . . . . . .  9
     4.4.  Security Considerations  . . . . . . . .  8
       5.3.3.  Both Models . . . . . . . . . 10
   5.  Acknowledgements . . . . . . . . . . . .  8
     5.4.  Details for DHCPv6 Address Acquisition (CORE)  . . . . . .  8
     5.5.  IPv6 Provisioning of Home Devices (CORE) . . . . . . . . .  9
       5.5.1.  LAN Initialization before WAN Initialization . . . . . 10
       5.5.2.  WAN initialization before LAN Initialization . .
   6.  Contributors . . . 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)  . . . . . .  IANA Considerations  . . . . . . . 13
     7.2.  IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . . 14 11
   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  . . . . . . . . . . . . . . . . . .  Normative References . . . . . . . 17
   12. Security Considerations . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . 17
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     15.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 13

1.  Introduction

   This document defines IPv6 features for a residential or small office
   router referred to as a CPE Router.  Typically, CPE Router devices
   support IPv4, as discussed in the "IPv4 Support" section.  Also, this
   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 CE router.  Typically these routers
   also support IPv4.

   This document discusses specifies how an IPv6 implications CE router automatically
   provisions its WAN interface, acquires an address block for
   provisioning of its LAN interfaces and fetches other configuration
   information from the attached Service
   Provider service provider network.  Automatic
   provisioning of more complex topology than a single router with
   multiple LAN interfaces is out of scope for this document.

   See [RFC4779] for a discussion of options available for deploying
   IPv6 in service provider access networks.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document notes that the CPE Router may are to be
   deployed in home interpreted as described in RFC 2119 [RFC2119].

2.  Terminology

   End-user Network      one of two ways.  Either the Service Provider or more links attached to the home user may manage this device.  When the CPE Router is managed
   by the Service Provider, the IPv6 CE
                         router that connect IPv6 hosts.

   IPv6 Customer Edge router may need additional management
   and routing properties like  a new MIB definition and routing
   protocols communicating between node intended for home or small office
                         use which forwards IPv6 packets not explicitly
                         addressed to itself.  The IPv6 CE router
                         connects the CPE Router and end-user network to a service
                         provider network.

   IPv6 host             any device implementing an IPv6 stack receiving
                         IPv6 Internet connectivity through the Service
   Provider IPv6 CE
                         router

   LAN interface         an IPv6 CE router's attachment to a link in the
                         end-user network.  The CPE  Examples are Ethernets
                         (simple or bridged), 802.11 wireless or other
                         LAN technologies.  An IPv6 CE router has may have
                         one or more WAN interface(s) to
   connect to the LAN Interfaces.

   Service Provider and zero or more LAN interfaces      a company that offers its customers access to
                         the home network devices. Internet.  In the case of zero LAN interfaces, any
   LAN-applicable initialization this document, a Service
                         Provider specifically offers Internet access
                         using IPv6, and behavior is skipped. 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.

   WAN interface is preferred         an IPv6 CE router's attachment to be Ethernet encapsulated but it may support
   other encapsulations 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 PPP.

   Technologies are labeled as: CORE (widely deployed in the field, many
   years of operational experience, one tunnels over IPv4 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) IPv6 itself.

3.  Architecture

3.1.  Current IPv4 end-user network architecture

   An end-user network will likely have been moved to a bis(updates) version of this document.

2.  Terminology support both IPv4 and Abbreviations

      Host - this IPv6.
   It is a personal computer or any other network device in
      a home not expected 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 end-user will change their existing
   network interfaces on topology with the
      CPE Router that introduction of IPv6.  There are used to connect hosts some
   differences in how IPv6 works and is provisioned which has
   implications for the home.  This set network architecture.  A typical IPv4 end-user
   network consist 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 a "plug and play" NAT box connected to connect wireless hosts in the home in
      either managed or ad-hoc modes.

      WAN interface - usually ISP.
   The assumption is a single physical network interface NAT device with a single link behind it.
   The NAT provides stable addressing allowing for manually configured
   addresses on the
      standalone CPE Router that is used to connect the router to nodes in the
      access network end-user network.

   A typical IPv4 NAT deployment by default blocks all incoming
   connections.  Opening of the Service Provider.  When the CPE Router ports is
      embedded typically allowed using UPnP or
   some other firewall control protocol.

   Another consequence of using private address space in a device that connects to the WAN, this interface is a
      logical end-user
   network interface is that bridges it provides stable addressing, i.e. it never changes
   even when you change ISPs, and the device to addresses are always there even
   when 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 down or the Internet for a home.  The customer edge router
   is also intended to provide home networking functionality.  The CPE
   Router may have a console or web interface for configuration.  This
   document defines has not
   yet been provisioned.

   Rewriting addresses on the core set edge of features that are supported by the
   CPE Router, however individual implementations may include value-
   added features such as WLAN capability.

   The core set network also allows for some
   rudimentary multi-homing; even though using NATs for multi-homing
   does not preserve connections during fail-overs [RFC4864].

   Many existing routers support dynamic routing, and advanced end users
   can build arbitrary, complex networks using manual configuration of
   address prefixes combined with a dynamic routing protocol.

3.2.  IPv6 features end-user network architecture

   The end-user network architecture for IPv6 should provide equivalent
   or better capabilities and functionality than the CPE Router includes
   provisioning equivalent IPv4
   architecture.

   The end-user network is a stub network.  Figure 1 illustrates the CPE Router
   model topology 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-
   Local Address, then the WAN interface initiates stateful DHCPv6 for
   IA_PD.  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.  Other IPv6
   configuration information is obtained using stateless DHCPv6.

   The CPE Router acquires its IPv6 addresses from the Service Provider
   along with any other IPv6 configuration any time the WAN interface is
   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)

   If an interface of the CPE Router is configured for IPv6, when the
   interface initializes itself, as per [RFC4862], the CPE Router must
   create a link-local address for the interface.  We recommend the CPE
   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)

   The CPE Router must process incoming RAs received on the WAN
   interface as specified in section 6.3 of [RFC4861].  The CPE Router
   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)

   The CPE Router must process RAs received on the WAN interface.  As
   per [RFC4861] if the M bit is set in the RA, the WAN interface must
   perform stateful DHCPv6- if the O bit is set in the RA, the WAN
   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)

   As instructed by the RA message, the WAN interface acquires global
   IPv6 address using stateful DHCPv6 or SLAAC.

5.3.2.  Unnumbered Model (MEDIUM)

   When the CPE router is configured for Unnumbered model, the WAN
   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

   At any instance in time of the CPE Router operation, the router does
   not forward any traffic between its WAN and LAN interface(s) if the
   router has not completed IPv6 provisioning process that involves the
   acquisition of a global IPv6 address by the WAN or if the WAN is
   unnumbered and there is no GUA available to source WAN packets.  The
   LAN interface(s) must also be provisioned for a global or Unique
   Local Address.

5.4.  Details for DHCPv6 Address Acquisition (CORE)

   If the WAN interface uses stateful DHCPv6, the interface sends a
   DHCPv6 Solicit message as described in section 17.1.1 of [RFC3315].
   The Solicit message must include an IA_NA option as specified by
   [RFC3315].  If the WAN interfaces uses stateless DHCPv6, the WAN
   interface sends an Information Request.  Both the DHCPv6 SOLICIT and
   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
   the response message (e.g.  ADVERTISE or REPLY) received does not
   include an IA_PD option (if stateful DHCPv6 was initiated), or
   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
   Protocol, as described in section 21.5 of [RFC3315].  The CPE Router
   may also support prefix sub-delegation as described in
   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)

   The CPE Router may include a stateful DHCPv6 server to assign
   addresses to home devices connected via the LAN interface(s) of the
   CPE Router.  The home devices can also acquire addresses via SLAAC.

   If the LAN interface(s) are switched or bridged ports, then the CPE
   Router assigns a single global IPv6 address to a conceptual virtual
   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
   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

   On power up, the LAN interface(s) of the CPE Router may become
   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
      configuration traffic.

      Use access control lists (ACL)s to block any ULA sourced packet
      from being sent out the WAN interface.

   Rule #1 of [RFC3484] and the ACLs ensure that the traffic does not
   escape the home network.

   After the WAN interface initializes, then the LAN interface(s) can
   acquire global unicast addresses.

   If the residential/SOHO network has multiple LANs, the CPE Router
   MUST calculate and distribute a ULA with different subnets on the
   different LANs, and the ULA MUST be saved in non-volatile memory in
   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

   On power up, the WAN interface of the CPE Router may become
   operational before the LAN interface(s).  This mode is appropriate
   for Service Provider configuration of the CPE Router (such as a Cable
   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,
   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

   In some deployments IPv6 over PPP is preferred to connect the home to
   the Service Provider.  For such a deployment, another configuration
   variable on the CPE Router enables optional IPv6 over PPP support.
   After IPv6CP negotiates IPv6 over PPP and the WAN interface has
   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,
   then the CPE Router WAN interface may initiate one PPP logical
   channel and support NCP IPv4 and IPv6 control protocols over one PPP
   logical channel.  [RFC4241] describes such behavior.  The IPv4 and
   IPv6 NCP's are independent of each other and start and terminate
   independently.

5.7.  Stateful DHCPv6 Server (CORE)

   The CPE Router may support a stateful DHCPv6 server to serve clients
   on the CPE Router LAN interface(s) .  If the CPE Router needs to
   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)

   One example of the CPE Router use in the home is shown below.  The
   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 end-user network.

                 An example 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 typical end-user network.

                     +-------+-------+                   \
                     |   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.

                /-------+------------\    /------------+-----\
        SP <--+ Modem    | CPE                     | ISP
                     |    Router    +--+ CPE     |                     | network
                     +-------+-------+                     |
                             |                             /
                             | Customer                   /
                             | Internet connection       /
                             |
                      +------+--------+                  \
                      |     IPv6      |                   \
                      | Customer Edge |                    \
                      |    Router     | WAP + --> PC
                \-------+------------/    \------------+-----/

        WAP = Wireless Access Point

                                 Figure 1.

7.                    /
                      +---+-------+-+-+                   /
          Network A       |       |   Network B          | Customer
    ---+-------------+----+-    --+--+-------------+---  |network(s)
       |             |               |             |      \
   +----+-----+ +-----+----+     +----+-----+ +-----+----+  \
   |IPv6 Host | |IPv6 Host |     | IPv6 Data Forwarding (CORE)

   Each Host| |IPv6 Host |  /
   |          | |          |     |          | |          | /
   +----------+ +-----+----+     +----------+ +----------+/

                                 Figure 1

   This architecture describes the:

   o  Basic capabilities of the WAN and LAN interface(s) an IPv6 CE router

   o  Provisioning of the CPE Router must have its
   own L2 (e.g.  MAC) address.  The CPE Router supports ND protocol on
   both the WAN interface and LAN interface(s) and sends Router
   Solicitations (RS) on connecting to the WAN interface and sends Router
   Advertisement(s) (RA) on ISP

   o  Provisioning of the LAN interface(s). interfaces

   The CPE Router forwards packets between IPv6 CE router defaults to acting as the Service Provider demarcation point
   between two networks by providing a ULA boundary, a multicast zone
   boundary and the
   home network.  To do this, the CPE Router looks up the destination
   address of the packet in the routing table ingress and decide which route to
   use to forward egress traffic filters.

   For IPv6 multicast traffic the packet.  The CPE Router IPv6 CE router may act as an MLD proxy
   [RFC4605] and may support a dynamic multicast routing table will protocol.

   IPv6 CE router may be
   initialized during CPE Router initialization.  The manually configured in an arbitrary topology
   with a dynamic routing table protocol.  Automatic provisioning and
   configuration is
   filled by directly connected, static, described for a single IPv6 CE router only.

4.  Use Cases and routing protocol routes.

   The CPE Router consumes any packet destined to its Requirements

4.1.  WAN or LAN
   interface. side configuration

   The CPE Router forwards other packets destined IPv6 CE router will need to hosts
   attached support connectivity to CPE Router LAN interface(s).  Any packet one or more
   access network architectures.  This document describes an IPv6 CE
   router that is not
   routable by the CPE Router must be dropped.

   The CPE Router must support the ND protocol specified by [RFC4861].
   Proxy Neighbor Advertisements as described in Section 7.2.8 of
   [RFC4861] as applicable specific to the CPE Router are discussed in the any particular architecture or Service
   Provider, and supports all commonly used architectures.

   IPv6
   ND Proxy Behavior section.  Also note, as per section 6.2.8 Neighbor Discovery and DHCP protocols operate over any type of
   [RFC4861] the link-local address on
   IPv6 supported link-layer and there is no need for a router should rarely change, if
   ever.  As per [RFC2460], link-layer
   specific configuration protocol for IPv6 network layer configuration
   options like what's e.g. in PPP IPCP for IPv4.  This section makes
   the CPE Router decrements assumption that the Hop Limit by 1 same mechanism will work for any packet link-layer,
   be it forwards.  The packet is discarded if Hop Limit Ethernet, DOCSIS, PPP/PPPoE or others.

   When the router is
   decremented attached to zero and the CPE Router also sends WAN interface link it must act as
   an ICMP Time
   Exceeded message to IPv6 host for the source 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 packet.

   A null route SHOULD purposes of DHCP prefix delegation ([RFC3633]).

   DHCP address assignment (IA_NA) and DHCP prefix delegation (IA_PD)
   should be added to the routing table (to prevent routing
   loops) that is lower priority than any route except the default
   route. done as a single DHCP session.

   Link-layer requirements:

   WLL-1:  The IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].

   WLL-2:  The choice to drop the packet or send an ICMPv6 Destination
   Unreachable to the source address IPv6 CE router MUST support IPv6 over PPP [RFC5072].  It
           MUST support use of the packet is implementation-
   dependent. IPv6 over PPP within PPPoE.

   Address assignment requirements:

   WAA-1:  The installation of this null route MAY be automatic.

7.1. IPv6 ND Proxy Behavior (MEDIUM)

   If CE router MUST support SLAAC ([RFC4862]).

   WAA-2:  The IPv6 CE router MUST follow the CPE Router has only one /64 prefix to be used across multiple
   LAN interfaces recommendation in
           [I-D.ietf-6man-ipv6-subnet-model] and in particular the CPE Router supports any two LAN interfaces
   that cannot bridge data between them because
           handling of the two interfaces have
   disparate MAC layers, then L-bit in the CPE Router Advertisement Prefix
           Information Option.

   WAA-3:  The IPv6 CE router MUST support ND Proxy
   [RFC4389].  If any two LAN interfaces DHCP [RFC3315] client
           behavior.  It MUST be able to support bridging between the
   interfaces, then ND Proxy is not necessary between following DHCP
           options: IA_NA, Reconfigure Accept([RFC3315]), DNS_SERVERS
           ([RFC3646]).

   WAA-4:  Th IPv6 CE router SHOULD support the two
   interfaces.  Legacy 3GPP networks have DHCP SNTP option
           ([RFC4075]) and the following requirements:

   1.  No DHCPv6 prefix is delegated to Information Refresh Time Option
           ([RFC4242].

   WAA-5:  If the CPE Router.

   2.  Only one /64 is available on IPv6 CE router receives an RA message (described in
           [RFC4861]) with the WAN link.

   3.  The link types between M-bit set to 1, the WAN interface and LAN interface(s) are
       disparate and, therefore, can't be bridged.

   4.  No NAT66 IPv6 CE router MUST
           request an IA_NA.  If the IPv6 CE router is unable to be used.

   5.  Each LAN interface needs global connectivity.

   6.  Uses assign
           an address through SLAAC it MAY request an IA_NA even if the
           M-bit is set to configure LAN interface addresses.

   For these legacy 3GPP networks, 0.

   WAA-6:  If the CPE Router IPv6 CE router does not acquire a global IPv6 address
           from either SLAAC or DHCP, then it MUST support ND Proxy
   between the WAN create a global IPv6
           address from its delegated prefix and LAN interface(s).  However, if the CPE Router has
   multiple prefixes available for use configure that on LAN interfaces(s), then ND
   Proxy is not necessary.

7.2. one
           of its internal virtual network interfaces.

   Prefix Delegation requirements:

   WPD-1:  The IPv6 Multicast Behavior (CORE) CE router MUST support DHCP prefix delegation
           requesting router behaviour as specified in [RFC3633] (IA_PD
           option).  The CPE Router SHOULD follow the model described IPv6 CE router MUST ask for MLD Proxy in
   [RFC4605] a prefix large
           enough to implement multicast. cover all of its LAN interfaces.

   WPD-2:  The MLD Proxy model was chosen
   because it is simpler to implement than more complicated multicast
   routing functionality.

   Querier Election rules as described in section 7.6.2 IPv6 CE router MUST always initiate DHCP prefix
           delegation, regardless of [RFC3810] do
   not apply to the CPE M and O-bits in a received
           Router (even when Advertisement.  If the home has multiple cascaded
   routers) since every CPE IPv6 CE Router in initiates DHCP
           before receiving a Router Advertisement it MUST also request
           an IA_NA.

   WPD-3:  If the cascade delegated prefix is an aggregate route of multiple,
           more-specific routes the only IPv6 CE router in
   its own multicast domain.  Every CPE Router in the cascade will send
   MLDv2 Reports with aggregated multicast Group Membership information
   to MUST discard packets
           that match the next upstream router.

   If aggregate route, but not any of the CPE Router hardware includes a network bridge between more-
           specific routes.  In other words, the WAN
   interface and "next-hop" for the LAN interface(s), then
           aggregate route should be the CPE Router MUST support
   MLDv2 snooping as per [RFC4541].

   Consistent with [RFC4605], null destination.  This is
           necessary to prevent forwarding loops when some addresses
           covered by the CPE Router must aggregate are not implement reachable.  [RFC4632]

   WPD-4:  If the IPv6 CE router portion of MLDv2 for 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).

   WPD-5:  An IPv6 CE router MUST not by default initiate any dynamic
           routing protocol on its WAN interface.  Likewise, the

4.2.  LAN
   interfaces on the CPE side configuration

   The IPv6 CE router must not implement an MLDv2 Multicast
   Listener.  However, if a user at home wants distributes configuration information obtained
   during WAN interface provisioning to create a new multicast
   group IPv6 hosts and send multicast data assists IPv6
   hosts in obtaining IPv6 addresses.  It also supports connectivity of
   these devices in the absence of any working WAN interface.

   An IPv6 CE router will be expected to other nodes on support an IPv6 end-user
   network and IPv6 hosts that exhibit the Service Provider
   network, then Protocol Independent Multicast-Source Specific
   Multicast (PIM-SSM) [RFC3569] is recommended following characteristics:

   1.  Link-local addresses are insufficient for allowing IPv6
       applications to handle multicast
   traffic flowing communicate with each other in the upstream direction as a one-to-many multicast
   flow.

8.  Other IPv6 Features

8.1.  Path MTU Discovery Support (MEDIUM)

   GRE tunnels, such as end-user
       network.  The IPv6 CE router will need to IPv4 tunnels (which may enable this
       communication by providing globally-scoped unicast addresses or
       ULAs whether or not WAN connectivity exists.

   2.  IPv6 hosts will be terminated on
   the CPE Router), can modify the default Ethernet MTU capable of 1500 bytes.
   Also, in the future, Ethernet Jumbo frames (> 1500 bytes) using SLAAC and may also be
   supported.  Since the MTU can vary, a newly initiated TCP stream must
   detect capable of
       using DHCP for acquiring their addresses.

   3.  IPv6 hosts will use DHCP for other configuration information,
       such as the largest packet that can be sent DNS_SERVERS option for acquiring DNS information.

   Unless otherwise specified these requirements only apply to the destination without
   fragmentation.  This can be detected using Path MTU Discovery

   [RFC1981].  Routers which may encounter IPv6
   CE router's LAN interfaces.

   Requirements:

   L-1:  The IPv6 CE router MUST support ULA addressing ([RFC4193]).

   L-2:  The IPv6 CE router MUST have a packet too large to be
   forwarded from source to destination may drop the packet and send an
   ICMPv6 Packet Too Big message to ULA prefix that it maintains
         consistently across reboots.  The value of the source. ULA prefix
         SHOULD be user configurable.

   L-3:  The CPE Router must
   route back IPv6 CE router by default MUST act as a site border router
         according to the source any ICMPv6 Packet Too Big messages generated
   anywhere on this path.  Issues section 4.3 of RFC4193 and solutions to problems filter packets with MTUs
   and tunnels are described more fully in [RFC4459].

8.2.  Optional RIPng Support (CORE)
         Local IPv6 source or destination addresses accordingly.

   L-4:  The CPE Router may IPv6 CE router MUST support RIPng routing protocol [RFC2080] so that
   RIPng operates between the CPE Router and the Service Provider
   network.  RIPng has scaling and security implications router behavior of Neighbor
         Discovery for the Service
   Provider network where one Service Provider IPv6 ([RFC4861]).

   L-5:  The IPv6 CE router may terminate
   several tens of thousands of CPE routers.  However, RIPng does
   provide one solution must assign a separate /64 from the CPE Router to the Service Provider
   network for its
         delegated prefix route injection.

8.3.  Automated Tunneling (MEDIUM)

   If the IPv4 address assigned (and ULA prefix if configured to the WAN interface provide ULA
         addressing) for each of its LAN interfaces.  The IPV6 CE router
         MUST make the CPE Router
   is a non-[RFC1918] IPv4 address, and the CPE Router fails to acquire
   an IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring
   the IPv4 address, then interface an advertising interface according to
         RFC4861.  In router advertisements messages, the 6rd tunneling protocol SHOULD Prefix
         Information Option's A/L-bits MUST be enabled
   (if supported).  If 6rd fails set to find a usable relay, then 6to4
   tunneling protocol [RFC3056] 1 by default; the
         A/L bits setting 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 configurable.

   L-6:  The IPv6 CE router MUST support a DHCP server ([RFC3315]) on
         its LAN interfaces.  It SHOULD support DHCP address has been acquired, then assignment
         (IA_NA).

   L-7:  Unless the CPE Router
   retries address acquisition.

   6to4 can be useful IPv6 CE router is configured to support DHCP IA_NA,
         it SHOULD set M=0 and O=1 in the scenario where the Service Provider does
   not yet its RA messages.

   L-8:  The IPv6 CE router MUST support IPv6, but devices providing DNS information in
         the home use IPv6.  An DHCP DNS_SERVERS option ([RFC3646]).

   L-9:  The IPv6
   address is constructed automatically CE router SHOULD pass the additional set of DHCP
         options received from the IPv4 address (V4ADDR)
   configured DHCP client on the its WAN interface using the prefix 2002:V4ADDR::/48.  A
   6to4 tunnel can be automatically created using a pre-configured 6to4
   gateway end-point for from
         the tunnel.

   6rd is similar Service Provider to 6to4, however it uses a service provider prefix
   instead of a well-known prefix. IPv6 hosts.

4.3.  General requirements

   The 6rd relay IPv6 CE router is typically managed
   by responsible for implementing IPv6 routing; that
   is, the service provider.  The 6rd protocol is described more fully in
   draft-townsley-ipv6-6rd [I-D.townsley-ipv6-6rd].  A deployment of 6rd
   is described in draft-despres-6rd [I-D.despres-6rd].

   Several proposals are being considered by IETF related to IPv6 CE router must look up the problem
   of IPv4 IPv6 Destination address depletion, but have not yet achieved working group
   consensus for publication as an RFC.  Dual-stack lite ietf-softwire-
   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
   its routing table to decide to which interface it should send the bis version of
   packet.

   In this document.

8.4.  DNS Support (CORE)

   For local DNS queries for configuration, role, the CPE Router may include a
   DNS server to handle local queries.  Non-local queries can be
   forwarded unchanged to a DNS server specified in IPv6 CE router is responsible for ensuring that
   traffic using its ULA addressing does not go out the DNS server
   DHCPv6 option.  The local DNS server MAY also handle renumbering WAN interface,
   and does not originate from the Service Provider provided prefix for local names used exclusively
   inside the home (the local AAAA WAN interface.

   Requirements:

   G-1:  An IPv6 CE router is an IPv6 node and PTR records are updated).  This
   capability provides connectivity using local DNS names in MUST follow the home
   after a Service Provider renumbering.

8.5.  Quality Of Service(QoS) IPv6 Node
         Requirements [RFC4294] specification.

   G-2:  The CPE IPV6 CE router MAY support differentiated services [RFC2474].

9.  IPv4 Support (CORE)

   IPv4 SHOULD support is largely out of scope for this document.  However, a
   brief overview of current practice in the market may be helpful since the CPE following RFCs:

         *  Internet Protocol, Version 6 (IPv6) Specification [RFC2460]

         *  Stateless Dynamic Host Configuration Protocol (DHCP) Service
            for IPv6 [RFC3736]

         *  Default Router may support both IPv4 Preferences and IPv6.  This section does NOT
   require More-Specific Routes
            [RFC4191]

         *  IP Version 6 Addressing Architecture [RFC4291]

         *  IPv6 Subnet Model: 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] Relationship between Links and Subnet
            Prefixes [I-D.ietf-6man-ipv6-subnet-model]

   G-3:  The IPv6 CE router MUST NOT forward any IPv6 traffic between
         its LAN Interface(s) and its 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 Interface until the
   FTP ALG.  The IPv4 NAT functionality typically router has
         successfully completed the IPv6 address acquisition process.

4.4.  Security Considerations

   It is considered 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 best practice to filter obviously malicious
   traffic (e.g. spoofed packets, "martian" addresses, etc.).  Thus, the
   IPv6 CE router should support IPv4 multicast forwarding ([RFC5135]) and basic firewall
   capabilities.  A stateful firewall can enhance security by examining
   the state of each connection stateless egress and only allow ingress
   filters.  The CE router should also offer mechanisms to filter
   traffic entering the customer network; however, the method by which conforms to
   an expected
   vendors implement configurable packet flow.

10.  DEVICE Constants

   1.  WAN_IP_ACQUIRE_TIMEOUT 180 seconds.

   The default value of WAN_IP_ACQUIRE_TIMEOUT can be overidden by link-
   type specific documents.

11.  Future Work

   All of filtering is beyond the future work has been moved to a bis(updates) version scope
   of this document.

12.  Security Considerations

   Security considerations of a CPE

   Security requirements:

   S-1:  The IPv6 CE router are covered by
   draft-ietf-v6ops-cpe-simple-security SHOULD support
         [I-D.ietf-v6ops-cpe-simple-security].

13.  IANA Considerations

   None.

14.

   S-2:  The IPv6 CE router MUST support ingress filtering in accordance
         with [RFC2827](BCP 38)

5.  Acknowledgements

   Thanks to the following people (in alphabetical order) to Antonio Querubin, Barbara Stark,
   Bernie Volz, for their
   guidance and feedback:

   Mikael Abrahamsson, Scott Beuker, Rex Bullinger, Brian Carpenter, Carlos Pignataro, Dan Wing, David
   Miles,
   Remi Denis-Courmont, Alain Durand, Katsunori Fukuoka, Tony Hain,
   Thomas Herbst, Kevin Johns, Stephen Kramer, Victor Kuarsingh,
   Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark
   Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, David Miles, Shin Miyakawa, Jean-Francois
   Mule, Carlos Pignataro, John Pomeroy, Antonio Querubin, Teemu
   Savolainen, Thomas Herbst, Matt Schmitt, Mark Townsley, Bernie Volz, James Woodyatt,
   Dan Wing and Tony Hain for their
   input Cor Zwart

   This draft is based in part on CableLabs' eRouter specification.  The
   authors wish to acknowledge the document.

15.  References

15.1.  Normative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., additional contributors from the
   eRouter team:

   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 H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., Greg White

6.  Contributors

   The following people have participated as co-authors or provided
   substantial contributions to this document: Ralph Droms, Kirk
   Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay,
   Yiu Lee, John Jason Brzozowski and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

15.2.  Informative Heather Kirksey.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Normative References

   [I-D.baker-ipv6-prefix-subdelegation]
              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]
              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]
              Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
              Model: the Relationship between Links and Subnet
              Prefixes", draft-ietf-6man-ipv6-subnet-model-05 (work in
              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]
              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for  Providing Residential
              IPv6 Internet Service",
              draft-ietf-v6ops-cpe-simple-security-07 (work in
              progress), July 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 Simple Security Capabilities in
              Customer Premises Equipment for IP version 6", RFC 1981, August 1996.

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng  Providing Residential
              IPv6 Internet Service",
              draft-ietf-v6ops-cpe-simple-security-08 (work in
              progress), October 2009.

   [RFC2119]  Bradner, S., "Key words for IPv6", use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2080,
              January 2119, March 1997.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition

   [RFC2464]  Crawford, M., "Transmission of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", Packets over Ethernet
              Networks", RFC 2474, 2464, 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.

   [RFC2827]  Ferguson, P. and K. Moore, "Connection D. Senie, "Network Ingress Filtering:
              Defeating Denial of IPv6 Domains
              via IPv4 Clouds", Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 3056, February 2001. 2827, May 2000.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              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
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3646]  Droms, R., "DNS Configuration options for Dynamic Host
              Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              December 2003.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
              Delegation", RFC 3769, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2)

   [RFC4075]  Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
              Configuration Option for IPv6", DHCPv6", RFC 3810, June 2004. 4075, May 2005.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4241]  Shirasaki, Y., Miyakawa,

   [RFC4242]  Venaas, S., Yamasaki, Chown, T., and A.
              Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet
              Access Service", B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4241, December 4242, November 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
              Network Tunneling",

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4459, 4294,
              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,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("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
              J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
              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
              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

   Hemant Singh
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 1622
   Email: shemant@cisco.com
   URI:   http://www.cisco.com/

   Wes Beebee
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

   Phone: +1 978 936 2030
   Email: wbeebee@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