One document matched: draft-winters-homenet-sper-interaction-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="2"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-winters-homenet-sper-interaction-01" ipr="trust200902">
<front>
<title abbrev="SPER">Service Provider Edge Router Interaction</title>
<author fullname="Timothy Winters" initials="T" surname="Winters" role="editor">
<organization>UNH-IOL</organization>
<address>
<postal>
<street></street>
<city>Durham</city>
<region>NH</region>
<!-- <code/> -->
<!-- <country/> -->
</postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>twinters@iol.unh.edu</email>
<!-- <uri/> -->
</address>
</author>
<date year="2014" />
<area>Internet</area>
<workgroup>Homenet</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>
This document describes the interaction between a Service Provider Gateway fixed at the home edge,
and the Home Networking interior routers. It assesses the interactions between existing routers
implementing <xref target='RFC7084'></xref> and the Home Networking routers. The document will also define the interactions
between other Service Provider Edge Router (eg. HIPnet) and Home Networking router.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document defines the interactions between the future Homenet network and 7084 Routers and
Service Provider Edge Routers (SPER). In the future the SPER will be full Homenet routers but
there will be a period of transition.
This document specifies how currently deployed SPER will interact with Homenet architecture
<xref target="I-D.ietf-homenet-arch"></xref>. The goal of this document is to make recommendations
on issues uncovered to make the devices work with the future Homenet. These recommendations may
result in requirements for the Homenet routers.
</t>
<section title="Requirements Language">
<t>
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
<xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="Terminology">
<t> For purposes of this report the Design Team adopts the following terminology.
<list style="symbols">
<t> Border: a point, typically resident on a router, between two
networks. A basic example is between the main internal homenet and a guest
network. This also defines point(s) at which filtering and
forwarding policies for different types of traffic may be
applied. For the purpose of this document we use the
Default Border Definition
<xref target='I-D.kline-homenet-default-perimeter'></xref>
to describe how the Border is discovered.</t>
<t> SPER: Service Provider Edge Router: A border router intended for home or
small-office use that forwards packet explicitly addressed as defined
<xref target='I-D.grundemann-homenet-hipnet'></xref> or <xref target='BBF.TR124'></xref> connecting the homenet
to a service provider network.</t>
<t> Homenet: Home network consisting of routers interacting with each other
using a dynamic routing protocol for prefix allocation
and reachability. Examples include Prefix Assignment
<xref target='I-D.arkko-homenet-prefix-assignment'></xref>
and OSPFv3 Auto-Configuration <xref target='I-D.ietf-ospf-ospfv3-autoconfig'></xref></t>
<t> Homenet Naming and Service Discovery: The Homenet supports the
ability for users and devices to be able to discover devices and services available
in the Homenet. Currently the mechanism is undefined but methods such as DNSSD
<xref target='RFC6763'></xref>, <xref target='SSDP'></xref>, Hybrid model using
<xref target='I-D.cheshire-dnssd-hybrid'></xref> or DNS-Based Service Discovery
using OSPFv3 <xref target='I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf'></xref>
could be used to solve this issue.</t>
<t> Internet Service Provider (ISP): 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. </t>
<t> 7084: A router intended for home or small-office use that forwards packet explicitly
addressed to itself as defined in <xref target='RFC7084'></xref></t>
</list>
</t>
</section>
<section title="Border Discovery">
<t> According to <xref target='I-D.kline-homenet-default-perimeter'></xref> there are 3 types
of product interfaces: external, internal, and mixed. Border Discovery is the process of
discovering the interface types. Below we describe the the 3 choices.
</t>
<section title="All Ports Discovery">
<t>Border Discovery must be performed on all interfaces. Legacy Routers that don't support
Homenet will not participate in Border Discovery and are considered to be external to the
Homenet Border.</t>
</section>
<section title="WAN Port defined As External">
<t>WAN ports are permanently defined as external requiring no discovery. LAN ports perform Border
Discovery. This requires that the user connect the WAN interface to the ISP or SPER defining
the boundary. All other ports are in border discovery mode. The advantage of this approach
is that it allows the Homenet to have multiple egress ports.
</t>
</section>
</section>
<section title="Home Networking Scenarios">
<section title="7084 to Homenet">
<figure>
<artwork>
+-----------+
| Service |
| Provider |
| Router |
+-----+-----+
|
|
| Customer
| Internet Connection
|
+-----v-----+
| 7084 |
| Router |
| |
+-----+-----+
|
+----+-+-------+
| |
| |
+---+----+ +-----+------+
| IPv6 | | Homenet |
| Host | | Router |
| | | |
+--------+ +------------+
</artwork>
</figure>
<section title="Addressing">
<t>
A 7084 Router acquires addresses to provision the LAN through DHCP Prefix Delegation
<xref target='RFC3633'></xref>. A 7084 Router will assign a separate /64 from the set of
delegated prefix(es) for each LAN interfaces. The Router can assign addresses to the LAN hosts using either
SLAAC or DHCP. There is no requirement for redistributing any unused prefix(es) that
were delegated to the 7084 Router. Support of IA_PD on the LAN interface is not required for a 7084 Router.
If a 7084 Router does not support IA_PD on the LAN interface
the Homenet will not receive a prefix allocation, and therefore will not have global
addressing for the entire Homenet.
</t>
</section>
<section title="Routing">
<t>
A 7084 Router learns default routes through Router Advertisements on the
WAN interface. Routes are installed when a prefix is assigned to a LAN
interface. All other Home Routing information requires user configuration.
<vspace blankLines='1'/>
A 7084 Router will NOT forward packets from an unrecognized source
address. Any IPv6 packets routed from the Homenet would receive an
ICMPv6 Destination Unreachable message. This restricts the Homenet
to internal communications only.
Packets with unrecognized destination addresses in the Homenet MAY pass thru a 7084 Router if configured.
This configuration might be done thru the mechanism such a IA_PD or direct configuration.
</t>
</section>
<section title="Border">
<t>A 7084 Router does not have a method for participating in Homenet border
discovery. A 7084 Router and any hosts connected to the Router are considered to be
as External to the Homenet. A Homenet Router is recommended to support a configuration
method that will allow the
border to include the 7084 Router as Internal to the Homenet.
</t>
</section>
<section title="Service Discovery into the Homenet">
<t> For service discovery to works routers need to forward multicast traffic
appropriately enabling server discovery across the home network.
A 7084 Router does not have any requirements for
supporting multicast forwarding. Based on this knowledge it is unlikely that
Service Discovery between the 7084 and Homemnet will work.</t>
</section>
</section>
<section title="Homenet to 7084 ">
<figure>
<artwork>
+-----------+
| Service |
| Provider |
| Router |
+-----+-----+
|
|
| Customer
| Internet Connection
|
+-----v-----+
| Homenet |
| Router |
| |
+-----+-----+
|
+----+-+-------+
| |
| |
+---+----+ +-----+------+
| IPv6 | | 7084 |
| Host | | Router |
| | | |
+--------+ +------------+
</artwork>
</figure>
<section title="Addressing">
<t> A 7084 Router needs to receive an IA_PD to allow devices on
LAN interfaces to be addressed. For addressing to work properly the
Homenet must provide IA_PDs when requested.</t>
</section>
<section title="Routing">
<t> When a Homenet Router is assigned an IA_PD it MUST install
routes for the prefixes into the Homenet Routing infrastructure.
This will allow packets to be routed from the Homenet to the
7084 Router. A 7084 Router only needs a Router
Advertisement with a valid Router Lifetime to route into the Homenet.</t>
</section>
<section title="Border">
<t> A Homenet Router with the firewall on might not allow valid
traffic from devices connected to the 7084 Router. When a
Homenet Router is assigned an IA_PD there needs to be a secure way
for the Homenet Border to allow IPv6 traffic to flow from the
7084 router into the Homenet or Internet.
</t>
</section>
<section title="Service Discovery into the Homenet">
<t> For service discovery to work routers need to forward multicast traffic
appropriately enabling server discovery across the home network.
A 7084 Router does not have any requirements for
supporting multicast forwarding. Based on this knowledge it is unlikely that
Service Discovery between the 7084 and Homemnet will work.</t>
</section>
</section>
<section title="Service Provider Edge Router (SPER) to Homenet">
<figure>
<artwork>
+-----------+
| Service |
| Provider |
| Router |
+-----+-----+
|
|
| Customer
| Internet Connection
|
+-----+-----+
| SPER |
| |
| |
+-----+-----+
|
+----+-+-------+
| |
| |
+---+----+ +-----+------+
| IPv6 | | Homenet |
| Host | | |
| | | |
+--------+ +------------+
</artwork>
</figure>
<section title="Addressing">
<t> SPERs use DHCPv6 prefix sub-delegation to build the network
<xref target="I-D.grundemann-homenet-hipnet"></xref>. If the prefix is larger then a single
/64 prefix the SPER will subdivide the IPv6 prefix received via DHCPv6
<xref target="RFC3315"></xref>. Using Recursive Prefix Delegation allows the Homenet to
receive prefixes that can be used to address the network.
</t>
</section>
<section title="Routing">
<t>Leveraging the recursive prefix delegation method described above, a SPER installs a
route to the WAN interface of the router which delegated the prefixes. With this routing
information the SPER is able to properly route packets to and from the Homenet.
</t>
</section>
<section title="Border">
<t>A SPER implements a stateful <xref target='RFC6092'></xref> firewall which may be have it enabled.
This stateful firewall will allow homenet traffic to leave the network. It is limited to only
returning traffic originated from the Homenet. No connections can be originated from outside of the Homenet.
<vspace blankLines='1'/>
A Homenet Router with the firewall on might not allow valid traffic from devices connected to the HIPnet SPER.
A Homenet Router will be able to detect a SPER based on a CER_ID, <xref target='I-D.donley-dhc-cer-id-option'></xref>,
SPER MUST include an CER_ID option with an address that is not the unspecified address (::). This allows for the
Homenet Router to detect a SPER allowing native IPv6 traffic through the firewall so that traffic can flow
between the SPER and Homenet.
</t>
</section>
<section title="Service Discovery">
<t>
Both the Homenet and SPER have several common protocols that can be used for
service discovery such as <xref target='RFC6762'>mDNS</xref>,
<xref target='RFC6763'>DNS-SD</xref>, and <xref target='SSDP'></xref>. Both the SPER and Homenet Routers
may have host directly connected that are using them as DNS servers.
If the SPER advertises itself as the DNS-SD server for connected host, the host could
query the SPER. The issue that arises with this
configuration is the HIPnet Router currently has no method for finding the Homenet
router to query when trying to resolve DNS.
</t>
</section>
</section>
<section title = "Homenet to SPER">
<figure>
<artwork>
+-----------+
| Service |
| Provider |
| Router |
+-----+-----+
|
|
| Customer
| Internet Connection
|
+-----+-----+
| Homenet |
| |
| |
+-----+-----+
|
+------+-------+
| |
| |
+---+----+ +-----+------+
| IPv6 | | SPER |
| Host | | |
| | | |
+--------+ +------------+
</artwork>
</figure>
<section title="Addressing">
<t> A SPER needs to receive an IA_PD to address IPv6 host and routers behind it.
If a large enough prefix is assigned, /56 for example, the SPER will attempt
further sub-delegation. This will not be optimized for the network but will still function properly.
For addressing between the SPER and Homenet to work properly the Homenet
must provide IA_PDs when requested.</t>
</section>
<section title="Routing">
<t> When a Homenet Router assigns an IA_PD to the SPER it MUST install
routes for the prefixes into the Homenet Routing infrastructure.
This will allow packets to be routed from the Homenet to the
SPER. If there are two ingress paths to the SPER, the sub-optimal path will be choosen
based on the interface that assigned the IA_PD.
</t>
</section>
<section title="Border">
<t> A Homenet Router with the firewall enabled might not allow valid
traffic from devices connected to the SPER or addressed by the SPER to enter the Homenet.
When a Homenet Router assigns an IA_PD there needs to be a secure way
for the Homenet Border to allow IPv6 traffic to flow from the
SPER into the Homenet or Internet.
</t>
</section>
<section title="Service Discovery into the Homenet">
<t> For service discovery to work routers need to forward multicast traffic
appropriately enabling server discovery across the home network.
</t>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
</section>
<section anchor="IANA" title="IANA Considerations">
<t> This document makes no request of IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The Homenet Design Team: Mikael Abrahamsson, Ray Bellis, John Brzozowski, Lorenzo Colitti,
Tim Chown, Chris Donley, Markus Stenberg, Andrew Yourtchecko, Erik Kline</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.RFC.3315.xml"?>
<?rfc include="reference.RFC.3633.xml"?>
<?rfc include="reference.RFC.6092.xml"?>
<?rfc include="reference.RFC.6204.xml"?>
<?rfc include="reference.RFC.6763.xml"?>
<?rfc include="reference.RFC.7084.xml"?>
<?rfc include="reference.I-D.draft-ietf-homenet-arch-11.xml"?>
<?rfc include="reference.I-D.draft-grundemann-homenet-hipnet-01.xml"?>
<?rfc include="reference.I-D.draft-arkko-homenet-prefix-assignment-04.xml"?>
<?rfc include="reference.I-D.draft-ietf-ospf-ospfv3-autoconfig-05"?>
<?rfc include="reference.I-D.draft-cheshire-dnssd-hybrid-01"?>
<?rfc include="reference.I-D.draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00"?>
<?rfc include="reference.I-D.draft-kline-homenet-default-perimeter-00.xml"?>
<?rfc include="reference.I-D.draft-donley-dhc-cer-id-option-02"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6762.xml"?>
<reference anchor="SSDP" target="">
<front>
<title>Univeral Plug and Play (UPnP) Device Architecture 1.1</title>
<author>
<organization>UPnP Forum</organization>
</author>
<date month="November" year="2008" />
</front>
</reference>
<reference anchor="BBF.TR124" target="">
<front>
<title>TR-124: Functional Requirements for Broadband Residental Gateways
Devices</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="August" year="2012" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:47:28 |