draft-ietf-homenet-arch-08.txt   draft-ietf-homenet-arch-09.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: November 22, 2013 Ericsson Expires: January 16, 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
May 21, 2013 July 15, 2013
Home Networking Architecture for IPv6 Home Networking Architecture for IPv6
draft-ietf-homenet-arch-08 draft-ietf-homenet-arch-09
Abstract Abstract
This text describes evolving networking technology within This text describes evolving networking technology within
increasingly large residential home networks. The goal of this increasingly large residential home networks. The goal of this
document is to define a general architecture for IPv6-based home document is to define a general architecture for IPv6-based home
networking, describing the associated principles, considerations and networking, describing the associated principles, considerations and
requirements. The text briefly highlights specific implications of requirements. The text briefly highlights specific implications of
the introduction of IPv6 for home networking, discusses the elements the introduction of IPv6 for home networking, discusses the elements
of the architecture, and suggests how standard IPv6 mechanisms and of the architecture, and suggests how standard IPv6 mechanisms and
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 November 22, 2013. This Internet-Draft will expire on January 16, 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 30 skipping to change at page 2, line 30
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 . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 13
3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 12 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. Homenet realms and borders . . . . . . . . . . . . . . 20 3.3.3. Handling varying link technologies . . . . . . . . . . 21
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 21 3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . 26 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. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30
3.6.1. Addressability vs reachability . . . . . . . . . . . . 29 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 29 3.6.1. Addressability vs reachability . . . . . . . . . . . . 30
3.6.3. Marginal Effectiveness of NAT and Firewalls . . . . . 30 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 31
3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 30 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 31
3.6.5. ULAs as a hint of connection origin . . . . . . . . . 30 3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 32
3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 31 3.6.5. ULAs as a hint of connection origin . . . . . . . . . 32
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 31 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 32
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 32 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33
3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 32 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34
3.7.4. The homenet name service . . . . . . . . . . . . . . . 34 3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 34
3.7.5. Independent operation . . . . . . . . . . . . . . . . 35 3.7.4. The homenet name service . . . . . . . . . . . . . . . 36
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 35 3.7.5. Independent operation . . . . . . . . . . . . . . . . 37
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 36 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 37
3.7.8. Devices roaming from the homenet . . . . . . . . . . . 36 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 37
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 36 3.7.8. Devices roaming from the homenet . . . . . . . . . . . 38
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 36 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 38
3.8.2. Operations and Management . . . . . . . . . . . . . . 37 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 38
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 37 3.8.2. Operations and Management . . . . . . . . . . . . . . 38
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 39
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1. Normative References . . . . . . . . . . . . . . . . . . . 38 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2. Informative References . . . . . . . . . . . . . . . . . . 39 5.1. Normative References . . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 5.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43
B.1. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 43
B.2. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 43 B.1. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 43
B.3. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 43 B.2. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.3. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 44
B.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.4. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 45
B.6. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.5. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 45
B.7. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.6. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 B.7. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.8. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
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 increasingly large residential home networks 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
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 we would like to avoid, such as
private [RFC1918] addressing with (cascaded) network address private [RFC1918] addressing with (cascaded) network address
translation (NAT)[RFC3022], or they may require expert assistance to translation (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
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.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
to the home network is not. As a result the growth inhibitor for the to the home network is not. As a result the growth inhibitor for the
home network shifts from the number of addresses to the number of home network shifts from the number of addresses to the number of
prefixes offered by the provider; this topic is discussed in prefixes offered by the provider; this topic is discussed in
[RFC6177] (BCP 157), which recommends that "end sites always be able [RFC6177] (BCP 157), which recommends that "end sites always be able
to obtain a reasonable amount of address space for their actual and to obtain a reasonable amount of address space for their actual and
planned usage". planned usage".
The addition of routing between subnets raises a number of issues. The addition of routing between subnets raises a number of issues.
One is a method by which prefixes can be efficiently allocated to One is a method by which prefixes can be efficiently allocated to
each subnet, without user intervention. Another is the issue of how each subnet, without user intervention. Another is the issue of how
to extend mechanisms such as service discovery which currently only to extend mechanisms such as zero configuration service discovery
operate within a single subnet using link-local traffic. In a which currently only operate within a single subnet using link-local
typical IPv4 home network, there is only one subnet, so such traffic. In a typical IPv4 home network, there is only one subnet,
mechanisms would normally operate as expected. For multi-subnet IPv6 so such mechanisms would normally operate as expected. For multi-
home networks there are two broad choices to enable such protocols to subnet IPv6 home networks there are two broad choices to enable such
work across the scope of the entire homenet; extend existing protocols to work across the scope of the entire homenet; extend
protocols to work across that scope, or introduce proxies for existing protocols to work across that scope, or introduce proxies
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
that will be restored by the introduction of IPv6 is on the one hand to be restored by the introduction of IPv6 is on the one hand an
an incredible opportunity for innovation and simpler network incredible opportunity for innovation and simpler network operation,
operation, but it is also a concern as it potentially exposes nodes but on the other hand it is also a concern as it potentially exposes
in the internal networks to receipt of unwanted traffic from the nodes in the internal networks to receipt of unwanted traffic from
Internet. 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
skipping to change at page 8, line 38 skipping to change at page 8, line 38
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 to for the homenet to use either mode would be available. the choice for the homenet to use either mode would be available.
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
skipping to change at page 9, line 25 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. temporarily unavailable. A homenet using provider-assigned global
addresses is exposed to its ISP renumbering the network to a much
larger degree than before whereas, for IPv4, NAT isolated the user
against ISP renumbering to some extent.
While setting up a network there may be a period where it has no 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 LLNs are being set up
in a new home/deployment (as early as during construction of the in a new home/deployment (as early as during construction of the
home), LLNs will likely need to use their own /48 ULA prefix. home), LLNs will likely need to use their own /48 ULA prefix.
Depending upon circumstances beyond the scope of homenet, it may be Depending upon circumstances beyond the scope of homenet, it may be
impossible to renumber the ULA used by the LLN so routing between ULA impossible to renumber the ULA used by the LLN so routing between ULA
/48s may be required. Also, some devices, particularly constrained /48s may be required. Also, some devices, particularly constrained
devices, may have only a ULA (in addition to a link-local), while devices, may have only a ULA (in addition to a link-local), while
skipping to change at page 9, line 51 skipping to change at page 10, line 6
not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
[RFC6296], rather that in an IPv6 homenet a node should use its ULA [RFC6296], rather that in an IPv6 homenet a node should use its ULA
address internally, and its additional globally unique IPv6 address address internally, and its additional globally unique IPv6 address
as a source address for external communications. By using such as a source address for external communications. By using such
globally unique addresses between hosts and devices in remote globally unique addresses between hosts and devices in remote
networks, the architectural cost and complexity, particularly to networks, the architectural cost and complexity, particularly to
applications, of NAT or NPTv6 translation is avoided. As such, applications, of NAT or NPTv6 translation is avoided. As such,
neither IPv6 NAT or NPTv6 is recommended for use in the homenet neither IPv6 NAT or NPTv6 is recommended for use in the homenet
architecture. architecture.
Devices in a homenet may be given only a ULA as a means to restrict
reachability from outside the homenet. ULAs can be used by default
for devices that, without additional configuration (e.g. via a web
interface), would only offer services to the internal network. For
example, a printer might only accept incoming connections on a ULA
until configured to be globally reachable, at which point it acquires
a global IPv6 address and may be advertised via a global name space.
Where both a ULA and a global prefix are in use, the ULA source 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.
skipping to change at page 14, line 18 skipping to change at page 14, line 31
Isolation may be physical, or implemented via IEEE 802.1q VLANs. Isolation may be physical, or implemented via IEEE 802.1q VLANs.
The latter is however not something a typical user would be The latter is however not something a typical user would be
expected to configure. expected to configure.
o Demarcation of the CER. The CER(s) may or may not be managed by o Demarcation of the CER. The CER(s) may or may not be managed by
the ISP. If the demarcation point is such that the customer can the ISP. If the demarcation point is such that the customer can
provide or manage the CER, its configuration must be simple. Both provide or manage the CER, its configuration must be simple. Both
models must be supported. models must be supported.
Various forms of multihoming are likely to become more prevalent with Various forms of multihoming are likely to become more prevalent with
IPv6 home networks, as discussed further below. Thus the following IPv6 home networks, where the homenet may have two or more external
ISP connections, as discussed further below. Thus the following
properties should also be considered for such networks: properties should also be considered for such networks:
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
skipping to change at page 20, line 20 skipping to change at page 21, line 20
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
two adjacent homenets, and to avoid unauthorised devices from two adjacent homenets, and to avoid unauthorised devices from
participating in the homenet. Such an authorisation capability may participating in the homenet. Such an authorisation capability may
need to operate through multiple hops in the homenet. need to operate through multiple hops in the homenet.
The homenet should thus support a way for a homenet owner to claim The homenet should thus support a way for a homenet owner to claim
ownership of their devices in a reasonably secure way. This could be ownership of their devices in a reasonably secure way. This could be
achieved by a pairing mechanism, by for example pressing buttons achieved by a pairing mechanism, by for example pressing buttons
simultaneously on an authenticated and a new homenet device. Or by simultaneously on an authenticated and a new homenet device, or by an
an enrolment process, as described in enrolment process as part of an autonomic networking environment.
[I-D.behringer-homenet-trust-bootstrap].
3.3.2. Largest practical subnets 3.3.2. Largest practical subnets
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 to the largest practical subnets that
can be constructed within the constraints of link layer mechanisms, can be constructed within the constraints of link layer mechanisms,
bridging, physical connectivity, and policy, and where applicable bridging, physical connectivity, and policy, and where applicable
performance or other criteria. performance or other criteria. In such subdivisions the logical
topology may not necessarily match the physical topology. This text
does not, however, make recommendations on how such subdivision
should occur. It is expected that subsequent documents 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. Homenet realms and borders 3.3.3. Handling varying link technologies
Homenets tend to grow organically over many years, and a homenet will
typically be built over link-layer technologies from different
generations. Current homenets typically use links ranging from
1Mbit/s up to 1Gbit/s, which is a three orders of magnitude
throughput discrepancy. We expect this discrepancy to widen further
as both high-speed and low-power technologies are deployed.
Homenet protocols should be designed to deal well with
interconnecting links of very different throughputs. In particular,
flows local to a link should not be flooded throughout the homenet,
even when sent over multicast, and, whenever possible, the homenet
protocols should be able to choose the faster links and avoid the
slower ones.
Links (particularly wireless links) may also have limited numbers of
transmit opportunities (txops), and there is a clear trend driven by
both power and downward compatibility constraints toward aggregation
of packets into these limited txops while increasing throughput.
Transmit opportunities may be a system's scarcest resource and
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
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
skipping to change at page 21, line 41 skipping to change at page 23, line 23
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.
Some initial proposals towards border discovery are presented in
[I-D.kline-default-perimeter].
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.
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
skipping to change at page 23, line 8 skipping to change at page 24, line 36
maximum size prefix it might expect to be offered, even if in maximum size prefix it might expect to be offered, even if in
practice it may only be offered a /56 or /60. For a typical IPv6 practice it may only be offered a /56 or /60. For a typical IPv6
homenet, it is not recommended that an ISP offer less than a /60 homenet, it is not recommended that an ISP offer less than a /60
prefix, and it is highly preferable that the ISP offers at least a prefix, and it is highly preferable that the ISP offers at least a
/56. It is expected that the allocated prefix to the homenet from /56. It is expected that the allocated prefix to the homenet from
any single ISP is a contiguous, aggregated one. While it may be any single ISP is a contiguous, aggregated one. While it may be
possible for a homenet CER to issue multiple prefix requests to possible for a homenet CER to issue multiple prefix requests to
attempt to obtain multiple delegations, such behaviour is out of attempt to obtain multiple delegations, such behaviour is out of
scope of this document. scope of this document.
There are reports that some CER equipment does not support receipt of The norm for residential customers of large ISPs may be similar to
a prefix bigger than /64, but the homenet architecture is designed their single IPv4 address provision; by default it is likely to
for future IPv6 home networks, and we assume that such restricted remain persistent for some time, but changes in the ISP's own
equipment will become rarer over time. 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
It is expected that ISPs will deliver a relatively stable prefix to generally support Provider Independent (PI) addressing for
residential customers. The norm for residential customers of large residential homenets.
ISPs may be similar to their single IPv4 address provision; by
default it is likely to 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 case their prefix pool) changing. It is not
expected that ISPs will generally support Provider Independent (PI)
addressing for 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
customer homenets, 'flash' renumbering is likely to be imposed. This customer homenets, 'flash' renumbering is likely to be imposed. This
implies a need for the homenet to be able to handle a sudden implies a need for the homenet to be able to handle a sudden
renumbering event which, unlike the process described in [RFC4192], renumbering event which, unlike the process described in [RFC4192],
would be a 'flag day" event, which means that a graceful renumbering would be a 'flag day" event, which means that a graceful renumbering
process moving through a state with two active prefixes in use would process moving through a state with two active prefixes in use would
not be possible. While renumbering can be viewed as an extended not be possible. While renumbering can be viewed as an extended
version of an initial numbering process, the difference between flash version of an initial numbering process, the difference between flash
renumbering and an initial 'cold start' is the need to provide renumbering and an initial 'cold start' is the need to provide
skipping to change at page 25, line 36 skipping to change at page 27, line 10
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 but not with it. However, where ULAs are used, most likely in parallel with
necessarily in parallel with global prefixes, one router should be global prefixes, one router should be elected as 'master' for
elected as 'master' for delegation of ULA prefixes for the homenet, delegation of ULA prefixes for the homenet, such that only one /48
such that only one /48 ULA covers the whole homenet where possible. ULA covers the whole homenet where possible. That router should
That router should generate a /48 ULA for the site, and then delegate generate a /48 ULA for the site, and then delegate /64's from that
/64's from that ULA prefix to subnets. In cases where two /48 ULAs ULA prefix to subnets. In cases where two /48 ULAs are generated
are generated within a homenet, the network should still continue to within a homenet, the network should still continue to function,
function, meaning that hosts will need to determine that each ULA is meaning that hosts will need to determine that each ULA is local to
local to the homenet. 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).
Several proposals have been made for prefix delegation within a There are multiple potential solutions for prefix delegation within a
homenet. One group of proposals is based on DHCPv6 PD, as described homenet. One solution could be based on DHCPv6 PD, as described in
in [I-D.baker-homenet-prefix-assignment], [RFC3315] and [RFC3633]. [RFC3315] and [RFC3633]. An alternative solution could be to convey
DHCPv6 PD is also used by [I-D.grundemann-homenet-hipnet]. Another prefixes within the chosen homenet routing protocol. This document
proposal uses OSPFv3, as described in makes no specific recommendation, but notes that it is very likely
[I-D.arkko-homenet-prefix-assignment] and that all routing devices participating in a homenet must use the same
[I-D.ietf-ospf-ospfv3-autoconfig]. internal prefix delegation method. This implies that only one
delegation method should be in use.
The above methods assume that all router devices participating in a
homenet 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. It There are no specific privacy concerns discussed in this text. If
should be noted that, in general, ISPs are expected to offer ISPs offer relatively stable IPv6 prefixes to customers, the network
relatively stable IPv6 prefixes to customers, and thus the network prefix part of addresses associated with the homenet may not change
prefix associated with the host addresses they use may not change
over a reasonably long period of time. This exposure is similar to over a reasonably long period of time. This exposure is similar to
IPv4 networks that expose the same IPv4 global address via use of IPv4 networks using NAT, where the IPv4 address received from the ISP
NAT, where the IPv4 address received from the ISP may change over may change over time, but not necessarily that frequently.
time, but not necessarily that frequently.
Hosts inside an IPv6 homenet may get new IPv6 addresses over time Hosts inside an IPv6 homenet may get new IPv6 addresses over time
regardless, e.g. through Privacy Addresses [RFC4941]. This may regardless, e.g. through Privacy Addresses [RFC4941]. This may
benefit mutual privacy of users within a home network, but not mask benefit mutual privacy of users within a home network, but not mask
which home network traffic is sourced from. which home network traffic is sourced from.
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 preferably be an existing The homenet unicast routing protocol should be a previously deployed
deployed protocol that has been shown to be reliable and robust, and protocol that has been shown to be reliable, robust, to allow
it is preferable that the protocol is both 'lightweight' and that lightweight implementations, and of which open source implementations
open source implementations are readily available. It is desirable are available. It is desirable, but not absolutely required, that
that the routing protocol has knowledge of the homenet topology, the routing protocol be able to give a complete view of the network,
which implies a link-state protocol is preferable. This would mean and that it be able to pass around more than just routing
the routing protocol gives a consistent view of the network, and that information.
it can pass around more than just routing information.
Multiple interface PHYs must be accounted for in the homenet routed Multiple interface PHYs must be accounted for in the homenet routed
topology. Technologies such as Ethernet, WiFi, MoCA, etc must be topology. Technologies such as Ethernet, WiFi, MoCA, etc must be
capable of coexisting in the same environment and should be treated capable of coexisting in the same environment and should be treated
as part of any routed deployment. The inclusion of the PHY layer as part of any routed deployment. The inclusion of the PHY 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
skipping to change at page 28, line 26 skipping to change at page 29, line 39
participate the same way as the main homenet, or alternatively map/be participate the same way as the main homenet, or alternatively map/be
gatewayed to the main homenet. Current home deployments use largely gatewayed to the main homenet. Current home deployments use largely
different mechanisms in sensor and basic Internet connectivity different mechanisms in sensor and basic Internet connectivity
networks. IPv6 VM solutions may also add additional routing networks. IPv6 VM solutions may also add additional routing
requirements. 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 multicast would be link-local or site-local, with natural scopes for internal multicast would be link-local or site-
the latter constrained within the homenet, but other policy borders, local, with the latter constrained within the homenet, but other
e.g. to a guest subnet, or to certain media types, may also affect policy borders, e.g. to a guest subnet, or to certain media types,
where specific multicast traffic is routed. may also affect where specific multicast traffic is routed.
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 service discovery should a proposal such as the homenet, e.g. for homenet-wide service discovery should a site-
xmDNS [I-D.lynn-homenet-site-mdns] be deployed, or potentially for scope multicast service discovery protocol be defined, or potentially
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
external networks, e.g. where video applications use multicast to
conserve the bandwidth they consume. Such multicast traffic would be
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
Devices may be mobile within the homenet. While resident on the same
subnet, their address will remain persistent, but should devices move
to a different (wireless) subnet, they will acquire a new address in
that subnet. It is desirable that the homenet supports internal
device mobility. To do so, the homenet may either extend the reach
of specific wireless subnets to enable wireless roaming across the
home (availability of a specific subnet across the home), or it may
support mobility protocols to facilitate such roaming where multiple
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 direct 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
skipping to change at page 30, line 16 skipping to change at page 31, line 47
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.
3.6.3. Marginal Effectiveness of NAT and Firewalls 3.6.3. Partial Effectiveness of NAT and Firewalls
Security by way of obscurity (address translation) or through Security by way of obscurity (address translation) or through
firewalls (filtering) is at best marginally effective. The very poor firewalls (filtering) is at best only partially effective. The very
security track record of home computer, home networking and business poor security track record of home computer, home networking and
PC computers and networking is testimony to its ineffectiveness. A business PC computers and networking is testimony to this. A
security compromise behind the firewall of any device exposes all security compromise behind the firewall of any device exposes all
others, making an entire network that relies on obscurity or a others, making an entire network that relies on obscurity or a
firewall as vulnerable as the most insecure device on the private firewall as vulnerable as the most insecure device on the private
side of the network. side of the network.
However, given home network products with very poor security, putting However, given current evidence of home network products with very
a firewall in place does provide some protection, even if only poor default device security, putting a firewall in place does
marginally effective. The use of firewalls today, whether a good provide some level of protection. The use of firewalls today,
practice or not, is common practice and whatever protection afforded, whether a good practice or not, is common practice and whatever
even if marginally effective, should not be lost. protection afforded, even if marginally effective, should not be
lost. Thus, while it is highly desirable that all hosts in a homenet
be adequately protected by built-in security functions, it should
also be assumed that all CERs will continue to support appropriate
perimeter defence functions, as per [I-D.ietf-v6ops-6204bis].
3.6.4. Device capabilities 3.6.4. 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.
skipping to change at page 33, line 22 skipping to change at page 35, line 10
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 access
to the homenet). The .local name space currently has a special to the homenet). The .local name space currently has a special
meaning for certain existing protocols which have link-local scope, meaning for certain existing protocols which have link-local scope,
and is thus not appropriate for multi-subnet home networks. A 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 (ALQDN) 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 an application in one homenet to be confused bookmarked somehow by name by an application in one homenet to be
with a device with the same name in another homenet. In practice confused with a device with the same name in another homenet. In
however the underlying service discovery protocols should be capable practice however the underlying service discovery protocols should be
of handling moving to a network where a new device is using the same capable of handling moving to a network where a new device is using
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 (ULQDN) 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
skipping to change at page 36, line 20 skipping to change at page 38, line 10
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 the search domains for
local FQDN-derived zones should be included. local FQDN-derived zones should be included.
3.7.8. Devices roaming from the homenet 3.7.8. Devices roaming 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 may be desirable that devices may be locations. In such cases it is desirable that devices may be
accessed by the same name as is used in the home network. accessed by the same name as is used in the 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. put additional requirements on to the homenet, or establishment of a
(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 QoS in a multi-service homenet may be a requirement, e.g.
skipping to change at page 40, line 43 skipping to change at page 42, line 26
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(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.
[I-D.lynn-homenet-site-mdns]
Lynn, K. and D. Sturek, "Extended Multicast DNS",
draft-lynn-homenet-site-mdns-01 (work in progress),
September 2012.
[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.baker-homenet-prefix-assignment]
Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small
Networks", draft-baker-homenet-prefix-assignment-01 (work
in progress), March 2012.
[I-D.arkko-homenet-prefix-assignment]
Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment
in a Home Network",
draft-arkko-homenet-prefix-assignment-03 (work in
progress), October 2012.
[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-02 (work in progress),
April 2013. April 2013.
[I-D.ietf-pcp-base] [I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-29 (work in progress), November 2012. draft-ietf-pcp-base-29 (work in progress), November 2012.
[I-D.grundemann-homenet-hipnet]
Grundemann, C., Donley, C., Brzozowski, J., Howard, L.,
and V. Kuarsingh, "A Near Term Solution for Home IP
Networking (HIPnet)", draft-grundemann-homenet-hipnet-01
(work in progress), February 2013.
[I-D.kline-default-perimeter]
Kline, E., "Default Border Definition",
draft-kline-default-perimeter-01 (work in progress),
November 2012.
[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.
[I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet",
draft-behringer-homenet-trust-bootstrap-00 (work in
progress), October 2012.
[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 [IGD-2] UPnP Gateway Committee, "Internet Gateway Device (IGD) V
2.0", September 2010, <http://upnp.org/specs/gw/ 2.0", September 2010, <http://upnp.org/specs/gw/
UPnP-gw-WANIPConnection-v2-Service.pdf>. UPnP-gw-WANIPConnection-v2-Service.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Aamer Akhter, Mark Andrews, Dmitry The authors would like to thank Aamer Akhter, Mikael Abrahamsson,
Anipko, Ran Atkinson, Fred Baker, Ray Bellis, Teco Boot, John Mark Andrews, Dmitry Anipko, Ran Atkinson, Fred Baker, Ray Bellis,
Brzozowski, Cameron Byrne, Brian Carpenter, Stuart Cheshire, Lorenzo Teco Boot, John Brzozowski, Cameron Byrne, Brian Carpenter, Stuart
Colitti, Robert Cragie, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Ralph
Gudmundsson, Wassim Haddad, Joel M. Halpern, David Harrington, Lee Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, Wassim Haddad,
Howard, Ray Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Joel M. Halpern, David Harrington, Lee Howard, Ray Hunter, Joel
Lindem, Kerry Lynn, Daniel Migault, Erik Nordmark, Michael Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Lynn, Daniel
Richardson, Mattia Rossi, Barbara Stark, Markus Stenberg, Sander Migault, Erik Nordmark, Michael Richardson, Mattia Rossi, Barbara
Steffann, Don Sturek, Andrew Sullivan, Dave Taht, Dave Thaler, Stark, Markus Stenberg, Sander Steffann, Don Sturek, Andrew Sullivan,
Michael Thomas, Mark Townsley, JP Vasseur, Curtis Villamizar, Dan Dave Taht, Dave Thaler, Michael Thomas, Mark Townsley, JP Vasseur,
Wing, Russ White, and James Woodyatt for their comments and Curtis Villamizar, Dan Wing, Russ White, and James Woodyatt for their
contributions within homenet WG meetings and on the WG mailing list. comments and contributions within homenet WG meetings and on the WG
An acknowledgement generally means that person's text made it in to mailing list. An acknowledgement generally means that person's text
the document, or was helpful in clarifying or reinforcing an aspect made it in to the document, or was helpful in clarifying or
of the document. reinforcing an aspect of the document. It does not 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 08 B.1. Version 09 (after WGLC)
Changes made include:
o Added note about multicast into or out of site
o Removed further personal draft references, replaced with covering
text
o Routing functionality text updated to avoid ambiguity
o Added note that devices away from homenet may tunnel home (via
VPN)
o Added note that homenets more exposed to provider renumbering than
with IPv4 and NAT
o Added note about devices that may be ULA-only until configured to
be globally addressable
o Removed paragraph about broken CERs that do not work with prefixes
other than /64
o Noted no recommendation on methods to convey prefix information is
made in this text
o Stated that this text does not recommend how to form largest
possible subnets
o Added text about homenet evolution and handling disparate media
types
o Rephrased NAT/firewall text on marginal effectiveness
o Emphasised that multihoming may be to any number of ISPs
B.2. 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
skipping to change at page 43, line 4 skipping to change at page 44, line 36
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.2. Version 07 B.3. 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 43, line 43 skipping to change at page 45, 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.3. Version 06 B.4. 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.4. Version 05 B.5. 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.5. Version 04 B.6. 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.6. Version 03 B.7. 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 46, line 5 skipping to change at page 47, 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.7. Version 02 B.8. 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. 47 change blocks. 
209 lines changed or deleted 265 lines changed or added

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