Internet DRAFT - draft-jvkjjmb-home-networking-incremental
draft-jvkjjmb-home-networking-incremental
Network Working Group V. Kuarsingh, Ed.
Internet-Draft Rogers Communications
Intended status: Informational J. Brzozowski
Expires: January 5, 2014 Comcast Cable Communications
C. Grundemann
CableLabs
J. McQueen
Broadcom Corporation
July 4, 2013
An incremental solution to advanced home networking
draft-jvkjjmb-home-networking-incremental-00
Abstract
The home network is an environment subject to ongoing evolution and
change. Many home networks today are simplistic in nature, often
comprising of a single router/gateway. The expectation over time is
predicated on the notion that the home network will be more complex
servicing many in-home and Internet functions. The home network will
evolve necessitating the replacement and update to current hardware
and software to more advanced devices and software capable of
operating in more complex environments. This document provides a
view on how the home network can progress from today's foundational
form, to a more advanced environment, using progressive technological
capabilities.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Kuarsingh, et al. Expires January 5, 2014 [Page 1]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
This Internet-Draft will expire on January 5, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kuarsingh, et al. Expires January 5, 2014 [Page 2]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Home Network Progression and Dynamics . . . . . . . . . . . . 6
3.1. Early Home Networks . . . . . . . . . . . . . . . . . . . 6
3.2. Home Network Upgrades and Evolution . . . . . . . . . . . 7
3.3. Home Networking Progression Considerations . . . . . . . . 7
3.4. Described Phases . . . . . . . . . . . . . . . . . . . . . 9
4. Phase 1: Elementary Network . . . . . . . . . . . . . . . . . 9
4.1. Service Potential . . . . . . . . . . . . . . . . . . . . 9
4.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Phase 2: Medius Network . . . . . . . . . . . . . . . . . . . 11
5.1. Service Potential . . . . . . . . . . . . . . . . . . . . 11
5.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Phase 3: Provectus Network . . . . . . . . . . . . . . . . . . 14
6.1. Service Service Potential . . . . . . . . . . . . . . . . 15
6.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Phase 4: Posterus Network . . . . . . . . . . . . . . . . . . 18
7.1. Service Potential . . . . . . . . . . . . . . . . . . . . 18
7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20
7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Kuarsingh, et al. Expires January 5, 2014 [Page 3]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
1. Introduction
The progression of the home IP network to more advanced states will
require an evolution from more primitive topologies and protocol
support to the eventual advanced topologies with more robust protocol
support. Home networks continue to advance from environments
originally intended to connect multiple subscriber hosts to a common
Internet connection to future environments where Internet,
teleworking, home automation, and other functions become common.
In support of this evolution, this document outlines an incremental
approach which begins with basic functionality laid out in [RFC6204]
and culminates with more advanced topologies and functions. The more
advanced home network would align well with the homenet architecture
as described in [draft-ietf-homenet-arch] along with potential
supporting technologies and concepts like Source Address Routing
[draft-troan-homenet-sadr], multi-homing
[draft-haddad-homenet-multihomed], IGP based prefix assignment
[draft-arkko-homenet-prefix-assignment] and/or
[draft-baker-homenet-prefix-assignment].
The criticality and evolution of the customer premises or home
network is growing in complexity and importance as the variety and
quantity of services being delivered using the Internet Protocol
continues to increase. Coupled with these growing needs and the
deployment of IPv6 an opportunity exists to advance the state of home
networking in an incremental fashion. The introduction of IPv6
support within the home today to facilitate the transition allows for
basic Internet access over IPv6, however, this is simply inadequate
long term. Home networking technology must advance beyond providing
access to Internet content, it must evolve with the goal to improve
the customer experience and ensure that the in home network
infrastructure is robust and reliable enough to support next
generation services.
As part of the evolution and the introduction of IPv6 support the
home network support for IPv4 must not be overlooked. Support for
IPv4 will remain in devices for years to come and IPv4 will likely
continue to be used within the home as IPv4 connectivity to the
Internet undergoes dramatic change during the transition to IPv6. As
such it is essential that efforts to modernize home networking not
only account for both IPv4 and IPv6, these activities must also allow
for an incremental approach that does not require flash upgrades of
the home networking infrastructure and technology or hardware
replacement.
Finally, as home networking technology continues to advance long term
the intermediate phases must strive for interoperability to help
Kuarsingh, et al. Expires January 5, 2014 [Page 4]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
ensure a seamless transition and to act as an enabler. This is
particular importance for brownfield adopters.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology
Home IP Network Router a node intended for home or small-office
use that forwards packets not explicitly
addressed to itself.
Customer Edge Router (CER) a router that connects the end-user
network to a service provider network.
Internal Router an additional router deployed in the home
or small-office network that is not
attached to a service provider network.
Note that this is a functional role; it is
expected that there will not be a
difference in hardware or software between
a CER and IR, except in such cases when a
CER has a dedicated non-Ethernet WAN
interface (e.g. DSL/cable/ LTE modem) that
would preclude it from operating as an IR.
Down Interface a router's attachment to a link in the end-
user network on which it distributes
addresses and/or prefixes. Examples are
Ethernet (simple or bridged), 802.11
wireless, or other LAN technologies. A
router may have one or more network-layer
down interfaces.
Service Provider an entity that provides access to the
Internet. In this document, a service
provider specifically offers Internet
access using IPv6, and may also offer IPv4
Internet access. The service provider can
provide such access over a variety of
different transport methods such as DSL,
cable, wireless, and others.
Kuarsingh, et al. Expires January 5, 2014 [Page 5]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
Up Interface a router's attachment to a link where it
receives one or more IP addresses and/or
prefixes. This is also the link to which a
CER or IR points its default route.
depth the number of layers of routers in a
network. A single router network would
have a depth of 1, while a router behind a
router behind a router would have a depth
of 3.
width The number of routers that can be directly
subtended to an upstream router. A network
with three directly attached routers behind
the CER would have a width of 3.
3. Home Network Progression and Dynamics
3.1. Early Home Networks
Early home networks, as those observed as of the writing of this
document, tend to be comprised of few routing zones and layer 3
boundaries. Most home networks attached to operator networks are
comprised of a single home LAN segment, or may often have a guest
network based on default capabilities of off the shelf vendor
platforms.
The object of early home network environments was closely related to
providing basic Internet connectivity for subscribers. This trend
started back in the late 90's and early 2000s when traditional
dial-up connections were replaced with more robust broadband
connections. These newer and faster connections provided the
bandwidth and flexibility to power home networks which typically used
a single gateway towards the Operator's network and Internet.
From an IPv6 perspective this approach was also adopted to ensure
that the transition from the use of IPv4 to IPv6 could begin. The
objective here has been to enable as long a period of time as
possible to encourage the incremental transition to the use of IPv6
while avoiding or delaying the use impactful and costly transition
technologies.
Subscriber expectations during the early network phases were to
connect multiple machines to the Internet over a single connection.
Early Internet services were often traditional web (HTTP), Mail
(SMPT/POP3/IMAP) and news (NNTP) among others. Most services other
then the Internet were often supported by legacy technologies. Such
Kuarsingh, et al. Expires January 5, 2014 [Page 6]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
other services may have included legacy Video (Cable and/or Satellite
TV), Voice (PSTN) and the like.
3.2. Home Network Upgrades and Evolution
The home network, although originally used for very basic Internet
connectivity, is now beginning to expand to support many more
services. Some of the historical expansion within the home includes
the use of the home network for Media like Photo viewing, Movies
viewing and communications between in-home devices. During the
2000s, the home network also saw a strong growth on how it was used
for more commercial functions such as online video streaming, peer to
peer communications, remote teleworking, and social networking.
The expansion to date did not necessarily require more complex home
networks, but did expand the use of the common IP connection provided
to subscribers. Some historical expansion within the home networks
were related to advancement of legacy services such as voice which
has transformed to VoIP in recent years. Operators often used
technological frameworks, such as Packet Cable [PacketCable], to
enable legacy services over IP. These newer functions expanded the
home network or at times the gateway functions attaching to the
operator's network. Future expansion and/or enhancements similar to
VoIP in some operator networks include IPTV.
The evolution of the home network continues as subscribers are
beginning to use the home network to connect many new IP enabled
devices. These new IP enabled devices include home security
endpoints, sensors, appliances, home electronics among many others.
As these new uses become prevalent in the home network, so do the
needs of the attached devices, and the somewhat arbitrary ecosystem
that is used to attach them. It is the expectation that this
expanding ecosystem will create more robust and topologically complex
home networks. It is not well understood how long or fast this
evolutionary path will take, but the evolution has started.
The topological attachment and addressing needs within the home
network will need to be supported by the infrastructure which
comprises the home network. The upstream operators will need to be
cognizant of this need such as to provide the correct address sizes
and/or address elements. The underlay routing platforms will also
need to support the evolving home network to allow for growth and
robust home network environment.
3.3. Home Networking Progression Considerations
Evolving from basic to intermediate or advanced home networks there
are a number of considerations. These considerations range from
Kuarsingh, et al. Expires January 5, 2014 [Page 7]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
technical matters specific to implementation to operational and
deployment considerations.
Unlike green field deployments most operators and customers must take
into consideration that existing products and services must continue
to be supported. It is also important to note that the process to
upgrade must be seamless and non-disruptive. Disruption during the
upgrade process will not only have direct impact to the customers of
the same, but also directly impact the operators who deliver the
same. Support call volumes and impacts to operator infrastructure
must be factored in to the process of new technology introduction
whether it is basic support for IPv6 Internet connectivity or
intermediate/advanced home networking.
While most modern home network devices are software upgradeable to
introduce new functionality, some feature and enhancements exceed
device capabilities. Further there is a large population of home
networking devices that are based on an earlier generation of
technology as such may not be upgradeable to even the most basic form
of home networking. Fortunately operators actively work to ensure
their infrastructure is modernized to ensure the greatest feature set
and performance are available to their customers.
For those platforms that are upgradeable, which is a non trivial
population for most operators, the implementation process can be
complex. Complexity is presented in many forms ranging from the
technical details to integration with other essential features that
must be supported. Technical functionality must be balanced with
simplicity. Features that are overly complex impact implementers,
customers, and operators. As such it is essential that technical
solutions be implementable and supportable by vendors, deployable by
operators, and usable by customers. Testing and interoperability are
critical aspects of advancing any technology; this is especially the
case with home networking largely due to the significant quantity of
unique devices that are in use with broadband enabled home networks.
The quantity and types of devices that are connected today are vast
and unique, there are probably very few home networks that are alike
today. As such innovators of the home network must ensure that they
develop the technologies with support for legacy devices while laying
the ground work for the next generation of connected devices and the
services that they enable.
Continued support for IPv4 to the Internet is a must at the time this
document was written. While efforts advance to someday enable IPv6
only with consumer electronics and content providers support for IPv4
remains essential and cannot be ignored or forgotten. Further, at
the time IPv6 only becomes a reality, it is likely that IPv4 (even
for dual stack in home devices) will continue to be used, possibly
Kuarsingh, et al. Expires January 5, 2014 [Page 8]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
for decades to comes. Since it is difficult to determine if or when
IPv4 will no longer be required operators and innovators must ensure
that IPv4 continues to be supported.
3.4. Described Phases
The phases described below are intended to provide a descriptive of
how the the overall transition from early home networks can evolve to
advanced home networks that support more complex functions. These
phases are labeled as "Elementary" (Initial), "Medius" (Middle),
"Provectus" (Advanced) and "Posterus" (Subsequent). The phase labels
chosen are for reference purposes only within this document and do
not hold any significance for global meaning.
4. Phase 1: Elementary Network
The Elementary network phase is closely associated to the basic
environment described in section two of this document. The phase is
based on basic connectivity from a simple home network toward the
Internet. As a starting point, future phases are built assuming this
phase was generally present. While some greenfield environments may
emerge, most future more advanced home networks will expand out of a
basic home network.
The Elementary network will likely have basic functionality at the
operator/Internet edge (subscriber's point of reference) as outlined
in [RFC6204]. In addition to IPv4 legacy functionality, [RFC6204]
lays out basic requirements for IPv6 connectivity. With reference to
IPv6, the main emphasis was the attachment of the home network to the
IPv6 Internet, along with any legacy attachment to the IPv4 Internet.
4.1. Service Potential
In the Elementary network, as noted, connectivity is quite basic and
allows a simple home network to connect to the IPv4 and/or IPv6
Internet. Services envisioned to be used in this phase are very
similar to those which are already well established. Such services
include traditional Internet services such as web (HTTP), mail, news,
ftp, peer to peer, social networking, teleworking among many others.
Given the simplistic topological nature of this phase, there is less
flexibility for downstream segments to be attached, and the in-home
environment that is supported is assumed to be flat in nature (single
layer 2 domain, with a potential secondary environment such as a
guest net). Attaching networks, like a sensor net may not be well
serviced in such a model since such environments may require layer 3
separation and/or advanced device functionality.
Kuarsingh, et al. Expires January 5, 2014 [Page 9]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
4.2. Topology
The topology in the Elementary phase is basic in nature and often
assumed to be flat with some exceptions for additional segments like
a guest net. The topology in this phase may bridge multiple switched
and WiFi environments. It is possible that tandem routers may show
up in the Elementary phase, and those environments would
topologically be downstream sub-network environments with little
integration with the upstream IPv4 environment and likely no support
for IPv6 on the sub-network/tandem LAN network (not shown in Figure 1
below).
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+---+-------+-+-+ /
Network A | | Network B (Guest) | End-User
---+-------------+----+- --+--+-------------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
| Host | | Host | | Host | | Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
Figure 1: Basic Home Network
4.3. Addressing
Addressing in the Elementary phase will be supported by legacy IPv4
addressing behaviours and IPv6 addressing behaviours as described in
[RFC6204]. IPv4 would operate much like it has for many years using
[RFC1918] addressing in the home network and translating (NAT44)
traffic flows to/from the Internet using a single IPv4 global address
assigned to the subscriber's gateway (operating facing interface).
IPv6 is expected to utilize a prefix delegation as described in
[RFC6204] and allow addresses from within the delegated prefix to be
assigned to hosts (or auto-configured by hosts using announced
prefix) on the guest network.
Kuarsingh, et al. Expires January 5, 2014 [Page 10]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
For cases where the operator supplies a single /64, only a single
segment can be supported on the home network. In cases where larger
prefixes are assigned to the subscriber's gateway, additional
segments can receive a /64 assignment for use on those segments. For
the most part, those segments are assumed to be attached directly off
the customer's edge router. Network side addressing will typically
be provided by DHCPv6 [RFC3633] or RADIUS [RFC4818].
4.4. Routing
Routing in the Elementary network is also quite basic in nature.
Since the layer 3 segments are typically attached to a single
gateway, routing is conducted by the single gateway which uses a
default route pointing to the upstream provider. The provider will
have gleaned routing state which is gleaned from the DHCPv6
transaction and/or RADIUS addressing as stated in the section above.
5. Phase 2: Medius Network
The Medius network extends and builds upon the concepts established
in the Elementary phase. The Medius network is intended to
incrementally enable and evolve the home network by going beyond
basic IPv4 and/or IPv6 access to the Internet. In the Medius phase,
the objective are to go beyond basic access to content and services
on the Internet. Medius leverages the basic concepts established in
the Elementary phase as building blocks for more advanced in home
functionality while acting as a foundation for future iterations of
home networking. Medius will not only act as an enabler but will
also provide criticality required transition capabilities to ensure
advanced phases can also be deployed seamlessly to both customers and
operators with minimal disruption.
5.1. Service Potential
Medius enables natively routable IP within a home or customer
premise. Leveraging mostly existing techniques and technology,
Medius fortifies and advances the home network to support the
delivery of next generation content and services while maintaining
balance from an implementation and deployment point of view. A
Medius home network alleviates the notion of nest IPv4 address and
port translation within a home or premises so that both IPv4 and IPv6
communications are high performance and reliable. Next generation
applications, services, and content will benefit greatly from a
native environment within the home as it is well known that address
and port translation not only introduce latency and delays but also
hamper the premise wide experience for customers. A native
environment will allow customers to take full advantage of all
Kuarsingh, et al. Expires January 5, 2014 [Page 11]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
devices and applications that are and will appear throughout their
home networks.
5.2. Topology
The topology of a Medius home network, unlike that of the Elementary
phase, will be that of a native IP network in that there is expected
to be no translation within the premises. The only place where
translation is likely to occur is at the premises edge facing the
Internet or service provider and will be for IPv4 only, which is
common place today for most home networks. Non-Medius devices will
continue to be supported, however, the experience and functionality
of a Medius environment may not be fully achievable. The Medius
network will leverage a tree topology and can support flexibility in
how sub-tended devices are connected and provisioned. However, while
the Medius topology can support sub-tended devices the expectation
here is that the advanced home networking phase will introduce
support for greater flexibility as the need arises. The flexibility
of the Medius topology meets the near to mid term flexibility
requirements for the customer premises. In a Medius home network
interface detection is supported allowing for devices to be connected
and reconnected to one another in a manner that will enable each to
be reconfigured along with any connected devices. Unlike the
Elementary phase, Medius will support multiple routed segments and a
home network hierarchy not just a primary segment and guest segment
providing greater flexibility in how devices within the customer
premises connect and access content and services over the internal
segments and on the Internet.
Kuarsingh, et al. Expires January 5, 2014 [Page 12]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
| /
| Customer /
| Internet connection /
|
+------+--------+ \
| IPv6 | \
| Customer Edge | \
| Router | /
+---+-------+-+-+ /
Network A | | Network B | End-User
---+-------------+----+- --+--+-------------+--- | network(s)
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
| Host | |Internal | | Host| |Internal | /
| | | Router | | | | Router | /
+----------+ +-----+----+ +----------+ +----------+ /
Network C | Network D | |
---+-------------+----+- --+--+-------------+--- |
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
| Host | | Host | | Host| | Host | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
Figure 2: Progressive Home Network
5.3. Addressing
The Medius network assumes greater flexibility and extensibility, and
as such, the addressing within the premises must be comparable.
Nodes or endpoints will be able to leverage all common techniques for
both IPv4 and IPv6 addresses. For IPv4, DHCP and static addressing
will be supported, however, dynamic addressing techniques are
preferred. For IPv6, stateless auto-configuration with [RFC6106]
support, stateless and stateful DHCPv6, and static addressing are all
supported. Stateful DHCPv6 includes support for IPv6 prefix
delegation [RFC3633]. For IPv6, all forms of dynamic addressing are
preferred over any form of static assignments.
Sub-tended routing devices in a Medius home network will leverage
IPv6 prefix delegation [RFC3633]. The width and depth of the duo
home network will provide the guidance required to determine the size
of sub-delegated prefixes to ensure the greatest depth and width for
Kuarsingh, et al. Expires January 5, 2014 [Page 13]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
a Medius home network. While Medius home networks have flexibility
for sub-delegated networks, it is expected that the typical Medius
home network will have a limited quantity of connected, sub-tended
devices. The overarching objective of the Medius network is to
alleviate overly flat home networks while enabling high performance,
reliably home networks that can be used to provide service to and
support next generation content, services, and applications.
In a Medius home network, IPv6 techniques can be leveraged to
bootstrap the provisioning and enablement of IPv4 natively. The
provisioning and enablement of IPv4 care of IPv6 enables congruent
IPv4 and IPv6 topologies and routing within a customer premises.
Congruent IPv4 and IPv6 help to ensure that ideal conditions are in
place within the home to enable the greatest performance,
reliability, and stability by dynamically altering security and
routing configurations. The details of IPv6 bootstrapped IPv4
provisioning is out of scope for this document.
5.4. Routing
The Medius home network does not currently require a dynamic routing
protocols for routing or provisioning purposes. Provisioning
techniques specified for Medius home networks are outlined in the
addressing section above. Routing for duo home networks is governed
by each routing device. The customer or premise edge router (facing
the Internet or service provider) is aware of both IPv4 and IPv6
routing information, care of the provisioning process, for sub-tended
device. Each router in a duo home network will act as a default
route for all connected devices. If a routing device supports
multiple connected, routed segments, routing information for all
connected segments will be known inherently by the device, otherwise,
the device will send all traffic to its own default route learned
from its "up" interface.
The Medius topology, addressing, and routing collectively act as
foundational elements for future states of the home network. In
fact, advanced home networking techniques may not be achievable
without aspects of Mediux being deployed in customer premises
networks.
6. Phase 3: Provectus Network
The Provectus phase is a progressive option beyond the Medius network
with the option to turn on a routing protocol. Efficiency can be
gained here while keeping addressing common from the previous model.
This model effectively allows for a routing protocol to be added
(will be explained in routing section below in more detail) allowing
Kuarsingh, et al. Expires January 5, 2014 [Page 14]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
for better flow efficiency in-home, likely helping more advanced home
networks where there are more in-home services/operations.
A routing protocol can be added to an existing Medius Network as an
"add on" feature. Among the advantages of having a routing protocol
enabled is that it provides an efficient and dynamic network topology
in the home. With respect to efficiency, a routing protocol will aid
in maintaining a routing table with the sense of metric or hops to
destinations. Additionally, a routing protocol can aid in the
network dynamic scalability.
The details of which specific routing protocol to use are out of
scope for this text; however, we will discuss how some of the common
routing protocols could help improve on an existing Medius Network.
6.1. Service Service Potential
The main service advantage of a Provectus Network is that it will
provide more seamless flexibility and transition when routers in the
home are either added, removed, or moved to a different location in
the network. Additionally, a routing protocol can provide a more
seamless transition upon IP configuration changes. It is important
to note that the added flexibility and efficiency may be lost when
there are inline routers which do not support or enable the same
routing protocol. In such a case, the system may revert to the
Medius network operation (not as efficient, but functional).
6.2. Topology
The topology for the Provectus network phase is expected to be
similar to that of the Medius network phase.
6.3. Addressing
The Provectus Network IP addressing considerations match those of the
Medius phase with all IP addressing adhering to the HIPNet DHCPv6 and
recursive prefix delegation model described above.
All downstream routers to the CER will request an IPv6 prefix (IA_PD)
via DHCPv6 along with an IPv6 address (IA_NA). DHCPv6 will provide
address and prefix information for a specific lifetime.
Upstream routers are able to create a routing table based on the
address and prefix information provided to downstream routers while
the DHCP lease is active. Without a routing protocol, upstream
routers will not be instantly aware of when a downstream router is
being removed from or moved within the home network. The upstream
routers will eventually learn of a removed or moved router when the
Kuarsingh, et al. Expires January 5, 2014 [Page 15]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
DHCPv6 lifetime expires or if the router imposes other gleaning or
keep alive logic to track router movement.
In another scenario, an upstream HIPnet router's width or depth could
be presently maximized and there is the need to replace one router
connected on the width or depth with another router. The upstream
router will be unable to provision the new router on the network
until it detects that the previous router has been removed from the
network. Without a routing protocol, the time needed to discover
this topology change will most likely be longer and it places a
dependency on the router which is not implementing a routing protocol
to assure that it cleans up its own routing table when DHCP leases
expire.
6.4. Routing
A routing protocol provides either instant and/or periodic
notification of the addition and deletion of downstream routers.
HIPNet-based upstream routers are aware of the prefixes that are
provisioned to the downstream routers and on which interface that
prefix route is associated. The downstream routers will refresh
and/or update that initial routing configuration.
A routing protocol simplifies the efforts needed by HIPNet routers
not implementing a routing protocol by eliminating the probing of
routing information with DHCPv6 and perhaps, Neighbor Discovery
[RFC4861] messages of downstream routers.
Additionally, a routing protocol could help support a router with
manual IPv6 prefix configuration. In a HIPNet router configuration,
recursive prefix delegation is assumed to cascade prefix information
to sub-tending downstream routers. However, with a routing protocol,
it could support a directly connected router or line of routers with
manual prefix configuration.
The routing protocol detailed here is assumed to be carrying only
route information and does not consider the presence of any other
configuration data.
Initially, it should also be assumed that the same routing protocol
is used within the home network and there would not be the need for
redistributing between multiple routing protocols.
Additionally, it is assumed that there will be no configuration
information passed along within the routing protocol for the
Provectus phase. That is, the routing protocol will simply be used
to maintain and update routing tables.
Kuarsingh, et al. Expires January 5, 2014 [Page 16]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
Some standard routing protocols to be considered for a Provectus
network (but not limited to) are:
- RIPng [RFC2080]
- OSPFv2 [RFC2328] and/or OSPFv3 [RFC5340] / [RFC5838]
- IS-IS (may also be candidate for phase 4 with multihoming) [ISO-
ISIS]
RIPng
- Distance vector protocol (hop count based)
- UDP protocol, port 521
- Multicast based messaging0
- Authentication done by IPv6 IPSEC layer
Advantages of RIPng
- Simple in design/implementation
- Supported a network topology change immediate route update
Disadvantages of RIPng
- Naturally converges slowly with default 30 second reporting
interval
- Multicast advertisement of complete routing table on every
reporting interval
- Hop Limit max of 15, 16 means infinity and considered
unreachable
- Requires split horizon to report only those routes not sourced
by the destination router.
OSPF
- Link state protocol (route cost based)
- IP based protocol
- Authentication done by IPv6 IPSEC layer
Kuarsingh, et al. Expires January 5, 2014 [Page 17]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
Advantages of OSPF
- Only updates when change in route table occurs - low network
overhead
- Limited only by size of routing table
- Low convergence time
Disadvantages of OSPF
- More complex in design/implementation
- May be difficult to configure
7. Phase 4: Posterus Network
The Posterus phase of home network development looks beyond many of
the current home networking paradigms and allows more dramatic
changes to surface. This phase can be characterized by two general
enhancements over previous phases; IGP enhancements allowing things
like prefix distribution and better multihoming capabilities,
possibly through source address route selection as described in
documents like [draft-troan-homenet-sadr] . The Posterus phase is
the focus of much of the current work of the Homenet working group.
Because the Posterus phase is the furthest into the future, it has
the most potential to change over time. As such, this document
captures current ideas and thinking but should not be seen as
limiting in any way the potential for future progress within home
networks. Additionally, many of the more dramatic changes currently
envisioned for this phase (e.g. IGP prefix distribution) are not
backwards compatible with existing home routers, nor those that are
likely to emerge in the Medius and Provectus phases. This
fundamental principle may restrain the Posterus phase deployments to
those home networks which actively require the added functionality
and efficiency.
7.1. Service Potential
The primary and most obvious service enhancement of the Posterus
phase is the enhancement of multihoming, connecting the home network
to multiple ISPs simultaneously for added bandwidth and/or enhanced
resiliency to WAN connectivity outages. Of course, multihoming isn't
limited only to multiple ISP connections, it could also enable the
connection of multiple discreet home networks thus enabling new
services related to local content sharing and caching. Also, as this
Kuarsingh, et al. Expires January 5, 2014 [Page 18]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
phase leverages routing protocols specifically tailored to home
networking, further service enhancements may be possible. Service
discovery is one area which may benefit from such enhancements if
these routing protocols are extended to share such information.
7.2. Topology
Posterus supports longer term, advanced home network topologies. As
mentioned above, this is primarily focused on enabling multiple ISP
connections, which is illustrated in figure 3, below. Other
topological changes in this phase may include connections to other,
non-ISP networks and other more complex home network topologies.
+-------+-------+ \
| Service | \
| Provider | | Service
| Router | | Provider
+-------+-------+ | network
+------------+ | /
| ISP 2 | | Customer /
+------------+ | Internet connection /
| |
| +------+--------+ \
| | IPv6 | \
| | Customer Edge | \
| | Router | /
| +---+-------+---+ /
| Network A | | Network B | End-User
| -------+----+- --+--+-------------+--- | network(s)
| | | | \
| +-----+----+ +----+-----+ +-----+----+ \
+-----|Secondary | | Host 1| |Internal | /
| CER | | | | Router | /
+-----+----+ +----------+ +----------+ /
Network C | Network D | |
---+-------------+----+- --+--+-------------+--- |
| | | | \
+----+-----+ +-----+----+ +----+-----+ +-----+----+ \
| Host 2| | Host 3 | | Host 4| | Host 5 | /
| | | | | | | | /
+----------+ +-----+----+ +----------+ +----------+ /
Figure 3: Complex Network with Two ISP Connections
Kuarsingh, et al. Expires January 5, 2014 [Page 19]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
7.3. Addressing
Posterus has the potential to see the most dramatic shift in
addressing of all the phases documented here. As described in
[draft-arkko-homenet-prefix-assignment], one of the key enhancements
in this phase may be the distribution of prefix information through
an enhanced IGP. The use of IGP prefix distribution has the distinct
advantage of breaking from the hierarchical prefix distribution
mechanisms introduced in the Medius phase, enabling much more
efficient use of the prefix' available to the home network. This is
a significant advantage in home networks that are allocated a small
prefix, such as a /60. Also, while the "Link ID" concept introduced
in the Medius phase will allow for the use of multiple address
families and multiple distinct prefixes within the home network, the
IGP prefix distribution also promises to further facilitate the use
of prefix' from more than one ISP.
The inherent complication introduced by IGP prefix distribution is
one of backwards compatibility. Home routers in the Elementary,
Medius and Provectus phase, in addition to all current home routers,
use DHCPv6 PD [RFC3633] exclusively for prefix distribution within
the home. A home router designed to use DHCP [RFC3633] will be able
to provide a prefix to a downstream Posterus phase router, but would
be unable to accept a prefix delegated from an upstream Posterus
phase router via an enhanced IGP.
7.4. Routing
Routing in Posterus will likely introduce source address route
selection, currently described in [draft-troan-homenet-sadr] and
[draft-xu-rtgwg-twod-ip-routing]. Source address route selection
uses both the source and destination addresses when determining the
proper routing of packets leaving the home network. This will
greatly enhance the multihoming capabilities of home networks by
ensuring that communications initiated within the home network will
always use the proper upstream ISP, avoiding ingress filtering
present on most residential broadband access networks like [RFC2827].
In addition to enhanced multihoming capabilities, source address
route selection may also be leveraged for access control within home
networks. Since each layer 3 domain within a home network can be
identified by the specific prefix' being used on that segment, source
address based access control provides an effective means of
implementing policy in routing.
Kuarsingh, et al. Expires January 5, 2014 [Page 20]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
8. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Security Considerations
No security considerations noted at this time.
10. Acknowledgements
Special thanks for the following people for their contributions.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.arkko-homenet-prefix-assignment]
Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment
in a Home Network",
draft-arkko-homenet-prefix-assignment-04 (work in
progress), May 2013.
[I-D.baker-homenet-prefix-assignment]
Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small
Networks", draft-baker-homenet-prefix-assignment-01 (work
in progress), March 2012.
[I-D.haddad-homenet-multihomed]
Haddad, W. and D. Saucez, "Multihoming in Homenet",
draft-haddad-homenet-multihomed-01 (work in progress),
March 2013.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"Home Networking Architecture for IPv6",
draft-ietf-homenet-arch-08 (work in progress), May 2013.
Kuarsingh, et al. Expires January 5, 2014 [Page 21]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
[I-D.troan-homenet-sadr]
Troan, O. and L. Colitti, "IPv6 Multihoming with Source
Address Dependent Routing (SADR)",
draft-troan-homenet-sadr-00 (work in progress),
February 2013.
[I-D.xu-rtgwg-twod-ip-routing]
Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP
Routing Architecture", draft-xu-rtgwg-twod-ip-routing-00
(work in progress), March 2012.
[ISO-ISIS]
"ISO/IEC 10589:2002 Intermediate System to Intermediate
System intra-domain routeing information exchange
protocol", 3 2008, <http://www.iso.org/iso/home/store/
catalogue_tc/catalogue_detail.htm?csnumber=30932>.
[PacketCable]
CableLabs, "Packet CableTM 2.0 Architecture Framework
Technical Report", May 2009, <http://www.cablelabs.com/
specifications/PKT-TR-ARCH-FRM-V06-090528.pdf>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Kuarsingh, et al. Expires January 5, 2014 [Page 22]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
Authors' Addresses
Victor Kuarsingh (editor)
Rogers Communications
8200 Dixie Road
Brampton, ON L6T 0C1
Canada
Email: victor@jvknet.com
John Jason Brzozowski
Comcast Cable Communications
1306 Goshen Parkway
Chester, PA 19380
USA
Email: john_brzozowski@cable.comcast.com
Chris Grundemann
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: c.grundemann@cablelabs.com
Kuarsingh, et al. Expires January 5, 2014 [Page 23]
Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013
John McQueen
Broadcom Corporation
16340 West Bernardo Drive
San Diego, CA 92127
USA
Email: jmcqueen@broadcom.com
Kuarsingh, et al. Expires January 5, 2014 [Page 24]
