tech-invite   World Map     

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

RFC 2740

 
 
 

OSPF for IPv6

Part 3 of 3, p. 46 to 80
Prev RFC Part

 


prevText      Top      Up      ToC       Page 46 
A. OSPF data formats

   This appendix describes the format of OSPF protocol packets and OSPF
   LSAs.  The OSPF protocol runs directly over the IPv6 network layer.
   Before any data formats are described, the details of the OSPF
   encapsulation are explained.

   Next the OSPF Options field is described.  This field describes
   various capabilities that may or may not be supported by pieces of
   the OSPF routing domain. The OSPF Options field is contained in OSPF
   Hello packets, Database Description packets and in OSPF LSAs.

   OSPF packet formats are detailed in Section A.3.

   A description of OSPF LSAs appears in Section A.4. This section
   describes how IPv6 address prefixes are represented within LSAs,
   details the standard LSA header, and then provides formats for each
   of the specific LSA types.

A.1 Encapsulation of OSPF packets

   OSPF runs directly over the IPv6's network layer.  OSPF packets are
   therefore encapsulated solely by IPv6 and local data-link headers.

   OSPF does not define a way to fragment its protocol packets, and
   depends on IPv6 fragmentation when transmitting packets larger than
   the link MTU. If necessary, the length of OSPF packets can be up to
   65,535 bytes.  The OSPF packet types that are likely to be large
   (Database Description Packets, Link State Request, Link State Update,
   and Link State Acknowledgment packets) can usually be split into
   several separate protocol packets, without loss of functionality.
   This is recommended; IPv6 fragmentation should be avoided whenever
   possible.  Using this reasoning, an attempt should be made to limit
   the sizes of OSPF packets sent over virtual links to 1280 bytes
   unless Path MTU Discovery is being performed [Ref14].

   The other important features of OSPF's IPv6 encapsulation are:

   o   Use of IPv6 multicast. Some OSPF messages are multicast, when
       sent over broadcast networks.  Two distinct IP multicast
       addresses are used.  Packets sent to these multicast addresses
       should never be forwarded; they are meant to travel a single hop
       only. As such, the multicast addresses have been chosen with
       link-local scope, and packets sent to these addresses should have
       their IPv6 Hop Limit set to 1.

Top      Up      ToC       Page 47 
   AllSPFRouters
      This multicast address has been assigned the value FF02::5.  All
      routers running OSPF should be prepared to receive packets sent to
      this address.  Hello packets are always sent to this destination.
      Also, certain OSPF protocol packets are sent to this address
      during the flooding procedure.

   AllDRouters
      This multicast address has been assigned the value FF02::6.  Both
      the Designated Router and Backup Designated Router must be
      prepared to receive packets destined to this address.  Certain
      OSPF protocol packets are sent to this address during the flooding
      procedure.

   o  OSPF is IP protocol 89.  This number should be inserted in the
      Next Header field of the encapsulating IPv6 header.

A.2 The Options field

   The 24-bit OSPF Options field is present in OSPF Hello packets,
   Database Description packets and certain LSAs (router-LSAs, network-
   LSAs, inter-area-router-LSAs and link-LSAs). The Options field
   enables OSPF routers to support (or not support) optional
   capabilities, and to communicate their capability level to other OSPF
   routers.  Through this mechanism routers of differing capabilities
   can be mixed within an OSPF routing domain.

   An option mismatch between routers can cause a variety of behaviors,
   depending on the particular option. Some option mismatches prevent
   neighbor relationships from forming (e.g., the E-bit below); these
   mismatches are discovered through the sending and receiving of Hello
   packets. Some option mismatches prevent particular LSA types from
   being flooded across adjacencies (e.g., the MC-bit below); these are
   discovered through the sending and receiving of Database Description
   packets. Some option mismatches prevent routers from being included
   in one or more of the various routing calculations because of their
   reduced functionality (again the MC-bit is an example); these
   mismatches are discovered by examining LSAs.

   Six bits of the OSPF Options field have been assigned. Each bit is
   described briefly below. Routers should reset (i.e.  clear)
   unrecognized bits in the Options field when sending Hello packets or
   Database Description packets and when originating LSAs. Conversely,
   routers encountering unrecognized Option bits in received Hello
   Packets, Database Description packets or LSAs should ignore the
   capability and process the packet/LSA normally.

Top      Up      ToC       Page 48 
                             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
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
         | | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+

                        The Options field

   V6-bit
     If this bit is clear, the router/link should be excluded from IPv6
     routing calculations. See Section 3.8 of this memo.

   E-bit
     This bit describes the way AS-external-LSAs are flooded, as
     described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1].

   MC-bit
     This bit describes whether IP multicast datagrams are forwarded
     according to the specifications in [Ref7].

   N-bit
     This bit describes the handling of Type-7 LSAs, as specified in
     [Ref8].

   R-bit
     This bit (the `Router' bit) indicates whether the originator is an
     active router.  If the router bit is clear routes which transit the
     advertising node cannot be computed. Clearing the router bit would
     be appropriate for a multi-homed host that wants to participate in
     routing, but does not want to forward non-locally addressed
     packets.

   DC-bit
     This bit describes the router's handling of demand circuits, as
     specified in [Ref10].

A.3 OSPF Packet Formats

   There are five distinct OSPF packet types.  All OSPF packet types
   begin with a standard 16 byte header.  This header is described
   first.  Each packet type is then described in a succeeding section.
   In these sections each packet's division into fields is displayed,
   and then the field definitions are enumerated.

   All OSPF packet types (other than the OSPF Hello packets) deal with
   lists of LSAs.  For example, Link State Update packets implement the
   flooding of LSAs throughout the OSPF routing domain. The format of
   LSAs is described in Section A.4.

Top      Up      ToC       Page 49 
   The receive processing of OSPF packets is detailed in Section 3.2.2.
   The sending of OSPF packets is explained in Section 3.2.1.

A.3.1 The OSPF packet header

   Every OSPF packet starts with a standard 16 byte header. Together
   with the encapsulating IPv6 headers, the OSPF header contains all the
   information necessary to determine whether the packet should be
   accepted for further processing.  This determination is described in
   Section 3.2.2 of this memo.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version #   |     Type      |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version #
       The OSPF version number.  This specification documents version 3
       of the OSPF protocol.

   Type
       The OSPF packet types are as follows. See Sections A.3.2 through
       A.3.6 for details.

         Type   Description
         ---------------------------------
         1      Hello
         2      Database Description
         3      Link State Request
         4      Link State Update
         5      Link State Acknowledgment

   Packet length
       The length of the OSPF protocol packet in bytes.  This length
       includes the standard OSPF header.

   Router ID
       The Router ID of the packet's source.

Top      Up      ToC       Page 50 
   Area ID
       A 32 bit number identifying the area that this packet belongs to.
       All OSPF packets are associated with a single area.  Most travel
       a single hop only.  Packets travelling over a virtual link are
       labelled with the backbone Area ID of 0.

   Checksum
       OSPF uses the standard checksum calculation for IPv6
       applications: The 16-bit one's complement of the one's complement
       sum of the entire contents of the packet, starting with the OSPF
       packet header, and prepending a "pseudo-header" of IPv6 header
       fields, as specified in [Ref14, section 8.1]. The "Upper-Layer
       Packet Length" in the pseudo-header is set to value of the OSPF
       packet header's length field.  The Next Header value used in the
       pseudo-header is 89. If the packet's length is not an integral
       number of 16-bit words, the packet is padded with a byte of zero
       before checksumming. Before computing the checksum, the checksum
       field in the OSPF packet header is set to 0.

   Instance ID
       Enables multiple instances of OSPF to be run over a single link.
       Each protocol instance would be assigned a separate Instance ID;
       the Instance ID has local link significance only. Received
       packets whose Instance ID is not equal to the receiving
       interface's Instance ID are discarded.

       0       These fields are reserved.  They must be 0.

A.3.2 The Hello packet

   Hello packets are OSPF packet type 1.  These packets are sent
   periodically on all interfaces (including virtual links) in order to
   establish and maintain neighbor relationships.  In addition, Hello
   Packets are multicast on those links having a multicast or broadcast
   capability, enabling dynamic discovery of neighboring routers.

   All routers connected to a common link must agree on certain
   parameters (HelloInterval and RouterDeadInterval).  These parameters
   are included in Hello packets, so that differences can inhibit the
   forming of neighbor relationships. The Hello packet also contains
   fields used in Designated Router election (Designated Router ID and
   Backup Designated Router ID), and fields used to detect bi-
   directionality (the Router IDs of all neighbors whose Hellos have
   been recently received).

Top      Up      ToC       Page 51 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3               |       1       |  Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |             Options                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        HelloInterval         |        RouterDeadInterval      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Designated Router ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Backup Designated Router ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Neighbor ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |


   Interface ID
       32-bit number uniquely identifying this interface among the
       collection of this router's interfaces. For example, in some
       implementations it may be possible to use the MIB-II IfIndex
       ([Ref3]).

   Rtr Pri
       This router's Router Priority.  Used in (Backup) Designated
       Router election.  If set to 0, the router will be ineligible to
       become (Backup) Designated Router.

   Options
       The optional capabilities supported by the router, as documented
       in Section A.2.

   HelloInterval
       The number of seconds between this router's Hello packets.

   RouterDeadInterval
       The number of seconds before declaring a silent router down.

Top      Up      ToC       Page 52 
   Designated Router ID
       The identity of the Designated Router for this network, in the
       view of the sending router.  The Designated Router is identified
       by its Router ID. Set to 0.0.0.0 if there is no Designated
       Router.

   Backup Designated Router ID
       The identity of the Backup Designated Router for this network, in
       the view of the sending router.  The Backup Designated Router is
       identified by its IP Router ID.  Set to 0.0.0.0 if there is no
       Backup Designated Router.

   Neighbor ID
       The Router IDs of each router from whom valid Hello packets have
       been seen recently on the network.  Recently means in the last
       RouterDeadInterval seconds.

A.3.3 The Database Description packet

   Database Description packets are OSPF packet type 2.  These packets
   are exchanged when an adjacency is being initialized.  They describe
   the contents of the link-state database.  Multiple packets may be
   used to describe the database.  For this purpose a poll-response
   procedure is used.      One of the routers is designated to be the
   master, the other the slave.  The master sends Database Description
   packets (polls) which are acknowledged by Database Description
   packets sent by the slave (responses).  The responses are linked to
   the polls via the packets' DD sequence numbers.

Top      Up      ToC       Page 53 
    0                  1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       2       |        Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Area ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |  Instance ID  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |               Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Interface MTU         |       0        |0|0|0|0|0|I|M|MS
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    DD sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                     An LSA Header                           -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

   The format of the Database Description packet is very similar to both
   the Link State Request and Link State Acknowledgment packets.  The
   main part of all three is a list of items, each item describing a
   piece of the link-state database.      The sending of Database
   Description Packets is documented in Section 10.8 of [Ref1].  The
   reception of Database Description packets is documented in Section
   10.6 of [Ref1].

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   Interface MTU
      The size in bytes of the largest IPv6 datagram that can be sent
      out the    associated interface, without fragmentation.  The MTUs
      of common Internet link  types can be found in Table 7-1    of
      [Ref12]. Interface MTU should be set to 0 in Database Description
      packets sent over virtual links.

Top      Up      ToC       Page 54 
   I-bit
      The Init bit.  When set to 1, this packet is the first in the
      sequence of Database Description Packets.

   M-bit
      The More bit.  When set to 1, it indicates that more Database
      Description Packets are to follow.

   MS-bit
      The Master/Slave bit.  When set to 1, it indicates that the router
      is the master during the Database Exchange process.  Otherwise,
      the router is the slave.

   DD sequence number
      Used to sequence the collection of Database Description Packets.
      The initial value (indicated by the Init bit being set) should be
      unique.  The DD sequence number then increments until the complete
      database description has been sent.

   The rest of the packet consists of a (possibly partial) list of the
   link-state database's pieces.  Each LSA in the database is described
   by its LSA header.      The LSA header is documented in Section
   A.4.1.  It contains all the information required to uniquely identify
   both the LSA and the LSA's current instance.

A.3.4 The Link State Request packet

   Link State Request packets are OSPF packet type 3.  After exchanging
   Database Description packets with a neighboring router, a router may
   find that parts of its link-state database are out-of-date. The Link
   State Request packet is used to request the pieces of the neighbor's
   database that are more up-to-date.  Multiple Link State Request
   packets may need to be used.

   A router that sends a Link State Request packet has in mind the
   precise instance of the database pieces it is requesting. Each
   instance is defined by its LS sequence number, LS checksum, and LS
   age, although these fields are not specified in the Link State
   Request Packet itself.  The router may receive even more recent
   instances in response.

   The sending of Link State Request packets is documented in Section
   10.9 of [Ref1].  The reception of Link State Request packets is
   documented in Section 10.7 of [Ref1].

Top      Up      ToC       Page 55 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3           |       3       |     Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Area ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum               |  Instance ID  |      0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              0                  |        LS type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Link State ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Advertising Router                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ...                     |

   Each LSA requested is specified by its LS type, Link State ID, and
   Advertising Router.  This uniquely identifies the LSA, but not its
   instance.  Link State Request packets are understood to be requests
   for the most recent instance (whatever that might be).

A.3.5 The Link State Update packet

   Link State Update packets are OSPF packet type 4.  These packets
   implement the flooding of LSAs.  Each Link State Update packet
   carries a collection of LSAs one hop further from their origin.
   Several LSAs may be included in a single packet.

   Link State Update packets are multicast on those physical networks
   that support multicast/broadcast.  In order to make the flooding
   procedure reliable, flooded LSAs are acknowledged in Link State
   Acknowledgment packets.  If retransmission of certain LSAs is
   necessary, the retransmitted LSAs are always carried by unicast Link
   State Update packets. For more information on the reliable flooding
   of LSAs, consult Section 3.5.

Top      Up      ToC       Page 56 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3        |       4       |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           # LSAs                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                            +-+
   |                            LSAs                               |
   +-                                                            +-+
   |                    ...                              |

   # LSAs
      The number of LSAs included in this update.

   The body of the Link State Update packet consists of a list of LSAs.
   Each LSA begins with a common 20 byte header, described in Section
   A.4.2. Detailed formats of the different types of LSAs are described
   in Section A.4.

A.3.6 The Link State Acknowledgment packet

   Link State Acknowledgment Packets are OSPF packet type 5.  To make
   the flooding of LSAs reliable, flooded LSAs are explicitly
   acknowledged.  This acknowledgment is accomplished through the
   sending and receiving of Link State Acknowledgment packets. The
   sending of Link State Acknowledgement packets is documented in
   Section 13.5 of [Ref1].  The reception of Link State Acknowledgement
   packets is documented in Section 13.7 of [Ref1].

   Multiple LSAs can be acknowledged in a single Link State
   Acknowledgment packet.  Depending on the state of the sending
   interface and the sender of the corresponding Link State Update
   packet, a Link State Acknowledgment packet is sent either to the
   multicast address AllSPFRouters, to the multicast address
   AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for
   details).

   The format of this packet is similar to that of the Data Description
   packet.  The body of both packets is simply a list of LSA headers.

Top      Up      ToC       Page 57 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      3              |       5       |  Packet length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum            |  Instance ID  |      0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                        An LSA Header                        -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    ...                              |

   Each acknowledged LSA is described by its LSA header.  The LSA header
   is documented in Section A.4.2.  It contains all the information
   required to uniquely identify both the LSA and the LSA's current
   instance.

A.4 LSA formats

   This memo defines seven distinct types of LSAs.  Each LSA begins with
   a standard 20 byte LSA header.  This header is explained in Section
   A.4.2.  Succeeding sections then diagram the separate LSA types.

   Each LSA describes a piece of the OSPF routing domain.  Every router
   originates a router-LSA. A network-LSA is advertised for each link by
   its Designated Router. A router's link-local addresses are advertised
   to its neighbors in link-LSAs. IPv6 prefixes are advertised in
   intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS-external-LSAs.
   Location of specific routers can be advertised across area boundaries
   in inter-area-router-LSAs. All LSAs are then flooded throughout the
   OSPF routing domain.  The flooding algorithm is reliable, ensuring
   that all routers have the same collection of LSAs.  (See Section 3.5
   for more information concerning the flooding algorithm).  This
   collection of LSAs is called the link-state database.

Top      Up      ToC       Page 58 
   From the link state database, each router constructs a shortest path
   tree with itself as root.  This yields a routing table (see Section
   11 of [Ref1]).  For the details of the routing table build process,
   see Section 3.8.

A.4.1 IPv6 Prefix Representation

   IPv6 addresses are bit strings of length 128. IPv6 routing
   algorithms, and OSPF for IPv6 in particular, advertise IPv6 address
   prefixes. IPv6 address prefixes are bit strings whose length ranges
   between 0 and 128 bits (inclusive).

   Within OSPF, IPv6 address prefixes are always represented by a
   combination of three fields: PrefixLength, PrefixOptions, and Address
   Prefix. PrefixLength is the length in bits of the prefix.
   PrefixOptions is an 8-bit field describing various capabilities
   associated with the prefix (see Section A.4.2). Address Prefix is an
   encoding of the prefix itself as an even multiple of 32-bit words,
   padding with zero bits as necessary; this encoding consumes
   (PrefixLength + 31) / 32) 32-bit words.

   The default route is represented by a prefix of length 0.

   Examples of IPv6 Prefix representation in OSPF can be found in
   Sections A.4.5, A.4.7, A.4.8 and A.4.9.

A.4.1.1 Prefix Options

   Each prefix is advertised along with an 8-bit field of capabilities.
   These serve as input to the various routing calculations, allowing,
   for example, certain prefixes to be ignored in some cases, or to be
   marked as not readvertisable in others.

                  0  1  2  3  4  5  6  7
                 +--+--+--+--+--+--+--+--+
                 |  |  |  |  | P|MC|LA|NU|
                 +--+--+--+--+--+--+--+--+

                 The Prefix Options field

   NU-bit
      The "no unicast" capability bit. If set, the prefix should be
      excluded from IPv6 unicast calculations, otherwise it should be
      included.

Top      Up      ToC       Page 59 
   LA-bit
      The "local address" capability bit. If set, the prefix is actually
      an IPv6 interface address of the advertising router.

   MC-bit
      The "multicast" capability bit. If set, the prefix should be
      included in IPv6 multicast routing calculations, otherwise it
      should be excluded.

   P-bit
      The "propagate" bit. Set on NSSA area prefixes that should be
      readvertised at the NSSA area border.

A.4.2 The LSA header

   All LSAs begin with a common 20 byte header.  This header contains
   enough information to uniquely identify the LSA (LS type, Link State
   ID, and Advertising Router).  Multiple instances of the LSA may exist
   in the routing domain at the same time.  It is then necessary to
   determine which instance is more recent.  This is accomplished by
   examining the LS age, LS sequence number and LS checksum fields that
   are also contained in the LSA header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |           LS type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   LS age
      The time in seconds since the LSA was originated.

   LS type
      The LS type field indicates the function performed by the LSA.
      The high-order three bits of LS type encode generic properties of
      the LSA, while the remainder (called LSA function code) indicate
      the LSA's specific functionality. See Section A.4.2.1 for a
      detailed description of LS type.

Top      Up      ToC       Page 60 
   Link State ID
      Together with LS type and Advertising Router, uniquely identifies
      the LSA in the link-state database.

   Advertising Router
      The Router ID of the router that originated the LSA.  For example,
      in network-LSAs this field is equal to the Router ID of the
      network's Designated Router.

   LS sequence number
      Detects old or duplicate LSAs.  Successive instances of an LSA are
      given successive LS sequence numbers.  See Section 12.1.6 in
      [Ref1] for more details.

   LS checksum
      The Fletcher checksum of the complete contents of the LSA,
      including the LSA header but excluding the LS age field. See
      Section 12.1.7 in [Ref1] for more details.

   length
      The length in bytes of the LSA.  This includes the 20 byte LSA
      header.

A.4.2.1 LS type

   The LS type field indicates the function performed by the LSA.  The
   high-order three bits of LS type encode generic properties of the
   LSA, while the remainder (called LSA function code) indicate the
   LSA's specific functionality. The format of the LS type is as
   follows:

           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         |U |S2|S1|           LSA Function Code          |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The U bit indicates how the LSA should be handled by a router which
   does not recognize the LSA's function code.  Its values are:

     U-bit   LSA Handling
     -------------------------------------------------------------
     0       Treat the LSA as if it had link-local flooding scope
     1       Store and flood the LSA, as if type understood

Top      Up      ToC       Page 61 
   The S1 and S2 bits indicate the flooding scope of the LSA. The values
   are:

   S2  S1   Flooding Scope
   ---------------------------------------------------------------------
   0  0    Link-Local Scoping. Flooded only on link it is originated on.
   0  1    Area Scoping. Flooded to all routers in the originating area
   1  0    AS Scoping. Flooded to all routers in the AS
   1  1    Reserved

   The LSA function codes are defined as follows. The origination and
   processing of these LSA function codes are defined elsewhere in this
   memo, except for the group-membership-LSA (see [Ref7]) and the Type-
   7-LSA (see [Ref8]). Each LSA function code also implies a specific
   setting for the U, S1 and S2 bits, as shown below.

         LSA function code   LS Type   Description
         ----------------------------------------------------
         1                   0x2001    Router-LSA
         2                   0x2002    Network-LSA
         3                   0x2003    Inter-Area-Prefix-LSA
         4                   0x2004    Inter-Area-Router-LSA
         5                   0x4005    AS-External-LSA
         6                   0x2006    Group-membership-LSA
         7                   0x2007    Type-7-LSA
         8                   0x0008    Link-LSA
         9                   0x2009    Intra-Area-Prefix-LSA

A.4.3 Router-LSAs

   Router-LSAs have LS type equal to 0x2001.  Each router in an area
   originates one or more router-LSAs.   The complete collection of
   router-LSAs originated by the router describe the state and cost of
   the router's interfaces to the area. For details concerning the
   construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are
   flooded throughout a single area only.

Top      Up      ToC       Page 62 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          1               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    0  |W|V|E|B|            Options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |       0       |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

   A single router may originate one or more Router LSAs, distinguished
   by their Link-State IDs (which are chosen arbitrarily by the
   originating router).  The Options field and V, E and B bits should be
   the same in all Router LSAs from a single originator.  However, in
   the case of a mismatch the values in the LSA with the lowest Link
   State ID take precedence. When more than one Router LSA is received
   from a single router, the links are processed as if concatenated into
   a single LSA.

   bit V
      When set, the router is an endpoint of one or more fully adjacent
      virtual links having the described area as Transit area (V is for
      virtual link endpoint).

Top      Up      ToC       Page 63 
   bit E
      When set, the router is an AS boundary router (E is for external).

   bit B
      When set, the router is an area border router (B is for border).

   bit W
      When set, the router is a wild-card multicast receiver.  When
      running MOSPF, these routers receive all multicast datagrams,
      regardless of destination. See Sections 3, 4 and A.2 of [Ref8] for
      details.

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   The following fields are used to describe each router interface.  The
   Type field indicates the kind of interface being described.  It may
   be an interface to a transit network, a point-to-point connection to
   another router or a virtual link.  The values of all the other fields
   describing a router interface depend on the interface's Type field.

   Type
      The kind of interface being described.  One of the following:

          Type   Description
          ---------------------------------------------------
          1      Point-to-point connection to another router
          2      Connection to a transit network
          3      Reserved
          4      Virtual link

   Metric
      The cost of using this router interface, for outbound traffic.

   Interface ID
      The Interface ID assigned to the interface being described. See
      Sections 3.1.2 and C.3.

   Neighbor Interface ID
      The Interface ID the neighbor router (or the attached link's
      Designated Router, for Type 2 interfaces) has been advertising
      in hello packets sent on the attached link.

   Neighbor Router ID
      The Router ID the neighbor router (or the attached link's
      Designated Router, for Type 2 interfaces).

Top      Up      ToC       Page 64 
      For Type 2 links, the combination of Neighbor Interface ID and
      Neighbor Router ID allows the network-LSA for the attached link
      to be found in the link-state database.

A.4.4 Network-LSAs

   Network-LSAs have LS type equal to 0x2002.  A network-LSA is
   originated for each broadcast and NBMA link in the area which
   supports two or more routers.  The network-LSA is originated by the
   link's Designated Router.  The LSA describes all routers attached to
   the link, including the Designated Router itself.  The LSA's Link
   State ID field is set to the Interface ID that the Designated Router
   has been advertising in Hello packets on the link.

   The distance from the network to all attached routers is zero.  This
   is why the metric fields need not be specified in the network-LSA.
   For details concerning the construction of network-LSAs, see Section
   3.4.3.2.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          2               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |              Options                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Attached Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

   Attached Router
      The Router IDs of each of the routers attached to the link.
      Actually, only those routers that are fully adjacent to the
      Designated Router are listed.  The Designated Router includes
      itself in this list.  The number of routers included can be
      deduced from the LSA header's length field.

Top      Up      ToC       Page 65 
A.4.5 Inter-Area-Prefix-LSAs

   Inter-Area-Prefix-LSAs have LS type equal to 0x2003.  These LSAs are
   are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see
   Section 12.4.3 of [Ref1]).  Originated by area border routers, they
   describe routes to IPv6 address prefixes that belong to other areas.
   A separate Inter-Area-Prefix-LSA is originated for each IPv6 address
   prefix. For details concerning the construction of Inter-Area-
   Prefix-LSAs, see Section 3.4.3.3.

   For stub areas, Inter-Area-Prefix-LSAs can also be used to describe a
   (per-area) default route.  Default summary routes are used in stub
   areas instead of flooding a complete set of external routes.  When
   describing a default summary route, the Inter-Area-Prefix-LSA's
   PrefixLength is set to 0.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|          3               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |                  Metric                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Metric
      The cost of this route.  Expressed in the same units as the
      interface costs in the router-LSAs. When the Inter-Area-Prefix-LSA
      is describing a route to a range of addresses (see Section C.2)
      the cost is set to the maximum cost to any reachable component of
      the address range.

   PrefixLength, PrefixOptions and Address Prefix
      Representation of the IPv6 address prefix, as described in Section
      A.4.1.

Top      Up      ToC       Page 66 
A.4.6 Inter-Area-Router-LSAs

   Inter-Area-Router-LSAs have LS type equal to 0x2004.  These LSAs are
   are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see
   Section 12.4.3 of [Ref1]).  Originated by area border routers, they
   describe routes to routers in other areas.  (To see why it is
   necessary to advertise the location of each ASBR, consult Section
   16.4 in [Ref1].)  Each LSA describes a route to a single router. For
   details concerning the construction of Inter-Area-Router-LSAs, see
   Section 3.4.3.4.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|        4                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |          Options                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0               |          Metric                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Router ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   Metric
      The cost of this route.  Expressed in the same units as the
      interface costs in the router-LSAs.

   Destination Router ID
      The Router ID of the router being described by the LSA.

Top      Up      ToC       Page 67 
A.4.7 AS-external-LSAs

   AS-external-LSAs have LS type equal to 0x4005.  These LSAs are
   originated by AS boundary routers, and describe destinations external
   to the AS. Each LSA describes a route to a single IPv6 address
   prefix. For details concerning the construction of AS-external-LSAs,
   see Section 3.4.3.5.

   AS-external-LSAs can be used to describe a default route.  Default
   routes are used when no specific route exists to the destination.
   When describing a default route, the AS-external-LSA's PrefixLength
   is set to 0.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|1|0|          5               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        |E|F|T|                 Metric                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixLength  | PrefixOptions |     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Forwarding Address (Optional)                -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           External Route Tag (Optional)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Link State ID (Optional)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 68 
   bit E
      The type of external metric.  If bit E is set, the metric
      specified is a Type 2 external metric.  This means the metric is
      considered larger than any intra-AS path.  If bit E is zero, the
      specified metric is a Type 1 external metric.  This means that it
      is expressed in the same units as the link state metric (i.e., the
      same units as interface cost).

   bit F
      If set, a Forwarding Address has been included in the LSA.

   bit T
      If set, an External Route Tag has been included in the LSA.

   Metric
      The cost of this route.  Interpretation depends on the external
      type indication (bit E above).

   PrefixLength, PrefixOptions and Address Prefix
      Representation of the IPv6 address prefix, as described in Section
      A.4.1.

   Referenced LS type
      If non-zero, an LSA with this LS type is to be associated with
      this LSA (see Referenced Link State ID below).

   Forwarding address
      A fully qualified IPv6 address (128 bits).  Included in the LSA if
      and only if bit F has been set.  If included, Data traffic for the
      advertised destination will be forwarded to this address. Must not
      be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0).

   External Route Tag
      A 32-bit field which may be used to communicate additional
      information between AS boundary routers; see [Ref5] for example
      usage. Included in the LSA if and only if bit T has been set.

   Referenced Link State ID Included if and only if Reference LS Type is
      non-zero.  If included, additional information concerning the
      advertised external route can be found in the LSA having LS type
      equal to "Referenced LS Type", Link State ID equal to "Referenced
      Link State ID" and Advertising Router the same as that specified
      in the AS-external-LSA's link state header. This additional
      information is not used by the OSPF protocol itself.  It may be
      used to communicate information between AS boundary routers; the
      precise nature of such information is outside the scope of this
      specification.

Top      Up      ToC       Page 69 
   All, none or some of the fields labeled Forwarding address, External
   Route Tag and Referenced Link State ID may be present in the AS-
   external-LSA (as indicated by the setting of bit F, bit T and
   Referenced LS type respectively). However, when present Forwarding
   Address always comes first, with External Route Tag always preceding
   Referenced Link State ID.

A.4.8 Link-LSAs

   Link-LSAs have LS type equal to 0x0008.  A router originates a
   separate Link-LSA for each link it is attached to. These LSAs have
   local-link flooding scope; they are never flooded beyond the link
   that they are associated with. 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 to associate with
   the Network-LSA that will be originated for the link.

   A link-LSA's Link State ID is set equal to the originating router's
   Interface ID on the link.

Top      Up      ToC       Page 70 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|0|           8              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |                Options                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Link-local Interface Address                 -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         # prefixes                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |             (0)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Address Prefix                         |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Rtr Pri
      The Router Priority of the interface attaching the originating
      router to the link.

   Options
      The set of Options bits that the router would like set in the
      Network-LSA that will be originated for the link.

Top      Up      ToC       Page 71 
   Link-local Interface Address
      The originating router's link-local interface address on the
      link.

   # prefixes
      The number of IPv6 address prefixes contained in the LSA.

      The rest of the link-LSA contains a list of IPv6 prefixes to be
      associated with the link.

   PrefixLength, PrefixOptions and Address Prefix
      Representation of an IPv6 address prefix, as described in
      Section A.4.1.

A.4.9 Intra-Area-Prefix-LSAs

   Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses
   Intra-Area-Prefix-LSAs to advertise one or more IPv6 address
   prefixes that are associated with a) the router itself, b) an
   attached stub network segment or c) an attached transit network
   segment. In IPv4, a) and b) were accomplished via the router's
   router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all
   addressing information has been removed from router-LSAs and
   network-LSAs, leading to the introduction of the Intra-Area-Prefix-LSA.

   A router can originate multiple Intra-Area-Prefix-LSAs for each
   router or transit network; each such LSA is distinguished by its
   Link State ID.

Top      Up      ToC       Page 72 
    0                  1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           LS age             |0|0|1|            9             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum           |             length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         # prefixes           |     Referenced LS type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Referenced Link State ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Advertising Router                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PrefixLength | PrefixOptions |          Metric               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   # prefixes
      The number of IPv6 address prefixes contained in the LSA.

      Router
   Referenced LS type, Referenced Link State ID and Referenced
      Advertising
      Identifies the router-LSA or network-LSA with which the IPv6
      address prefixes should be associated. If Referenced LS type is 1,
      the prefixes are associated with a router-LSA, Referenced Link
      State ID should be 0 and Referenced Advertising Router should be
      the originating router's Router ID. If Referenced LS type is 2,
      the prefixes are associated with a network-LSA, Referenced Link
      State ID should be the Interface ID of the link's Designated
      Router and Referenced Advertising Router should be the Designated
      Router's Router ID.

Top      Up      ToC       Page 73 
   The rest of the Intra-Area-Prefix-LSA contains a list of IPv6
   prefixes to be associated with the router or transit link, together
   with the cost of each prefix.

   PrefixLength, PrefixOptions and Address Prefix
      Representation of an IPv6 address prefix, as described in Section
      A.4.1.

   Metric
      The cost of this prefix.  Expressed in the same units as the
      interface costs in the router-LSAs.

B. Architectural Constants

   Architectural constants for the OSPF protocol are defined in Appendix
   B of [Ref1]. The only difference for OSPF for IPv6 is that
   DefaultDestination is encoded as a prefix of length 0 (see Section
   A.4.1).

C. Configurable Constants

   The OSPF protocol has quite a few configurable parameters.  These
   parameters are listed below.  They are grouped into general
   functional categories (area parameters, interface parameters, etc.).
   Sample values are given for some of the parameters.

   Some parameter settings need to be consistent among groups of
   routers.  For example, all routers in an area must agree on that
   area's parameters, and all routers attached to a network must agree
   on that network's HelloInterval and RouterDeadInterval.

   Some parameters may be determined by router algorithms outside of
   this specification (e.g., the address of a host connected to the
   router via a SLIP line).  From OSPF's point of view, these items are
   still configurable.

C.1 Global parameters

   In general, a separate copy of the OSPF protocol is run for each
   area.  Because of this, most configuration parameters are defined on
   a per-area basis.  The few global configuration parameters are listed
   below.

   Router ID
      This is a 32-bit number that uniquely identifies the router in the
      Autonomous System. If a router's OSPF Router ID is changed, the
      router's OSPF software should be restarted before the new Router
      ID takes effect. Before restarting in order to change its Router

Top      Up      ToC       Page 74 
      ID, the router should flush its self-originated LSAs from the
      routing domain (see Section 14.1 of [Ref1]), or they will persist
      for up to MaxAge minutes.

      Because the size of the Router ID is smaller than an IPv6 address,
      it cannot be set to one of the router's IPv6 addresses (as is
      commonly done for IPv4). Possible Router ID assignment procedures
      for IPv6 include: a) assign the IPv6 Router ID as one of the
      router's IPv4 addresses or b) assign IPv6 Router IDs through some
      local administrative procedure (similar to procedures used by
      manufacturers to assign product serial numbers).

      The Router ID of 0.0.0.0 is reserved, and should not be used.

C.2 Area parameters

   All routers belonging to an area must agree on that area's
   configuration.  Disagreements between two routers will lead to an
   inability for adjacencies to form between them, with a resulting
   hindrance to the flow of routing protocol and data traffic.  The
   following items must be configured for an area:

   Area ID
       This is a 32-bit number that identifies the area.  The Area
       ID of 0 is reserved for the backbone.

   List of address ranges
       Address ranges control the advertisement of routes across
       area boundaries. Each address range consists of the
       following items:

       [IPv6 prefix, prefix length]
               Describes the collection of IPv6 addresses contained in
               the address range.

       Status  Set to either Advertise or DoNotAdvertise.  Routing
               information is condensed at area boundaries.  External to
               the area, at most a single route is advertised (via a
               inter-area-prefix-LSA) for each address range. The route
               is advertised if and only if the address range's Status
               is set to Advertise.  Unadvertised ranges allow the
               existence of certain networks to be intentionally hidden
               from other areas. Status is set to Advertise by default.

Top      Up      ToC       Page 75 
   ExternalRoutingCapability
      Whether AS-external-LSAs will be flooded into/throughout the area.
      If AS-external-LSAs are excluded from the area, the area is called
      a "stub".  Internal to stub areas, routing to external
      destinations will be based solely on a default inter-area route.
      The backbone cannot be configured as a stub area. Also, virtual
      links cannot be configured through stub areas. For more
      information, see Section 3.6 of [Ref1].

   StubDefaultCost
      If the area has been configured as a stub area, and the router
      itself is an area border router, then the StubDefaultCost
      indicates the cost of the default inter-area-prefix-LSA that the
      router should advertise into the area. See Section 12.4.3.1 of
      [Ref1] for more information.

C.3 Router interface parameters

   Some of the configurable router interface parameters (such as Area
   ID, HelloInterval and RouterDeadInterval) actually imply properties
   of the attached links, and therefore must be consistent across all
   the routers attached to that link.  The parameters that must be
   configured for a router interface are:

   IPv6 link-local address
      The IPv6 link-local address associated with this interface.  May
      be learned through auto-configuration.

   Area ID
      The OSPF area to which the attached link belongs.

   Instance ID
      The OSPF protocol instance associated with this OSPF interface.
      Defaults to 0.

   Interface ID
      32-bit number uniquely identifying this interface among the
      collection of this router's interfaces. For example, in some
      implementations it may be possible to use the MIB-II IfIndex
      ([Ref3]).

   IPv6 prefixes
      The list of IPv6 prefixes to associate with the link. These will
      be advertised in intra-area-prefix-LSAs.

Top      Up      ToC       Page 76 
   Interface output cost(s)
      The cost of sending a packet on the interface, expressed in the
      link state metric.  This is advertised as the link cost for this
      interface in the router's router-LSA. The interface output cost
      must always be greater than 0.

   RxmtInterval
      The number of seconds between LSA retransmissions, for adjacencies
      belonging to this interface.  Also used when retransmitting
      Database Description and Link State Request Packets.  This should
      be well over the expected round-trip delay between any two routers
      on the attached link.  The setting of this value should be
      conservative or needless retransmissions will result.  Sample
      value for a local area network: 5 seconds.

   InfTransDelay
      The estimated number of seconds it takes to transmit a Link State
      Update Packet over this interface.  LSAs contained in the update
      packet must have their age incremented by this amount before
      transmission.  This value should take into account the
      transmission and propagation delays of the interface. It must be
      greater than 0.  Sample value for a local area network: 1 second.

   Router Priority
      An 8-bit unsigned integer. When two routers attached to a network
      both attempt to become Designated Router, the one with the highest
      Router Priority takes precedence. If there is still a tie, the
      router with the highest Router ID takes precedence.  A router
      whose Router Priority is set to 0 is ineligible to become
      Designated Router on the attached link.  Router Priority is only
      configured for interfaces to broadcast and NBMA networks.

   HelloInterval
      The length of time, in seconds, between the Hello Packets that the
      router sends on the interface.  This value is advertised in the
      router's Hello Packets.  It must be the same for all routers
      attached to a common link.  The smaller the HelloInterval, the
      faster topological changes will be detected; however, more OSPF
      routing protocol traffic will ensue.  Sample value for a X.25 PDN:
      30 seconds.  Sample value for a local area network (LAN): 10
      seconds.

   RouterDeadInterval
      After ceasing to hear a router's Hello Packets, the number of
      seconds before its neighbors declare the router down.  This is
      also advertised in the router's Hello Packets in their

Top      Up      ToC       Page 77 
      RouterDeadInterval field.  This should be some multiple of the
      HelloInterval (say 4).  This value again must be the same for all
      routers attached to a common link.

C.4 Virtual link parameters

   Virtual links are used to restore/increase connectivity of the
   backbone.  Virtual links may be configured between any pair of area
   border routers having interfaces to a common (non-backbone) area.
   The virtual link appears as an unnumbered point-to-point link in the
   graph for the backbone.  The virtual link must be configured in both
   of the area border routers.

   A virtual link appears in router-LSAs (for the backbone) as if it
   were a separate router interface to the backbone.  As such, it has
   most of the parameters associated with a router interface (see
   Section C.3).  Virtual links do not have link-local addresses, but
   instead use one of the router's global-scope or site-local IPv6
   addresses as the IP source in OSPF protocol packets it sends along
   the virtual link.  Router Priority is not used on virtual links.
   Interface output cost is not configured on virtual links, but is
   dynamically set to be the cost of the intra-area path between the two
   endpoint routers.  The parameter RxmtInterval must be configured, and
   should be well over the expected round-trip delay between the two
   routers.  This may be hard to estimate for a virtual link; it is
   better to err on the side of making it too large.

   A virtual link is defined by the following two configurable
   parameters: the Router ID of the virtual link's other endpoint, and
   the (non-backbone) area through which the virtual link runs (referred
   to as the virtual link's Transit area).  Virtual links cannot be
   configured through stub areas.

C.5 NBMA network parameters

   OSPF treats an NBMA network much like it treats a broadcast network.
   Since there may be many routers attached to the network, a Designated
   Router is selected for the network.  This Designated Router then
   originates a network-LSA, which lists all routers attached to the
   NBMA network.

   However, due to the lack of broadcast capabilities, it may be
   necessary to use configuration parameters in the Designated Router
   selection.  These parameters will only need to be configured in those
   routers that are themselves eligible to become Designated Router
   (i.e., those router's whose Router Priority for the network is non-
   zero), and then only if no automatic procedure for discovering
   neighbors exists:

Top      Up      ToC       Page 78 
   List of all other attached routers
      The list of all other routers attached to the NBMA network.  Each
      router is configured with its Router ID and IPv6 link-local
      address on the network.  Also, for each router listed, that
      router's eligibility to become Designated Router must be defined.
      When an interface to a NBMA network comes up, the router sends
      Hello Packets only to those neighbors eligible to become
      Designated Router, until the identity of the Designated Router is
      discovered.

   PollInterval If a neighboring router has become inactive (Hello
      Packets have not been seen for RouterDeadInterval seconds), it may
      still be necessary to send Hello Packets to the dead neighbor.
      These Hello Packets will be sent at the reduced rate PollInterval,
      which should be much larger than HelloInterval.  Sample value for
      a PDN X.25 network: 2 minutes.

C.6 Point-to-MultiPoint network parameters

   On Point-to-MultiPoint networks, it may be necessary to configure the
   set of neighbors that are directly reachable over the Point-to-
   MultiPoint network. Each neighbor is configured with its Router ID
   and IPv6 link-local address on the network.  Designated Routers are
   not elected on Point-to-MultiPoint networks, so the Designated Router
   eligibility of configured neighbors is undefined.

C.7 Host route parameters

   Host prefixes are advertised in intra-area-prefix-LSAs.  They
   indicate either internal router addresses, router interfaces to
   point-to-point networks, looped router interfaces, or IPv6 hosts that
   are directly connected to the router (e.g., via a PPP connection).
   For each host directly connected to the router, the following items
   must be configured:

   Host IPv6 prefix
      The IPv6 prefix belonging to the host.

   Cost of link to host
      The cost of sending a packet to the host, in terms of the link
      state metric. However, since the host probably has only a single
      connection to the internet, the actual configured cost(s) in many
      cases is unimportant (i.e., will have no effect on routing).

   Area ID
      The OSPF area to which the host's prefix belongs.

Top      Up      ToC       Page 79 
Security Considerations

   When running over IPv6, OSPF relies on the IP Authentication Header
   (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20])
   to ensure integrity and authentication/confidentiality of routing
   exchanges.

   Most OSPF implementations will be running on systems that support
   multiple protocols, many of them having independent security
   assumptions and domains.  When IPSEC is used to protect OSPF packets,
   it is important for the implementation to check the IPSEC SA, and
   local SA database to make sure that the packet originates from a
   source THAT IS TRUSTED FOR OSPF PURPOSES.

Authors' Addresses

   Rob Coltun
   Siara Systems
   300 Ferguson Drive
   Mountain View, CA 94043

   Phone: (650) 390-9030
   EMail: rcoltun@siara.com


   Dennis Ferguson
   Juniper Networks
   385 Ravendale Drive
   Mountain View, CA  94043

   Phone: +1 650 526 8004
   EMail: dennis@juniper.com


   John Moy
   Sycamore Networks, Inc.
   10 Elizabeth Drive
   Chelmsford, MA 01824

   Phone: (978) 367-2161
   Fax:   (978) 250-3350
   EMail: jmoy@sycamorenet.com

Top      Up      ToC       Page 80 
Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.