Internet Draft G. Chelius Document: draft-chelius-router-autoconf-00.txt E. Fleury 13 June 2002 Inria, France L. Toutain ENST Bretagne, France Using OSPFv3 for IPv6 router autoconfiguration <draft-chelius-router-autoconf-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 the definition of three new OSPFv3 LSA types for auto-configuration of IPv6 networks with routers by allowing a consensus on the SLA part of the IPv6 address for each link of the network. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Overview........................................................2 2. Conventions used in this document...............................2 3. Algorithm description...........................................3 3.1. Merging of a new router.......................................3 3.2. Merging of several networks...................................4 3.3. Use with OSPF Areas...........................................4 4. Routers internal data structures................................4 Chelius, Fleury, Toutain Expires 13 December 2002 1 Internet Draft IPv6 router autoconfiguration 13 June 2002 5. Definition of LSAs..............................................5 5.1. SLA-Link LSA..................................................5 5.2. SLA-Area LSA..................................................5 5.3. TLA-Site LSA..................................................6 6. Security Considerations.........................................6 7. IANA consideration..............................................7 8. References......................................................8 A. LSA Format......................................................8 A.1. SLA-Link LSA Format...........................................8 A.2. SLA-Area LSA Format...........................................8 A.3. TLA-Site LSA Format...........................................9 Author's Addresses.................................................9 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 SLA 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 home networking. In this latter case, even if the network size is limited, the topology can be complex due to the use of different technologies (HomePNA, IEEE 802.11, Bluetoothà). It is difficult to delegate the network configuration to the ISP since several routers may be necessary. In a simple model, the edge router connected to the ISP forwards packets to the different supports used to compose the home network. This model is very restrictive since, for instance, some wireless networks may be directly unreachable from the edge router but accessible from some intermediary routers. The home network may be multi-homed, since several accesses (GPRS, ADSL,à) may be available at the same time. The home network may also evolve dynamically as, for example, Bluetooth links may leave or enter the network. Our proposal is to define three new OSPFv3 LSAs to allow automatic configuration of the SLA part of an IPv6 address. Our algorithm guaranties consensus and a strong stability for the SLA chosen by a given link and uniqueness of the TLA-SLA association in a site. One or more edge routers can connect the home network to ISPs. These edge routers can be configured by standard means to learn the TLA from the ISP. Site-local TLA (FEC0::/48) can be used in any case, but must be used explicitly when no other global TLA is advertised. The protocol can also work if the network is splited into OSPF areas. This is not pure zero-configuration since areas cannot be discovered automatically. With areas, some protocol enhancements can be defined to improve scalability by prefix aggregation. 2. Conventions used in this document Chelius, Fleury, Toutain Expires 13 December 2002 2 Internet Draft IPv6 router autoconfiguration 13 June 2002 This document uses terms from the OSPFv3 protocol as described in RFC-2740 [RFC2740]. In addition, this draft uses the following terms: o TLA: the first 48 bits of an IPv6 address. o SLA: the 16 following bits of an IPv6 address. o TLA-SLA association: concatenation of a TLA and a SLA that forms the 64-bits prefix of an IPv6 address. o Site: an OSPF site corresponds to an OSPF AS (autonomous system) 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]. 3. Algorithm description Three OSPFv3 LSAs are defined in this protocol: o SLA-Link LSA: it carries the SLA chosen by the Designated Router on the link. The scope of this LSA is the link. This LSA is used to generate a consensus about the link SLA. o SLA-Area: it carries the SLA obtained by consensus on the link. The scope of this LSA is the area. This LSA is used to detect and avoid SLA collisions between different links of the network. o TLA-Site: it carries the TLA(s) chosen by the ISP(s). The scope of this LSA is the OSPF network. This LSA is used to generate prefixes by concatenation with the SLAs obtained by consensus. SLAs are chosen randomly, but the risk of collisions is very low, since routers know, from the OSPF database, the already chosen SLAs. This risk is higher when two partitioned networks merge. 3.1. Merging of a new router A new zero conf router entering on a link: o synchronizes its OSPF database with the designated router. o accepts the SLA value of the designated router. If collision occurs for some of its other links, interfaces with the smallest link IDs will renumber their SLA. o Configures its internal variables to inform hosts of the chosen prefix through the neighbor discovery protocol [RFC2461]. Chelius, Fleury, Toutain Expires 13 December 2002 3 Internet Draft IPv6 router autoconfiguration 13 June 2002 o Injects the negotiated prefixes in the routing OSPF database to allow prefix advertisement. Note that, as IPv6 prefixes cannot be guessed a priori, since the SLA 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. 3.2. Merging of several networks When several networks merge, OSPF synchronizes the databases of all routers. All routers receive the list of all SLAs allocated in the network. In case of conflict, two or more links have the same SLA, all conflicting links with the smallest IDs will have to renumber their SLA. The renumbering process is the following. All routers of a conflicting link generate a new potential SLA for the link but only the Designated Router fixes the new SLA. New potential SLAs are chosen randomly but avoid the already chosen SLAs in the network. 3.3. Use with OSPF Areas This protocol allows the negociation of only a portion of a link SLA. The remaining part of the SLA can be manually configured. This feature allows address aggregation in the case of OSPF areas. All links of an area may share a portion of their SLA. 4. Routers internal data structures Routers will keep the following pieces of information for each interface running the protocol. o Link-ID: 128 bit that identifies the link the interface is attached to. This value is chosen randomly at the interface startup and may change upon reception of a SLA-Link LSA. o SLA-value: SLA value of the link the interface is attached to. This value is chosen randomly at the interface startup and may change upon reception of a SLA-Link LSA. Its length is equal to SLA- length bits. o SLA-length: the length of the SLA portion that is negotiated by the protocol for the link. The default value is 16 bits and can be changed by system management and upon reception of a SLA-Link LSA. o SLA-prefix: the portion of the SLA that is not negotiated by the protocol. Its length is equal to (16 - SLA-length)bits. The default value is 0 and can be changed by system management and upon reception of a SLA-Link LSA. Chelius, Fleury, Toutain Expires 13 December 2002 4 Internet Draft IPv6 router autoconfiguration 13 June 2002 o TLA-list: list of TLA values available in the network. By default, this list only contains the TLA value of the site-local prefix (i.e. fec0::/48). This list changes depending on the reception of TLA-site LSAs. The prefixes negotiated for a link by the protocol are built by concatening a TLA with the SLA-prefix and the SLA-value of an interface for all TLAs of the TLA list. We can notice that modification of the SLA-length induces modifications of the SLA-prefix and SLA-value. Edge routers also have the following piece of information: o TLA-to-export: list of TLAs to declare in the site. This list is modified by system management. For instance, TLAs can be provided by an ISP. 5. Definition of LSAs This protocol defines three new LSA types: SLA-Link, SLA-Area and TLA-Site. 5.1. SLA-Link LSA The LS type of a SLA-Link LSA is set to the value <TBD by IANA>. SLA-Link LSAs have link flooding scope. A SLA-Link LSA is originated for every broadcast or NBMA link having two or more attached routers, by the link's Designated Router. The SLA-Link LSA gives the SLA-value, the SLA-length, the SLA-prefix and the Link-ID for the link. The events causing SLA-Link LSAs to be reoriginated, are the following: o The SLA-value of a link interface is modified. o The SLA-prefix of a link interface is modified. Upon reception of a SLA-Link LSA, a router updates the SLA-value, SLA-length, SLA-prefix and Link-ID of its receiving interface with the received ones. 5.2. SLA-Area LSA The LS type of a SLA-Area LSA is set to the value <TBD by IANA>. SLA-Area LSAs have area flooding scope. A SLA-Area LSA is originated for every broadcast or NBMA link having two or more attached routers, by the link's Designated Router. The SLA-Area LSA gives the SLA of the link. Chelius, Fleury, Toutain Expires 13 December 2002 5 Internet Draft IPv6 router autoconfiguration 13 June 2002 The events causing SLA-Area LSAs to be reoriginated, are the following: o The SLA-value of a link interface is modified. o The SLA-prefix of a link interface is modified Upon reception of a SLA-Area LSA, a router first removes from its OSPF database all older SLA-Area LSAs with the same Link-ID. Secondly, for each of its interfaces, it compares the received SLA and Link-ID with its interface ones. There is collision if the Link- IDs differ and the SLAs are equal. In the case of a collision, the router renumbers the SLA if its interface Link-ID is smaller than the received one. Renumbering is done randomly. The new SLA must not already be present in any SLA- Area LSA of its database. 5.3. TLA-Site LSA The LS type of a TLA-Site LSA is set to the value <TBD by IANA>. TLA-Site LSAs have site flooding scope. A TLA-Site LSA is originated for all edge routers by the corresponding edge router. The TLA-Site LSA lists all TLA provided by the edge router. The events causing SLA-Area LSAs to be reoriginated, are the following: o The TLA-to-export list of the edge router is modified. Upon reception of a TLA-to-export LSA, a router adds all received TLAs to the TLA lists of all its interfaces. 6. 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, Fleury, Toutain Expires 13 December 2002 6 Internet Draft IPv6 router autoconfiguration 13 June 2002 local SA database to make sure that the packet originates from a source THAT IS TRUSTED FOR OSPF PURPOSES. 7. IANA consideration Three OSPFv3 LSA type have to be defined: one with a link scope, the other with a area scope and the last with a site scope. Chelius, Fleury, Toutain Expires 13 December 2002 7 Internet Draft IPv6 router autoconfiguration 13 June 2002 8. 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. A. LSA Format This appendice describes the format of the SLA-Link, SLA-Area and TLA-Site LSAs. A.1. SLA-Link LSA Format SLA-Link LSAs have LS type equal to <TBD by IANA>. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Link-ID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLA | SLA-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link-ID The Link-ID value of the sending interface. SLA Concatenation of the SLA-prefix and SLA-value of the sending interface. SLA-length The SLA-length of the sending interface. A.2. SLA-Area LSA Format Chelius, Fleury, Toutain Expires 13 December 2002 8 Internet Draft IPv6 router autoconfiguration 13 June 2002 SLA-Area LSAs have LS type equal to <TBD by IANA> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Link-ID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link-ID The Link-ID value for the sending interface. Reserved 0 SLA Concatenation of the SLA-prefix and SLA-value of the sending interface. A.3. TLA-Site LSA Format TLA-Site LSAs have LS type equal to <TBD by IANA> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | | +-+-+-+-+-+-+-+-++-+-+-+-+-++-+-+ + | TLA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Reserved 0 TLA All TLAs of the TLA-to-export list of the sending router. Author's Addresses Guillaume Chelius Ares, Inria, France Email: gchelius@telecom.insa-lyon.fr Eric Fleury Ares, Inria, France Email: Eric.Fleury@inria.fr Chelius, Fleury, Toutain Expires 13 December 2002 9 Internet Draft IPv6 router autoconfiguration 13 June 2002 Laurent Toutain ENST Bretagne, France Email: Laurent.Toutain@enst-bretagne.fr Chelius, Fleury, Toutain Expires 13 December 2002 10