draft-ietf-homenet-arch-09.txt   draft-ietf-homenet-arch-10.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: January 16, 2014 Ericsson Expires: February 2, 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
July 15, 2013 August 1, 2013
Home Networking Architecture for IPv6 Home Networking Architecture for IPv6
draft-ietf-homenet-arch-09 draft-ietf-homenet-arch-10
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 January 16, 2014. This Internet-Draft will expire on February 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5 1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 5
2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6 2. Effects of IPv6 on Home Networking . . . . . . . . . . . . . . 6
2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 7 2.1. Multiple subnets and routers . . . . . . . . . . . . . . . 7
2.2. Global addressability and elimination of NAT . . . . . . . 8 2.2. Global addressability and elimination of NAT . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . 13 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 . . . . . . . . . . . . . . . . 17
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 18
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 19
3.3.1. Differentiating neighbouring homenets . . . . . . . . 21 3.3.1. Differentiating neighbouring homenets . . . . . . . . 20
3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 20
3.3.3. Handling varying link technologies . . . . . . . . . . 21 3.3.3. Handling varying link technologies . . . . . . . . . . 21
3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22 3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 21
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 23 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 22
3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 23 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 22
3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 25 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 24
3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 26 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 25
3.4.4. Coordination of configuration information . . . . . . 27 3.4.4. Coordination of configuration information . . . . . . 26
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 27
3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 27
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 28
3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30 3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 29
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6.1. Addressability vs reachability . . . . . . . . . . . . 30 3.6.1. Addressability vs reachability . . . . . . . . . . . . 29
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 31 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 30
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 31 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 31
3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 32 3.6.4. Device capabilities . . . . . . . . . . . . . . . . . 31
3.6.5. ULAs as a hint of connection origin . . . . . . . . . 32 3.6.5. ULAs as a hint of connection origin . . . . . . . . . 31
3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 32 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 31
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 32
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 33
3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 34 3.7.3. Name spaces . . . . . . . . . . . . . . . . . . . . . 33
3.7.4. The homenet name service . . . . . . . . . . . . . . . 36 3.7.4. The homenet name service . . . . . . . . . . . . . . . 35
3.7.5. Independent operation . . . . . . . . . . . . . . . . 37 3.7.5. Independent operation . . . . . . . . . . . . . . . . 36
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 37 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 36
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 37 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 37
3.7.8. Devices roaming from the homenet . . . . . . . . . . . 38 3.7.8. Devices roaming from the homenet . . . . . . . . . . . 37
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 38 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 37
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 38 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 37
3.8.2. Operations and Management . . . . . . . . . . . . . . 38 3.8.2. Operations and Management . . . . . . . . . . . . . . 38
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 39 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 38
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 39
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 39
5.1. Normative References . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
5.2. Informative References . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 43 7.1. Normative References . . . . . . . . . . . . . . . . . . . 39
7.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 43 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 43
B.1. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 43 B.1. Version 10 (after AD review) . . . . . . . . . . . . . . . 43
B.2. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.2. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 43
B.3. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 44 B.3. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 44
B.4. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.4. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 44
B.5. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 45 B.5. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 45
B.6. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 45
B.7. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.7. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 45
B.8. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.8. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.9. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 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
skipping to change at page 5, line 38 skipping to change at page 5, line 38
adopting this architecture will be handled as separate and specific adopting this architecture will be handled as separate and specific
updates to these existing documents. Further, the scope of this text updates to these existing documents. Further, the scope of this text
is the internal homenet, and thus specific features on the WAN side is the internal homenet, and thus specific features on the WAN side
of the CER are out of scope for this text. of the CER are out of scope for this text.
1.1. Terminology and Abbreviations 1.1. Terminology and Abbreviations
In this section we define terminology and abbreviations used In this section we define terminology and abbreviations used
throughout the text. throughout the text.
o ALQDN: Ambiguous Locally Qualified Domain Name. An example would
be .sitelocal.
o Border: a point, typically resident on a router, between two o Border: a point, typically resident on a router, between two
networks, e.g. between the main internal homenet and a guest networks, e.g. between the main internal homenet and a guest
network. This defines point(s) at which filtering and forwarding network. This defines point(s) at which filtering and forwarding
policies for different types of traffic may be applied. policies for different types of traffic may be applied.
o CER: Customer Edge Router: A border router intended for use in a o CER: Customer Edge Router: A border router intended for use in a
homenet, which connects the homenet to a service provider network. homenet, which connects the homenet to a service provider network.
o FQDN: Fully Qualified Domain Name. A globally unique name space. o FQDN: Fully Qualified Domain Name. A globally unique name space.
skipping to change at page 6, line 26 skipping to change at page 6, line 22
o LLN: Low-power and lossy network. o LLN: Low-power and lossy network.
o LQDN: Locally Qualified Domain Name. A name space local to the o LQDN: Locally Qualified Domain Name. A name space local to the
homenet. homenet.
o NAT: Network Address Translation. Typically referring to IPv4 o NAT: Network Address Translation. Typically referring to IPv4
Network Address and Port Translation (NAPT) [RFC3022]. Network Address and Port Translation (NAPT) [RFC3022].
o NPTv6: Network Prefix Translation for IPv6 [RFC6296]. o NPTv6: Network Prefix Translation for IPv6 [RFC6296].
o PCP: Port Control Protocol [I-D.ietf-pcp-base]. o PCP: Port Control Protocol [RFC6887].
o Realm: a network delimited by a defined border. A guest network o Realm: a network delimited by a defined border. A guest network
within a homenet may form one realm. within a homenet may form one realm.
o 'Simple Security'. Defined in [RFC4864] and expanded further in o 'Simple Security'. Defined in [RFC4864] and expanded further in
[RFC6092]; describes recommended perimeter security capabilities [RFC6092]; describes recommended perimeter security capabilities
for IPv6 networks. for IPv6 networks.
o ULA: IPv6 Unique Local Addresses [RFC4193]. o ULA: IPv6 Unique Local Address [RFC4193].
o ULQDN: Unique Locally Qualified Domain Name. An example might be
.<UniqueString>.sitelocal.
o UPnP: Universal Plug and Play. Includes the Internet Gateway o UPnP: Universal Plug and Play. Includes the Internet Gateway
Device (IGD) function, which for IPv6 is UPnP IGD Version 2 Device (IGD) function, which for IPv6 is UPnP IGD Version 2
[IGD-2]. [IGD-2].
o VM: Virtual machine. o VM: Virtual machine.
o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance. o WPA2: Wi-Fi Protected Access, as defined by the Wi-Fi Alliance.
2. Effects of IPv6 on Home Networking 2. Effects of IPv6 on Home Networking
skipping to change at page 7, line 29 skipping to change at page 7, line 23
corporate extensions from the main Internet access network, or corporate extensions from the main Internet access network, or
different subnets may in general be associated with parts of the different subnets may in general be associated with parts of the
homenet that have different routing and security policies. Further, homenet that have different routing and security policies. Further,
link layer networking technology is poised to become more link layer networking technology is poised to become more
heterogeneous, as networks begin to employ both traditional Ethernet heterogeneous, as networks begin to employ both traditional Ethernet
technology and link layers designed for low-power and lossy networks technology and link layers designed for low-power and lossy networks
(LLNs), such as those used for certain types of sensor devices. (LLNs), such as those used for certain types of sensor devices.
Constraining the flow of certain traffic from Ethernet links to much Constraining the flow of certain traffic from Ethernet links to much
lower capacity links thus becomes an important topic. lower capacity links thus becomes an important topic.
The introduction of IPv6 for home networking enables the potential The introduction of IPv6 for home networking makes it possible for
for every home network to be delegated enough address space from its every home network to be delegated enough address space from its ISP
ISP to provision globally unique prefixes for each such subnet in the to provision globally unique prefixes for each such subnet in the
home. While the number of addresses in a standard /64 IPv6 prefix is home. While the number of addresses in a standard /64 IPv6 prefix is
practically infinite, the number of prefixes available for assignment practically unlimited, the number of prefixes available for
to the home network is not. As a result the growth inhibitor for the assignment to the home network is not. As a result the growth
home network shifts from the number of addresses to the number of inhibitor for the home network shifts from the number of addresses to
prefixes offered by the provider; this topic is discussed in the number of prefixes offered by the provider; this topic is
[RFC6177] (BCP 157), which recommends that "end sites always be able discussed in [RFC6177] (BCP 157), which recommends that "end sites
to obtain a reasonable amount of address space for their actual and always be able to obtain a reasonable amount of address space for
planned usage". their actual and 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 zero configuration service discovery to extend mechanisms such as zero configuration service discovery
which currently only operate within a single subnet using link-local which currently only operate within a single subnet using link-local
traffic. In a typical IPv4 home network, there is only one subnet, traffic. In a typical IPv4 home network, there is only one subnet,
so such mechanisms would normally operate as expected. For multi- so such mechanisms would normally operate as expected. For multi-
subnet IPv6 home networks there are two broad choices to enable such subnet IPv6 home networks there are two broad choices to enable such
protocols to work across the scope of the entire homenet; extend protocols to work across the scope of the entire homenet; extend
skipping to change at page 9, line 45 skipping to change at page 9, line 38
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
others may have both a GUA and a ULA. others may have both a GUA and a ULA.
Note that unlike private IPv4 RFC 1918 space, the use of ULAs does Note that unlike private IPv4 RFC 1918 space, the use of ULAs does
not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT not imply use of host-based IPv6 NAT, or NPTv6 prefix-based NAT
[RFC6296], rather that in an IPv6 homenet a node should use its ULA [RFC6296]. In an IPv6 homenet a node should only use its ULA address
address internally, and its additional globally unique IPv6 address internally, and use its additional globally unique IPv6 address as a
as a source address for external communications. By using such source address for external communications. By using such globally
globally unique addresses between hosts and devices in remote unique addresses between hosts and devices in remote networks, the
networks, the architectural cost and complexity, particularly to architectural cost and complexity, particularly to applications, of
applications, of NAT or NPTv6 translation is avoided. As such, NAT or NPTv6 translation is avoided. As such, neither IPv6 NAT or
neither IPv6 NAT or NPTv6 is recommended for use in the homenet 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 Devices in a homenet may be given only a ULA as a means to restrict
reachability from outside the homenet. ULAs can be used by default reachability from outside the homenet. ULAs can be used by default
for devices that, without additional configuration (e.g. via a web for devices that, without additional configuration (e.g. via a web
interface), would only offer services to the internal network. For interface), would only offer services to the internal network. For
example, a printer might only accept incoming connections on a ULA example, a printer might only accept incoming connections on a ULA
until configured to be globally reachable, at which point it acquires until configured to be globally reachable, at which point it acquires
a global IPv6 address and may be advertised via a global name space. a global IPv6 address and may be advertised via a global name space.
Where both a ULA and a global prefix are in use, the ULA source Where both a ULA and a global prefix are in use, the ULA source
skipping to change at page 11, line 46 skipping to change at page 11, line 38
The widespread availability of robust solutions to these types of The widespread availability of robust solutions to these types of
requirements will help accelerate the uptake of IPv6-only homenets. requirements will help accelerate the uptake of IPv6-only homenets.
The specifics of these are however beyond the scope of this document, The specifics of these are however beyond the scope of this document,
especially those functions that reside on the CER. especially those functions that reside on the CER.
3. Homenet Architecture 3. Homenet Architecture
The aim of this text is to outline how to construct advanced IPv6- The aim of this text is to outline how to construct advanced IPv6-
based home networks involving multiple routers and subnets using based home networks involving multiple routers and subnets using
standard IPv6 protocols and addressing [RFC2460] [RFC4291]. In this standard IPv6 addressing and protocols [RFC2460] [RFC4291]. In this
section, we present the elements of the proposed home networking section, we present the elements of the proposed home networking
architecture, with discussion of the associated design principles. architecture, with discussion of the associated design principles.
In general, home network equipment needs to be able to operate in In general, home network equipment needs to be able to operate in
networks with a range of different properties and topologies, where networks with a range of different properties and topologies, where
home users may plug components together in arbitrary ways and expect home users may plug components together in arbitrary ways and expect
the resulting network to operate. Significant manual configuration the resulting network to operate. Significant manual configuration
is rarely, if at all, possible, or even desirable given the knowledge is rarely, if at all, possible, or even desirable given the knowledge
level of typical home users. Thus the network should, as far as level of typical home users. Thus the network should, as far as
possible, be self-configuring, though configuration by advanced users possible, be self-configuring, though configuration by advanced users
skipping to change at page 18, line 15 skipping to change at page 17, line 16
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 |
+---------+---------+ \ +---------+---------+ \
| IPv6 | \ | IPv6 | \
| Customer Edge | \ | Customer Edge | \
| Router | / | Router | /
+---------+---------+ / +---------+---------+ /
| / | /
| | End-User | | End-User
---+------------+-------+--------+-------------+--- | network(s) ---+------------+-------+--------+-------------+--- | network(s)
| | | | \ | | | | \
+----+-----+ +----+-----+ +----+-----+ +-----+----+ \ +----+-----+ +----+-----+ +----+-----+ +-----+----+ \
skipping to change at page 19, line 40 skipping to change at page 18, line 43
In the general homenet architecture, multihomed hosts should be In the general homenet architecture, multihomed hosts should be
multi-addressed with a global IPv6 address from the global prefix multi-addressed with a global IPv6 address from the global prefix
delegated from each ISP they communicate with or through. When such delegated from each ISP they communicate with or through. When such
multi-addressing is in use, hosts need some way to pick source and multi-addressing is in use, hosts need some way to pick source and
destination address pairs for connections. A host may choose a destination address pairs for connections. A host may choose a
source address to use by various methods, most commonly [RFC6724]. source address to use by various methods, most commonly [RFC6724].
Applications may of course do different things, and this should not Applications may of course do different things, and this should not
be precluded. be precluded.
For the single CER Network Model C illustrated above, multihoming may For the single CER Network Model C illustrated above, multihoming may
be offered by source routing at the CER. With multiple exit routers, be offered by source-based routing at the CER. With multiple exit
as in CER Network Model B, the complexity rises. Given a packet with routers, as in CER Network Model B, the complexity rises. Given a
a source address on the home network, the packet must be routed to packet with a source address on the home network, the packet must be
the proper egress to avoid BCP 38 filtering if exiting through the routed to the proper egress to avoid BCP 38 filtering if exiting
wrong ISP. It is highly desirable that the packet is routed in the through the wrong ISP. It is highly desirable that the packet is
most efficient manner to the correct exit, though as a minimum routed in the most efficient manner to the correct exit, though as a
requirement the packet should not be dropped. minimum requirement the packet should not be dropped.
The homenet architecture should support both the above models, i.e. The homenet architecture should support both the above models, i.e.
one or more CERs. However, the general multihoming problem is broad, one or more CERs. However, the general multihoming problem is broad,
and solutions suggested to date within the IETF have included complex and solutions suggested to date within the IETF have included complex
architectures for monitoring connectivity, traffic engineering, architectures for monitoring connectivity, traffic engineering,
identifier-locator separation, connection survivability across identifier-locator separation, connection survivability across
multihoming events, and so on. It is thus important that the homenet multihoming events, and so on. It is thus important that the homenet
architecture should as far as possible minimise the complexity of any architecture should as far as possible minimise the complexity of any
multihoming support. multihoming support.
An example of such a 'simpler' approach has been documented in An example of such a 'simpler' approach has been documented in
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. Alternatively a
flooding/routing protocol could potentially be used to pass flooding/routing protocol could potentially be used to pass
information through the homenet, such that internal routers and information through the homenet, such that internal routers and
ultimately end hosts could learn per-prefix configuration ultimately end hosts could learn per-prefix configuration
information, allowing better address selection decisions to be made. information, allowing better address selection decisions to be made.
However, this would imply router and, most likely, host changes. However, this would imply router and, most likely, host changes.
Another avenue is to introduce support for source routing throughout Another avenue is to introduce support throughout the homenet for
the homenet; while greatly improving the 'intelligence' of routing routing which is based on the source as well as the destination
decisions within the homenet, such an approach would require address of each packet. While greatly improving the 'intelligence'
relatively significant router changes but avoid host changes. of routing decisions within the homenet, such an approach would
require relatively significant router changes but avoid host changes.
As explained previously, while NPTv6 has been proposed for providing As explained previously, while NPTv6 has been proposed for providing
multi-homing support in networks, its use is not recommended in the multi-homing support in networks, its use is not recommended in the
homenet architecture. homenet architecture.
It should be noted that some multihoming scenarios may see one It should be noted that some multihoming scenarios may see one
upstream being a "walled garden", and thus only appropriate for upstream being a "walled garden", and thus only appropriate for
connectivity to the services of that provider; an example may be a connectivity to the services of that provider; an example may be a
VPN service that only routes back to the enterprise business network VPN service that only routes back to the enterprise business network
of a user in the homenet. While we should not specifically target of a user in the homenet. While we should not specifically target
skipping to change at page 22, line 45 skipping to change at page 21, line 50
A homenet will most likely also have internal borders between A homenet will most likely also have internal borders between
internal realms, e.g. a guest realm or a corporate network extension internal realms, e.g. a guest realm or a corporate network extension
realm. It should be possible to automatically discover these realm. It should be possible to automatically discover these
borders, which will determine, for example, the scope of where borders, which will determine, for example, the scope of where
network prefixes, routing information, network traffic, service network prefixes, routing information, network traffic, service
discovery and naming may be shared. The default mode internally discovery and naming may be shared. The default mode internally
should be to share everything. should be to share everything.
It is expected that a realm would span at least an entire subnet, and It is expected that a realm would span at least an entire subnet, and
thus the borders lie at routers which receive delegated prefixes thus the borders lie at routers which receive delegated prefixes
within the homenet. It is also desirable for a richer security model within the homenet. It is also desirable, for a richer security
that hosts, which may be running in a transparent communication mode, model, that hosts are able to make communication decisions based on
are able to make communication decisions based on available realm and available realm and associated prefix information in the same way
associated prefix information in the same way that routers at realm that routers at realm borders can.
borders can.
A simple homenet model may just consider three types of realm and the A simple homenet model may just consider three types of realm and the
borders between them, namely the internal homenet, the ISP and a borders between them, namely the internal homenet, the ISP and a
guest network. In this case the borders will include that from the guest network. In this case the borders will include that from the
homenet to the ISP, that from the guest network to the ISP, and that homenet to the ISP, that from the guest network to the ISP, and that
from the homenet to the guest network. Regardless, it should be from the homenet to the guest network. Regardless, it should be
possible for additional types of realms and borders to be defined, possible for additional types of realms and borders to be defined,
e.g. for some specific Grid or LLN-based network, and for these to be e.g. for some specific Grid or LLN-based network, and for these to be
detected automatically, and for an appropriate default policy to be detected automatically, and for an appropriate default policy to be
applied as to what type of traffic/data can flow across such borders. applied as to what type of traffic/data can flow across such borders.
skipping to change at page 24, line 10 skipping to change at page 23, line 13
However, if, for example, only a /64 is offered by the ISP, the However, if, for example, only a /64 is offered by the ISP, the
homenet may be severely constrained or even unable to function. homenet may be severely constrained or even unable to function.
[RFC6177] (BCP 157) states that "a key principle for address [RFC6177] (BCP 157) states that "a key principle for address
management is that end sites always be able to obtain a reasonable management is that end sites always be able to obtain a reasonable
amount of address space for their actual and planned usage, and over amount of address space for their actual and planned usage, and over
time ranges specified in years rather than just months. In practice, time ranges specified in years rather than just months. In practice,
that means at least one /64, and in most cases significantly more. that means at least one /64, and in most cases significantly more.
One particular situation that must be avoided is having an end site One particular situation that must be avoided is having an end site
feel compelled to use IPv6-to-IPv6 Network Address Translation or feel compelled to use IPv6-to-IPv6 Network Address Translation or
other burdensome address conservation techniques because it could not other burdensome address conservation techniques because it could not
get sufficient address space." This architecture text assumes that get sufficient address space." This architecture document assumes
this guidance is being followed by ISPs. that the guidance in the quoted text is being followed by ISPs.
There are many problems that would arise from a homenet not being There are many problems that would arise from a homenet not being
offered a sufficient prefix size for its needs. Rather than attempt offered a sufficient prefix size for its needs. Rather than attempt
to contrive a method for a homenet to operate in a constrained manner to contrive a method for a homenet to operate in a constrained manner
when faced with insufficient prefixes, such as the use of subnet when faced with insufficient prefixes, such as the use of subnet
prefixes longer than /64 (which would break SLAAC), use of NPTv6, or prefixes longer than /64 (which would break SLAAC), use of NPTv6, or
falling back to bridging across potentially very different media, it falling back to bridging across potentially very different media, it
is recommended that the receiving router instead enters an error is recommended that the receiving router instead enters an error
state and issues appropriate warnings. Some consideration may need state and issues appropriate warnings. Some consideration may need
to be given to how such a warning or error state should best be to be given to how such a warning or error state should best be
skipping to change at page 28, line 28 skipping to change at page 27, line 30
3.5. Routing functionality 3.5. Routing functionality
Routing functionality is required when there are multiple routers Routing functionality is required when there are multiple routers
deployed within the internal home network. This functionality could deployed within the internal home network. This functionality could
be as simple as the current 'default route is up' model of IPv4 NAT, be as simple as the current 'default route is up' model of IPv4 NAT,
or, more likely, it would involve running an appropriate routing or, more likely, it would involve running an appropriate routing
protocol. Regardless of the solution method, the functionality protocol. Regardless of the solution method, the functionality
discussed below should be met. discussed below should be met.
The homenet unicast routing protocol should be a previously deployed The homenet unicast routing protocol should be based on a previously
protocol that has been shown to be reliable, robust, to allow deployed protocol that has been shown to be reliable, robust, to
lightweight implementations, and of which open source implementations allow lightweight implementations, and of which open source
are available. It is desirable, but not absolutely required, that implementations are available. It is desirable, but not absolutely
the routing protocol be able to give a complete view of the network, required, that the routing protocol be able to give a complete view
and that it be able to pass around more than just routing of the network, and that it be able to pass around more than just
information. 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 31, line 8 skipping to change at page 30, line 11
reachable. reachable.
[RFC4864] describes a 'Simple Security' model for IPv6 networks, [RFC4864] describes a 'Simple Security' model for IPv6 networks,
whereby stateful perimeter filtering can be applied to control the whereby stateful perimeter filtering can be applied to control the
reachability of devices in a homenet. RFC 4864 states in Section 4.2 reachability of devices in a homenet. RFC 4864 states in Section 4.2
that "the use of firewalls ... is recommended for those that want that "the use of firewalls ... is recommended for those that want
boundary protection in addition to host defences". It should be boundary protection in addition to host defences". It should be
noted that a 'default deny' filtering approach would effectively noted that a 'default deny' filtering approach would effectively
replace the need for IPv4 NAT traversal protocols with a need to use replace the need for IPv4 NAT traversal protocols with a need to use
a signalling protocol to request a firewall hole be opened, e.g. a a signalling protocol to request a firewall hole be opened, e.g. a
protocol such as UPnP or PCP [I-D.ietf-pcp-base]. In networks with protocol such as UPnP or PCP [RFC6887]. In networks with multiple
multiple CERs, the signalling would need to handle the cases of flows CERs, the signalling would need to handle the cases of flows that may
that may use one or more exit routers. CERs would need to be able to use one or more exit routers. CERs would need to be able to
advertise their existence for such protocols. advertise their existence for such protocols.
[RFC6092] expands on RFC 4864, giving a more detailed discussion of [RFC6092] expands on RFC 4864, giving a more detailed discussion of
IPv6 perimeter security recommendations, without mandating a 'default IPv6 perimeter security recommendations, without mandating a 'default
deny' approach. Indeed, RFC 6092 does not enforce a particular mode deny' approach. Indeed, RFC 6092 does not enforce a particular mode
of operation, instead stating that CERs must provide an easily of operation, instead stating that CERs must provide an easily
selected configuration option that permits a 'transparent' mode, thus selected configuration option that permits a 'transparent' mode, thus
ensuring a 'default allow' model is available. The homenet ensuring a 'default allow' model is available. The homenet
architecture text makes no recommendation on the default setting, and architecture text makes no recommendation on the default setting, and
refers the reader to RFC 6092. refers the reader to RFC 6092.
skipping to change at page 35, line 7 skipping to change at page 34, line 12
If however a global name space is not available, the homenet will If however a global name space is not available, the homenet will
need to pick and use a local name space which would only have meaning need to pick and use a local name space which would only have meaning
within the local homenet (i.e. it would not be used for remote access within the local homenet (i.e. it would not be used for remote 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 space, such as .sitelocal (or an
appropriate name reserved for the purpose). While this is a simple appropriate name reserved for the purpose). While this is a simple
approach, there is the potential in principle for devices that are approach, there is the potential in principle for devices that are
bookmarked somehow by name by an application in one homenet to be bookmarked somehow by name by an application in one homenet to be
confused with a device with the same name in another homenet. In confused with a device with the same name in another homenet. In
practice however the underlying service discovery protocols should be practice however the underlying service discovery protocols should be
capable of handling moving to a network where a new device is using capable of handling moving to a network where a new device is using
the same name as a device used previously in another homenet. the same name as a device used previously in another homenet.
An alternative approach for a local name space would be to use a An alternative approach for a local name space would be to use a
Unique Locally Qualified Domain Name (ULQDN) space such as Unique Locally Qualified Domain Name space such as
.<UniqueString>.sitelocal. The <UniqueString> could be generated in .<UniqueString>.sitelocal. The <UniqueString> could be generated in
a variety of ways, one potentially being based on the local /48 ULA a variety of ways, one potentially being based on the local /48 ULA
prefix being used across the homenet. Such a <UniqueString> should prefix being used across the homenet. Such a <UniqueString> should
survive a cold restart, i.e. be consistent after a network power- survive a cold restart, i.e. be consistent after a network power-
down, or, if a value is not set on startup, the CER or device running down, or, if a value is not set on startup, the CER or device running
the name service should generate a default value. It would be the name service should generate a default value. It would be
desirable for the homenet user to be able to override the desirable for the homenet user to be able to override the
<UniqueString> with a value of their choice, but that would increase <UniqueString> with a value of their choice, but that would increase
the likelihood of a name conflict. the likelihood of a name conflict.
skipping to change at page 40, line 5 skipping to change at page 39, line 13
ability to turn on routing, prefix delegation and other functions in ability to turn on routing, prefix delegation and other functions in
a backwards compatible manner. a backwards compatible manner.
4. Conclusions 4. Conclusions
This text defines principles and requirements for a homenet This text defines principles and requirements for a homenet
architecture. The principles and requirements documented here should architecture. The principles and requirements documented here should
be observed by any future texts describing homenet protocols for be observed by any future texts describing homenet protocols for
routing, prefix management, security, naming or service discovery. routing, prefix management, security, naming or service discovery.
5. References 5. Security Considerations
5.1. Normative References Security considerations for the homenet architecture are discussed in
Section 3.6 above.
6. IANA Considerations
This document has no actions for IANA.
7. References
7.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
skipping to change at page 40, line 29 skipping to change at page 40, line 5
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 7.2. Informative References
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
5.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 5, RFC 1918, February 1996. BCP 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,
skipping to change at page 41, line 20 skipping to change at page 40, line 37
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[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.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
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 5969, August 2010. RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
skipping to change at page 42, line 26 skipping to change at page 41, line 50
"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.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address Wing, "IPv6 Multihoming without Network Address
Translation", Translation",
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 (work draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 (work
in progress), March 2013. in progress), March 2013.
[I-D.ietf-ospf-ospfv3-autoconfig] [I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress), draft-ietf-ospf-ospfv3-autoconfig-02 (work in progress),
April 2013. April 2013.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-29 (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.
[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>.
skipping to change at page 43, line 32 skipping to change at page 43, line 9
comments and contributions within homenet WG meetings and on the WG comments and contributions within homenet WG meetings and on the WG
mailing list. An acknowledgement generally means that person's text mailing list. An acknowledgement generally means that person's text
made it in to the document, or was helpful in clarifying or made it in to the document, or was helpful in clarifying or
reinforcing an aspect of the document. It does not imply that each reinforcing an aspect of the document. It does not imply that each
controbutor agrees with every point in the document. 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 09 (after WGLC) B.1. Version 10 (after AD review)
Changes made include:
o Minor changes/clarifications resulting from AD review
B.2. Version 09 (after WGLC)
Changes made include: Changes made include:
o Added note about multicast into or out of site o Added note about multicast into or out of site
o Removed further personal draft references, replaced with covering o Removed further personal draft references, replaced with covering
text text
o Routing functionality text updated to avoid ambiguity o Routing functionality text updated to avoid ambiguity
skipping to change at page 44, line 21 skipping to change at page 44, line 5
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.2. Version 08 B.3. Version 08
Changes made include: Changes made include:
o Various clarifications made in response to list comments o Various clarifications made in response to list comments
o Added note on ULAs with IPv4, where no GUAs in use o Added note on ULAs with IPv4, where no GUAs in use
o Added note on naming and internationalisation (IDNA) o Added note on naming and internationalisation (IDNA)
o Added note on trust relationships when adding devices o Added note on trust relationships when adding devices
o Added note for MPTCP o Added note for MPTCP
o Added various naming and SD notes o Added various naming and SD notes
o Added various notes on delegated ISP prefixes o Added various notes on delegated ISP prefixes
B.3. Version 07 B.4. Version 07
Changes made include: Changes made include:
o Removed reference to NPTv6 in section 3.2.4. Instead now say it o Removed reference to NPTv6 in section 3.2.4. Instead now say it
has an architectural cost to use in the earlier section, and thus has an architectural cost to use in the earlier section, and thus
it is not recommended for use in the homenet architecture. it is not recommended for use in the homenet architecture.
o Removed 'proxy or extend?' section. Included shorter text in main o Removed 'proxy or extend?' section. Included shorter text in main
body, without mandating either approach for service discovery. body, without mandating either approach for service discovery.
skipping to change at page 45, line 28 skipping to change at page 45, line 12
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.4. Version 06 B.5. 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.5. Version 05 B.6. 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.6. Version 04 B.7. 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.7. Version 03 B.8. Version 03
Changes made include: Changes made include:
o Various improvements to the readability. o Various improvements to the readability.
o Removed bullet lists of requirements, as requested by chair. o Removed bullet lists of requirements, as requested by chair.
o Noted 6204bis has replaced advanced-cpe draft. o Noted 6204bis has replaced advanced-cpe draft.
o Clarified the topology examples are just that. o Clarified the topology examples are just that.
skipping to change at page 47, line 36 skipping to change at page 47, line 20
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.8. Version 02 B.9. 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. 45 change blocks. 
132 lines changed or deleted 142 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/