One document matched: draft-arkko-townsley-homenet-arch-00.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902"
docName="draft-arkko-townsley-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 initials="M" surname="Townsley" fullname="Mark Townsley">
<organization>Cisco</organization>
<address>
<postal>
<street/>
<city>Paris</city><code>75006</code>
<country>France</country>
</postal>
<email>townsley@cisco.com</email>
</address>
</author>
<date month="July" year="2011" />
<keyword>IPv6</keyword>
<abstract>
<t>This memo focuses on the evolving networking technology within and
among relatively small "residential home" networks. The goal of this
memo is to define the architecture for IPv6-based home networking that
supports the demands placed on it. This architecture shows how
standard IPv6 mechanisms and addressing can be employed in home
networking, 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 and
among relatively small "residential home" networks and the associated
challenges. For example, an
obvious trend in home networking is the proliferation of networking
technology in an increasingly broad range and number of devices. This
evolution in scale and diversity sets some requirements on IETF
protocols. Some of these requirements relate to the need for
supporting 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 many 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 an 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 that are widely deployed.</t>
</section>
<section anchor="trends" title="Effects of IPv6 on Home Networking">
<t>
Service providers are deploying IPv6, widely accessed 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
and allows direct IP addressability and routing to devices in the home
from the Internet. Following is an overview of some of the areas of
that are both promising and problematic:
<list style="hanging">
<t hangText="Multiple segments"><vspace blankLines="1"/>
While less complex L3-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 remain necessary for some
cases. For instance, a common feature in modern home routers in 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. Finally, similar
needs for segmentation may occur in other cases, such as separating
building control or corporate extensions from the Internet access
network. 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">r</xref>, and
<xref target="I-D.baker-fun-routing-class"></xref>.</t>
<t> In addition to routing, rather than natting, 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 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 easy of network operation,
but it is also a concern as it 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. <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.
</t>
<t hangText="Naming, and manual configuration of IP addresses"><vspace blankLines="1"/>
In IPv4, it is common practice to reach a router for configuration,
DNS resolver functions, or otherwise via 192.168.1.1 or some other
well-known RFC 1918 address. In IPv6, there is no such address space
available, and generally IPv6 addresses are more cumbersome for humans
to manually configure. As such, even for the simplest of functions,
naming and the associated discovery of service is imperative for an
easy to administer homenet. </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 following this memo presents a
few typical home network topology models, followed by 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"/>.
<!-- This document applies 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> -->
<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 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>
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.</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>...</t>
<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 understand
the entire topology. The topology itself may also be complex, it may
not be possible to assume a pure tree form, for instance.</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>
<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 different types of network topologies discussed above. Manual
configuration is rarely, if at all, possible. 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>
<t>Additional requirements may stem from support for multi-homing or
multiple exit routers <xref target="I-D.baker-fun-multi-router"/>.</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
internetworking 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:</t>
<list style="hanging">
<t hangText="Largest Possible Subnets"><vspace blankLines="1"/>As part
of the self-organization of the netowrk, 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 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 local addressing domains and address
translation.</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 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 area capable of connecting their devices in
ingenious ways.</t>
<t hangText="Discovery"><vspace blankLines="1"/>The
most natural way to think about name 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 hangText="Intelligent Policy"><vspace blankLines="1"/>As the
Internet continues to evolve, no part of the architecture or security
design should depend on hardcoding acceptable or unacceptable traffic
patterns into the devices. Rather, these traffic patterns should be
driven off up-to-date databases in the Internet.</t>
</list>
</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. For prefix
configuration, existing protocols are likely sufficient, but may at
worst may need some small enhancements, such as new options. 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.</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">
<?rfc include="reference.RFC.2460.xml"?>
<?rfc include="reference.RFC.4291.xml"?>
<?rfc include="reference.RFC.6092.xml"?>
<?rfc include="reference.RFC.6204.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.baker-fun-multi-router.xml"?>
<?rfc include="reference.I-D.baker-fun-routing-class.xml"?>
<?rfc include="reference.I-D.herbst-v6ops-cpeenhancements.xml"?>
<?rfc include="reference.I-D.vyncke-advanced-ipv6-security.xml"?>
<?rfc include="reference.I-D.ietf-v6ops-ipv6-cpe-router-bis.xml"?>
</references>
<section title="Acknowledgments">
<t>The authors would like to thank to Stuart Cheshire, James Woodyatt,
Ole Troan, Lars Eggert, Ray Bellis, David Harrington, Wassim Haddad,
Heather Kirksey, Dave Thaler, Fred Baker, and Ralph Droms for
interesting discussions in this problem space.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:46:32 |