draft-ietf-homenet-arch-16.txt   draft-ietf-homenet-arch-17.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: December 12, 2014 Ericsson Expires: January 5, 2015 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
June 10, 2014 July 4, 2014
IPv6 Home Networking Architecture Principles IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-16 draft-ietf-homenet-arch-17
Abstract Abstract
This text describes evolving networking technology within residential This text describes evolving networking technology within residential
home networks with increasing numbers of devices and a trend towards home networks with increasing numbers of devices and a trend towards
increased internal routing. The goal of this document is to define a increased internal routing. The goal of this document is to define a
general architecture for IPv6-based home networking, describing the general architecture for IPv6-based home networking, describing the
associated principles, considerations and requirements. The text associated principles, considerations and requirements. The text
briefly highlights specific implications of the introduction of IPv6 briefly highlights specific implications of the introduction of IPv6
for home networking, discusses the elements of the architecture, and for home networking, discusses the elements of the architecture, and
suggests how standard IPv6 mechanisms and addressing can be employed suggests how standard IPv6 mechanisms and addressing can be employed
in home networking. The architecture describes the need for specific in home networking. The architecture describes the need for specific
protocol extensions for certain additional functionality. It is protocol extensions for certain additional functionality. It is
assumed that the IPv6 home network is not actively managed, and runs assumed that the IPv6 home network is not actively managed, and runs
as an IPv6-only or dual-stack network. There are no recommendations as an IPv6-only or dual-stack network. There are no recommendations
in this text for the IPv4 part 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 December 12, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 11 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 11
3. Homenet Architecture Principles . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 18 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 18
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Mobility support . . . . . . . . . . . . . . . . . . . 20 3.2.5. Mobility support . . . . . . . . . . . . . . . . . . 20
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20
3.3.1. Differentiating neighbouring homenets . . . . . . . . 21 3.3.1. Differentiating neighbouring homenets . . . . . . . . 21
3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21
3.3.3. Handling varying link technologies . . . . . . . . . . 22 3.3.3. Handling varying link technologies . . . . . . . . . 22
3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22 3.3.4. Homenet realms and borders . . . . . . . . . . . . . 22
3.3.5. Configuration information from the ISP . . . . . . . . 23 3.3.5. Configuration information from the ISP . . . . . . . 23
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 23 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . 23
3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 24 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . 24
3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 26 3.4.2. Stable internal IP addresses . . . . . . . . . . . . 26
3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 27 3.4.3. Internal prefix delegation . . . . . . . . . . . . . 27
3.4.4. Coordination of configuration information . . . . . . 28 3.4.4. Coordination of configuration information . . . . . . 28
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 30 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.5.1. Unicast Routing Within the Homenet . . . . . . . . . 29
3.6.1. Addressability vs reachability . . . . . . . . . . . . 31 3.5.2. Unicast Routing at the Homenet Border . . . . . . . . 31
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 32 3.5.3. Multicast support . . . . . . . . . . . . . . . . . . 31
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 33 3.6.1. Addressability vs reachability . . . . . . . . . . . 32
3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 33 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . 33
3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . 33
3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 34 3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 34
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34 3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 34
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 35 3.6.6. ULAs as a hint of connection origin . . . . . . . . . 34
3.7.3. The homenet name service . . . . . . . . . . . . . . . 35 3.7. Naming and Service Discovery . . . . . . . . . . . . . . 34
3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36 3.7.1. Discovering services . . . . . . . . . . . . . . . . 35
3.7.5. Independent operation . . . . . . . . . . . . . . . . 39 3.7.2. Assigning names to devices . . . . . . . . . . . . . 36
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 39 3.7.3. The homenet name service . . . . . . . . . . . . . . 36
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 39 3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 37
3.7.8. Devices roaming to/from the homenet . . . . . . . . . 40 3.7.5. Independent operation . . . . . . . . . . . . . . . . 39
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 40
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 40 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . 40
3.8.2. Operations and Management . . . . . . . . . . . . . . 40 3.7.8. Devices roaming to/from the homenet . . . . . . . . . 40
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 42 3.8. Other Considerations . . . . . . . . . . . . . . . . . . 41
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 3.8.2. Operations and Management . . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 42
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1. Normative References . . . . . . . . . . . . . . . . . . . 43 5. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7.2. Informative References . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 46 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46 7.1. Normative References . . . . . . . . . . . . . . . . . . 43
B.1. Version 14 . . . . . . . . . . . . . . . . . . . . . . . . 46 7.2. Informative References . . . . . . . . . . . . . . . . . 44
B.2. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47
B.3. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 47
B.4. Version 11 (after IESG review) . . . . . . . . . . . . . . 47 B.1. Version 17 . . . . . . . . . . . . . . . . . . . . . . . 47
B.5. Version 10 (after AD review) . . . . . . . . . . . . . . . 47 B.2. Version 16 . . . . . . . . . . . . . . . . . . . . . . . 47
B.6. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47 B.3. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 47
B.7. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.4. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 48
B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.5. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 48
B.9. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.6. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 48
B.10. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.7. Version 11 (after IESG review) . . . . . . . . . . . . . 48
B.11. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.8. Version 10 (after AD review) . . . . . . . . . . . . . . 49
B.12. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.9. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 49
B.13. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.10. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 B.11. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 50
B.12. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 51
B.13. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 51
B.14. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 51
B.15. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 51
B.16. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
This document focuses on evolving networking technology within This document focuses on evolving networking technology within
residential home networks with increasing numbers of devices and a residential home networks with increasing numbers of devices and a
trend towards increased internal routing, and the associated 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
skipping to change at page 5, line 27 skipping to change at page 5, line 29
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. Likewise, we also do not specify the link layer considerations. Likewise, we also do not specify the
whole design of a homenet router from top to bottom, rather we focus whole design of a homenet router from top to bottom, rather we focus
on the Layer 3 aspects. This means that Layer 2 is largely out of on the Layer 3 aspects. This means that Layer 2 is largely out of
scope, we're assuming a data link layer that supports IPv6 is scope, we're assuming a data link layer that supports IPv6 is
present, and that we react accordingly. Any IPv6-over-Foo present, and that we react accordingly. Any IPv6-over-Foo
definitions occur elsewhere. definitions occur elsewhere.
[RFC6204] defines basic requirements for customer edge routers [RFC7084], which has obsoleted [RFC6204], defines basic requirements
(CERs). This document has recently been updated with the definition for customer edge routers (CERs). The update includes the definition
of requirements for specific transition tools on the CER in of requirements for specific transition tools on the CER,
[RFC7084], specifically DS-Lite [RFC6333] and 6rd [RFC5969]. Such specifically DS-Lite [RFC6333] and 6rd [RFC5969]. Such detailed
detailed specification of CER devices is considered out of scope of specification of CER devices is considered out of scope of this
this architecture document, and we assume that any required update of architecture document, and we assume that any required update of the
the CER device specification as a result of adopting this CER device specification as a result of adopting this architecture
architecture will be handled as separate and specific updates to will be handled as separate and specific updates to these existing
these existing documents. Further, the scope of this text is the documents. Further, the scope of this text is the internal homenet,
internal homenet, and thus specific features on the WAN side of the and thus specific features on the WAN side of the CER are out of
CER are out of scope for this text. 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.
skipping to change at page 9, line 19 skipping to change at page 9, line 22
correct source address to be used for the corresponding uplink. correct source address to be used for the corresponding uplink.
Default Address Selection for IPv6 [RFC6724] provides a solution for Default Address Selection for IPv6 [RFC6724] provides a solution for
this, but a challenge here is that the node may not have the this, but a challenge here is that the node may not have the
information it needs to make that decision based on addresses alone. information it needs to make that decision based on addresses alone.
We discuss this challenge in Section 3.2.4. We discuss this challenge in 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 [RFC7084]. 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.
skipping to change at page 14, line 8 skipping to change at page 14, line 8
As hinted above, while the architecture may focus on likely common As hinted above, while the architecture may focus on likely common
topologies, it should not preclude any arbitrary topology from being topologies, it should not preclude any arbitrary topology from being
constructed. constructed.
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 Architectures described in [RFC6204] For IPv6 homenets, the Network Architectures described in [RFC7084]
and its successor [RFC7084] should, as a minimum, be supported. should, as a minimum, be 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 16, line 46 skipping to change at page 16, line 46
| | | | | | | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ | +----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | |
| H5 | | H6 | | H7 | | H8 | / | H5 | | H6 | | H7 | | H8 | /
+----------+ +----------+ +----------+ +----------+ / +----------+ +----------+ +----------+ +----------+ /
Figure 1 Figure 1
In this diagram there is one CER. It has a single uplink interface. In this diagram there is one CER. It has a single uplink interface.
It has three additional interfaces connected to Network A, Link F, It has three additional interfaces connected to Network A, Link F,
and Network B. IPv6 Internal Router (IR) has four interfaces and Network B. IPv6 Internal Router (IR) has four interfaces
connected to Link F, Network C, Network D and Network E. Network B connected to Link F, Network C, Network D and Network E. Network B
and Network E have been bridged, likely inadvertently. This could be and Network E have been bridged, likely inadvertently. This could be
as a result of connecting a wire between a switch for Network B and a as a result of connecting a wire between a switch for Network B and a
switch for Network E. switch for Network E.
Any of logical Networks A through F might be wired or wireless. Any of logical Networks A through F might be wired or wireless.
Where multiple hosts are shown, this might be through one or more Where multiple hosts are shown, this might be through one or more
physical ports on the CER or IPv6 (IR), wireless networks, or through physical ports on the CER or IPv6 (IR), wireless networks, or through
one or more layer-2 only Ethernet switches. one or more layer-2 only Ethernet switches.
3.2.2.2. B: Two ISPs, Two CERs, Shared subnet 3.2.2.2. B: Two ISPs, Two CERs, Shared subnet
+-------+-------+ +-------+-------+ \ +-------+-------+ +-------+-------+ \
| Service | | Service | \ | Service | | Service | \
| Provider A | | Provider B | | Service | Provider A | | Provider B | | Service
| Router | | Router | | Provider | Router | | Router | | Provider
skipping to change at page 17, line 37 skipping to change at page 17, line 38
---+---------+---+---------------+--+----------+--- | network(s) ---+---------+---+---------------+--+----------+--- | network(s)
| | | | \ | | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|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 prefixes, 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 | \
| Provider A | | Provider B | | Service | Provider A | | Provider B | | Service
| Router | | Router | | Provider | Router | | Router | | Provider
+-------+-------+ +-------+-------+ | network +-------+-------+ +-------+-------+ | network
| | / | | /
| Customer | / | Customer | /
| Internet | / | Internet | /
| connections | | connections |
+---------+---------+ \ +---------+---------+ \
skipping to change at page 26, line 34 skipping to change at page 26, line 34
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 7084 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 6204 filtering at the border(s) of the homenet, as mandated by RFC 7084
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 may be in use within the same homenet, e.g., when the network is
being deployed, perhaps also without external connectivity. In cases being deployed, perhaps also without external connectivity. In cases
where multiple ULA /48's are in use, hosts need to know that each /48 where multiple ULA /48's are in use, hosts need to know that each /48
is 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
skipping to change at page 28, line 40 skipping to change at page 28, line 40
Addresses [RFC4941], adds additional exposure of which traffic is Addresses [RFC4941], adds additional exposure of which traffic is
sourced from the same internal device, through use of the same IPv6 sourced from the same internal device, through use of the same IPv6
source address for a period of time. 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.
discussed below should be met.
The homenet unicast routing protocol should be based on a previously A mechanism is required to discover which router(s) in the homenet
deployed protocol that has been shown to be reliable and robust, and are providing the CER function. Borders may include but are not
that allows lightweight implementations, but that does not preclude limited to the interface to the upstream ISP, a gateway device to a
the selection of a newer protocol for which a high quality open separate home network such as a LLN network, or a gateway to a guest
source implementation becomes available. Using information or private corporate extension network. In some cases there may be
distributed through the routing protocol, each node in the homenet no border present, which may for example occur before an upstream
should be able to build a graph of the topology of the whole homenet connection has been established.
including attributes such as links, nodes, connectivity, and (if
supported by the protocol in use) link metrics.
The routing protocol should support the generic use of multiple The routing environment should be self-configuring, as discussed
customer Internet connections, and the concurrent use of multiple previously. The homenet self-configuration process and the routing
delegated prefixes. A routing protocol that can make routing protocol must interact in a predictable manner, especially during
decisions based on source and destination addresses is thus startup and reconvergence. The border discovery functionality and
desirable, to avoid upstream ISP BCP 38 ingress filtering problems. other self-configuration functionality may be integrated into the
Multihoming support should also include load-balancing to multiple routing protocol itself, but may also be imported via a separate
providers, and failover from a primary to a backup link when discovery mechanism.
available. The protocol however should not require upstream ISP
connectivity to be established to continue routing within the
homenet.
Routing within the homenet will determine the least cost path across It is preferable that configuration information is distributed and
the homenet towards the destination address given the source address. synchronised within the homenet by a separate configuration protocol.
The path cost will be computed as a linear sum of the metric assigned
to each link. The metric may be configured or automatically derived The homenet routing protocol should be based on a previously deployed
per link based on consideration of factors such as worst-case queue protocol that has been shown to be reliable and robust. This does
depth and router processing capabilities. not preclude the selection of a newer protocol for which a high
quality open source implementation becomes available. The resulting
code must support lightweight implementations, and be suitable for
incorporation into consumer devices, where both fixed and temporary
storage and processing power are at a premium.
At most, one unicast and one multicast routing protocol should be in
use at a given time in a given homenet. In some simple topologies,
no routing protocol may be needed. If more than one routing protocol
is supported by routers in a given homenet, then a mechanism is
required to ensure that all routers in that homenet use the same
protocol.
The homenet architecture is IPv6 only. In practice, dual-stack
homenets are still likely for the foreseeable future, as described in
Section 3.2.3. Whilst support for IPv4 and other address families
may therefore be beneficial, it is not an explicit requirement to
carry the routing information in the same routing protocol.
Multiple types of physical interfaces must be accounted for in the Multiple types of physical interfaces must be accounted for in the
homenet routed topology. Technologies such as Ethernet, WiFi, homenet routing topology. Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path characteristics in path computation should be considered for
computation should be considered for optimising communication in the optimising communication in the homenet.
homenet.
The routing environment should be self-configuring, as discussed 3.5.1. Unicast Routing Within the Homenet
previously. Minimising convergence time should be a goal in any
routed environment, but as a guideline a maximum convergence time at
most 30 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).
Homenets may use a variety of underlying link layer technologies, and The role of the unicast routing protocol is to provide good enough
may therefore benefit from being able to use link metrics if end-to-end connectivity often enough, where good/often enough is
available. It may be beneficial for traffic to use multiple paths to defined by user expectations.
a given destination within the homenet where available, rather than a
single best path.
At most one routing protocol should be in use at a given time in a Due to the use of a variety of diverse underlying link technologies,
given homenet. In some simple topologies, no routing protocol may be path selection in a homenet may benefit from being more refined than
needed. If more than one routing protocol is supported by routers in minimising hop count. It may also be beneficial for traffic to use
a given homenet, then a mechanism is required to ensure that all multiple paths to a given destination within the homenet where
routers in that homenet use the same protocol. available, rather than just a single best path.
An appropriate mechanism is required to discover which router(s) in Minimising convergence time should be a goal in any routed
the homenet are providing the CER function. Borders may include but environment. It is reasonable to assume that convergence time should
are not limited to the interface to the upstream ISP, a gateway not be significantly longer than network outages users are accustomed
device to a separate home network such as a LLN network, or a gateway to should their CER reboot.
to a guest or private corporate extension network. In some cases
there may be no border present, which may for example occur before an The homenet architecture is agnostic as to the choice of underlying
upstream connection has been established. The border discovery routing technology, e.g., link state versus Bellman-Ford.
functionality may be integrated into the routing protocol itself, but
may also be imported via a separate discovery mechanism. The routing protocol should support the generic use of multiple
customer Internet connections, and the concurrent use of multiple
delegated prefixes. A routing protocol that can make routing
decisions based on source and destination addresses is thus highly
desirable, to avoid upstream ISP BCP 38 ingress filtering problems.
Multihoming support may also include load-balancing to multiple
providers, and failover from a primary to a backup link when
available. The protocol should not require upstream ISP connectivity
to be established to continue routing within the homenet.
The homenet architecture is agnostic on a minimum hop count that has
to be supported by the routing protocol. The architecture should
however be scalable to other scenarios where homenet technology may
be deployed, which may include small office and small enterprise
sites. To allow for such cases it would be desirable that the
architecture is scalable to higher hop counts and to a larger numbers
of routers than would be typical in a true home network.
At the time of writing, link layer networking technology is poised to
become more heterogeneous, as networks begin to employ both
traditional Ethernet technology and link layers designed for low-
power and lossy networks (LLNs), such as those used for certain types
of sensor devices.
Ideally, LLN or other logically separate networks should be able Ideally, LLN or other logically separate networks should be able
exchange routes such that IP traffic may be forwarded among the exchange routes such that IP traffic may be forwarded among the
networks via gateway routers which interoperate with both the homenet networks via gateway routers which interoperate with both the homenet
and the LLN. Current home deployments use largely different and any LLNs. Current home deployments use largely different
mechanisms in sensor and basic Internet connectivity networks. IPv6 mechanisms in sensor and basic Internet connectivity networks. IPv6
virtual machine (VM) solutions may also add additional routing virtual machine (VM) solutions may also add additional routing
requirements. requirements.
3.5.1. Multicast support In this homenet architecture, LLNs and other specialised networks are
considered stub areas of the homenet, and are thus not expected to
act as a transit for traffic between more traditional media.
3.5.2. Unicast Routing at the Homenet Border
The current practice defined in [RFC7084] would suggest that routing
between the homenet CER and the Service Provider Router follow the
model of [RFC7084] Section 4 WAN Side Requirements, at least in
initial deployments. However, consideration of whether a routing
protocol is used between the homenet CER and the Service provider
Router is out of scope of this document.
3.5.3. 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, media types, multicast routing is supported across the homenet,
including source-specific multicast (SSM) [RFC4607]. including source-specific multicast (SSM) [RFC4607] .
[RFC4291] requires that any boundary of scope 4 or higher (i.e., [RFC4291] requires that any boundary of scope 4 or higher (i.e.,
admin-local or higher) be administratively configured. Thus the admin-local or higher) be administratively configured. Thus the
boundary at the homenet-ISP border must be administratively boundary at the homenet-ISP border must be administratively
configured, though that may be triggered by an administrative configured, though that may be triggered by an administrative
function such as DHCP-PD. Other multicast forwarding policy borders function such as DHCP-PD. Other multicast forwarding policy borders
may also exist within the homenet, e.g., to/from a guest subnet, may also exist within the homenet, e.g., to/from a guest subnet,
whilst the use of certain link media types may also affect where whilst the use of certain link media types may also affect where
specific multicast traffic is forwarded or routed. specific multicast traffic is forwarded or routed.
skipping to change at page 31, line 34 skipping to change at page 32, line 30
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 PCP [RFC6887]. In networks with multiple CERs, the protocol such as PCP [RFC6887]. In networks with multiple CERs, the
signalling would need to handle the cases of flows that may use one signalling would need to handle the cases of flows that may use one
or more exit routers. CERs would need to be able to advertise their or more exit routers. CERs would need to be able to 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
skipping to change at page 33, line 42 skipping to change at page 34, line 37
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.6. 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 6204 requirement S-2, a ULA source address CER(s), as mandated by RFC 7084 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, and which are not names by which they can be accessed on the network, and which are not
skipping to change at page 39, line 39 skipping to change at page 40, line 29
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) solutions for use by the Constrained Application Protocol (CoAP)
[I-D.ietf-core-coap] in LLN networks. These are outside the scope of [RFC7252] in LLN networks. These are outside the scope of this
this document. 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 it may be desirable to hops away from the name service. Similarly it may be desirable to
convey any DNS domain search list that may be in effect for the convey any DNS domain search list that may be in effect for the
homenet. homenet.
skipping to change at page 43, line 29 skipping to change at page 44, line 18
[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", BCP
BCP 5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
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
February 2000. 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 [RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking
Workshop", RFC 3002, December 2000. 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
January 2001. 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, March 2005. 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.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
skipping to change at page 44, line 35 skipping to change at page 45, line 24
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.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[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
RFC 5969, August 2010. 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
January 2011. 2011.
[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.
skipping to change at page 45, line 31 skipping to change at page 46, line 20
(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
April 2013. 2013.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, October 2013. the DNS", RFC 6950, October 2013.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, March 2014. Translation", RFC 7157, March 2014.
[I-D.ietf-core-coap] [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", RFC 7252, June 2014.
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[IABdotless] [IABdotless]
"IAB Statement: Dotless Domains Considered Harmful", "IAB Statement: Dotless Domains Considered Harmful",
February 2013, <http://www.iab.org/documents/ February 2013, <http://www.iab.org/documents/
correspondence-reports-documents/2013-2/ correspondence-reports-documents/2013-2/
iab-statement-dotless-domains-considered-harmful>. 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>.
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, Elwyn Cheshire, Julius Chroboczek, Lorenzo Colitti, Robert Cragie, Elwyn
Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson, Davies, Ralph Droms, Lars Eggert, Jim Gettys, Olafur Gudmundsson,
Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray
Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry
Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia
Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek, Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek,
Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark
Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and
James Woodyatt for their comments and contributions within homenet WG James Woodyatt for their comments and contributions within homenet WG
meetings and on the WG mailing list. An acknowledgement generally meetings and on the WG mailing list. An acknowledgement generally
means that person's text made it in to the document, or was helpful means that person's text made it in to the document, or was helpful
in clarifying or reinforcing an aspect of the document. It does not in clarifying or reinforcing an aspect of the document. It does not
imply that each contributor agrees with every point in the document. imply that each contributor 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 14 B.1. Version 17
Changes made include:
o Updated Section 3.5 on routing functionality.
o Noted consensus in London for a separate configuration protocol.
o Updated text to refer to RFC7084 rather than RFC6204.
o Updated coap reference to the pubished RFC.
B.2. Version 16
Changes made include:
o Reverted back to paragraph on link metric usage.
B.3. Version 15
Changes made include:
o Inserted WG chair compromise text on routing functionality.
Removed paragraph on link metric usage.
B.4. Version 14
Changes made include: Changes made include:
o Changes for Adrian Farrell discuss/comment. o Changes for Adrian Farrell discuss/comment.
o Very minor wordsmithing requested by Benoit for OAM text. o Very minor wordsmithing requested by Benoit for OAM text.
o Very minor wordsmithing from IETF89 session. o Very minor wordsmithing from IETF89 session.
o Added note to support SSM. o Added note to support SSM.
o Emphasised at most one routing protocol in use, possibly none. o Emphasised at most one routing protocol in use, possibly none.
B.2. Version 13 B.5. Version 13
Changes made include: Changes made include:
o Changes to address last outstanding IESG DISCUSSes/COMMENTs. o Changes to address last outstanding IESG DISCUSSes/COMMENTs.
B.3. Version 12 B.6. Version 12
Changes made include: Changes made include:
o Fixed minor typo nits introduced in -11. o Fixed minor typo nits introduced in -11.
o Elwyn Davies' gen-art review comments addressed. o Elwyn Davies' gen-art review comments addressed.
o Some further IESG DISCUSSes/COMMENTs addressed. o Some further IESG DISCUSSes/COMMENTs addressed.
B.4. Version 11 (after IESG review) B.7. Version 11 (after IESG review)
Changes made include: Changes made include:
o Jouni Korhonen's OPSDIR review comments addressed. o Jouni Korhonen's OPSDIR review comments addressed.
o Elwyn Davies' gen-art review comments addressed. o Elwyn Davies' gen-art review comments addressed.
o Considered secdir review by Samiel Weiler; many points addressed. o Considered secdir review by Samiel Weiler; many points addressed.
o Considered APPSDIR review. o Considered APPSDIR review.
o Addressed a large number of IESG comments and discusses. o Addressed a large number of IESG comments and discusses.
B.5. Version 10 (after AD review) B.8. 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.6. Version 09 (after WGLC) B.9. 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
o Added note that devices away from homenet may tunnel home (via o Added note that devices away from homenet may tunnel home (via
VPN) VPN)
o Added note that homenets more exposed to provider renumbering than o Added note that homenets more exposed to provider renumbering than
with IPv4 and NAT with IPv4 and NAT
o Added note about devices that may be ULA-only until configured to o Added note about devices that may be ULA-only until configured to
be globally addressable be globally addressable
o Removed paragraph about broken CERs that do not work with prefixes o Removed paragraph about broken CERs that do not work with prefixes
skipping to change at page 48, line 29 skipping to change at page 49, line 47
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.7. Version 08 B.10. 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
skipping to change at page 48, line 47 skipping to change at page 50, line 16
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.8. Version 07 B.11. 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.
o Made it clearer that ULAs are expected to be used alongside o Made it clearer that ULAs are expected to be used alongside
globals. globals.
o Removed reference to 'advanced security' as described in o Removed reference to 'advanced security' as described in draft-
draft-vyncke-advanced-ipv6-security. vyncke-advanced-ipv6-security.
o Balanced the text between ULQDN and ALQDN. o Balanced the text between ULQDN and ALQDN.
o Clarify text does not assume default deny or allow on CER, but o Clarify text does not assume default deny or allow on CER, but
that either mode may be enabled. that either mode may be enabled.
o Removed ULA-C reference for 'simple' addresses. Instead only o Removed ULA-C reference for 'simple' addresses. Instead only
suggested service discovery to find such devices. suggested service discovery to find such devices.
o Reiterated that single/multiple CER models to be supported for o Reiterated that single/multiple CER models to be supported for
skipping to change at page 49, line 38 skipping to change at page 51, line 5
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.9. Version 06 B.12. 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.10. Version 05 B.13. 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.11. Version 04 B.14. 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.12. Version 03 B.15. 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 51, line 47 skipping to change at page 53, line 11
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.13. Version 02 B.16. 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.
skipping to change at page 52, line 39 skipping to change at page 53, line 49
o Added reference to the new xmDNS draft. o Added reference to the new xmDNS draft.
o Added naming/SD requirements from Ralph Droms. o Added naming/SD requirements from Ralph Droms.
Authors' Addresses Authors' Addresses
Tim Chown (editor) Tim Chown (editor)
University of Southampton University of Southampton
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton , Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Anders Brandt Anders Brandt
Sigma Designs Sigma Designs
Emdrupvej 26A, 1 Emdrupvej 26A, 1
Copenhagen DK-2100 Copenhagen DK-2100
Denmark Denmark
Email: abr@sdesigns.dk Email: abr@sdesigns.dk
Ole Troan Ole Troan
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 59 change blocks. 
203 lines changed or deleted 267 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/