RFC 7368
IPv6 Home Networking Architecture Principles
Pages: 49
Informational
Informational
Part 1 of 3 – Pages 1 to 11
Internet Engineering Task Force (IETF) T. Chown, Ed. Request for Comments: 7368 University of Southampton Category: Informational J. Arkko ISSN: 2070-1721 Ericsson A. Brandt Sigma Designs O. Troan Cisco Systems, Inc. J. Weil Time Warner Cable October 2014 IPv6 Home Networking Architecture PrinciplesAbstract
This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7368.
Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . 6 2.1. Multiple Subnets and Routers . . . . . . . . . . . . . . 7 2.2. Global Addressability and Elimination of NAT . . . . . . 8 2.3. Multi-Addressing of Devices . . . . . . . . . . . . . . . 8 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9 2.5. Avoiding Manual Configuration of IP Addresses . . . . . . 10 2.6. IPv6-Only Operation . . . . . . . . . . . . . . . . . . . 11 3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11 3.1. General Principles . . . . . . . . . . . . . . . . . . . 12 3.1.1. Reuse Existing Protocols . . . . . . . . . . . . . . 12 3.1.2. Minimise Changes to Hosts and Routers . . . . . . . . 13 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Supporting Arbitrary Topologies . . . . . . . . . . . 13 3.2.2. Network Topology Models . . . . . . . . . . . . . . . 14 3.2.3. Dual-Stack Topologies . . . . . . . . . . . . . . . . 18 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19 3.2.5. Mobility Support . . . . . . . . . . . . . . . . . . 20 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 21 3.3.1. Differentiating Neighbouring Homenets . . . . . . . . 21 3.3.2. Largest Practical Subnets . . . . . . . . . . . . . . 21 3.3.3. Handling Varying Link Technologies . . . . . . . . . 22 3.3.4. Homenet Realms and Borders . . . . . . . . . . . . . 22 3.3.5. Configuration Information from the ISP . . . . . . . 23 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . 24 3.4.1. Use of ISP-Delegated IPv6 Prefixes . . . . . . . . . 24 3.4.2. Stable Internal IP Addresses . . . . . . . . . . . . 26 3.4.3. Internal Prefix Delegation . . . . . . . . . . . . . 27 3.4.4. Coordination of Configuration Information . . . . . . 28 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Routing Functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Unicast Routing within the Homenet . . . . . . . . . 30
3.5.2. Unicast Routing at the Homenet Border . . . . . . . . 31
3.5.3. Multicast Support . . . . . . . . . . . . . . . . . . 31
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.1. Addressability vs. Reachability . . . . . . . . . . . 32
3.6.2. Filtering at Borders . . . . . . . . . . . . . . . . 33
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . 34
3.6.4. Exfiltration Concerns . . . . . . . . . . . . . . . . 34
3.6.5. Device Capabilities . . . . . . . . . . . . . . . . . 34
3.6.6. ULAs as a Hint of Connection Origin . . . . . . . . . 35
3.7. Naming and Service Discovery . . . . . . . . . . . . . . 35
3.7.1. Discovering Services . . . . . . . . . . . . . . . . 35
3.7.2. Assigning Names to Devices . . . . . . . . . . . . . 36
3.7.3. The Homenet Name Service . . . . . . . . . . . . . . 37
3.7.4. Name Spaces . . . . . . . . . . . . . . . . . . . . . 38
3.7.5. Independent Operation . . . . . . . . . . . . . . . . 40
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 40
3.7.7. DNS Resolver Discovery . . . . . . . . . . . . . . . 41
3.7.8. Devices Roaming to/from the Homenet . . . . . . . . . 41
3.8. Other Considerations . . . . . . . . . . . . . . . . . . 41
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . 41
3.8.2. Operations and Management . . . . . . . . . . . . . . 42
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 43
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. Normative References . . . . . . . . . . . . . . . . . . 44
6.2. Informative References . . . . . . . . . . . . . . . . . 44
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
This document focuses on evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing, as well as the associated challenges with their deployment and operation. There is a growing trend in home networking for the proliferation of networking technology through an increasingly broad range of devices and media. This evolution in scale and diversity sets requirements on IETF protocols. Some of these requirements relate to the introduction of IPv6, while others relate to the introduction of specialised networks for home automation and sensors. While at the time of writing some complex home network topologies exist, most are relatively simple single subnet networks and ostensibly operate using just IPv4. While there may be IPv6 traffic within the network, e.g., for service discovery, the homenet is provisioned by the ISP as an IPv4 network. Such networks also typically employ solutions that should be avoided, such as private [RFC1918] addressing with (cascaded) Network Address Translation (NAT) [RFC3022], or they may require expert assistance to set up. In contrast, emerging IPv6-capable home networks are very likely to have multiple internal subnets, e.g., to facilitate private and guest networks, heterogeneous link layers, and smart grid components, and have enough address space available to allow every device to have a globally unique address. This implies that internal routing functionality is required, and that the homenet's ISP delegates a large enough address block, to allow assignment of a prefix to each subnet in the home network. It is not practical to expect home users to configure their networks. Thus, the assumption of this document is that the homenet is as far as possible self-organising and self-configuring, i.e., it should function without proactive management by the residential user. The architectural constructs in this document are focused on the problems to be solved when introducing IPv6, with an eye towards a better result than what we have today with IPv4, as well as aiming for a more consistent solution that addresses as many of the identified requirements as possible. This document aims to provide the basis and guiding principles for how standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be employed in home networking, while coexisting with existing IPv4 mechanisms. In emerging dual- stack home networks, it is vital that introducing IPv6 does not adversely affect IPv4 operation. We assume that the IPv4 network architecture in home networks is what it is and cannot be modified by new recommendations. This document does not discuss how IPv4 home
networks provision or deliver support for multiple subnets. It should not be assumed that any future new functionality created with IPv6 in mind will be backward compatible to include IPv4 support. Further, future deployments, or specific subnets within an otherwise dual-stack home network, may be IPv6-only, in which case considerations for IPv4 impact would not apply. This document proposes a baseline homenet architecture, using protocols and implementations that are as far as possible proven and robust. The scope of the document is primarily the network-layer technologies that provide the basic functionality to enable addressing, connectivity, routing, naming, and service discovery. While it may, for example, state that homenet components must be simple to deploy and use, it does not discuss specific user interfaces, nor does it discuss specific physical, wireless, or data- link-layer considerations. Likewise, we also do not specify the whole design of a homenet router from top to bottom; rather, we focus on the Layer 3 aspects. This means that Layer 2 is largely out of scope, we're assuming a data-link layer that supports IPv6 is present, and we react accordingly. Any IPv6-over-Foo definitions occur elsewhere. [RFC7084], which has obsoleted [RFC6204], defines basic requirements for Customer Edge (CE) routers. The update includes the definition of requirements for specific transition tools on the CE router, specifically Dual-Stack Lite (DS-Lite) [RFC6333] and IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]. Such detailed specification of CE router devices is considered out of scope of this architecture document, and we assume that any required update of the CE router device specification as a result of adopting this architecture will be handled as separate and specific updates to these existing documents. Further, the scope of this text is the internal homenet, and thus specific features on the WAN side of the CE router are out of scope for this text.1.1. Terminology and Abbreviations
In this section, we define terminology and abbreviations used throughout the text. o Border: A point, typically resident on a router, between two networks, e.g., between the main internal homenet and a guest network. This defines a point(s) at which filtering and forwarding policies for different types of traffic may be applied. o CE router: Customer Edge router. A border router intended for use in a homenet. A CE router connects the homenet to a service provider network.
o FQDN: Fully Qualified Domain Name. A globally unique name.
o Guest network: A part of the home network intended for use by
visitors or guests to the home(net). Devices on the guest network
may typically not see or be able to use all services in the
home(net).
o Homenet: A home network, comprising host and router equipment,
with one or more CE routers providing connectivity to a service
provider network(s).
o ISP: Internet Service Provider. An entity that provides access to
the Internet. In this document, a service provider specifically
offers Internet access using IPv6 and may also offer IPv4 Internet
access. The service provider can provide such access over a
variety of different transport methods such as DSL, cable,
wireless, and others.
o LLN: Low-power and Lossy Network.
o LQDN: Locally Qualified Domain Name. A name local to the homenet.
o NAT: Network Address Translation. Typically referring to IPv4
Network Address Port Translation (NAPT) [RFC3022].
o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296].
o PCP: Port Control Protocol [RFC6887].
o Realm: A network delimited by a defined border. A guest network
within a homenet may form one realm.
o 'Simple Security': Defined in [RFC4864] and expanded further in
[RFC6092]; describes recommended perimeter security capabilities
for IPv6 networks.
o ULA: IPv6 Unique Local Address [RFC4193].
o VM: Virtual Machine.
2. Effects of IPv6 on Home Networking
While IPv6 resembles IPv4 in many ways, there are some notable
differences in the way it may typically be deployed. It changes
address allocation principles, making multi-addressing the norm, and
through the vastly increased address space, it allows globally unique
IP addresses to be used for all devices in a home network. This
section presents an overview of some of the key implications of the
introduction of IPv6 for home networking that are simultaneously both promising and problematic.2.1. Multiple Subnets and Routers
While simple Layer 3 topologies involving as few subnets as possible are preferred in home networks, the incorporation of dedicated (routed) subnets remains necessary for a variety of reasons. For instance, an increasingly common feature in modern home routers is the ability to support both guest and private network subnets. Likewise, there may be a need to separate home automation or corporate extension LANs (whereby a home worker can have their corporate network extended into the home using a virtual private network, commonly presented as one port on an Ethernet device) from the main Internet access network, or different subnets may in general be associated with parts of the homenet that have different routing and security policies. Further, link-layer networking technology is poised to become more heterogeneous as networks begin to employ both traditional Ethernet technology and link layers designed for Low- power and Lossy Networks (LLNs), such as those used for certain types of sensor devices. Constraining the flow of certain traffic from Ethernet links to links of much lower capacity thus becomes an important topic. The introduction of IPv6 for home networking makes it possible for every home network to be delegated enough address space from its ISP to provision globally unique prefixes for each such subnet in the home. While the number of addresses in a standard /64 IPv6 prefix is practically unlimited, the number of prefixes available for assignment to the home network is not. As a result, the growth inhibitor for the home network shifts from the number of addresses to the number of prefixes offered by the provider; this topic is discussed in BCP 157 [RFC6177], which recommends that "end sites always be able to obtain a reasonable amount of address space for their actual and planned usage." The addition of routing between subnets raises a number of issues. One is a method by which prefixes can be efficiently allocated to each subnet, without user intervention. Another issue is how to extend mechanisms such as zero-configuration service discovery that currently only operate within a single subnet using link-local traffic. In a typical IPv4 home network, there is only one subnet, so such mechanisms would normally operate as expected. For multi- subnet IPv6 home networks, there are two broad choices to enable such protocols to work across the scope of the entire homenet: extend existing protocols to work across that scope or introduce proxies for existing link-layer protocols. This topic is discussed in Section 3.7.
2.2. Global Addressability and Elimination of NAT
The possibility for direct end-to-end communication on the Internet to be restored by the introduction of IPv6 is, on the one hand, an incredible opportunity for innovation and simpler network operation, but on the other hand, it is also a concern as it potentially exposes nodes in the internal networks to receipt of unwanted and possibly malicious traffic from the Internet. With devices and applications able to talk directly to each other when they have globally unique addresses, there may be an expectation of improved host security to compensate for this. It should be noted that many devices may (for example) ship with default settings that make them readily vulnerable to compromise by external attackers if globally accessible, or they may simply not be robust by design because it was assumed that either such devices would only be used on private networks or the devices don't have the computing power to apply the necessary security methods. In addition, the upgrade cycle for devices (or their firmware) may be slow and/or lack auto-update mechanisms. It is thus important to distinguish between addressability and reachability. While IPv6 offers global addressability through the use of globally unique addresses in the home, whether devices are globally reachable or not would depend on any firewall or filtering configuration, and not, as is commonly the case with IPv4, the presence or use of NAT. In this respect, IPv6 networks may or may not have filters applied at their borders to control such traffic, i.e., at the homenet CE router. [RFC4864] and [RFC6092] discuss such filtering and the merits of 'default allow' against 'default deny' policies for external traffic initiated into a homenet. This topic is discussed further in Section 3.6.1.2.3. Multi-Addressing of Devices
In an IPv6 network, devices will often acquire multiple addresses, typically at least a link-local address and one or more globally unique addresses (GUAs). Where a homenet is multihomed, a device would typically receive a GUA from within the delegated prefix from each upstream ISP. Devices may also have an IPv4 address if the network is dual stack, an IPv6 Unique Local Address (ULA) [RFC4193] (see below), and one or more IPv6 privacy addresses [RFC4941]. It should thus be considered the norm for devices on IPv6 home networks to be multi-addressed and to need to make appropriate address selection decisions for the candidate source and destination address pairs for any given connection. In multihoming scenarios, nodes will be configured with one address from each upstream ISP
prefix. In such cases, the presence of upstream ingress filtering as described in BCP 38 [RFC2827] requires such multi-addressed nodes to select the correct source address to be used for the corresponding uplink. Default address selection for IPv6 [RFC6724] provides a solution for this, but a challenge here is that the node may not have the information it needs to make that decision based on addresses alone. We discuss this challenge in Section 3.2.4.2.4. Unique Local Addresses (ULAs)
[RFC4193] defines ULAs for IPv6 that may be used to address devices within the scope of a single site. Support for ULAs for IPv6 CE routers is described in [RFC7084]. A home network running IPv6 should deploy ULAs alongside its globally unique prefix(es) to allow stable communication between devices (on different subnets) within the homenet where that externally allocated globally unique prefix may change over time, e.g., due to renumbering within the subscriber's ISP, or where external connectivity may be temporarily unavailable. A homenet using provider-assigned global addresses is exposed to its ISP renumbering the network to a much larger degree than before whereas, for IPv4, NAT isolated the user against ISP renumbering to some extent. While setting up a network, there may be a period where it has no external connectivity, in which case ULAs would be required for inter-subnet communication. In the case where home automation networks are being set up in a new home/deployment (as early as during construction of the home), such networks will likely need to use their own /48 ULA prefix. Depending upon circumstances beyond the control of the owner of the homenet, it may be impossible to renumber the ULA used by the home automation network so routing between ULA /48s may be required. Also, some devices, particularly constrained devices, may have only a ULA (in addition to a link- local), while others may have both a GUA and a ULA. Note that unlike private IPv4 space as described in RFC 1918, the use of ULAs does not imply use of an IPv6 equivalent of a traditional IPv4 NAT [RFC3022] or of NPTv6 prefix-based NAT [RFC6296]. When an IPv6 node in a homenet has both a ULA and a globally unique IPv6 address, it should only use its ULA address internally and use its additional globally unique IPv6 address as a source address for external communications. This should be the natural behaviour given support for default address selection for IPv6 [RFC6724]. By using such globally unique addresses between hosts and devices in remote networks, the architectural cost and complexity, particularly to applications, of NAT or NPTv6 translation are avoided. As such, neither IPv6 NAT nor NPTv6 is recommended for use in the homenet architecture. Further, the homenet border router(s) should filter
packets with ULA source/destination addresses as discussed in Section 3.4.2. Devices in a homenet may be given only a ULA as a means to restrict reachability from outside the homenet. ULAs can be used by default for devices that, without additional configuration (e.g., via a web interface), would only offer services to the internal network. For example, a printer might only accept incoming connections on a ULA until configured to be globally reachable, at which point it acquires a global IPv6 address and may be advertised via a global name space. Where both a ULA and a global prefix are in use, the ULA source address is used to communicate with ULA destination addresses when appropriate, i.e., when the ULA source and destination lie within the /48 ULA prefix(es) known to be used within the same homenet. In cases where multiple /48 ULA prefixes are in use within a single homenet (perhaps because multiple homenet routers each independently auto-generate a /48 ULA prefix and then share prefix/routing information), utilising a ULA source address and a ULA destination address from two disjoint internal ULA prefixes is preferable to using GUAs. While a homenet should operate correctly with two or more /48 ULAs enabled, a mechanism for the creation and use of a single /48 ULA prefix is desirable for addressing consistency and policy enforcement. A counter argument to using ULAs is that it is undesirable to aggressively deprecate global prefixes for temporary loss of connectivity, so for a host to lose its global address, there would have to be a connection breakage longer than the lease period, and even then, deprecating prefixes when there is no connectivity may not be advisable. However, it is assumed in this architecture that homenets should support and use ULAs.2.5. Avoiding Manual Configuration of IP Addresses
Some IPv4 home networking devices expose IPv4 addresses to users, e.g., the IPv4 address of a home IPv4 CE router that may be configured via a web interface. In potentially complex future IPv6 homenets, users should not be expected to enter IPv6 literal addresses in devices or applications, given their much greater length and the apparent randomness of such addresses to a typical home user. Thus, even for the simplest of functions, simple naming and the associated (minimal, and ideally zero configuration) discovery of services are imperative for the easy deployment and use of homenet devices and applications.
2.6. IPv6-Only Operation
It is likely that IPv6-only networking will be deployed first in new home network deployments, often referred to as 'greenfield' scenarios, where there is no existing IPv4 capability, or perhaps as one element of an otherwise dual-stack network. Running IPv6-only adds additional requirements, e.g., for devices to get configuration information via IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP) and for devices to be able to initiate communications to external devices that are IPv4-only. Some specific transition technologies that may be deployed by the homenet's ISP are discussed in [RFC7084]. In addition, certain other functions may be desirable on the CE router, e.g., to access content in the IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable. The widespread availability of robust solutions to these types of requirements will help accelerate the uptake of IPv6-only homenets. The specifics of these are, however, beyond the scope of this document, especially those functions that reside on the CE router.
(page 11 continued on part 2)