Internet Draft A. Dimitrelis A. Williams Document: draft-dimitri-zospf-00.txt Motorola Expires: April 2003 October 2002 Autoconfiguration of routers using a link state routing protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 memo documents our thinking to date regarding the use of version 3 of the Open Shortest Path First (OSPF) protocol as a mechanism for the autoconfiguration of IP routers within an OSPF area. Specifically, a method for the allocation and distribution of IPv4 and IPv6 subnet addresses without explicit configuration is described. Such a mechanism would be useful in an environment where routing is desirable, but the network administration skills necessary to configure IP routers are not available. This draft presents zOSPF (zeroconfigutaion OSPF), a protocol based on OSFPv3 that will allow routers to self configure and forward IPv4 and IPv6 traffic. DISCLAIMER This draft is a work in progress. Its purpose is to sketch a potential solution to the problem of router self-configuration and highlight some of the trade-offs. The hope is to gauge interest within the IETF community for solving the problem, and soliciting Dimitrelis [Page 1] Router Autoconfiguration October 2002 feedback and suggestions from the designers, implementers, and users of the protocols referred to within. The purpose of this draft is not to attempt to set in stone a complete solution to the problem. Criticism and feedback are welcome. All references to OSPF imply OSPFv3, unless stated otherwise. Table of Contents 1. Overview.......................................................2 1.3 Scope.....................................................4 2. zOSPF Protocol Operation.......................................5 2.1 Initialization............................................5 2.2 The Hello Protocol........................................5 2.2.1 Active Router ID collision resolution....................6 2.2.2 Passive Router ID collision handling.....................6 2.2.3 Link local address collision.............................7 2.2.4 zOSPF Options field......................................7 3. Exchange of routing information................................8 3.0 Handling IPv4 subnet addresses.............................8 3.1 Designated Router..........................................8 3.2 Non designated router.....................................10 3.3 Stub links................................................11 3.4 Discovering uplinks......................................12 3.5 Processing AS-external LSAs...............................13 3.6 Monitoring for subnet address collisions.................14 4. Layer 2 partitions and merges.................................15 5. Services to hosts.............................................15 6. Related Work..................................................15 Security Considerations..........................................15 References.......................................................15 Author's Addresses...............................................16 1. Overview The deployment of OSPF requires a non-trivial degree of configuration effort on the part of a network administrator, in particular the consistent and correct allocation of subnet addresses to network links. By 'consistent' we mean that all routers attached to a link must agree on that link's subnet address (although the subnet model is relaxed in IPv6), and by 'correct' we imply that for traffic to be routed reliably, each subnet must have a unique subnet address. So, the problem is one of allocating a unique subnet address to each link in the network. Dimitrelis [Page 2] Router Autoconfiguration October 2002 We believe that a protocol based on a cut-down version of OSPF for IPv6 [2] can be used within limited topologies to route both IPv4 and IPv6 traffic without requiring manual configuration. The basic idea is as follows: o A router comes up and listens. It listens for network prefixes (e.g. "the link attached to interface 3 has a subnet prefix of 2002:beef:beef:1000::/64"), and for address spaces from which it can allocate subnet prefixes (e.g. "the global prefix for this site is 2002:beef:beef::/48"). o For any links a router is attached to that do not have a prefix allocated, one particular router (the designated router) will allocate a prefix. The first router to come up on a link will typically be responsible for choosing that link's subnet prefix. o The router includes the prefixes it has allocated in future routing announcements. This allows other routers to route to the new IP subnet, and to avoid allocating the prefix to another link elsewhere in the network. o The router continues to listen, and is prepared to deal with addressing collisions by renumbering problematic subnets. With reference to OSPF, the initial "listening" stage corresponds to the formation of neighbor relationships (including participating in the designated router election) and the synchronization of link state databases. So before a router chooses a subnet prefix at random, it will have as complete a view of the network, and the prefixes in use therein, as possible. OSPF routers "announce" their choice of subnet prefixes by flooding the appropriate LSAs. In OSPFv3, a designated router that has picked a subnet address for a link will flood a Link-LSA to OSPFv3 routers on that link, and an Intra-Area Prefix LSA to all OSPF routers within the area. Finally, the ongoing listening stage corresponds to the processing of LSAs received as part of on-going OSPF operation. Other routers in the area will periodically resend valid LSA, will revoke invalid LSAs, and will originate new LSAs as new links come up and as networks merge. A zOSPF router must perform additional processing on received LSAs in order to check for prefix collisions. A router is responsible for handling collisions involving prefixes it itself allocated. Refer to section 3.6 for a more detailed discussion. OSPFv3 is a promising platform for realizing zOSPF routers because: Dimitrelis [Page 3] Router Autoconfiguration October 2002 o The exchange of OSPFv3 protocol data units occurs using IPv6 link local addressing, which is inherently configuration-free [3]. This allows the Hello protocol (in particular, the election of a designated router) and the database distribution protocol to operate in the absence of area-wide addressing. o It is straightforward to extend the responsibilities of a subnet's designated router to include the selection of that link's prefix. The choice of prefix is made after the designated router (DR) has gathered as much information about the network as possible - in other words, after it has become fully adjacent to the designated routers on its other links. At this point, the DR has a knowledge of the prefixes that are in use within the network, and is able to choose prefixes that are least likely to cause addressing collisions. o OSPF provides the means for a designated router to signal to other routers on a link the prefix that has been chosen for that link - this is the Link LSA. Changing the prefix associated with a link is also straightforward - the current Link LSA can be timed out by the originator, and a new link-LSA originated. o LSAs designed to carry IPv6 addresses can also carry IPv4 addresses, using IPv4 mapped IPv6 addresses. This allows support for routing IPv4 without the need to introduce additional protocol data units. o OSPFv3 decouples addressing and topology information. This means it is necessary to invalidate only LSAs related to addressing when a collision is detected. 1.2 Motivation The quintessential scenario motivating this draft is a home or small office, possibly connected to the Internet through an ISP. An ISP can provide a global IPv4 address, a global IPv6 prefix, or both. The site may contain any number of hosts and routers, and the network topology within may be arbitrarily complex. 1.3 Scope The purpose of this draft is to sketch an approach to creating a zero configuration routing protocol by reusing much of OSPFv3. This draft does not aim to specify a configuration-free alternative to the OSPF protocol. Several of OSPF's features are not considered, in particular: Dimitrelis [Page 4] Router Autoconfiguration October 2002 o Support for NBMA networks and point-to-multipoint links. o The ability to route between multiple OSPF areas within an Autonomous System. The assumption is made that routers talking the zOSPF protocol are within a single pre-configured area. o Interoperability with other routing protocols is not rigorously considered. Section 3.4 discusses how external prefixes can be discovered and injected into a zOSPF area. Sections detailing interoperability with established routing protocols may be added in future (and input is welcome). 2. zOSPF Protocol Operation This section describes the operation of zOSPF by detailing the sequence of events that occur from the moment a router begins operating. The zOSPF scheme is explained by detailing the processing performed by a zOSPF router in addition to that performed by an OSPFv3 router. This section assumes a familiarity with OSPFv3. 2.1 Initialization Upon commencing operation, a router must choose a 32-bit router ID. The router ID will be a pseudorandom number, and is not related to any of the router's IP addresses. If possible, a router should re-use an ID that it has previously used with success. A router's initial selection of router ID may not be final - the router may determine that the ID is in use elsewhere in the network during the exchange of database description packets as it becomes fully adjacent with neighboring designated routers. The router will set its area ID to x (0 has special meaning, i.e. backbone). A zOSPF router must also configure broadcast interfaces with IPv6 link local addresses. If a router must change an IPv6 link local address, it must allow all adjacencies based on that address to time out (see section 2.2.2). 2.2 The Hello Protocol Once a router has chosen an ID, it is able to engage in the Hello protocol, as described in sections 3.2.1.1 and 3.2.2 of [2]. A zOSPF router, just like an OSPFv3 compliant router, continues to transmit and process Hello packets for the entire time it is up. Because router IDs are chosen in a pseudorandom manner, and because the shortest path routing algorithm will fail if two or more distinct nodes are indistinguishable because of duplicate router IDs, some extra processing overhead is required to handle router ID collisions. Therefore, the zOSPF Hello protocol extends OSPF's Hello protocol by Dimitrelis [Page 5] Router Autoconfiguration October 2002 requiring zOSPF routers perform additional processing in order to detect and resolve router ID collisions with directly connected neighbors. References to router ID collisions in the following subsections imply collisions between directly connected neighbors only. 2.2.1 Active Router ID collision resolution This subsection discusses how a zOSPF router is to detect a collision involving its own router ID, and the actions it must take in order to resolve the conflict. A router will detect that it has been involved in an ID collision when it receives a Hello packet (that it did not itself originate) that contains its router ID in the router ID field of the OSPF packet header. The detecting router will send several gratuitous Hello packets using the conflicting router ID, and then choose a new ID. These Hello packets will be sent with the 'R' bit (Appendix A.3.1, [2]) cleared - this will inform other routers that it is not eligible to forward traffic. The effect will be that all routers with a conflicting ID will be excluded from SPF calculations by other routers. This is done in order to avoid a potential routing loop due to the inconsistent state of the routing table. The purpose of the gratuitous Hello packets is to ensure that the other router(s) involved in the ID collision is (are) aware of the collision. Once a router has chosen a new router ID, it may begin sending Hello packets identifying itself with this new ID. It will have to reform adjacencies with its neighbors, and re-originate its router LSA. Before announcing that it is eligible to forward packets again (by setting the R bit), a router that has been involved in a collision must be reasonably confident that the collision has been resolved. One way a router might determine the collision to have been resolved is if it receives Hello packets from each of the routers involved in the collision with new, non-colliding IDs. The routers involved in the collision can be identified by their IPv6 link local addresses, which were stored when the collision was detected. A router can also assume that it is safe to resume forwarding after it has not received Hello packets containing the problematic ID for several RouterDead intervals. 2.2.2 Passive Router ID collision handling This subsection describes how a router is to detect a router ID collision involving directly connected peers (but not the router Dimitrelis [Page 6] Router Autoconfiguration October 2002 itself), and the actions it must take in order to handle the collision. A router will detect a router ID collision on a broadcast subnet to which it is directly connected if it receives Hello messages from more than one source with the same router ID. A source is identified by its IPv6 link local address. The router will store the link local addresses of the routers it deems involved in the collision and drop neighbor relationships with them by not including their router IDs in the Neighbors section of future Hello packets. These changes will trigger an updated router LSA. The link local addresses of colliding routers, along with the colliding router ID must be stored so that future Hello packets with the invalid link-local source address/router ID combination can be ignored. The additional processing related to detecting router ID collisions involves checking the RouterID field of Hello packets and the IPv6 link local source address of the Hello packet. Since the originator of a Hello packet is identified by its IPv6 link local address (as well as its Router ID), a router's LL address cannot change if adjacencies are to be gracefully maintained. Routers must be prepared to re-establish neighbor adjacencies if they change an IPv6 link local address whilst they have existing neighbor relationships. Note that a router ID collision may result in a change of a link's Designated Router, Backup Designated Router, or both. 2.2.3 Link local address collision A layer 2 merge may bring routers with identical link-local addresses onto the same link. The detection and resolution of a LL address collision is the responsibility of the IP layer. This will entail selecting a new LL address and re-running DAD [3]. 2.2.4 zOSPF Options field This draft specifies a new bit in the options field, the Z bit. This bit will signal to routers receiving Hello, database description, and LSA packets that the originator is a zOSPF router, and is performing zOSPF related processing, as specified by this memo. The options field becomes: 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ | | | | | | | | | | | | | | | | |Z|DC| R| N|MC| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ Dimitrelis [Page 7] Router Autoconfiguration October 2002 The Options field The Options field for OSPFv3 can be found in Appendix A.3.1 of [2]. zOSPF routers will transmit all applicable zOSPF packets with the Z bit set, and will not form adjacencies with non zOSPF capable routers. Hello packets with the Z bit not set are dropped without further processing. Future versions of this draft may specify a sensible way to interact with OSPFv3 and OSPFv2 routers. 3. Exchange of routing information After initializing and participating in the Hello protocol, a router may find itself elected the designated router (DR) on one or more of the links it is connected to. This section details additional routing-related processing routers must perform depending on whether they are a link's DR or not. Section 5 lists services zOSPF routers might provide to hosts (such as DHCPv4). 3.1 Handling IPv4 subnet addresses zOSPF handles IPv4 and IPv6 routing in an integrated manner. IPv4 subnet addresses are represented within the routing protocol as IPv4 mapped IPv6 addresses [4]. A router that has claimed 192.168.120/24 for a subnet will flood a network LSA containing the prefix ::ffff:c0:a8:78:0/48. 3.2 Designated Router A broadcast link's designated router is responsible for selecting and maintaining that link's IPv4 and IPv6 subnet prefixes. When a router is elected a link's designated router it must select subnet addresses for that link. This can include an IPv4 subnet address, and a number of IPv6 prefixes. Subnet addresses are chosen in a pseudorandom manner with constraints - namely, the use of the contents of the link state database to filter poor prefix choices. Before choosing subnet prefixes, a DR must form full adjacencies with the designated routers (if any) on its other links. Forming such adjacencies will allow a router to learn which subnet prefixes are in use within a network. With its link state database synchronized, the DR is able to choose a prefix that is least likely to cause a collision. OSPF's distributed database also allows a zOSPF router to discover the address spaces it can use to form IPv6 subnet addresses. The existence and validity of a dynamically allocated prefix, such as a global or a 6to4 prefix, can be signaled using area scoped LSAs. In addition, routers can be preconfigured to allocate out of fixed Dimitrelis [Page 8] Router Autoconfiguration October 2002 address spaces - such as fec0::/48 and 192.168/16. Section 3.4 discusses how global prefixes are injected into an OSPF routing domain. Once a router has been elected the designated router (DR) on a link, it must select a set of subnet addresses for that link. The procedure for doing this follows. (1) For each of the router's other links, ensure one of the following: - The router is the designated router on the link - The router has formed a full adjacency with the DR on the link - The link is a stub link (i.e. there are no other zOSPF speakers on the link) Satisfying (1) ensures that a router that is going to choose subnet addresses has a knowledge of those subnet addresses that have already been allocated. This knowledge arises from having allocated those subnet addresses (as designated router), and from the synchronization of link state databases, which is a result of forming a full adjacency with designated routers on its other links. (2) For each site-wide prefix known to be valid within the OSPF area, choose a subnet address. Section 3.4.1 discusses how site-wide prefixes are discovered. For each /48 IPv6 site wide prefix, the router will choose a /64 IPv6 subnet address. For a /16 IPv4 prefix, a router will choose a /24 subnet address. The site allocated subnet identifier of each of the IPv6 addresses created in (2) is generated using a random number generator. The address is compared with addresses stored in the link state database. If a router generates a subnet address that clashes with an address with an entry in the routing table, the router will generate a new subnet address. (3) When a zOSPF router is satisfied that the prefixes it has chosen for a link do not collide with prefixes already in use within the OSPF area, it will configure the corresponding network interface with an address based on the new prefix. The creation of IPv6 addresses from prefixes is documented in [3]. (4) The router must inject the new prefixes into the OSPF routing domain. The process of advertising the new prefix in zOSPF is the same as the process of advertising a configured prefix in OSPFv3. The LSAs flooded are: - A new network LSA, if the link is a transit link - A new intra-area prefix LSA, if the link is a transit link. This LSA will contain the subnet address Dimitrelis [Page 9] Router Autoconfiguration October 2002 - A new router LSA. The router LSA will reference a network LSA if the link is a transit link, otherwise it will have an entry for a new stub link. Note that a newly elected designated router chooses new prefixes for a link regardless of any prefixes on the link previous to its becoming the designated router. The prefixes chosen by a previous designated router must not be reused. The rationale behind this is presented in section 3.2. For IPv6 addresses, a subnet prefix will typically be a /64 prefix, and can be created by appending a subnet identifier to a site-wide /48 prefix. A site-wide /48 prefix may be: - a publicly routable IPv6 prefix delegated to a site by an ISP - a 6to4 prefix [6] created from a public IPv4 address which has been allocated by an ISP - the IPv6 site local prefix fec0::/48 3.2 Non designated router zOSPF routers do not have subnet address information explicitly configured; they must configure their network interfaces from information via the routing protocol. Configuring interfaces with IPv6 addresses consists of learning a network prefix through routing protocol exchanges, and forming a full address using the mechanisms described in [3]. 3.2.1 Configuring IPv6 Addresses Non-designated routers will use received link LSAs to configure some of their interfaces (stub links are not configured via link LSAs, see section 3.3). A router configures an interface when it receives a link LSA on that interface. The router processes the link LSA, extracts the IPv6 prefix, and creates an IPv6 address by combining the prefix with its MAC address (using the procedure detailed in [3]). This IPv6 address is assigned to the corresponding interface. A router will invalidate an address formed as a result of processing a link LSA when: - The link LSA is timed out by its originator. - The originating router of that link LSA (i.e. the link's DR) is deemed 'dead' by the Hello protocol In the context of this document, to 'invalidate' an address means to remove its current interface binding. A router invalidating a prefix must transmit several router advertisements advertising the prefix with an expired valid lifetime. The prefix will not be moved to the Dimitrelis [Page 10] Router Autoconfiguration October 2002 deprecated state. Packets arriving with a source or destination address based on an invalidated prefix will not be forwarded. The rational behind the immediate invalidation of a prefix is based on a conservative approach to avoiding routing failures (including loops). The originator of link-LSA containing prefix Y will time-out that LSA if it detects a prefix collision involving Y. The trade-off is between invaliding an address without a period of deprecation, and attempting to route traffic with invalid routing information. In this case, a duplicate prefix constitutes the invalid routing information. It is the current position of this draft that routing based on inconsistent or invalid routing information should be avoided. A router must also immediately invalidate a link-LSA if it loses bi- directional communication with a link's designated router. Such a loss of communication will be detected by the Hello protocol. Despite becoming unreachable due to a layer 2 partition, the DR will likely continue to claim the prefix it originally chose for the link. Continuing to use the original prefix on both subnets is a prefix collision. When the DR is deemed dead, the backup designated router (BDR) will take over, and will choose a new prefix. It will flood a new set of LSAs: - A new link LSA to allow routers on the link to configure their interfaces with the new prefixes - A new network LSA, announcing the new prefix to the entire OSPF domain. This LSA also announces the link's designated router - A new router LSA, referencing the new network LSA. All other routers on the link will similarly produce a new router LSA which references the new network LSA. The old link LSA will remain in the link state database until it times out. Each on-link router will invalidate their respective router LSAs that reference the old network LSA. There are other situations where it makes sense for a DR to artificially time-out a link-LSA. An example would be timing out of subnet prefixes when they are based on a global, provider-based prefix that has expired. So it would be reasonable for a router to time out a link LSA containing the 2000:0:beef:cafe::/64 prefix when an AS border router announces that 2000:0:beef::/48 is no longer available (because the uplink to the ISP has failed, for example). 3.3 Stub links [7] describes stub links as links to which only one OSPF speaker is attached. Dimitrelis [Page 11] Router Autoconfiguration October 2002 Routers will potentially have stub links attached to some of their network interfaces. A router with attached stub links is responsible for configuring those links with network prefixes (or subnet addresses), just as Designated Routers are responsible for configuring transit networks with prefixes. In particular, a router will need to have synchronized its link state database before it begins choosing subnet addresses for stub networks. The list of area- wide prefixes from which to create subnet addresses will have built by processing AS-external LSAs (section 3.5). A router with stub links must process routing protocol exchanges for prefix collisions involving the stub links it has allocated prefixes. The constant monitoring of prefixes in use elsewhere in the network is identical to the monitoring performed by designated routers that have chosen prefixes for transit links. A router must change the prefixes it has assigned to local stub links if a prefix collision is detected. A router will update its router LSA to include any prefixes assigned to local stub links (refer to A.4.2, [7]). 3.4 Discovering uplinks A zOSPF router may have an interface connected to a global uplink, typically a residential ISP that relies on DHCP for address configuration. An area border router is responsible for injecting prefix information into the routing domain and advertising a default route. 3.4.1 Detecting an uplink This section briefly describes how a router can detect an uplink interface and obtain a global address and/or prefix. After forming adjacencies with other zOSPF routers and configuring any eligible interfaces, a router will attempt to detect an IPv4 uplink by broadcasting DHCP DISCOVER messages over those interfaces through which there are no zOSPF adjacencies. Links with zOSPF adjacencies are avoided because the designated router on each link acts as a DHCP server. If a zOSPF router receives a response from a DHCP server that is not another zOSPF speaker, it will request an IP address and configure its uplink interface with that address. DHCP responses should be filtered based on MAC address - the MAC addresses of neighboring zOSPF routers will be known, and DHCP responses from them should be ignored. A zOSPF router can also attempt to discover a global IPv6 prefix delegated by an ISP. There are currently several ways to do this, including the methods described in - [8], [3], and [9]. Dimitrelis [Page 12] Router Autoconfiguration October 2002 3.4.2 Injecting external routing information A zOSPF area border router will inject prefix and global reachability information into a zOSPF routing domain. AS-external LSAs will be used to advertise a default route, and also a delegated IPv6 prefix. The default route is advertised using AS-external LSAs as documented in [2]. If a zOSPF area border router is allocated an IPv4 address via DHCP, it will use this address to form a /48 6to4 prefix, and flood an AS- external LSA throughout the area in order to advertise this prefix. Similarly, if the site is delegated a global /48 prefix, the prefix will be signaled to other routers within the area with an AS-external LSA. This usage overloads the semantics of AS-external LSAs from the point of view of OSPFv3, as (in this instance) they are not advertising a route, but instead a prefix. The use of AS-external LSAs to flood site-wide prefix data is distinguished from their use in propagating routing information by defining a new bit in the prefix options field. This new bit is the L bit, as shown below. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | | L| P|MC|LA|NU| +--+--+--+--+--+--+--+--+ The zOSPF Prefix Options field When the L bit is set to 1, the address prefix contained in an AS- external LSA is to be interpreted as a site wide prefix that can be used to create subnet addresses. If the L bit is set to 0, the address prefix carried within the AS- external LSA will be treated as an address reachable by the originator of the LSA. The default route will always be advertised with the L bit set to 0. 3.5 Processing AS-external LSAs Section 3.4 discusses how an area border router injects AS-external LSAs into the routing domain. This section discusses additional processing that applies to AS-external LSAs carrying prefixes with the 'L' bit set in the prefix options field (refer to section 3.4.2). The purpose of AS-external LSAs within zOSPF is twofold: (1) To advertise the reachability of external prefixes. In a typical zOSPF deployment, only the default route will be advertised using an AS-external LSA. Dimitrelis [Page 13] Router Autoconfiguration October 2002 (2) To advertise IPv6 prefixes that are valid within an area. There may be multiple valid 'global' IPv6 prefixes within an area, and the same router need not have originated them. An example would be where one border router with an IPv4 uplink creates a 6to4 address while another router has a native IPv6 uplink. In this case, each router would flood a /48 IPv6 prefix and advertise a default route for IPv6 traffic. zOSPF routers use prefixes flooded within AS-external LSAs to determine the set of area-wide prefixes to use when allocating subnet addresses to attached links. The entries advertising area-wide prefixes are distinguished by having the 'L' bit set in their prefix options field. Prefixes having the 'L' bit set in their prefix options field are only to be used for creating subnet addresses are not to be used in SPF calculation. 3.6 Monitoring for subnet address collisions Routers that have allocated subnet addresses to any of their directly connected links will need to perform additional processing on Intra- area prefix LSAs in order to detect and resolve prefix collisions. Prefix collisions can occur if two routers simultaneously choose the same prefix for allocation to distinct subnets, or when two networks merge. All prefixes allocated by routers to their links will be announced via Intra-area prefix LSAs. The additional processing related to detecting prefix collisions is as follows: o A router maintains a conceptual list of the prefixes it has allocated to its links. This list includes both IPv4 and IPv6 prefixes, and may be an empty list o When a router receives an Intra-area prefix LSA that it did not originate, it compares the prefixes contained in the received LSA with those that it itself has allocated. Any prefixes advertised by another router that match a prefix claimed by this router are involved in a collision. A router that detects any of its subnet addresses to conflict with addresses claimed by another zOSPF router will discontinue advertising the contentious prefixes and choose a new subnet addresses for the affected links. The LSA advertising the problematic subnet address will be timed out immediately. Dimitrelis [Page 14] Router Autoconfiguration October 2002 4. Layer 2 partitions and merges One goal of zOSPF is that it is robust to layer 2 merges and splits. OSPF's Hello protocol will ensure the reliable election of a designated router and a backup designated router on a link in the face of layer 2 partitions and merges. This is coupled with the strategy that a router that has just taken over as a designated router chooses a new set of prefixes for a link, rather than continuing to use the old prefixes. This is because it cannot make any assumptions about why it has become designated router (refer to section 3.1). 5. Services to hosts zOSPF routers will be required to provide a DHCP service, primarily to allow hosts to configure an IPv4 address, netmask, and default route. The only active DHCP server on a link will be co-located within the designated router. A future version of this document will discuss how hosts will be notified of the premature expiration of their lease due to a subnet being renumbered. A potential approach would be a broadcast (rather than unicast) DHCP FORCERENEW message. [10] specifies the unicast DHCP FORCERENEW message. A broadcast FORCERENEW message may be necessary when a router that is not aware of existing leases assumed the role of the designated router and must renumber the subnet. 6. Related Work draft-chelius-router-autoconf-00.txt describes a scheme that utilized OSPFv3 to configure IPv6-only routers. Security Considerations The send working group has been chartered to produce mechanisms for securing IPv6 neighbor discovery. These mechanisms could potentially fit into a zOSPF scheme in the sense that only those zOSPF routers with the correct credentials will communicate with each other. References [1] Bradner, S., "The Internet Standards Process", RFC2026, October 1996 [2] Coltun, R., Ferguson, D., Moy, J., RFC2740, "OSPF for IPv6", December 1999 Dimitrelis [Page 15] Router Autoconfiguration October 2002 [3] Thomson, S., Narten, T., RFC2462, "IPv6 Stateless Address Autoconfiguration", December 1998 [4] Hinden, R., Deering, S., RFC2373, "IP Version 6 Addressing Architecture", July 1998 [5] Zinin, A., Friedman, B., Roy, A., Nguyen, L., Yeung, D., draft- nguyen-ospf-lls-01, "OSPF Link-local Signalling" (work in progress), September 2002 [6] Carpenter, B., Moore, K., RFC3056, "Connection of IPv6 Domains via IPv4 Clouds", February 2001 [7] Moy, J., RFC2178, "OSPF Version 2", April 1998 [8] Troan, O., Droms, R., draft-troan-dhcpv6-opt-prefix-delegation- 01, "IPv6 Prefix Options for DHCPv6" (work in progress), May 2002 [9] Haberman, B., Martin, J., draft-haberman-ipngwg-auto-prefix-02, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6" (work in progress), February 2002 [10] Y. T'Joens, C. Hublet, P. De Schrijver, RFC 3203, "DHCP reconfigure extension", December 2001 Author's Addresses Arthur Dimitrelis Motorola Australia Locked Bag 5028 Botany NSW 1455 Australia Email: Arthur.Dimitrelis@Motorola.com Aidan Williams Motorola Australia Locked Bag 5028 Botany NSW 1455 Australia Email: Aidan.Williams@Motorola.com Expires: April 2003 Dimitrelis [Page 16]