< draft-ietf-homenet-arch-12.txt   draft-ietf-homenet-arch-13.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: August 18, 2014 Ericsson Expires: September 5, 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
February 14, 2014 March 4, 2014
IPv6 Home Networking Architecture Principles IPv6 Home Networking Architecture Principles
draft-ietf-homenet-arch-12 draft-ietf-homenet-arch-13
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 August 18, 2014. This Internet-Draft will expire on September 5, 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 2, line 40 skipping to change at page 2, line 40
2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 11 2.6. IPv6-only operation . . . . . . . . . . . . . . . . . . . 11
3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11 3. Homenet Architecture Principles . . . . . . . . . . . . . . . 11
3.1. General Principles . . . . . . . . . . . . . . . . . . . . 12 3.1. General Principles . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 12 3.1.1. Reuse existing protocols . . . . . . . . . . . . . . . 12
3.1.2. Minimise changes to hosts and routers . . . . . . . . 12 3.1.2. Minimise changes to hosts and routers . . . . . . . . 12
3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 13 3.2. Homenet Topology . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13 3.2.1. Supporting arbitrary topologies . . . . . . . . . . . 13
3.2.2. Network topology models . . . . . . . . . . . . . . . 13 3.2.2. Network topology models . . . . . . . . . . . . . . . 13
3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 18 3.2.3. Dual-stack topologies . . . . . . . . . . . . . . . . 18
3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19 3.2.4. Multihoming . . . . . . . . . . . . . . . . . . . . . 19
3.2.5. Mobility support . . . . . . . . . . . . . . . . . . . 20
3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20 3.3. A Self-Organising Network . . . . . . . . . . . . . . . . 20
3.3.1. Differentiating neighbouring homenets . . . . . . . . 21 3.3.1. Differentiating neighbouring homenets . . . . . . . . 21
3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21 3.3.2. Largest practical subnets . . . . . . . . . . . . . . 21
3.3.3. Handling varying link technologies . . . . . . . . . . 22 3.3.3. Handling varying link technologies . . . . . . . . . . 22
3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22 3.3.4. Homenet realms and borders . . . . . . . . . . . . . . 22
3.3.5. Configuration information from the ISP . . . . . . . . 23 3.3.5. Configuration information from the ISP . . . . . . . . 23
3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 23 3.4. Homenet Addressing . . . . . . . . . . . . . . . . . . . . 23
3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 23 3.4.1. Use of ISP-delegated IPv6 prefixes . . . . . . . . . . 24
3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 25 3.4.2. Stable internal IP addresses . . . . . . . . . . . . . 26
3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 26 3.4.3. Internal prefix delegation . . . . . . . . . . . . . . 27
3.4.4. Coordination of configuration information . . . . . . 27 3.4.4. Coordination of configuration information . . . . . . 28
3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28 3.4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28 3.5. Routing functionality . . . . . . . . . . . . . . . . . . 28
3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 29 3.5.1. Multicast support . . . . . . . . . . . . . . . . . . 30
3.5.2. Mobility support . . . . . . . . . . . . . . . . . . . 30 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . 33
3.7.1. Discovering services . . . . . . . . . . . . . . . . . 33 3.7.1. Discovering services . . . . . . . . . . . . . . . . . 34
3.7.2. Assigning names to devices . . . . . . . . . . . . . . 34 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 . . . . . . . . . . . . . . . . 38
3.7.6. Considerations for LLNs . . . . . . . . . . . . . . . 38 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 . . . . . . . . . 39
3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 39 3.8. Other Considerations . . . . . . . . . . . . . . . . . . . 40
3.8.1. Quality of Service . . . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . 41
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. Normative References . . . . . . . . . . . . . . . . . . . 42 7.1. Normative References . . . . . . . . . . . . . . . . . . . 42
7.2. Informative References . . . . . . . . . . . . . . . . . . 42 7.2. Informative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 45 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 45
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 46
B.1. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 46 B.1. Version 13 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.2. Version 11 (after IESG review) . . . . . . . . . . . . . . 46 B.2. Version 12 . . . . . . . . . . . . . . . . . . . . . . . . 46
B.3. Version 10 (after AD review) . . . . . . . . . . . . . . . 46 B.3. Version 11 (after IESG review) . . . . . . . . . . . . . . 46
B.4. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 46 B.4. Version 10 (after AD review) . . . . . . . . . . . . . . . 47
B.5. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.5. Version 09 (after WGLC) . . . . . . . . . . . . . . . . . 47
B.6. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 47 B.6. Version 08 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.7. Version 07 . . . . . . . . . . . . . . . . . . . . . . . . 48
B.8. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 48 B.8. Version 06 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.9. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.9. Version 05 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.10. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 49 B.10. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 49
B.11. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 50 B.11. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 B.12. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 51
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.
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 8, line 36 skipping to change at page 8, line 36
It is thus important to distinguish between addressability and It is thus important to distinguish between addressability and
reachability. While IPv6 offers global addressability through use of reachability. While IPv6 offers global addressability through use of
globally unique addresses in the home, whether devices are globally globally unique addresses in the home, whether devices are globally
reachable or not would depend on any firewall or filtering reachable or not would depend on any firewall or filtering
configuration, and not, as is commonly the case with IPv4, the configuration, and not, as is commonly the case with IPv4, the
presence or use of NAT. In this respect, IPv6 networks may or may presence or use of NAT. In this respect, IPv6 networks may or may
not have filters applied at their borders to control such traffic, not have filters applied at their borders to control such traffic,
i.e., at the homenet CER. [RFC4864] and [RFC6092] discuss such i.e., at the homenet CER. [RFC4864] and [RFC6092] discuss such
filtering, and the merits of 'default allow' against 'default deny' filtering, and the merits of 'default allow' against 'default deny'
policies for external traffic initiated into a homenet. This policies for external traffic initiated into a homenet. This topic
document takes no position on which mode is the default, but assumes is discussed further in Section 3.6.1.
the choice for the homenet to use either mode would be available.
This topic is discussed further in Section 3.6.1.
2.3. Multi-Addressing of devices 2.3. Multi-Addressing of devices
In an IPv6 network, devices will often acquire multiple addresses, In an IPv6 network, devices will often acquire multiple addresses,
typically at least a link-local address and one or more globally typically at least a link-local address and one or more globally
unique addresses. Where a homenet is multihomed, a device would unique addresses. Where a homenet is multihomed, a device would
typically receive a globally unique address (GUA) from within the typically receive a globally unique address (GUA) from within the
delegated prefix from each upstream ISP. Devices may also have an delegated prefix from each upstream ISP. Devices may also have an
IPv4 address if the network is dual-stack, an IPv6 Unique Local IPv4 address if the network is dual-stack, an IPv6 Unique Local
Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy Address (ULA) [RFC4193] (see below), and one or more IPv6 Privacy
Addresses [RFC4941]. Addresses [RFC4941].
It should thus be considered the norm for devices on IPv6 home It should thus be considered the norm for devices on IPv6 home
networks to be multi-addressed, and to need to make appropriate networks to be multi-addressed, and to need to make appropriate
address selection decisions for the candidate source and destination address selection decisions for the candidate source and destination
address pairs for any given connection. Default Address Selection address pairs for any given connection. In multihoming scenarios
for IPv6 [RFC6724] provides a solution for this, though it may face nodes will be configured with one address from each upstream ISP
problems in the event of multihoming where, as described above, nodes prefix. In such cases the presence of upstream BCP 38 [RFC2827]
will be configured with one address from each upstream ISP prefix. ingress filtering requires such multi-addressed nodes to select the
In such cases the presence of upstream BCP 38 [RFC2827] ingress correct source address to be used for the corresponding uplink.
filtering requires multi-addressed nodes to select the correct source Default Address Selection for IPv6 [RFC6724] provides a solution for
address to be used for the corresponding uplink. A challenge here is this, but a challenge here is that the node may not have the
that the node may not have the information it needs to make that information it needs to make that decision based on addresses alone.
decision based on addresses alone. We discuss this challenge in We discuss this challenge in Section 3.2.4.
Section 3.2.4.
2.4. Unique Local Addresses (ULAs) 2.4. Unique Local Addresses (ULAs)
[RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be [RFC4193] defines Unique Local Addresses (ULAs) for IPv6 that may be
used to address devices within the scope of a single site. Support used to address devices within the scope of a single site. Support
for ULAs for IPv6 CERs is described in [RFC6204]. A home network for ULAs for IPv6 CERs is described in [RFC6204]. A home network
running IPv6 should deploy ULAs alongside its globally unique running IPv6 should deploy ULAs alongside its globally unique
prefix(es) to allow stable communication between devices (on prefix(es) to allow stable communication between devices (on
different subnets) within the homenet where that externally allocated different subnets) within the homenet where that externally allocated
globally unique prefix may change over time, e.g., due to renumbering globally unique prefix may change over time, e.g., due to renumbering
skipping to change at page 11, line 21 skipping to change at page 11, line 18
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 [RFC1918]. 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
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
skipping to change at page 12, line 34 skipping to change at page 12, line 31
at the network layer for policy or link layer compatibility reasons. at the network layer for policy or link layer compatibility reasons.
However, there is a lot of flexibility in using IP addressing and However, there is a lot of flexibility in using IP addressing and
inter-networking mechanisms. This text discusses how such inter-networking mechanisms. This text discusses how such
flexibility should be used to provide the best user experience and flexibility should be used to provide the best user experience and
ensure that the network can evolve with new applications in the ensure that the network can evolve with new applications in the
future. The principles described in this text should be followed future. The principles described in this text should be followed
when designing homenet protocol solutions. when designing homenet protocol solutions.
3.1.1. Reuse existing protocols 3.1.1. Reuse existing protocols
It is desirable to reuse existing protocols where possible, but at Existing protocols will be used to meet the requirements of home
the same time to avoid consciously precluding the introduction of new networks. Where necessary, extensions will be made to those
or emerging protocols. A generally conservative approach, giving protocols. When no existing protocol is found to be suitable, a new
weight to running (and available) code, is preferable. Where new or emerging protocol may be used. Therefore, it is important that no
protocols are required, evidence of commitment to implementation by design or architectural decisions are made that would preclude the
appropriate vendors or development communities is highly desirable. use of new or emerging protocols.
Protocols used should be backwardly compatible, and forward
compatible where changes are made. A generally conservative approach, giving weight to running (and
available) code, is preferable. Where new protocols are required,
evidence of commitment to implementation by appropriate vendors or
development communities is highly desirable. Protocols used should
be backwardly compatible, and forward compatible where changes are
made.
3.1.2. Minimise changes to hosts and routers 3.1.2. Minimise changes to hosts and routers
In order to maximise deployability of new homenets, where possible In order to maximise deployability of new homenets, where possible
any requirement for changes to hosts and routers should be minimised, any requirement for changes to hosts and routers should be minimised,
though solutions which, for example, incrementally improve capability though solutions which, for example, incrementally improve capability
with host or router changes may be acceptable. There may be cases with host or router changes may be acceptable. There may be cases
where changes are unavoidable, e.g., to allow a given homenet routing where changes are unavoidable, e.g., to allow a given homenet routing
protocol to be self-configuring. protocol to be self-configuring, or to support routing based on
sources addresses in addition to destination addresses (to improve
multihoming support, as discussed in Section 3.2.4).
3.2. Homenet Topology 3.2. Homenet Topology
This section considers homenet topologies, and the principles that This section considers homenet topologies, and the principles that
may be applied in designing an architecture to support as wide a may be applied in designing an architecture to support as wide a
range of such topologies as possible. range of such topologies as possible.
3.2.1. Supporting arbitrary topologies 3.2.1. Supporting arbitrary topologies
There should ideally be no built-in assumptions about the topology in There should ideally be no built-in assumptions about the topology in
skipping to change at page 13, line 28 skipping to change at page 13, line 31
activating a certain part of the infrastructure to allow the rest to activating a certain part of the infrastructure to allow the rest to
operate. In such cases, the user should ideally have some useful operate. In such cases, the user should ideally have some useful
indication of the failure mode encountered. indication of the failure mode encountered.
There should be no topology scenarios which cause loss of There should be no topology scenarios which cause loss of
connectivity, except when the user creates a physical island within connectivity, except when the user creates a physical island within
the topology. Some potentially pathological cases that can be the topology. Some potentially pathological cases that can be
created include bridging ports of a router together, however this created include bridging ports of a router together, however this
case can be detected and dealt with by the router. Loops within a case can be detected and dealt with by the router. Loops within a
routed topology are in a sense good in that they offer redundancy. routed topology are in a sense good in that they offer redundancy.
Bridging loops can be dangerous but are also detectable when a switch Topologies that include potential bridging loops can be dangerous but
learns the MAC of one of its interfaces on another or runs a spanning are also detectable when a switch learns the MAC of one of its
tree or link state protocol. It is only loops using simple repeaters interfaces on another or runs a spanning tree or link state protocol.
that are truly pathological. It is only topologies with such potential loops using simple
repeaters that are truly pathological.
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
skipping to change at page 15, line 15 skipping to change at page 15, line 17
3.2.2.1. A: Single ISP, Single CER, Internal routers 3.2.2.1. A: Single ISP, Single CER, Internal routers
Figure 1 shows a home network with multiple local area networks. Figure 1 shows a home network with multiple local area networks.
These may be needed for reasons relating to different link layer These may be needed for reasons relating to different link layer
technologies in use or for policy reasons, e.g., classic Ethernet in technologies in use or for policy reasons, e.g., classic Ethernet in
one subnet and a LLN link layer technology in another. In this one subnet and a LLN link layer technology in another. In this
example there is no single router that a priori understands the example there is no single router that a priori understands the
entire topology. The topology itself may also be complex, and it may entire topology. The topology itself may also be complex, and it may
not be possible to assume a pure tree form, for instance (because not be possible to assume a pure tree form, for instance (because
home users may plug routers together to form arbitrary topologies home users may plug routers together to form arbitrary topologies
including loops). including those with potential loops in them).
+-------+-------+ \ +-------+-------+ \
| Service | \ | Service | \
| Provider | | Service | Provider | | Service
| Router | | Provider | Router | | Provider
+-------+-------+ | network +-------+-------+ | network
| / | /
| Customer / | Customer /
| Internet connection | Internet connection
| |
skipping to change at page 20, line 26 skipping to change at page 20, line 26
require relatively significant router changes but avoid host changes. require relatively significant router changes but avoid host changes.
As explained previously, while NPTv6 has been proposed for providing As explained previously, while NPTv6 has been proposed for providing
multi-homing support in networks, its use is not recommended in the multi-homing support in networks, its use is not recommended in the
homenet architecture. homenet architecture.
It should be noted that some multihoming scenarios may see one It should be noted that some multihoming scenarios may see one
upstream being a "walled garden", and thus only appropriate for upstream being a "walled garden", and thus only appropriate for
connectivity to the services of that provider; an example may be a connectivity to the services of that provider; an example may be a
VPN service that only routes back to the enterprise business network VPN service that only routes back to the enterprise business network
of a user in the homenet. As per [RFC3002] (section 4.2.1) we do not of a user in the homenet. As per Section 4.2.1 of [RFC3002] we do
specifically target walled garden multihoming as a goal of this not specifically target walled garden multihoming as a goal of this
document. document.
The homenet architecture should also not preclude use of host or The homenet architecture should also not preclude use of host or
application-oriented tools, e.g., Shim6 [RFC5533], MPTCP [RFC6824] or application-oriented tools, e.g., Shim6 [RFC5533], MPTCP [RFC6824] or
Happy Eyeballs [RFC6555]. In general, any incremental improvements Happy Eyeballs [RFC6555]. In general, any incremental improvements
obtained by host changes should give benefit for the hosts obtained by host changes should give benefit for the hosts
introducing them, but not be required. introducing them, but not be required.
3.2.5. Mobility support
Devices may be mobile within the homenet. While resident on the same
subnet, their address will remain persistent, but should devices move
to a different (wireless) subnet, they will acquire a new address in
that subnet. It is desirable that the homenet supports internal
device mobility. To do so, the homenet may either extend the reach
of specific wireless subnets to enable wireless roaming across the
home (availability of a specific subnet across the home), or it may
support mobility protocols to facilitate such roaming where multiple
subnets are used.
3.3. A Self-Organising Network 3.3. A Self-Organising Network
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
skipping to change at page 28, line 34 skipping to change at page 28, line 45
Routing functionality is required when there are multiple routers Routing functionality is required when there are multiple routers
deployed within the internal home network. This functionality could deployed within the internal home network. This functionality could
be as simple as the current 'default route is up' model of IPv4 NAT, be as simple as the current 'default route is up' model of IPv4 NAT,
or, more likely, it would involve running an appropriate routing or, more likely, it would involve running an appropriate routing
protocol. Regardless of the solution method, the functionality protocol. Regardless of the solution method, the functionality
discussed below should be met. discussed below should be met.
The homenet unicast routing protocol should be 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. The availability of open that allows lightweight implementations, but that does not preclude
source implementations is an important consideration. It is the selection of a newer protocol for which a high quality open
desirable, but not absolutely required, that the routing protocol be source implemenation becomes available. The availability of open
able to give a complete view of the network, and that it be able to source implementations is an important consideration. Using
pass around more than just routing information. information distributed through the routing protocol, each node in
the homenet should be able to build a graph of the topology of the
whole homenet including links, nodes, connectivity, and (if the
routing protocol supports them) link metrics.
Multiple types of physical interfaces must be accounted for in the Multiple types of physical interfaces must be accounted for in the
homenet routed topology. Technologies such as Ethernet, WiFi, homenet routed topology. Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of coexisting in the same environment and should be treated as part of
any routed deployment. The inclusion of physical layer any routed deployment. The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the computation should be considered for optimising communication in the
homenet. homenet.
The routing protocol should support the generic use of multiple The routing protocol should support the generic use of multiple
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 BCP38 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.
The routing environment should be self-configuring, as discussed The routing environment should be self-configuring, as discussed
previously. An example of how OSPFv3 can be self-configuring in a previously. Minimising convergence time should be a goal in any
homenet is described in [I-D.ietf-ospf-ospfv3-autoconfig]. routed environment, but as a guideline a maximum convergence time at
Minimising convergence time should be a goal in any routed most 30 seconds should be the target (this target is somewhat
environment, but as a guideline a maximum convergence time at most 30 arbitrary, and was chosen based on how long a typical home user might
seconds should be the target (this target is somewhat arbitrary, and wait before attempting another reset; ideally the routers might have
was chosen based on how long a typical home user might wait before some status light indicating they are converging, similar to an ADSL
attempting another reset; ideally the routers might have some status router light indicating it is establishing a connection to its ISP).
light indicating they are converging, similar to an ADSL router light
indicating it is establishing a connection to its ISP).
As per prefix delegation, it is assumed that a single routing Homenets may use a variety of underlying link layer technologies, and
solution is in use in the homenet architecture. If there is an may therefore benefit from being able to use link metrics if
identified need to support multiple solutions, these must be available. It may be beneficial for traffic to use multiple paths to
interoperable. a given destination within the homenet whwre available, rather than a
single best path.
Ideally, a single routing protocol solution is in use at a given time
in a given homenet. If more than one routing protocol is defined for
use in a homenet, then a mechanism is required to ensure that all
routers in a given homenet support the same protocol before it is
used, and that a particular routing solution is enabled by default.
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.
In general, LLN or other networks should be able to attach and Ideally, LLN or other logically separate networks should be able
participate in the same way as the main homenet, or alternatively exchange routes such that IP traffic may be forwarded among the
map/be gatewayed to the main homenet. Current home deployments use networks via gateway routers which interoperate with both the homenet
largely different mechanisms in sensor and basic Internet and the LLN. Current home deployments use largely different
connectivity networks. IPv6 virtual machine (VM) solutions may also mechanisms in sensor and basic Internet connectivity networks. IPv6
add additional routing requirements. virtual machine (VM) solutions may also 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. media types, multicast routing is supported across the homenet.
[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
skipping to change at page 30, line 31 skipping to change at page 31, line 5
A homenet may not only use multicast internally, it may also be a A homenet may not only use multicast internally, it may also be a
consumer or provider of external multicast traffic, where the consumer or provider of external multicast traffic, where the
homenet's ISP supports such multicast operation. This may be homenet's ISP supports such multicast operation. This may be
valuable for example where live video applications are being sourced valuable for example where live video applications are being sourced
to/from the homenet. 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
Devices may be mobile within the homenet. While resident on the same
subnet, their address will remain persistent, but should devices move
to a different (wireless) subnet, they will acquire a new address in
that subnet. It is desirable that the homenet supports internal
device mobility. To do so, the homenet may either extend the reach
of specific wireless subnets to enable wireless roaming across the
home (availability of a specific subnet across the home), or it may
support mobility protocols to facilitate such roaming where multiple
subnets are used.
3.6. Security 3.6. Security
The security of an IPv6 homenet is an important consideration. The The security of an IPv6 homenet is an important consideration. The
most notable difference to the IPv4 operational model is the removal most notable difference to the IPv4 operational model is the removal
of NAT, the introduction of global addressability of devices, and of NAT, the introduction of global addressability of devices, and
thus a need to consider whether devices should have global thus a need to consider whether devices should have global
reachability. Regardless, hosts need to be able to operate securely, reachability. Regardless, hosts need to be able to operate securely,
end-to-end where required, and also be robust against malicious end-to-end where required, and also be robust against malicious
traffic directed towards them. However, there are other challenges traffic directed towards them. However, there are other challenges
introduced, e.g., default filtering policies at the borders between introduced, e.g., default filtering policies at the borders between
skipping to change at page 31, line 35 skipping to change at page 31, line 45
protocol such as PCP [RFC6887]. In networks with multiple CERs, the protocol such as PCP [RFC6887]. In networks with multiple CERs, the
signalling would need to handle the cases of flows that may use one signalling would need to handle the cases of flows that may use one
or more exit routers. CERs would need to be able to advertise their or more exit routers. CERs would need to be able to advertise their
existence for such protocols. existence for such protocols.
[RFC6092] expands on RFC 4864, giving a more detailed discussion of [RFC6092] expands on RFC 4864, giving a more detailed discussion of
IPv6 perimeter security recommendations, without mandating a 'default IPv6 perimeter security recommendations, without mandating a 'default
deny' approach. Indeed, RFC 6092 does not enforce a particular mode deny' approach. Indeed, RFC 6092 does not enforce a particular mode
of operation, instead stating that CERs must provide an easily of operation, instead stating that CERs must provide an easily
selected configuration option that permits a 'transparent' mode, thus selected configuration option that permits a 'transparent' mode, thus
ensuring a 'default allow' model is available. The homenet ensuring a 'default allow' model is available.
architecture text makes no recommendation on the default setting, and
refers the reader to RFC 6092. The topic of whether future home networks as described in this
document should have have a 'default deny' or 'default allow'
position has been discussed at length in various IETF meetings
without any consensus being reached on which approach is more
appropriate. Further, the choice of which default to apply may be
situational, and thus this text makes no recommendation on the
default setting beyond what is written on this topic in RFC 6092. We
note in Section 3.6.3 below that the implicit firewall function of an
IPv4 NAT is commonplace today, and thus future CERs targeted at home
networks should continue to support the option of running in 'default
deny mode', whether or not that is the default setting
3.6.2. Filtering at borders 3.6.2. Filtering at borders
It is desirable that there are mechanisms to detect different types It is desirable that there are mechanisms to detect different types
of borders within the homenet, as discussed previously, and further of borders within the homenet, as discussed previously, and further
mechanisms to then apply different types of filtering policies at mechanisms to then apply different types of filtering policies at
those borders, e.g., whether naming and service discovery should pass those borders, e.g., whether naming and service discovery should pass
a given border. Any such policies should be able to be easily a given border. Any such policies should be able to be easily
applied by typical home users, e.g., to give a user in a guest applied by typical home users, e.g., to give a user in a guest
network access to media services in the home, or access to a printer. network access to media services in the home, or access to a printer.
skipping to change at page 32, line 33 skipping to change at page 33, line 4
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 the capability
protection afforded, even if marginally effective, should not be to afford protection via a 'default deny' setting, even if marginally
lost. Thus, while it is highly desirable that all hosts in a homenet effective, should not be lost. Thus, while it is highly desirable
be adequately protected by built-in security functions, it should that all hosts in a homenet be adequately protected by built-in
also be assumed that all CERs will continue to support appropriate security functions, it should also be assumed that all CERs will
perimeter defence functions, as per [RFC7084]. continue to support appropriate 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,
skipping to change at page 33, line 28 skipping to change at page 33, line 47
CER(s), as mandated by RFC 6204 requirement S-2, a ULA source address CER(s), as mandated by RFC 6204 requirement S-2, a ULA source address
may be taken as an indication of locally sourced traffic. This may be taken as an indication of locally sourced traffic. This
indication could then be used with security settings to designate indication could then be used with security settings to designate
between which nodes a particular application is allowed to between which nodes a particular application is allowed to
communicate, provided ULA address space is filtered appropriately at communicate, provided ULA address space is filtered appropriately at
the boundary of the realm. the boundary of the realm.
3.7. Naming and Service Discovery 3.7. Naming and Service Discovery
The homenet requires devices to be able to determine and use unique The homenet requires devices to be able to determine and use unique
names by which they can be accessed on the network. Users and names by which they can be accessed on the network, and which are not
devices will need to be able to discover devices and services used by other devices on the network. Users and devices will need to
available on the network, e.g., media servers, printers, displays or be able to discover devices and services available on the network,
specific home automation devices. Thus naming and service discovery e.g., media servers, printers, displays or specific home automation
must be supported in the homenet, and, given the nature of typical devices. Thus naming and service discovery must be supported in the
home network users, the service(s) providing this function must as homenet, and, given the nature of typical home network users, the
far as possible support unmanaged operation. service(s) providing this function must as far as possible support
unmanaged operation.
The naming system will be required to work internally or externally, The naming system will be required to work internally or externally,
be the user within the homenet or outside it, i.e., the user should be the user within the homenet or outside it, i.e., the user should
be able to refer to devices by name, and potentially connect to them, be able to refer to devices by name, and potentially connect to them,
wherever they may be. The most natural way to think about such wherever they may be. The most natural way to think about such
naming and service discovery is to enable it to work across the naming and service discovery is to enable it to work across the
entire homenet residence (site), disregarding technical borders such entire homenet residence (site), disregarding technical borders such
as subnets but respecting policy borders such as those between guest as subnets but respecting policy borders such as those between guest
and other internal network realms. Remote access may be desired by and other internal network realms. Remote access may be desired by
the homenet residents while travelling, but also potentially by the homenet residents while travelling, but also potentially by
skipping to change at page 34, line 4 skipping to change at page 34, line 25
and other internal network realms. Remote access may be desired by and other internal network realms. Remote access may be desired by
the homenet residents while travelling, but also potentially by the homenet residents while travelling, but also potentially by
manufacturers or other 'benevolent' third parties. manufacturers or other 'benevolent' third parties.
3.7.1. Discovering services 3.7.1. Discovering services
Users will typically perform service discovery through graphical user Users will typically perform service discovery through graphical user
interfaces (GUIs) that allow them to browse services on their network interfaces (GUIs) that allow them to browse services on their network
in an appropriate and intuitive way. Devices may also need to in an appropriate and intuitive way. Devices may also need to
discover other devices, without any user intervention or choice. discover other devices, without any user intervention or choice.
Either way, such interfaces are beyond the scope of this document, Either way, such interfaces are beyond the scope of this document,
but the interface should have an appropriate application programming but the interface should have an appropriate application programming
interface (API) for the discovery to be performed. interface (API) for the discovery to be performed.
Such interfaces may also typically hide the local domain name element Such interfaces may also typically hide the local domain name element
from users, especially where only one name space is available. from users, especially where only one name space is available.
However, as we discuss below, in some cases the ability to discover However, as we discuss below, in some cases the ability to discover
available domains may be useful. available domains may be useful.
We note that current zero-configuration service discovery protocols We note that current zero-configuration service discovery protocols
are generally aimed at single subnets. There is thus a choice to are generally aimed at single subnets. There is thus a choice to
make for multi-subnet homenets as to whether such protocols should be make for multi-subnet homenets as to whether such protocols should be
proxied or extended to operate across a whole homenet. In this proxied or extended to operate across a whole homenet. In this
context, that may mean bridging a link-local method, taking care to context, that may mean bridging a link-local method, taking care to
avoid loops, or extending the scope of multicast traffic used for the avoid packets entering looping paths, or extending the scope of
purpose. It may mean that some proxy or hybrid service is utilised, multicast traffic used for the purpose. It may mean that some proxy
perhaps co-resident on the CER. Or it may be that a new approach is or hybrid service is utilised, perhaps co-resident on the CER. Or it
preferable, e.g., flooding information around the homenet as may be that a new approach is preferable, e.g., flooding information
attributes within the routing protocol (which could allow per-prefix around the homenet as attributes within the routing protocol (which
configuration). However, we should prefer approaches that are could allow per-prefix configuration). However, we should prefer
backwardly compatible, and allow current implementations to continue approaches that are backwardly compatible, and allow current
to be used. Note that this document does not mandate a particular implementations to continue to be used. Note that this document does
solution, rather it expresses the principles that should be used for not mandate a particular solution, rather it expresses the principles
a homenet naming and service discovery environment. that should be used for a homenet naming and service discovery
environment.
One of the primary challenges facing service discovery today is lack One of the primary challenges facing service discovery today is lack
of interoperability due to the ever increasing number of service of interoperability due to the ever increasing number of service
discovery protocols available. While it is conceivable for consumer discovery protocols available. While it is conceivable for consumer
devices to support multiple discovery protocols, this is clearly not devices to support multiple discovery protocols, this is clearly not
the most efficient use of network and computational resources. One the most efficient use of network and computational resources. One
goal of the homenet architecture should be a path to service goal of the homenet architecture should be a path to service
discovery protocol interoperability either through a standards based discovery protocol interoperability either through a standards based
translation scheme, hooks into current protocols to allow some for of translation scheme, hooks into current protocols to allow some for of
communication among discovery protocols, extensions to support a communication among discovery protocols, extensions to support a
skipping to change at page 40, line 13 skipping to change at page 40, line 36
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 have the general goal of being self-organising and In this section we briefly review some initial considerations for
configuring, and thus the network elements should not need to be pro- operations and management in the type of homenet described in this
actively managed by the home user. Thus specific protocols that may document. It is expected that a separate document will define an
be available to manage the network are not discussed in this appropriate operations and management framework for such homenets.
document.
The network protocols used should, as far as possible, be able to As described in this document, the homenet should have the general
self-configure, e.g. for prefixes to be assigned to router goal of being self-organising and configuring from the network layer
interfaces, or for devices to use zero-configuration protocols to perspective, e.g. prefixes should be able to be assigned to router
discover services in the home. A home user would not be expected to, interfaces. Further, applications running on devices should be able
e.g., assign prefixes to links, or manage the DNS entries for the to use zero configuration service discovery protocols to discover
home network. Such expert operation should not be precluded, but it services of interest to the home user. In contrast, a home user
is not the norm. would not be expected, for example, to have to 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 The user may still be required to, or wish to, perform some
users, e.g., SSID name(s), or wireless security key(s). Users may configuration of the network and the devices on it. Examples might
also be expected to be aware of the functions of certain devices they include entering a security key to enable access to their wireless
connect, e.g., which are providing a server function, and they may be network, or choosing to give a 'friendly name' to a device presented
able to assign 'friendly names' to those devices, though service to them through service discovery. Configuration of link layer and
discovery protocols should make their selection as intuitive as application layer services is out of scope of this architectural
possible. principles document, but are likely to be required in an operational
homenet.
As discussed in Section 3.6.1 the default setting on the homenet-ISP While not being expected to actively configure the networking
border for inbound traffic may be default deny, default allow, or elements of their homenet, users may be interested in being able to
some position inbetween. Whatever the default position, it should be view the status of their networks and the devices connected to it, in
possible for the user to change the setting. which case appropriate network monitoring protocols will be required
to allow them to view their network, and its status, e.g. via a web
interface or equivalent. While the user may not understand how the
network operates, it is reasonable to assume they are interested in
understanding what faults or problems may exist on it. Such
monitoring may extend to other devices on the network, e.g. storage
devices, or web cameras, but such devices are beyond the scope of
this document.
Users may also be interested in the status of their networks and It may also be the case that an ISP, or a third party, might wish to
devices on the network, in which case simple self-monitoring offer a remote management service for the homenet on behalf of the
mechanisms would be desirable. This may be particularly important user, or to be able to assist the user in event of some problem they
when some fault arises in the network or with a device. It may also are experiencing, in which case appropriate management and monitoring
be the case that an ISP, or a third party, might offer management of protocols would be required.
the homenet on behalf of a user, in which case management protocols
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.
A final consideration is that all network management and monitoring The specific protocols required to facilitate homenet management and
functions should be available over IPv6 transport, even where the monitoring are out of scope of this document. As stated above, it is
homenet is dual-stack. expected that a separate document will be produced to describe the
operations and management framework for the types of home network
presented in this document.
As a final point, we note that it is desirable that all network
management and monitoring 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 52 skipping to change at page 45, line 32
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] [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-06 (work draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 (work
in progress), February 2014. in progress), February 2014.
[I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-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/
iab-statement-dotless-domains-considered-harmful>. iab-statement-dotless-domains-considered-harmful>.
skipping to change at page 46, line 5 skipping to change at page 46, line 24
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 12 B.1. Version 13
Changes made include:
o Changes to address last outstanding IESG DISCUSSes/COMMENTs.
B.2. 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 DISCUSS comments addressed. o Some further IESG DISCUSSes/COMMENTs addressed.
B.2. Version 11 (after IESG review) B.3. 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.3. Version 10 (after AD review) B.4. 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.4. Version 09 (after WGLC) B.5. 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 47, line 24 skipping to change at page 48, line 5
o Stated that this text does not recommend how to form largest o Stated that this text does not recommend how to form largest
possible subnets possible subnets
o Added text about homenet evolution and handling disparate media o Added text about homenet evolution and handling disparate media
types types
o Rephrased NAT/firewall text on marginal effectiveness o Rephrased NAT/firewall text on marginal effectiveness
o Emphasised that multihoming may be to any number of ISPs o Emphasised that multihoming may be to any number of ISPs
B.5. Version 08 B.6. 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.6. Version 07 B.7. 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 48, line 31 skipping to change at page 49, line 12
o Reordered section 3.3 to improve flow. o Reordered section 3.3 to improve flow.
o Added recommendation that homenet is not allocated less than /60, o Added recommendation that homenet is not allocated less than /60,
and a /56 is preferable. and a /56 is preferable.
o Tidied up first few intro sections. o Tidied up first few intro sections.
o Other minor edits from list feedback. o Other minor edits from list feedback.
B.7. Version 06 B.8. 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.8. Version 05 B.9. 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.9. Version 04 B.10. 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.10. Version 03 B.11. 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 50, line 38 skipping to change at page 51, line 20
the homenet. the homenet.
o Added some ISPs renumber due to privacy laws. o Added some ISPs renumber due to privacy laws.
o Removed extra repeated references to Simple Security. o Removed extra repeated references to Simple Security.
o Removed some solution creep on RIOs/RAs. o Removed some solution creep on RIOs/RAs.
o Load-balancing scenario added as to be supported. o Load-balancing scenario added as to be supported.
B.11. Version 02 B.12. 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. 55 change blocks. 
184 lines changed or deleted 219 lines changed or added

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