RFC 7368
IPv6 Home Networking Architecture Principles
RFC 7368: IPv6 Home Networking Architecture Principles 🏡✨
okay bestie, this is the front matter, so it's all the "who made this and what is it" stuff 💅
- Request for Comments: 7368
- Category: Informational 📘 (published for information, not a Standards Track spec)
- ISSN: 2070-1721
- Date: October 2014 🗓️
- Editor: T. Chown, Ed. (University of Southampton) 🎓
- Authors: J. Arkko (Ericsson), A. Brandt (Sigma Designs), O. Troan (Cisco Systems, Inc.), J. Weil (Time Warner Cable)
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙈
Abstract 🌸
so the vibe here is that home networks keep getting more devices and more internal routing, and this doc is basically the blueprint for an IPv6-based home network 🏠🧚
It describes where residential home networks are heading, with more and more devices and a growing trend toward more internal routing. The goal is to lay out a general architecture for IPv6-based home networking, including the principles, things to consider, and requirements that come with it. It quickly calls out what IPv6 changes for home networking, walks through the parts of the architecture, and suggests how standard IPv6 mechanisms and addressing can be used at home. It also admits that some extra functionality will need specific protocol extensions 🔧. The big assumption is that the home network isn't actively managed and runs either IPv6-only or dual-stack. There's nothing in here about the IPv4 side of things 🙅♀️
Status of This Memo 📝
This document isn't an Internet Standards Track specification. It's published for informational purposes 📘
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). ngl, not every IESG-approved doc is going to be a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🤓
For the current status, any errata, and how to send feedback, check 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) as they're in effect on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 🧾 Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 . . . . . . . . . . . . . . . . . . . . . . . 49part 1 of 12 done, the real architecture starts next 🌈💖 stay tuned, bestie 🧚
1. Introduction ✨
okay bestie, let's get into it 🎀 this doc is all about homenet tech, which is the stuff inside your house's network as more and more devices get connected and the internal routing gets way more complicated. there's a growing trend of networking tech showing up in a wild range of devices and media, and that scale and diversity sets requirements on IETF protocols 💅 some of those requirements are about bringing in IPv6, and others are about specialised networks for home automation and sensors 🌸
so right now, most home networks are pretty simple single subnet setups that basically run just IPv4 🙈 there might be some IPv6 traffic floating around, e.g., for service discovery, but the ISP provisions the homenet as an IPv4 network. these networks also usually use stuff that should be avoided, like private [RFC1918] addressing with (cascaded) Network Address Translation (NAT) [RFC3022], or they need an expert to set them up. not it 😭
emerging IPv6-capable homenets are a whole different vibe 🦋 they're very likely to have multiple internal subnets, e.g., for private and guest networks, heterogeneous link layers, and smart grid components, and there's enough address space for every device to get a globally unique address. this means internal routing functionality is required, and the homenet's ISP has to delegate a big enough address block so each subnet in the home network can get its own prefix 👑
it's not practical to expect home users to configure their networks, so the assumption here 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 focus on the problems to be solved when introducing IPv6, with an eye towards a better result than what we have today with IPv4 ✨ they're also aiming for a more consistent solution that addresses as many of the identified requirements as possible. this doc 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 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 doc proposes a baseline homenet architecture, using protocols and implementations that are as far as possible proven and robust 💖 the scope 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 don't specify the whole design of a homenet router from top to bottom; rather, we focus on the Layer 3 aspects. this means 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, so specific features on the WAN side of the CE router are out of scope for this text 💅
1.1. Terminology and Abbreviations 🍓
okay so here are the terms we use all over the doc, no cap 📖
- 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. 🚧
- 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. 🛜
- FQDN: Fully Qualified Domain Name. a globally unique name. 🌐
- 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). 🙋♀️
- Homenet: a home network, comprising host and router equipment, with one or more CE routers providing connectivity to a service provider network(s). 🏠
- 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. 📡
- LLN: Low-power and Lossy Network. 🪫
- LQDN: Locally Qualified Domain Name. a name local to the homenet. 🏡
- NAT: Network Address Translation. typically referring to IPv4 Network Address Port Translation (NAPT) [RFC3022]. 🔁
- NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296]. 🪞
- PCP: Port Control Protocol [RFC6887]. 🔌
- Realm: a network delimited by a defined border. a guest network within a homenet may form one realm. 👯
- 'Simple Security': defined in [RFC4864] and expanded further in [RFC6092]; describes recommended perimeter security capabilities for IPv6 networks. 🔒
- ULA: IPv6 Unique Local Address [RFC4193]. 🫧
- VM: Virtual Machine. 💻
2. Effects of IPv6 on Home Networking 🌈
okay so IPv6 looks a lot like IPv4, but there are some notable differences in how it's typically deployed ✨ it changes address allocation principles, making multi-addressing the norm, and thanks to the vastly increased address space, it allows globally unique IP addresses for all devices in a home network 🤯 this section gives an overview of some of the key implications of bringing IPv6 into home networking, which are both promising and problematic at the same time 💀
2.1. Multiple Subnets and Routers 🏘️
simple Layer 3 topologies with as few subnets as possible are preferred in home networks, BUT dedicated (routed) subnets are still necessary for a bunch of reasons 💅 for instance, a super common feature in modern home routers is supporting both guest and private network subnets. there may also be a need to separate home automation or corporate extension LANs (like when a home worker extends their corporate network into the house using a virtual private network, usually presented as one port on an Ethernet device) from the main Internet access network 💼. or different subnets may be tied to parts of the homenet with different routing and security policies 🔐. further, link-layer networking tech is poised to get more heterogeneous as networks start using both traditional Ethernet and link layers designed for Low-power and Lossy Networks (LLNs), like the ones used for certain sensor devices 🌡️. so constraining the flow of certain traffic from Ethernet links to links of much lower capacity becomes an important topic 🚦
the introduction of IPv6 makes it possible for every home network to be delegated enough address space from its ISP to provision globally unique prefixes for each 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 😮💨 so the growth inhibitor for the home network shifts from the number of addresses to the number of prefixes the provider offers. 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 few issues 👀 one is a method by which prefixes can be efficiently allocated to each subnet, without user intervention. another is how to extend mechanisms like zero-configuration service discovery, which currently only work within a single subnet using link-local traffic. in a typical IPv4 home network there's only one subnet, so those mechanisms normally work as expected 🙌 for multi-subnet IPv6 home networks, there are two broad choices to make these protocols work across 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 🌍
Okay so, IPv6 bringing back direct end-to-end communication on the Internet is an incredible opportunity ✨ for innovation and simpler network operation. But ngl, it's also kind of a concern, because it can potentially expose the nodes in your internal networks to unwanted and possibly malicious traffic from the Internet 😭
When devices and applications can talk directly to each other because they have globally unique addresses, there may be an expectation of better host security to make up for it. Here's the tea though: many devices may (for example) ship with default settings that make them super easy to compromise by external attackers if they're globally accessible 💀. Or they may just not be robust by design, because people assumed those devices would only ever be used on private networks, or because the devices don't have the computing power to apply the necessary security methods. Plus, the upgrade cycle for devices (or their firmware) may be slow and/or lack auto-update mechanisms. Not it 🙈.
So it is important to tell apart addressability and reachability 🎀. IPv6 gives you global addressability through globally unique addresses in the home, but whether devices are globally reachable would depend on any firewall or filtering configuration. It would not depend on the presence or use of NAT, which is how it usually works with IPv4. In this respect, IPv6 networks may or may not have filters applied at their borders to control that traffic, i.e., at the homenet CE router 🧚. [RFC4864] and [RFC6092] talk about such filtering and the merits of 'default allow' against 'default deny' policies for external traffic initiated into a homenet. We'll get into this more in Section 3.6.1 💅.
2.3. Multi-Addressing of Devices 🦋
In an IPv6 network, devices will often pick up multiple addresses 💜. Typically they get at least a link-local address and one or more globally unique addresses (GUAs). If 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] (more on that below), and one or more IPv6 privacy addresses [RFC4941].
So it should 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 those cases, upstream ingress filtering as described in BCP 38 [RFC2827] means multi-addressed nodes have to select the correct source address for the corresponding uplink 🔥. Default address selection for IPv6 [RFC6724] is the solution here, but the challenge is that the node may not have the information it needs to make that decision based on addresses alone 😩. We dig into this challenge in Section 3.2.4 🫶.
2.4. Unique Local Addresses (ULAs) 🌸
[RFC4193] defines ULAs for IPv6, which 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), so devices on different subnets can have stable communication within the homenet. This matters because the externally allocated globally unique prefix may change over time, e.g., due to renumbering within the subscriber's ISP, or when external connectivity is temporarily unavailable 🌈. A homenet using provider-assigned global addresses is exposed to its ISP renumbering the network to a much larger degree than before. With IPv4, NAT isolated the user against ISP renumbering to some extent, so this is a real glow-up in the wrong direction 😭.
While setting up a network, there may be a period with no external connectivity, and in that case ULAs would be required for inter-subnet communication ⭐. If home automation networks are being set up in a new home or deployment (as early as during construction of the home), those networks will likely need to use their own /48 ULA prefix. Depending on circumstances beyond the control of the homenet's owner, 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, using ULAs does not imply using an IPv6 equivalent of a traditional IPv4 NAT [RFC3022] or 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 globally unique addresses between hosts and devices in remote networks, we avoid the architectural cost and complexity (particularly for applications) of NAT or NPTv6 translation. So 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 way 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 it's configured to be globally reachable. At that point it acquires a global IPv6 address and may be advertised via a global name space 🖨️✨.
When both a ULA and a global prefix are in use, the ULA source address is used to communicate with ULA destination addresses when appropriate. That's 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), using a ULA source address and a ULA destination address from two disjoint internal ULA prefixes is preferable to using GUAs 💅.
A homenet should operate correctly with two or more /48 ULAs enabled. Still, a mechanism for creating and using a single /48 ULA prefix is desirable for addressing consistency and policy enforcement 🧁.
Now, the counter argument to using ULAs: it's 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. 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 into devices or applications 😵. These addresses are much longer, and they look totally random to a typical home user. So even for the simplest functions, simple naming and the associated (minimal, and ideally zero configuration) discovery of services are imperative for easy deployment and use of homenet devices and applications 🍓.
2.6. IPv6-Only Operation 🌙
IPv6-only networking will likely get deployed first in new home network deployments, often called 'greenfield' scenarios 🌱. These are places where there is no existing IPv4 capability, or it may be one element of an otherwise dual-stack network. Running IPv6-only adds extra requirements, e.g., devices need to get configuration information over IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), and devices need 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]. There are also other functions that may be desirable on the CE router. For example, 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 speed up the uptake of IPv6-only homenets 🚀. The specifics are, however, beyond the scope of this document, especially the functions that reside on the CE router 🫧.
3. Homenet Architecture Principles 🏡
The aim of this text is to outline how to construct advanced IPv6-based home networks involving multiple routers and subnets, using standard IPv6 addressing and protocols [RFC2460] [RFC4291] as the basis 💜. As described in Section 3.1, solutions should as far as possible reuse existing protocols and minimise changes to hosts and routers, but some new protocols or extensions are likely to be required 🧩. In this section, we go over the elements of the proposed home networking architecture, along with the design principles behind them ✨.
In general, home network equipment needs to be able to operate in networks with a range of different properties and topologies. Home users may plug components together in arbitrary ways and expect the resulting network to just work 🥹. Significant manual configuration is rarely, if ever, possible or even desirable, given the knowledge level of typical home users. So the network should, as far as possible, be self-configuring. Configuration by advanced users should not be precluded though 🤓.
The homenet needs to be able to handle or provision at least the following:
- Routing 🛣️
- Prefix configuration for routers
- Name resolution
- Service discovery
- Network security 🔐
The rest of this document describes the principles by which the homenet architecture may deliver these properties 💖.
3.1. General Principles 🌟
There is little that the Internet standards community can do about the physical topologies, or about the need for some networks to be separated at the network layer for policy or link-layer compatibility reasons 🫠. However, there is a lot of flexibility in how IP addressing and internetworking mechanisms are used. This text discusses how that flexibility should be used to provide the best user experience and ensure the network can evolve with new applications in the future 🦋. The principles described in this text should be followed when designing homenet protocol solutions 🎀.
3.1.1. Reuse Existing Protocols 🫶
okay bestie, so the plan is to use existing protocols to meet home network requirements 💅. if one needs extending, we extend it. only when no existing protocol is suitable can a new or emerging one come in. that means we can't make any design or architecture choice that would block new or emerging protocols from being used later 🔮
a generally conservative approach is the move ✨, and it gives extra weight to code that's already running and available. for new protocols, evidence that appropriate vendors or development communities are actually committed to implementing them is highly desirable 🙌. protocols used should be backward compatible, and forward compatible wherever changes are made 🎀
3.1.2. Minimise Changes to Hosts and Routers 🦋
so we want new homenets to be easy to deploy 🚀, which means any requirement to change hosts and routers should be kept as small as possible. solutions that improve capability through host or router changes, bit by bit, might be fine though 🍓. sometimes changes are unavoidable, like letting a homenet routing protocol configure itself, or supporting routing based on source addresses as well as destination addresses (for better multihoming support, more on that in Section 3.2.4) 💜
3.2. Homenet Topology 🗺️
this section looks at homenet topologies and the principles we can use to design an architecture that supports as wide a range of them as possible 🧚
3.2.1. Supporting Arbitrary Topologies 🌈
ideally there are no built-in assumptions about the topology of a home network, because users are capable of connecting their devices in 'ingenious' ways 😭. so arbitrary topologies and arbitrary routing will need to be supported 🫠. if that's not possible, the failure mode for when a user makes a mistake should at least be as robust as it can be. for example, a certain part of the infrastructure gets deactivated so the rest can keep working ✨. in those cases, ideally the user gets some useful indication of the failure they hit 💡
there should be no topology scenarios that cause a loss of connectivity, except when the user creates a physical island within the topology 🏝️. some potentially pathological setups include bridging ports of a router together, but the router can detect and handle that case 🤖. loops in a routed topology are actually good, since they offer redundancy 🔁. topologies with potential bridging loops can be dangerous, but they're also detectable, for example when a switch learns the Media Access Control (MAC) address of one of its interfaces on another interface, or when it runs a spanning tree or link-state protocol 🕸️. only topologies with potential loops made of simple repeaters are truly pathological 💀
the topology of the homenet can change over time, because equipment gets added or removed, and also because of temporary failures or connectivity problems 🌪️. sometimes this means a multihomed homenet gets split into two isolated homenets 💔. once the fault is fixed, those two isolated parts can reconfigure back into a single network 🫶
3.2.2. Network Topology Models 🧩
as hinted above, the architecture may focus on the likely common topologies, but it should not rule out any arbitrary topology from being built 🛠️.
right now most IPv4 home network models are pretty simple, usually a single NAT router to the ISP and one internal subnet 🏠. but as discussed earlier, evolving network architectures are pushing things toward more complex topologies, like separating guest and private networks 👀. there may also be some cascaded IPv4 NAT scenarios, which we'll get to in the next section. for IPv6 homenets, the network architectures described in [RFC7084] should, as a minimum, be supported 💖
there are a number of properties or attributes that can describe a home network's topology and operation 📋. the following properties apply to any IPv6 home network:
- Presence of internal routers. The homenet may have one or more internal routers, or it may only provide subnetting from interfaces on the CE router 🧚.
- Presence of isolated internal subnets. There may be isolated internal subnets with no direct connectivity between them inside the homenet, and each one has its own external connectivity 🏝️. the isolation may be physical or done with IEEE 802.1q VLANs. but a typical user isn't expected to configure VLANs, so that part is on the more techy side 🤓.
- Demarcation of the CE router. The CE router(s) may or may not be managed by the ISP. if the demarcation point means the customer can provide or manage the CE router, its configuration must be simple 🎀. both models must be supported 🫶.
multihoming is likely to become more common with IPv6 homenets, where the homenet may have two or more external ISP connections, as we'll discuss further below 🌸. so the following properties should also be considered for those networks:
- Number of upstream providers. most home networks today have a single upstream ISP, but it may become more common to have multiple ISPs, whether for resilience or for extra services ✨. each one would offer its own prefix 💜. some may or may not provide a default route to the public Internet 🌐.
- Number of CE routers. the homenet may have a single CE router, which might serve one or more providers, or it may have multiple CE routers 🧠. multiple CE routers add extra complexity for multihoming scenarios, and for protocols like PCP that may need to manage connection-oriented state mappings on the same CE router that handles the later traffic flows 😵💫.
in the following sections we give some examples of the homenet topologies we may see in the future 🔭. this list isn't meant to be exhaustive or complete. it's more of an indicative one, to make the discussion in this text easier to follow 🫶.
3.2.2.1. A: Single ISP, Single CE Router, and Internal Routers 🌟
Figure 1 shows a home network with multiple local area networks 🏘️. these might be needed because of different link-layer technologies or for policy reasons, like classic Ethernet in one subnet and an LLN link-layer technology in another 🔌. in this example, no single router a priori understands the entire topology 🤯. the topology can also get complex, and it may not be possible to assume a pure tree form, for instance, because home users may plug routers together into arbitrary topologies, including ones with potential loops 🌀.
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | Network
| /
| Customer /
| Internet Connection
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | |
+----+-+---+----+ |
Network A | | | Network B(E) |
----+-------------+----+ | +---+-------------+------+ |
| | | | | | |
+----+-----+ +-----+----+ | +----+-----+ +-----+----+ | |
|IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | |
| H1 | | H2 | | | H3 | | H4 | | |
+----------+ +----------+ | +----------+ +----------+ | |
| | | | |
Link F | ---+------+------+-----+ |
| | Network E(B) |
+------+--------+ | | End-User
| IPv6 | | | Networks
| Interior +------+ |
| Router | |
+---+-------+-+-+ |
Network C | | Network D |
----+-------------+---+ +---+-------------+--- |
| | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | |
| H5 | | H6 | | H7 | | H8 | /
+----------+ +----------+ +----------+ +----------+ /
Figure 1in this diagram there is one CE router 📦. it has a single uplink interface, plus three more interfaces connected to Network A, Link F, and Network B 🔗. the IPv6 Internal Router (IR) has four interfaces, connected to Link F, Network C, Network D, and Network E 🧭. Network B and Network E have been bridged, most likely by accident 😬. this could happen if you connect a wire between a switch for Network B and a switch for Network E 🪢.
any of the logical Networks A through F might be wired or wireless 📶. where multiple hosts are shown, that might be through one or more physical ports on the CE router or IPv6 (IR), wireless networks, or one or more Ethernet switches that are Layer 2 only 💫.
3.2.2.2. B: Two ISPs, Two CE Routers, and Shared Subnet ✨
Okay so bestie, this next diagram is giving multihomed homenet 🏠💖 Two ISPs, two CE routers, and one shared subnet. Let's look at it!
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+------+--------+ +-------+-------+ | Network
| | /
| Customer | /
| Internet Connections | /
| |
+------+--------+ +-------+-------+ \
| IPv6 | | IPv6 | \
| Customer Edge | | Customer Edge | \
| Router 1 | | Router 2 | /
+------+--------+ +-------+-------+ /
| | /
| | | End-User
---+---------+---+---------------+--+----------+--- | Network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
Figure 2So Figure 2 shows the customer hooked up via CE router 1 to ISP A, and via CE router 2 to ISP B 🌸 There's one shared subnet where the IPv6 nodes could end up multihomed and get multiple global prefixes, one from each ISP. Literally so cool 🦋
This model can also get mixed with the one from Figure 1 for a more complex setup with multiple internal routers 🧚 Or, the shared subnet can get split in two, so each CE router runs its own isolated subnet. That's a setup we already see with some IPv4 networks today, iykyk 💅
3.2.2.3. C: Two ISPs, One CE Router, and Shared Subnet 🎀
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+-------+-------+ +------+--------+ | Network
| | /
| Customer | /
| Internet | /
| Connections |
+-----------+-----------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+-----------+-----------+ /
| /
| | End-User
---+------------+-------+--------+-------------+--- | Network(s)
| | | | \
+----+-----+ +----+-----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+
Figure 3Figure 3 is the model where a home network might have multiple connections to multiple providers, OR multiple logical connections to the same provider, all sharing internal subnets 💜 Main character energy for sure ⭐
3.2.3. Dual-Stack Topologies 🌈
Okay so for the immediate future, most homenets are gonna be dual-stack IPv4/IPv6 ngl 💅 That means we really shouldn't add any new IPv6 features that would break when they're used alongside IPv4+NAT, because these dual-stack homenets are going to be everywhere for a while 😭 Still, IPv6 should work better than IPv4 in as many situations as possible ✨ And the homenet architecture has to keep working even without IPv4 at all 🫶
The general vibe is to use the same topology for IPv6 as for IPv4, just without NAT. So wherever there's an IPv4 NAT, there should be routed IPv6, and where there's no NAT, routing or bridging is fine. Routing can be better than bridging when you're mixing high-speed and low-speed shared media, and bridging might not work for some networks, like ad hoc mobile ones 🦋
Sometimes IPv4 home networks have cascaded NATs. End users often have no idea they've built one, because "home routers" and "home switches" get mixed up all the time 🙈 Also, NAT routers can hide inside Virtual Machine Hypervisors, or show up when Internet connection-sharing services are turned on. This document applies just as much to these sneaky hidden NAT "routers" 💀 IPv6-routed versions of these setups will be required. So yeah, routers in the homenet might not be separate physical boxes at all; they can be embedded inside other devices 🍓
3.2.4. Multihoming 🔥
A homenet can be multihomed to multiple providers, like the network models above show. This can look like either multiple isolated networks inside the home, or a more integrated network where the connection choice has to be dynamic. Current practice is mostly the first kind, but the second is expected to become more common 👑
In the general homenet architecture, multihomed hosts should be multi-addressed, with a global IPv6 address from the global prefix delegated by each ISP they talk to or through 🎀 When there's multi-addressing going on, hosts need some way to pick source and destination address pairs for their connections. A host can pick its source address in various ways, most commonly [RFC6724] ✨ Applications can totally do their own thing here too, and that shouldn't be ruled out 💅
For the single CE Router Network Model C from above, multihoming can be offered by source-based routing at the CE router 🧚 With multiple exit routers, like in CE Router Network Model B, things get way more complex 😭 If a packet has a source address from the home network, it must be routed to the proper egress so it doesn't hit ingress filtering as described in BCP 38, if it would exit through the wrong ISP. It's highly desirable that the packet takes the most efficient route to the correct exit, but at the very least the packet should not be dropped 🫶
The homenet architecture should support both of these models, meaning one or more CE routers 💖 But the general multihoming problem is huge, and the solutions the IETF has suggested so far include complicated architectures for monitoring connectivity, traffic engineering, identifier-locator separation, keeping connections alive across multihoming events, and so on 🌀 So it's important that the homenet architecture keeps the complexity of any multihoming support as low as it possibly can 🌸
An example of one of these "simpler" approaches is documented in [RFC7157] 🦋 Another option is that a flooding/routing protocol could pass information through the homenet, so internal routers and eventually end hosts could learn per-prefix configuration info and make better address selection decisions 🧠 But that would mean changes to routers and, most likely, hosts too 🙈 Another path is to add support throughout the homenet for routing based on both the source and destination address of each packet. That would make routing decisions way smarter inside the homenet, but it would need pretty significant router changes while skipping host changes 💜
As explained earlier, NPTv6 has been proposed for multihoming support in networks, but it is NOT RECOMMENDED for the homenet architecture 🚫
Heads up: some multihoming setups might have one upstream that's a "walled garden," so it's only useful for reaching that provider's own services. An example is a VPN service that only routes back to a user's enterprise business network from inside the homenet 🔒 As per Section 4.2.1 of [RFC3002], walled-garden multihoming is NOT a specific goal of this document 💅
The homenet architecture also shouldn't block host or application-oriented tools, like Shim6 [RFC5533], Multipath TCP (MPTCP) [RFC6824], or Happy Eyeballs [RFC6555] 🎀 In general, any small improvements from host changes should benefit the hosts that adopt them, but they should not be required 🫶
3.2.5. Mobility Support 🦋
Devices can move around inside the homenet 🧚 While they stay on the same subnet, their address stays persistent. But if a device moves to a different (wireless) subnet, it'll get a new address in that subnet 💖 It's desirable that the homenet supports internal device mobility ✨ To make that happen, the homenet can either extend the reach of specific wireless subnets so wireless roaming works across the whole home (a specific subnet available throughout the home), or support mobility protocols that make roaming easier when multiple subnets are in use 🌈
3.3. A Self-Organising Network 👑
The home network infrastructure should be naturally self-organising and self-configuring, no matter the situation with its Internet connectivity, the number of devices, or the physical topology 💅 At the same time, advanced users should be able to manually adjust (override) the current configuration 🔧
Even though the goal is for the network to be as self-organising as possible, some manual configuration may still be needed sometimes, like entering a cryptographic key to set up wireless security, or configuring a shared routing secret 🔐 The shared routing secret part may matter when figuring out how to bootstrap a routing configuration 🧚 It's highly desirable that the number of these manual configurations is kept to a minimum 🫶
3.3.1. Differentiating Neighbouring Homenets 🌸
It's important to avoid self-configuring with "unintended" devices 🙅 There should be a simple way for a user to administratively assert whether or not a device belongs to a given homenet 💜 The goal is to set up borders, especially between two adjacent homenets, and to keep unauthorised devices from joining the homenet 🚧 That authorisation capability may need to work across multiple hops in the homenet 🌈
So the homenet should support a way for a homenet owner to claim ownership of their devices in a reasonably secure way 🔐 This could be done with a pairing mechanism, like pressing buttons at the same time on an authenticated device and a new homenet device, or through an enrollment process as part of an autonomic networking environment ✨
Sometimes one homenet might want to intentionally get access through another, like to share external connectivity costs 🤝 Those scenarios aren't discussed in this document, bestie 💖
3.3.2. Largest Practical Subnets 🏠✨
okay so today's IPv4 home networks basically have one subnet 💅, and early dual-stack setups usually have one matching IPv6 subnet too, maybe with some bridging going on. lately some vendors have started adding 'home' and 'guest' functions 🎀, which in IPv6 would be two subnets. fancy!!
future homes are highly likely to have one or more internal routers 🧚, so they'll need multiple subnets for the reasons we covered earlier. as part of self-organising 🦋, the homenet should split itself into the largest practical subnets it can build, given link-layer mechanisms, bridging, physical connectivity, policy, and (where it applies) performance or other criteria. the logical topology might not match the physical one, and that's totally fine 🙈. this text doesn't tell anyone how to do the splitting though. that's a job for future documents 💜
and ngl, bigger subnets = better odds that link-local protocols work across the whole homenet 🌈 but multi-subnet homes are inevitable, so we have to support them. no cap. 🫶
3.3.3. Handling Varying Link Technologies ⚡
homenets grow organically over many years 🌸, so one home is often built out of link technologies from totally different generations. right now links run anywhere from 1 Mbit/s up to 1 Gbit/s, which is a throughput gap of three orders of magnitude 😭. and it's only going to get wider as high-speed and low-power tech shows up.
homenet protocols need to handle links with very different throughputs well 💖. the big rule: flows that are local to one link shouldn't get flooded across the whole homenet, even when they're multicast 🙅♀️. and whenever possible, the protocols should pick the faster links and dodge the slow ones 🏎️
the spicy bit: links (especially wireless ones) may only have a limited number of transmit opportunities (txops). power and backwards-compatibility pressures are pushing everyone toward cramming packets into those limited txops while cranking up throughput. txops might be the scarcest resource in the whole system, which means they can seriously cap the real throughput you actually get 💀
3.3.4. Homenet Realms and Borders 🗺️
the homenet needs to know how big its own 'site' is 👑. that matters because the site defines the borders for ULA and site-scope multicast traffic, and it might need specific security policies applied. there will be one or more of these borders with external connectivity providers 🌐
there will most likely also be internal borders between internal realms, like a guest realm or a corporate network extension realm 🍓 it's desirable that these borders can be configured to decide where prefixes, routing info, traffic, service discovery, and naming are allowed to be shared. the default internally? share everything! 🥰
a realm is expected to span at least one entire subnet, so the borders sit at the routers that receive delegated prefixes inside the homenet 🧭. for a richer security model, it's also desirable that hosts can make communication decisions based on realm and prefix info, the same way the routers at realm borders can. main character energy for hosts 😤💅
a simple homenet model might just use three types of realm and the borders between them: the internal homenet, the ISP, and a guest network 🎀. in that case the borders are homenet-to-ISP, guest-to-ISP, and homenet-to-guest. but either way, it should be possible to define extra realm types, like an LLN-based network such as a Smart Grid ⚡. those should be detected automatically, and an appropriate default policy should apply to what kind of traffic and data can cross those borders. iykyk 🙈
it's desirable to treat the external border of the home network as one unique logical interface that separates the home from the service provider network(s) 🦋. that border might be a single physical interface to a single provider, multiple Layer 2 sub-interfaces to a single provider, or multiple connections to one or several providers. this setup makes it possible to describe edge operations and interface requirements across security, routing, service discovery, and router discovery, all in one place. so organised 🫶
the homenet user should be able to override any automatically determined borders and the default policies between them 🙌. the one exception: it may not be possible to override policies the ISP has defined at the external border. sorry bestie, the ISP is the boss of that one 💀
3.3.5. Configuration Information from the ISP 📬
sometimes it's useful for the homenet to get certain configuration info from its ISP 💜. for example, the homenet DHCP server might request some options from its upstream DHCP server and then forward them along. the specifics of those options can vary between deployments though. and if the homenet is multihomed, things get extra complicated 😵💫
3.4. Homenet Addressing 🏡
the IPv6 addressing scheme inside a homenet has to conform to the IPv6 addressing architecture [RFC4291] 📐 this section is all about how the homenet adapts to the prefixes its upstream ISP hands it, so that internal subnets, hosts, and devices can get the addressing info they need to actually work 🎀
3.4.1. Use of ISP-Delegated IPv6 Prefixes 🌷
discussion of IPv6 prefix allocation policies lives in [RFC6177] 📖 in practice, a homenet might get a prefix of any length from its provider, like /60, /56, or /48. the prefix might stay stable, or it might change from time to time. ISPs are generally expected to offer relatively stable prefixes to residential customers 🥹 either way, the home network needs to be as adaptable as it can be to ISP prefix allocation policies, and it should assume nothing about how stable the prefix is or how long it'll be. flexible queen 👑
but ngl, if the ISP only offers a /64, the homenet could be seriously constrained or even unable to function at all 😭 BCP 157 [RFC6177] says the following:
A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.
this architecture document assumes ISPs are following the guidance in that quote 🙏
there are lots of problems if a homenet isn't offered a big enough prefix for its needs 💀 so instead of trying to contrive some clever way to run in a squeezed mode, the kind of thing that uses subnet prefixes longer than /64 (which would break stateless address autoconfiguration [RFC4862]), or NPTv6, or falling back to bridging across potentially very different media, it's recommended that the receiving router enters an error state and issues appropriate warnings instead 🚨 we'll need to think about how a warning or error like that gets shown to a typical home user, because nobody wants a scary wall of jargon 🙈
so a homenet CE router should request a prefix from its ISP via DHCP Prefix Delegation (DHCP PD) [RFC3633], asking for a /48 🎀 it asks for the biggest prefix it might expect, even if in reality it only ends up with a /56 or a /60. for a typical IPv6 homenet, it's not recommended that an ISP offers less than a /60, and it's highly preferable that the ISP offers at least a /56 ✨ the prefix delegated to the homenet from any single ISP is expected to be one contiguous, aggregated block. the router could send multiple prefix requests to try to get multiple delegations, but that behaviour is out of scope for this document 🙅♀️
for residential customers of big ISPs, the norm might look a lot like their single IPv4 address: it'll probably stay put for a while by default 🕰️ but changes in the ISP's own provisioning systems can cause the customer's IP (and, for IPv6, their prefix pool) to change. ISPs are not generally expected to support Provider Independent (PI) addressing for residential homenets 🚫
now, when an ISP needs to restructure and renumber its customers' homenets, 'flash' renumbering is likely to get imposed 😱 that means the homenet has to handle a sudden renumbering event. unlike the process described in [RFC4192], this is a 'flag day' event, so a graceful renumbering that moves through a state with two active prefixes at once wouldn't be possible. renumbering can be thought of as an extended version of initial numbering, but the difference between a flash renumbering and an initial 'cold start' is that the flash version has to keep service continuity going 🌈
there might also be cases where local law requires some ISPs to change IPv6 prefixes (current IPv4 addresses) for privacy reasons 🔐 in those cases, it may be possible to avoid an instant 'flash' renumbering and plan a non-flag day renumbering as per RFC 4192 instead. likewise, if an ISP has a planned renumbering process, it may be able to adjust lease timers and so on to match 🗓️
if the customer chooses to move to a new ISP, they'll start using a new prefix 📦 they should expect a discontinuity: not only might the prefix change, but the prefix length might change too if the new ISP's default size is different. and the homenet might also be forced to renumber itself if the user does some major internal 'replumbing' 🔧
regardless of all that, it's desirable that homenet protocols support rapid renumbering, and that the operational processes don't add unnecessary complexity 💅 and the introduction of any new homenet protocols shouldn't make renumbering any more complicated than it already is. no new drama please 🙏
finally, the internal operation of the home network shouldn't depend on the ISP network being available at any given time 🏠 the only exception is connectivity to services or systems off the home network, obviously. this reinforces the use of ULAs for stable internal communication 💜 and it highlights the need for a naming and service discovery mechanism that can run independently inside the homenet 🫧
3.4.2. Stable Internal IP Addresses ✨
okay so by default, the network should try to give IP-layer connectivity between all the internal parts of the homenet 🏠 and also to and from the external Internet 🌍. the catch is that it's subject to the filtering policies or other policy constraints we'll get into later in the security section 🔐. bestie, the vibe is everyone stays connected unless the rules say otherwise 💖
ULAs should be used within the scope of a homenet to keep routing and connectivity stable between subnets and hosts, whether or not a globally unique ISP-provided prefix is available 🫶. if the external connection goes down for a long time, ULAs let everything inside keep talking across routed subnets 🔥. they're also iconic for constrained devices, which can make permanent relationships between IPv6 addresses. think a wall controller talking to a lamp 💡. symbolic host names would need extra non-volatile memory for that, and updating global prefixes on sleeping devices can be a whole mess 😭
as we covered before, ULAs would normally be used next to one or more global prefixes in a homenet. that means hosts end up with multiple addresses, both globally unique and ULA 🦋. ULAs should be used for all devices, not just the ones that only need internal connectivity, no exceptions 💅. default address selection then prefers ULAs for internal chats between devices using ULA prefixes generated within the same homenet. it's giving smooth internal vibes ✨
when a homenet has ULA prefixes but no external IPv6 connectivity (so no GUAs in use), recommendationsULA-5,L-3, andL-4in RFC 7084 should be followed so everything works correctly 🙈. this matters extra if the homenet is dual stack with IPv4 external connectivity. the Route Information Option described in [RFC4191] is how you advertise those more-specific ULA routes 🎀
ULAs should stay within the homenet. that means filtering at the homenet border(s), as required by RFC 7084 requirement S-2 🚧.
one more thing bestie 👀. sometimes a homenet might have more than one /48 ULA prefix in use, like when the network is still being set up, maybe without external connectivity too 🌸. when that happens, hosts need to know each /48 is local to the homenet. one way is including it in their local address selection policy table 🧚
3.4.3. Internal Prefix Delegation 🍓
so there are a bunch of prefix sources. from the homenet's point of view, a single global prefix from each ISP should be received on the border CE router [RFC3633]. if there are multiple CE routers with multiple ISP prefix pools, routers inside the homenet are expected to give themselves prefixes from each ISP they talk to or go through 🌈. and like we said, a ULA prefix should be set up for stable internal chats or for constrained/LLN networks 💜
giving a prefix pool to the homenet should let it hand out prefixes internally on its own afterwards 🙌. that internal assignment should not assume a flat or hierarchical model, and it shouldn't assume whether assignment is distributed or centralised either. the assignment mechanism should be reasonably efficient, so typical home prefix allocation sizes can fit all the needed /64 allocations in most cases without wasting prefixes 🧠. it should also avoid giving multiple /64s to the same network, and it should behave as gracefully as possible if prefixes run out (though the options might be limited in that case 💀)
when the home network has multiple CE routers and each gets prefix pools from its attached ISP, internal prefix assignment would be expected to be served by each CE router for each prefix tied to it 🏡. if ULAs are used, it's preferable that only one /48 ULA covers the whole homenet, and /64s get assigned to the subnets from it 👑. if two /48 ULAs get generated inside one homenet, the network should still keep working, which means hosts will need to figure out that each ULA is local to the homenet 🔍
prefix assignment inside the homenet should give each link a stable prefix that sticks around across reboots, power outages, and similar short outages ⭐. the persistent prefixes shouldn't depend on router boot order. adding a new routing device shouldn't mess with existing persistent prefixes 🦋. persistence might not be expected if the homenet gets significantly replumbed though. but assigned ULA prefixes should stay persistent even through an ISP-driven renumbering event 🫶
getting persistent prefixes like this might mean routing devices need stable storage, plus some way for a home user to 'reset' the stored prefix if a big reconfiguration is needed 🔧. ideally the home user isn't involved at all tho 🙈
this document doesn't make a specific recommendation for any solution. it does note that it's very likely all routing devices in a homenet must use the same internal prefix delegation method. that means only one delegation method should be in use 💅
3.4.4. Coordination of Configuration Information 🎀
the network elements need to be integrated in a way that accounts for the different lifetimes on the timers used across different elements 🕰️. examples are DHCPv6 PD, router, valid prefix, and preferred prefix timers. main character timing energy ⏱️
3.4.5. Privacy 🔐
if ISPs give customers relatively stable IPv6 prefixes, the network prefix part of addresses tied to the homenet may not change for a pretty long time 📅
so the exposure of which traffic comes from the same homenet is kinda similar to IPv4 😌. the single IPv4 global address seen through IPv4 NAT gives the same hint as the global IPv6 prefix seen for IPv6 traffic 🫣
IPv4 NAT might hide which internal device the traffic is coming from, to an outside observer 🕶️. but IPv6, even with privacy addresses [RFC4941], adds extra exposure of which traffic is coming from the same internal device, because it keeps using the same IPv6 source address for a period of time 😭
3.5. Routing Functionality 🛣️
routing functionality is required when there are multiple routers deployed inside the internal home network 🧭. it could be as simple as the 'default route is up' model of IPv4 NAT, but more likely it'll involve running an appropriate routing protocol 🔥
a mechanism is required to discover which router(s) in the homenet is providing the CE router function 🔍. borders can include, but aren't limited to, the interface to the upstream ISP, a gateway device to a separate home network such as an LLN network, or a gateway to a guest or private corporate extension network 🚪. sometimes there may be no border at all, which could happen before an upstream connection is set up 🌱
the routing environment should be self-configuring, like we talked about before 🤖. the homenet self-configuration process and the routing protocol must work together predictably, especially during startup and reconvergence 🫶. border discovery and other self-configuration functionality can be built into the routing protocol itself, or imported through a separate discovery mechanism 🧩
configuration information is preferably distributed and synchronised inside the homenet by a separate configuration protocol 📦
the homenet routing protocol should be based on a previously deployed protocol that's been shown to be reliable and robust 💪. that doesn't rule out picking a newer protocol once a high-quality open source implementation shows up 🌟. the resulting code must support lightweight implementations and be suitable for consumer devices, where both fixed and temporary storage and processing power are at a premium 🪫
at most, one unicast and one multicast routing protocol should be in use at a given time in a given homenet ✌️. some simple topologies might not need a routing protocol at all 🍃. if more than one routing protocol is supported by routers in a given homenet, a mechanism is required to make sure all routers in that homenet use the same protocol 🫧
the homenet architecture is IPv6-only 💜. in practice though, dual-stack homenets are still likely for the foreseeable future, as described in Section 3.2.3 🌈. support for IPv4 and other address families may be beneficial, but it's not an explicit requirement to carry the routing information in the same routing protocol 🦋
multiple types of physical interfaces must be accounted for in the homenet routing topology 🧃. technologies like Ethernet, Wi-Fi, Multimedia over Coax Alliance (MoCA), etc. must be able to coexist in the same environment and should be treated as part of any routed deployment 🏠. including physical-layer characteristics in path computation should be considered for optimising communication in the homenet 🔥
3.5.1. Unicast Routing within the Homenet ✨
okay bestie, the whole job of the unicast routing protocol is to give you good enough end-to-end connectivity often enough 💖. What counts as "good enough" and "often enough" is decided by user expectations 🫶
Because a homenet mixes a bunch of different link technologies 🌈, path selection might need to be more refined than just counting hops. It can also be super useful for traffic to use multiple paths to the same destination inside the homenet when they're available, instead of only one best path 🦋
Minimising convergence time should be a goal in any routed environment 🔥. It's reasonable to assume that convergence time should not be significantly longer than the network outages users are already used to whenever their CE router reboots 😭
The homenet architecture doesn't pick a side on the routing technology underneath, whether that's link state or Bellman-Ford 🧚
The routing protocol should support the generic use of multiple customer Internet connections and the concurrent use of multiple delegated prefixes 👑. A routing protocol that can make routing decisions based on source and destination addresses is thus highly desirable, so you don't run into problems with upstream ISP ingress filtering as described in BCP 38 🙈. Multihoming support may also include load balancing to multiple providers, and failover from a primary to a backup link when one is available. The protocol should not require upstream ISP connectivity to be established in order to keep routing within the homenet 💅
The homenet architecture doesn't set a minimum hop count that the routing protocol has to support 🍓. The architecture should, however, be scalable to other scenarios where homenet technology may be deployed, which may include small office and small enterprise sites. To allow for those cases, it would be desirable for the architecture to scale to higher hop counts and to larger numbers of routers than you'd typically see in a true home network 🏢
Link-layer networking is getting more heterogeneous right now 🌸, as networks start to use both traditional Ethernet and link layers designed for LLNs, like the ones used for certain types of sensor devices.
Ideally, LLNs or other logically separate networks should be able to exchange routes so IP traffic can be forwarded among the networks through gateway routers that interoperate with both the homenet and any LLNs 💜. Right now, home deployments use pretty different mechanisms for sensor networks and basic Internet connectivity networks 😵. IPv6 virtual machine (VM) solutions may also add extra routing requirements.
In this homenet architecture, LLNs and other specialised networks are considered stub areas of the homenet, so they aren't expected to act as a transit for traffic between more traditional media 🧸
3.5.2. Unicast Routing at the Homenet Border
The current practice defined in [RFC7084] would suggest that routing between the homenet CE router and the service provider router follow the WAN-side requirements model in [RFC7084], Section 4 (WAN-side requirements), at least in initial deployments 🎀. However, whether a routing protocol gets used between the homenet CE router and the service provider router is out of scope for this document 🙅♀️
3.5.3. Multicast Support
It is desirable that, depending on the capacities of devices on certain media types, multicast routing is supported across the homenet, including source-specific multicast (SSM) [RFC4607] 📡
[RFC4291] requires that any boundary of scope 4 or higher (i.e., admin-local or higher) be administratively configured. So the boundary at the homenet-ISP border must be administratively configured, though that may be triggered by an administrative function such as DHCP PD 🛎️. Other multicast forwarding policy borders may also exist within the homenet, e.g., to/from a guest subnet, whilst the use of certain link media types may also affect where specific multicast traffic gets forwarded or routed 🍿
There may be different drivers for multicast to be supported across the homenet -- for example,
- for homenet-wide service discovery, should a multicast service discovery protocol of scope greater than link-local be defined
- for multicast-based streaming or file-sharing applications
Where multicast is routed across a homenet, an appropriate multicast routing protocol is required, and as with the unicast routing protocol, it should be self-configuring 🤖. As hinted above, it must be possible to scope or filter multicast traffic so it doesn't get flooded onto network media where devices can't reasonably support it 🚫
A homenet may not only use multicast internally, it may also be a consumer or provider of external multicast traffic, where the homenet's ISP supports that kind of multicast operation 📺. This may be valuable, for example, where live video applications are being sourced to or from the homenet 🎥
The multicast environment should support the ability for applications to pick a unique multicast group to use 🦄
3.6. Security 🔐
The security of an IPv6 homenet is a really important consideration 😤. The biggest difference from the IPv4 operational model is the removal of NAT, plus the introduction of global addressability for devices. That means we need to think about whether devices should have global reachability at all. Either way, hosts need to be able to operate securely, end to end where required, and also be robust against malicious traffic aimed at them. There are other challenges too, e.g., default filtering policies at the borders between the various homenet realms 🧱
3.6.1. Addressability vs. Reachability
An IPv6-based home network architecture should embrace the transparent end-to-end communications model described in [RFC2775] 🌍. Each device should be globally addressable, and those addresses must not be altered in transit. However, security perimeters can be applied to restrict end-to-end communications, so a host can be globally addressable and still not be globally reachable 🙃
[RFC4864] describes a 'Simple Security' model for IPv6 networks, where stateful perimeter filtering can be applied to control the reachability of devices in a homenet 🛡️. RFC 4864 states in Section 4.2 that "the use of firewalls...is recommended for those that want boundary protection in addition to host defences." It should be noted that a 'default deny' filtering approach would effectively replace the need for IPv4 NAT traversal protocols with a need to use a signalling protocol to request a firewall hole be opened, e.g., a protocol such as PCP [RFC6887]. In networks with multiple CE routers, the signalling would need to handle flows that may use one or more exit routers. CE routers would also need to be able to advertise their existence for such protocols 📣
[RFC6092] expands on RFC 4864 with a more detailed discussion of IPv6 perimeter security recommendations, without mandating a 'default deny' approach 🧐. In fact, RFC 6092 doesn't enforce a particular mode of operation. Instead, it states that CE routers must provide an easily selected configuration option that permits a 'transparent' mode, so a 'default allow' model stays available 🪄
The topic of whether future home networks like the ones described in this document should have a 'default deny' or 'default allow' position has been debated at length in various IETF meetings, and no consensus has been reached on which approach is more appropriate 🗣️. Further, the choice of default may be situational, so this text makes no recommendation on the default setting beyond what RFC 6092 already says on the topic. We note in Section 3.6.3 below that the implicit firewall function of an IPv4 NAT is commonplace today, so future CE routers targeted at home networks should continue to support the option of running in 'default deny mode', whether or not that's the default setting 💅
3.6.2. Filtering at Borders
It is desirable that there are mechanisms to detect the different types of borders within the homenet, as discussed previously, plus further mechanisms to apply different types of filtering policies at those borders, e.g., whether naming and service discovery should pass a given border 🚧. Any such policies should be easy for typical home users to apply, e.g., to give a guest network user access to media services in the home or to a printer 🖨️. Simple mechanisms to apply policy changes, or associations between devices, will be required 🎀
There are cases where full internal connectivity may not be desirable, e.g., in certain utility networking scenarios, or where filtering is required for policy reasons against a guest network subnet(s). So some scenarios or models may involve running isolated subnet(s) with their own CE routers. In those cases, connectivity would only be expected within each isolated network (though traffic may potentially pass between them via external providers) 🏝️
LLNs are another example of where there may be secure perimeters inside the homenet 🔒. Constrained LLN nodes may implement network key security, but they may depend on access policies enforced by the LLN border router 🧠
Considerations for differentiating neighbouring homenets are discussed in Section 3.3.1 🫂
3.6.3. Partial Effectiveness of NAT and Firewalls
Security by way of obscurity (address translation) or through firewalls (filtering) is at best only partially effective 🙃. The very poor security track record of home computers, home networking, and business PC computers and networking is proof of that 💀. A security compromise behind the firewall of any device exposes all the others, which means an entire network that relies on obscurity or a firewall is only as safe as its most insecure device on the private side of the network 😬
However, given the current evidence of home network products with very poor default device security, putting a firewall in place does provide some level of protection 🧱. Firewalls are common practice today, whether or not that counts as a good practice, and the ability to get protection via a 'default deny' setting, even if it's only marginally effective, should not be lost 🫶. So while it's highly desirable that all hosts in a homenet be adequately protected by built-in security functions, it should also be assumed that all CE routers will keep supporting appropriate perimeter defence functions, as per [RFC7084] ✨
3.6.4. Exfiltration Concerns
As homenets get more complex, with more devices and service discovery potentially enabled across the whole home, there are potential concerns about information leaking out 👀. Devices could use discovery protocols to gather information and report it to equipment vendors or application service providers, and that's a real worry 😱
It isn't clear how such exfiltration could be easily avoided 🤷♀️, but the threat should be recognised, whether it comes from a new piece of hardware or some 'app' installed on a personal device 📱
3.6.5. Device Capabilities
When it comes to the devices themselves, homenet hosts should implement their own security policies in accordance with their computing capabilities 💻. They should have the means to request transparent communications that can be initiated to them through security filters in the homenet, for either all ports or specific services 🦋. Users should have simple methods to associate devices with services they want to operate transparently through (CE router) borders 💖
3.6.6. ULAs as a Hint of Connection Origin 🦋
okay so back in Section 3.6 we talked about filtering 🫶 if appropriate filtering is in place on the CE router(s), as mandated by requirement S-2 in RFC 7084, then a ULA source address can be taken as a sign that the traffic is locally sourced. ngl this is sneaky-but-useful hint energy 💜 That signal could then be paired with security settings to decide which nodes a particular application is allowed to talk to each other, as long as ULA address space is filtered properly at the boundary of the realm 🔥
3.7. Naming and Service Discovery 🎀
okay the homenet needs devices to be able to figure out and use unique names they can be reached by on the network, and names that no other device on the network is using 🧚 Users and devices also need to be able to find the devices and services on the network, like media servers, printers, displays, or specific home automation devices 💅 So naming and service discovery must be supported in the homenet, and since most home users aren't network admins, the service(s) providing this function must as far as possible support unmanaged operation 🙈
The naming system will be required to work internally or externally, whether the user is inside or outside of the homenet. Basically, the user should be able to refer to devices by name, and potentially connect to them, wherever they are 🌈 The most natural way to think about this is to make naming and service discovery work across the entire homenet residence (site), ignoring technical borders like subnets but respecting policy borders like the ones between guest and other internal network realms ✨ Remote access may be wanted by the homenet residents while they're travelling, but also potentially by manufacturers or other 'benevolent' third parties 👑
3.7.1. Discovering Services 🔍
Users will typically do service discovery through graphical user interfaces (GUIs) that let them browse the services on their network in an appropriate and intuitive way 💖 Devices may also need to discover other devices, without any user intervention or choice. Either way, these interfaces are beyond the scope of this document, but the interface should have an appropriate application programming interface (API) for the discovery to be performed 🧚
These interfaces may also hide the local domain name element from users, especially where only one name space is available. However, as we discuss below, in some cases being able to discover available domains may be useful 🌸
We note that current zero-configuration service discovery protocols are generally aimed at single subnets. So there's a choice to make for multi-subnet homenets: should such protocols be proxied, or extended to operate across a whole homenet? 🤔 In this context, that may mean bridging a link-local method, taking care to avoid packets entering looping paths, or extending the scope of multicast traffic used for the purpose. It may also mean that some proxy or hybrid service is utilised, perhaps co-resident on the CE router. Or, it may be that a new approach is preferable, e.g., flooding information around the homenet as attributes within the routing protocol (which could allow per-prefix configuration) 🦋 However, we should prefer approaches that are backward compatible and allow current implementations to continue to be used 💅 Note that this document does not mandate a particular solution. Instead, it expresses the principles that should be used for a homenet naming and service discovery environment 🫶
One of the biggest challenges facing service discovery today is the lack of interoperability, because there keeps being more and more service discovery protocols 😭 It's conceivable for consumer devices to support multiple discovery protocols, but that's clearly not the most efficient use of network and computational resources 💀 So one goal of the homenet architecture should be a path to service discovery protocol interoperability. That could come through a standards-based translation scheme, hooks into current protocols that allow some form of communication among discovery protocols, extensions to support a central service repository in the homenet, or simply convergence towards a unified protocol suite 🌈
3.7.2. Assigning Names to Devices 🏷️
Given the large number of devices that may be networked in the future, devices should have a way to generate their own unique names within a homenet, and to detect clashes should they arise 🎀 For example, a second device of the same type/vendor as an existing device could be deployed with the same default name, or a new subnet could be added to the homenet that already has a device of the same name. It is expected that a device should have a fixed name while within the scope of the homenet 🔒
Users will also want simple ways to (re)name devices, again most likely through an appropriate and intuitive interface that is beyond the scope of this document 💖 Note that the name a user assigns to a device may be a label stored on the device as an attribute of the device. It may be distinct from the name used in a name service, e.g., 'Study Laser Printer' as opposed to printer2.<somedomain> 🖨️✨
3.7.3. The Homenet Name Service 🌐
The homenet name service should support both lookups and discovery. A lookup would operate via a direct query to a known service, while discovery may use multicast messages or a service where applications register in order to be found 🧚
It is highly desirable that the homenet name service must at the very least coexist with the Internet name service. There should also be a bias towards proven, existing solutions 💅 The strong implication is that the homenet service is DNS based, or DNS compatible. There are naming protocols designed to be configured and operate Internet-wide, like unicast-based DNS, but there are also protocols designed for zero-configuration local environments, like Multicast DNS (mDNS) [RFC6762] 🦋
When DNS is used as the homenet name service, it typically includes both a resolving service and an authoritative service. The authoritative service hosts the homenet-related zone. One approach when provisioning such a name service, which is designed to facilitate name resolution from the global Internet, is to run an authoritative name service on the CE router, plus a secondary authoritative name service provided by the ISP or perhaps an external third party 🌍
Where zero-configuration name services are used, it is desirable that these can also coexist with the Internet name service. In particular, where the homenet is using a global name space, it is desirable that devices have the ability, where desired, to add entries to that name space. There should also be a mechanism for such entries to be removed or expired from the global name space 🧹
To protect against attacks such as cache poisoning, where an attacker is able to insert a bogus DNS entry in the local cache, it is desirable to support appropriate name service security methods. These include DNS Security Extensions (DNSSEC) [RFC4033], on both the authoritative server and the resolver sides 🔐 Where DNS is used, the homenet router or naming service must not prevent DNSSEC from operating.
⚠️ bestie, the line above is a hard rule: the homenet router or naming service must not prevent DNSSEC from operating. no exceptions 💀
While this document does not specify hardware requirements, it's worth noting briefly here that, e.g., in support of DNSSEC, appropriate homenet devices should have good random number generation capability. Future homenet specifications should indicate where high-quality random number generators, i.e., with decent entropy, are needed 🎲
Finally, the impact of a change in the CE router must be considered 🥺 It would be desirable to retain any relevant state (configuration) that was held in the old CE router. This might imply that state information should be distributed in the homenet, so it can be recovered by/to the new CE router, or to the homenet's ISP or a third-party externally provided service by some means 💜
3.7.4. Name Spaces ✨
okay so bestie, if you want to reach homenet devices from literally anywhere on the Internet, you need at least one globally unique name space 🌍💖. You're allowed to have more than one, though, and nothing says you can't 💅. One approach is that the homenet's name space(s) get served authoritatively by the homenet itself, most likely by a server living on the CE router 🎀. Those name spaces could be acquired by the user, or provided or generated by their ISP or some other external service ✨. The default case is probably that a homenet uses a global domain from the ISP 🦋. But advanced users who want a name space that's independent of their provider in the long run should be able to get and use their own domain name 👑. If you're one of those users, those services already exist, so you're not stuck 🫶.
Devices can also get different names in different name spaces 🧚. For example, third parties who manage systems or devices in the homenet for the residents might do this 💜. Remote management of the homenet is out of scope for this document 🙈.
Now, if there's no global name space available, the homenet will need to pick and use a local name space 🌸. That name only has meaning inside the local homenet, so it won't be used for remote access to the homenet 😭. The .local name space already has a special meaning for certain existing protocols that have link-local scope, so it's not appropriate for multi-subnet home networks 💀. That means the homenet needs a different name space, full stop 🍓.
One way to pick a local name space is an Ambiguous Local Qualified Domain Name (ALQDN) space, like .sitelocal (or some other name reserved for the purpose) 🌈. It's a simple approach, but in principle, a device that an application bookmarked by name in one homenet could get mixed up with a device that has the same name in another homenet 😬. In practice, though, the underlying service discovery protocols should be able to handle moving to a network where a new device uses the same name as a device that was used before in another homenet 🫶.
Another option for a local name space is a Unique Locally Qualified Domain Name (ULQDN) space, such as .<UniqueString>.sitelocal ✨. The <UniqueString> could be generated in a variety of ways, and one potential way is based on the local /48 ULA prefix being used across the homenet 🔥. That <UniqueString> should survive a cold restart, meaning it stays consistent after a network power-down 🔋. If no value is set on startup, the CE router or the device running the name service should generate a default value 💖. It would be desirable for the homenet user to be able to override the <UniqueString> with a value of their choice, but that would increase the likelihood of a name conflict 😅. Any generated <UniqueString> should not be predictable, so adding a salt/hash function would be desirable 🔐.
In the (likely) event that the homenet is accessible from outside the homenet using the global name space, it is vital that the homenet name space follows the rules and conventions of the global name space 👑. In that mode, names in the homenet, including the ones devices generate automatically, must be usable as labels in the global name space 💅. [RFC5890] describes considerations for Internationalizing Domain Names in Applications (IDNA) 🌸.
Also, with the arrival of new "dotless" top-level domains, there's potential for ambiguity 👀. For example, a local host called computer could clash with a .computer Generic Top Level Domain (gTLD), if that gets registered 💀. So qualified names should always be used, whether or not they're shown to the user 🙈. The IAB has issued a statement explaining why dotless domains should be considered harmful [IABdotless] 🚫.
There may be use cases where different realms in the homenet want different name spaces, or where a single name space gets segmented within the homenet 🧩. So hierarchical name space management is likely to be required 🌳. Nothing should stop an individual device, or devices, from being independently registered in external name spaces 🦋.
If there are two or more CE routers serving the home network, and each has a name space delegated from a different ISP, devices in the home could end up with multiple fully qualified names under multiple domains 😭✨.
When a user is on a remote network and wants to reach devices in their home network, the domain search order presented might need a look when several associated name spaces exist 🔍. That also implies a domain discovery function is desirable 💜.
It may be that not every device in the homenet is made available by name through an Internet name space. In that case, a "split view" (as described in [RFC6950], Section 4) may be preferred for certain devices, where devices inside the homenet get different DNS responses than devices outside 🎭.
Finally, this document makes no assumption about whether a reverse lookup service is present or absent 🤷♀️. One argument is that it could be useful for showing logging information to users with meaningful device names instead of literal addresses 📝. Also, some services, most notably email mail exchangers, have operators who've chosen to require a valid reverse lookup before accepting connections 📬.
3.7.5. Independent Operation 🏠
Name resolution and service discovery for reachable devices must keep working if the local network gets disconnected from the global Internet 🔌. For example, a local media server should still be available even if the Internet link is down for a long time 🎬. This implies the local network should also be able to do a complete restart without external connectivity, with local naming and service discovery still working correctly 💪.
Like we said above, a local authoritative name service with a cache would let things keep working locally during sustained ISP outages 🌧️.
Having an independent local trust anchor is desirable, so secure exchanges can still happen if external connectivity is unavailable 🔐.
Changing ISPs should not affect local naming and service discovery 🦋. Still, if the homenet uses a global name space provided by the ISP, then changing network providers will obviously have an impact 😬.
3.7.6. Considerations for LLNs 🔋
In some parts of the homenet, especially LLNs or any devices running on battery power, devices may be sleeping 😴. In that case, a proxy for those nodes may be required, one that could respond to things like multicast service discovery requests 📡. Those same devices or parts of the network may have less capacity for multicast traffic that might be flooded in from other parts of the network 🌊. In general, message utilisation should be efficient, considering the network technologies and constrained devices the service may need to run over ⚡.
There are efforts underway to work out naming and discovery solutions for the Constrained Application Protocol (CoAP) [RFC7252] in LLN networks 🧠. Those efforts are outside the scope of this document 🙅♀️.
3.7.7. DNS Resolver Discovery 🔎
Automatic discovery of a name service is required, so client devices in the homenet can resolve external domains on the Internet 🌐. That discovery must support clients that may be a number of router hops away from the name service 🛣️. Similarly, it may be desirable to convey any DNS domain search list that may be in effect for the homenet 📃.
3.7.8. Devices Roaming to/from the Homenet ✈️
Some devices that have registered names in the homenet Internet name space, and that are mobile, will likely attach to the Internet at other locations and get an IP address there 🧳. Devices may also move between different homenets 🏡. In those cases, it is desirable that devices can be accessed by the same name they use in their home network 💫.
This document doesn't discuss solutions to this problem 🙅♀️. Possible solutions include Mobile IPv6 or Dynamic DNS -- either of which would put additional requirements on the homenet -- or setting up a (VPN) tunnel to a server in the home network 🔐🦋.
3.8. Other Considerations 🌈
This section covers two other considerations for home networking. The architecture should not preclude them, but this text stays neutral about them 💜.
3.8.1. Quality of Service 🎢
Quality of Service (QoS) support in a multi-service homenet may be a requirement 📺. For example, a critical system (maybe health care related) might need it, or differentiation between types of traffic like file sharing, cloud storage, live streaming, Voice over IP (VoIP), and so on 🎧. Different link media types may have different properties or capabilities for this 🧵.
However, homenet scenarios should require no new QoS protocols 🙅♀️. A Diffserv [RFC2475] approach with a small number of predefined traffic classes may generally be sufficient 🎀. There's little experience of QoS deployment in home networks right now, though 🤔. QoS, or traffic prioritisation, methods will likely be needed at the CE router, and potentially around boundaries between different link media types 🚦. For example, some traffic may simply not be appropriate for some media and need to be dropped to avoid overloading the constrained media 📉.
There may also be complementary mechanisms that help application performance and behaviour in the homenet domain, such as making sure proper buffering algorithms are used, as described in [Gettys11] ✨🫧.
3.8.2. Operations and Management ✨
okay bestie, let's talk about keeping the homenet running 🧚 this section is like a quick vibe check on ops and management for the kind of homenet this doc describes. a separate doc is supposed to handle the full ops framework, so this is just the opening chat 💅
the big goal is for the homenet to be self-organising and self-configuring at the network layer 🌸 like, prefixes should be able to get assigned to router interfaces without anyone lifting a finger. apps on devices should also be able to use zero-configuration service discovery to find stuff the home user actually cares about 🦋 the home user is NOT expected to assign prefixes to links or manage DNS entries for the home network. that's expert territory 🙈 expert operation shouldn't be blocked, but it's not the norm, obviously.
the user might still need to do a little config, though 🎀 think entering a security key so they can get on the wireless network, or giving a "friendly name" to a device that shows up in service discovery. configuring link- and application-layer services is out of scope for this architecture principles doc, but it's probably going to be needed in an operational homenet, iykyk 💖
even if the user isn't configuring the networking bits, they might still wanna see how their network is doing and what devices are connected 👀 that means network monitoring protocols will be needed so they can view the network and its status, maybe through a web interface or something similar. the user may not understand how the network works, but it's fair to assume they care about faults or problems 😭 monitoring could also reach other devices like storage devices or web cameras, but those are beyond this doc's scope 🍓
an ISP or some third party might also want to offer remote management for the homenet on the user's behalf, or help out when something goes wrong 🫶 if so, appropriate management and monitoring protocols would be required, periodt ✨
specifying the protocols for homenet management and monitoring is out of scope for this doc 💅 again, a separate document is expected to describe the ops and management framework for these kinds of home networks.
one last thing, and it's important 🔥 all network management and monitoring functions should be available over IPv6 transport, even when the homenet is dual stack. literally main character energy for IPv6 💜
3.9. Implementing the Architecture on IPv6 🌈
this architecture text encourages reusing existing protocols, so the necessary mechanisms are mostly already part of the IPv6 protocol set and common implementations 🦋 there are some exceptions though, obviously 💀
for automatic routing, it's expected that solutions can be built from existing protocols 🌸 some smaller updates will probably be needed, like a new mechanism to turn a selected protocol on by default, or a mechanism to automatically assign prefixes to links inside the homenet 🧚
some functionality might need bigger changes or brand-new protocols if the architecture requires it 👑 for example, multihoming with multiple exit routers would likely need extensions to support source and destination address-based routing inside the homenet. big ask, ngl 😭
some protocol changes are required by the architecture no matter what 💖 for example, name resolution and service discovery need extensions to the existing zero-configuration link-local name resolution protocols so they can work across subnets, within the scope of the home network site ✨
some of the hardest problems here are figuring out where the "home" domain ends and the service provider domain begins 🙈 also deciding whether some of the discovery extensions should affect only the network infrastructure or hosts too, and being able to turn on routing, prefix delegation, and other functions in a backwards-compatible way 🎀 the hard stuff, bestie 😤
4. Conclusions 🎀
this text defines principles and requirements for a homenet architecture 💅 the principles and requirements documented here should be observed by any future texts describing homenet protocols for routing, prefix management, security, naming, or service discovery 🫶 no going rogue, bestie 🔥
5. Security Considerations 🔐
security considerations for the homenet architecture are discussed in Section 3.6 above 💜 go read that, it's giving very serious energy 😭
6. References 📚
6.1. Normative References 🌸
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998,
<http://www.rfc-editor.org/info/rfc2460>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006,
<http://www.rfc-editor.org/info/rfc4291>.6.2. Informative References 📚
okay so these are the "extra reading" refs, the ones that give background and context but aren't required to make the homenet stuff work 🤓 bestie, there are a LOT of them, so here they are, all of them, complete:
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
- [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
- [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, <http://www.rfc-editor.org/info/rfc2775>.
- [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
- [RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000, <http://www.rfc-editor.org/info/rfc3002>.
- [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
- [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>.
- [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005, <http://www.rfc-editor.org/info/rfc4192>.
- [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
- [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
- [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007, <http://www.rfc-editor.org/info/rfc4864>.
- [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
- [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.
- [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
- [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
- [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
- [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.
- [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
- [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, March 2011, <http://www.rfc-editor.org/info/rfc6177>.
- [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011, <http://www.rfc-editor.org/info/rfc6204>.
- [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
- [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012, <http://www.rfc-editor.org/info/rfc6555>.
- [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
- [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
- [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
- [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
- [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, "Architectural Considerations on Application Features in the DNS", RFC 6950, October 2013, <http://www.rfc-editor.org/info/rfc6950>.
- [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
- [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", RFC 7157, March 2014, <http://www.rfc-editor.org/info/rfc7157>.
- [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
- [IABdotless] IAB, "IAB Statement: Dotless Domains Considered Harmful", February 2013, <http://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful>.
- [Gettys11] Gettys, J., "Bufferbloat: Dark Buffers in the Internet", March 2011, <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
Acknowledgments 🫶
the authors wanted to thank a huge crew of people for their comments and contributions during the homenet WG meetings and on the WG mailing list 💜 Mikael Abrahamsson, Aamer Akhter, Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis, Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Elwyn Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia Rossi, Barbara Stark, Sander Steffann, Markus Stenberg, Don Sturek, Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur, Curtis Villamizar, Russ White, Dan Wing, and James Woodyatt 🌸
an acknowledgment basically means that a person's text made it into the document or really helped clarify or reinforce something in it ✨ it does NOT mean every contributor agrees with every single point in the document, so don't go assuming that 🙈
Authors' Addresses 💌
Tim Chown (editor)
University of Southampton
Highfield
Southampton, Hampshire SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@piuha.net
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1
Copenhagen DK-2100
Denmark
EMail: anders_brandt@sigmadesigns.com
Ole Troan
Cisco Systems, Inc.
Philip Pedersensvei 1
Lysaker, N-1325
Norway
EMail: ot@cisco.com
Jason Weil
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
United States
EMail: jason.weil@twcable.comand that's a wrap on RFC 7368, bestie!! 🌈✨👑 the whole homenet crew, from the editor to every single person who helped out, made this happen 💖
📦 where this page comes from
- ietf: rfc7368 2014-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms