draft-ietf-homenet-arch-13.txt   draft-ietf-homenet-arch-14.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: September 5, 2014 Ericsson Expires: December 10, 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
March 4, 2014 June 8, 2014
IPv6 Home Networking Architecture Principles IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-13 draft-ietf-homenet-arch-14
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 September 5, 2014. This Internet-Draft will expire on December 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
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 . . . . . . . . . . . . . . . . . . 30 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 30
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6.1. Addressability vs reachability . . . . . . . . . . . . 31 3.6.1. Addressability vs reachability . . . . . . . . . . . . 31
3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 32 3.6.2. Filtering at borders . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . 33 3.6.4. Exfiltration concerns . . . . . . . . . . . . . . . . 33
3.6.5. Device capabilities . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . 34
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 35 3.7.2. Assigning names to devices . . . . . . . . . . . . . . 35
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 . . . . . . . . . . . . . . . . 39
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 39 3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 39
3.7.7. DNS resolver discovery . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . 40
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 40 3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 40
3.8.2. Operations and Management . . . . . . . . . . . . . . 40 3.8.2. Operations and Management . . . . . . . . . . . . . . 40
3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 41 3.9. Implementing the Architecture on IPv6 . . . . . . . . . . 42
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1. Normative References . . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . . 43
7.2. Informative References . . . . . . . . . . . . . . . . . . 43 7.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 46
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46
B.1. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.1. Version 14 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.2. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.2. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 47
B.3. Version 11 (after IESG review) . . . . . . . . . . . . . . 46 B.3. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 47
B.4. Version 10 (after AD review) . . . . . . . . . . . . . . . 47 B.4. Version 11 (after IESG review) . . . . . . . . . . . . . . 47
B.5. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47 B.5. Version 10 (after AD review) . . . . . . . . . . . . . . . 47
B.6. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.6. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47
B.7. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.7. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.8. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.9. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.9. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.10. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.10. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.11. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.11. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 50
B.12. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51 B.12. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50
B.13. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
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.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
should not be expected to enter IPv6 literal addresses in devices or should not be expected to enter IPv6 literal addresses in devices or
applications, given their much greater length and the apparent applications, given their much greater length and the apparent
randomness of such addresses to a typical home user. Thus, even for randomness of such addresses to a typical home user. Thus, even for
the simplest of functions, simple naming and the associated (minimal, the simplest of functions, simple naming and the associated (minimal,
and ideally zero configuration) discovery of services is imperative and ideally zero configuration) discovery of services is imperative
for the easy deployment and use of homenet devices and applications. for the easy deployment and use of homenet devices and applications.
2.6. IPv6-only operation 2.6. IPv6-only operation
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 referred to as 'greenfield'
where there is no existing IPv4 capability, or perhaps as one element scenarios, where there is no existing IPv4 capability, or perhaps as
of an otherwise dual-stack network. Running IPv6-only adds one element of an otherwise dual-stack network. Running IPv6-only
additional requirements, e.g., for devices to get configuration adds 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 [RFC7084]. In addition, certain other homenet's ISP are discussed in [RFC7084]. In addition, certain other
functions may be desirable on the CER, e.g., to access content in the functions may be desirable on the CER, e.g., to access content in the
IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable. IPv4 Internet, NAT64 [RFC6144] and DNS64 [RFC6145] may be applicable.
The widespread availability of robust solutions to these types of The widespread availability of robust solutions to these types of
skipping to change at page 20, line 6 skipping to change at page 20, line 6
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 [RFC7157]. Alternatively a flooding/routing protocol could
flooding/routing protocol could potentially be used to pass potentially be used to pass information through the homenet, such
information through the homenet, such that internal routers and that internal routers and ultimately end hosts could learn per-prefix
ultimately end hosts could learn per-prefix configuration configuration information, allowing better address selection
information, allowing better address selection decisions to be made. decisions to be made. However, this would imply router and, most
However, this would imply router and, most likely, host changes. likely, host changes. Another avenue is to introduce support
Another avenue is to introduce support throughout the homenet for throughout the homenet for routing which is based on the source as
routing which is based on the source as well as the destination well as the destination address of each packet. While greatly
address of each packet. While greatly improving the 'intelligence' improving the 'intelligence' of routing decisions within the homenet,
of routing decisions within the homenet, such an approach would such an approach would require relatively significant router changes
require relatively significant router changes but avoid host 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. As per Section 4.2.1 of [RFC3002] we do of a user in the homenet. As per Section 4.2.1 of [RFC3002] we do
skipping to change at page 28, line 47 skipping to change at page 28, line 47
deployed within the internal home network. This functionality could deployed within the internal home network. This functionality could
be as simple as the current 'default route is up' model of IPv4 NAT, be as simple as the current 'default route is up' model of IPv4 NAT,
or, more likely, it would involve running an appropriate routing or, more likely, it would involve running an appropriate routing
protocol. Regardless of the solution method, the functionality protocol. Regardless of the solution method, the functionality
discussed below should be met. discussed below should be met.
The homenet unicast routing protocol should be based on a previously The homenet unicast routing protocol should be based on a previously
deployed protocol that has been shown to be reliable and robust, and deployed protocol that has been shown to be reliable and robust, and
that allows lightweight implementations, but that does not preclude that allows lightweight implementations, but that does not preclude
the selection of a newer protocol for which a high quality open the selection of a newer protocol for which a high quality open
source implemenation becomes available. The availability of open source implementation becomes available. Using information
source implementations is an important consideration. Using distributed through the routing protocol, each node in the homenet
information distributed through the routing protocol, each node in should be able to build a graph of the topology of the whole homenet
the homenet should be able to build a graph of the topology of the including attributes such as links, nodes, connectivity, and (if
whole homenet including links, nodes, connectivity, and (if the supported by the protocol in use) link metrics. In the latter case,
routing protocol supports them) link metrics. link metrics may be configured or automatically derived per-link
based on consideration of factors such as worst-case queue depth and
Multiple types of physical interfaces must be accounted for in the router processing capabilities.
homenet routed topology. Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the
homenet.
The routing protocol should support the generic use of multiple The routing protocol should support the generic use of multiple
customer Internet connections, and the concurrent use of multiple customer Internet connections, and the concurrent use of multiple
delegated prefixes. A routing protocol that can make routing delegated prefixes. A routing protocol that can make routing
decisions based on source and destination addresses is thus decisions based on source and destination addresses is thus
desirable, to avoid upstream ISP BCP 38 ingress filtering problems. desirable, to avoid upstream ISP BCP 38 ingress filtering problems.
Multihoming support should also include load-balancing to multiple Multihoming support should also include load-balancing to multiple
providers, and failover from a primary to a backup link when providers, and failover from a primary to a backup link when
available. The protocol however should not require upstream ISP available. The protocol however should not require upstream ISP
connectivity to be established to continue routing within the connectivity to be established to continue routing within the
homenet. homenet.
Routing within the homenet will determine the least cost path across
the homenet towards the destination address given the source address.
The path cost will be computed as a linear sum of the metric assigned
to each link. The metric may be configured or automatically derived
per link based on consideration of factors such as worst-case queue
depth and router processing capabilities.
Multiple types of physical interfaces must be accounted for in the
homenet routed topology. Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the
homenet.
The routing environment should be self-configuring, as discussed The routing environment should be self-configuring, as discussed
previously. Minimising convergence time should be a goal in any previously. Minimising convergence time should be a goal in any
routed environment, but as a guideline a maximum convergence time at routed environment, but as a guideline a maximum convergence time at
most 30 seconds should be the target (this target is somewhat most 30 seconds should be the target (this target is somewhat
arbitrary, and was chosen based on how long a typical home user might arbitrary, and was chosen based on how long a typical home user might
wait before attempting another reset; ideally the routers might have wait before attempting another reset; ideally the routers might have
some status light indicating they are converging, similar to an ADSL some status light indicating they are converging, similar to an ADSL
router light indicating it is establishing a connection to its ISP). router light indicating it is establishing a connection to its ISP).
Homenets may use a variety of underlying link layer technologies, and Homenets may use a variety of underlying link layer technologies, and
may therefore benefit from being able to use link metrics if may therefore benefit from being able to use link metrics if
available. It may be beneficial for traffic to use multiple paths to available. It may be beneficial for traffic to use multiple paths to
a given destination within the homenet whwre available, rather than a a given destination within the homenet where available, rather than a
single best path. single best path.
Ideally, a single routing protocol solution is in use at a given time At most one routing protocol should be in use at a given time in a
in a given homenet. If more than one routing protocol is defined for given homenet. In some simple topologies, no routing protocol may be
use in a homenet, then a mechanism is required to ensure that all needed. If more than one routing protocol is supported by routers in
routers in a given homenet support the same protocol before it is a given homenet, then a mechanism is required to ensure that all
used, and that a particular routing solution is enabled by default. routers in that homenet use the same protocol.
An appropriate mechanism is required to discover which router(s) in An appropriate mechanism is required to discover which router(s) in
the homenet are providing the CER function. Borders may include but the homenet are providing the CER function. Borders may include but
are not limited to the interface to the upstream ISP, a gateway are not limited to the interface to the upstream ISP, a gateway
device to a separate home network such as a LLN network, or a gateway device to a separate home network such as a LLN network, or a gateway
to a guest or private corporate extension network. In some cases to a guest or private corporate extension network. In some cases
there may be no border present, which may for example occur before an there may be no border present, which may for example occur before an
upstream connection has been established. The border discovery upstream connection has been established. The border discovery
functionality may be integrated into the routing protocol itself, but functionality may be integrated into the routing protocol itself, but
may also be imported via a separate discovery mechanism. may also be imported via a separate discovery mechanism.
skipping to change at page 30, line 18 skipping to change at page 30, line 28
exchange routes such that IP traffic may be forwarded among the exchange routes such that IP traffic may be forwarded among the
networks via gateway routers which interoperate with both the homenet networks via gateway routers which interoperate with both the homenet
and the LLN. Current home deployments use largely different and the LLN. Current home deployments use largely different
mechanisms in sensor and basic Internet connectivity networks. IPv6 mechanisms in sensor and basic Internet connectivity networks. IPv6
virtual machine (VM) solutions may also add additional routing virtual machine (VM) solutions may also add additional routing
requirements. requirements.
3.5.1. Multicast support 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. media types, multicast routing is supported across the homenet,
including source-specific multicast (SSM) [RFC4607].
[RFC4291] requires that any boundary of scope 4 or higher (i.e., [RFC4291] requires that any boundary of scope 4 or higher (i.e.,
admin-local or higher) be administratively configured. Thus the admin-local or higher) be administratively configured. Thus the
boundary at the homenet-ISP border must be administratively boundary at the homenet-ISP border must be administratively
configured, though that may be triggered by an administrative configured, though that may be triggered by an administrative
function such as DHCP-PD. Other multicast forwarding policy borders function such as DHCP-PD. Other multicast forwarding policy borders
may also exist within the homenet, e.g., to/from a guest subnet, may also exist within the homenet, e.g., to/from a guest subnet,
whilst the use of certain media types may also affect where specific whilst the use of certain link media types may also affect where
multicast traffic is forwarded or routed. 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 the homenet, e.g., for homenet-wide service discovery should a
multicast service discovery protocol of scope greater than link-local multicast service discovery protocol of scope greater than link-local
be defined, or potentially for multicast-based streaming or be defined, or potentially for multicast-based streaming or
filesharing applications. Where multicast is routed across a homenet filesharing applications. Where multicast is routed across a homenet
an appropriate multicast routing protocol is required, one that as an appropriate multicast routing protocol is required, one that as
per the unicast routing protocol should be self-configuring. As per the unicast routing protocol should be self-configuring. As
hinted above, it must be possible to scope or filter multicast 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
skipping to change at page 40, line 17 skipping to change at page 40, line 31
This section discusses two other considerations for home networking This section discusses two other considerations for home networking
that the architecture should not preclude, but that this text is that the architecture should not preclude, but that this text is
neutral towards. neutral towards.
3.8.1. Quality of Service 3.8.1. Quality of Service
Support for Quality of Service in a multi-service homenet may be a Support for Quality of Service in a multi-service homenet may be a
requirement, e.g., for a critical system (perhaps healthcare requirement, e.g., for a critical system (perhaps healthcare
related), or for differentiation between different types of traffic related), or for differentiation between different types of traffic
(file sharing, cloud storage, live streaming, VoIP, etc). Different (file sharing, cloud storage, live streaming, VoIP, etc). Different
media types may have different such properties or capabilities. link media types may have different such properties or capabilities.
However, homenet scenarios should require no new Quality of Service However, homenet scenarios should require no new Quality of Service
protocols. A DiffServ [RFC2475] approach with a small number of protocols. A DiffServ [RFC2475] approach with a small number of
predefined traffic classes may generally be sufficient, though at predefined traffic classes may generally be sufficient, though at
present there is little experience of Quality of Service deployment present there is little experience of Quality of Service deployment
in home networks. It is likely that QoS, or traffic prioritisation, in home networks. It is likely that QoS, or traffic prioritisation,
methods will be required at the CER, and potentially around methods will be required at the CER, and potentially around
boundaries between different media types (where for example some boundaries between different link media types (where for example some
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
skipping to change at page 41, line 29 skipping to change at page 41, line 43
monitoring may extend to other devices on the network, e.g. storage monitoring may extend to other devices on the network, e.g. storage
devices, or web cameras, but such devices are beyond the scope of devices, or web cameras, but such devices are beyond the scope of
this document. this document.
It may also be the case that an ISP, or a third party, might wish to It may also be the case that an ISP, or a third party, might wish to
offer a remote management service for the homenet on behalf of the offer a remote management service for the homenet on behalf of the
user, or to be able to assist the user in event of some problem they user, or to be able to assist the user in event of some problem they
are experiencing, in which case appropriate management and monitoring are experiencing, in which case appropriate management and monitoring
protocols would be required. protocols would be required.
The specific protocols required to facilitate homenet management and Specifying the required protocols to facilitate homenet management
monitoring are out of scope of this document. As stated above, it is and monitoring is out of scope of this document. As stated above, it
expected that a separate document will be produced to describe the is expected that a separate document will be produced to describe the
operations and management framework for the types of home network operations and management framework for the types of home network
presented in this document. presented in this document.
As a final point, we note that it is desirable that all network As a final point, we note that it is desirable that all network
management and monitoring functions should be available over IPv6 management and monitoring functions should be available over IPv6
transport, even where the homenet is dual-stack. 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
skipping to change at page 43, line 48 skipping to change at page 44, line 13
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864, E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007. May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
skipping to change at page 45, line 25 skipping to change at page 45, line 42
April 2013. April 2013.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in "Architectural Considerations on Application Features in
the DNS", RFC 6950, October 2013. the DNS", RFC 6950, October 2013.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013. November 2013.
[I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] [RFC7157] 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", RFC 7157, March 2014.
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 (work
in progress), 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.
[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/
skipping to change at page 46, line 18 skipping to change at page 46, line 30
Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray Wassim Haddad, Joel M. Halpern, David Harrington, Lee Howard, Ray
Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry Hunter, Joel Jaeggli, Heather Kirksey, Ted Lemon, Acee Lindem, Kerry
Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia Lynn, Daniel Migault, Erik Nordmark, Michael Richardson, Mattia
Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek, Rossi, Barbara Stark, Markus Stenberg, Sander Steffann, Don Sturek,
Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark Andrew Sullivan, Dave Taht, Dave Thaler, Michael Thomas, Mark
Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and Townsley, JP Vasseur, Curtis Villamizar, Dan Wing, Russ White, and
James Woodyatt for their comments and contributions within homenet WG James Woodyatt for their comments and contributions within homenet WG
meetings and on the WG mailing list. An acknowledgement generally meetings and on the WG mailing list. An acknowledgement generally
means that person's text made it in to the document, or was helpful means that person's text made it in to the document, or was helpful
in clarifying or reinforcing an aspect of the document. It does not in clarifying or reinforcing an aspect of the document. It does not
imply that each controbutor agrees with every point in the document. imply that each contributor agrees with every point in the document.
Appendix B. Changes Appendix B. Changes
This section will be removed in the final version of the text. This section will be removed in the final version of the text.
B.1. Version 13 B.1. Version 14
Changes made include:
o Changes for Adrian Farrell discuss/comment.
o Very minor wordsmithing requested by Benoit for OAM text.
o Very minor wordsmithing from IETF89 session.
o Added note to support SSM.
o Emphasised at most one routing protocol in use, possibly none.
B.2. Version 13
Changes made include: Changes made include:
o Changes to address last outstanding IESG DISCUSSes/COMMENTs. o Changes to address last outstanding IESG DISCUSSes/COMMENTs.
B.2. Version 12 B.3. Version 12
Changes made include: Changes made include:
o Fixed minor typo nits introduced in -11. o Fixed minor typo nits introduced in -11.
o Elwyn Davies' gen-art review comments addressed. o Elwyn Davies' gen-art review comments addressed.
o Some further IESG DISCUSSes/COMMENTs addressed. o Some further IESG DISCUSSes/COMMENTs addressed.
B.3. Version 11 (after IESG review) B.4. Version 11 (after IESG review)
Changes made include: Changes made include:
o Jouni Korhonen's OPSDIR review comments addressed. o Jouni Korhonen's OPSDIR review comments addressed.
o Elwyn Davies' gen-art review comments addressed. o Elwyn Davies' gen-art review comments addressed.
o Considered secdir review by Samiel Weiler; many points addressed. o Considered secdir review by Samiel Weiler; many points addressed.
o Considered APPSDIR review. o Considered APPSDIR review.
o Addressed a large number of IESG comments and discusses. o Addressed a large number of IESG comments and discusses.
B.4. Version 10 (after AD review) B.5. 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.5. Version 09 (after WGLC) B.6. Version 09 (after WGLC)
Changes made include: Changes made include:
o Added note about multicast into or out of site o Added note about multicast into or out of site
o Removed further personal draft references, replaced with covering o Removed further personal draft references, replaced with covering
text text
o Routing functionality text updated to avoid ambiguity o Routing functionality text updated to avoid ambiguity
o Added note that devices away from homenet may tunnel home (via o Added note that devices away from homenet may tunnel home (via
VPN) VPN)
o Added note that homenets more exposed to provider renumbering than o Added note that homenets more exposed to provider renumbering than
with IPv4 and NAT with IPv4 and NAT
o Added note about devices that may be ULA-only until configured to o Added note about devices that may be ULA-only until configured to
be globally addressable be globally addressable
o Removed paragraph about broken CERs that do not work with prefixes o Removed paragraph about broken CERs that do not work with prefixes
skipping to change at page 48, line 5 skipping to change at page 48, line 29
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.6. Version 08 B.7. 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.7. Version 07 B.8. 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 49, line 12 skipping to change at page 49, line 38
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.8. Version 06 B.9. 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.9. Version 05 B.10. 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.10. Version 04 B.11. 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.11. Version 03 B.12. Version 03
Changes made include: Changes made include:
o Various improvements to the readability. o Various improvements to the readability.
o Removed bullet lists of requirements, as requested by chair. o Removed bullet lists of requirements, as requested by chair.
o Noted 6204bis has replaced advanced-cpe draft. o Noted 6204bis has replaced advanced-cpe draft.
o Clarified the topology examples are just that. o Clarified the topology examples are just that.
skipping to change at page 51, line 20 skipping to change at page 51, line 47
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.12. Version 02 B.13. 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. 39 change blocks. 
87 lines changed or deleted 111 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/