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]