One document matched: draft-chown-homenet-arch-00.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2460 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY rfc4193 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY rfc4291 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc6092 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6092.xml'>
<!ENTITY rfc6204 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml'>
<!ENTITY rfc6296 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml'>
<!ENTITY I-D.baker-fun-multi-router
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-fun-multi-router.xml'>
<!ENTITY I-D.baker-fun-routing-class
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.baker-fun-routing-class.xml'>
<!ENTITY I-D.herbst-v6ops-cpeenhancements
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.herbst-v6ops-cpeenhancements.xml'>
<!ENTITY I-D.vyncke-advanced-ipv6-security
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vyncke-advanced-ipv6-security.xml'>
<!ENTITY I-D.ietf-v6ops-ipv6-cpe-router-bis
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-ipv6-cpe-router-bis.xml'>
<!ENTITY I-D.ietf-6man-rfc3484-revise
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-rfc3484-revise.xml'>
<!ENTITY I-D.ietf-dhc-pd-exclude
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-pd-exclude.xml'>
<!ENTITY I-D.v6ops-multihoming-without-ipv6nat
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.v6ops-multihoming-without-ipv6nat.xml'>
]>
<rfc ipr="trust200902"
docName="draft-chown-homenet-arch-00"
category="info">
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>
<front>
<title abbrev="IPv6 Home Networking">Home Networking Architecture for IPv6</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author fullname="Tim Chown" initials="T.J." surname="Chown">
<organization> University of Southampton </organization>
<address>
<postal>
<street> Highfield </street>
<city> Southampton </city>
<code> SO17 1BJ </code>
<region> Hampshire </region>
<country> United Kingdom </country>
</postal>
<email> tjc@ecs.soton.ac.uk </email>
</address>
</author>
<author initials="J" surname="Weil" fullname="Jason Weil">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<city>Herndon, VA</city><code>20171</code>
<country>USA</country>
</postal>
<email>jason.weil@twcable.com</email>
</address>
</author>
<author initials="O" surname="Troan" fullname="Ole Troan">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Drammensveien 145A</street>
<city>Oslo</city><code>N-0212</code>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
</address>
</author>
<date month="September" year="2011" />
<keyword>IPv6</keyword>
<abstract>
<t>This text describes the evolving networking technology within small
"residential home" networks. The goal of this memo is to define the
architecture for IPv6-based home networking. The text highlights the
impact of IPv6 on home networking, and illustrates some topology
scenarios. The architecture shows how standard IPv6 mechanisms and
addressing can be employed in home networking, lists a number of
principles that should apply, and outlines the need for specific
protocol extensions for certain additional functionality.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This memo focuses on the evolving networking technology within
small "residential home" networks and the associated challenges. For
example, a trend in home networking is the proliferation of networking
technology in an increasingly broad range of devices and media. This
evolution in scale and diversity sets requirements on IETF
protocols. Some of these requirements relate to the need for multiple
subnets for private and guest networks, the introduction of IPv6, and
the introduction of specialized networks for home automation and
sensors.</t>
<t> While advanced home networks have been built, most operate based
on IPv4, employ solutions that we would like to avoid such as network
address translation (NAT), or require expert assistance to set up. The
architectural constructs in this document are focused on the problems
to be solved when introducing IPv6 with a eye towards a better result
than what we have today with IPv4, as well as a better result than if
the IETF had not given this specific guidance.</t>
<t>This architecture document aims to provide the basis for how
standard IPv6 mechanisms and addressing <xref target="RFC2460"/> <xref
target="RFC4291"/> can be employed in home networking, while
coexisting with existing IPv4 mechanisms. Some general principles for
the architecture are listed. At this stage it is vital that
introducing IPv6 does not adversely affect IPv4 operation. Future
deployments, or potentially specific subnets within an otherwise
dual-stack home network, may be IPv6-only.</t>
<t>
Currently some parts of this text are somewhat "chatty", which is
intended to solicit feedback on the issues presented.
</t>
</section>
<section anchor="trends" title="Effects of IPv6 on Home Networking">
<t>
Service providers are deploying IPv6, content is becoming available on
IPv6, and support for IPv6 is increasingly available in devices and
software used in the home. While IPv6 resembles IPv4 in many ways, it
changes address allocation principles, makes multi-addressing the
norm, and allows direct IP addressability and routing to devices in
the home from the Internet. The following is an overview of some of
the key areas impacted by the implementation of IPv6 into the home
network that are both promising and problematic:
<list style="hanging">
<t hangText="Multiple segments"><vspace blankLines="1"/>
While less complex layer 3 topologies involving as few
subnets as possible are preferred in home networks for a variety of
reasons including simpler management and service discovery,
incorporation of dedicated segments remains necessary for some
cases.
</t>
<t>
For instance, a common feature in modern home routers is the
ability to support both guest and private network segments. Also, link
layer networking technology is poised to become more heterogeneous, as
networks begin to employ both traditional Ethernet technology and link
layers designed for low-powered sensor networks. Similar
needs for segmentation may occur in other cases, such as separating
building control or corporate extensions from the Internet access
network. Also, different segments may be associated with subnets that have
different routing and security policies.</t>
<t>Documents that provide some more specific background and depth on this topic include:
<xref target="I-D.herbst-v6ops-cpeenhancements"></xref>,
<xref target="I-D.baker-fun-multi-router"></xref>, and
<xref target="I-D.baker-fun-routing-class"></xref>.</t>
<t> In addition to routing, rather than NATing, between subnets,
there are issues of when and how to extend mechanisms such as service
discovery which currently rely on link-local addressing to limit
scope. </t>
<t>
The presence of a multiple segment, multi-router network implies that
there is some kind of automatic routing mechanism in place. In advanced
configurations similar to those used in multihomed corporate networks,
there may also be a need to discover border router(s) by an
appropriate mechanism.
</t>
<t hangText="Multi-Addressing of devices"><vspace blankLines="1"/>
In an IPv6 network, devices may acquire multiple addresses, typically
at least a link-local address and a globally unique address. Thus it
should be considered the norm for devices on IPv6 home networks to be
multi-addressed, and to also have an IPv4 address where the network is
dual-stack. Default address selection mechanisms <xref
target="I-D.ietf-6man-rfc3484-revise"/> allow a node to select
appropriate src/dst address pairs for communications, though such
selection may face problems in the event of multihoming, where nodes
may have multiple globally unique addresses and multiple exit routers
associated with them.
</t>
<t hangText="Unique Local Addresses (ULAs)"><vspace blankLines="1"/>
<xref target="RFC4193"></xref> defines Unique Local Addresses (ULAs)
for IPv6
that may be used to address devices within the scope of a single
site. Support for ULAs for CPEs is described in
<xref target="RFC6204"></xref>.
</t>
<t>
A home network running IPv6 may deploy ULAs for communication between
devices within the network. Address selection mechanisms should
ensure a ULA source address is used to communicate with ULA destination
address. The use of ULAs does not imply IPv6 NAT, rather that external
communications should use a node's global IPv6 source address.
</t>
<t hangText="Security, Borders, and the elimination of NAT"><vspace blankLines="1"/>
The end-to-end communication that is promised with IPv6 is both an
incredible opportunity for innovation and simpler network operation,
but it is also a concern as it exposes nodes in the internal
networks to receipt of otherwise unwanted traffic from the
Internet. Firewalls that restrict incoming connections may be used to
prevent exposure, however, this reduces the efficacy of end-to-end
connectivity that IPv6 has the potential to
restore. <xref target="RFC6092"></xref> provides recommendations for
an IPv6 firewall that applies "limitations on end-to-end transparency
where security considerations are deemed important to promote local
and Internet security." The firewall operation is "simple" in that
there is an assumption that traffic which is to be blocked by default
is defined in the RFC and not expected to be updated by the user or
otherwise. The RFC also discusses an option for CPEs to have an
option to be put into a "transparent mode" of operation.
</t>
<t>
It is important to distinguish between addressability and reachability;
i.e. IPv6 through use of globally unique addressing in the home makes
all devices potentially reachable from anywhere. Whether they are or
not should depend on firewall or filtering behaviour, and not the
presence or use of NAT.
</t>
<t>
<xref target="I-D.vyncke-advanced-ipv6-security">Advanced
Security for IPv6 CPE</xref> takes the approach that in order to
provide the greatest end-to-end transparency as well as security,
security polices must be updated by a trusted party which can provide
intrusion signatures an other "active" information on security
threats. This is much like a virus-scanning tool which must receive
updates in order to detect and/or neutralize the latest attacks as
they arrive. As the name implies "advanced" security requires
significantly more resources and infrastructure (including a source
for attack signatures) vs. "simple" security.
</t>
<t>
In addition to the security mechanisms themselves, it is important to
know where to enable them. If there is some indication as to which
router is connected to the "outside" of the home network, this is
feasible. Otherwise, it can be difficult to know which security
policies to apply where. Further, security policies may be different
for various address ranges if ULA addressing is setup to only operate
within the homenet itself and not be routed to the Internet at large.
Finally, such policies must be able to be applied by typical
home users, e.g. to give a visitor in a 'guest' network access to
media services in the home.
</t>
<t>
It may be useful to classify the border of the home network as a unique
logical interface separating the home network from service provider
network/s. This border interface may be a single physical interface to
a single service provider, multiple layer 2 sub-interfaces to a single
service provider, or multiple connections to a single or multiple providers.
This border is useful for describing edge operations and interface
requirements across multiple functional areas including security, routing,
service discovery, and router discovery.
</t>
<t hangText="Naming, and manual configuration of IP addresses"><vspace blankLines="1"/>
In IPv4, a single subnet NATed home network environment is currently the
norm. As a result, it is common practice to reach a router for configuration,
DNS resolver functions, or otherwise via 192.168.1.1 or some other
commonly used RFC 1918 address. In IPv6, while ULAs exist and could
potentially be used to address internally-reachable services, little
deployment experience exists to date. In addition, generally IPv6
addresses are more cumbersome for humans to manually configure, with a
true ULA prefix effectively being a random 48-bit prefix. As such, even
for the simplest of functions,
naming and the associated discovery of services is imperative for an
easy to administer homenet. </t>
<t>
Naming and service discovery are thus important, but they may also be
expected to operate across the scope of the entire home network, despite
crossing subnet boundaries. It should be noted that in IPv4, these services
do not generally function across home router NAT boundaries, so this would
be one area where there is room for an improvement in IPv6.
</t>
</list></t>
</section>
<section anchor="arch" title="Architecture">
<t>An architecture outlines how to construct home networks involving
multiple routers and subnets. In the next section this text presents a
few typical home network topology models/scenarios, followed by a list of
topics that may influence the architecture discussions. This is
followed by a set of architectural
principles that govern how the various nodes should work
together. Finally, some guidelines are given for realizing the
architecture with the IPv6 addressing architecture, prefix delegation,
global and ULA addresses, source address selection rules and other
existing components of the IPv6 architecture. The architecture also
drives what protocols extensions are necessary, as will be discussed
in <xref target="miss"/>.
</t>
<section title="Network Models">
<t>Figure 1 shows the simplest possible home network topology,
involving just one router, a local area network, and a set of
hosts. Setting up such networks is in principle well understood today
<xref target="RFC6204"/>.</t>
<figure align="left" anchor="Figure.1 ">
<preamble></preamble>
<artwork align="left">
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+------+--------+ /
| | End-User
Local Network | | network(s)
---+-----+-------+--- \
| | \
+----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | /
| | | | /
+----------+ +-----+----+ /
</artwork>
<postamble></postamble>
</figure>
<t>Figure 2 shows another network that now introduces multiple local
area networks. These may be needed for reasons relating to different
link layer technology or for policy reasons. Note that a common
arrangement is to have different link types supported on the same
router, bridged together. For the purposes of this memo and IP layer
operation this arrangement is considered equivalent to the topology in
Figure 1.</t>
<t>
This topology is also relatively well understood today
<xref target="RFC6204"/>, though it certainly presents additional
demands with regards suitable firewall policies and limits the
operation of certain applications and discovery mechanisms (which
may typically today only succeed within a single subnet).</t>
<figure align="left" anchor="Figure.2 ">
<preamble></preamble>
<artwork align="left">
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+------+--------+ | network
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+----+-------+--+ /
Network A | | Network B | End-User
---+-------------+----+- --+--+-------------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
</artwork>
<postamble></postamble>
</figure>
<t>Figure 3 shows a little bit more complex network with two routers
and eight devices connected to one ISP. This network is similar to the
one discussed in
<xref target="I-D.ietf-v6ops-ipv6-cpe-router-bis"/>. The main
complication in this topology compared to the ones described earlier
is that there is no longer a single router that a priori understands
the entire topology. The topology itself may also be complex. It may
not be possible to assume a pure tree form, for instance. This
would be a consideration if there was an assumption that home users
may plug routers together to form arbitrary topologies.</t>
<figure align="left" anchor="Figure.3 ">
<preamble></preamble>
<artwork align="left">
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | |
+----+-+---+----+ |
Network A | | | Network B/E |
----+-------------+----+ | +---+-------------+------+ |
| | | | | | | |
+----+-----+ +-----+----+ | +----+-----+ +-----+----+ | |
|IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | |
| | | | | | | | | | |
+----------+ +-----+----+ | +----------+ +----------+ | |
| | | | |
| ---+------+------+-----+ |
| | Network B/E |
+------+--------+ | | End-User
| IPv6 | | | networks
| Interior +------+ |
| Router | |
+---+-------+-+-+ |
Network C | | Network D |
----+-------------+---+- --+---+-------------+--- |
| | | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+ |
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | |
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
</artwork>
<postamble></postamble>
</figure>
<figure align="left" anchor="Figure.4 ">
<preamble></preamble>
<artwork align="left">
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+------+--------+ +-------+-------+ | network
| | /
| Customer | /
| Internet connections | /
| |
+------+--------+ +-------+-------+ \
| IPv6 | | IPv6 | \
| Customer Edge | | Customer Edge | \
| Router 1 | | Router 2 | /
+------+--------+ +-------+-------+ /
| | /
| | | End-User
---+---------+---+---------------+--+----------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+
</artwork>
<postamble></postamble>
</figure>
<t>
Figure 4 illustrates a multihomed home network model, where the
customer has connectivity via CPE1 to ISP A and via CPE2 to ISP B.
This example shows one shared subnet where IPv6 nodes would
potentially be multihomed and received multiple IPv6 global
addresses, one per ISP. This model may also be combined with
that shown in Figure 3 for example to create a more complex scenario.
</t>
<figure align="left" anchor="Figure.5 ">
<preamble></preamble>
<artwork align="left">
+-------+-------+ +-------+-------+ \
| Service | | Service | \
| Provider A | | Provider B | | Service
| Router | | Router | | Provider
+-------+-------+ +-------+-------+ | network
| | /
| Customer | /
| Internet | /
| connections | |
+---------+---------+ \
| IPv6 | \
| Customer Edge | \
| Router 1 | /
+---------+---------+ /
| | /
| | | End-User
---+---------+---+-- --+--+----------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
|IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+
</artwork>
<postamble></postamble>
</figure>
<t>
Figure 5 illustrates a model where a home network may have multiple
connections to multiple providers or multiple logical connections to
the same provider, but the associated subnet(s) are isolated.
Some deployment scenarios may require this model.
</t>
</section>
<section anchor="req" title="Requirements">
<t><xref target="RFC6204"/> defines "basic" requirements for IPv6
Customer Edge Routers,
while <xref target="I-D.ietf-v6ops-ipv6-cpe-router-bis"></xref>
describes "advanced" features. In general, home network equipment needs to
cope with the different types of network topologies discussed above. Manual
configuration is rarely, if at all, possible, given the knowledge lying
with typical home users. The equipment needs to be prepared
to handle at least
<list style="symbols">
<t>Prefix configuration for routers</t>
<t>Managing routing</t>
<t>Name resolution</t>
<t>Service discovery</t>
<t>Network security</t>
</list></t>
</section>
<section title="Considerations">
<t>
This section lists some considerations for home networking that may
affect the architecture depending on how or if they are included.
Comments are certainly required here.
</t>
<t>
<list style="hanging">
<t hangText="Multihoming"><vspace blankLines="1"/>
A home network may be multihomed to multiple providers. This may either
take a form where there are multiple isolated networks within the home or
a more integrated network where the connectivity selection is dynamic.
Current practice is typically of the former kind.
</t>
<t>
In an integrated network,
specific appliances or applications may use their own external connectivity,
or the entire network may change its connectivity based on the status
of the different upstream connections. Many general solutions for IPv6
multihoming
have been worked for years in the IETF and to date there is little
deployment of these mechanisms. An argument can be made that
home networking standards should not make another attempt at this.
An obvious counter-argument is that multihoming support may be
necessary for many deployment situations.
</t>
<t>
In any case, if multihoming is supported, additional requirements are
necessary as described in <xref target="I-D.baker-fun-multi-router"/>.
In the case of multiple exit routers, either
the use of NAT66 <xref target="RFC6296"/>
or an alternative approach may be needed, e.g.
<xref target="I-D.v6ops-multihoming-without-ipv6nat"/>.
One could also argue that a "happy
eyeballs" viewpoint, not too dissimilar to that proposed for
multiple interface (mif) scenarios is also acceptable. The central part of
the arguments about IPv6 multihoming is whether all devices exist in the
same multihomed network, and if they, do they have one or multiple IPv6
addresses.
</t>
<t hangText="Quality of Service in multi-service home networks"><vspace blankLines="1"/>
Support for QoS between multiple services may be a requirement,
e.g. for a critical system (perhaps healthcare related), or for
differentiation between different types of traffic (file sharing,
cloud storage, live streaming, VoIP, etc). Different media types
may have different QoS properties or capabilities.
</t>
<t>
A counter-argument for adding any specific support for home networking
related standards is that again, there is little practical deployment of
QoS mechanism even in the general networking world, let alone home networks.
It could also be argued that simpler mechanisms are more cost-effective,
such as ensuring proper
buffering algorithms to avoid the bufferbloat problem as described
in <xref target="Gettys11"/>.
</t>
<t hangText="DNS services"><vspace blankLines="1"/>
Consideration will need to be given for existing protocols that
may be used within a network, e.g. mDNS. With the introduction of
new top level domains, there is potential for ambiguity between
for example a local host called apple and (if it is registered)
an apple gTLD, so some local name space is probably required, and
one that may be configurable by a home user. It is probably
desirable to have DNS treated the same within a home network for
IPv4 and IPv6. This will fall under the naming and service
discovery requirements. More input needed here.
</t>
<t hangText="Privacy considerations"><vspace blankLines="1"/>
There has been some suggestion to include privacy consideration in
homenet. What do we want to say about that here?
</t>
</list>
</t>
</section>
<section title="Principles">
<t>There is little that the Internet standards community can do about
the physical topologies or the need for some networks to be separated
at the network layer for policy or link layer compatibility reasons.
However, there is a lot of flexibility in using IP addressing and
inter-networking mechanisms. It would be desirable to provide some
guidance on how this flexibility should be used to provide the best
user experience and ensure that the network can evolve with new
applications in the future.</t>
<t>The authors believe that the following principles guide us in
designing these networks in the correct manner. There is no
implied priority by the order in which the principles are listed.</t>
<t>
<list style="hanging">
<t hangText="Reuse existing protocols"><vspace blankLines="1"/>
It is desirable to reuse existing protocols where possible, but at
the same time to avoid consciously precluding the introduction of new or
emerging protocols. For example,
<xref target="I-D.baker-fun-routing-class"></xref> suggests introducing
a routing protocol that may may route on both source and destination
addresses. Protocols used should be backwardly compatible.
</t>
<t>
Do we wish to say anything about other home networking related
standards or groups, e.g. DLNA?
</t>
<t hangText="Dual-stack Operation"><vspace blankLines="1"/>
Any solutions for IPv6 must not adversely affect IPv4 operation.
While RFC 6204 is targeted at IPv6-only networks,
it is likely that dual-stack home networks will be the norm for
some period of time, but IPv6-only home networks will be deployed
in due course, perhaps first in "greenfield" scenarios, or
may appear as one element of an otherwise dual-stack network.
It is likely that topologies of IPv4 and IPv6 networks would be
as congruent as possible.
</t>
<t>
Should the text say anything to say about transition tool use?
Some discussion has
also happened on mapping of external IPv6 addresses to internal IPv4 ones.
</t>
<t hangText="Largest Possible Subnets"><vspace blankLines="1"/>
Today's IPv4 home networks generally have a single subnet, and
early dual-stack deployments have a single congruent IPv6 subnet,
possibly with some bridging functionality. Future home networks
are highly likely to need multiple subnets, for reasons described
earlier. As part
of the self-organization of the network, the network should subdivide
itself to the largest possible subnets that can be constructed with
the constraints of link layer mechanisms, bridging, physical
connectivity, and policy. For instance, separate subnetworks are
necessary where two different links cannot be bridged, or when a
policy requires the separation of a private and visitor parts of the
network.</t>
<t>
While it may be desirable to maximise the chance of link-local
protocols succeeding, multiple subnet home networks are inevitable,
so their support must be included.
A general recommendation is to follow the same topology for IPv6
as is used for IPv4, but not to use NAT. Thus there should be
routed IPv6 where an IPv4 NAT is used, and where there is no NAT
there should be bridging.
</t>
<t>
** Perhaps add a Figure here to illustrate the principle.
</t>
<t hangText="Transparent End-to-End
Communications"><vspace blankLines="1"/> An IPv6-based home network
architecture should naturally offer a transparent end-to-end
communications model. Each device should be addressable by a unique
address. Security perimeters can of course restrict the end-to-end
communications, but it is much easier to block certain nodes from
communicating than it is to re-enable nodes to communicate if they
have been hidden behind address translation devices.</t>
<t>
As discussed previously, it is important to note
the difference between addressable and
reachable. So filtering is to be expected, but NAT is not. For
configuring filters, protocols for securely associating
devices would be desirable. The use of protocols including
uPnP or PCP may be expected. A default 'transparent mode' (as per
RFC6092) may be used.
</t>
<t>
Local addressing (ULAs) may be used within the scope of a home network.
Should ULAs be encouraged for all devices or only those intended to
have internal connectivity only? IPv4 "thinking" would incorrectly
associate ULAs with use of NAT.
</t>
<t hangText="IP Connectivity between All Nodes"><vspace blankLines="1"/>
A logical consequence of the end-to-end
communications model is that the network should attempt to provide
IP-layer connectivity between all internal parts as well as between
the internal parts and the Internet. This connectivity should be
established at the link layer, if possible, and using routing at the
IP layer otherwise.</t>
<t>
Some home networking scenarios/models may involve isolated subnet(s)
with their own CPEs. In such cases connectivity would only be expected
within each isolated network (though traffic may potentially
pass between them via external providers).
</t>
<t hangText="Routing functionality"><vspace blankLines="1"/>
Routing functionality is required when multiple subnets are in use.
This functionality could be as simple as the current "default route is up"
model of IPv4 NAT, or it could be running an actual routing protocol.
</t>
<t>
The requirements for solutions in this area are unclear, but it seems likely
that a solution is required and that it should be something that can work
across different types of devices in the same home network.
</t>
<t>
If an actual routing protocol is needed, is it necessary to pick one? If there
are multiple protocols, will some kind of negotiation be needed?
</t>
<t>
If one routing protocol is recommended, which one should it be? Should the
selection of the solution be guided by what already exists in most
devices (the running code approach) or what satisfies the full
requirements (the design principle)?
</t>
<t>
Should sensor and machine-to-machine communication networks be
dealt with as separate networks, or as a part of the routing mechanisms
that handle the entire home network? Or are the requirements and mechanisms
for home networks too different from these specialized, low-power networks
that attempting to use one solution would merely cause harm? Current home
deployments use largely different mechanisms in sensor and basic Internet
connectivity networks.
</t>
<t hangText="Self-Organization"><vspace blankLines="1"/>A home network
architecture should be naturally self-organizing and self-configuring
under different circumstances relating to connectivity status to the
Internet, number of devices, and physical topology.</t>
<t hangText="Least Topology Assumptions"><vspace blankLines="1"/>
There should be ideally no built-in assumptions about the topology in home
networks, as users are capable of connecting their devices in
ingenious ways. Thus arbitrary topologies will need to be supported.</t>
<t hangText="Discovery"><vspace blankLines="1"/>
The most natural way to think about naming and service discovery
within a home is
to enable it to work across the entire residence, disregarding technical
borders such as subnets but respecting policy borders such as those
between visitor and internal networks.</t>
<t>
This implies support for IPv6 multicast across the scope of the
home network, and thus at least all routing devices in the network.
</t>
<t hangText="Proxy or Extend?"><vspace blankLines="1"/>
Related to the above,
it would be desirable to decide whether in general existing protocols
that are designed to only work within a subnet are modified/extended
to work across subnets, or whether proxy capabilities are defined
for those functions.
</t>
<t>
We may need to do more analysis (a survey?) on which functions/protocols
assume subnet-only operation, in the context of existing home networks (which
today are most commonly a single subnet).
Some experience from enterprises may be relevant here.
</t>
<t hangText="Adapt to ISP constraints"><vspace blankLines="1"/>
The home network may receive an arbitrary length IPv6 prefix from
its provider, e.g. /60 or /56. The offered prefix may be static or
dynamic. The home network needs to be adaptable to such ISP policies,
e.g. on constraints placed by the size of prefix offered by the ISP.
The ISP may use <xref target="I-D.ietf-dhc-pd-exclude"/> for example.
</t>
<t>
The internal operation of the home network should not also depend on
the availability of the ISP network at any given time, other than
for connectivity to services or systems off the home network.
</t>
<t hangText="Intelligent Policy"><vspace blankLines="1"/>As the
Internet continues to evolve, no part of the architecture or security
design should depend on hard coding acceptable or unacceptable traffic
patterns into the devices. Rather, these traffic patterns should be
driven off up-to-date databases in the Internet.</t>
<t>
This principle should also cover consideration to avoid hard coding
IP literals or taking other actions that unnecessarily complicate
any required home network renumbering operation.
</t>
</list>
</t>
</section>
<section anchor="miss" title="Implementing the Architecture on IPv6">
<t>The necessary mechanisms are largely already part of the IPv6
protocol set and common implementations. The few known
counter-examples are discussed in the following section. For automatic
routing, it is expected that existing routing protocols can be used as
is. However, a new mechanism may be needed in order to turn a selected
protocol on by default. Support for multiple exit routers and
multi-homing would also require extensions. For name resolution and
service discovery, extensions to existing multicast-based name
resolution protocols are needed to enable them to work across subnets,
within the scope of the home network.</t>
<t>The hardest problems in developing solutions for home networking
IPv6 architectures include discovering the right borders where the
domain "home" ends and the service provider domain begins, deciding
whether some of necessary discovery mechanism extensions should affect
only the network infrastructure or also hosts, and the ability to turn
on routing, prefix delegation and other functions in a backwards
compatible manner.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2460;
&rfc4193;
&rfc4291;
&rfc6092;
&rfc6204;
&rfc6296;
</references>
<references title="Informative References">
&I-D.baker-fun-multi-router;
&I-D.baker-fun-routing-class;
&I-D.herbst-v6ops-cpeenhancements;
&I-D.vyncke-advanced-ipv6-security;
&I-D.ietf-v6ops-ipv6-cpe-router-bis;
&I-D.ietf-6man-rfc3484-revise;
&I-D.ietf-dhc-pd-exclude;
&I-D.v6ops-multihoming-without-ipv6nat;
<reference anchor='Gettys11' target="http://www.ietf.org/proceedings/80/slides/tsvarea-1.pdf">
<front>
<title>Bufferbloat: Dark Buffers in the Internet</title>
<author initials="J." surname="Gettys" fullname=" Jim Gettys"> <organization />
</author>
<date month="March" year="2011" />
</front>
</reference>
</references>
<section title="Acknowledgments">
<t>The authors would like to thank to Stuart Cheshire, James Woodyatt,
Lars Eggert, Ray Bellis, David Harrington, Wassim Haddad,
Heather Kirksey, Dave Thaler, Fred Baker, and Ralph Droms for
interesting discussions in this problem space, and Mark Townsley
for being an initial editor/author of this text before taking his
position as homenet WG co-chair.</t>
<t>
** Additional acknowledgements TBA.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:47:10 |