Internet DRAFT - draft-chelius-nemo-router-autoconf
draft-chelius-nemo-router-autoconf
Internet Draft G.Chelius
Document: draft-chelius-nemo-router-autoconf-00.txt E. Fleury
Expires: July 2005 INRIA
E. K. Paik
KT
L. Toutain
ENST Bretagne
January 2005
Distributed Prefix-Delegation Scheme for NEMO
<draft-chelius-nemo-router-autoconf-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author certifies that any applicable patent or other IPR claims of
which he or she is aware have been disclosed, or will be disclosed,
and any of which he or she becomes aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes a distributed prefix delegation scheme for
IPv6 mobile networks by allowing a consensus on the prefix part of
Ipv6 addresses for each link of the network.
Table of Contents
1. Overview......................................................2
2. Terminologies.................................................3
3. Algorithm description.........................................3
3.1 Protocol bootstrap...........................................4
3.2 Link Management..............................................4
3.3 Global Prefix advertisement..................................4
Chelius Expires - July 2005 [Page 1]
Distributed Prefix Delegation January 2005
3.4 Prefix attribution...........................................4
4. Events........................................................5
4.1 Collision Avoidance..........................................5
4.2 Merging of several networks.................................5
5. Routers internal data structures..............................5
6. Definition of PUMs............................................6
6.1 Prefix PUM...................................................6
6.2 Global Prefix PUM............................................6
7. PUM Format....................................................7
7.1 P-PUM Format.................................................7
7.2 GP-PUM Format................................................7
8. Examples Usage with NEMO......................................8
9. Security Considerations.......................................8
Normative References.............................................9
A.Related Protocols: OSPF........................................9
B.Example Usage and Configuration with the Length of Global Prefix
and SID..........................................................9
Author's Addresses..............................................10
1. Overview
Auto-configuration in IPv6 has been defined for hosts, but
knowledge of the network topology is still required for routers
configuration since the prefix part of the IPv6 address reflects
the topology. This is not a problem in the context of large
companies but it may limit the spread of IPv6 for small companies
or for in-house networking or for network mobility (NEMO). In this
latter case, even if the network size is limited, the topology can
be complex due to the use of different technologies (CDMA, IEEE
802.11, Bluetooth...). It is difficult to delegate the network
configuration to the ISP since several routers may be involved. In
a simple model, the home agent (HA) connected to the ISP forwards
packets to the different supports used to compose the mobile
network. The mobile network may be multi-homed, since several
accesses (GPRS, ADSL...) may be available at the same time. The
mobile network may also evolve dynamically as, for example,
Bluetooth links may leave or enter the network.
Our proposal is to define Prefix Update Messages (PUMs) that are
flooded in the Self-Configured Network (SCN) to allow automatic
configuration of the Prefix part of an IPv6 address. Our algorithm
guaranties consensus and a strong stability for the prefix chosen
by a given link and uniqueness of the prefix in a SCN. One or more
HAs can connect the mobile network to ISPs. These HAs can be
configured by standard means to learn the Global Prefix from the
ISP. Site-local Global Prefix (FEC0::/48) or other well-known
valuecan be used in any case, but must be used explicitly when no
other global Global Prefix is advertised.
Chelius Expires - July 2005 [Page 2]
Distributed Prefix Delegation January 2005
2. Terminologies
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].
This draft creates and/or extends the terms as follows:
o Global Prefix: the first bits of an IPv6 address which are common
to the whole network. Typically, Global Prefixes are provided by
ISPs to Edge Routers using a delegation protocol.
o Site ID (SID): the remaining bits of an IPv6 address before the
Interface ID. SID follows Global Prefix. As an example, if the
Global Prefix length is 48 bits, the SID size is 16 bits.
o Prefix: concatenation of a Global Prefix and a SID that forms the
64-bits prefix of an IPv6 address.
o Prefix Update Message (PUM): a message that advertises some
prefix (Global Prefix or Prefix) informations.
o Self-Configured Network (SCN): a set of links and routers running
the auto-configuration protocol.
o Edge Router (ER):a router which is provided with a Global Prefix.
Typically, ER are directly connected to ISPs.
o Router ID (RID): a 128 bits value associated to each router. RIDs
must be unique in the SCN.
o Interface Index Value (IIV): a 32 bits value associated to a
router interface. IIVs must be unique in a router.
o Link ID (LID): a 160 bits value built by concatenation of the
link dedicated router RID and the IIV of the link dedicated router
interface attached to the considered link. LIDs are unique in the
SCN.
o Dedicated Router (DR): a particular router which is responsible
for choosing the link SID and advertising the link prefixes. DR are
elected through a dedicated router election algorithm which is
associated to the Hello protocol.
Other terminologies related to mobility are defined in
[RFC3753], [RFC3775], and [NEMO-term].
3. Algorithm description
Chelius Expires - July 2005 [Page 3]
Distributed Prefix Delegation January 2005
This protocol automatically delegates unique prefixes to the
different links of the SCN. On each link, a dedicated router is
elected. This dedicated router is responsible for the attribution
of a Prefix to the link and for the advertisement of the chosen
Prefix in the SCN. Advertisement of Prefixes is performed through
the flooding of PUMs. Each router internally records the list of
already attributed Prefixes in a PUM database. Knowledge of already
attributed Prefixes allows the detection of collisions as well as
Prefix collision avoidance during the choice of a new Prefix.
3.1 Protocol bootstrap
Each router is identified by a 128 bits Router ID (RID). This RID
may be either manually provided or randomly chosen during the
protocol bootstrap.
Each interface of a router is internally uniquely identified by an
Interface Index Value (IIV). Indexation of the router interfaces is
performed arbitrarily and automatically during the protocol
bootstrap.
3.2 Link Management
Routers use a Hello protocol to detect other routers on each of
their interfaces. If no Dedicated Router (DR) is present for a
particular link, a DR election is performed. If a DR is present,
each router on the link associates the Link ID (LID), i.e., the
concatenation of RID and IIV of the dedicated router, to its link-
connected interface.
For more information on the Hello protocol and the DR election
protocol, please refer to annex A.
3.3 Global Prefix advertisement
Edge Routers (ER) are responsible for advertising Global Prefixes
to the SCN using a Global Prefix PUM (GP-PUM). Upon reception of a
GP-PUM, all routers record the available Global Prefixes in their
PUM database.
A GP-PUM contains both the edge router RID and the list of the
Global Prefixes that are available to the edge router.
3.4 Prefix attribution
It is the responsibility of a DR to attribute Prefixes to a link.
For a given link, the DR builds Prefixes by concatenation of the
available Global Prefixes and one or several arbitrary SIDs. The
choice of the SID should be such that the link Prefixes are unique
Chelius Expires - July 2005 [Page 4]
Distributed Prefix Delegation January 2005
regarding the different already attributed Prefixes contained in
the DR PUM database. After creation of the link Prefixes, the DR
advertise them in the SCN using a Prefix PUM (P-PUM). Upon
reception of a P-PUM, routers record the Prefixes in their PUM
database.
A P-PUM contains both the concerned LID (RID+IIV of the link
dedicated router) and the list of the Prefixes that have been
chosen for the link.
SIDs are chosen randomly, but the risk of collisions is very low,
since routers know, from the PUM database, the already chosen
Prefixes. This risk is higher when two partitioned networks merge.
4. Events
This section explains how the proposed protocol avoids prefix
collision. In addition, it manages merging of several networks.
4.1 Collision Avoidance
A new zero conf router entering on a link:
o synchronizes its PUM database with the link DR.
o accepts the link Prefixes. If collision occurs for some of its
other links, the DR of the link with the smallest LID will renumber
the link Prefixes.
o Configures its internal variables to inform hosts of the chosen
prefix through the neighbor discovery protocol [RFC2461].
Note that, as IPv6 prefixes cannot be guessed a priori, since the
SID is randomly chosen, the DNS registration cannot be done
manually. Hosts must use DNS dynamic updates, if they want to
register their addresses. This is not incompatible with the goal of
a zero conf network.
4.2 Merging of several networks
When several networks are merged, the PUM databases of all
routers are synchronized. All routers receive the list of all
Prefixes allocated in the network. In case of conflict, two or more
links having the same Prefixes, DRs of the links with the smallest
LIDs will renumber their Prefixes.
5. Routers internal data structures
Chelius Expires - July 2005 [Page 5]
Distributed Prefix Delegation January 2005
Routers will keep the following pieces of information for each
interface running the protocol.
o LID: RID+IIV of the link dedicated router.
o Prefix-list: List of (Prefixes, LID) already attributed in the
SCN. This list is kept up-to-date upon reception of P-PUMs.
o Global Prefix-list: list of Global Prefix values available in the
network.This list is kept up-to-date upon reception of GP-PUMs.
o Global Prefix-to-export: list of Global Prefixs to declare in the
SCN. This list is modified by system management. For instance,
Global Prefixs can be provided by an ISP.
6. Definition of PUMs
This protocol defines two types of PUM according to the prefix
information it carries. These are Prefix PUM (P-PUM) and Global
Prefix PUM (GP-PUM).
6.1 Prefix PUM
A P-PUM is originated for every links by the link's DR. The P-PUM
contains the link LID and the link attributed Prefixes. P-PUMs
must be flooded in the whole SCN. P-PUMs have a limited lifetime in
the PUM database.
The events causing P-PUMs to be reoriginated, are the following:
o Some Prefix of the link is modified after collisions.
o Expiration of the P-PUM lifetime: a DR must reoriginate a P-PUM
before expiration of the corresponding previous P-PUM.
Upon reception of a P-PUM, a router first removes from its PUM
database all older P-PUM with the same LID. Secondly, for each of
its interfaces, it compares the received Prefixes and LID with its
interface ones. There is collision if the LIDs differ and the
Prefixes are equal.
6.2 Global Prefix PUM
GP-PUMs must be flooded in the whole SCN. A GP-PUM is originated by
all ERs. The GP-PUM lists all Global Prefixes provided by the ER.
GP-PUMs have a limited lifetime in the PUM database.
The events causing GP-PUM to be reoriginated, are the following:
Chelius Expires - July 2005 [Page 6]
Distributed Prefix Delegation January 2005
o The Global Prefix-to-export list of the ER is modified.
o Expiration of the GP-PUM lifetime: an ER must reoriginate its GP-
PUM before expiration of its previous GP-PUM.
Upon reception of a Global Prefix PUM, a router adds all received
Global Prefixes to the Global Prefix lists of all its interfaces.
7. PUM Format
This section describes the format of the P-PUMs and GP-PUMs.
7.1 P-PUM Format
P-PUMs have the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| LID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LID
The Link-ID.
Prefixes
Prefixes attributed to the link.
7.2 GP-PUM Format
GP-PUMs have the following format.
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
Chelius Expires - July 2005 [Page 7]
Distributed Prefix Delegation January 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| RID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of Prefix 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Prefix 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
RID
Edge Router RID
Size of Prefix
Size of the next Global Prefix.
Global Prefix
Global prefix available to the Edge Router.
8. Examples Usage with NEMO
When a mobile network wants to be delegated a prefix on its home
link, above protocol is operated as follows: a HA acts as an ER of
our proposed protocol and an MR as a DR.
When more than one mobile networks are merged into one, or a mobile
network is splitted into two or more moboile networks, the proposed
protocol manages prefixes as described in Section 4.2. The
operation described in Section 4.2. can also be performed with
nested mobile networks or multihomed mobile networks.
9. Security Considerations
In rare case, this protocol may lead to aberrations in network
addressing and routing. The sanity of the protocol relies on the
fact that two links will not have the same link ID. As this 128bits
value is chosen randomly, the risk of collision is small.
As OSPF, when running over IPv6, this protocol relies on the IP
Authentication Header (see [Ref19]) and the IP Encapsulating
Security Payload (see [Ref20]) to ensure integrity and
authentication/confidentiality of routing exchanges.
Most implementations will be running on systems that support
multiple protocols, many of them having independent security
assumptions and domains. When IPSEC is used to protect OSPF packets,
it is important for the implementation to check the IPSEC SA, and
Chelius Expires - July 2005 [Page 8]
Distributed Prefix Delegation January 2005
local SA database to make sure that the packet originates from
source THAT IS TRUSTED FOR OSPF PURPOSES.
Normative References
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload(ESP)", RFC 2406, November 1998.
[RFC2740] Coltun, R. and Ferguson, D. and J. Moy, "OSPF for IPv6",
RFC 2470, December 1999.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirements Levels", RFC 2119, March 1997.
[RFC2461] Narten, T. and Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2641, December 1998.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[NEMO-term] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-01 (work in progress),
February 2004.
A.Related Protocols: OSPF
Several mechanisms are not detailed in this draft. They are the
Hello protocol, the DR election protocol, the PUM database
synchronization protocol and the PUM flooding protocol. These
different protocols are very similar to the ones used in OSPF. We
propose to adapt the OSPF mechanisms to be used with our protocol.
B.Example Usage and Configuration with the Length of Global Prefix and
SID
We can configure the length of the Global Prefix and SID according
to the scale of mobile networks and/or the number of mobile
networks that a HA manages. By the flexible configuration of the
length of Global Prefix and SID, we can also optimize the prefix
delegation process. But, the optimization of the length of the
Global Prefix and SID is out of scope of this draft.
Chelius Expires - July 2005 [Page 9]
Distributed Prefix Delegation January 2005
Author's Addresses
Guillaume Chelius
Ares, Inria, France
Email: guillaume.chelius@inria.fr
Eric Fleury
Insa de Lyon, France
Email: Eric.Fleury@inria.fr
Laurent Toutain
ENST Bretagne, France
Email: Laurent.Toutain@enst-bretagne.fr
Eun Kyoung Paik
KT, Korea
Email: euna@kt.co.kr
Copyright Statement
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Chelius Expires - July 2005 [Page 10]
