tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2740

 
 
 

OSPF for IPv6

Part 2 of 3, p. 20 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
3.4.  Link State Advertisements

   For IPv6, the OSPF LSA header has changed slightly, with the LS type
   field expanding and the Options field being moved into the body of
   appropriate LSAs. Also, the formats of some LSAs have changed
   somewhat (namely router-LSAs, network-LSAs and AS-external-LSAs),
   while the names of other LSAs have been changed (type 3 and 4
   summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-

Top      Up      ToC       Page 21 
   LSAs respectively) and additional LSAs have been added (Link-LSAs and
   Intra-Area-Prefix-LSAs). Type of Service (TOS) has been removed from
   the OSPFv2 specification [Ref1], and is not encoded within OSPF for
   IPv6's LSAs.

   These changes will be described in detail in the following
   subsections.

3.4.1.  The LSA Header

   In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte
   LSA header. However, the contents of this 20 byte header have changed
   in IPv6. The LS age, Advertising Router, LS Sequence Number, LS
   checksum and length fields within the LSA header remain unchanged, as
   documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of
   [Ref1] respectively.  However, the following fields have changed for
   IPv6:

   Options
      The Options field has been removed from the standard 20 byte LSA
      header, and into the body of router-LSAs, network-LSAs, inter-
      area-router-LSAs and link-LSAs. The size of the Options field has
      increased from 8 to 24 bits, and some of the bit definitions have
      changed (see Section A.2). In addition a separate PrefixOptions
      field, 8 bits in length, is attached to each prefix advertised
      within the body of an LSA.

   LS type
      The size of the LS type field has increased from 8 to 16 bits,
      with the top two bits encoding flooding scope and the next bit
      encoding the handling of unknown LS types.  See Section A.4.2.1
      for the current coding of the LS type field.

   Link State ID
      Link State ID remains at 32 bits in length, but except for
      network-LSAs and link-LSAs, Link State ID has shed any addressing
      semantics. For example, an IPv6 router originating multiple AS-
      external-LSAs could start by assigning the first a Link State ID
      of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on.
      Instead of the IPv4 behavior of encoding the network number within
      the AS-external-LSA's Link State ID, the IPv6 Link State ID simply
      serves as a way to differentiate multiple LSAs originated by the
      same router.

      For network-LSAs, the Link State ID is set to the Designated
      Router's Interface ID on the link. When a router originates a
      Link-LSA for a given link, its Link State ID is set equal to the
      router's Interface ID on the link.

Top      Up      ToC       Page 22 
3.4.2.  The link-state database

   In IPv6, as in IPv4, individual LSAs are identified by a combination
   of their LS type, Link State ID and Advertising Router fields. Given
   two instances of an LSA, the most recent instance is determined by
   examining the LSAs' LS Sequence Number, using LS checksum and LS age
   as tiebreakers (see Section 13.1 of [Ref1]).

   In IPv6, the link-state database is split across three separate data
   structures. LSAs with AS flooding scope are contained within the
   top-level OSPF data structure (see Section 3.1) as long as either
   their LS type is known or their U-bit is 1 (flood even when
   unrecognized); this includes the AS-external-LSAs. LSAs with area
   flooding scope are contained within the appropriate area structure
   (see Section 3.1.1) as long as either their LS type is known or their
   U-bit is 1 (flood even when unrecognized); this includes router-LSAs,
   network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and
   intra-area-prefix-LSAs. LSAs with unknown LS type and U-bit set to 0
   and/or link-local flooding scope are contained within the appropriate
   interface structure (see Section 3.1.2); this includes link-LSAs.

   To lookup or install an LSA in the database, you first examine the LS
   type and the LSA's context (i.e., to which area or link does the LSA
   belong). This information allows you to find the correct list of
   LSAs, all of the same LS type, where you then search based on the
   LSA's Link State ID and Advertising Router.

3.4.3.  Originating LSAs

   The process of reoriginating an LSA in IPv6 is the same as in IPv4:
   the LSA's LS sequence number is incremented, its LS age is set to 0,
   its LS checksum is calculated, and the LSA is added to the link state
   database and flooded out the appropriate interfaces.

   To the list of events causing LSAs to be reoriginated, which for IPv4
   is given in Section 12.4 of [Ref1], the following events and/or
   actions are added for IPv6:

   o  The state of one of the router's interfaces changes. The router
      may need to (re)originate or flush its Link-LSA and one or more
      router-LSAs and/or intra-area-prefix-LSAs.

   o  The identity of a link's Designated Router changes. The router may
      need to (re)originate or flush the link's network-LSA and one or
      more router-LSAs and/or intra-area-prefix-LSAs.

Top      Up      ToC       Page 23 
   o  A neighbor transitions to/from "Full" state.  The router may need
      to (re)originate or flush the link's network-LSA and one or more
      router-LSAs and/or intra-area-prefix-LSAs.

   o  The Interface ID of a neighbor changes. This may cause a new
      instance of a router-LSA to be originated for the associated area,
      and the reorigination of one or more intra-area-prefix-LSAs.

   o  A new prefix is added to an attached link, or a prefix is deleted
      (both through configuration). This causes the router to
      reoriginate its link-LSA for the link, or, if it is the only
      router attached to the link, causes the router to reoriginate an
      intra-area-prefix-LSA.

   o  A new link-LSA is received, causing the link's collection of
      prefixes to change. If the router is Designated Router for the
      link, it originates a new intra-area-prefix-LSA.

   Detailed construction of the seven required IPv6 LSA types is
   supplied by the following subsections. In order to display example
   LSAs, the network map in Figure 15 of [Ref1] has been reworked to
   show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
   interface is has been displayed in Figure 1. The assignment of IPv6
   prefixes to network links is shown in Table 1. A single area address
   range has been configured for Area 1, so that outside of Area 1 all
   of its prefixes are covered by a single route to 5f00:0000:c001::/48.
   The OSPF interface IDs and the link-local addresses for the router
   interfaces in Figure 1 are given in Table 2.

Top      Up      ToC       Page 24 
       ..........................................
       .                                  Area 1.
       .     +                                  .
       .     |                                  .
       .     | 3+---+1                          .
       .  N1 |--|RT1|-----+                     .
       .     |  +---+      \                    .
       .     |              \  ______           .
       .     +               \/       \      1+---+
       .                     *    N3   *------|RT4|------
       .     +               /\_______/       +---+
       .     |              /     |             .
       .     | 3+---+1     /      |             .
       .  N2 |--|RT2|-----+      1|             .
       .     |  +---+           +---+           .
       .     |                  |RT3|----------------
       .     +                  +---+           .
       .                          |2            .
       .                          |             .
       .                   +------------+       .
       .                          N4            .
       ..........................................

       Figure 1: Area 1 with IP addresses shown


              Network   IPv6 prefix
              -----------------------------------
              N1        5f00:0000:c001:0200::/56
              N2        5f00:0000:c001:0300::/56
              N3        5f00:0000:c001:0100::/56
              N4        5f00:0000:c001:0400::/56

       Table 1: IPv6 link prefixes for sample network


            Router   interface   Interface ID   link-local address
            -------------------------------------------------------
            RT1      to N1       1              fe80:0001::RT1
                     to N3       2              fe80:0002::RT1
            RT2      to N2       1              fe80:0001::RT2
                     to N3       2              fe80:0002::RT2
            RT3      to N3       1              fe80:0001::RT3
                     to N4       2              fe80:0002::RT3
            RT4      to N3       1              fe80:0001::RT4

       Table 2: OSPF Interface IDs and link-local addresses

Top      Up      ToC       Page 25 
3.4.3.1.  Router-LSAs

   The LS type of a router-LSA is set to the value 0x2001.  Router-LSAs
   have area flooding scope. A router may originate one or more router-
   LSAs for a given area. Each router-LSA contains an integral number of
   interface descriptions; taken together, the collection of router-LSAs
   originated by the router for an area describes the collected states
   of all the router's interfaces to the area. When multiple router-LSAs
   are used, they are distinguished by their Link State ID fields.

   The Options field in the router-LSA should be coded as follows. The
   V6-bit should be set. The E-bit should be clear if and only if the
   attached area is an OSPF stub area. The MC-bit should be set if and
   only if the router is running MOSPF (see [Ref8]). The N-bit should be
   set if and only if the attached area is an OSPF NSSA area.  The R-bit
   should be set. The DC-bit should be set if and only if the router can
   correctly process the DoNotAge bit when it appears in the LS age
   field of LSAs (see [Ref11]). All unrecognized bits in the Options
   field should be cleared

   To the left of the Options field, the router capability bits V, E and
   B should be coded according to Section 12.4.1 of [Ref1]. Bit W should
   be coded according to [Ref8].

   Each of the router's interfaces to the area are then described by
   appending "link descriptions" to the router-LSA. Each link
   description is 16 bytes long, consisting of 5 fields: (link) Type,
   Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID
   (see Section A.4.3). Interfaces in state "Down" or "Loopback" are not
   described (although looped back interfaces can contribute prefixes to
   Intra-Area-Prefix-LSAs). Nor are interfaces without any full
   adjacencies described. All other interfaces to the area add zero, one
   or more link descriptions, the number and content of which depend on
   the interface type. Within each link description, the Metric field is
   always set the interface's output cost and the Interface ID field is
   set to the interface's OSPF Interface ID.

   Point-to-point interfaces
      If the neighboring router is fully adjacent, add a Type 1 link
      description (point-to-point). The Neighbor Interface ID field is
      set to the Interface ID advertised by the neighbor in its Hello
      packets, and the Neighbor Router ID field is set to the neighbor's
      Router ID.

Top      Up      ToC       Page 26 
   Broadcast and NBMA interfaces
      If the router is fully adjacent to the link's Designated Router,
      or if the router itself is Designated Router and is fully adjacent
      to at least one other router, add a single Type 2 link description
      (transit network). The Neighbor Interface ID field is set to the
      Interface ID advertised by the Designated Router in its Hello
      packets, and the Neighbor Router ID field is set to the Designated
      Router's Router ID.

   Virtual links
      If the neighboring router is fully adjacent, add a Type 4 link
      description (virtual). The Neighbor Interface ID field is set to
      the Interface ID advertised by the neighbor in its Hello packets,
      and the Neighbor Router ID field is set to the neighbor's Router
      ID. Note that the output cost of a virtual link is calculated
      during the routing table calculation (see Section 3.7).

   Point-to-MultiPoint interfaces
      For each fully adjacent neighbor associated with the interface,
      add a separate Type 1 link description (point-to-point) with
      Neighbor Interface ID field set to the Interface ID advertised by
      the neighbor in its Hello packets, and Neighbor Router ID field
      set to the neighbor's Router ID.

   As an example, consider the router-LSA that router RT3 would
   originate for Area 1 in Figure 1. Only a single interface must be
   described, namely that which connects to the transit network N3. It
   assumes that RT4 has been elected Designated Router of Network N3.

     ; RT3's router-LSA for Area 1

     LS age = 0                     ;newly (re)originated
     LS type = 0x2001               ;router-LSA
     Link State ID = 0              ;first fragment
     Advertising Router = 192.1.1.3 ;RT3's Router ID
     bit E = 0                      ;not an AS boundary router
     bit B = 1                      ;area border router
     Options = (V6-bit|E-bit|R-bit)
         Type = 2                     ;connects to N3
         Metric = 1            ;cost to N3
         Interface ID = 1             ;RT3's Interface ID on N3
         Neighbor Interface ID = 1    ;RT4's Interface ID on N3
         Neighbor Router ID = 192.1.1.4 ; RT4's Router ID

   If for example another router was added to Network N4, RT3 would have
   to advertise a second link description for its connection to (the now
   transit) network N4. This could be accomplished by reoriginating the
   above router-LSA, this time with two link descriptions. Or, a

Top      Up      ToC       Page 27 
   separate router-LSA could be originated with a separate Link State ID
   (e.g., using a Link State ID of 1) to describe the connection to N4.

   Host routes no longer appear in the router-LSA, but are instead
   included in intra-area-prefix-LSAs.

3.4.3.2.  Network-LSAs

   The LS type of a network-LSA is set to the value 0x2002.  Network-
   LSAs have area flooding scope. A network-LSA is originated for every
   broadcast or NBMA link having two or more attached routers, by the
   link's Designated Router. The network-LSA lists all routers attached
   to the link.

   The procedure for originating network-LSAs in IPv6 is the same as the
   IPv4 procedure documented in Section 12.4.2 of [Ref1], with the
   following exceptions:

   o  An IPv6 network-LSA's Link State ID is set to the Interface ID of
      the Designated Router on the link.

   o  IPv6 network-LSAs do not contain a Network Mask. All addressing
      information formerly contained in the IPv4 network-LSA has now
      been consigned to intra-Area-Prefix-LSAs.

   o  The Options field in the network-LSA is set to the logical OR of
      the Options fields contained within the link's associated link-
      LSAs.  In this way, the network link exhibits a capability when at
      least one of the link's routers requests that the capability be
      asserted.

   As an example, assuming that Router RT4 has been elected Designated
   Router of Network N3 in Figure 1, the following network-LSA is
   originated:

     ; Network-LSA for Network N3

     LS age = 0                     ;newly (re)originated
     LS type = 0x2002               ;network-LSA
     Link State ID = 1              ;RT4's Interface ID on N3
     Advertising Router = 192.1.1.4 ;RT4's Router ID
     Options = (V6-bit|E-bit|R-bit)
            Attached Router = 192.1.1.4    ;Router ID
            Attached Router = 192.1.1.1    ;Router ID
            Attached Router = 192.1.1.2    ;Router ID
            Attached Router = 192.1.1.3    ;Router ID

Top      Up      ToC       Page 28 
3.4.3.3.  Inter-Area-Prefix-LSAs

   The LS type of an inter-area-prefix-LSA is set to the value 0x2003.
   Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter-
   area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area-
   prefix-LSA describes a prefix external to the area, yet internal to
   the Autonomous System.

   The procedure for originating inter-area-prefix-LSAs in IPv6 is the
   same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1
   of [Ref1], with the following exceptions:

   o  The Link State ID of an inter-area-prefix-LSA has lost all of its
      addressing semantics, and instead simply serves to distinguish
      multiple inter-area-prefix-LSAs that are originated by the same
      router.

   o  The prefix is described by the PrefixLength, PrefixOptions and
      Address Prefix fields embedded within the LSA body. Network Mask
      is no longer specified.

   o  The NU-bit in the PrefixOptions field should be clear. The coding
      of the MC-bit depends upon whether, and if so how, MOSPF is
      operating in the routing domain (see [Ref8]).

   o  Link-local addresses must never be advertised in inter-area-
      prefix-LSAs.

      As an example, the following shows the inter-area-prefix-LSA that
      Router RT4 originates into the OSPF backbone area, condensing all
      of Area 1's prefixes into the single prefix 5f00:0000:c001::/48.
      The cost is set to 4, which is the maximum cost to all of the
      prefix' individual components. The prefix is padded out to an even
      number of 32-bit words, so that it consumes 64-bits of space
      instead of 48 bits.

        ; Inter-area-prefix-LSA for Area 1 addresses
        ; originated by Router RT4 into the backbone

        LS age = 0                  ;newly (re)originated
        LS type = 0x2003            ;inter-area-prefix-LSA
        Advertising Router = 192.1.1.4       ;RT4's ID
        Metric = 4                  ;maximum to components
        PrefixLength = 48
        PrefixOptions = 0
        Address Prefix = 5f00:0000:c001 ;padded to 64-bits

Top      Up      ToC       Page 29 
3.4.3.4.  Inter-Area-Router-LSAs

      The LS type of an inter-area-router-LSA is set to the value
      0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4,
      inter-area-router-LSAs were called type 4 summary-LSAs. Each
      inter-area-router-LSA describes a path to a destination OSPF
      router (an ASBR) that is external to the area, yet internal to the
      Autonomous System.

      The procedure for originating inter-area-router-LSAs in IPv6 is
      the same as the IPv4 procedure documented in Section 12.4.3 of
      [Ref1], with the following exceptions:

   o  The Link State ID of an inter-area-router-LSA is no longer the
      destination router's OSPF Router ID, but instead simply serves to
      distinguish multiple inter-area-router-LSAs that are originated by
      the same router. The destination router's Router ID is now found
      in the body of the LSA.

   o  The Options field in an inter-area-router-LSA should be set equal
      to the Options field contained in the destination router's own
      router-LSA. The Options field thus describes the capabilities
      supported by the destination router.

   As an example, consider the OSPF Autonomous System depicted in Figure
   6 of [Ref1]. Router RT4 would originate into Area 1 the following
   inter-area-router-LSA for destination router RT7.

     ; inter-area-router-LSA for AS boundary router RT7
     ; originated by Router RT4 into Area 1

     LS age = 0                  ;newly (re)originated
     LS type = 0x2004            ;inter-area-router-LSA
     Advertising Router = 192.1.1.4  ;RT4's ID
     Options = (V6-bit|E-bit|R-bit)  ;RT7's capabilities
     Metric = 14                     ;cost to RT7
     Destination Router ID = Router RT7's ID

3.4.3.5.  AS-external-LSAs

   The LS type of an AS-external-LSA is set to the value 0x4005. AS-
   external-LSAs have AS flooding scope. Each AS-external-LSA describes
   a path to a prefix external to the Autonomous System.

   The procedure for originating AS-external-LSAs in IPv6 is the same as
   the IPv4 procedure documented in Section 12.4.4 of [Ref1], with the
   following exceptions:

Top      Up      ToC       Page 30 
   o  The Link State ID of an AS-external-LSA has lost all of its
      addressing semantics, and instead simply serves to distinguish
      multiple AS-external-LSAs that are originated by the same router.

   o  The prefix is described by the PrefixLength, PrefixOptions and
      Address Prefix fields embedded within the LSA body. Network Mask
      is no longer specified.

   o  The NU-bit in the PrefixOptions field should be clear. The coding
      of the MC-bit depends upon whether, and if so how, MOSPF is
      operating in the routing domain (see [Ref8]).

   o  Link-local addresses can never be advertised in AS-external-LSAs.

   o  The forwarding address is present in the AS-external-LSA if and
      only if the AS-external-LSA's bit F is set.

   o  The external route tag is present in the AS-external-LSA if and
      only if the AS-external-LSA's bit T is set.

   o  The capability for an AS-external-LSA to reference another LSA has
      been included, by inclusion of the Referenced LS Type field and
      the optional Referenced Link State ID field (the latter present if
      and only if Referenced LS Type is non-zero). This capability is
      for future use; for now Referenced LS Type should be set to 0 and
      received non-zero values for this field should be ignored.

   As an example, consider the OSPF Autonomous System depicted in Figure
   6 of [Ref1]. Assume that RT7 has learned its route to N12 via BGP,
   and that it wishes to advertise a Type 2 metric into the AS.  Further
   assume the the IPv6 prefix for N12 is the value 5f00:0000:0a00::/40.
   RT7 would then originate the following AS-external-LSA for the
   external network N12.  Note that within the AS-external-LSA, N12's
   prefix occupies 64 bits of space, to maintain 32-bit alignment.

     ; AS-external-LSA for Network N12,
     ; originated by Router RT7

     LS age = 0                  ;newly (re)originated
     LS type = 0x4005            ;AS-external-LSA
     Link State ID = 123         ;or something else
     Advertising Router = Router RT7's ID
     bit E = 1                   ;Type 2 metric
     bit F = 0                   ;no forwarding address
     bit T = 1                   ;external route tag included
     Metric = 2
     PrefixLength = 40
     PrefixOptions = 0

Top      Up      ToC       Page 31 
     Referenced LS Type = 0      ;no Referenced Link State ID
     Address Prefix = 5f00:0000:0a00 ;padded to 64-bits
     External Route Tag = as per BGP/OSPF interaction

3.4.3.6.  Link-LSAs

   The LS type of a Link-LSA is set to the value 0x0008.  Link-LSAs have
   link-local flooding scope. A router originates a separate Link-LSA
   for each attached link that supports 2 or more (including the
   originating router itself) routers.

   Link-LSAs have three purposes: 1) they provide the router's link-
   local address to all other routers attached to the link and 2) they
   inform other routers attached to the link of a list of IPv6 prefixes
   to associate with the link and 3) they allow the router to assert a
   collection of Options bits in the Network-LSA that will be originated
   for the link.

   A Link-LSA for a given Link L is built in the following fashion:

   o  The Link State ID is set to the router's Interface ID on Link L.

   o  The Router Priority of the router's interface to Link L is
      inserted into the Link-LSA.

   o  The Link-LSA's Options field is set to those bits that the router
      wishes set in Link L's Network LSA.

   o  The router inserts its link-local address on Link L into the
      Link-LSA. This information will be used when the other routers on
      Link L do their next hop calculations (see Section 3.8.1.1).

   o  Each IPv6 address prefix that has been configured into the router
      for Link L is added to the Link-LSA, by specifying values for
      PrefixLength, PrefixOptions, and Address Prefix fields.

   After building a Link-LSA for a given link, the router installs the
   link-LSA into the associate interface data structure and floods the
   Link-LSA onto the link. All other routers on the link will receive
   the Link-LSA, but it will go no further.

   As an example, consider the Link-LSA that RT3 will build for N3 in
   Figure 1. Suppose that the prefix 5f00:0000:c001:0100::/56 has been
   configured within RT3 for N3. This will give rise to the following
   Link-LSA, which RT3 will flood onto N3, but nowhere else. Note that
   not all routers on N3 need be configured with the prefix; those not
   configured will learn the prefix when receiving RT3's Link-LSA.

Top      Up      ToC       Page 32 
     ; RT3's Link-LSA for N3

     LS age = 0                  ;newly (re)originated
     LS type = 0x0008            ;Link-LSA
     Link State ID = 1           ;RT3's Interface ID on N3
     Advertising Router = 192.1.1.3 ;RT3's Router ID
     Rtr Pri = 1                 ;RT3's N3 Router Priority
     Options = (V6-bit|E-bit|R-bit)
     Link-local Interface Address = fe80:0001::RT3
     # prefixes = 1
     PrefixLength = 56
     PrefixOptions = 0
     Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits

3.4.3.7.  Intra-Area-Prefix-LSAs

   The LS type of an intra-area-prefix-LSA is set to the value 0x2009.
   Intra-area-prefix-LSAs have area flooding scope. An intra-area-
   prefix-LSA has one of two functions. It associates a list of IPv6
   address prefixes with a transit network link by referencing a
   network- LSA, or associates a list of IPv6 address prefixes with a
   router by referencing a router-LSA. A stub link's prefixes are
   associated with its attached router.

   A router may originate multiple intra-area-prefix-LSAs for a given
   area, distinguished by their Link State ID fields. Each intra-area-
   prefix-LSA contains an integral number of prefix descriptions.

   A link's Designated Router originates one or more intra-area-prefix-
   LSAs to advertise the link's prefixes throughout the area. For a link
   L, L's Designated Router builds an intra-area-prefix-LSA in the
   following fashion:

   o  In order to indicate that the prefixes are to be associated with
      the Link L, the fields Referenced LS type, Referenced Link State
      ID, and Referenced

      Advertising Router are set to the corresponding fields in Link L's
      network-LSA (namely LS type, Link State ID, and Advertising Router
      respectively). This means that Referenced LS Type is set to
      0x2002, Referenced Link State ID is set to the Designated Router's
      Interface ID on Link L, and Referenced Advertising Router is set
      to the Designated Router's Router ID.

   o  Each Link-LSA associated with Link L is examined (these are in the
      Designated Router's interface structure for Link L). If the Link-
      LSA's Advertising Router is fully adjacent to the Designated
      Router, the list of prefixes in the Link-LSA is copied into the

Top      Up      ToC       Page 33 
      intra-area-prefix-LSA that is being built.  Prefixes having the
      NU-bit and/or LA-bit set in their Options field should not be
      copied, nor should link-local addresses be copied.  Each prefix is
      described by the PrefixLength, PrefixOptions, and Address Prefix
      fields. Multiple prefixes having the same PrefixLength and Address
      Prefix are considered to be duplicates; in this case their Prefix
      Options fields should be merged by logically OR'ing the fields
      together, and a single resulting prefix should be copied into the
      intra-area-prefix-LSA. The Metric field for all prefixes is set to
      0.

   o  The "# prefixes" field is set to the number of prefixes that the
      router has copied into the LSA. If necessary, the list of prefixes
      can be spread across multiple intra-area-prefix-LSAs in order to
      keep the LSA size small.

      A router builds an intra-area-prefix-LSA to advertise its own
      prefixes, and those of its attached stub links.  A Router RTX
      would build its intra-area-prefix-LSA in the following fashion:

   o  In order to indicate that the prefixes are to be associated with
      the Router RTX itself, RTX sets Referenced LS type to 0x2001,
      Referenced Link State ID to 0, and Referenced Advertising Router
      to RTX's own Router ID.

   o  Router RTX examines its list of interfaces to the area. If the
      interface is in state Down, its prefixes are not included. If the
      interface has been reported in RTX's router-LSA as a Type 2 link
      description (link to transit network), its prefixes are not
      included (they will be included in the intra-area-prefix-LSA for
      the link instead). If the interface type is Point-to-MultiPoint,
      or the interface is in state Loopback, or the interface connects
      to a point-to-point link which has not been assigned a prefix,
      then the site-local and global scope IPv6 addresses associated
      with the interface (if any) are copied into the intra-area-
      prefix-LSA, setting the LA-bit in the PrefixOptions field, and
      setting the PrefixLength to 128 and the Metric to 0.  Otherwise,
      the list of site-local and global prefixes configured in RTX for
      the link are copied into the intra-area-prefix-LSA by specifying
      the PrefixLength, PrefixOptions, and Address Prefix fields. The
      Metric field for each of these prefixes is set to the interface's
      output cost.

   o  RTX adds the IPv6 prefixes for any directly attached hosts
      belonging to the area (see Section C.7) to the intra-area-prefix-
      LSA.

Top      Up      ToC       Page 34 
   o  If RTX has one or more virtual links configured through the area,
      it includes one of its site-local or global scope IPv6 interface
      addresses in the LSA (if it hasn't already), setting the LA-bit in
      the PrefixOptions field, and setting the PrefixLength to 128 and
      the Metric to 0. This information will be used later in the
      routing calculation so that the two ends of the virtual link can
      discover each other's IPv6 addresses.

   o  The "# prefixes" field is set to the number of prefixes that the
      router has copied into the LSA. If necessary, the list of prefixes
      can be spread across multiple intra-area-prefix-LSAs in order to
      keep the LSA size small.

   For example, the intra-area-prefix-LSA originated by RT4 for Network
   N3 (assuming that RT4 is N3's Designated Router), and the intra-
   area-prefix-LSA originated into Area 1 by Router RT3 for its own
   prefixes, are pictured below.

     ; Intra-area-prefix-LSA
     ; for network link N3

     LS age = 0                  ;newly (re)originated
     LS type = 0x2009            ;Intra-area-prefix-LSA
     Link State ID = 5           ;or something
     Advertising Router = 192.1.1.4 ;RT4's Router ID
     # prefixes = 1
     Referenced LS type = 0x2002 ;network-LSA reference
     Referenced Link State ID = 1
     Referenced Advertising Router = 192.1.1.4
     PrefixLength = 56           ;N3's prefix
     PrefixOptions = 0
     Metric = 0
     Address Prefix = 5f00:0000:c001:0100 ;pad

     ; RT3's Intra-area-prefix-LSA
     ; for its own prefixes

     LS age = 0                  ;newly (re)originated
     LS type = 0x2009            ;Intra-area-prefix-LSA
     Link State ID = 177         ;or something
     Advertising Router = 192.1.1.3 ;RT3's Router ID
     # prefixes = 1
     Referenced LS type = 0x2001 ;router-LSA reference
     Referenced Link State ID = 0
     Referenced Advertising Router = 192.1.1.3
     PrefixLength = 56           ;N4's prefix

Top      Up      ToC       Page 35 
     PrefixOptions = 0
     Metric = 2                  ;N4 interface cost
     Address Prefix = 5f00:0000:c001:0400 ;pad

   When network conditions change, it may be necessary for a router to
   move prefixes from one intra-area-prefix-LSA to another. For example,
   if the router is Designated Router for a link but the link has no
   other attached routers, the link's prefixes are advertised in an
   intra-area-prefix-LSA referring to the Designated Router's router-
   LSA.  When additional routers appear on the link, a network-LSA is
   originated for the link and the link's prefixes are moved to an
   intra-area-prefix-LSA referring to the network-LSA.

   Note that in the intra-area-prefix-LSA, the "Referenced Advertising
   Router" is always equal to the router that is originating the intra-
   area-prefix-LSA (i.e., the LSA's Advertising Router). The reason that
   the Referenced Advertising Router field appears is that, even though
   it is currently redundant, it may not be in the future. We may
   sometime want to use the same LSA format to advertise address
   prefixes for other protocol suites. In that event, the Designated
   Router may not be running the other protocol suite, and so another of
   the link's routers may need to send out the prefix-LSA. In that case,
   "Referenced Advertising Router" and "Advertising Router" would be
   different.

3.5.  Flooding

   Most of the flooding algorithm remains unchanged from the IPv4
   flooding mechanisms described in Section 13 of [Ref1]. In particular,
   the processes for determining which LSA instance is newer (Section
   13.1 of [Ref1]), responding to updates of self-originated LSAs
   (Section 13.4 of [Ref1]), sending Link State Acknowledgment packets
   (Section 13.5 of [Ref1]), retransmitting LSAs (Section 13.6 of
   [Ref1]) and receiving Link State Acknowledgment packets (Section 13.7
   of [Ref1]) are exactly the same for IPv6 and IPv4.

   However, the addition of flooding scope and handling options for
   unrecognized LSA types (see Section A.4.2.1) has caused some changes
   in the OSPF flooding algorithm: the reception of Link State Updates
   (Section 13 in [Ref1]) and the sending of Link State Updates (Section
   13.3 of [Ref1]) must take into account the LSA's scope and U-bit
   setting. Also, installation of LSAs into the OSPF database (Section
   13.2 of [Ref1]) causes different events in IPv6, due to the
   reorganization of LSA types and contents in IPv6. These changes are
   described in detail below.

Top      Up      ToC       Page 36 
3.5.1.  Receiving Link State Update packets

   The encoding of flooding scope in the LS type and the need to process
   unknown LS types causes modifications to the processing of received
   Link State Update packets. As in IPv4, each LSA in a received Link
   State Update packet is examined. In IPv4, eight steps are executed
   for each LSA, as described in Section 13 of [Ref1]. For IPv6, all the
   steps are the same, except that Steps 2 and 3 are modified as
   follows:

   (2)   Examine the LSA's LS type.  If the LS type is
         unknown, the area has been configured as a stub area,
         and either the LSA's flooding scope is set to "AS
         flooding scope" or the U-bit of the LS type is set to
         1 (flood even when unrecognized), then discard the
         LSA and get the next one from the Link State Update
         Packet. This generalizes the IPv4 behavior where AS-
         external-LSAs are not flooded into/throughout stub
         areas.

   (3)   Else if the flooding scope of the LSA is set to
         "reserved", discard the LSA and get the next one from
         the Link State Update Packet.

   Steps 5b (sending Link State Update packets) and 5d (installing LSAs
   in the link state database) in Section 13 of [Ref1] are also somewhat
   different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.

3.5.2.  Sending Link State Update packets

   The sending of Link State Update packets is described in Section 13.3
   of [Ref1]. For IPv4 and IPv6, the steps for sending a Link State
   Update packet are the same (steps 1 through 5 of Section 13.3 in
   [Ref1]). However, the list of eligible interfaces out which to flood
   the LSA is different.  For IPv6, the eligible interfaces are selected
   based on the following factors:

   o  The LSA's flooding scope.

   o  For LSAs with area or link-local flooding scoping, the particular
      area or interface that the LSA is associated with.

   o  Whether the LSA has a recognized LS type.

   o  The setting of the U-bit in the LS type. If the U-bit is set to 0,
      unrecognized LS types are treated as having link-local scope. If
      set to 1, unrecognized LS types are stored and flooded as if they
      were recognized.

Top      Up      ToC       Page 37 
   Choosing the set of eligible interfaces then breaks into the
   following cases:

   Case 1
      The LSA's LS type is recognized. In this case, the set of eligible
      interfaces is set depending on the flooding scope encoded in the
      LS type. If the flooding scope is "AS flooding scope", the
      eligible interfaces are all router interfaces excepting virtual
      links. In addition, AS-external-LSAs are not flooded out
      interfaces connecting to stub areas. If the flooding scope is
      "area flooding scope", the set of eligible interfaces are those
      interfaces connecting to the LSA's associated area. If the
      flooding scope is "link-local flooding scope", then there is a
      single eligible interface, the one connecting to the LSA's
      associated link (which, when the LSA is received in a Link State
      Update packet, is also the interface the LSA was received on).

   Case 2
      The LS type is unrecognized, and the U-bit in the LS Type is set
      to 0 (treat the LSA as if it had link-local flooding scope). In
      this case there is a single eligible interface, namely, the
      interface on which the LSA was received.

   Case 3
      The LS type is unrecognized, and the U-bit in the LS Type is set
      to 1 (store and flood the LSA, as if type understood). In this
      case, select the eligible interfaces based on the encoded flooding
      scope as in Case 1 above. However, in this case interfaces
      attached to stub areas are always excluded.

   A further decision must sometimes be made before adding an LSA to a
   given neighbor's link-state retransmission list (Step 1d in Section
   13.3 of [Ref1]). If the LS type is recognized by the router, but not
   by the neighbor (as can be determined by examining the Options field
   that the neighbor advertised in its Database Description packet) and
   the LSA's U-bit is set to 0, then the LSA should be added to the
   neighbor's link-state retransmission list if and only if that
   neighbor is the Designated Router or Backup Designated Router for the
   attached link. The LS types described in detail by this memo, namely
   router-LSAs (LS type 0x2001), network-LSAs (0x2002), Inter-Area-
   Prefix-LSAs (0x2003), Inter-Area-Router-LSAs (0x2004), AS-External-
   LSAs (0x4005), Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009)
   are assumed to be understood by all routers. However, as an example
   the group-membership-LSA (0x2006) is understood only by MOSPF routers
   and since it has its U-bit set to 0, it should only be forwarded to a
   non-MOSPF neighbor (determined by examining the MC-bit in the
   neighbor's Database Description packets' Options field) when the
   neighbor is Designated Router or Backup Designated Router for the

Top      Up      ToC       Page 38 
   attached link.

   The previous paragraph solves a problem in IPv4 OSPF extensions such
   as MOSPF, which require that the Designated Router support the
   extension in order to have the new LSA types flooded across broadcast
   and NBMA networks (see Section 10.2 of [Ref8]).

3.5.3.  Installing LSAs in the database

   There are three separate places to store LSAs, depending on their
   flooding scope. LSAs with AS flooding scope are stored in the global
   OSPF data structure (see Section 3.1) as long as their LS type is
   known or their U-bit is 1. LSAs with area flooding scope are stored
   in the appropriate area data structure (see Section 3.1.1) as long as
   their LS type is known or their U-bit is 1. LSAs with link-local
   flooding scope, and those LSAs with unknown LS type and U-bit set to
   0 (treat the LSA as if it had link-local flooding scope) are stored
   in the appropriate interface structure.

   When storing the LSA into the link-state database, a check must be
   made to see whether the LSA's contents have changed.  Changes in
   contents are indicated exactly as in Section 13.2 of [Ref1]. When an
   LSA's contents have been changed, the following parts of the routing
   table must be recalculated, based on the LSA's LS type:

   Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs and Link-LSAs
      The entire routing table is recalculated, starting with the
      shortest path calculation for each area (see Section 3.8).

   Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
      The best route to the destination described by the LSA must be
      recalculated (see Section 16.5 in [Ref1]).  If this destination is
      an AS boundary router, it may also be necessary to re-examine all
      the AS-external-LSAs.

   AS-external-LSAs
      The best route to the destination described by the AS-external-LSA
      must be recalculated (see Section 16.6 in [Ref1]).

   As in IPv4, any old instance of the LSA must be removed from the
   database when the new LSA is installed.  This old instance must also
   be removed from all neighbors' Link state retransmission lists.

Top      Up      ToC       Page 39 
3.6.  Definition of self-originated LSAs

   In IPv6 the definition of a self-originated LSA has been simplified
   from the IPv4 definition appearing in Sections 13.4 and 14.1 of
   [Ref1]. For IPv6, self-originated LSAs are those LSAs whose
   Advertising Router is equal to the router's own Router ID.

3.7.  Virtual links

   OSPF virtual links for IPv4 are described in Section 15 of [Ref1].
   Virtual links are the same in IPv6, with the following exceptions:

   o  LSAs having AS flooding scope are never flooded over virtual
      adjacencies, nor are LSAs with AS flooding scope summarized over
      virtual adjacencies during the Database Exchange process. This is
      a generalization of the IPv4 treatment of AS-external-LSAs.

   o  The IPv6 interface address of a virtual link must be an IPv6
      address having site-local or global scope, instead of the link-
      local addresses used by other interface types. This address is
      used as the IPv6 source for OSPF protocol packets sent over the
      virtual link.

   o  Likewise, the virtual neighbor's IPv6 address is an IPv6 address
      with site-local or global scope. To enable the discovery of a
      virtual neighbor's IPv6 address during the routing calculation,
      the neighbor advertises its virtual link's IPv6 interface address
      in an Intra-Area-Prefix-LSA originated for the virtual link's
      transit area (see Sections 3.4.3.7 and 3.8.1).

   o  Like all other IPv6 OSPF interfaces, virtual links are assigned
      unique (within the router) Interface IDs. These are advertised in
      Hellos sent over the virtual link, and in the router's router-
      LSAs.

3.8.  Routing table calculation

   The IPv6 OSPF routing calculation proceeds along the same lines as
   the IPv4 OSPF routing calculation, following the five steps specified
   by Section 16 of [Ref1]. High level differences between the IPv6 and
   IPv4 calculations include:

   o  Prefix information has been removed from router-LSAs, and now is
      advertised in intra-area-prefix-LSAs. Whenever [Ref1] specifies
      that stub networks within router-LSAs be examined, IPv6 will
      instead examine prefixes within intra-area-prefix-LSAs.

Top      Up      ToC       Page 40 
   o  Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
      and inter-area-router-LSAs (respectively).

   o  Addressing information is no longer encoded in Link State IDs, and
      must instead be found within the body of LSAs.

   o  In IPv6, a router can originate multiple router-LSAs within a
      single area, distinguished by Link State ID. These router-LSAs
      must be treated as a single aggregate by the area's shortest path
      calculation (see Section 3.8.1).

   For each area, routing table entries have been created for the area's
   routers and transit links, in order to store the results of the
   area's shortest-path tree calculation (see Section 3.8.1). These
   entries are then used when processing intra-area-prefix-LSAs, inter-
   area-prefix-LSAs and inter-area-router-LSAs, as described in Section
   3.8.2.

   Events generated as a result of routing table changes (Section 16.7
   of [Ref1]), and the equal-cost multipath logic (Section 16.8 of
   [Ref1]) are identical for both IPv4 and IPv6.

3.8.1.  Calculating the shortest path tree for an area

   The IPv4 shortest path calculation is contained in Section 16.1 of
   [Ref1].  The graph used by the shortest-path tree calculation is
   identical for both IPv4 and IPv6. The graph's vertices are routers
   and transit links, represented by router-LSAs and network-LSAs
   respectively. A router is identified by its OSPF Router ID, while a
   transit link is identified by its Designated Router's Interface ID
   and OSPF Router ID. Both routers and transit links have associated
   routing table entries within the area (see Section 3.3).

   Section 16.1 of [Ref1] splits up the shortest path calculations into
   two stages. First the Dijkstra calculation is performed, and then the
   stub links are added onto the tree as leaves. The IPv6 calculation
   maintains this split.

   The Dijkstra calculation for IPv6 is identical to that specified for
   IPv4, with the following exceptions (referencing the steps from the
   Dijkstra calculation as described in Section 16.1 of [Ref1]):

   o  The Vertex ID for a router is the OSPF Router ID. The Vertex ID
      for a transit network is a combination of the Interface ID and
      OSPF Router ID of the network's Designated Router.

Top      Up      ToC       Page 41 
   o  In Step 2, when a router Vertex V has just been added to the
      shortest path tree, there may be multiple LSAs associated with the
      router. All Router-LSAs with Advertising Router set to V's OSPF
      Router ID must processed as an aggregate, treating them as
      fragments of a single large router-LSA. The Options field and the
      router type bits (bits W, V, E and B) should always be taken from
      "fragment" with the smallest Link State ID.

   o  Step 2a is not needed in IPv6, as there are no longer stub network
      links in router-LSAs.

   o  In Step 2b, if W is a router, there may again be multiple LSAs
      associated with the router. All Router-LSAs with Advertising
      Router set to W's OSPF Router ID must processed as an aggregate,
      treating them as fragments of a single large router-LSA.

   o  In Step 4, there are now per-area routing table entries for each
      of an area's routers, instead of just the area border routers.
      These entries subsume all the functionality of IPv4's area border
      router routing table entries, including the maintenance of virtual
      links.  When the router added to the area routing table in this
      step is the other end of a virtual link, the virtual neighbor's IP
      address is set as follows: The collection of intra-area-prefix-
      LSAs originated by the virtual neighbor is examined, with the
      virtual neighbor's IP address being set to the first prefix
      encountered having the "LA-bit" set.

   o  Routing table entries for transit networks, which are no longer
      associated with IP networks, are also modified in Step 4.

   The next stage of the shortest path calculation proceeds similarly to
   the two steps of the second stage of Section 16.1 in [Ref1]. However,
   instead of examining the stub links within router-LSAs, the list of
   the area's intra-area-prefix-LSAs is examined. A prefix advertisement
   whose "NU-bit" is set should not be included in the routing
   calculation. The cost of any advertised prefix is the sum of the
   prefix' advertised metric plus the cost to the transit vertex (either
   router or transit network) identified by intra-area-prefix-LSA's
   Referenced LS type, Referenced Link State ID and Referenced
   Advertising Router fields. This latter cost is stored in the transit
   vertex' routing table entry for the area.

3.8.1.1.  The next hop calculation

   In IPv6, the calculation of the next hop's IPv6 address (which will
   be a link-local address) proceeds along the same lines as the IPv4
   next hop calculation (see Section 16.1.1 of [Ref1]). The only
   difference is in calculating the next hop IPv6 address for a router

Top      Up      ToC       Page 42 
   (call it Router X) which shares a link with the calculating router.
   In this case the calculating router assigns the next hop IPv6 address
   to be the link-local interface address contained in Router X's Link-
   LSA (see Section A.4.8) for the link. This procedure is necessary
   since on some links, such as NBMA links, the two routers need not be
   neighbors, and therefore might not be exchanging OSPF Hellos.

3.8.2.  Calculating the inter-area routes

   Calculation of inter-area routes for IPv6 proceeds along the same
   lines as the IPv4 calculation in Section 16.2 of [Ref1], with the
   following modifications:

   o  The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have
      been changed to inter-area-prefix-LSAs and inter-area-router-LSAs
      respectively.

   o  The Link State ID of the above LSA types no longer encodes the
      network or router described by the LSA.  Instead, an address
      prefix is contained in the body of an inter-area-prefix-LSA, and a
      described router's OSPF Router ID is carried in the body of an
      inter-area- router-LSA.

   o  Prefixes having the "NU-bit" set in their Prefix Options field
      should be ignored by the inter-area route calculation.

   When a single inter-area-prefix-LSA or inter-area-router-LSA has
   changed, the incremental calculations outlined in Section 16.5 of
   [Ref1] can be performed instead of recalculating the entire routing
   table.

3.8.3.  Examining transit areas' summary-LSAs

   Examination of transit areas' summary-LSAs in IPv6 proceeds along the
   same lines as the IPv4 calculation in Section 16.3 of [Ref1],
   modified in the same way as the IPv6 inter-area route calculation in
   Section 3.8.2.

3.8.4.  Calculating AS external routes

   The IPv6 AS external route calculation proceeds along the same lines
   as the IPv4 calculation in Section 16.4 of [Ref1], with the following
   exceptions:

   o  The Link State ID of the AS-external-LSA types no longer encodes
      the network described by the LSA. Instead, an address prefix is
      contained in the body of an AS- external-LSA.

Top      Up      ToC       Page 43 
   o  The default route is described by AS-external-LSAs which advertise
      zero length prefixes.

   o  Instead of comparing the AS-external-LSA's Forwarding address
      field to 0.0.0.0 to see whether a forwarding address has been
      used, bit F of the external-LSA is examined. A forwarding address
      is in use if and only if bit F is set.

   o  Prefixes having the "NU-bit" set in their Prefix Options field
      should be ignored by the inter-area route calculation.

   When a single AS-external-LSA has changed, the incremental
   calculations outlined in Section 16.6 of [Ref1] can be performed
   instead of recalculating the entire routing table.

3.9.  Multiple interfaces to a single link

   In OSPF for IPv6, a router may have multiple interfaces to a single
   link. All interfaces are involved in the reception and transmission
   of data traffic, however only a single interface sends and receives
   OSPF control traffic. In more detail:

   o  Each of the multiple interfaces are assigned different Interface
      IDs.  In this way the router can automatically detect when
      multiple interfaces attach to the same link, when receiving Hellos
      from its own Router ID but with an Interface ID other than the
      receiving interface's.

   o  The router turns off the sending and receiving of OSPF packets
      (that is, control traffic) on all but one of the interfaces to the
      link. The choice of interface to send and receive control traffic
      is implementation dependent; as one example, the interface with
      the highest Interface ID could be chosen.  If the router is
      elected DR, it will be this interface's Interface ID that will be
      used as the network-LSA's Link State ID.

   o  All the multiple interfaces to the link will however appear in the
      router-LSA. In addition, a Link-LSA will be generated for each of
      the multiple interfaces. In this way, all interfaces will be
      included in OSPF's routing calculations.

   o  If the interface which is responsible for sending and receiving
      control traffic fails,  another will have to take over, reforming
      all neighbor adjacencies from scratch. This failure can be
      detected by the router itself, when the other interfaces to the
      same link cease to hear the router's own Hellos.

Top      Up      ToC       Page 44 
References

   [Ref1]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [Ref2]  McKenzie, A., "ISO Transport Protocol specification ISO DP
           8073", RFC 905, April 1984.

   [Ref3]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
           using SMIv2", RFC 2233, November 1997.

   [Ref4]  Fuller, V., Li, T, Yu, J. and K. Varadhan, "Classless Inter-
           Domain Routing (CIDR): an Address Assignment and Aggregation
           Strategy", RFC 1519, September 1993.

   [Ref5]  Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP---
           OSPF Interaction", RFC 1745, December 1994

   [Ref6]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
           1700, October 1994.

   [Ref7]  deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF
           Over Frame Relay Networks", RFC 1586, March 1994.

   [Ref8]  Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
           1994.

   [Ref9]  Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
           March 1994.

   [Ref10] Ferguson, D., "The OSPF External Attributes LSA",
           unpublished.

   [Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
           1793, April 1995.

   [Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
           November 1990.

   [Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
           RFC 1771, March 1995.

   [Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998.

   [Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 2373, July 1998.

Top      Up      ToC       Page 45 
   [Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol
           (ICMPv6) for the Internet Protocol Version 6 (IPv6)
           Specification" RFC 2463, December 1998.

   [Ref17] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
           for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for
           IP version 6", RFC 1981, August 1996.

   [Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
           2402, November 1998.

   [Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
           (ESP)", RFC 2406, November 1998.


Next RFC Part