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) draft-wbeebee-v6ops-ipv6-cpe-router-bis-01 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 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. Abstract 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 flow. 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 draft-ietf-v6ops-cpe-simple-security [I-D.ietf-v6ops-cpe-simple-security]. 9. IANA Considerations None. 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 [I-D.bagnulo-behave-dns64] 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. [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-softwire-hs-framework-l2tpv2] 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. [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-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 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/ Singh & Beebee Expires April 29, 2010 [Page 11]