One document matched: draft-pfister-moving-net-autoconf-00.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<!DOCTYPE rfc SYSTEM "rfcXXXX.dtd">
<rfc category="exp" ipr="trust200902" docName="draft-pfister-moving-net-autoconf-00">
<front>
<title abbrev="Moving networks prefix exchange">Routers auto-configuration using Route Information Option from ICMPv6 Router Advertisements</title>
<author initials="P.P." surname="Pfister" fullname="Pierre Pfister" >
<organization abbrev="CEA">Commissariat à l'Énergie Atomique</organization>
<address>
<postal>
<street>8 Avenue de la Vauve</street>
<city>Palaiseau</city>
<region>Ile-de-France</region>
<code>91120</code>
<country>FR</country>
</postal>
<email>pierre.pfister@polytechnique.org</email>
</address>
</author>
<author initials="A.P." surname="Petrescu" fullname="Alexandru Petrescu">
<organization abbrev="CEA">Commissariat à l'Énergie Atomique</organization>
<address>
<postal>
<street>8 Avenue de la Vauve</street>
<city>Palaiseau</city>
<region>Ile-de-France</region>
<code>91120</code>
<country>FR</country>
</postal>
<email>alexandru.petrescu@cea.fr</email>
</address>
</author>
<date day="29" month="July" year="2013" />
<keyword>IPv6</keyword>
<keyword>Mobile Network</keyword>
<keyword>Router</keyword>
<keyword>Neighbor Discovery</keyword>
<abstract>
<t>This draft defines a way for multiple routers that are communicating on a single link to exchange routing information using Router Advertisements. This allows moving networks to communicate with each other through auto-configured routers. This document specifies a new flag for the Router Information option from ICMPv6 Router Advertisement messages and specifies how routers must process such options.</t>
</abstract>
</front>
<middle>
<section title="Introduction and motivations">
<t>The Neighbor Discovery protocol <xref target="NEIGHDISC"/> enables auto-configuration for hosts based on information provided by routers (in Router Advertisements). It assumes routers to be access routers, advertising different on-link prefixes and providing access to the whole network, and thus mainly focuses on the last hop of networks.</t>
<t>More specific options also exist in order to provide complementary informations for more complex and dynamic networks. For example, ICMPv6 Router Advertisements can carry DNS configuration information <xref target="RADNS"/> or more specific route information <xref target="RIO"/>.</t>
<t>The Neighbor Discovery protocol well succeeds in configuring mobile hosts when visiting fixed networks served by fixed routers, but doesn't allow moving networks, served by an attached moving router, to interact with fixed or moving networks.</t>
<t>This draft extends the Neighbor Discovery protocol. It defines a new flag for the Route Information Option from <xref target="RIO"/> and specifies routers processing of such options when the flag is set. Thus allowing moving networks to dynamically use routing information in a simpler and more dynamic way than existing routing protocols. Finally, we discuss the different possibilities of securing such process.</t>
</section>
<section title="Terminology">
<t>This document uses the terminology defined in <xref target="NEIGHDISC"/>, and <xref target="RIO"/>.</t>
</section>
<section title="Requirements">
<t>The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, CAN, when they appear in this document, are to be interpreted as described in <xref target="KEYWORDS"/>.</t>
</section>
<section title="Use case example">
<t>In most cases, only hosts are considered to be mobile, but with the increase in the number of IP devices, we can expect the number of moving networks to highly increase in the next few years. For example, cars will contain a lot of different devices, from pressure captors to infotainment terminals, all gathered in possibly complex networks. The neighbor discovery protocol allows such devices to dynamically obtain their needed networking information, but routers that serves such networks cannot use this protocol to establish connexions with the infrastructure or other cars.</t>
<t>This draft proposes to extend the Route Information option (RIO) use-case by allowing moving networks, that share a common link, to exchange routing information, and thus form multiple hops networks.</t>
<t>The simplest example of such a situation happens when two routers, configured as default gateways for fixed networks, connect to the same link. This draft allows them to advertise their respective prefixes on the visited link.</t>
<figure anchor="V2V" title="Two moving networks auto-configuration">
<artwork>
Visited link
-------------------------------------------
fe80::1 | | fe80::2
----- -----
| R1 | | R2 |
----- -----
| fd00:1::/64 | fd00:2::/64
--------- ---------
| | | |
--- --- --- ---
|H11| |H12| |H21| |H22|
--- --- --- ---
</artwork>
</figure>
<t>In this figure, two 1-hop networks, served by their respective default routers, come in communication range on a visited link. This draft proposes a simplified procedure for those routers to exchange their internal prefixes (fd00:1::/64 and fd00:2::/64), thus allowing leaf nodes from one network (H11 and H12) to communicate with the nodes in the other network (H21 and H22).</t>
</section>
<section title="Message Format">
<t>The RIO is defined in <xref target="RIO"/> as a Router Advertisement option. It is used by routers to send preference information about specific routes that hosts can take into account in their route selection process. This document proposes to reserve the bit 24 for Mobile Network Prefix flag.</t>
<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 |M| R |Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging" hangIndent="17">
<t hangText="'M':">Mobile Network Prefix flag. It MUST be set to 1 if this Route Information option can be used by a router and set to 0 otherwise.</t>
<t hangText="'R':">Two reserved bits. They MUST be initialized to zero by the sender and ignored by the receiver.</t>
</list></t>
<t>A router sets the 'M' flag when it wants receiving routers to modify their routing table in order to use itself as next hop for the specified prefix, with the specified preference. If the flag is set, a router MAY use this information in order to modify its routing table. If not, it SHOULD ignore the option. In both cases, a host MUST behave as specified in <xref target="RIO"/>.</t>
</section>
<section title="Host Specifications">
<t><xref target="RIO"/> defines three different kind of valid behaviors for hosts. This document doesn't propose any modification for hosts. Therefore, a host MUST ignore the Mobile Network Prefix flag.</t>
</section>
<section title="Router Specifications">
<section title="Router configuration">
<t>Routers SHOULD NOT set the Mobile Network Prefix flag by default in the Route Information options they send but they SHOULD be configureable.</t>
<t>The default behavior of router MUST be to ignore all received Route Information options. But a router SHOULD be configurable in order to specify other behaviors.</t>
</section>
<section title="Accepting a Route Information option">
<t>Routers SHOULD ignore all Route Information option which Mobile Network Prefix flag is not set. When the flag is set, a router submits the option to its acceptation algorithm in order to decide whether to accept the RIO or not.</t>
<t>Routers MAY accept all, none, or some of the RIOs which 'M' flag is set. Such selection CAN be based on any kind of policy (source address, authentication, etc…). </t>
</section>
<section title="Using a Route Information option">
<t>When accepted, a RIO is used as defined in <xref target="RIO"/> for type C hosts. The receiving router is free to give any metric to the newly introduced route.</t>
<t>When routing a packet, longest prefix match is first used. When different next-hops addresses exist for the same packet, with the same metric, routes that are obtained through Route Information options have the lowest priority. The preference field is used in order to break ties between routes that were obtained with RIOs.</t>
<t>Routing entries that are obtained with RIOs MUST be removed after at most 'Route lifetime' seconds unless its lifetime is extended by a newly received RIO from the same neighbor. If so, the new preference value and timeout date override previously received values.</t>
</section>
</section>
<section title="Security Considerations">
<t>The Neighbor Discovery protocol have some known security weaknesses. This draft doesn't intend to solve them. Nevertheless, route auto-configuration for routers extends the scope of possible threats from a single node to a complete network. Special care should therefore be taken when deciding whether to accept or reject a Route Information option.</t>
<section title="Using IPSec">
<t>IPSec <xref target="IPSEC"/> can be used, in some cases, to secure the Neighbor Discovery messages. But, as it only supports security associations between pairs of nodes, it requires unicast communications. Care should therefore be taken when considering this solution in order to avoid congestion.</t>
</section>
<section title="Using SeND">
<t>SeND <xref target="SEND"/> uses public-key cryptography in order to broadcast signed Router Advertisements. X.509 certificates are used in order to certify the right of routers to advertise a set of prefixes. This document proposes to extends the right of advertising a prefix (in Prefix Information options) to the right of advertising the same prefixes in RIOs.</t>
<t>In other words, when SeND is enabled, a router MUST NOT send RIOs containing prefixes it hasn't the right to send in Prefix Information options.</t>
<t>The use of this protocol would not prevent a malicious node, present on the shared link, to spoof IPs from both networks, to eaves-drop, or potentially to perform man-in-the-middle attacks, depending on the shared link security. Connected networks should therefore use higher layers security in order to establish point-to-point secured connexions.</t>
</section>
</section>
<section title="IANA Considerations">
<t>IANA is kindly requested by the authors to allocate the following value:
<list style="symbols">
<t>Space allocation for the Mobile Network Prefix flag in the Route Information option.</t>
</list>
</t>
</section>
<section title="Acknowledgements">
</section>
</middle>
<back>
<references>
<reference anchor="KEYWORDS">
<front>
<title>Key words for use in RFCs to indicate Requirement Levels</title>
<author initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="NEIGHDISC">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author initials="T." surname="Narten"/>
<author initials="E." surname="Nordmark"/>
<author initials="W." surname="Simpson"/>
<author initials="H." surname="Soliman"/>
<date month="September" year="2007"/>
</front>
<seriesInfo name="RFC" value="4861"/>
</reference>
<reference anchor="RIO">
<front>
<title>Default Router Preferences and More-Specific Routes</title>
<author initials="R." surname="Draves"/>
<author initials="D." surname="Thaler"/>
<date month="November" year="2005"/>
</front>
<seriesInfo name="RFC" value="4191"/>
</reference>
<reference anchor="RADNS">
<front>
<title>IPv6 Router Advertisement Options for DNS Configuration</title>
<author initials="J." surname="Jeong"/>
<author initials="S." surname="Park"/>
<author initials="L." surname="Beloeil"/>
<author initials="S." surname="Madanapalli"/>
<date month="November" year="2010"/>
</front>
<seriesInfo name="RFC" value="6106"/>
</reference>
<reference anchor="IPSEC">
<front>
<title>IPv6 Node Requirements</title>
<author initials="J." surname="Loughney"/>
<date month="April" year="2006"/>
</front>
<seriesInfo name="RFC" value="4294"/>
</reference>
<reference anchor="SEND">
<front>
<title>SEcure Neighbor Discovery (SEND)</title>
<author initials="J." surname="Arkko"/>
<author initials="J." surname="Kempf"/>
<author initials="B." surname="Zill"/>
<author initials="P." surname="Nikander"/>
<date month="March" year="2005"/>
</front>
<seriesInfo name="RFC" value="3971"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:34:03 |