idnits 2.17.1 draft-chelius-router-autoconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 578 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ref19' is mentioned on line 301, but not defined == Missing Reference: 'Ref20' is mentioned on line 302, but not defined == Unused Reference: 'RFC2402' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2641 (ref. 'RFC2461') Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft G. Chelius 3 Document: draft-chelius-router-autoconf-00.txt E. Fleury 4 13 June 2002 Inria, France 5 L. Toutain 6 ENST Bretagne, France 8 Using OSPFv3 for IPv6 router autoconfiguration 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document proposes the definition of three new OSPFv3 LSA types 34 for auto-configuration of IPv6 networks with routers by allowing a 35 consensus on the SLA part of the IPv6 address for each link of the 36 network. 38 Table of Contents 40 Status of this Memo................................................1 41 Abstract...........................................................1 42 1. Overview........................................................2 43 2. Conventions used in this document...............................2 44 3. Algorithm description...........................................3 45 3.1. Merging of a new router.......................................3 46 3.2. Merging of several networks...................................4 47 3.3. Use with OSPF Areas...........................................4 48 4. Routers internal data structures................................4 50 Chelius, Fleury, Toutain Expires 13 December 2002 1 51 5. Definition of LSAs..............................................5 52 5.1. SLA-Link LSA..................................................5 53 5.2. SLA-Area LSA..................................................5 54 5.3. TLA-Site LSA..................................................6 55 6. Security Considerations.........................................6 56 7. IANA consideration..............................................7 57 8. References......................................................8 58 A. LSA Format......................................................8 59 A.1. SLA-Link LSA Format...........................................8 60 A.2. SLA-Area LSA Format...........................................8 61 A.3. TLA-Site LSA Format...........................................9 62 Author's Addresses.................................................9 64 1. Overview 66 Auto-configuration in IPv6 has been defined for hosts, but knowledge 67 of the network topology is still required for routers configuration 68 since the SLA part of the IPv6 address reflects the topology. This 69 is not a problem in the context of large companies but it may limit 70 the spread of IPv6 for small companies or for home networking. In 71 this latter case, even if the network size is limited, the topology 72 can be complex due to the use of different technologies (HomePNA, 73 IEEE 802.11, Bluetooth�). It is difficult to delegate the network 74 configuration to the ISP since several routers may be necessary. In 75 a simple model, the edge router connected to the ISP forwards 76 packets to the different supports used to compose the home network. 77 This model is very restrictive since, for instance, some wireless 78 networks may be directly unreachable from the edge router but 79 accessible from some intermediary routers. The home network may be 80 multi-homed, since several accesses (GPRS, ADSL,�) may be available 81 at the same time. The home network may also evolve dynamically as, 82 for example, Bluetooth links may leave or enter the network. 84 Our proposal is to define three new OSPFv3 LSAs to allow automatic 85 configuration of the SLA part of an IPv6 address. Our algorithm 86 guaranties consensus and a strong stability for the SLA chosen by a 87 given link and uniqueness of the TLA-SLA association in a site. One 88 or more edge routers can connect the home network to ISPs. These 89 edge routers can be configured by standard means to learn the TLA 90 from the ISP. Site-local TLA (FEC0::/48) can be used in any case, 91 but must be used explicitly when no other global TLA is advertised. 93 The protocol can also work if the network is splited into OSPF 94 areas. This is not pure zero-configuration since areas cannot be 95 discovered automatically. With areas, some protocol enhancements can 96 be defined to improve scalability by prefix aggregation. 98 2. Conventions used in this document 100 Chelius, Fleury, Toutain Expires 13 December 2002 2 101 This document uses terms from the OSPFv3 protocol as described in 102 RFC-2740 [RFC2740]. 104 In addition, this draft uses the following terms: 106 o TLA: the first 48 bits of an IPv6 address. 108 o SLA: the 16 following bits of an IPv6 address. 110 o TLA-SLA association: concatenation of a TLA and a SLA that forms 111 the 64-bits prefix of an IPv6 address. 113 o Site: an OSPF site corresponds to an OSPF AS (autonomous system) 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 117 this document are to be interpreted as described in RFC-2119 118 [RFC2119]. 120 3. Algorithm description 122 Three OSPFv3 LSAs are defined in this protocol: 124 o SLA-Link LSA: it carries the SLA chosen by the Designated Router 125 on the link. The scope of this LSA is the link. This LSA is used to 126 generate a consensus about the link SLA. 128 o SLA-Area: it carries the SLA obtained by consensus on the link. 129 The scope of this LSA is the area. This LSA is used to detect and 130 avoid SLA collisions between different links of the network. 132 o TLA-Site: it carries the TLA(s) chosen by the ISP(s). The scope of 133 this LSA is the OSPF network. This LSA is used to generate prefixes 134 by concatenation with the SLAs obtained by consensus. 136 SLAs are chosen randomly, but the risk of collisions is very low, 137 since routers know, from the OSPF database, the already chosen SLAs. 138 This risk is higher when two partitioned networks merge. 140 3.1. Merging of a new router 142 A new zero conf router entering on a link: 144 o synchronizes its OSPF database with the designated router. 146 o accepts the SLA value of the designated router. If collision 147 occurs for some of its other links, interfaces with the smallest 148 link IDs will renumber their SLA. 150 o Configures its internal variables to inform hosts of the chosen 151 prefix through the neighbor discovery protocol [RFC2461]. 153 Chelius, Fleury, Toutain Expires 13 December 2002 3 154 o Injects the negotiated prefixes in the routing OSPF database to 155 allow prefix advertisement. 157 Note that, as IPv6 prefixes cannot be guessed a priori, since the 158 SLA is randomly chosen, the DNS registration cannot be done 159 manually. Hosts must use DNS dynamic updates, if they want to 160 register their addresses. This is not incompatible with the goal of 161 a zero conf network. 163 3.2. Merging of several networks 165 When several networks merge, OSPF synchronizes the databases of all 166 routers. All routers receive the list of all SLAs allocated in the 167 network. In case of conflict, two or more links have the same SLA, 168 all conflicting links with the smallest IDs will have to renumber 169 their SLA. 171 The renumbering process is the following. All routers of a 172 conflicting link generate a new potential SLA for the link but only 173 the Designated Router fixes the new SLA. New potential SLAs are 174 chosen randomly but avoid the already chosen SLAs in the network. 176 3.3. Use with OSPF Areas 178 This protocol allows the negociation of only a portion of a link 179 SLA. The remaining part of the SLA can be manually configured. 181 This feature allows address aggregation in the case of OSPF areas. 182 All links of an area may share a portion of their SLA. 184 4. Routers internal data structures 186 Routers will keep the following pieces of information for each 187 interface running the protocol. 189 o Link-ID: 128 bit that identifies the link the interface is 190 attached to. This value is chosen randomly at the interface startup 191 and may change upon reception of a SLA-Link LSA. 193 o SLA-value: SLA value of the link the interface is attached to. 194 This value is chosen randomly at the interface startup and may 195 change upon reception of a SLA-Link LSA. Its length is equal to SLA- 196 length bits. 198 o SLA-length: the length of the SLA portion that is negotiated by 199 the protocol for the link. The default value is 16 bits and can be 200 changed by system management and upon reception of a SLA-Link LSA. 202 o SLA-prefix: the portion of the SLA that is not negotiated by the 203 protocol. Its length is equal to (16 - SLA-length)bits. The default 204 value is 0 and can be changed by system management and upon 205 reception of a SLA-Link LSA. 207 Chelius, Fleury, Toutain Expires 13 December 2002 4 208 o TLA-list: list of TLA values available in the network. By default, 209 this list only contains the TLA value of the site-local prefix (i.e. 210 fec0::/48). This list changes depending on the reception of TLA-site 211 LSAs. 213 The prefixes negotiated for a link by the protocol are built by 214 concatening a TLA with the SLA-prefix and the SLA-value of an 215 interface for all TLAs of the TLA list. 217 We can notice that modification of the SLA-length induces 218 modifications of the SLA-prefix and SLA-value. 220 Edge routers also have the following piece of information: 222 o TLA-to-export: list of TLAs to declare in the site. This list is 223 modified by system management. For instance, TLAs can be provided by 224 an ISP. 226 5. Definition of LSAs 228 This protocol defines three new LSA types: SLA-Link, SLA-Area and 229 TLA-Site. 231 5.1. SLA-Link LSA 233 The LS type of a SLA-Link LSA is set to the value . 234 SLA-Link LSAs have link flooding scope. A SLA-Link LSA is originated 235 for every broadcast or NBMA link having two or more attached 236 routers, by the link's Designated Router. The SLA-Link LSA gives the 237 SLA-value, the SLA-length, the SLA-prefix and the Link-ID for the 238 link. 240 The events causing SLA-Link LSAs to be reoriginated, are the 241 following: 243 o The SLA-value of a link interface is modified. 245 o The SLA-prefix of a link interface is modified. 247 Upon reception of a SLA-Link LSA, a router updates the SLA-value, 248 SLA-length, SLA-prefix and Link-ID of its receiving interface with 249 the received ones. 251 5.2. SLA-Area LSA 253 The LS type of a SLA-Area LSA is set to the value . 254 SLA-Area LSAs have area flooding scope. A SLA-Area LSA is originated 255 for every broadcast or NBMA link having two or more attached 256 routers, by the link's Designated Router. The SLA-Area LSA gives the 257 SLA of the link. 259 Chelius, Fleury, Toutain Expires 13 December 2002 5 260 The events causing SLA-Area LSAs to be reoriginated, are the 261 following: 263 o The SLA-value of a link interface is modified. 265 o The SLA-prefix of a link interface is modified 267 Upon reception of a SLA-Area LSA, a router first removes from its 268 OSPF database all older SLA-Area LSAs with the same Link-ID. 269 Secondly, for each of its interfaces, it compares the received SLA 270 and Link-ID with its interface ones. There is collision if the Link- 271 IDs differ and the SLAs are equal. 273 In the case of a collision, the router renumbers the SLA if its 274 interface Link-ID is smaller than the received one. Renumbering is 275 done randomly. The new SLA must not already be present in any SLA- 276 Area LSA of its database. 278 5.3. TLA-Site LSA 280 The LS type of a TLA-Site LSA is set to the value . 281 TLA-Site LSAs have site flooding scope. A TLA-Site LSA is originated 282 for all edge routers by the corresponding edge router. The TLA-Site 283 LSA lists all TLA provided by the edge router. 285 The events causing SLA-Area LSAs to be reoriginated, are the 286 following: 288 o The TLA-to-export list of the edge router is modified. 290 Upon reception of a TLA-to-export LSA, a router adds all received 291 TLAs to the TLA lists of all its interfaces. 293 6. Security Considerations 295 In rare case, this protocol may lead to aberrations in network 296 addressing and routing. The sanity of the protocol relies on the 297 fact that two links will not have the same link ID. As this 128bits 298 value is chosen randomly, the risk of collision is small. 300 As OSPF, when running over IPv6, this protocol relies on the IP 301 Authentication Header (see [Ref19]) and the IP Encapsulating 302 Security Payload (see [Ref20]) to ensure integrity and 303 authentication/confidentiality of routing exchanges. 305 Most implementations will be running on systems that support 306 multiple protocols, many of them having independent security 307 assumptions and domains. When IPSEC is used to protect OSPF packets, 308 it is important for the implementation to check the IPSEC SA, and 310 Chelius, Fleury, Toutain Expires 13 December 2002 6 311 local SA database to make sure that the packet originates from a 312 source THAT IS TRUSTED FOR OSPF PURPOSES. 314 7. IANA consideration 316 Three OSPFv3 LSA type have to be defined: one with a link scope, the 317 other with a area scope and the last with a site scope. 319 Chelius, Fleury, Toutain Expires 13 December 2002 7 320 8. References 322 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 323 2402, November 1998. 325 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 326 Payload(ESP)", RFC 2406, November 1998. 328 [RFC2740] Coltun, R. and Ferguson, D. and J. Moy, "OSPF for IPv6", 329 RFC 2470, December 1999. 331 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 332 Requirements Levels", RFC 2119, March 1997. 334 [RFC2461] Narten, T. and Nordmark, E. and W. Simpson, "Neighbor 335 Discovery for IP Version 6 (IPv6)", RFC 2641, December 1998. 337 A. LSA Format 339 This appendice describes the format of the SLA-Link, SLA-Area and 340 TLA-Site LSAs. 342 A.1. SLA-Link LSA Format 344 SLA-Link LSAs have LS type equal to . 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 | Link-ID | 351 | | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | SLA | SLA-length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Link-ID 358 The Link-ID value of the sending interface. 360 SLA 361 Concatenation of the SLA-prefix and SLA-value of the sending 362 interface. 364 SLA-length 365 The SLA-length of the sending interface. 367 A.2. SLA-Area LSA Format 369 Chelius, Fleury, Toutain Expires 13 December 2002 8 370 SLA-Area LSAs have LS type equal to 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | | 376 | Link-ID | 377 | | 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Reserved | SLA | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Link-ID 384 The Link-ID value for the sending interface. 386 Reserved 387 0 389 SLA 390 Concatenation of the SLA-prefix and SLA-value of the sending 391 interface. 393 A.3. TLA-Site LSA Format 395 TLA-Site LSAs have LS type equal to 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Reserved | | 401 +-+-+-+-+-+-+-+-++-+-+-+-+-++-+-+ + 402 | TLA | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | ... | 406 Reserved 407 0 409 TLA 410 All TLAs of the TLA-to-export list of the sending router. 412 Author's Addresses 414 Guillaume Chelius 415 Ares, Inria, France 416 Email: gchelius@telecom.insa-lyon.fr 418 Eric Fleury 419 Ares, Inria, France 420 Email: Eric.Fleury@inria.fr 422 Chelius, Fleury, Toutain Expires 13 December 2002 9 423 Laurent Toutain 424 ENST Bretagne, France 425 Email: Laurent.Toutain@enst-bretagne.fr 427 Chelius, Fleury, Toutain Expires 13 December 2002 10