tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7368

Informational
Pages: 49
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: HOMENET

IPv6 Home Networking Architecture Principles

Part 1 of 3, p. 1 to 11
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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 RFC Part