< draft-ietf-homenet-arch-10.txt   draft-ietf-homenet-arch-11.txt >
Network Working Group T. Chown, Ed. Network Working Group T. Chown, Ed.
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational J. Arkko Intended status: Informational J. Arkko
Expires: February 2, 2014 Ericsson Expires: April 25, 2014 Ericsson
A. Brandt A. Brandt
Sigma Designs Sigma Designs
O. Troan O. Troan
Cisco Systems, Inc. Cisco Systems, Inc.
J. Weil J. Weil
Time Warner Cable Time Warner Cable
August 1, 2013 October 22, 2013
Home Networking Architecture for IPv6 IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-10 draft-ietf-homenet-arch-11
Abstract Abstract
This text describes evolving networking technology within This text describes evolving networking technology within residential
increasingly large residential home networks. The goal of this home networks with increasing numbers of devices and a trend towards
document is to define a general architecture for IPv6-based home increased internal routing. The goal of this document is to define a
networking, describing the associated principles, considerations and general architecture for IPv6-based home networking, describing the
requirements. The text briefly highlights specific implications of associated principles, considerations and requirements. The text
the introduction of IPv6 for home networking, discusses the elements briefly highlights specific implications of the introduction of IPv6
of the architecture, and suggests how standard IPv6 mechanisms and for home networking, discusses the elements of the architecture, and
addressing can be employed in home networking. The architecture suggests how standard IPv6 mechanisms and addressing can be employed
describes the need for specific protocol extensions for certain in home networking. The architecture describes the need for specific
additional functionality. It is assumed that the IPv6 home network protocol extensions for certain additional functionality. It is
is not actively managed, and runs as an IPv6-only or dual-stack assumed that the IPv6 home network is not actively managed, and runs
network. There are no recommendations in this text for the IPv4 part as an IPv6-only or dual-stack network. There are no recommendations
of the network. in this text for the IPv4 part of the network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 2, 2014. This Internet-Draft will expire on April 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5
2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6
2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 7 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 7
2.2. Global addressability and elimination of NAT . . . . . . . 7 2.2. Global addressability and elimination of NAT . . . . . . . 8
2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 8 2.3. Multi-Addressing of devices . . . . . . . . . . . . . . . 8
2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9 2.4. Unique Local Addresses (ULAs) . . . . . . . . . . . . . . 9
2.5. Avoiding manual configuration of IP addresses . . . . . . 10 2.5. Avoiding manual configuration of IP addresses . . . . . . 10
2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 10 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 11
3. Homenet Architecture . . . . . . . . . . . . . . . . . . . . . 11 3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 12 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 12 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 12
3.1.2. Minimise changes to hosts and routers . . . . . . . . 12 3.1.2. Minimise changes to hosts and routers . . . . . . . . 12
3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 13 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13
3.2.2. Network topology models . . . . . . . . . . . . . . . 13 3.2.2. Network topology models . . . . . . . . . . . . . . . 13
3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 17 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 18
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 18 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 19 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20
3.3.1. Differentiating neighbouring homenets . . . . . . . . 20 3.3.1. Differentiating neighbouring homenets . . . . . . . . 21
3.3.2. Largest practical subnets . . . . . . . . . . . . . . 20 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21
3.3.3. Handling varying link technologies . . . . . . . . . . 21 3.3.3. Handling varying link technologies . . . . . . . . . . 22
3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 21 3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 22 3.3.5. Configuration information from the ISP . . . . . . . . 23
3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 22 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 23
3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 24 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 23
3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 25 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 25
3.4.4. Coordination of configuration information . . . . . . 26 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 26
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.4. Coordination of configuration information . . . . . . 27
3.5. Routing functionality . . . . . . . . . . . . . . . . . . 27 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 28
3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 29 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29
3.6.1. Addressability vs reachability . . . . . . . . . . . . 29 3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 30 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 31 3.6.1. Addressability vs reachability . . . . . . . . . . . . 31
3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 31 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 31
3.6.5. ULAs as a hint of connection origin . . . . . . . . . 31 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32
3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 31 3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 32
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 32 3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 32
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 33 3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33
3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 33 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 33
3.7.4. The homenet name service . . . . . . . . . . . . . . . 35 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33
3.7.5. Independent operation . . . . . . . . . . . . . . . . 36 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 36 3.7.3. The homenet name service . . . . . . . . . . . . . . . 35
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 37 3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36
3.7.8. Devices roaming from the homenet . . . . . . . . . . . 37 3.7.5. Independent operation . . . . . . . . . . . . . . . . 38
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 37 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 38
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 37 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 38
3.8.2. Operations and Management . . . . . . . . . . . . . . 38 3.7.8. Devices roaming to/from the homenet . . . . . . . . . 39
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 38 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 39
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 39 3.8.2. Operations and Management . . . . . . . . . . . . . . 39
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . . 39 5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 43 7.1. Normative References . . . . . . . . . . . . . . . . . . . 41
B.1. Version 10 (after AD review) . . . . . . . . . . . . . . . 43 7.2. Informative References . . . . . . . . . . . . . . . . . . 42
B.2. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 43 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 44
B.3. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 45
B.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.1. Version 11 (after IESG review) . . . . . . . . . . . . . . 45
B.5. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.2. Version 10 (after AD review) . . . . . . . . . . . . . . . 45
B.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.3. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 45
B.7. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.4. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.8. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.5. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.9. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.6. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 B.7. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 47
B.8. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.9. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.10. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
This document focuses on evolving networking technology within This document focuses on evolving networking technology within
increasingly large residential home networks and the associated residential home networks with increasing numbers of devices and a
trend towards increased internal routing, and the associated
challenges with their deployment and operation. There is a growing challenges with their deployment and operation. There is a growing
trend in home networking for the proliferation of networking trend in home networking for the proliferation of networking
technology through an increasingly broad range of devices and media. technology through an increasingly broad range of devices and media.
This evolution in scale and diversity sets requirements on IETF This evolution in scale and diversity sets requirements on IETF
protocols. Some of these requirements relate to the introduction of protocols. Some of these requirements relate to the introduction of
IPv6, others to the introduction of specialised networks for home IPv6, others to the introduction of specialised networks for home
automation and sensors. automation and sensors.
While at the time of writing some complex home network topologies While at the time of writing some complex home network topologies
exist, most are relatively simple single subnet networks, and exist, most are relatively simple single subnet networks, and
ostensibly operate using just IPv4. While there may be IPv6 traffic ostensibly operate using just IPv4. While there may be IPv6 traffic
within the network, e.g. for service discovery, the homenet is within the network, e.g., for service discovery, the homenet is
provisioned by the ISP as an IPv4 network. Such networks also provisioned by the ISP as an IPv4 network. Such networks also
typically employ solutions that we would like to avoid, such as typically employ solutions that should be avoided, such as private
private [RFC1918] addressing with (cascaded) network address [RFC1918] addressing with (cascaded) network address translation
translation (NAT)[RFC3022], or they may require expert assistance to (NAT) [RFC3022], or they may require expert assistance to set up.
set up.
In contrast, emerging IPv6-capable home networks are very likely to In contrast, emerging IPv6-capable home networks are very likely to
have multiple internal subnets, e.g. to facilitate private and guest have multiple internal subnets, e.g., to facilitate private and guest
networks, heterogeneous link layers, and smart grid components, and networks, heterogeneous link layers, and smart grid components, and
have enough address space available to allow every device to have a have enough address space available to allow every device to have a
globally unique address. This implies that internal routing globally unique address. This implies that internal routing
functionality is required, and that the homenet's ISP both provides a functionality is required, and that the homenet's ISP both provides a
large enough prefix to allocate a prefix to each subnet, and that a large enough prefix to allocate a prefix to each subnet, and that a
method is supported for such prefixes to be delegated efficiently to method is supported for such prefixes to be delegated efficiently to
those subnets. those subnets.
It is not practical to expect home users to configure their networks. It is not practical to expect home users to configure their networks.
Thus the assumption of this document is that the homenet is as far as Thus the assumption of this document is that the homenet is as far as
possible self-organising and self-configuring, i.e. it should possible self-organising and self-configuring, i.e., it should
function without pro-active management by the residential user. function without pro-active management by the residential user.
The architectural constructs in this document are focused on the The architectural constructs in this document are focused on the
problems to be solved when introducing IPv6, with an eye towards a problems to be solved when introducing IPv6, with an eye towards a
better result than what we have today with IPv4, as well as a better better result than what we have today with IPv4, as well as aiming at
result than if the IETF had not given this specific guidance. The a more consistent solution that addresses as many of the identified
document aims to provide the basis and guiding principles for how requirements as possible. The document aims to provide the basis and
standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be guiding principles for how standard IPv6 mechanisms and addressing
employed in home networking, while coexisting with existing IPv4 [RFC2460] [RFC4291] can be employed in home networking, while
mechanisms. In emerging dual-stack home networks it is vital that coexisting with existing IPv4 mechanisms. In emerging dual-stack
introducing IPv6 does not adversely affect IPv4 operation. We assume home networks it is vital that introducing IPv6 does not adversely
that the IPv4 network architecture in home networks is what it is, affect IPv4 operation. We assume that the IPv4 network architecture
and can not be modified by new recommendations. This document does in home networks is what it is, and can not be modified by new
not discuss how IPv4 home networks provision or deliver support for recommendations. This document does not discuss how IPv4 home
multiple subnets. It should not be assumed that any future new networks provision or deliver support for multiple subnets. It
functionality created with IPv6 in mind will be backward-compatible should not be assumed that any future new functionality created with
to include IPv4 support. Further, future deployments, or specific IPv6 in mind will be backward-compatible to include IPv4 support.
subnets within an otherwise dual-stack home network, may be IPv6- Further, future deployments, or specific subnets within an otherwise
only, in which case considerations for IPv4 impact would not apply. dual-stack home network, may be IPv6-only, in which case
considerations for IPv4 impact would not apply.
This document proposes a baseline homenet architecture, using This document proposes a baseline homenet architecture, using
protocols and implementations that are as far as possible proven and protocols and implementations that are as far as possible proven and
robust. The scope of the document is primarily the network layer robust. The scope of the document is primarily the network layer
technologies that provide the basic functionality to enable technologies that provide the basic functionality to enable
addressing, connectivity, routing, naming and service discovery. addressing, connectivity, routing, naming and service discovery.
While it may, for example, state that homenet components must be While it may, for example, state that homenet components must be
simple to deploy and use, it does not discuss specific user simple to deploy and use, it does not discuss specific user
interfaces, nor does it discuss specific physical, wireless or data- interfaces, nor does it discuss specific physical, wireless or data-
link layer considerations. link layer considerations.
skipping to change at page 5, line 39 skipping to change at page 5, line 40
updates to these existing documents. Further, the scope of this text updates to these existing documents. Further, the scope of this text
is the internal homenet, and thus specific features on the WAN side is the internal homenet, and thus specific features on the WAN side
of the CER are out of scope for this text. of the CER are out of scope for this text.
1.1. Terminology and Abbreviations 1.1. Terminology and Abbreviations
In this section we define terminology and abbreviations used In this section we define terminology and abbreviations used
throughout the text. throughout the text.
o Border: a point, typically resident on a router, between two o Border: a point, typically resident on a router, between two
networks, e.g. between the main internal homenet and a guest networks, e.g., between the main internal homenet and a guest
network. This defines point(s) at which filtering and forwarding network. This defines point(s) at which filtering and forwarding
policies for different types of traffic may be applied. policies for different types of traffic may be applied.
o CER: Customer Edge Router: A border router intended for use in a o CER: Customer Edge Router: A border router intended for use in a
homenet, which connects the homenet to a service provider network. homenet, which connects the homenet to a service provider network.
o FQDN: Fully Qualified Domain Name. A globally unique name space. o FQDN: Fully Qualified Domain Name. A globally unique name.
o Guest network: A part of the home network intended for use by
visitors or guests to the home(net). Devices on the guest network
may typically not see or be able to use all services in the
home(net).
o Homenet: A home network, comprising host and router equipment, o Homenet: A home network, comprising host and router equipment,
with one or more CERs providing connectivity to service provider with one or more CERs providing connectivity to service provider
network(s). network(s).
o Internet Service Provider (ISP): an entity that provides access to o Internet Service Provider (ISP): an entity that provides access to
the Internet. In this document, a service provider specifically the Internet. In this document, a service provider specifically
offers Internet access using IPv6, and may also offer IPv4 offers Internet access using IPv6, and may also offer IPv4
Internet access. The service provider can provide such access Internet access. The service provider can provide such access
over a variety of different transport methods such as DSL, cable, over a variety of different transport methods such as DSL, cable,
wireless, and others. wireless, and others.
o LLN: Low-power and lossy network. o LLN: Low-power and lossy network.
o LQDN: Locally Qualified Domain Name. A name space local to the o LQDN: Locally Qualified Domain Name. A name local to the homenet.
homenet.
o NAT: Network Address Translation. Typically referring to IPv4 o NAT: Network Address Translation. Typically referring to IPv4
Network Address and Port Translation (NAPT) [RFC3022]. Network Address and Port Translation (NAPT) [RFC3022].
o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. o NPTv6: Network Prefix Translation for IPv6 [RFC6296].
o PCP: Port Control Protocol [RFC6887]. o PCP: Port Control Protocol [RFC6887].
o Realm: a network delimited by a defined border. A guest network o Realm: a network delimited by a defined border. A guest network
within a homenet may form one realm. within a homenet may form one realm.
o 'Simple Security'. Defined in [RFC4864] and expanded further in o 'Simple Security'. Defined in [RFC4864] and expanded further in
[RFC6092]; describes recommended perimeter security capabilities [RFC6092]; describes recommended perimeter security capabilities
for IPv6 networks. for IPv6 networks.
o ULA: IPv6 Unique Local Address [RFC4193]. o ULA: IPv6 Unique Local Address [RFC4193].
o UPnP: Universal Plug and Play. Includes the Internet Gateway
Device (IGD) function, which for IPv6 is UPnP IGD Version 2
[IGD-2].
o VM: Virtual machine. o VM: Virtual machine.
o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance.
2. Effects of IPv6 on Home Networking 2. Effects of IPv6 on Home Networking
While IPv6 resembles IPv4 in many ways, there are some notable While IPv6 resembles IPv4 in many ways, there are some notable
differences in the way it may typically be deployed. It changes differences in the way it may typically be deployed. It changes
address allocation principles, making multi-addressing the norm, and, address allocation principles, making multi-addressing the norm, and,
through the vastly increased address space, allows globally unique IP through the vastly increased address space, allows globally unique IP
addresses to be used for all devices in a home network. This section addresses to be used for all devices in a home network. This section
presents an overview of some of the key implications of the presents an overview of some of the key implications of the
introduction of IPv6 for home networking, that are simultaneously introduction of IPv6 for home networking, that are simultaneously
both promising and problematic. both promising and problematic.
2.1. Multiple subnets and routers 2.1. Multiple subnets and routers
While simple layer 3 topologies involving as few subnets as possible While simple layer 3 topologies involving as few subnets as possible
are preferred in home networks, the incorporation of dedicated are preferred in home networks, the incorporation of dedicated
(routed) subnets remains necessary for a variety of reasons. For (routed) subnets remains necessary for a variety of reasons. For
instance, an increasingly common feature in modern home routers is instance, an increasingly common feature in modern home routers is
the ability to support both guest and private network subnets. the ability to support both guest and private network subnets.
Likewise, there may be a need to separate building control or Likewise, there may be a need to separate home automation or
corporate extensions from the main Internet access network, or corporate extension LANs (whereby a home worker can have their
different subnets may in general be associated with parts of the corporate network extended into the home using a virtual private
homenet that have different routing and security policies. Further, network, commonly presented as one port on an Ethernet device) from
link layer networking technology is poised to become more the main Internet access network, or different subnets may in general
heterogeneous, as networks begin to employ both traditional Ethernet be associated with parts of the homenet that have different routing
technology and link layers designed for low-power and lossy networks and security policies. Further, link layer networking technology is
(LLNs), such as those used for certain types of sensor devices. poised to become more heterogeneous, as networks begin to employ both
Constraining the flow of certain traffic from Ethernet links to much traditional Ethernet technology and link layers designed for low-
lower capacity links thus becomes an important topic. power and lossy networks (LLNs), such as those used for certain types
of sensor devices. Constraining the flow of certain traffic from
Ethernet links to much lower capacity links thus becomes an important
topic.
The introduction of IPv6 for home networking makes it possible for The introduction of IPv6 for home networking makes it possible for
every home network to be delegated enough address space from its ISP every home network to be delegated enough address space from its ISP
to provision globally unique prefixes for each such subnet in the to provision globally unique prefixes for each such subnet in the
home. While the number of addresses in a standard /64 IPv6 prefix is home. While the number of addresses in a standard /64 IPv6 prefix is
practically unlimited, the number of prefixes available for practically unlimited, the number of prefixes available for
assignment to the home network is not. As a result the growth assignment to the home network is not. As a result the growth
inhibitor for the home network shifts from the number of addresses to inhibitor for the home network shifts from the number of addresses to
the number of prefixes offered by the provider; this topic is the number of prefixes offered by the provider; this topic is
discussed in [RFC6177] (BCP 157), which recommends that "end sites discussed in [RFC6177] (BCP 157), which recommends that "end sites
skipping to change at page 8, line 5 skipping to change at page 8, line 11
existing protocols to work across that scope, or introduce proxies existing protocols to work across that scope, or introduce proxies
for existing link layer protocols. This topic is discussed in for existing link layer protocols. This topic is discussed in
Section 3.7. Section 3.7.
2.2. Global addressability and elimination of NAT 2.2. Global addressability and elimination of NAT
The possibility for direct end-to-end communication on the Internet The possibility for direct end-to-end communication on the Internet
to be restored by the introduction of IPv6 is on the one hand an to be restored by the introduction of IPv6 is on the one hand an
incredible opportunity for innovation and simpler network operation, incredible opportunity for innovation and simpler network operation,
but on the other hand it is also a concern as it potentially exposes but on the other hand it is also a concern as it potentially exposes
nodes in the internal networks to receipt of unwanted traffic from nodes in the internal networks to receipt of unwanted and possibly
the Internet. malicious traffic from the Internet.
With devices and applications able to talk directly to each other With devices and applications able to talk directly to each other
when they have globally unique addresses, there may be an expectation when they have globally unique addresses, there may be an expectation
of improved host security to compensate for this. It should be noted of improved host security to compensate for this. It should be noted
that many devices may (for example) ship with default settings that that many devices may (for example) ship with default settings that
make them readily vulnerable to compromise by external attackers if make them readily vulnerable to compromise by external attackers if
globally accessible, or may simply not have robustness designed-in globally accessible, or may simply not have robustness designed-in
because it was either assumed such devices would only be used on because it was either assumed such devices would only be used on
private networks or the device itself doesn't have the computing private networks or the device itself doesn't have the computing
power to apply the necessary security methods. In addition, the power to apply the necessary security methods. In addition, the
upgrade cycle for devices (or their firmware) may be slow, and/or upgrade cycle for devices (or their firmware) may be slow, and/or
lack auto-update mechanisms. lack auto-update mechanisms.
It is thus important to distinguish between addressability and It is thus important to distinguish between addressability and
reachability. While IPv6 offers global addressability through use of reachability. While IPv6 offers global addressability through use of
globally unique addresses in the home, whether devices are globally globally unique addresses in the home, whether devices are globally
reachable or not would depend on any firewall or filtering reachable or not would depend on any firewall or filtering
configuration, and not, as is commonly the case with IPv4, the configuration, and not, as is commonly the case with IPv4, the
presence or use of NAT. In this respect, IPv6 networks may or may presence or use of NAT. In this respect, IPv6 networks may or may
not have filters applied at their borders to control such traffic, not have filters applied at their borders to control such traffic,
i.e. at the homenet CER. [RFC4864] and [RFC6092] discuss such i.e., at the homenet CER. [RFC4864] and [RFC6092] discuss such
filtering, and the merits of 'default allow' against 'default deny' filtering, and the merits of 'default allow' against 'default deny'
policies for external traffic initiated into a homenet. This policies for external traffic initiated into a homenet. This
document takes no position on which mode is the default, but assumes document takes no position on which mode is the default, but assumes
the choice for the homenet to use either mode would be available. the choice for the homenet to use either mode would be available.
This topic is discussed further in Section 3.6.1.
2.3. Multi-Addressing of devices 2.3. Multi-Addressing of devices
In an IPv6 network, devices will often acquire multiple addresses, In an IPv6 network, devices will often acquire multiple addresses,
typically at least a link-local address and one or more globally typically at least a link-local address and one or more globally
unique addresses. Where a homenet is multihomed, a device would unique addresses. Where a homenet is multihomed, a device would
typically receive a globally unique address (GUA) from within the typically receive a globally unique address (GUA) from within the
delegated prefix from each upstream ISP. Devices may also have an delegated prefix from each upstream ISP. Devices may also have an
IPv4 address if the network is dual-stack, an IPv6 Unique Local IPv4 address if the network is dual-stack, an IPv6 Unique Local
Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy
Addresses [RFC4941]. Addresses [RFC4941].
skipping to change at page 9, line 18 skipping to change at page 9, line 25
Section 3.2.4. Section 3.2.4.
2.4. Unique Local Addresses (ULAs) 2.4. Unique Local Addresses (ULAs)
[RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be
used to address devices within the scope of a single site. Support used to address devices within the scope of a single site. Support
for ULAs for IPv6 CERs is described in [RFC6204]. A home network for ULAs for IPv6 CERs is described in [RFC6204]. A home network
running IPv6 should deploy ULAs alongside its globally unique running IPv6 should deploy ULAs alongside its globally unique
prefix(es) to allow stable communication between devices (on prefix(es) to allow stable communication between devices (on
different subnets) within the homenet where that externally allocated different subnets) within the homenet where that externally allocated
globally unique prefix may change over time, e.g. due to renumbering globally unique prefix may change over time, e.g., due to renumbering
within the subscriber's ISP, or where external connectivity may be within the subscriber's ISP, or where external connectivity may be
temporarily unavailable. A homenet using provider-assigned global temporarily unavailable. A homenet using provider-assigned global
addresses is exposed to its ISP renumbering the network to a much addresses is exposed to its ISP renumbering the network to a much
larger degree than before whereas, for IPv4, NAT isolated the user larger degree than before whereas, for IPv4, NAT isolated the user
against ISP renumbering to some extent. against ISP renumbering to some extent.
While setting up a network there may be a period where it has no While setting up a network there may be a period where it has no
external connectivity, in which case ULAs would be required for external connectivity, in which case ULAs would be required for
inter-subnet communication. In the case where LLNs are being set up inter-subnet communication. In the case where home automation
in a new home/deployment (as early as during construction of the networks are being set up in a new home/deployment (as early as
home), LLNs will likely need to use their own /48 ULA prefix. during construction of the home), such networks will likely need to
Depending upon circumstances beyond the scope of homenet, it may be use their own /48 ULA prefix. Depending upon circumstances beyond
impossible to renumber the ULA used by the LLN so routing between ULA the control of the owner of the homenet, it may be impossible to
/48s may be required. Also, some devices, particularly constrained renumber the ULA used by the home automation network so routing
devices, may have only a ULA (in addition to a link-local), while between ULA /48s may be required. Also, some devices, particularly
others may have both a GUA and a ULA. 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 RFC 1918 space, the use of ULAs does Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT not imply use of an IPv6 equivalent of a traditional IPv4 NAT
[RFC6296]. In an IPv6 homenet a node should only use its ULA address [RFC3022], or of NPTv6 prefix-based NAT [RFC6296]. When an IPv6 node
internally, and use its additional globally unique IPv6 address as a in a homenet has both a ULA and a globally unique IPv6 address, it
source address for external communications. By using such globally should only use its ULA address internally, and use its additional
unique addresses between hosts and devices in remote networks, the globally unique IPv6 address as a source address for external
architectural cost and complexity, particularly to applications, of communications. This should be the natural behaviour given support
NAT or NPTv6 translation is avoided. As such, neither IPv6 NAT or for Default Address Selection for IPv6 [RFC6724]. By using such
NPTv6 is recommended for use in the homenet architecture. globally unique addresses between hosts and devices in remote
networks, the architectural cost and complexity, particularly to
applications, of NAT or NPTv6 translation is avoided. As such,
neither IPv6 NAT or NPTv6 is recommended for use in the homenet
architecture. Further, the homenet border router(s) should filter
packets with ULA source/destination addresses as discussed in
Section 3.4.2.
Devices in a homenet may be given only a ULA as a means to restrict Devices in a homenet may be given only a ULA as a means to restrict
reachability from outside the homenet. ULAs can be used by default reachability from outside the homenet. ULAs can be used by default
for devices that, without additional configuration (e.g. via a web for devices that, without additional configuration (e.g., via a web
interface), would only offer services to the internal network. For interface), would only offer services to the internal network. For
example, a printer might only accept incoming connections on a ULA example, a printer might only accept incoming connections on a ULA
until configured to be globally reachable, at which point it acquires until configured to be globally reachable, at which point it acquires
a global IPv6 address and may be advertised via a global name space. a global IPv6 address and may be advertised via a global name space.
Where both a ULA and a global prefix are in use, the ULA source Where both a ULA and a global prefix are in use, the ULA source
address is used to communicate with ULA destination addresses when address is used to communicate with ULA destination addresses when
appropriate, i.e. when the ULA source and destination lie within the appropriate, i.e., when the ULA source and destination lie within the
/48 ULA prefix(es) known to be used within the same homenet. In /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 cases where multiple /48 ULA prefixes are in use within a single
homenet (perhaps because multiple homenet routers each independently homenet (perhaps because multiple homenet routers each independently
auto-generate a /48 ULA prefix and then share prefix/routing auto-generate a /48 ULA prefix and then share prefix/routing
information), utilising a ULA source address and a ULA destination information), utilising a ULA source address and a ULA destination
address from two disjoint internal ULA prefixes is preferable to address from two disjoint internal ULA prefixes is preferable to
using GUAs. using GUAs.
While a homenet should operate correctly with two or more /48 ULAs While a homenet should operate correctly with two or more /48 ULAs
enabled, a mechanism for the creation and use of a single /48 ULA enabled, a mechanism for the creation and use of a single /48 ULA
prefix is desirable for addressing consistency and policy prefix is desirable for addressing consistency and policy
enforcement. It may thus be expected that one router in the homenet enforcement.
be elected a 'master' to delegate ULA prefixes to subnets from a
single /48 ULA prefix.
A counter-argument to using ULAs is that it is undesirable to A counter-argument to using ULAs is that it is undesirable to
aggressively deprecate global prefixes for temporary loss of aggressively deprecate global prefixes for temporary loss of
connectivity, so for a host to lose its global address there would connectivity, so for a host to lose its global address there would
have to be a connection breakage longer than the lease period, and have to be a connection breakage longer than the lease period, and
even then, deprecating prefixes when there is no connectivity may not even then, deprecating prefixes when there is no connectivity may not
be advisable. However, it is assumed in this architecture that be advisable. However, it is assumed in this architecture that
homenets should support and use ULAs. homenets should support and use ULAs.
2.5. Avoiding manual configuration of IP addresses 2.5. Avoiding manual configuration of IP addresses
Some IPv4 home networking devices expose IPv4 addresses to users, Some IPv4 home networking devices expose IPv4 addresses to users,
e.g. the IPv4 address of a home IPv4 CER that may be configured via a e.g., the IPv4 address of a home IPv4 CER that may be configured via
web interface. In potentially complex future IPv6 homenets, users a web interface. In potentially complex future IPv6 homenets, users
should not be expected to enter IPv6 literal addresses in devices or should not be expected to enter IPv6 literal addresses in devices or
applications, given their much greater length and the apparent applications, given their much greater length and the apparent
randomness of such addresses to a typical home user. Thus, even for randomness of such addresses to a typical home user. Thus, even for
the simplest of functions, simple naming and the associated (minimal, the simplest of functions, simple naming and the associated (minimal,
and ideally zero configuration) discovery of services is imperative and ideally zero configuration) discovery of services is imperative
for the easy deployment and use of homenet devices and applications. for the easy deployment and use of homenet devices and applications.
As mentioned previously, this means that zeroconf naming and service
discovery protocols must be capable of operating across subnet
boundaries.
2.6. IPv6-only operation 2.6. IPv6-only operation
It is likely that IPv6-only networking will be deployed first in It is likely that IPv6-only networking will be deployed first in new
'greenfield' homenet scenarios, or perhaps as one element of an home network deployments, often refered to as 'greenfield' scenarios,
otherwise dual-stack network. Running IPv6-only adds additional where there is no existing IPv4 capability, or perhaps as one element
requirements, e.g. for devices to get configuration information via of an otherwise dual-stack network. Running IPv6-only adds
IPv6 transport (not relying on an IPv4 protocol such as IPv4 DHCP), additional requirements, e.g., for devices to get configuration
and for devices to be able to initiate communications to external information via IPv6 transport (not relying on an IPv4 protocol such
devices that are IPv4-only. Thus, for example, the following as IPv4 DHCP), and for devices to be able to initiate communications
requirements are amongst those that should be considered in IPv6-only to external devices that are IPv4-only.
environments:
o Ensuring there is a way to access content in the IPv4 Internet.
This can be arranged through appropriate use of NAT64 [RFC6144]
and DNS64 [RFC6145], for example, or via a node-based DS-Lite
[RFC6333] approach.
o Ensuring DNS resolver discovery mechanisms are enabled for IPv6.
Both stateless DHCPv6 [RFC3736] [RFC3646] and Router Advertisement
options [RFC6106] may have to be supported and turned on by
default to ensure maximum compatibility with all types of hosts in
the network. This requires, however, that a working DNS server is
known and addressable via IPv6, and that the automatic discovery
of such a server is possible through multiple routers in the
homenet.
o Ensuring all nodes in the home network support operations in IPv6- Some specific transition technologies which may be deployed by the
only mode. Some current devices work well with dual-stack but homenet's ISP are discussed in [I-D.ietf-v6ops-6204bis]. In
fail to recognise connectivity when IPv4 DHCP fails, for instance. addition, certain other functions may be desirable on the CER, e.g.,
to access content in the IPv4 Internet, NAT64 [RFC6144] and DNS64
[RFC6145] may be applicable.
The widespread availability of robust solutions to these types of The widespread availability of robust solutions to these types of
requirements will help accelerate the uptake of IPv6-only homenets. requirements will help accelerate the uptake of IPv6-only homenets.
The specifics of these are however beyond the scope of this document, The specifics of these are however beyond the scope of this document,
especially those functions that reside on the CER. especially those functions that reside on the CER.
3. Homenet Architecture 3. Homenet Architecture Principles
The aim of this text is to outline how to construct advanced IPv6- The aim of this text is to outline how to construct advanced IPv6-
based home networks involving multiple routers and subnets using based home networks involving multiple routers and subnets using
standard IPv6 addressing and protocols [RFC2460] [RFC4291]. In this standard IPv6 addressing and protocols [RFC2460] [RFC4291] as the
section, we present the elements of the proposed home networking basis. As described in Section 3.1, solutions should as far as
architecture, with discussion of the associated design principles. possible re-use existing protocols, and minimise changes to hosts and
routers, but some new protocols, or extensions, are likely to be
required. In this section, we present the elements of the proposed
home networking architecture, with discussion of the associated
design principles.
In general, home network equipment needs to be able to operate in In general, home network equipment needs to be able to operate in
networks with a range of different properties and topologies, where networks with a range of different properties and topologies, where
home users may plug components together in arbitrary ways and expect home users may plug components together in arbitrary ways and expect
the resulting network to operate. Significant manual configuration the resulting network to operate. Significant manual configuration
is rarely, if at all, possible, or even desirable given the knowledge is rarely, if at all, possible, or even desirable given the knowledge
level of typical home users. Thus the network should, as far as level of typical home users. Thus the network should, as far as
possible, be self-configuring, though configuration by advanced users possible, be self-configuring, though configuration by advanced users
should not be precluded. should not be precluded.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
3.1. General Principles 3.1. General Principles
There is little that the Internet standards community can do about There is little that the Internet standards community can do about
the physical topologies or the need for some networks to be separated the physical topologies or the need for some networks to be separated
at the network layer for policy or link layer compatibility reasons. at the network layer for policy or link layer compatibility reasons.
However, there is a lot of flexibility in using IP addressing and However, there is a lot of flexibility in using IP addressing and
inter-networking mechanisms. This text discusses how such inter-networking mechanisms. This text discusses how such
flexibility should be used to provide the best user experience and flexibility should be used to provide the best user experience and
ensure that the network can evolve with new applications in the ensure that the network can evolve with new applications in the
future. The principles described in this text should be followed future. The principles described in this text should be followed
when designing homenet solutions. when designing homenet protocol solutions.
3.1.1. Reuse existing protocols 3.1.1. Reuse existing protocols
It is desirable to reuse existing protocols where possible, but at It is desirable to reuse existing protocols where possible, but at
the same time to avoid consciously precluding the introduction of new the same time to avoid consciously precluding the introduction of new
or emerging protocols. A generally conservative approach, giving or emerging protocols. A generally conservative approach, giving
weight to running (and available) code, is preferable. Where new weight to running (and available) code, is preferable. Where new
protocols are required, evidence of commitment to implementation by protocols are required, evidence of commitment to implementation by
appropriate vendors or development communities is highly desirable. appropriate vendors or development communities is highly desirable.
Protocols used should be backwardly compatible, and forward Protocols used should be backwardly compatible, and forward
compatible where changes are made. compatible where changes are made.
3.1.2. Minimise changes to hosts and routers 3.1.2. Minimise changes to hosts and routers
Where possible, any requirement for changes to hosts and routers In order to maximise deployability of new homenets, where possible
should be minimised, though solutions which, for example, any requirement for changes to hosts and routers should be minimised,
incrementally improve capability with host or router changes may be though solutions which, for example, incrementally improve capability
acceptable. with host or router changes may be acceptable. There may be cases
where changes are unavoidable, e.g., to allow a given homenet routing
protocol to be self-configuring.
3.2. Homenet Topology 3.2. Homenet Topology
This section considers homenet topologies, and the principles that This section considers homenet topologies, and the principles that
may be applied in designing an architecture to support as wide a may be applied in designing an architecture to support as wide a
range of such topologies as possible. range of such topologies as possible.
3.2.1. Supporting arbitrary topologies 3.2.1. Supporting arbitrary topologies
There should ideally be no built-in assumptions about the topology in There should ideally be no built-in assumptions about the topology in
home networks, as users are capable of connecting their devices in home networks, as users are capable of connecting their devices in
'ingenious' ways. Thus arbitrary topologies and arbitrary routing 'ingenious' ways. Thus arbitrary topologies and arbitrary routing
will need to be supported, or at least the failure mode for when the will need to be supported, or at least the failure mode for when the
user makes a mistake should be as robust as possible, e.g. de- user makes a mistake should be as robust as possible, e.g., de-
activating a certain part of the infrastructure to allow the rest to activating a certain part of the infrastructure to allow the rest to
operate. In such cases, the user should ideally have some useful operate. In such cases, the user should ideally have some useful
indication of the failure mode encountered. indication of the failure mode encountered.
There should be no topology scenarios which cause loss of There should be no topology scenarios which cause loss of
connectivity, except when the user creates a physical island within connectivity, except when the user creates a physical island within
the topology. Some potentially pathological cases that can be the topology. Some potentially pathological cases that can be
created include bridging ports of a router together, however this created include bridging ports of a router together, however this
case can be detected and dealt with by the router. Loops within a case can be detected and dealt with by the router. Loops within a
routed topology are in a sense good in that they offer redundancy. routed topology are in a sense good in that they offer redundancy.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
to a single network. to a single network.
3.2.2. Network topology models 3.2.2. Network topology models
Most IPv4 home network models at the time of writing tend to be Most IPv4 home network models at the time of writing tend to be
relatively simple, typically a single NAT router to the ISP and a relatively simple, typically a single NAT router to the ISP and a
single internal subnet but, as discussed earlier, evolution in single internal subnet but, as discussed earlier, evolution in
network architectures is driving more complex topologies, such as the network architectures is driving more complex topologies, such as the
separation of guest and private networks. There may also be some separation of guest and private networks. There may also be some
cascaded IPv4 NAT scenarios, which we mention in the next section. cascaded IPv4 NAT scenarios, which we mention in the next section.
For IPv6 homenets, the network models described in [RFC6204] and its For IPv6 homenets, the Network Architectures described in [RFC6204]
successor RFC 6204-bis [I-D.ietf-v6ops-6204bis] should, as a minimum, and its successor [I-D.ietf-v6ops-6204bis] should, as a minimum, be
be supported. supported.
There are a number of properties or attributes of a home network that There are a number of properties or attributes of a home network that
we can use to describe its topology and operation. The following we can use to describe its topology and operation. The following
properties apply to any IPv6 home network: properties apply to any IPv6 home network:
o Presence of internal routers. The homenet may have one or more o Presence of internal routers. The homenet may have one or more
internal routers, or may only provide subnetting from interfaces internal routers, or may only provide subnetting from interfaces
on the CER. on the CER.
o Presence of isolated internal subnets. There may be isolated o Presence of isolated internal subnets. There may be isolated
skipping to change at page 14, line 38 skipping to change at page 14, line 38
o Number of upstream providers. The majority of home networks today o Number of upstream providers. The majority of home networks today
consist of a single upstream ISP, but it may become more common in consist of a single upstream ISP, but it may become more common in
the future for there to be multiple ISPs, whether for resilience the future for there to be multiple ISPs, whether for resilience
or provision of additional services. Each would offer its own or provision of additional services. Each would offer its own
prefix. Some may or may not provide a default route to the public prefix. Some may or may not provide a default route to the public
Internet. Internet.
o Number of CERs. The homenet may have a single CER, which might be o Number of CERs. The homenet may have a single CER, which might be
used for one or more providers, or multiple CERs. The presence of used for one or more providers, or multiple CERs. The presence of
multiple CERs adds additional complexity for multihoming multiple CERs adds additional complexity for multihoming
scenarios, and protocols like PCP that need to manage connection- scenarios, and protocols like PCP that may need to manage
oriented state mappings. connection-oriented state mappings on the same CER as used for
subsequent traffic flows.
In the following sections we give some examples of the types of In the following sections we give some examples of the types of
homenet topologies we may see in the future. This is not intended to homenet topologies we may see in the future. This is not intended to
be an exhaustive or complete list, rather an indicative one to be an exhaustive or complete list, rather an indicative one to
facilitate the discussion in this text. facilitate the discussion in this text.
3.2.2.1. A: Single ISP, Single CER, Internal routers 3.2.2.1. A: Single ISP, Single CER, Internal routers
Figure 1 shows a home network with multiple local area networks. Figure 1 shows a home network with multiple local area networks.
These may be needed for reasons relating to different link layer These may be needed for reasons relating to different link layer
technologies in use or for policy reasons, e.g. classic Ethernet in technologies in use or for policy reasons, e.g., classic Ethernet in
one subnet and a LLN link layer technology in another. In this one subnet and a LLN link layer technology in another. In this
example there is no single router that a priori understands the example there is no single router that a priori understands the
entire topology. The topology itself may also be complex, and it may entire topology. The topology itself may also be complex, and it may
not be possible to assume a pure tree form, for instance (because not be possible to assume a pure tree form, for instance (because
home users may plug routers together to form arbitrary topologies home users may plug routers together to form arbitrary topologies
including loops). including loops).
+-------+-------+ \ +-------+-------+ \
| Service | \ | Service | \
| Provider | | Service | Provider | | Service
skipping to change at page 16, line 47 skipping to change at page 17, line 39
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| H1 | | H2 | | H3 | | H4 | / | H1 | | H2 | | H3 | | H4 | /
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 2 Figure 2
Figure 2 illustrates a multihomed homenet model, where the customer Figure 2 illustrates a multihomed homenet model, where the customer
has connectivity via CER1 to ISP A and via CER2 to ISP B. This has connectivity via CER1 to ISP A and via CER2 to ISP B. This
example shows one shared subnet where IPv6 nodes would potentially be example shows one shared subnet where IPv6 nodes would potentially be
multihomed and receive multiple IPv6 global addresses, one per ISP. multihomed and receive multiple IPv6 global prefixes, one per ISP.
This model may also be combined with that shown in Figure 1 to create This model may also be combined with that shown in Figure 1 to create
a more complex scenario with multiple internal routers. Or the above a more complex scenario with multiple internal routers. Or the above
shared subnet may be split in two, such that each CER serves a shared subnet may be split in two, such that each CER serves a
separate isolated subnet, which is a scenario seen with some IPv4 separate isolated subnet, which is a scenario seen with some IPv4
networks today. networks today.
3.2.2.3. C: Two ISPs, One CER, Shared subnet 3.2.2.3. C: Two ISPs, One CER, Shared subnet
+-------+-------+ +-------+-------+ \ +-------+-------+ +-------+-------+ \
| Service | | Service | \ | Service | | Service | \
skipping to change at page 18, line 46 skipping to change at page 19, line 43
multi-addressing is in use, hosts need some way to pick source and multi-addressing is in use, hosts need some way to pick source and
destination address pairs for connections. A host may choose a destination address pairs for connections. A host may choose a
source address to use by various methods, most commonly [RFC6724]. source address to use by various methods, most commonly [RFC6724].
Applications may of course do different things, and this should not Applications may of course do different things, and this should not
be precluded. be precluded.
For the single CER Network Model C illustrated above, multihoming may For the single CER Network Model C illustrated above, multihoming may
be offered by source-based routing at the CER. With multiple exit be offered by source-based routing at the CER. With multiple exit
routers, as in CER Network Model B, the complexity rises. Given a routers, as in CER Network Model B, the complexity rises. Given a
packet with a source address on the home network, the packet must be packet with a source address on the home network, the packet must be
routed to the proper egress to avoid BCP 38 filtering if exiting routed to the proper egress to avoid BCP 38 ingress filtering if
through the wrong ISP. It is highly desirable that the packet is exiting through the wrong ISP. It is highly desirable that the
routed in the most efficient manner to the correct exit, though as a packet is routed in the most efficient manner to the correct exit,
minimum requirement the packet should not be dropped. though as a minimum requirement the packet should not be dropped.
The homenet architecture should support both the above models, i.e. The homenet architecture should support both the above models, i.e.,
one or more CERs. However, the general multihoming problem is broad, one or more CERs. However, the general multihoming problem is broad,
and solutions suggested to date within the IETF have included complex and solutions suggested to date within the IETF have included complex
architectures for monitoring connectivity, traffic engineering, architectures for monitoring connectivity, traffic engineering,
identifier-locator separation, connection survivability across identifier-locator separation, connection survivability across
multihoming events, and so on. It is thus important that the homenet multihoming events, and so on. It is thus important that the homenet
architecture should as far as possible minimise the complexity of any architecture should as far as possible minimise the complexity of any
multihoming support. multihoming support.
An example of such a 'simpler' approach has been documented in An example of such a 'simpler' approach has been documented in
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a
skipping to change at page 19, line 32 skipping to change at page 20, line 30
require relatively significant router changes but avoid host changes. require relatively significant router changes but avoid host changes.
As explained previously, while NPTv6 has been proposed for providing As explained previously, while NPTv6 has been proposed for providing
multi-homing support in networks, its use is not recommended in the multi-homing support in networks, its use is not recommended in the
homenet architecture. homenet architecture.
It should be noted that some multihoming scenarios may see one It should be noted that some multihoming scenarios may see one
upstream being a "walled garden", and thus only appropriate for upstream being a "walled garden", and thus only appropriate for
connectivity to the services of that provider; an example may be a connectivity to the services of that provider; an example may be a
VPN service that only routes back to the enterprise business network VPN service that only routes back to the enterprise business network
of a user in the homenet. While we should not specifically target of a user in the homenet. As per [RFC3002] (section 4.2.1) we do not
walled garden multihoming as a principal goal, it should not be specifically target walled garden multihoming as a goal of this
precluded. document.
The homenet architecture should also not preclude use of host or The homenet architecture should also not preclude use of host or
application-oriented tools, e.g. Shim6 [RFC5533], MPTCP [RFC6824] or application-oriented tools, e.g., Shim6 [RFC5533], MPTCP [RFC6824] or
Happy Eyeballs [RFC6555]. In general, any incremental improvements Happy Eyeballs [RFC6555]. In general, any incremental improvements
obtained by host changes should give benefit for the hosts obtained by host changes should give benefit for the hosts
introducing them, but not be required. introducing them, but not be required.
3.3. A Self-Organising Network 3.3. A Self-Organising Network
The home network architecture should be naturally self-organising and The home network infrastructure should be naturally self-organising
self-configuring under different circumstances relating to the and self-configuring under different circumstances relating to the
connectivity status to the Internet, number of devices, and physical connectivity status to the Internet, number of devices, and physical
topology. At the same time, it should be possible for advanced users topology. At the same time, it should be possible for advanced users
to manually adjust (override) the current configuration. to manually adjust (override) the current configuration.
While a goal of the homenet architecture is for the network to be as While a goal of the homenet architecture is for the network to be as
self-organising as possible, there may be instances where some manual self-organising as possible, there may be instances where some manual
configuration is required, e.g. the entry of a cryptographic key to configuration is required, e.g., the entry of a cryptographic key to
apply wireless security, or to configure a shared routing secret. apply wireless security, or to configure a shared routing secret.
The latter may be relevant when considering how to bootstrap a The latter may be relevant when considering how to bootstrap a
routing configuration. It is highly desirable that the number of routing configuration. It is highly desirable that the number of
such configurations is minimised. such configurations is minimised.
3.3.1. Differentiating neighbouring homenets 3.3.1. Differentiating neighbouring homenets
It is important that self-configuration with 'unintended' devices is It is important that self-configuration with 'unintended' devices is
avoided. There should be a way for a user to administratively assert avoided. There should be a way for a user to administratively assert
in a simple way whether or not a device belongs to a homenet. The in a simple way whether or not a device belongs to a homenet. The
goal is to allow the establishment of borders, particularly between goal is to allow the establishment of borders, particularly between
skipping to change at page 20, line 37 skipping to change at page 21, line 36
Today's IPv4 home networks generally have a single subnet, and early Today's IPv4 home networks generally have a single subnet, and early
dual-stack deployments have a single congruent IPv6 subnet, possibly dual-stack deployments have a single congruent IPv6 subnet, possibly
with some bridging functionality. More recently, some vendors have with some bridging functionality. More recently, some vendors have
started to introduce 'home' and 'guest' functions, which in IPv6 started to introduce 'home' and 'guest' functions, which in IPv6
would be implemented as two subnets. would be implemented as two subnets.
Future home networks are highly likely to have one or more internal Future home networks are highly likely to have one or more internal
routers and thus need multiple subnets, for the reasons described routers and thus need multiple subnets, for the reasons described
earlier. As part of the self-organisation of the network, the earlier. As part of the self-organisation of the network, the
homenet should subdivide itself to the largest practical subnets that homenet should subdivide itself into the largest practical subnets
can be constructed within the constraints of link layer mechanisms, that can be constructed within the constraints of link layer
bridging, physical connectivity, and policy, and where applicable mechanisms, bridging, physical connectivity, and policy, and where
performance or other criteria. In such subdivisions the logical applicable performance or other criteria. In such subdivisions the
topology may not necessarily match the physical topology. This text logical topology may not necessarily match the physical topology.
does not, however, make recommendations on how such subdivision This text does not, however, make recommendations on how such
should occur. It is expected that subsequent documents will address subdivision should occur. It is expected that subsequent documents
this problem. will address this problem.
While it may be desirable to maximise the chance of link-local While it may be desirable to maximise the chance of link-local
protocols operating across a homenet by maximising the size of a protocols operating across a homenet by maximising the size of a
subnet, multi-subnet home networks are inevitable, so their support subnet, multi-subnet home networks are inevitable, so their support
must be included. must be included.
3.3.3. Handling varying link technologies 3.3.3. Handling varying link technologies
Homenets tend to grow organically over many years, and a homenet will Homenets tend to grow organically over many years, and a homenet will
typically be built over link-layer technologies from different typically be built over link-layer technologies from different
skipping to change at page 21, line 28 skipping to change at page 22, line 28
protocols should be able to choose the faster links and avoid the protocols should be able to choose the faster links and avoid the
slower ones. slower ones.
Links (particularly wireless links) may also have limited numbers of Links (particularly wireless links) may also have limited numbers of
transmit opportunities (txops), and there is a clear trend driven by transmit opportunities (txops), and there is a clear trend driven by
both power and downward compatibility constraints toward aggregation both power and downward compatibility constraints toward aggregation
of packets into these limited txops while increasing throughput. of packets into these limited txops while increasing throughput.
Transmit opportunities may be a system's scarcest resource and Transmit opportunities may be a system's scarcest resource and
therefore also strongly limit actual throughput available. therefore also strongly limit actual throughput available.
Therefore protocols that avoid being 'chatty', do not require
flooding, and enable isolation of traffic between subnets are
preferable to those which burn scarce resources.
3.3.4. Homenet realms and borders 3.3.4. Homenet realms and borders
The homenet will need to be aware of the extent of its own 'site', The homenet will need to be aware of the extent of its own 'site',
which will, for example, define the borders for ULA and site scope which will, for example, define the borders for ULA and site scope
multicast traffic, and may require specific security policies to be multicast traffic, and may require specific security policies to be
applied. The homenet will have one or more such borders with applied. The homenet will have one or more such borders with
external connectivity providers. external connectivity providers.
A homenet will most likely also have internal borders between A homenet will most likely also have internal borders between
internal realms, e.g. a guest realm or a corporate network extension internal realms, e.g., a guest realm or a corporate network extension
realm. It should be possible to automatically discover these realm. It should be possible to automatically discover these
borders, which will determine, for example, the scope of where borders, which will determine, for example, the scope of where
network prefixes, routing information, network traffic, service network prefixes, routing information, network traffic, service
discovery and naming may be shared. The default mode internally discovery and naming may be shared. The default mode internally
should be to share everything. should be to share everything.
It is expected that a realm would span at least an entire subnet, and It is expected that a realm would span at least an entire subnet, and
thus the borders lie at routers which receive delegated prefixes thus the borders lie at routers which receive delegated prefixes
within the homenet. It is also desirable, for a richer security within the homenet. It is also desirable, for a richer security
model, that hosts are able to make communication decisions based on model, that hosts are able to make communication decisions based on
available realm and associated prefix information in the same way available realm and associated prefix information in the same way
that routers at realm borders can. that routers at realm borders can.
A simple homenet model may just consider three types of realm and the A simple homenet model may just consider three types of realm and the
borders between them, namely the internal homenet, the ISP and a borders between them, namely the internal homenet, the ISP and a
guest network. In this case the borders will include that from the guest network. In this case the borders will include that from the
homenet to the ISP, that from the guest network to the ISP, and that homenet to the ISP, that from the guest network to the ISP, and that
from the homenet to the guest network. Regardless, it should be from the homenet to the guest network. Regardless, it should be
possible for additional types of realms and borders to be defined, possible for additional types of realms and borders to be defined,
e.g. for some specific Grid or LLN-based network, and for these to be e.g., for some specific LLN-based network, such as Smart Grid, and
detected automatically, and for an appropriate default policy to be for these to be detected automatically, and for an appropriate
applied as to what type of traffic/data can flow across such borders. default policy to be applied as to what type of traffic/data can flow
across such borders.
It is desirable to classify the external border of the home network It is desirable to classify the external border of the home network
as a unique logical interface separating the home network from as a unique logical interface separating the home network from
service provider network/s. This border interface may be a single service provider network/s. This border interface may be a single
physical interface to a single service provider, multiple layer 2 physical interface to a single service provider, multiple layer 2
sub-interfaces to a single service provider, or multiple connections sub-interfaces to a single service provider, or multiple connections
to a single or multiple providers. This border makes it possible to to a single or multiple providers. This border makes it possible to
describe edge operations and interface requirements across multiple describe edge operations and interface requirements across multiple
functional areas including security, routing, service discovery, and functional areas including security, routing, service discovery, and
router discovery. router discovery.
It should be possible for the homenet user to override any It should be possible for the homenet user to override any
automatically determined borders and the default policies applied automatically determined borders and the default policies applied
between them. between them, the exception being that it may not be possible to
override policies defined by the ISP at the external border.
3.3.5. Configuration information from the ISP
In certain cases, it may be useful for the homenet to get certain
configuration information from its ISP. For example, the homenet
DHCP server may request and forward some options that it gets from
its upstream DHCP server, though the specific of the options may vary
across deployments. There is potential complexity here of course
should the homenet be multihomed.
3.4. Homenet Addressing 3.4. Homenet Addressing
The IPv6 addressing scheme used within a homenet must conform to the The IPv6 addressing scheme used within a homenet must conform to the
IPv6 addressing architecture [RFC4291]. In this section we discuss IPv6 addressing architecture [RFC4291]. In this section we discuss
how the homenet needs to adapt to the prefixes made available to it how the homenet needs to adapt to the prefixes made available to it
by its upstream ISP, such that internal subnets, hosts and devices by its upstream ISP, such that internal subnets, hosts and devices
can obtain the and configure the necessary addressing information to can obtain the and configure the necessary addressing information to
operate. operate.
3.4.1. Use of ISP-delegated IPv6 prefixes 3.4.1. Use of ISP-delegated IPv6 prefixes
Discussion of IPv6 prefix allocation policies is included in Discussion of IPv6 prefix allocation policies is included in
[RFC6177]. In practice, a homenet may receive an arbitrary length [RFC6177]. In practice, a homenet may receive an arbitrary length
IPv6 prefix from its provider, e.g. /60, /56 or /48. The offered IPv6 prefix from its provider, e.g., /60, /56 or /48. The offered
prefix may be stable or change from time to time; it is generally prefix may be stable or change from time to time; it is generally
expected that ISPs will offer relatively stable prefixes to their expected that ISPs will offer relatively stable prefixes to their
residential customers. Regardless, the home network needs to be residential customers. Regardless, the home network needs to be
adaptable as far as possible to ISP prefix allocation policies, and adaptable as far as possible to ISP prefix allocation policies, and
thus make no assumptions about the stability of the prefix received thus make no assumptions about the stability of the prefix received
from an ISP, or the length of the prefix that may be offered. from an ISP, or the length of the prefix that may be offered.
However, if, for example, only a /64 is offered by the ISP, the However, if, for example, only a /64 is offered by the ISP, the
homenet may be severely constrained or even unable to function. homenet may be severely constrained or even unable to function.
[RFC6177] (BCP 157) states that "a key principle for address [RFC6177] (BCP 157) states that "a key principle for address
skipping to change at page 23, line 20 skipping to change at page 24, line 27
One particular situation that must be avoided is having an end site One particular situation that must be avoided is having an end site
feel compelled to use IPv6-to-IPv6 Network Address Translation or feel compelled to use IPv6-to-IPv6 Network Address Translation or
other burdensome address conservation techniques because it could not other burdensome address conservation techniques because it could not
get sufficient address space." This architecture document assumes get sufficient address space." This architecture document assumes
that the guidance in the quoted text is being followed by ISPs. that the guidance in the quoted text is being followed by ISPs.
There are many problems that would arise from a homenet not being There are many problems that would arise from a homenet not being
offered a sufficient prefix size for its needs. Rather than attempt offered a sufficient prefix size for its needs. Rather than attempt
to contrive a method for a homenet to operate in a constrained manner to contrive a method for a homenet to operate in a constrained manner
when faced with insufficient prefixes, such as the use of subnet when faced with insufficient prefixes, such as the use of subnet
prefixes longer than /64 (which would break SLAAC), use of NPTv6, or prefixes longer than /64 (which would break stateless address
falling back to bridging across potentially very different media, it autonfiguration [RFC4862]), use of NPTv6, or falling back to bridging
is recommended that the receiving router instead enters an error across potentially very different media, it is recommended that the
state and issues appropriate warnings. Some consideration may need receiving router instead enters an error state and issues appropriate
to be given to how such a warning or error state should best be warnings. Some consideration may need to be given to how such a
presented to a typical home user. warning or error state should best be presented to a typical home
user.
Thus a homenet CER should request, for example via DHCP-PD, that it Thus a homenet CER should request, for example via DHCP Prefix
would like a /48 prefix from its ISP, i.e. it asks the ISP for the Delegation (DHCP PD) [RFC3633], that it would like a /48 prefix from
maximum size prefix it might expect to be offered, even if in its ISP, i.e., it asks the ISP for the maximum size prefix it might
practice it may only be offered a /56 or /60. For a typical IPv6 expect to be offered, even if in practice it may only be offered a
homenet, it is not recommended that an ISP offer less than a /60 /56 or /60. For a typical IPv6 homenet, it is not recommended that
prefix, and it is highly preferable that the ISP offers at least a an ISP offer less than a /60 prefix, and it is highly preferable that
/56. It is expected that the allocated prefix to the homenet from the ISP offers at least a /56. It is expected that the allocated
any single ISP is a contiguous, aggregated one. While it may be prefix to the homenet from any single ISP is a contiguous, aggregated
possible for a homenet CER to issue multiple prefix requests to one. While it may be possible for a homenet CER to issue multiple
attempt to obtain multiple delegations, such behaviour is out of prefix requests to attempt to obtain multiple delegations, such
scope of this document. behaviour is out of scope of this document.
The norm for residential customers of large ISPs may be similar to The norm for residential customers of large ISPs may be similar to
their single IPv4 address provision; by default it is likely to their single IPv4 address provision; by default it is likely to
remain persistent for some time, but changes in the ISP's own remain persistent for some time, but changes in the ISP's own
provisioning systems may lead to the customer's IP (and in the IPv6 provisioning systems may lead to the customer's IP (and in the IPv6
case their prefix pool) changing. It is not expected that ISPs will case their prefix pool) changing. It is not expected that ISPs will
generally support Provider Independent (PI) addressing for generally support Provider Independent (PI) addressing for
residential homenets. residential homenets.
When an ISP does need to restructure, and in doing so renumber its When an ISP does need to restructure, and in doing so renumber its
skipping to change at page 24, line 48 skipping to change at page 26, line 8
The network should by default attempt to provide IP-layer The network should by default attempt to provide IP-layer
connectivity between all internal parts of the homenet as well as to connectivity between all internal parts of the homenet as well as to
and from the external Internet, subject to the filtering policies or and from the external Internet, subject to the filtering policies or
other policy constraints discussed later in the security section. other policy constraints discussed later in the security section.
ULAs should be used within the scope of a homenet to support stable ULAs should be used within the scope of a homenet to support stable
routing and connectivity between subnets and hosts regardless of routing and connectivity between subnets and hosts regardless of
whether a globally unique ISP-provided prefix is available. In the whether a globally unique ISP-provided prefix is available. In the
case of a prolonged external connectivity outage, ULAs allow internal case of a prolonged external connectivity outage, ULAs allow internal
operations across routed subnets to continue. ULA addresses also operations across routed subnets to continue. ULA addresses also
allow constrained LLN devices to create permanent relationships allow constrained devices to create permanent relationships between
between IPv6 addresses, e.g. from a wall controller to a lamp, where IPv6 addresses, e.g., from a wall controller to a lamp, where
symbolic host names would require additional non-volatile memory and symbolic host names would require additional non-volatile memory and
updating global prefixes in sleeping LLN devices might also be updating global prefixes in sleeping devices might also be
problematic. problematic.
As discussed previously, it would be expected that ULAs would As discussed previously, it would be expected that ULAs would
normally be used alongside one or more global prefixes in a homenet, normally be used alongside one or more global prefixes in a homenet,
such that hosts become multi-addressed with both globally unique and such that hosts become multi-addressed with both globally unique and
ULA prefixes. ULAs should be used for all devices, not just those ULA prefixes. ULAs should be used for all devices, not just those
intended to only have internal connectivity. Default address intended to only have internal connectivity. Default address
selection would then enable ULAs to be preferred for internal selection would then enable ULAs to be preferred for internal
communications between devices that are using ULA prefixes generated communications between devices that are using ULA prefixes generated
within the same homenet. within the same homenet.
In cases where ULA prefixes are in use within a homenet but there is In cases where ULA prefixes are in use within a homenet but there is
no external IPv6 connectivity (and thus no GUAs in use), no external IPv6 connectivity (and thus no GUAs in use),
recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed to recommendations ULA-5, L-3 and L-4 in RFC 6204 should be followed to
ensure correct operation, in particular where the homenet may be ensure correct operation, in particular where the homenet may be
dual-stack with IPv4 external connectivity. The use of the Route dual-stack with IPv4 external connectivity. The use of the Route
Information Option described in [RFC4191] provides a mechanism to Information Option described in [RFC4191] provides a mechanism to
advertise such more-specific ULA routes. advertise such more-specific ULA routes.
The use of ULAs should be restricted to the homenet scope through The use of ULAs should be restricted to the homenet scope through
filtering at the border(s) of the homenet, as mandated by RFC 6024 filtering at the border(s) of the homenet, as mandated by RFC 6204
requirement S-2. requirement S-2.
Note that it is possible that in some cases multiple /48 ULA prefixes Note that it is possible that in some cases multiple /48 ULA prefixes
may be in use within the same homenet, e.g. when the network is being may be in use within the same homenet, e.g., when the network is
deployed, perhaps also without external connectivity. In cases where being deployed, perhaps also without external connectivity. In cases
multiple ULA /48's are in use, hosts need to know that each /48 is where multiple ULA /48's are in use, hosts need to know that each /48
local to the homenet, e.g. by inclusion in their local address is local to the homenet, e.g., by inclusion in their local address
selection policy table. selection policy table.
3.4.3. Internal prefix delegation 3.4.3. Internal prefix delegation
As mentioned above, there are various sources of prefixes. From the As mentioned above, there are various sources of prefixes. From the
homenet perspective, a single global prefix from each ISP should be homenet perspective, a single global prefix from each ISP should be
received on the border CER [RFC3633]. Where multiple CERs exist with received on the border CER [RFC3633]. Where multiple CERs exist with
multiple ISP prefix pools, it is expected that routers within the multiple ISP prefix pools, it is expected that routers within the
homenet would assign themselves prefixes from each ISP they homenet would assign themselves prefixes from each ISP they
communicate with/through. As discussed above, a ULA prefix should be communicate with/through. As discussed above, a ULA prefix should be
skipping to change at page 26, line 13 skipping to change at page 27, line 21
efficiency, so that typical home network prefix allocation sizes can efficiency, so that typical home network prefix allocation sizes can
accommodate all the necessary /64 allocations in most cases, and not accommodate all the necessary /64 allocations in most cases, and not
waste prefixes. Further, duplicate assignment of multiple /64s to waste prefixes. Further, duplicate assignment of multiple /64s to
the same network should be avoided, and the network should behave as the same network should be avoided, and the network should behave as
gracefully as possible in the event of prefix exhaustion (though the gracefully as possible in the event of prefix exhaustion (though the
options in such cases may be limited). options in such cases may be limited).
Where the home network has multiple CERs and these are delegated Where the home network has multiple CERs and these are delegated
prefix pools from their attached ISPs, the internal prefix delegation prefix pools from their attached ISPs, the internal prefix delegation
would be expected to be served by each CER for each prefix associated would be expected to be served by each CER for each prefix associated
with it. However, where ULAs are used, most likely in parallel with with it. Where ULAs are used, it is preferable that only one /48 ULA
global prefixes, one router should be elected as 'master' for covers the whole homenet, from which /64's can be delegated to the
delegation of ULA prefixes for the homenet, such that only one /48 subnets. In cases where two /48 ULAs are generated within a homenet,
ULA covers the whole homenet where possible. That router should the network should still continue to function, meaning that hosts
generate a /48 ULA for the site, and then delegate /64's from that will need to determine that each ULA is local to the homenet.
ULA prefix to subnets. In cases where two /48 ULAs are generated
within a homenet, the network should still continue to function,
meaning that hosts will need to determine that each ULA is local to
the homenet.
Delegation within the homenet should result in each link being Delegation within the homenet should result in each link being
assigned a stable prefix that is persistent across reboots, power assigned a stable prefix that is persistent across reboots, power
outages and similar short-term outages. The availability of outages and similar short-term outages. The availability of
persistent prefixes should not depend on the router boot order. The persistent prefixes should not depend on the router boot order. The
addition of a new routing device should not affect existing addition of a new routing device should not affect existing
persistent prefixes, but persistence may not be expected in the face persistent prefixes, but persistence may not be expected in the face
of significant 'replumbing' of the homenet. However, delegated ULA of significant 'replumbing' of the homenet. However, delegated ULA
prefixes within the homenet should remain persistent through an ISP- prefixes within the homenet should remain persistent through an ISP-
driven renumbering event. driven renumbering event.
Provisioning such persistent prefixes may imply the need for stable Provisioning such persistent prefixes may imply the need for stable
storage on routing devices, and also a method for a home user to storage on routing devices, and also a method for a home user to
'reset' the stored prefix should a significant reconfiguration be 'reset' the stored prefix should a significant reconfiguration be
required (though ideally the home user should not be involved at required (though ideally the home user should not be involved at
all). all).
There are multiple potential solutions for prefix delegation within a This document makes no specific recommendation towards solutions, but
homenet. One solution could be based on DHCPv6 PD, as described in notes that it is very likely that all routing devices participating
[RFC3315] and [RFC3633]. An alternative solution could be to convey in a homenet must use the same internal prefix delegation method.
prefixes within the chosen homenet routing protocol. This document This implies that only one delegation method should be in use.
makes no specific recommendation, but notes that it is very likely
that all routing devices participating in a homenet must use the same
internal prefix delegation method. This implies that only one
delegation method should be in use.
3.4.4. Coordination of configuration information 3.4.4. Coordination of configuration information
The network elements will need to be integrated in a way that takes The network elements will need to be integrated in a way that takes
account of the various lifetimes on timers that are used on different account of the various lifetimes on timers that are used on different
elements, e.g. DHCPv6 PD, router, valid prefix and preferred prefix elements, e.g., DHCPv6 PD, router, valid prefix and preferred prefix
timers. timers.
3.4.5. Privacy 3.4.5. Privacy
There are no specific privacy concerns discussed in this text. If If ISPs offer relatively stable IPv6 prefixes to customers, the
ISPs offer relatively stable IPv6 prefixes to customers, the network network prefix part of addresses associated with the homenet may not
prefix part of addresses associated with the homenet may not change change over a reasonably long period of time.
over a reasonably long period of time. This exposure is similar to
IPv4 networks using NAT, where the IPv4 address received from the ISP
may change over time, but not necessarily that frequently.
Hosts inside an IPv6 homenet may get new IPv6 addresses over time The exposure of which traffic is sourced from the same homenet is
regardless, e.g. through Privacy Addresses [RFC4941]. This may thus similar to IPv4; the single IPv4 global address seen through use
benefit mutual privacy of users within a home network, but not mask of IPv4 NAT gives the same hint as the global IPv6 prefix seen for
which home network traffic is sourced from. IPv6 traffic.
While IPv4 NAT may obfuscate to an external observer which internal
devices traffic is sourced from, IPv6, even with use of Privacy
Addresses [RFC4941], adds additional exposure of which traffic is
sourced from the same internal device, through use of the same IPv6
source address for a period of time.
3.5. Routing functionality 3.5. Routing functionality
Routing functionality is required when there are multiple routers Routing functionality is required when there are multiple routers
deployed within the internal home network. This functionality could deployed within the internal home network. This functionality could
be as simple as the current 'default route is up' model of IPv4 NAT, be as simple as the current 'default route is up' model of IPv4 NAT,
or, more likely, it would involve running an appropriate routing or, more likely, it would involve running an appropriate routing
protocol. Regardless of the solution method, the functionality protocol. Regardless of the solution method, the functionality
discussed below should be met. discussed below should be met.
The homenet unicast routing protocol should be based on a previously The homenet unicast routing protocol should be based on a previously
deployed protocol that has been shown to be reliable, robust, to deployed protocol that has been shown to be reliable and robust, and
allow lightweight implementations, and of which open source that allows lightweight implementations. The availability of open
implementations are available. It is desirable, but not absolutely source implementations is an important consideration. It is
required, that the routing protocol be able to give a complete view desirable, but not absolutely required, that the routing protocol be
of the network, and that it be able to pass around more than just able to give a complete view of the network, and that it be able to
routing information. pass around more than just routing information.
Multiple interface PHYs must be accounted for in the homenet routed Multiple types of physical interfaces must be accounted for in the
topology. Technologies such as Ethernet, WiFi, MoCA, etc must be homenet routed topology. Technologies such as Ethernet, WiFi,
capable of coexisting in the same environment and should be treated Multimedia over Coax Alliance (MoCA), etc. must be capable of
as part of any routed deployment. The inclusion of the PHY layer coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the computation should be considered for optimising communication in the
homenet. homenet.
The routing protocol should support the generic use of multiple The routing protocol should support the generic use of multiple
customer Internet connections, and the concurrent use of multiple customer Internet connections, and the concurrent use of multiple
delegated prefixes. A routing protocol that can make routing delegated prefixes. A routing protocol that can make routing
decisions based on source and destination addresses is thus decisions based on source and destination addresses is thus
desirable, to avoid upstream ISP BCP38 ingress filtering problems. desirable, to avoid upstream ISP BCP38 ingress filtering problems.
Multihoming support should also include load-balancing to multiple Multihoming support should also include load-balancing to multiple
providers, and failover from a primary to a backup link when providers, and failover from a primary to a backup link when
available. The protocol however should not require upstream ISP available. The protocol however should not require upstream ISP
connectivity to be established to continue routing within the connectivity to be established to continue routing within the
homenet. homenet.
The routing environment should be self-configuring, as discussed The routing environment should be self-configuring, as discussed
previously. An example of how OSPFv3 can be self-configuring in a previously. An example of how OSPFv3 can be self-configuring in a
homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig]. homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig].
Minimising convergence time should be a goal in any routed Minimising convergence time should be a goal in any routed
environment, but as a guideline a maximum convergence time at most 30 environment, but as a guideline a maximum convergence time at most 30
seconds should be the target. seconds should be the target (this target is somewhat arbitrary, and
was chosen based on how long a typical home user might wait before
attempting another reset; ideally the routers might have some status
light indicating they are converging, similar to an ADSL router light
indicating it is establishing a connection to its ISP).
As per prefix delegation, it is assumed that a single routing As per prefix delegation, it is assumed that a single routing
solution is in use in the homenet architecture. If there is an solution is in use in the homenet architecture. If there is an
identified need to support multiple solutions, these must be identified need to support multiple solutions, these must be
interoperable. interoperable.
An appropriate mechanism is required to discover which router(s) in An appropriate mechanism is required to discover which router(s) in
the homenet are providing the CER function. Borders may include but the homenet are providing the CER function. Borders may include but
are not limited to the interface to the upstream ISP, a gateway are not limited to the interface to the upstream ISP, a gateway
device to a separate home network such as a LLN network, or a gateway device to a separate home network such as a LLN network, or a gateway
to a guest or private corporate extension network. In some cases to a guest or private corporate extension network. In some cases
there may be no border present, which may for example occur before an there may be no border present, which may for example occur before an
upstream connection has been established. The border discovery upstream connection has been established. The border discovery
functionality may be integrated into the routing protocol itself, but functionality may be integrated into the routing protocol itself, but
may also be imported via a separate discovery mechanism. may also be imported via a separate discovery mechanism.
In general, LLN or other networks should be able to attach and In general, LLN or other networks should be able to attach and
participate the same way as the main homenet, or alternatively map/be participate in the same way as the main homenet, or alternatively
gatewayed to the main homenet. Current home deployments use largely map/be gatewayed to the main homenet. Current home deployments use
different mechanisms in sensor and basic Internet connectivity largely different mechanisms in sensor and basic Internet
networks. IPv6 VM solutions may also add additional routing connectivity networks. IPv6 virtual machine (VM) solutions may also
requirements. add additional routing requirements.
3.5.1. Multicast support 3.5.1. Multicast support
It is desirable that, subject to the capacities of devices on certain It is desirable that, subject to the capacities of devices on certain
media types, multicast routing is supported across the homenet. The media types, multicast routing is supported across the homenet. The
natural scopes for internal multicast would be link-local or site- natural scopes for internal multicast would be link-local or site-
local, with the latter constrained within the homenet, but other local, with the latter constrained within the homenet, but other
policy borders, e.g. to a guest subnet, or to certain media types, policy borders, e.g., to a guest subnet, or to certain media types,
may also affect where specific multicast traffic is routed. may also affect where specific multicast traffic is routed.
The homenet will need to be able to automatically configure the site
multicast scope and scope boundary as part of the homenet edge
(border) discovery process.
There may be different drivers for multicast to be supported across There may be different drivers for multicast to be supported across
the homenet, e.g. for homenet-wide service discovery should a site- the homenet, e.g., for homenet-wide service discovery should a site-
scope multicast service discovery protocol be defined, or potentially scope multicast service discovery protocol be defined, or potentially
for novel streaming or filesharing applications. Where multicast is for novel streaming or filesharing applications. Where multicast is
routed across a homenet an appropriate multicast routing protocol is routed across a homenet an appropriate multicast routing protocol is
required, one that as per the unicast routing protocol should be required, one that as per the unicast routing protocol should be
self-configuring. It must be possible to scope or filter multicast self-configuring. It must be possible to scope or filter multicast
traffic to avoid it being flooded to network media where devices traffic to avoid it being flooded to network media where devices
cannot reasonably support it. cannot reasonably support it.
Multicast may also be received by or sourced from the homenet from/to Multicast may also be received by or sourced from the homenet from/to
external networks, e.g. where video applications use multicast to external networks, e.g., where video applications use multicast to
conserve the bandwidth they consume. Such multicast traffic would be conserve the bandwidth they consume. Such multicast traffic would be
greater than site scope. greater than site scope.
The multicast environment should support the ability for applications The multicast environment should support the ability for applications
to pick a unique multicast group to use. to pick a unique multicast group to use.
3.5.2. Mobility support 3.5.2. Mobility support
Devices may be mobile within the homenet. While resident on the same Devices may be mobile within the homenet. While resident on the same
subnet, their address will remain persistent, but should devices move subnet, their address will remain persistent, but should devices move
skipping to change at page 29, line 37 skipping to change at page 30, line 48
subnets are used. subnets are used.
3.6. Security 3.6. Security
The security of an IPv6 homenet is an important consideration. The The security of an IPv6 homenet is an important consideration. The
most notable difference to the IPv4 operational model is the removal most notable difference to the IPv4 operational model is the removal
of NAT, the introduction of global addressability of devices, and of NAT, the introduction of global addressability of devices, and
thus a need to consider whether devices should have global thus a need to consider whether devices should have global
reachability. Regardless, hosts need to be able to operate securely, reachability. Regardless, hosts need to be able to operate securely,
end-to-end where required, and also be robust against malicious end-to-end where required, and also be robust against malicious
traffic direct towards them. However, there are other challenges traffic directed towards them. However, there are other challenges
introduced, e.g. default filtering policies at the borders between introduced, e.g., default filtering policies at the borders between
various homenet realms. various homenet realms.
3.6.1. Addressability vs reachability 3.6.1. Addressability vs reachability
An IPv6-based home network architecture should embrace the An IPv6-based home network architecture should embrace the
transparent end-to-end communications model as described in transparent end-to-end communications model as described in
[RFC2775]. Each device should be globally addressable, and those [RFC2775]. Each device should be globally addressable, and those
addresses must not be altered in transit. However, security addresses must not be altered in transit. However, security
perimeters can be applied to restrict end-to-end communications, and perimeters can be applied to restrict end-to-end communications, and
thus while a host may be globally addressable it may not be globally thus while a host may be globally addressable it may not be globally
reachable. reachable.
[RFC4864] describes a 'Simple Security' model for IPv6 networks, [RFC4864] describes a 'Simple Security' model for IPv6 networks,
whereby stateful perimeter filtering can be applied to control the whereby stateful perimeter filtering can be applied to control the
reachability of devices in a homenet. RFC 4864 states in Section 4.2 reachability of devices in a homenet. RFC 4864 states in Section 4.2
that "the use of firewalls ... is recommended for those that want that "the use of firewalls ... is recommended for those that want
boundary protection in addition to host defences". It should be boundary protection in addition to host defences". It should be
noted that a 'default deny' filtering approach would effectively noted that a 'default deny' filtering approach would effectively
replace the need for IPv4 NAT traversal protocols with a need to use 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 a signalling protocol to request a firewall hole be opened, e.g., a
protocol such as UPnP or PCP [RFC6887]. In networks with multiple protocol such as PCP [RFC6887]. In networks with multiple CERs, the
CERs, the signalling would need to handle the cases of flows that may signalling would need to handle the cases of flows that may use one
use one or more exit routers. CERs would need to be able to or more exit routers. CERs would need to be able to advertise their
advertise their existence for such protocols. existence for such protocols.
[RFC6092] expands on RFC 4864, giving a more detailed discussion of [RFC6092] expands on RFC 4864, giving a more detailed discussion of
IPv6 perimeter security recommendations, without mandating a 'default IPv6 perimeter security recommendations, without mandating a 'default
deny' approach. Indeed, RFC 6092 does not enforce a particular mode deny' approach. Indeed, RFC 6092 does not enforce a particular mode
of operation, instead stating that CERs must provide an easily of operation, instead stating that CERs must provide an easily
selected configuration option that permits a 'transparent' mode, thus selected configuration option that permits a 'transparent' mode, thus
ensuring a 'default allow' model is available. The homenet ensuring a 'default allow' model is available. The homenet
architecture text makes no recommendation on the default setting, and architecture text makes no recommendation on the default setting, and
refers the reader to RFC 6092. refers the reader to RFC 6092.
3.6.2. Filtering at borders 3.6.2. Filtering at borders
It is desirable that there are mechanisms to detect different types It is desirable that there are mechanisms to detect different types
of borders within the homenet, as discussed previously, and further of borders within the homenet, as discussed previously, and further
mechanisms to then apply different types of filtering policies at mechanisms to then apply different types of filtering policies at
those borders, e.g. whether naming and service discovery should pass those borders, e.g., whether naming and service discovery should pass
a given border. Any such policies should be able to be easily a given border. Any such policies should be able to be easily
applied by typical home users, e.g. to give a user in a guest network applied by typical home users, e.g., to give a user in a guest
access to media services in the home, or access to a printer. Simple network access to media services in the home, or access to a printer.
mechanisms to apply policy changes, or associations between devices, Simple mechanisms to apply policy changes, or associations between
will be required. devices, will be required.
There are cases where full internal connectivity may not be There are cases where full internal connectivity may not be
desirable, e.g. in certain utility networking scenarios, or where desirable, e.g., in certain utility networking scenarios, or where
filtering is required for policy reasons against guest network filtering is required for policy reasons against guest network
subnet(s). Some scenarios/models may as a result involve running subnet(s). Some scenarios/models may as a result involve running
isolated subnet(s) with their own CERs. In such cases connectivity isolated subnet(s) with their own CERs. In such cases connectivity
would only be expected within each isolated network (though traffic would only be expected within each isolated network (though traffic
may potentially pass between them via external providers). may potentially pass between them via external providers).
LLNs provide an another example of where there may be secure LLNs provide an another example of where there may be secure
perimeters inside the homenet. Constrained LLN nodes may implement perimeters inside the homenet. Constrained LLN nodes may implement
network key security but may depend on access policies enforced by network key security but may depend on access policies enforced by
the LLN border router. the LLN border router.
skipping to change at page 31, line 26 skipping to change at page 32, line 34
However, given current evidence of home network products with very However, given current evidence of home network products with very
poor default device security, putting a firewall in place does poor default device security, putting a firewall in place does
provide some level of protection. The use of firewalls today, provide some level of protection. The use of firewalls today,
whether a good practice or not, is common practice and whatever whether a good practice or not, is common practice and whatever
protection afforded, even if marginally effective, should not be protection afforded, even if marginally effective, should not be
lost. Thus, while it is highly desirable that all hosts in a homenet lost. Thus, while it is highly desirable that all hosts in a homenet
be adequately protected by built-in security functions, it should be adequately protected by built-in security functions, it should
also be assumed that all CERs will continue to support appropriate also be assumed that all CERs will continue to support appropriate
perimeter defence functions, as per [I-D.ietf-v6ops-6204bis]. perimeter defence functions, as per [I-D.ietf-v6ops-6204bis].
3.6.4. Device capabilities 3.6.4. Exfiltration concerns
As homenets become more complex, with more devices, and with service
discovery potentially enabled across the whole home, there are
potential concerns over the leakage of information should devices use
discovery protocols to gather information and report it to equipment
vendors or application service providers.
While it is not clear how such exfiltration could be easily avoided,
the threat should be recognised, be it from a new piece of hardware
or some 'app' installed on personal device.
3.6.5. Device capabilities
In terms of the devices, homenet hosts should implement their own In terms of the devices, homenet hosts should implement their own
security policies in accordance to their computing capabilities. security policies in accordance to their computing capabilities.
They should have the means to request transparent communications to They should have the means to request transparent communications to
be able to be initiated to them through security filters in the be able to be initiated to them through security filters in the
homenet, either for all ports or for specific services. Users should homenet, either for all ports or for specific services. Users should
have simple methods to associate devices to services that they wish have simple methods to associate devices to services that they wish
to operate transparently through (CER) borders. to operate transparently through (CER) borders.
3.6.5. ULAs as a hint of connection origin 3.6.6. ULAs as a hint of connection origin
As noted in Section 3.6, if appropriate filtering is in place on the As noted in Section 3.6, if appropriate filtering is in place on the
CER(s), as mandated by RFC 6024 requirement S-2, a ULA source address CER(s), as mandated by RFC 6204 requirement S-2, a ULA source address
may be taken as an indication of locally sourced traffic. This may be taken as an indication of locally sourced traffic. This
indication could then be used with security settings to designate indication could then be used with security settings to designate
between which nodes a particular application is allowed to between which nodes a particular application is allowed to
communicate, provided ULA address space is filtered appropriately at communicate, provided ULA address space is filtered appropriately at
the boundary of the realm. the boundary of the realm.
3.7. Naming and Service Discovery 3.7. Naming and Service Discovery
The homenet requires devices to be able to determine and use unique The homenet requires devices to be able to determine and use unique
names by which they can be accessed on the network. Users and names by which they can be accessed on the network. Users and
devices will need to be able to discover devices and services devices will need to be able to discover devices and services
available on the network, e.g. media servers, printers, displays or available on the network, e.g., media servers, printers, displays or
specific home automation devices. Thus naming and service discovery specific home automation devices. Thus naming and service discovery
must be supported in the homenet, and, given the nature of typical must be supported in the homenet, and, given the nature of typical
home network users, the service(s) providing this function must as home network users, the service(s) providing this function must as
far as possible support unmanaged operation. far as possible support unmanaged operation.
The naming system will be required to work internally or externally, The naming system will be required to work internally or externally,
be the user within the homenet or outside it, i.e. the user should be be the user within the homenet or outside it, i.e., the user should
able to refer to devices by name, and potentially connect to them, be able to refer to devices by name, and potentially connect to them,
wherever they may be. The most natural way to think about such wherever they may be. The most natural way to think about such
naming and service discovery is to enable it to work across the naming and service discovery is to enable it to work across the
entire homenet residence (site), disregarding technical borders such entire homenet residence (site), disregarding technical borders such
as subnets but respecting policy borders such as those between guest as subnets but respecting policy borders such as those between guest
and other internal network realms. Remote access may be desired by and other internal network realms. Remote access may be desired by
the homenet residents while travelling, but also potentially by the homenet residents while travelling, but also potentially by
manufacturers or other 'benevolent' third parties. manufacturers or other 'benevolent' third parties.
3.7.1. Discovering services 3.7.1. Discovering services
Users will typically perform service discovery through GUI interfaces Users will typically perform service discovery through graphical user
that allow them to browse services on their network in an appropriate interfaces (GUIs) that allow them to browse services on their network
and intuitive way. Devices may also need to discover other devices, in an appropriate and intuitive way. Devices may also need to
without any user intervention or choice. Either way, such interfaces discover other devices, without any user intervention or choice.
are beyond the scope of this document, but the interface should have Either way, such interfaces are beyond the scope of this document,
an appropriate API for the discovery to be performed. but the interface should have an appropriate application programming
interface (API) for the discovery to be performed.
Such interfaces may also typically hide the local domain name element Such interfaces may also typically hide the local domain name element
from users, especially where only one name space is available. from users, especially where only one name space is available.
However, as we discuss below, in some cases the ability to discover However, as we discuss below, in some cases the ability to discover
available domains may be useful. available domains may be useful.
We note that current zero-configuration service discovery protocols We note that current zero-configuration service discovery protocols
are generally aimed at single subnets. There is thus a choice to are generally aimed at single subnets. There is thus a choice to
make for multi-subnet homenets as to whether such protocols should be make for multi-subnet homenets as to whether such protocols should be
proxied or extended to operate across a whole homenet. In this proxied or extended to operate across a whole homenet. In this
context, that may mean bridging a link-local method, taking care to context, that may mean bridging a link-local method, taking care to
avoid loops, or extending the scope of multicast traffic used for the avoid loops, or extending the scope of multicast traffic used for the
purpose. It may mean that some proxy or hybrid service is utilised, purpose. It may mean that some proxy or hybrid service is utilised,
perhaps co-resident on the CER. Or it may be that a new approach is perhaps co-resident on the CER. Or it may be that a new approach is
preferable, e.g. flooding information around the homenet as preferable, e.g., flooding information around the homenet as
attributes within the routing protocol (which could allow per-prefix attributes within the routing protocol (which could allow per-prefix
configuration). However, we should prefer approaches that are configuration). However, we should prefer approaches that are
backwardly compatible, and allow current implementations to continue backwardly compatible, and allow current implementations to continue
to be used. Note that this document does not mandate a particular to be used. Note that this document does not mandate a particular
solution, rather it expresses the principles that should be used for solution, rather it expresses the principles that should be used for
a homenet naming and service discovery environment. a homenet naming and service discovery environment.
One of the primary challenges facing service discovery today is lack One of the primary challenges facing service discovery today is lack
of interoperability due to the ever increasing number of service of interoperability due to the ever increasing number of service
discovery protocols available. While it is conceivable for consumer discovery protocols available. While it is conceivable for consumer
skipping to change at page 33, line 17 skipping to change at page 34, line 40
discovery protocol interoperability either through a standards based discovery protocol interoperability either through a standards based
translation scheme, hooks into current protocols to allow some for of translation scheme, hooks into current protocols to allow some for of
communication among discovery protocols, extensions to support a communication among discovery protocols, extensions to support a
central service repository in the homenet, or simply convergence central service repository in the homenet, or simply convergence
towards a unified protocol suite. towards a unified protocol suite.
3.7.2. Assigning names to devices 3.7.2. Assigning names to devices
Given the large number of devices that may be networked in the Given the large number of devices that may be networked in the
future, devices should have a means to generate their own unique future, devices should have a means to generate their own unique
names within a homenet, and to detect clashes should they arise, e.g. names within a homenet, and to detect clashes should they arise,
where a second device of the same type/vendor as an existing device e.g., where a second device of the same type/vendor as an existing
with the same default name is deployed, or where two running network device with the same default name is deployed, or where a new subnet
elements with such devices are suddenly joined. It is expected that is added to the homenet which already has a device of the same name.
a device should have a fixed name while within the scope of the It is expected that a device should have a fixed name while within
homenet. the scope of the homenet.
Users will also want simple ways to (re)name devices, again most Users will also want simple ways to (re)name devices, again most
likely through an appropriate and intuitive interface that is beyond likely through an appropriate and intuitive interface that is beyond
the scope of this document. Note the name a user assigns to a device the scope of this document. Note the name a user assigns to a device
may be a label that is stored on the device as an attribute of the may be a label that is stored on the device as an attribute of the
device, and may be distinct from the name used in a name service, device, and may be distinct from the name used in a name service,
e.g. 'Study Laser Printer' as opposed to printer2.<somedomain>. e.g., 'Study Laser Printer' as opposed to printer2.<somedomain>.
3.7.3. Name spaces 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 co-exist with the Internet name service. There should also be
a bias towards proven, existing solutions. The strong implication is
thus that the homenet service is DNS-based, or DNS-compatible. There
are naming protocols that are designed to be configured and operate
Internet-wide, like unicast-based DNS, but also protocols that are
designed for zero-configuration local environments, like 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 CER and 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,
including 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.
While this document does not specify hardware requirements, it is
worth noting briefly here that e.g., in support of DNSSEC,
appropriate homenet devices should have good random number generation
capability, and 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 CER must be considered. It would
be desirable to retain any relevant state (configuration) that was
held in the old CER. This might imply that state information should
be distributed in the homenet, to be recoverable by/to the new CER,
or to the homenet's ISP or a third party externally provided service
by some means.
3.7.4. Name spaces
If access to homenet devices is required remotely from anywhere on If access to homenet devices is required remotely from anywhere on
the Internet, then at least one globally unique name space is the Internet, then at least one globally unique name space is
required, though the use of multiple name spaces should not be required, though the use of multiple name spaces should not be
precluded. The name space(s) should be served authoritatively by the precluded. One approach is that the name space(s) used for the
homenet, most likely by a server resident on the CER. Such name homenet would be served authoritatively by the homenet, most likely
spaces may be acquired by the user or provided/generated by their ISP by a server resident on the CER. Such name spaces may be acquired by
or an alternative cloud-based service. It is likely that the default the user or provided/generated by their ISP or an alternative
case is that a homenet will use a global domain provided by the ISP, externally provided service. It is likely that the default case is
but advanced users wishing to use a name space that is independent of that a homenet will use a global domain provided by the ISP, but
advanced users wishing to use a name space that is independent of
their provider in the longer term should be able to acquire and use their provider in the longer term should be able to acquire and use
their own domain name. For users wanting to use their own their own domain name. For users wanting to use their own
independent domain names, such services are already available. independent domain names, such services are already available.
Devices may also be assigned different names in different name Devices may also be assigned different names in different name
spaces, e.g. by third parties who may manage systems or devices in spaces, e.g., by third parties who may manage systems or devices in
the homenet on behalf of the resident(s). Remote management of the the homenet on behalf of the resident(s). Remote management of the
homenet is out of scope of this document. homenet is out of scope of this document.
If however a global name space is not available, the homenet will If however a global name space is not available, the homenet will
need to pick and use a local name space which would only have meaning need to pick and use a local name space which would only have meaning
within the local homenet (i.e. it would not be used for remote access within the local homenet (i.e., it would not be used for remote
to the homenet). The .local name space currently has a special access to the homenet). The .local name space currently has a
meaning for certain existing protocols which have link-local scope, special meaning for certain existing protocols which have link-local
and is thus not appropriate for multi-subnet home networks. A scope, and is thus not appropriate for multi-subnet home networks. A
different name space is thus required for the homenet. different name space is thus required for the homenet.
One approach for picking a local name space is to use an Ambiguous One approach for picking a local name space is to use an Ambiguous
Local Qualified Domain Name space, such as .sitelocal (or an Local Qualified Domain Name (ALQDN) space, such as .sitelocal (or an
appropriate name reserved for the purpose). While this is a simple appropriate name reserved for the purpose). While this is a simple
approach, there is the potential in principle for devices that are approach, there is the potential in principle for devices that are
bookmarked somehow by name by an application in one homenet to be bookmarked somehow by name by an application in one homenet to be
confused with a device with the same name in another homenet. In confused with a device with the same name in another homenet. In
practice however the underlying service discovery protocols should be practice however the underlying service discovery protocols should be
capable of handling moving to a network where a new device is using capable of handling moving to a network where a new device is using
the same name as a device used previously in another homenet. the same name as a device used previously in another homenet.
An alternative approach for a local name space would be to use a An alternative approach for a local name space would be to use a
Unique Locally Qualified Domain Name space such as Unique Locally Qualified Domain Name (ULQDN) space such as
.<UniqueString>.sitelocal. The <UniqueString> could be generated in .<UniqueString>.sitelocal. The <UniqueString> could be generated in
a variety of ways, one potentially being based on the local /48 ULA a variety of ways, one potentially being based on the local /48 ULA
prefix being used across the homenet. Such a <UniqueString> should prefix being used across the homenet. Such a <UniqueString> should
survive a cold restart, i.e. be consistent after a network power- survive a cold restart, i.e., be consistent after a network power-
down, or, if a value is not set on startup, the CER or device running down, or, if a value is not set on startup, the CER or device running
the name service should generate a default value. It would be the name service should generate a default value. It would be
desirable for the homenet user to be able to override the desirable for the homenet user to be able to override the
<UniqueString> with a value of their choice, but that would increase <UniqueString> with a value of their choice, but that would increase
the likelihood of a name conflict. the likelihood of a name conflict. Any generated <UniqueString>
should not be predictable; thus adding a salt/hash function would be
desirable.
In the (likely) event that the homenet is accessible from outside the In the (likely) event that the homenet is accessible from outside the
homenet (using the global name space), it is vital that the homenet homenet (using the global name space), it is vital that the homenet
name space follow the rules and conventions of the global name space. name space follow the rules and conventions of the global name space.
In this mode of operation, names in the homenet (including those In this mode of operation, names in the homenet (including those
automatically generated by devices) must be usable as labels in the automatically generated by devices) must be usable as labels in the
global name space. [RFC5890] describes considerations for global name space. [RFC5890] describes considerations for
Internationalizing Domain Names in Applications (IDNA). Internationalizing Domain Names in Applications (IDNA).
Also, with the introduction of new 'dotless' top level domains, there Also, with the introduction of new 'dotless' top level domains, there
is also potential for ambiguity between, for example, a local host is also potential for ambiguity between, for example, a local host
called 'computer' and (if it is registered) a .computer gTLD. Thus called 'computer' and (if it is registered) a .computer gTLD. Thus
qualified names should always be used, whether these are exposed to qualified names should always be used, whether these are exposed to
the user or not. the user or not. The IAB has issued a statement which explains why
dotless domains should be considered harmful [IABdotless].
There may be use cases where either different name spaces may be There may be use cases where either different name spaces may be
desired for different realms in the homenet, or for segmentation of a desired for different realms in the homenet, or for segmentation of a
single name space within the homenet. Thus hierarchical name space single name space within the homenet. Thus hierarchical name space
management is likely to be required. There should also be nothing to management is likely to be required. There should also be nothing to
prevent individual device(s) being independently registered in prevent individual device(s) being independently registered in
external name spaces. external name spaces.
Where a user is in a remote network wishing to access devices in Where a user is in a remote network wishing to access devices in
their home network, there may be a requirement to consider the domain their home network, there may be a requirement to consider the domain
search order presented where multiple associated name spaces exist. search order presented where multiple associated name spaces exist.
This also implies that a domain discovery function is desirable. This also implies that a domain discovery function is desirable.
It may be the case that not all devices in the homenet are made It may be the case that not all devices in the homenet are made
available by name via an Internet name space, and that a 'split view' available by name via an Internet name space, and that a 'split view'
is preferred for certain devices. is preferred for certain devices, whereby devices inside the homenet
see different DNS responses to those outside.
This document makes no assumption about the presence or omission of a This document makes no assumption about the presence or omission of a
reverse lookup service. There is an argument that it may be useful reverse lookup service. There is an argument that it may be useful
for presenting logging information to users with meaningful device for presenting logging information to users with meaningful device
names rather than literal addresses. names rather than literal addresses. There are also some services,
most notably email mail exchangers, where some operators have chosen
3.7.4. The homenet name service to require a valid reverse lookup before accepting connections.
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 co-exist with the Internet name service. There should also be
a bias towards proven, existing solutions. The strong implication is
thus that the homenet service is DNS-based, or DNS-compatible. There
are naming protocols that are designed to be configured and operate
Internet-wide, like unicast-based DNS, but also protocols that are
designed for zero-configuration local environments, like mDNS
[RFC6762].
When DNS is used as the homenet name service, it 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 CER and a secondary resolving name service
provided by the ISP or perhaps a cloud-based third party.
Where zeroconf 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, it is desirable
to support appropriate name service security methods, including
DNSSEC.
Finally, the impact of a change in CER must be considered. It would
be desirable to retain any relevant state (configuration) that was
held in the old CER. This might imply that state information should
be distributed in the homenet, to be recoverable by/to the new CER,
or to the homenet's ISP or a third party cloud-based service by some
means.
3.7.5. Independent operation 3.7.5. Independent operation
Name resolution and service discovery for reachable devices must Name resolution and service discovery for reachable devices must
continue to function if the local network is disconnected from the continue to function if the local network is disconnected from the
global Internet, e.g. a local media server should still be available global Internet, e.g., a local media server should still be available
even if the Internet link is down for an extended period. This even if the Internet link is down for an extended period. This
implies the local network should also be able to perform a complete implies the local network should also be able to perform a complete
restart in the absence of external connectivity, and have local restart in the absence of external connectivity, and have local
naming and service discovery operate correctly. naming and service discovery operate correctly.
The approach described above of a local authoritative name service The approach described above of a local authoritative name service
with a cache would allow local operation for sustained ISP outages. with a cache would allow local operation for sustained ISP outages.
Having an independent local trust anchor is desirable, to support Having an independent local trust anchor is desirable, to support
secure exchanges should external connectivity be unavailable. secure exchanges should external connectivity be unavailable.
skipping to change at page 36, line 47 skipping to change at page 38, line 38
In some parts of the homenet, in particular LLNs or any devices where In some parts of the homenet, in particular LLNs or any devices where
battery power is used, devices may be sleeping, in which case a proxy battery power is used, devices may be sleeping, in which case a proxy
for such nodes may be required, that could respond (for example) to for such nodes may be required, that could respond (for example) to
multicast service discovery requests. Those same devices or parts of multicast service discovery requests. Those same devices or parts of
the network may have less capacity for multicast traffic that may be the network may have less capacity for multicast traffic that may be
flooded from other parts of the network. In general, message flooded from other parts of the network. In general, message
utilisation should be efficient considering the network technologies utilisation should be efficient considering the network technologies
and constrained devices that the service may need to operate over. and constrained devices that the service may need to operate over.
There are efforts underway to determine naming and discovery There are efforts underway to determine naming and discovery
solutions for use by the Constrained Application Protocol (CoAP) in solutions for use by the Constrained Application Protocol (CoAP)
LLN networks. These are outside the scope of this document. [I-D.ietf-core-coap] in LLN networks. These are outside the scope of
this document.
3.7.7. DNS resolver discovery 3.7.7. DNS resolver discovery
Automatic discovery of a name service to allow client devices in the Automatic discovery of a name service to allow client devices in the
homenet to resolve external domains on the Internet is required, and homenet to resolve external domains on the Internet is required, and
such discovery must support clients that may be a number of router such discovery must support clients that may be a number of router
hops away from the name service. Similarly the search domains for hops away from the name service. Similarly it may be desirable to
local FQDN-derived zones should be included. convey any DNS domain search list that may be in effect for the
homenet.
3.7.8. Devices roaming from the homenet 3.7.8. Devices roaming to/from the homenet
It is likely that some devices which have registered names within the It is likely that some devices which have registered names within the
homenet Internet name space and that are mobile will attach to the homenet Internet name space and that are mobile will attach to the
Internet at other locations and acquire an IP address at those Internet at other locations and acquire an IP address at those
locations. In such cases it is desirable that devices may be locations. Devices may move between different homenets. In such
accessed by the same name as is used in the home network. cases it is desirable that devices may be accessed by the same name
as is used in their home network.
Solutions to this problem are not discussed in this document. They Solutions to this problem are not discussed in this document. They
may include use of Mobile IPv6 or Dynamic DNS, either of which would may include use of Mobile IPv6 or Dynamic DNS, either of which would
put additional requirements on to the homenet, or establishment of a put additional requirements on to the homenet, or establishment of a
(VPN) tunnel to a server in the home network. (VPN) tunnel to a server in the home network.
3.8. Other Considerations 3.8. Other Considerations
This section discusses two other considerations for home networking This section discusses two other considerations for home networking
that the architecture should not preclude, but that this text is that the architecture should not preclude, but that this text is
neutral towards. neutral towards.
3.8.1. Quality of Service 3.8.1. Quality of Service
Support for QoS in a multi-service homenet may be a requirement, e.g. Support for Quality of Service in a multi-service homenet may be a
for a critical system (perhaps healthcare related), or for requirement, e.g., for a critical system (perhaps healthcare
differentiation between different types of traffic (file sharing, related), or for differentiation between different types of traffic
cloud storage, live streaming, VoIP, etc). Different media types may (file sharing, cloud storage, live streaming, VoIP, etc). Different
have different such properties or capabilities. media types may have different such properties or capabilities.
However, homenet scenarios should require no new QoS protocols. A However, homenet scenarios should require no new Quality of Service
DiffServ [RFC2475] approach with a small number of predefined traffic protocols. A DiffServ [RFC2475] approach with a small number of
classes may generally be sufficient, though at present there is predefined traffic classes may generally be sufficient, though at
little experience of QoS deployment in home networks. It is likely present there is little experience of Quality of Service deployment
that QoS, or traffic prioritisation, methods will be required at the in home networks. It is likely that QoS, or traffic prioritisation,
CER, and potentially around boundaries between different media types methods will be required at the CER, and potentially around
(where for example some traffic may simply not be appropriate for boundaries between different media types (where for example some
some media, and need to be dropped to avoid drowning the constrained traffic may simply not be appropriate for some media, and need to be
media). dropped to avoid overloading the constrained media).
There may also be complementary mechanisms that could be beneficial There may also be complementary mechanisms that could be beneficial
to application performance and behaviour in the homenet domain, such to application performance and behaviour in the homenet domain, such
as ensuring proper buffering algorithms are used as described in as ensuring proper buffering algorithms are used as described in
[Gettys11]. [Gettys11].
3.8.2. Operations and Management 3.8.2. Operations and Management
The homenet should be self-organising and configuring as far as The homenet should be self-organising and configuring as far as
possible, and thus not be pro-actively managed by the home user. possible, and thus should not need to be pro-actively managed by the
Thus protocols to manage the network are not discussed in this home user. Thus specific protocols to manage the network are not
architecture text. discussed in this document.
However, users may be interested in the status of their networks and There may be some configuration parameters which are exposed to
users, e.g., SSID name(s), or wireless security key(s). Users may
also be expected to be aware of the functions of certain devices they
connect, e.g., which are providing a server function, though service
discovery protocols should make their selection as intuitive as
possible.
As discussed in Section 3.6.1 the default setting on the homenet-ISP
border for inbound traffic may be default deny, default allow, or
some position inbetween. Whatever the default position, it should be
possible for the user to change the setting.
Users may also be interested in the status of their networks and
devices on the network, in which case simplified monitoring devices on the network, in which case simplified monitoring
mechanisms may be desirable. It may also be the case that an ISP, or mechanisms may be desirable. It may also be the case that an ISP, or
a third party, might offer management of the homenet on behalf of a a third party, might offer management of the homenet on behalf of a
user, in which case management protocols would be required. How such user, in which case management protocols would be required. How such
management is done is out of scope of this document; many solutions management is done is out of scope of this document; many solutions
exist. exist.
It is expected that network management functions would be available
over IPv6 transport, even where the homenet is dual-stack.
3.9. Implementing the Architecture on IPv6 3.9. Implementing the Architecture on IPv6
This architecture text encourages re-use of existing protocols. Thus This architecture text encourages re-use of existing protocols. Thus
the necessary mechanisms are largely already part of the IPv6 the necessary mechanisms are largely already part of the IPv6
protocol set and common implementations, though there are some protocol set and common implementations, though there are some
exceptions. exceptions.
For automatic routing, it is expected that solutions can be found For automatic routing, it is expected that solutions can be found
based on existing protocols. Some relatively smaller updates are based on existing protocols. Some relatively smaller updates are
likely to be required, e.g. a new mechanism may be needed in order to likely to be required, e.g., a new mechanism may be needed in order
turn a selected protocol on by default, a mechanism may be required to turn a selected protocol on by default, a mechanism may be
to automatically assign prefixes to links within the homenet. required to automatically assign prefixes to links within the
homenet.
Some functionality, if required by the architecture, may need more Some functionality, if required by the architecture, may need more
significant changes or require development of new protocols, e.g. significant changes or require development of new protocols, e.g.,
support for multihoming with multiple exit routers would likely support for multihoming with multiple exit routers would likely
require extensions to support source and destination address based require extensions to support source and destination address based
routing within the homenet. routing within the homenet.
Some protocol changes are however required in the architecture, e.g. Some protocol changes are however required in the architecture, e.g.,
for name resolution and service discovery, extensions to existing for name resolution and service discovery, extensions to existing
zeroconf link-local name resolution protocols are needed to enable zero configuration link-local name resolution protocols are needed to
them to work across subnets, within the scope of the home network enable them to work across subnets, within the scope of the home
site. network site.
Some of the hardest problems in developing solutions for home Some of the hardest problems in developing solutions for home
networking IPv6 architectures include discovering the right borders networking IPv6 architectures include discovering the right borders
where the 'home' domain ends and the service provider domain begins, where the 'home' domain ends and the service provider domain begins,
deciding whether some of the necessary discovery mechanism extensions deciding whether some of the necessary discovery mechanism extensions
should affect only the network infrastructure or also hosts, and the should affect only the network infrastructure or also hosts, and the
ability to turn on routing, prefix delegation and other functions in ability to turn on routing, prefix delegation and other functions in
a backwards compatible manner. a backwards compatible manner.
4. Conclusions 4. Conclusions
skipping to change at page 39, line 29 skipping to change at page 41, line 38
This document has no actions for IANA. This document has no actions for IANA.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
7.2. Informative References 7.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
skipping to change at page 40, line 22 skipping to change at page 42, line 22
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking
Workshop", RFC 3002, December 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Rose, "DNS Security Introduction and Requirements",
December 2003. RFC 4033, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007. May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
skipping to change at page 41, line 12 skipping to change at page 43, line 18
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011. Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
skipping to change at page 41, line 51 skipping to change at page 44, line 4
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013. April 2013.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address Wing, "IPv6 Multihoming without Network Address
Translation", Translation",
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 (work draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 (work
in progress), March 2013. in progress), March 2013.
[I-D.ietf-ospf-ospfv3-autoconfig] [I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress), draft-ietf-ospf-ospfv3-autoconfig-05 (work in progress),
April 2013. October 2013.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-v6ops-6204bis] [I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", Requirements for IPv6 Customer Edge Routers",
draft-ietf-v6ops-6204bis-12 (work in progress), draft-ietf-v6ops-6204bis-12 (work in progress),
October 2012. October 2012.
[IABdotless]
"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] [Gettys11]
Gettys, J., "Bufferbloat: Dark Buffers in the Internet", Gettys, J., "Bufferbloat: Dark Buffers in the Internet",
March 2011, March 2011,
<http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>. <http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf>.
[IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V
2.0", September 2010, <http://upnp.org/specs/gw/
UPnP-gw-WANIPConnection-v2-Service.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Aamer Akhter, Mikael Abrahamsson, The authors would like to thank Aamer Akhter, Mikael Abrahamsson,
Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis, Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis,
Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart
Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Ralph Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Elwyn
Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, Wassim Haddad, Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson,
Joel M. Halpern, David Harrington, Lee Howard, Ray Hunter, Joel Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray
Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Daniel Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry
Migault, Erik Nordmark, Michael Richardson, Mattia Rossi, Barbara Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia
Stark, Markus Stenberg, Sander Steffann, Don Sturek, Andrew Sullivan, Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek,
Dave Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur, Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark
Curtis Villamizar, Dan Wing, Russ White, and James Woodyatt for their Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and
comments and contributions within homenet WG meetings and on the WG James Woodyatt for their comments and contributions within homenet WG
mailing list. An acknowledgement generally means that person's text meetings and on the WG mailing list. An acknowledgement generally
made it in to the document, or was helpful in clarifying or means that person's text made it in to the document, or was helpful
reinforcing an aspect of the document. It does not imply that each in clarifying or reinforcing an aspect of the document. It does not
controbutor agrees with every point in the document. imply that each controbutor agrees with every point in the document.
Appendix B. Changes Appendix B. Changes
This section will be removed in the final version of the text. This section will be removed in the final version of the text.
B.1. Version 10 (after AD review) B.1. Version 11 (after IESG review)
Changes made include:
o Jouni Korhonen's OPSDIR review comments addressed.
o Elwyn Davies' gen-art review comments addressed.
B.2. Version 10 (after AD review)
Changes made include: Changes made include:
o Minor changes/clarifications resulting from AD review o Minor changes/clarifications resulting from AD review
B.2. Version 09 (after WGLC) B.3. Version 09 (after WGLC)
Changes made include: Changes made include:
o Added note about multicast into or out of site o Added note about multicast into or out of site
o Removed further personal draft references, replaced with covering o Removed further personal draft references, replaced with covering
text text
o Routing functionality text updated to avoid ambiguity o Routing functionality text updated to avoid ambiguity
skipping to change at page 44, line 5 skipping to change at page 46, line 21
o Stated that this text does not recommend how to form largest o Stated that this text does not recommend how to form largest
possible subnets possible subnets
o Added text about homenet evolution and handling disparate media o Added text about homenet evolution and handling disparate media
types types
o Rephrased NAT/firewall text on marginal effectiveness o Rephrased NAT/firewall text on marginal effectiveness
o Emphasised that multihoming may be to any number of ISPs o Emphasised that multihoming may be to any number of ISPs
B.3. Version 08 B.4. Version 08
Changes made include: Changes made include:
o Various clarifications made in response to list comments o Various clarifications made in response to list comments
o Added note on ULAs with IPv4, where no GUAs in use o Added note on ULAs with IPv4, where no GUAs in use
o Added note on naming and internationalisation (IDNA) o Added note on naming and internationalisation (IDNA)
o Added note on trust relationships when adding devices o Added note on trust relationships when adding devices
o Added note for MPTCP o Added note for MPTCP
o Added various naming and SD notes o Added various naming and SD notes
o Added various notes on delegated ISP prefixes o Added various notes on delegated ISP prefixes
B.4. Version 07 B.5. Version 07
Changes made include: Changes made include:
o Removed reference to NPTv6 in section 3.2.4. Instead now say it o Removed reference to NPTv6 in section 3.2.4. Instead now say it
has an architectural cost to use in the earlier section, and thus has an architectural cost to use in the earlier section, and thus
it is not recommended for use in the homenet architecture. it is not recommended for use in the homenet architecture.
o Removed 'proxy or extend?' section. Included shorter text in main o Removed 'proxy or extend?' section. Included shorter text in main
body, without mandating either approach for service discovery. body, without mandating either approach for service discovery.
skipping to change at page 45, line 12 skipping to change at page 47, line 28
o Reordered section 3.3 to improve flow. o Reordered section 3.3 to improve flow.
o Added recommendation that homenet is not allocated less than /60, o Added recommendation that homenet is not allocated less than /60,
and a /56 is preferable. and a /56 is preferable.
o Tidied up first few intro sections. o Tidied up first few intro sections.
o Other minor edits from list feedback. o Other minor edits from list feedback.
B.5. Version 06 B.6. Version 06
Changes made include: Changes made include:
o Stated that unmanaged goal is 'as far as possible'. o Stated that unmanaged goal is 'as far as possible'.
o Added note about multiple /48 ULAs potentially being in use. o Added note about multiple /48 ULAs potentially being in use.
o Minor edits from list feedback. o Minor edits from list feedback.
B.6. Version 05 B.7. Version 05
Changes made include: Changes made include:
o Some significant changes to naming and SD section. o Some significant changes to naming and SD section.
o Removed some expired drafts. o Removed some expired drafts.
o Added notes about issues caused by ISP only delegating a /64. o Added notes about issues caused by ISP only delegating a /64.
o Recommended against using prefixes longer than /64. o Recommended against using prefixes longer than /64.
o Suggested CER asks for /48 by DHCP-PD, even if it only receives o Suggested CER asks for /48 by DHCP PD, even if it only receives
less. less.
o Added note about DS-Lite but emphasised transition is out of o Added note about DS-Lite but emphasised transition is out of
scope. scope.
o Added text about multicast routing. o Added text about multicast routing.
B.7. Version 04 B.8. Version 04
Changes made include: Changes made include:
o Moved border section from IPv6 differences to principles section. o Moved border section from IPv6 differences to principles section.
o Restructured principles into areas. o Restructured principles into areas.
o Added summary of naming and service discovery discussion from WG o Added summary of naming and service discovery discussion from WG
list. list.
B.8. Version 03 B.9. Version 03
Changes made include: Changes made include:
o Various improvements to the readability. o Various improvements to the readability.
o Removed bullet lists of requirements, as requested by chair. o Removed bullet lists of requirements, as requested by chair.
o Noted 6204bis has replaced advanced-cpe draft. o Noted 6204bis has replaced advanced-cpe draft.
o Clarified the topology examples are just that. o Clarified the topology examples are just that.
skipping to change at page 47, line 20 skipping to change at page 49, line 36
the homenet. the homenet.
o Added some ISPs renumber due to privacy laws. o Added some ISPs renumber due to privacy laws.
o Removed extra repeated references to Simple Security. o Removed extra repeated references to Simple Security.
o Removed some solution creep on RIOs/RAs. o Removed some solution creep on RIOs/RAs.
o Load-balancing scenario added as to be supported. o Load-balancing scenario added as to be supported.
B.9. Version 02 B.10. Version 02
Changes made include: Changes made include:
o Made the IPv6 implications section briefer. o Made the IPv6 implications section briefer.
o Changed Network Models section to describe properties of the o Changed Network Models section to describe properties of the
homenet with illustrative examples, rather than implying the homenet with illustrative examples, rather than implying the
number of models was fixed to the six shown in 01. number of models was fixed to the six shown in 01.
o Text to state multihoming support focused on single CER model. o Text to state multihoming support focused on single CER model.
 End of changes. 136 change blocks. 
464 lines changed or deleted 542 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/