[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                           H. Singh
Internet-Draft                                                 W. Beebee
Intended status: Informational                       Cisco Systems, Inc.
Expires: April 29, 2010                                 October 26, 2009

             IPv6 Customer Edge Router Recommendations(bis)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on 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

Singh & Beebee           Expires April 29, 2010                 [Page 1]

Internet-Draft         CPE Router Recommendations           October 2009

   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.


   This document continues the work undertaken by a earlier version of
   this document that has been a IETF v6ops working Group document.  The
   Working Group preferred to expedite the IPv6 CE Router document with
   basic technology requirements.  Any leftover work is continued in
   this document and considered as Phase two effort.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
   3.  Conceptual Configuration Variables . . . . . . . . . . . . . .  3
   4.  CPE Router Behavior in a routed network (MEDIUM) . . . . . . .  3
   5.  IPv6 Data Forwarding (CORE)  . . . . . . . . . . . . . . . . .  4
     5.1.  IPv6 ND Proxy Behavior (MEDIUM)  . . . . . . . . . . . . .  4
     5.2.  IPv6 Multicast Behavior (CORE) . . . . . . . . . . . . . .  5
   6.  Other IPv6 Features  . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  Path MTU Discovery Support (MEDIUM)  . . . . . . . . . . .  5
     6.2.  Optional RIPng Support (CORE)  . . . . . . . . . . . . . .  6
     6.3.  Firewall (DEV) . . . . . . . . . . . . . . . . . . . . . .  6
       6.3.1.  Packet Filters (DEV) . . . . . . . . . . . . . . . . .  6
     6.4.  Zero Configuration Support (MEDIUM)  . . . . . . . . . . .  6
     6.5.  6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)  .  6
     6.6.  DNS Support (DEV)  . . . . . . . . . . . . . . . . . . . .  7
     6.7.  Quality Of Service(QoS)  . . . . . . . . . . . . . . . . .  8
     6.8.  Multi-homed Host Support (MEDIUM)  . . . . . . . . . . . .  8
   7.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2. Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Singh & Beebee           Expires April 29, 2010                 [Page 2]

Internet-Draft         CPE Router Recommendations           October 2009

1.  Introduction

   This document continues the work undertaken by the IPv6 CE Router
   work to incorporate technologies under development or any leftover
   work from the Phase I Working Group document.

   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

      mDNS - Multicast Domain Name System - see http://www.zeroconf.org.

3.  Conceptual Configuration Variables

   The CE Router maintains such a list of conceptual optional
   configuration variables.

   1.  Enable RIPng on the LAN.

   2.  Softwire enable.

   3.  More Specifc Route ([RFC4191]) enable and configure routes.

   4.  If DHCPv6 fails, the CE Router may initiate PPPOE, L2TPv2
       Softwire tunnel, or 6to4 [RFC3056] or 6rd
       (draft-ietf-softwire-ipv6-6rd-01) operation.

   5.  Change ULA on the device.

4.  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 of the
   downstream router may obtain an IA_PD via stateful DHCPv6.  If the
   CPE router supports the routed network through automatic prefix sub-

Singh & Beebee           Expires April 29, 2010                 [Page 3]

Internet-Draft         CPE Router Recommendations           October 2009

   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.

                /-------+------------\    /------------+-----\
        SP <--+ Modem | CPE Router    +--+ CPE Router | WAP + --> PC
                \-------+------------/    \------------+-----/

        WAP = Wireless Access Point

                                 Figure 1.

5.  IPv6 Data Forwarding (CORE)

5.1.  IPv6 ND Proxy Behavior (MEDIUM)

   If the CPE Router has only one /64 prefix to be used across multiple
   LAN interfaces and the CPE Router supports any two LAN interfaces
   that cannot bridge data between them because the two interfaces have
   disparate MAC layers, then the CPE Router MUST support ND Proxy
   [RFC4389].  If any two LAN interfaces support bridging between the
   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.

   2.  Only one /64 is available on the WAN link.

   3.  The link types between the WAN interface and LAN interface(s) are
       disparate and, therefore, can't be bridged.

   4.  No NAT66 is to be used.

   5.  Each LAN interface needs global connectivity.

   6.  Uses SLAAC to configure LAN interface addresses.

   For these legacy 3GPP networks, the CPE Router MUST support ND Proxy
   between the WAN and LAN interface(s).  If a CPE Router will never be
   deployed in an environment with these characteristics, then ND Proxy

Singh & Beebee           Expires April 29, 2010                 [Page 4]

Internet-Draft         CPE Router Recommendations           October 2009

   is not necessary.

5.2.  IPv6 Multicast Behavior (CORE)

   The CPE Router SHOULD follow the model described for MLD Proxy in
   [RFC4605] to implement multicast.  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 of [RFC3810] do
   not apply to the CPE Router (even when the home has multiple cascaded
   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
   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
   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

6.  Other IPv6 Features

6.1.  Path MTU Discovery Support (MEDIUM)

   GRE tunnels, such as IPv6 to IPv4 tunnels (which may be terminated on
   the CPE Router), can modify the default Ethernet MTU of 1500 bytes.
   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
   forwarded from source to destination may drop the packet and send an
   ICMPv6 Packet Too Big message to the source.  The CPE Router must
   route back to the source any ICMPv6 Packet Too Big messages generated
   anywhere on this path.  Issues and solutions to problems with MTUs
   and tunnels are described more fully in [RFC4459].

Singh & Beebee           Expires April 29, 2010                 [Page 5]

Internet-Draft         CPE Router Recommendations           October 2009

6.2.  Optional RIPng Support (CORE)

   The CPE Router may support RIPng routing protocol [RFC2080] so that
   RIPng operates between the CPE Router and the Service Provider
   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.

6.3.  Firewall (DEV)

   The CE Router must support an IPv6 Firewall feature.  The firewall
   may include features like access-control lists.  The firewall may
   support interpretation or recognition of most IPv6 extension header
   information including inspecting fragmentation header.  The firewall
   must support stateful and stateless Packet Filters as follows.

6.3.1.  Packet Filters (DEV)

   The CE Router must support packet filtering based on IP headers,
   extended headers, UDP and TCP ports etc.  There are numerous filters
   mentioned (section 3.2) in draft-ietf-v6ops-cpe-simple-security
   [I-D.ietf-v6ops-cpe-simple-security], like some that allow IKE, IPSec
   packets while another filter may block Teredo packets.

   It is possible that in future, IPv6 global unicast prefix can expand
   beyond its existing range.  Therefore the CE Router MUST not have
   hard coded filters tied to only allow prefixes in a given range.

   6to4 or 6rd tunnels may be initiated by hosts behind the CE Router.
   The CE Router MUST NOT block 6to4 or 6rd packets without a
   configurable override.

6.4.  Zero Configuration Support (MEDIUM)

   The CE Router MAY support manual configuration via the web using a
   URL string like http://router.local as per mDNS described in the
   Terminology and Abbreviations section.  Note that mDNS is a link-
   local protocol, so extra functionality is required if configuration
   is to be supported over cascaded routers.  Support of configuration
   through cascaded routers is beyond the scope of this document.

6.5.  6to4 Automated Tunneling (MEDIUM)/Dual-Stack Lite (DEV)

   If the IPv4 address assigned to the WAN interface of the CE Router is
   a non-[RFC1918] IPv4 address, and the CE Router fails to acquire an
   IPv6 address before WAN_IP_ACQUIRE_TIMEOUT seconds after acquiring

Singh & Beebee           Expires April 29, 2010                 [Page 6]

Internet-Draft         CPE Router Recommendations           October 2009

   the IPv4 address, then the 6to4 tunneling protocol [RFC3056] SHOULD
   be enabled automatically, allowing tunneling of IPv6 packets over
   IPv4 without requiring user configuration.  If an anycast 6to4 server
   cannot be located to establish IPv6 connectivity over the IPv4
   network.  If an IPv6 address is acquired, but no IPv4 address is
   acquired before WAN_IP_ACQUIRE_TIMEOUT seconds after the IPv6 address
   was acquired, then the CE Router SHOULD use DS-Lite and disable NAT44
   in the CE Router.  If both IPv6 and IPv4 addresses are acquired
   within WAN_IP_ACQUIRE_TIMEOUT seconds of each other, then the CE
   Router operates in dual stack mode, and does not need either 6to4 or
   DS-Lite.  If no IPv4 and no IPv6 address has been acquired, then the
   CE Router retries acquisition.

   6to4 can be useful in the scenario where the Service Provider does
   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.

   Several proposals are being considered by IETF related to the problem
   of IPv4 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
   CE Router to support features such as v4 in v6 encapsulation and
   softwires.  Further, any approach which requires the use of a tunnel
   MUST take into account the reduced MTU.  The tunnel software on the
   CE Router MUST be capable of fragmenting data packets.

   For DS-Lite, the CE Router also discovers the IPv6 address of the
   Carrier Grade NAT node in the deployment.  The ietf-softwire-dual-
   stack-lite-00 [I-D.ietf-softwire-dual-stack-lite] draft has yet to
   fully describe the method of discovery.

6.6.  DNS Support (DEV)

   For local DNS queries for configuration, the CE Router may include a
   DNS server to handle local queries.  Non-local queries can be
   forwarded unchanged to a DNS server specified in the DNS server
   DHCPv6 option.  The CE Router may also include DNS64 functionality
   which is specified in draft-bagnulo-behave-dns64
   [I-D.bagnulo-behave-dns64].  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.  A CE Router
   MAY add local DNS entries based on dynamic requests from the LAN
   segment(s).  The protocol to carry such requests from hosts to the CE

Singh & Beebee           Expires April 29, 2010                 [Page 7]

Internet-Draft         CPE Router Recommendations           October 2009

   Router is yet to be described.

6.7.  Quality Of Service(QoS)

   The CPE router MAY support differentiated services [RFC2474].

6.8.  Multi-homed Host Support (MEDIUM)

   The CE Router MAY support [RFC4191] on its LAN interfaces.  Small
   consumer embedded multi-homed hosts in the home may not have
   configurable routing tables.  The CE Router can communicate More
   Specific Routes (MSRs) to these hosts to allow them to choose a
   preferred router to send traffic to for traffic destined to specific
   prefixes configured through manual configuration.  Advertisement of
   MSRs through RAs is turned off by default.

7.  Future Work

   1.  Enumerate requirements in list form (to be done after
       requirements are solidified).

8.  Security Considerations

   Security considerations of a CE router are covered by

9.  IANA Considerations


10.  Acknowledgements

   Thanks (in alphabetical order) to Antonio Querubin, Barbara Stark,
   Bernie Volz, Brian Carpenter, Carlos Pignataro, Dan Wing, David
   Miles, Francois-Xavier Le Bail, Fred Baker, James Woodyatt, Mark
   Townsley, Mikael Abrahamsson, Ole Troan, Remi Denis-Courmont, Shin
   Miyakawa, Teemu Savolainen, Thomas Herbst, and Tony Hain for their
   input on the document.

11.  References

Singh & Beebee           Expires April 29, 2010                 [Page 8]

Internet-Draft         CPE Router Recommendations           October 2009

11.1.  Normative References

11.2.  Informative References

              Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and
              M. Endo, "DNS64: DNS extensions for Network Address
              Translation from IPv6 Clients to  IPv4 Servers",
              draft-bagnulo-behave-dns64-02 (work in progress),
              March 2009.

              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.

              Storer, B., Pignataro, C., Santos, M., Stevant, B., and J.
              Tremblay, "Softwire Hub & Spoke Deployment Framework with
              L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-13 (work
              in progress), April 2009.

              Woodyatt, J., "Recommended Simple Security Capabilities in
              Customer Premises Equipment for  Providing Residential
              IPv6 Internet Service",
              draft-ietf-v6ops-cpe-simple-security-08 (work in
              progress), October 2009.

   [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.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

Singh & Beebee           Expires April 29, 2010                 [Page 9]

Internet-Draft         CPE Router Recommendations           October 2009

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [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
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4214]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", RFC 4214, October 2005.

   [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", 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,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", RFC 4605, August 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

Singh & Beebee           Expires April 29, 2010                [Page 10]

Internet-Draft         CPE Router Recommendations           October 2009

Authors' Addresses

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

   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

   Phone: +1 978 936 2030
   Email: wbeebee@cisco.com
   URI:   http://www.cisco.com/

Singh & Beebee           Expires April 29, 2010                [Page 11]