[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/