draft-ietf-homenet-arch-11.txt   draft-ietf-homenet-arch-12.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: April 25, 2014 Ericsson Expires: August 18, 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
October 22, 2013 February 14, 2014
IPv6 Home Networking Architecture Principles IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-11 draft-ietf-homenet-arch-12
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
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 April 25, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29
3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30 3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6.1. Addressability vs reachability . . . . . . . . . . . . 31 3.6.1. Addressability vs reachability . . . . . . . . . . . . 31
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 31 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 31
3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32 3.6.3. Partial Effectiveness of NAT and Firewalls . . . . . . 32
3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 32 3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 32
3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 32 3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 33
3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33 3.6.6. ULAs as a hint of connection origin . . . . . . . . . 33
3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 33 3.7. Naming and Service Discovery . . . . . . . . . . . . . . . 33
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34
3.7.3. The homenet name service . . . . . . . . . . . . . . . 35 3.7.3. The homenet name service . . . . . . . . . . . . . . . 35
3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36 3.7.4. Name spaces . . . . . . . . . . . . . . . . . . . . . 36
3.7.5. Independent operation . . . . . . . . . . . . . . . . 38 3.7.5. Independent operation . . . . . . . . . . . . . . . . 38
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 38 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 38
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 38 3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 39
3.7.8. Devices roaming to/from the homenet . . . . . . . . . 39 3.7.8. Devices roaming to/from the homenet . . . . . . . . . 39
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 39 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 39
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 39 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 39
3.8.2. Operations and Management . . . . . . . . . . . . . . 39 3.8.2. Operations and Management . . . . . . . . . . . . . . 40
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 40 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 41
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Normative References . . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . . 42 7.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 44 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 45
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 45
B.1. Version 11 (after IESG review) . . . . . . . . . . . . . . 45 B.1. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.2. Version 10 (after AD review) . . . . . . . . . . . . . . . 45 B.2. Version 11 (after IESG review) . . . . . . . . . . . . . . 46
B.3. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 45 B.3. Version 10 (after AD review) . . . . . . . . . . . . . . . 46
B.4. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.4. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 46
B.5. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 47
B.6. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.6. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 47
B.7. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.8. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.8. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.9. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.9. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.10. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.10. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 B.11. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
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 20 skipping to change at page 5, line 20
considerations for IPv4 impact would not apply. considerations for IPv4 impact would not apply.
This document proposes a baseline homenet architecture, using This document proposes a baseline homenet architecture, using
protocols and implementations that are as far as possible proven and protocols and implementations that are as far as possible proven and
robust. The scope of the document is primarily the network layer robust. The scope of the document is primarily the network layer
technologies that provide the basic functionality to enable technologies that provide the basic functionality to enable
addressing, connectivity, routing, naming and service discovery. addressing, connectivity, routing, naming and service discovery.
While it may, for example, state that homenet components must be While it may, for example, state that homenet components must be
simple to deploy and use, it does not discuss specific user simple to deploy and use, it does not discuss specific user
interfaces, nor does it discuss specific physical, wireless or data- interfaces, nor does it discuss specific physical, wireless or data-
link layer considerations. link layer considerations. Likewise, we also do not specify the
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
scope, we're assuming a data link layer that supports IPv6 is
present, and that we react accordingly. Any IPv6-over-Foo
definitions occur elsewhere.
[RFC6204] defines basic requirements for customer edge routers [RFC6204] defines basic requirements for customer edge routers
(CERs). This document has recently been updated with the definition (CERs). This document has recently been updated with the definition
of requirements for specific transition tools on the CER in of requirements for specific transition tools on the CER in
[I-D.ietf-v6ops-6204bis], specifically DS-Lite [RFC6333] and 6rd [RFC7084], specifically DS-Lite [RFC6333] and 6rd [RFC5969]. Such
[RFC5969]. Such detailed specification of CER devices is considered detailed specification of CER devices is considered out of scope of
out of scope of this architecture document, and we assume that any this architecture document, and we assume that any required update of
required update of the CER device specification as a result of the CER device specification as a result of adopting this
adopting this architecture will be handled as separate and specific architecture will be handled as separate and specific updates to
updates to these existing documents. Further, the scope of this text these existing documents. Further, the scope of this text is the
is the internal homenet, and thus specific features on the WAN side internal homenet, and thus specific features on the WAN side of the
of the CER are out of scope for this text. CER are out of scope for this text.
1.1. Terminology and Abbreviations 1.1. Terminology and Abbreviations
In this section we define terminology and abbreviations used In this section we define terminology and abbreviations used
throughout the text. throughout the text.
o Border: a point, typically resident on a router, between two o Border: a point, typically resident on a router, between two
networks, e.g., between the main internal homenet and a guest networks, e.g., between the main internal homenet and a guest
network. This defines point(s) at which filtering and forwarding network. This defines point(s) at which filtering and forwarding
policies for different types of traffic may be applied. policies for different types of traffic may be applied.
skipping to change at page 11, line 20 skipping to change at page 11, line 21
It is likely that IPv6-only networking will be deployed first in new It is likely that IPv6-only networking will be deployed first in new
home network deployments, often refered to as 'greenfield' scenarios, home network deployments, often refered to as 'greenfield' scenarios,
where there is no existing IPv4 capability, or perhaps as one element where there is no existing IPv4 capability, or perhaps as one element
of an otherwise dual-stack network. Running IPv6-only adds of an otherwise dual-stack network. Running IPv6-only adds
additional requirements, e.g., for devices to get configuration additional requirements, e.g., for devices to get configuration
information via IPv6 transport (not relying on an IPv4 protocol such information via IPv6 transport (not relying on an IPv4 protocol such
as IPv4 DHCP), and for devices to be able to initiate communications as IPv4 DHCP), and for devices to be able to initiate communications
to external devices that are IPv4-only. to external devices that are IPv4-only.
Some specific transition technologies which may be deployed by the Some specific transition technologies which may be deployed by the
homenet's ISP are discussed in [I-D.ietf-v6ops-6204bis]. In homenet's ISP are discussed in [RFC1918]. In addition, certain other
addition, certain other functions may be desirable on the CER, e.g., functions may be desirable on the CER, e.g., to access content in the
to access content in the IPv4 Internet, NAT64 [RFC6144] and DNS64 IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable.
[RFC6145] may be applicable.
The widespread availability of robust solutions to these types of The widespread availability of robust solutions to these types of
requirements will help accelerate the uptake of IPv6-only homenets. requirements will help accelerate the uptake of IPv6-only homenets.
The specifics of these are however beyond the scope of this document, The specifics of these are however beyond the scope of this document,
especially those functions that reside on the CER. especially those functions that reside on the CER.
3. Homenet Architecture Principles 3. Homenet Architecture Principles
The aim of this text is to outline how to construct advanced IPv6- The aim of this text is to outline how to construct advanced IPv6-
based home networks involving multiple routers and subnets using based home networks involving multiple routers and subnets using
skipping to change at page 13, line 42 skipping to change at page 13, line 42
The topology of the homenet may change over time, due to the addition The topology of the homenet may change over time, due to the addition
or removal of equipment, but also due to temporary failures or or removal of equipment, but also due to temporary failures or
connectivity problems. In some cases this may lead to, for example, connectivity problems. In some cases this may lead to, for example,
a multihomed homenet being split into two isolated homenets, or, a multihomed homenet being split into two isolated homenets, or,
after such a fault is remedied, two isolated parts reconfiguring back after such a fault is remedied, two isolated parts reconfiguring back
to a single network. to a single network.
3.2.2. Network topology models 3.2.2. Network topology models
As hinted above, while the architecture may focus on likely common
topologies, it should not preclude any arbitrary topology from being
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 [RFC6204]
and its successor [I-D.ietf-v6ops-6204bis] should, as a minimum, be and its successor [RFC7084] should, as a minimum, be supported.
supported.
There are a number of properties or attributes of a home network that There are a number of properties or attributes of a home network that
we can use to describe its topology and operation. The following we can use to describe its topology and operation. The following
properties apply to any IPv6 home network: properties apply to any IPv6 home network:
o Presence of internal routers. The homenet may have one or more o Presence of internal routers. The homenet may have one or more
internal routers, or may only provide subnetting from interfaces internal routers, or may only provide subnetting from interfaces
on the CER. on the CER.
o Presence of isolated internal subnets. There may be isolated o Presence of isolated internal subnets. There may be isolated
skipping to change at page 18, line 36 skipping to change at page 18, line 36
|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 3 Figure 3
Figure 3 illustrates a model where a home network may have multiple Figure 3 illustrates a model where a home network may have multiple
connections to multiple providers or multiple logical connections to connections to multiple providers or multiple logical connections to
the same provider, with shared internal subnets. the same provider, with shared internal subnets.
In general, while the architecture may focus on likely common
topologies, it should not preclude any arbitrary topology from being
constructed.
3.2.3. Dual-stack topologies 3.2.3. Dual-stack topologies
It is expected that most homenet deployments will for the immediate It is expected that most homenet deployments will for the immediate
future be dual-stack IPv4/IPv6. In such networks it is important not future be dual-stack IPv4/IPv6. In such networks it is important not
to introduce new IPv6 capabilities that would cause a failure if used to introduce new IPv6 capabilities that would cause a failure if used
alongside IPv4+NAT, given that such dual-stack homenets will be alongside IPv4+NAT, given that such dual-stack homenets will be
commonplace for some time. That said, it is desirable that IPv6 commonplace for some time. That said, it is desirable that IPv6
works better than IPv4 in as many scenarios as possible. Further, works better than IPv4 in as many scenarios as possible. Further,
the homenet architecture must operate in the absence of IPv4. the homenet architecture must operate in the absence of IPv4.
skipping to change at page 21, line 4 skipping to change at page 20, line 48
The home network infrastructure should be naturally self-organising The home network infrastructure should be naturally self-organising
and self-configuring under different circumstances relating to the and self-configuring under different circumstances relating to the
connectivity status to the Internet, number of devices, and physical connectivity status to the Internet, number of devices, and physical
topology. At the same time, it should be possible for advanced users topology. At the same time, it should be possible for advanced users
to manually adjust (override) the current configuration. to manually adjust (override) the current configuration.
While a goal of the homenet architecture is for the network to be as While a goal of the homenet architecture is for the network to be as
self-organising as possible, there may be instances where some manual self-organising as possible, there may be instances where some manual
configuration is required, e.g., the entry of a cryptographic key to configuration is required, e.g., the entry of a cryptographic key to
apply wireless security, or to configure a shared routing secret. apply wireless security, or to configure a shared routing secret.
The latter may be relevant when considering how to bootstrap a The latter may be relevant when considering how to bootstrap a
routing configuration. It is highly desirable that the number of routing configuration. It is highly desirable that the number of
such configurations is minimised. such configurations is minimised.
3.3.1. Differentiating neighbouring homenets 3.3.1. Differentiating neighbouring homenets
It is important that self-configuration with 'unintended' devices is It is important that self-configuration with 'unintended' devices is
avoided. There should be a way for a user to administratively assert avoided. There should be a way for a user to administratively assert
in a simple way whether or not a device belongs to a homenet. The in a simple way whether or not a device belongs to a given homenet.
goal is to allow the establishment of borders, particularly between The goal is to allow the establishment of borders, particularly
two adjacent homenets, and to avoid unauthorised devices from between two adjacent homenets, and to avoid unauthorised devices from
participating in the homenet. Such an authorisation capability may participating in the homenet. Such an authorisation capability may
need to operate through multiple hops in the homenet. need to operate through multiple hops in the homenet.
The homenet should thus support a way for a homenet owner to claim The homenet should thus support a way for a homenet owner to claim
ownership of their devices in a reasonably secure way. This could be ownership of their devices in a reasonably secure way. This could be
achieved by a pairing mechanism, by for example pressing buttons achieved by a pairing mechanism, by for example pressing buttons
simultaneously on an authenticated and a new homenet device, or by an simultaneously on an authenticated and a new homenet device, or by an
enrolment process as part of an autonomic networking environment. enrolment process as part of an autonomic networking environment.
While there may be scenarios where one homenet may wish to
intentionally gain access through another, e.g. to share external
connectivity costs, such scenarios are not discussed in this
document.
3.3.2. Largest practical subnets 3.3.2. Largest practical subnets
Today's IPv4 home networks generally have a single subnet, and early Today's IPv4 home networks generally have a single subnet, and early
dual-stack deployments have a single congruent IPv6 subnet, possibly dual-stack deployments have a single congruent IPv6 subnet, possibly
with some bridging functionality. More recently, some vendors have with some bridging functionality. More recently, some vendors have
started to introduce 'home' and 'guest' functions, which in IPv6 started to introduce 'home' and 'guest' functions, which in IPv6
would be implemented as two subnets. would be implemented as two subnets.
Future home networks are highly likely to have one or more internal Future home networks are highly likely to have one or more internal
routers and thus need multiple subnets, for the reasons described routers and thus need multiple subnets, for the reasons described
skipping to change at page 22, line 38 skipping to change at page 22, line 38
3.3.4. Homenet realms and borders 3.3.4. Homenet realms and borders
The homenet will need to be aware of the extent of its own 'site', The homenet will need to be aware of the extent of its own 'site',
which will, for example, define the borders for ULA and site scope which will, for example, define the borders for ULA and site scope
multicast traffic, and may require specific security policies to be multicast traffic, and may require specific security policies to be
applied. The homenet will have one or more such borders with applied. The homenet will have one or more such borders with
external connectivity providers. external connectivity providers.
A homenet will most likely also have internal borders between A homenet will most likely also have internal borders between
internal realms, e.g., a guest realm or a corporate network extension internal realms, e.g., a guest realm or a corporate network extension
realm. It should be possible to automatically discover these realm. It is desirable that appropriate borders can be configured to
borders, which will determine, for example, the scope of where determine, for example, the scope of where network prefixes, routing
network prefixes, routing information, network traffic, service information, network traffic, service discovery and naming may be
discovery and naming may be shared. The default mode internally shared. The default mode internally should be to share everything.
should be to share everything.
It is expected that a realm would span at least an entire subnet, and It is expected that a realm would span at least an entire subnet, and
thus the borders lie at routers which receive delegated prefixes thus the borders lie at routers which receive delegated prefixes
within the homenet. It is also desirable, for a richer security within the homenet. It is also desirable, for a richer security
model, that hosts are able to make communication decisions based on model, that hosts are able to make communication decisions based on
available realm and associated prefix information in the same way available realm and associated prefix information in the same way
that routers at realm borders can. that routers at realm borders can.
A simple homenet model may just consider three types of realm and the A simple homenet model may just consider three types of realm and the
borders between them, namely the internal homenet, the ISP and a borders between them, namely the internal homenet, the ISP and a
skipping to change at page 23, line 33 skipping to change at page 23, line 32
It should be possible for the homenet user to override any It should be possible for the homenet user to override any
automatically determined borders and the default policies applied automatically determined borders and the default policies applied
between them, the exception being that it may not be possible to between them, the exception being that it may not be possible to
override policies defined by the ISP at the external border. override policies defined by the ISP at the external border.
3.3.5. Configuration information from the ISP 3.3.5. Configuration information from the ISP
In certain cases, it may be useful for the homenet to get certain In certain cases, it may be useful for the homenet to get certain
configuration information from its ISP. For example, the homenet configuration information from its ISP. For example, the homenet
DHCP server may request and forward some options that it gets from DHCP server may request and forward some options that it gets from
its upstream DHCP server, though the specific of the options may vary its upstream DHCP server, though the specifics of the options may
across deployments. There is potential complexity here of course vary across deployments. There is potential complexity here of
should the homenet be multihomed. course should the homenet be multihomed.
3.4. Homenet Addressing 3.4. Homenet Addressing
The IPv6 addressing scheme used within a homenet must conform to the The IPv6 addressing scheme used within a homenet must conform to the
IPv6 addressing architecture [RFC4291]. In this section we discuss IPv6 addressing architecture [RFC4291]. In this section we discuss
how the homenet needs to adapt to the prefixes made available to it how the homenet needs to adapt to the prefixes made available to it
by its upstream ISP, such that internal subnets, hosts and devices by its upstream ISP, such that internal subnets, hosts and devices
can obtain the and configure the necessary addressing information to can obtain the and configure the necessary addressing information to
operate. operate.
skipping to change at page 24, line 28 skipping to change at page 24, line 27
feel compelled to use IPv6-to-IPv6 Network Address Translation or feel compelled to use IPv6-to-IPv6 Network Address Translation or
other burdensome address conservation techniques because it could not other burdensome address conservation techniques because it could not
get sufficient address space." This architecture document assumes get sufficient address space." This architecture document assumes
that the guidance in the quoted text is being followed by ISPs. that the guidance in the quoted text is being followed by ISPs.
There are many problems that would arise from a homenet not being There are many problems that would arise from a homenet not being
offered a sufficient prefix size for its needs. Rather than attempt offered a sufficient prefix size for its needs. Rather than attempt
to contrive a method for a homenet to operate in a constrained manner to contrive a method for a homenet to operate in a constrained manner
when faced with insufficient prefixes, such as the use of subnet when faced with insufficient prefixes, such as the use of subnet
prefixes longer than /64 (which would break stateless address prefixes longer than /64 (which would break stateless address
autonfiguration [RFC4862]), use of NPTv6, or falling back to bridging autoconfiguration [RFC4862]), use of NPTv6, or falling back to
across potentially very different media, it is recommended that the bridging across potentially very different media, it is recommended
receiving router instead enters an error state and issues appropriate that the receiving router instead enters an error state and issues
warnings. Some consideration may need to be given to how such a appropriate warnings. Some consideration may need to be given to how
warning or error state should best be presented to a typical home such a warning or error state should best be presented to a typical
user. home user.
Thus a homenet CER should request, for example via DHCP Prefix Thus a homenet CER should request, for example via DHCP Prefix
Delegation (DHCP PD) [RFC3633], that it would like a /48 prefix from Delegation (DHCP PD) [RFC3633], that it would like a /48 prefix from
its ISP, i.e., it asks the ISP for the maximum size prefix it might its ISP, i.e., it asks the ISP for the maximum size prefix it might
expect to be offered, even if in practice it may only be offered a expect to be offered, even if in practice it may only be offered a
/56 or /60. For a typical IPv6 homenet, it is not recommended that /56 or /60. For a typical IPv6 homenet, it is not recommended that
an ISP offer less than a /60 prefix, and it is highly preferable that an ISP offer less than a /60 prefix, and it is highly preferable that
the ISP offers at least a /56. It is expected that the allocated the ISP offers at least a /56. It is expected that the allocated
prefix to the homenet from any single ISP is a contiguous, aggregated prefix to the homenet from any single ISP is a contiguous, aggregated
one. While it may be possible for a homenet CER to issue multiple one. While it may be possible for a homenet CER to issue multiple
skipping to change at page 29, line 48 skipping to change at page 29, line 48
In general, LLN or other networks should be able to attach and In general, LLN or other networks should be able to attach and
participate in the same way as the main homenet, or alternatively participate in the same way as the main homenet, or alternatively
map/be gatewayed to the main homenet. Current home deployments use map/be gatewayed to the main homenet. Current home deployments use
largely different mechanisms in sensor and basic Internet largely different mechanisms in sensor and basic Internet
connectivity networks. IPv6 virtual machine (VM) solutions may also connectivity networks. IPv6 virtual machine (VM) solutions may also
add additional routing requirements. add additional routing requirements.
3.5.1. Multicast support 3.5.1. Multicast support
It is desirable that, subject to the capacities of devices on certain It is desirable that, subject to the capacities of devices on certain
media types, multicast routing is supported across the homenet. The media types, multicast routing is supported across the homenet.
natural scopes for internal multicast would be link-local or site-
local, with the latter constrained within the homenet, but other
policy borders, e.g., to a guest subnet, or to certain media types,
may also affect where specific multicast traffic is routed.
The homenet will need to be able to automatically configure the site [RFC4291] requires that any boundary of scope 4 or higher (i.e.,
multicast scope and scope boundary as part of the homenet edge admin-local or higher) be administratively configured. Thus the
(border) discovery process. boundary at the homenet-ISP border must be administratively
configured, though that may be triggered by an administrative
function such as DHCP-PD. Other multicast forwarding policy borders
may also exist within the homenet, e.g., to/from a guest subnet,
whilst the use of certain media types may also affect where specific
multicast traffic is forwarded or routed.
There may be different drivers for multicast to be supported across There may be different drivers for multicast to be supported across
the homenet, e.g., for homenet-wide service discovery should a site- the homenet, e.g., for homenet-wide service discovery should a
scope multicast service discovery protocol be defined, or potentially multicast service discovery protocol of scope greater than link-local
for novel streaming or filesharing applications. Where multicast is be defined, or potentially for multicast-based streaming or
routed across a homenet an appropriate multicast routing protocol is filesharing applications. Where multicast is routed across a homenet
required, one that as per the unicast routing protocol should be an appropriate multicast routing protocol is required, one that as
self-configuring. It must be possible to scope or filter multicast per the unicast routing protocol should be self-configuring. As
hinted above, it must be possible to scope or filter multicast
traffic to avoid it being flooded to network media where devices traffic to avoid it being flooded to network media where devices
cannot reasonably support it. cannot reasonably support it.
Multicast may also be received by or sourced from the homenet from/to A homenet may not only use multicast internally, it may also be a
external networks, e.g., where video applications use multicast to consumer or provider of external multicast traffic, where the
conserve the bandwidth they consume. Such multicast traffic would be homenet's ISP supports such multicast operation. This may be
greater than site scope. valuable for example where live video applications are being sourced
to/from the homenet.
The multicast environment should support the ability for applications The multicast environment should support the ability for applications
to pick a unique multicast group to use. to pick a unique multicast group to use.
3.5.2. Mobility support 3.5.2. Mobility support
Devices may be mobile within the homenet. While resident on the same Devices may be mobile within the homenet. While resident on the same
subnet, their address will remain persistent, but should devices move subnet, their address will remain persistent, but should devices move
to a different (wireless) subnet, they will acquire a new address in to a different (wireless) subnet, they will acquire a new address in
that subnet. It is desirable that the homenet supports internal that subnet. It is desirable that the homenet supports internal
skipping to change at page 32, line 13 skipping to change at page 32, line 16
subnet(s). Some scenarios/models may as a result involve running subnet(s). Some scenarios/models may as a result involve running
isolated subnet(s) with their own CERs. In such cases connectivity isolated subnet(s) with their own CERs. In such cases connectivity
would only be expected within each isolated network (though traffic would only be expected within each isolated network (though traffic
may potentially pass between them via external providers). may potentially pass between them via external providers).
LLNs provide an another example of where there may be secure LLNs provide an another example of where there may be secure
perimeters inside the homenet. Constrained LLN nodes may implement perimeters inside the homenet. Constrained LLN nodes may implement
network key security but may depend on access policies enforced by network key security but may depend on access policies enforced by
the LLN border router. the LLN border router.
Considerations for differentiating neighbouring homenets are
discussed in Section 3.3.1.
3.6.3. Partial Effectiveness of NAT and Firewalls 3.6.3. Partial Effectiveness of NAT and Firewalls
Security by way of obscurity (address translation) or through Security by way of obscurity (address translation) or through
firewalls (filtering) is at best only partially effective. The very firewalls (filtering) is at best only partially effective. The very
poor security track record of home computer, home networking and poor security track record of home computer, home networking and
business PC computers and networking is testimony to this. A business PC computers and networking is testimony to this. A
security compromise behind the firewall of any device exposes all security compromise behind the firewall of any device exposes all
others, making an entire network that relies on obscurity or a others, making an entire network that relies on obscurity or a
firewall as vulnerable as the most insecure device on the private firewall as vulnerable as the most insecure device on the private
side of the network. side of the network.
However, given current evidence of home network products with very However, given current evidence of home network products with very
poor default device security, putting a firewall in place does poor default device security, putting a firewall in place does
provide some level of protection. The use of firewalls today, provide some level of protection. The use of firewalls today,
whether a good practice or not, is common practice and whatever whether a good practice or not, is common practice and whatever
protection afforded, even if marginally effective, should not be protection afforded, even if marginally effective, should not be
lost. Thus, while it is highly desirable that all hosts in a homenet lost. Thus, while it is highly desirable that all hosts in a homenet
be adequately protected by built-in security functions, it should be adequately protected by built-in security functions, it should
also be assumed that all CERs will continue to support appropriate also be assumed that all CERs will continue to support appropriate
perimeter defence functions, as per [I-D.ietf-v6ops-6204bis]. perimeter defence functions, as per [RFC7084].
3.6.4. Exfiltration concerns 3.6.4. Exfiltration concerns
As homenets become more complex, with more devices, and with service As homenets become more complex, with more devices, and with service
discovery potentially enabled across the whole home, there are discovery potentially enabled across the whole home, there are
potential concerns over the leakage of information should devices use potential concerns over the leakage of information should devices use
discovery protocols to gather information and report it to equipment discovery protocols to gather information and report it to equipment
vendors or application service providers. vendors or application service providers.
While it is not clear how such exfiltration could be easily avoided, While it is not clear how such exfiltration could be easily avoided,
the threat should be recognised, be it from a new piece of hardware the threat should be recognised, be it from a new piece of hardware
or some 'app' installed on personal device. or some 'app' installed on a personal device.
3.6.5. Device capabilities 3.6.5. Device capabilities
In terms of the devices, homenet hosts should implement their own In terms of the devices, homenet hosts should implement their own
security policies in accordance to their computing capabilities. security policies in accordance to their computing capabilities.
They should have the means to request transparent communications to They should have the means to request transparent communications to
be able to be initiated to them through security filters in the be able to be initiated to them through security filters in the
homenet, either for all ports or for specific services. Users should homenet, either for all ports or for specific services. Users should
have simple methods to associate devices to services that they wish have simple methods to associate devices to services that they wish
to operate transparently through (CER) borders. to operate transparently through (CER) borders.
skipping to change at page 37, line 36 skipping to change at page 37, line 43
the user or not. The IAB has issued a statement which explains why the user or not. The IAB has issued a statement which explains why
dotless domains should be considered harmful [IABdotless]. dotless domains should be considered harmful [IABdotless].
There may be use cases where either different name spaces may be There may be use cases where either different name spaces may be
desired for different realms in the homenet, or for segmentation of a desired for different realms in the homenet, or for segmentation of a
single name space within the homenet. Thus hierarchical name space single name space within the homenet. Thus hierarchical name space
management is likely to be required. There should also be nothing to management is likely to be required. There should also be nothing to
prevent individual device(s) being independently registered in prevent individual device(s) being independently registered in
external name spaces. external name spaces.
It may be the case that if there are two or more CERs serving the
home network, that if each has name space delegated from a different
ISP there is the potential for devices in the home to have multiple
fully qualified names under multiple domains.
Where a user is in a remote network wishing to access devices in Where a user is in a remote network wishing to access devices in
their home network, there may be a requirement to consider the domain their home network, there may be a requirement to consider the domain
search order presented where multiple associated name spaces exist. search order presented where multiple associated name spaces exist.
This also implies that a domain discovery function is desirable. This also implies that a domain discovery function is desirable.
It may be the case that not all devices in the homenet are made It may be the case that not all devices in the homenet are made
available by name via an Internet name space, and that a 'split view' available by name via an Internet name space, and that a 'split view'
is preferred for certain devices, whereby devices inside the homenet (as described in [RFC6950] Section 4) is preferred for certain
see different DNS responses to those outside. devices, whereby devices inside the homenet see different DNS
responses to those outside.
This document makes no assumption about the presence or omission of a Finally, this document makes no assumption about the presence or
reverse lookup service. There is an argument that it may be useful omission of a reverse lookup service. There is an argument that it
for presenting logging information to users with meaningful device may be useful for presenting logging information to users with
names rather than literal addresses. There are also some services, meaningful device names rather than literal addresses. There are
most notably email mail exchangers, where some operators have chosen also some services, most notably email mail exchangers, where some
to require a valid reverse lookup before accepting connections. operators have chosen to require a valid reverse lookup before
accepting connections.
3.7.5. Independent operation 3.7.5. Independent operation
Name resolution and service discovery for reachable devices must Name resolution and service discovery for reachable devices must
continue to function if the local network is disconnected from the continue to function if the local network is disconnected from the
global Internet, e.g., a local media server should still be available global Internet, e.g., a local media server should still be available
even if the Internet link is down for an extended period. This even if the Internet link is down for an extended period. This
implies the local network should also be able to perform a complete implies the local network should also be able to perform a complete
restart in the absence of external connectivity, and have local restart in the absence of external connectivity, and have local
naming and service discovery operate correctly. naming and service discovery operate correctly.
skipping to change at page 39, line 50 skipping to change at page 40, line 13
traffic may simply not be appropriate for some media, and need to be traffic may simply not be appropriate for some media, and need to be
dropped to avoid overloading the constrained media). dropped to avoid overloading the constrained media).
There may also be complementary mechanisms that could be beneficial There may also be complementary mechanisms that could be beneficial
to application performance and behaviour in the homenet domain, such to application performance and behaviour in the homenet domain, such
as ensuring proper buffering algorithms are used as described in as ensuring proper buffering algorithms are used as described in
[Gettys11]. [Gettys11].
3.8.2. Operations and Management 3.8.2. Operations and Management
The homenet should be self-organising and configuring as far as The homenet should have the general goal of being self-organising and
possible, and thus should not need to be pro-actively managed by the configuring, and thus the network elements should not need to be pro-
home user. Thus specific protocols to manage the network are not actively managed by the home user. Thus specific protocols that may
discussed in this document. be available to manage the network are not discussed in this
document.
There may be some configuration parameters which are exposed to The network protocols used should, as far as possible, be able to
self-configure, e.g. for prefixes to be assigned to router
interfaces, or for devices to use zero-configuration protocols to
discover services in the home. A home user would not be expected to,
e.g., assign prefixes to links, or manage the DNS entries for the
home network. Such expert operation should not be precluded, but it
is not the norm.
There may still be some configuration parameters which are exposed to
users, e.g., SSID name(s), or wireless security key(s). Users may users, e.g., SSID name(s), or wireless security key(s). Users may
also be expected to be aware of the functions of certain devices they also be expected to be aware of the functions of certain devices they
connect, e.g., which are providing a server function, though service connect, e.g., which are providing a server function, and they may be
able to assign 'friendly names' to those devices, though service
discovery protocols should make their selection as intuitive as discovery protocols should make their selection as intuitive as
possible. possible.
As discussed in Section 3.6.1 the default setting on the homenet-ISP As discussed in Section 3.6.1 the default setting on the homenet-ISP
border for inbound traffic may be default deny, default allow, or border for inbound traffic may be default deny, default allow, or
some position inbetween. Whatever the default position, it should be some position inbetween. Whatever the default position, it should be
possible for the user to change the setting. possible for the user to change the setting.
Users may also be interested in the status of their networks and Users may also be interested in the status of their networks and
devices on the network, in which case simplified monitoring devices on the network, in which case simple self-monitoring
mechanisms may be desirable. It may also be the case that an ISP, or mechanisms would be desirable. This may be particularly important
a third party, might offer management of the homenet on behalf of a when some fault arises in the network or with a device. It may also
user, in which case management protocols would be required. How such be the case that an ISP, or a third party, might offer management of
management is done is out of scope of this document; many solutions the homenet on behalf of a user, in which case management protocols
exist. would be required. How either model of management and monitoring is
performed is out of scope of this document. It is expected that a
separate document will follow to describe the operations and
management model(s) for the types of home networks presented in this
document.
It is expected that network management functions would be available A final consideration is that all network management and monitoring
over IPv6 transport, even where the homenet is dual-stack. functions should be available over IPv6 transport, even where the
homenet is dual-stack.
3.9. Implementing the Architecture on IPv6 3.9. Implementing the Architecture on IPv6
This architecture text encourages re-use of existing protocols. Thus This architecture text encourages re-use of existing protocols. Thus
the necessary mechanisms are largely already part of the IPv6 the necessary mechanisms are largely already part of the IPv6
protocol set and common implementations, though there are some protocol set and common implementations, though there are some
exceptions. exceptions.
For automatic routing, it is expected that solutions can be found For automatic routing, it is expected that solutions can be found
based on existing protocols. Some relatively smaller updates are based on existing protocols. Some relatively smaller updates are
skipping to change at page 44, line 4 skipping to change at page 44, line 34
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, January 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, Selkirk, "Port Control Protocol (PCP)", RFC 6887,
April 2013. April 2013.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", RFC 6950, October 2013.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 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-06 (work
in progress), March 2013. in progress), February 2014.
[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-05 (work in progress), draft-ietf-ospf-ospfv3-autoconfig-06 (work in progress),
October 2013. February 2014.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (work in progress), June 2013.
[I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers",
draft-ietf-v6ops-6204bis-12 (work in progress),
October 2012.
[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>.
skipping to change at page 45, line 17 skipping to change at page 46, line 5
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 controbutor agrees with every point in the document. imply that each controbutor agrees with every point in the document.
Appendix B. Changes Appendix B. Changes
This section will be removed in the final version of the text. This section will be removed in the final version of the text.
B.1. Version 11 (after IESG review) B.1. Version 12
Changes made include:
o Fixed minor typo nits introduced in -11.
o Elwyn Davies' gen-art review comments addressed.
o Some further IESG DISCUSS comments addressed.
B.2. 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.
B.2. Version 10 (after AD review) o Considered secdir review by Samiel Weiler; many points addressed.
o Considered APPSDIR review.
o Addressed a large number of IESG comments and discusses.
B.3. 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.3. Version 09 (after WGLC) B.4. 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 46, line 21 skipping to change at page 47, line 24
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.4. Version 08 B.5. 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.5. Version 07 B.6. 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 47, line 28 skipping to change at page 48, line 31
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.6. Version 06 B.7. 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.7. Version 05 B.8. 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.8. Version 04 B.9. 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.9. Version 03 B.10. 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 49, line 36 skipping to change at page 50, line 38
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.10. Version 02 B.11. 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. 53 change blocks. 
125 lines changed or deleted 177 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/