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 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]