Internet DRAFT - draft-pfister-moving-net-autoconf
draft-pfister-moving-net-autoconf
Network Working Group P. Pfister
Internet-Draft A. Petrescu
Intended status: Experimental CEA
Expires: November 23, 2013 July 29, 2013
Routers auto-configuration using Route Information Option from ICMPv6
Router Advertisements
draft-pfister-moving-net-autoconf-00
Abstract
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.
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."
This Internet-Draft will expire on November 23, 2013.
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
Pfister & Petrescu Expires November 23, 2013 [Page 1]
Internet-Draft Moving networks prefix exchange May 2013
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.
Table of Contents
1. Introduction and motivations . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use case example . . . . . . . . . . . . . . . . . . . . . . . 6
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Host Specifications . . . . . . . . . . . . . . . . . . . . . 8
7. Router Specifications . . . . . . . . . . . . . . . . . . . . 9
7.1. Router configuration . . . . . . . . . . . . . . . . . . . 9
7.2. Accepting a Route Information option . . . . . . . . . . . 9
7.3. Using a Route Information option . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Using IPSec . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Using SeND . . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Pfister & Petrescu Expires November 23, 2013 [Page 2]
Internet-Draft Moving networks prefix exchange May 2013
1. Introduction and motivations
The Neighbor Discovery protocol [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.
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
[RADNS] or more specific route information [RIO].
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.
This draft extends the Neighbor Discovery protocol. It defines a new
flag for the Route Information Option from [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.
Pfister & Petrescu Expires November 23, 2013 [Page 3]
Internet-Draft Moving networks prefix exchange May 2013
2. Terminology
This document uses the terminology defined in [NEIGHDISC], and [RIO].
Pfister & Petrescu Expires November 23, 2013 [Page 4]
Internet-Draft Moving networks prefix exchange May 2013
3. Requirements
The keywords MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, CAN, when they
appear in this document, are to be interpreted as described in
[KEYWORDS].
Pfister & Petrescu Expires November 23, 2013 [Page 5]
Internet-Draft Moving networks prefix exchange May 2013
4. Use case example
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.
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.
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.
Visited link
-------------------------------------------
fe80::1 | | fe80::2
----- -----
| R1 | | R2 |
----- -----
| fd00:1::/64 | fd00:2::/64
--------- ---------
| | | |
--- --- --- ---
|H11| |H12| |H21| |H22|
--- --- --- ---
Figure 1: Two moving networks auto-configuration
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).
Pfister & Petrescu Expires November 23, 2013 [Page 6]
Internet-Draft Moving networks prefix exchange May 2013
5. Message Format
The RIO is defined in [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.
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) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'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.
'R': Two reserved bits. They MUST be initialized to zero
by the sender and ignored by the receiver.
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 [RIO].
Pfister & Petrescu Expires November 23, 2013 [Page 7]
Internet-Draft Moving networks prefix exchange May 2013
6. Host Specifications
[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.
Pfister & Petrescu Expires November 23, 2013 [Page 8]
Internet-Draft Moving networks prefix exchange May 2013
7. Router Specifications
7.1. Router configuration
Routers SHOULD NOT set the Mobile Network Prefix flag by default in
the Route Information options they send but they SHOULD be
configureable.
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.
7.2. Accepting a Route Information option
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.
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...).
7.3. Using a Route Information option
When accepted, a RIO is used as defined in [RIO] for type C hosts.
The receiving router is free to give any metric to the newly
introduced route.
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.
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.
Pfister & Petrescu Expires November 23, 2013 [Page 9]
Internet-Draft Moving networks prefix exchange May 2013
8. Security Considerations
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.
8.1. Using IPSec
IPSec [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.
8.2. Using SeND
SeND [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.
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.
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.
Pfister & Petrescu Expires November 23, 2013 [Page 10]
Internet-Draft Moving networks prefix exchange May 2013
9. IANA Considerations
IANA is kindly requested by the authors to allocate the following
value:
o Space allocation for the Mobile Network Prefix flag in the Route
Information option.
Pfister & Petrescu Expires November 23, 2013 [Page 11]
Internet-Draft Moving networks prefix exchange May 2013
10. Acknowledgements
Pfister & Petrescu Expires November 23, 2013 [Page 12]
Internet-Draft Moving networks prefix exchange May 2013
11. References
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NEIGHDISC]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RIO] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RADNS] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[IPSEC] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Pfister & Petrescu Expires November 23, 2013 [Page 13]
Internet-Draft Moving networks prefix exchange May 2013
Authors' Addresses
Pierre Pfister
Commissariat a l'Energie Atomique
8 Avenue de la Vauve
Palaiseau, Ile-de-France 91120
FR
Email: pierre.pfister@polytechnique.org
Alexandru Petrescu
Commissariat a l'Energie Atomique
8 Avenue de la Vauve
Palaiseau, Ile-de-France 91120
FR
Email: alexandru.petrescu@cea.fr
Pfister & Petrescu Expires November 23, 2013 [Page 14]
