Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7368

IPv6 Home Networking Architecture Principles

Pages: 49
Informational
Part 1 of 3 – Pages 1 to 11
None   None   Next

Top   ToC   RFC7368 - Page 1
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 Principles

Abstract

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.
Top   ToC   RFC7368 - Page 2
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
Top   ToC   RFC7368 - Page 3
     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
Top   ToC   RFC7368 - Page 4

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
Top   ToC   RFC7368 - Page 5
   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.
Top   ToC   RFC7368 - Page 6
   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
Top   ToC   RFC7368 - Page 7
   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.
Top   ToC   RFC7368 - Page 8

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
Top   ToC   RFC7368 - Page 9
   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
Top   ToC   RFC7368 - Page 10
   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.
Top   ToC   RFC7368 - Page 11

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)

Next Section