One document matched: draft-howard-up-pio-00.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="std" docName="draft-howard-up-pio-00" ipr="pre5378Trust200902"
obsoletes="" submissionType="IETF" xml:lang="en">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="UP PIO">The UP PIO Field: Finding Up in an Unmanaged
Network</title>
<author fullname="Lee Howard" initials="L" surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703 345 3513</phone>
<email>lee.howard@twcable.com</email>
</address>
</author>
<date month="November" year="2011" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>UP prefix information</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>It is difficult to find a path through an unmanaged network with
multiple routers. This document describes a new Prefix Information
Option field which can provide information to routers to find a
path.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>This document describes a new Prefix Information Option field to be
used in unmanaged networks (such as home networks) to find a path to a
given prefix. This PIO field is not intended to replace dynamic routing
protocols, and will not find the best path to a given destination,
though it can provide useful information to 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 RFC 2119<xref
target="RFC2119">.</xref>.</t>
</section>
</section>
<section title="Format" toc="default">
<figure>
<artwork> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|U| Rsvd1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Distance | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The use of L and A bits are specified in rfc4861. The use of the R
bit is specified in rfc3775.</t>
<t>This format represents the following changes over those RFCs: <list>
<t>Upstream Prefix (U) 1-bit router address flag. When this UP bit
is set to 1, indicates that the prefix was learned, rather than
configured.</t>
<t>Rsvd1 Reduced from a 5-bit field to a 4-bit field to account for
the addition of the above bit.</t>
<t>Distance An 8-bit metric used to determine distance and prevent
loops.</t>
</list>The UP bit is used to find a path through an unmanaged network.
When a router learns prefix information from a Router Advertisement with
the UP bit sent, the router SHOULD add that prefix to its own RAs. When
sending RAs containing the learned prefix, it MUST increment the
Distance value by one.</t>
<t></t>
</section>
<section title="Use Cases">
<section title="Default Route">
<t>The most common implementation of this field would be the
advertisement of a default route, where Prefix Length = 0 and Prefix =
0. An Internet access provider could use Router Advertisements to
customer gateways with the UP bit set, and a distance of 0, to
indicate the border of the administrative domain and the default
gateway for the customer access router. That customer access router,
having learned the default gateway, SHOULD add the prefix to its
routing table, then SHOULD include this information in its own RAs.
When the router sends RAs including this prefix, it MUST increment the
Distance in those RAs to indicate that it is one hop further than the
origin or the prefix.</t>
</section>
<section title="Walled Garden ">
<t>For a network provider who does not provide a default route, the UP
option can be used to indicate that a prefix is available. For
instance, an operator who only wanted traffic for its hosted services
on 2001:db8::/32, would send an RA for that prefix to the access
gateway, with Distance=0. That gateway SHOULD add the prefix to its
routing table, then SHOULD include the prefix in its own RAs, and MUST
increment the Distance in those RAs to indicate that it is one hop
away from the border.</t>
</section>
<section title="ULA">
<t>Unique Local Addresses may be used for a variety of reasons <xref
target="RFC6204"></xref>. When a router generates a ULA prefix, it
MUST include that prefix in RAs. It SHOULD include the UP option
field, with a Distance = 0. When another router learns that prefix, it
SHOULD add the prefix to its routing table, then SHOULD include the
prefix in its own RAs, and MUST increment the Distance in those RAs to
indicate that it is one hop away from the border.</t>
</section>
<section title="Delegated Prefix">
<t>In home network scenarios, routers are often also DHCPv6 servers.
When a device is a DHCPv6-PD server, and receives a prefix to be used
for host address assignments (regardless of setting of M-bit), if that
device is also the router for that prefix, that router becomes
authoritative for the prefix. "Authoritative for the prefix" is
analogous to the notion of the "delegating router" responding to a
request from the "requesting router" per <xref
target="RFC3633"></xref>. In other words, when a router receives
Prefix Delegation, it SHOULD include that prefix in its RAs, and
SHOULD set the Distance to 0. Note that other values are possible, but
reduce the possible diameter of the network.</t>
<t>Note that in this way, more specific routes may be propagated
through the network via Router Advertisements. The longest match rule
applies, and establishes the route preference. See Examples
section.</t>
</section>
</section>
<section title="Implementation">
<section title="Host Behavior">
<t>Hosts use RAs and the PIO to find their next hop, and for address
autoconfiguration. Nothing in the use of the UP bit changes these
behaviors, though it is possible that hosts will learn multiple
prefixes, and might have multiple paths to the same prefix. It is
expected that these are harmless. Details of path selection are left
to implementers.</t>
<t>A host MAY use the Distance metric to select a better bath for a
prefix. A host might learn multiple prefixes from which SLAAC may be
used. This is not a new function introduced with the UP bit, and host
behavior is expected to be unchanged.</t>
</section>
<section title="Tie Breaking">
<t>When a router learns the same prefix from two other routers, and
both RAs have the same Distance, a tie-breaker mechanism is required.
The tie-breaker could be arbitrary, such as the time the RA was
received, or it could be based on (e.g.) the Preferred Lifetime value,
the layer 2 link type, or other suitable informationr. Implementers
MUST have a tie-breaker rule or rules to resolve all ties.</t>
</section>
<section title="Multiple Paths">
<t>A router receiving multiple RAs for the same prefix may choose to
discard the path not chosen, or may add the route to its routing table
with a higher Administrative Distance.</t>
</section>
<section title="Route Withdrawal">
<t>As with other RAs, when an RA is received from a router with no
information for a prefix, even if that router had previously provided
prefix information, the receiver SHOULD remove references to that
prefix from its routing table. Similarly, if no RAs are received from
a router, the prefix SHOULD be removed. Further, it SHOULD send RAs
without that prefix.</t>
<t>When the Valid Lifetime has passed, the route MUST be removed. When
the Preferred Lifetime has passed, the route MAY be lowered in
preference.</t>
</section>
</section>
<section anchor="Examples" title="Examples">
<t>Consider the example in Figure 1, in which a network has two upstream
ISPs, ISP A and ISP B. A different router connects to each ISP. Routers
A and B connect to their respective upstream ISPs, and a Router C and
Router D connect to the same link. Routers C and D share another link,
causing a potential loop situation. A Host #1 connects to the shared
link between Routers A, B, C, and D. A Host #2 connects to the shared
link between Routers C and D.</t>
<figure title="Multi-homed Topology">
<artwork> +----+-----+ +-----+----+ \
| ISP A | | ISP B | \
| | | | | Service
+----+-----+ +-----+----+ | Provider
| | | Network
| | /
| | /
+----+-----+ +-----+----+ \
| Router A | | Router B | \
| | | | |
+----+-----+ +-----+----+ |
| | | Home
| | | Network
----+---------------------+--------------------+--- |
| | | |
+----+-----+ +----+-----+ +-----+----+ |
|IPv6 Host | | Router C | | Router D | |
| #1 | | |---+----| | /
+----------+ +----------+ | +----------+ /
|
|
+-----+----+
| IPv6 Host|
| #2 |
+-----+----+
</artwork>
</figure>
<t>Suppose ISP A and ISP B both provide a default route via Router
Advertisements. Further suppose that ISP A delegates (via DHCPv6) the
prefix 2001:db8:000a::/48, and ISP B delegates the prefix
2001:db8:0000:00b0::/56.</t>
<t>Router A sends 0::/0 with UP bit and Distance=1, and sends
2001:db8:a::/48 with UP bit and Distance=0.<list>
<t>Router B receives the RA. It prefers the default route from ISP
B, because its Distance=0. It learns prefix 2001:db8:a::/48 and adds
it to its routing table.</t>
<t>Router C and Router D receive the RA. They each install the
default route and the /48 prefix in their routing tables.</t>
<t>Host #1 might configure an address from the prefix via DHCP or
SLAAC.</t>
</list></t>
<t>Router B sends 0::/0 with UP bit and Distance=1, and sends
2001:db8:0:b0::/56 with UP bit and Distance=0.<list>
<t>Router A receives the RA. It prefers the default route from ISP
A, because its Distance=0. It learns prefix 2001:db8:b0::/56 and
adds it to its routing table.</t>
<t>Router C and Router D receive the RA. They compare the default
route to the existing default route. Each applies its tie-breaking
rule, and installs the winning route. Suppose they have different
methods, and Router C uses the default to Router A, and Router D
uses the default to Router B. They each add the /56 prefix to their
routing tables.</t>
<t>Host #1 might configure an additional address from the prefix via
DHCP or SLAAC. Whether it does is beyond the scope of this
document.</t>
</list></t>
<t>Router C sends 0::/0 with UP bit and Distance=2, and sends
2001:db8:a::/48 with UP bit and Distance=2, and sends 2001:db8:0:b0::/56
with UP bit and Distance=2.<list>
<t>Routers A and B receive the RAs, but ignore the duplicate
prefixes within them because they already have those prefixes with a
shorter Distance.</t>
<t>Router D receives the RA for 0::/0, but already has a route with
a lower Distance. Router D receives the RA for 2001:db8:a::/48, but
already has a route with a lower Distance (from Router A, where
Distance=0). Router D receives the RA for 2001:db8:0:b::/56, but
already has a route with a lower Distance (from Router B, where
Distance=0).</t>
</list></t>
<t>Router C then receives delegated prefix 2001:db8:a:c::/64. Host #2
gets an address for this prefix, either via SLAAC or DHCP. Router C
sends RAs for 2001:db8:a:c::/64 with UP bit and Distance=0. The host
also receives RAs for the /64 prefix.<list>
<t>Router D receives the RA for 2001:db8:a:c::/64. It is a longer
(more specific prefix) than its previous 2001:db8:a::/48 route, so
it adds the more specific to its routing table.</t>
<t>Routers A and B receive the RA for 2001:db8:a:c::/64. It is a
longer (more specific prefix) than their previous 2001:db8:a::/48
route, so they add the more specific to its routing table. They will
update their own RAs, but Routers C and D already have routes with
lower Distance.</t>
<t>If Router A or Router B sends the more-specific prefix to the
ISP, the ISP MAY choose to add the route or ignore it if a route
preferred by policy exists (for the delegated prefix).</t>
</list></t>
</section>
<section title="Evaluation">
<t>Here follows an evaluation of whether this solution meets all of the
Homenet routing requirements.<list>
<t>Can Host #1 reach Host #2? Yes, via a path through either
router.</t>
<t>Is the network border clear? Yes, as Distance=0 for the shortest
prefix.</t>
<t>Can it handle a router being added? Yes, the new router will
learn prefixes via RAs quickly.</t>
<t>Can it handle a router being moved? Yes, with some delay in
relearning the routes. If Host #2 were a Router E, and it was moved
to the shared ABCD link without the router or interface going down
long enough for RAs to be missed, it might propagate RAs learned
from Routers C and D. It would have a higher Distance for the
shorter prefixes (the /0, /48, /56), so neighboring routers would
ignore its RAs. If it were two layers deeper in the network, such
that it had a Distance=2 for a more-specific, which was better than
the Distance previously seen by Routers A and B, neighbors would
prefer its RAs. However, it would stop sending those RAs once it
stopped receiving them. The router would continue sending RAs for
its delegated prefix for as long as it had that prefix; this problem
is related to addressing, not routing.</t>
<t>Can it handle a router being removed? Yes. Some routers may
install multiple routes; as soon as they miss seeing an RA for a
prefix, they will have a back route. Other routers may have to wait
until they see a new RA before having a backup path to the
prefix.</t>
<t>Will it work in a no-configuration environment? Yes.</t>
<t>Can it support multiple upstream networks? Yes. It does not solve
address configuration or source selection issues, but those are not
routing problems per se.</t>
<t>Does it work if prefix delegation is not hierarchical? Yes. Each
prefix has its own Prefix Information Option, each with its own
Distance.</t>
<t>Can another path be found in case of failure? Yes, within a
couple of RA intervals.</t>
<t>Does it prevent loops? Yes.</t>
<t>Does it allow for stable prefixes through reboots? Yes, though
paths will have to be rediscovered, through the period configured
for Router Advertisement transmissions.</t>
<t>Is it lightweight/cheap? Yes. A simple addition to the PIO, which
already exists. Some additional routing decision-tree logic is
required for comparing best paths, tie-breaking among equal paths,
etc.</t>
<t>Can it handle multiple-dwelling units, or other potentially dense
networks? Each upstream router will increment Distance, so each
router should choose the shortest upstream path. However, a host
with no router could end up choosing a neighbor's router instead of
their ISP. The solution is no chattier than existing RAs.</t>
<t>Can it stand up to wireless networks, and networks with wired and
wireless segments? Yes, with consideration for multiple-dwelling
units.</t>
<t>Can it stand up to unintentional connections of networks? Yes.
Although the Distance would seem to limit the diameter of the
network to 255 segments, when each router is given a subnet prefix,
it resets the Distance to 0 for its prefix. Thus, the Diameter is a
wide as prefix topology allows.</t>
</list></t>
</section>
<section title="Additional Work Required">
<t>This option essentially overloads the PIO to be a lightweight
distance-vector routing protocol of sorts. As such, it needs to avoid
the problems of distance-vector protocols, such as the count-to-infinity
problem. Several possibilities exist to mitigate this problem:<list>
<t>Use a smaller possible infinity (i.e., change the Distance field
to be a 4-bit field)</t>
<t>Shorten the RA transmission intervals</t>
<t>Split horizon (do not advertise a prefix out the interface it was
learned) with poison reverse (when a neighbor is lost, send an RA
with Distance=255) could be used</t>
</list></t>
</section>
<section title="Alternatives">
<t anchor="foo">An extension of rfc4191, Default Router Preferences and
More-Specific Routes, with its definition of a Route Information Option,
might be a closer approximation to the distance-vector protocol
described here.</t>
<t>A link-state protocol would solve standard problems with
distance-vector protocols. However, most link-state protocols are much
heavier implementations.</t>
</section>
<section title="Security Considerations">
<t>By using unsecured Router Advertisements, attacks that compromise RAs
would have an extended effect. Use of SeND should mitigate these
attacks.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations or implications that arise from this
document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author fullname="S. Bradner"></author>
<date />
</front>
</reference>
<reference anchor="RFC3775">
<front>
<title>Mobility Support in IPv6</title>
<author fullname="D. Johnson"></author>
<author></author>
<author fullname="J. Arkko"></author>
<date />
</front>
</reference>
<reference anchor="RFC2461">
<front>
<title>Neighbor Discovery for IP Version 6 (IPv6)</title>
<author fullname="T. Narten"></author>
<author fullname="E. Nordmark"></author>
<author fullname="E. Nordmark"></author>
<author></author>
<date />
</front>
</reference>
<reference anchor="RFC4861">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author fullname="T. Narten"></author>
<author fullname="E. Nordmark"></author>
<author fullname="W. Simpson"></author>
<author fullname="H. Soliman"></author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3633">
<front>
<title>IPv6 Prefix Options for Dynamic Host Configuration Protocol
(DHCP) version 6</title>
<author fullname="O. Troan">
<organization></organization>
</author>
<author fullname="R. Droms"></author>
<date />
</front>
</reference>
<reference anchor="RFC6204">
<front>
<title>Basic Requirements for IPv6 Customer Edge Routers</title>
<author fullname="H. Singh">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="W. Beebee">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="C. Donley">
<organization>CableLabs</organization>
</author>
<author fullname="B. Stark">
<organization>AT&T</organization>
</author>
<author fullname="O. Troan" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:19 |