Network Working Group                                          R. Coltun
Internet-Draft                                            Touch Acoustra
Expires: December 3, 2006                                    D. Ferguson
                                                        Juniper Networks
                                                                  J. Moy
                                                  Sycamore Networks, Inc
                                                      A. Lindem (Editor)
                                                      Cisco Systems, Inc
                                                               June 2006


                             OSPF for IPv6
                  draft-ietf-ospf-ospfv3-update-09.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 3, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the modifications to OSPF to support version
   6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
   OSPF (flooding, DR election, area support, SPF calculations, etc.)



Coltun, et al.          Expires December 3, 2006                [Page 1]


Internet-Draft                OSPF for IPv6                    June 2006


   remain unchanged.  However, some changes have been necessary, either
   due to changes in protocol semantics between IPv4 and IPv6, or simply
   to handle the increased address size of IPv6.

   Changes between OSPF for IPv4 and this document include the
   following.  Addressing semantics have been removed from OSPF packets
   and the basic LSAs.  New LSAs have been created to carry IPv6
   addresses and prefixes.  OSPF now runs on a per-link basis rather
   than on a per-IP-subnet basis.  Flooding scope for LSAs has been
   generalized.  Authentication has been removed from the OSPF protocol
   and instead relies on IPv6's Authentication Header and Encapsulating
   Security Payload.

   Even with larger IPv6 packet, most packets in OSPF for IPv6 are
   almost as compact as those in OSPF for IPv4.  Most fields and packet-
   size limitations present in OSPF for IPv4 have been relaxed.  In
   addition, option handling has been made more flexible.

   All of OSPF for IPv4's optional capabilities, including demand
   circuit support, NSSA areas, and the multicast extensions to OSPF
   (MOSPF) are also supported in OSPF for IPv6.






























Coltun, et al.          Expires December 3, 2006                [Page 2]


Internet-Draft                OSPF for IPv6                    June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
     1.1   Requirements notation  . . . . . . . . . . . . . . . . . .  6
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Differences from OSPF for IPv4 . . . . . . . . . . . . . . . .  7
     2.1   Protocol processing per-link, not per-subnet . . . . . . .  7
     2.2   Removal of addressing semantics  . . . . . . . . . . . . .  7
     2.3   Addition of Flooding scope . . . . . . . . . . . . . . . .  8
     2.4   Explicit support for multiple instances per link . . . . .  8
     2.5   Use of link-local addresses  . . . . . . . . . . . . . . .  8
     2.6   Authentication changes . . . . . . . . . . . . . . . . . .  9
     2.7   Packet format changes  . . . . . . . . . . . . . . . . . .  9
     2.8   LSA format changes . . . . . . . . . . . . . . . . . . . . 10
     2.9   Handling unknown LSA types . . . . . . . . . . . . . . . . 12
     2.10  Stub/NSSA area support . . . . . . . . . . . . . . . . . . 12
     2.11  Identifying neighbors by Router ID . . . . . . . . . . . . 13
   3.  Implementation details . . . . . . . . . . . . . . . . . . . . 14
     3.1   Protocol data structures . . . . . . . . . . . . . . . . . 15
       3.1.1   The Area Data structure  . . . . . . . . . . . . . . . 15
       3.1.2   The Interface Data structure . . . . . . . . . . . . . 16
       3.1.3   The Neighbor Data Structure  . . . . . . . . . . . . . 17
     3.2   Protocol Packet Processing . . . . . . . . . . . . . . . . 18
       3.2.1   Sending protocol packets . . . . . . . . . . . . . . . 18
         3.2.1.1   Sending Hello packets  . . . . . . . . . . . . . . 19
         3.2.1.2   Sending Database Description Packets . . . . . . . 20
       3.2.2   Receiving protocol packets . . . . . . . . . . . . . . 20
         3.2.2.1   Receiving Hello Packets  . . . . . . . . . . . . . 22
     3.3   The Routing table Structure  . . . . . . . . . . . . . . . 23
       3.3.1   Routing table lookup . . . . . . . . . . . . . . . . . 24
     3.4   Link State Advertisements  . . . . . . . . . . . . . . . . 24
       3.4.1   The LSA Header . . . . . . . . . . . . . . . . . . . . 24
       3.4.2   The link-state database  . . . . . . . . . . . . . . . 25
       3.4.3   Originating LSAs . . . . . . . . . . . . . . . . . . . 25
         3.4.3.1   LSA Options  . . . . . . . . . . . . . . . . . . . 28
         3.4.3.2   Router-LSAs  . . . . . . . . . . . . . . . . . . . 28
         3.4.3.3   Network-LSAs . . . . . . . . . . . . . . . . . . . 30
         3.4.3.4   Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 31
         3.4.3.5   Inter-Area-Router-LSAs . . . . . . . . . . . . . . 32
         3.4.3.6   AS-external-LSAs . . . . . . . . . . . . . . . . . 33
         3.4.3.7   Link-LSAs  . . . . . . . . . . . . . . . . . . . . 34
         3.4.3.8   Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
     3.5   Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 39
       3.5.1   Receiving Link State Update packets  . . . . . . . . . 39
       3.5.2   Sending Link State Update packets  . . . . . . . . . . 40
       3.5.3   Installing LSAs in the database  . . . . . . . . . . . 42
     3.6   Definition of self-originated LSAs . . . . . . . . . . . . 42
     3.7   Virtual links  . . . . . . . . . . . . . . . . . . . . . . 43



Coltun, et al.          Expires December 3, 2006                [Page 3]


Internet-Draft                OSPF for IPv6                    June 2006


     3.8   Routing table calculation  . . . . . . . . . . . . . . . . 43
       3.8.1   Calculating the shortest path tree for an area . . . . 44
       3.8.2   The next hop calculation . . . . . . . . . . . . . . . 45
       3.8.3   Calculating the inter-area routes  . . . . . . . . . . 46
       3.8.4   Examining transit areas' summary-LSAs  . . . . . . . . 46
       3.8.5   Calculating AS external routes . . . . . . . . . . . . 46
     3.9   Multiple interfaces to a single link . . . . . . . . . . . 47
       3.9.1   Standby Interface State  . . . . . . . . . . . . . . . 49
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 51
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 52
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 53
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 54
     7.2   Informative References . . . . . . . . . . . . . . . . . . 55
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55
   A.  OSPF data formats  . . . . . . . . . . . . . . . . . . . . . . 57
     A.1   Encapsulation of OSPF packets  . . . . . . . . . . . . . . 57
     A.2   The Options field  . . . . . . . . . . . . . . . . . . . . 58
     A.3   OSPF Packet Formats  . . . . . . . . . . . . . . . . . . . 59
       A.3.1   The OSPF packet header . . . . . . . . . . . . . . . . 60
       A.3.2   The Hello packet . . . . . . . . . . . . . . . . . . . 61
       A.3.3   The Database Description packet  . . . . . . . . . . . 63
       A.3.4   The Link State Request packet  . . . . . . . . . . . . 65
       A.3.5   The Link State Update packet . . . . . . . . . . . . . 66
       A.3.6   The Link State Acknowledgment packet . . . . . . . . . 67
     A.4   LSA formats  . . . . . . . . . . . . . . . . . . . . . . . 68
       A.4.1   IPv6 Prefix Representation . . . . . . . . . . . . . . 69
         A.4.1.1   Prefix Options . . . . . . . . . . . . . . . . . . 69
       A.4.2   The LSA header . . . . . . . . . . . . . . . . . . . . 70
         A.4.2.1   LSA Type . . . . . . . . . . . . . . . . . . . . . 71
       A.4.3   Router-LSAs  . . . . . . . . . . . . . . . . . . . . . 72
       A.4.4   Network-LSAs . . . . . . . . . . . . . . . . . . . . . 75
       A.4.5   Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 76
       A.4.6   Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 77
       A.4.7   AS-external-LSAs . . . . . . . . . . . . . . . . . . . 78
       A.4.8   NSSA-LSAs  . . . . . . . . . . . . . . . . . . . . . . 81
       A.4.9   Link-LSAs  . . . . . . . . . . . . . . . . . . . . . . 81
       A.4.10  Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 83
   B.  Architectural Constants  . . . . . . . . . . . . . . . . . . . 86
   C.  Configurable Constants . . . . . . . . . . . . . . . . . . . . 87
     C.1   Global parameters  . . . . . . . . . . . . . . . . . . . . 87
     C.2   Area parameters  . . . . . . . . . . . . . . . . . . . . . 87
     C.3   Router interface parameters  . . . . . . . . . . . . . . . 89
     C.4   Virtual link parameters  . . . . . . . . . . . . . . . . . 90
     C.5   NBMA network parameters  . . . . . . . . . . . . . . . . . 91
     C.6   Point-to-Multipoint network parameters . . . . . . . . . . 92
     C.7   Host route parameters  . . . . . . . . . . . . . . . . . . 92
   D.  Stub Area Unknown LSA Flooding Restriction Deprecated  . . . . 93



Coltun, et al.          Expires December 3, 2006                [Page 4]


Internet-Draft                OSPF for IPv6                    June 2006


   E.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 94
     E.1   Changes from RFC 2740 to 00 Version  . . . . . . . . . . . 94
     E.2   Changes from the 00 Version to the 01 Version  . . . . . . 94
     E.3   Changes from the 01 Version to the 02 Version  . . . . . . 95
     E.4   Changes from the 02 Version to the 03 Version  . . . . . . 95
     E.5   Changes from the 03 Version to the 04 Version  . . . . . . 95
     E.6   Changes from the 04 Version to the 05 Version  . . . . . . 96
     E.7   Changes from the 05 Version to the 06 Version  . . . . . . 96
     E.8   Changes from the 06 Version to the 07 Version  . . . . . . 96
     E.9   Changes from the 07 Version to the 08 Version  . . . . . . 97
     E.10  Changes from the 08 Version to the 09 Version  . . . . . . 97
       Intellectual Property and Copyright Statements . . . . . . . . 98







































Coltun, et al.          Expires December 3, 2006                [Page 5]


Internet-Draft                OSPF for IPv6                    June 2006


1.  Introduction

   This document describes the modifications to OSPF to support version
   6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
   OSPF (flooding, DR election, area support, SPF calculations, etc.)
   remain unchanged.  However, some changes have been necessary, either
   due to changes in protocol semantics between IPv4 and IPv6, or simply
   to handle the increased address size of IPv6.

   This document is organized as follows.  Section 2 describes the
   differences between OSPF for IPv4 and OSPF for IPv6 in detail.
   Section 3 provides implementation details for the changes.  Appendix
   A gives the OSPF for IPv6 packet and LSA formats.  Appendix B lists
   the OSPF architectural constants.  Appendix C describes configuration
   parameters.

1.1  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

1.2  Terminology

   This document attempts to use terms from both the OSPF for IPv4
   specification ([OSPFV2]) and the IPv6 protocol specifications
   ([IPV6]).  This has produced a mixed result.  Most of the terms used
   both by OSPF and IPv6 have roughly the same meaning (e.g.,
   interfaces).  However, there are a few conflicts.  IPv6 uses "link"
   similarly to IPv4 OSPF's "subnet" or "network".  In this case, we
   have chosen to use IPv6's "link" terminology.  "Link" replaces OSPF's
   "subnet" and "network" in most places in this document, although
   OSPF's network-LSA remains unchanged (and possibly unfortunately, a
   new link-LSA has also been created).

   The names of some of the OSPF LSAs have also changed.  See
   Section 2.8 for details.

   In the context of this document, an OSPF instance is a separate
   protocol instance complete with its own protocol data structures
   (e.g., areas, interfaces, neighbors), link state database, protocol
   state machines, and protocol processes (e.g.  SPF calculation).









Coltun, et al.          Expires December 3, 2006                [Page 6]


Internet-Draft                OSPF for IPv6                    June 2006


2.  Differences from OSPF for IPv4

   Most of the algorithms from OSPF for IPv4 [OSPFV2] have been
   preserved in OSPF for IPv6.  However, some changes have been
   necessary, either due to changes in protocol semantics between IPv4
   and IPv6, or simply to handle the increased address size of IPv6.

   The following subsections describe the differences between this
   document and [OSPFV2].

2.1  Protocol processing per-link, not per-subnet

   IPv6 uses the term "link" to indicate "a communication facility or
   medium over which nodes can communicate at the link layer" ([IPV6]).
   "Interfaces" connect to links.  Multiple IP subnets can be assigned
   to a single link, and two nodes can talk directly over a single link,
   even if they do not share a common IP subnet (IPv6 prefix).

   For this reason, OSPF for IPv6 runs per-link instead of the IPv4
   behavior of per-IP-subnet.  The terms "network" and "subnet" used in
   the IPv4 OSPF specification ([OSPFV2]) should generally be replaced
   by link.  Likewise, an OSPF interface now connects to a link instead
   of an IP subnet.

   This change affects the receiving of OSPF protocol packets, the
   contents of Hello Packets, and the contents of network-LSAs.

2.2  Removal of addressing semantics

   In OSPF for IPv6, addressing semantics have been removed from the
   OSPF protocol packets and the main LSA types, leaving a network-
   protocol-independent core.  In particular:


   o  IPv6 Addresses are not present in OSPF packets, except in LSA
      payloads carried by the Link State Update Packets.  See
      Section 2.7 for details.

   o  Router-LSAs and network-LSAs no longer contain network addresses,
      but simply express topology information.  See Section 2.8 for
      details.

   o  OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the
      IPv4 size of 32-bits.  They can no longer be assigned as (IPv6)
      addresses.

   o  Neighboring routers are now always identified by Router ID.
      Previously, they had been identified by IP address on broadcast



Coltun, et al.          Expires December 3, 2006                [Page 7]


Internet-Draft                OSPF for IPv6                    June 2006


      and NBMA networks.


2.3  Addition of Flooding scope

   Flooding scope for LSAs has been generalized and is now explicitly
   coded in the LSA's LS type field.  There are now three separate
   flooding scopes for LSAs:


   o  Link-local scope.  LSA is only flooded on the local link, and no
      further.  Used for the new link-LSA.  See Section 3.4.3.7 for
      details.

   o  Area scope.  LSA is only flooded throughout a single OSPF area.
      Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-
      area-router-LSAs, and intra-area-prefix-LSAs.

   o  AS scope.  LSA is flooded throughout the routing domain.  Used for
      AS-external-LSAs.


2.4  Explicit support for multiple instances per link

   OSPF now supports the ability to run multiple OSPF protocol instances
   on a single link.  For example, this may be required on a NAP segment
   shared between several providers.  Providers may be running separate
   OSPF routing domains that want to remain separate even though they
   have one or more physical network segments (i.e., links) in common.
   In OSPF for IPv4 this was supported in a haphazard fashion using the
   authentication fields in the OSPF for IPv4 header.

   Another use for running multiple OSPF instances is if you want, for
   one reason or another, to have a single link belong to two or more
   OSPF areas.

   Support for multiple protocol instances on a link is accomplished via
   an "Instance ID" contained in the OSPF packet header and OSPF
   interface data structures.  Instance ID solely affects the reception
   of OSPF packets and applies to normal OSPF interfaces and virtual
   links.

2.5  Use of link-local addresses

   IPv6 link-local addresses are for use on a single link, for purposes
   of neighbor discovery, auto-configuration, etc.  IPv6 routers do not
   forward IPv6 datagrams having link-local source addresses [IP6ADDR].
   Link-local unicast addresses are assigned from the IPv6 address range



Coltun, et al.          Expires December 3, 2006                [Page 8]


Internet-Draft                OSPF for IPv6                    June 2006


   FE80/10.

   OSPF for IPv6 assumes that each router has been assigned link-local
   unicast addresses on each of the router's attached physical links
   [IP6ADDR].  On all OSPF interfaces except virtual links, OSPF packets
   are sent using the interface's associated link-local unicast address
   as the source address.  A router learns the link-local addresses of
   all other routers attached to its links, and uses these addresses as
   next hop information during packet forwarding.

   On virtual links, a global scope IPv6 address MUST be used as the
   source address for OSPF protocol packets.

   Link-local addresses appear in OSPF link-LSAs (see Section 3.4.3.7).
   However, link-local addresses are not allowed in other OSPF LSA
   types.  In particular, link-local addresses MUST NOT be advertised in
   inter-area-prefix-LSAs (Section 3.4.3.4), AS-external-LSAs
   (Section 3.4.3.6), or intra-area-prefix-LSAs (Section 3.4.3.8).

2.6  Authentication changes

   In OSPF for IPv6, authentication has been removed from the OSPF
   protocol.  The "AuType" and "Authentication" fields have been removed
   from the OSPF packet header, and all authentication related fields
   have been removed from the OSPF area and interface data structures.

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

   Protection of OSPF packet exchanges against accidental data
   corruption is provided by the standard IPv6 16-bit one's complement
   checksum, covering the entire OSPF packet and prepended IPv6 pseudo-
   header (see Appendix A.3.1).

2.7  Packet format changes

   OSPF for IPv6 runs directly over IPv6.  Aside from this, all
   addressing semantics have been removed from the OSPF packet headers,
   making it essentially "network-protocol-independent".  All addressing
   information is now contained in the various LSA types only.

   In detail, changes in OSPF packet format consist of the following:


   o  The OSPF version number has been increased from 2 to 3.




Coltun, et al.          Expires December 3, 2006                [Page 9]


Internet-Draft                OSPF for IPv6                    June 2006


   o  The Options field in Hello Packets and Database description Packet
      has been expanded to 24-bits.

   o  The Authentication and AuType fields have been removed from the
      OSPF packet header (see Section 2.6)

   o  The Hello packet now contains no address information at all, and
      includes an Interface ID which the originating router has assigned
      to uniquely identify (among its own interfaces) its interface to
      the link.  This Interface ID will be used as the network-LSA's
      Link State ID if the router becomes Designated-Router on the link.

   o  Two option bits, the "R-bit" and the "V6-bit", have been added to
      the Options field for processing router-LSAs during the SPF
      calculation (see Appendix A.2).  If the "R-bit" is clear an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward transit traffic; this can be used in multi-
      homed hosts that want to participate in the routing protocol.  The
      V6-bit specializes the R-bit; if the V6-bit is clear an OSPF
      speaker can participate in OSPF topology distribution without
      being used to forward IPv6 datagrams.  If the R-bit is set and the
      V6-bit is clear, IPv6 datagrams are not forwarded but datagrams
      belonging to another protocol family may be forwarded.

   o  The OSPF packet header now includes an "Instance ID" which allows
      multiple OSPF protocol instances to be run on a single link (see
      Section 2.4).


2.8  LSA format changes

   All addressing semantics have been removed from the LSA header,
   router-LSAs, and network-LSAs.  These two LSAs now describe the
   routing domain's topology in a network-protocol-independent manner.
   New LSAs have been added to distribute IPv6 address information and
   data required for next hop resolution.  The names of some of IPv4's
   LSAs have been changed to be more consistent with each other.

   In detail, changes in LSA format consist of the following:


   o  The Options field has been removed from the LSA header, expanded
      to 24 bits, and moved into the body of router-LSAs, network-LSAs,
      inter-area-router-LSAs, and link-LSAs.  See Appendix A.2 for
      details.

   o  The LSA Type field has been expanded (into the former Options
      space) to 16 bits, with the upper three bits encoding flooding



Coltun, et al.          Expires December 3, 2006               [Page 10]


Internet-Draft                OSPF for IPv6                    June 2006


      scope and the handling of unknown LSA types (see Section 2.9).

   o  Addresses in LSAs are now expressed as [prefix, prefix length]
      instead of [address, mask] (see Appendix A.4.1).  The default
      route is expressed as a prefix with length 0.

   o  Router-LSAs and Network-LSAs now have no address information and
      are network protocol independent.

   o  Router interface information MAY be spread across multiple Router
      LSAs.  Receivers MUST concatenate all the router-LSAs originated
      by a given router when running the SPF calculation.

   o  A new LSA called the link-LSA has been introduced.  Link-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, 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.  See Section 3.4.3.7 for details.

   o  In IPv4, the router-LSA carries a router's IPv4 interface
      addresses, the IPv4 equivalent of link-local addresses.  These are
      only used when calculating next hops during the OSPF routing
      calculation (see Section 16.1.1 of [OSPFV2]), so they do not need
      to be flooded past the local link.  Hence, using link-LSAs to
      distribute these addresses is more efficient.  Note that link-
      local addresses cannot be learned through the reception of Hellos
      in all cases.  On NBMA links, next hop routers do not necessarily
      exchange hellos, but rather learn of each other's existence by way
      of the Designated Router.

   o  The Options field in the Network LSA is set to the logical OR of
      the Options that each router on the link advertises in its link-
      LSA.

   o  Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs".
      Type-4 summary LSAs have been renamed "inter-area-router-LSAs".

   o  The Link State ID in inter-area-prefix-LSAs, inter-area-router-
      LSAs, and AS-external-LSAs, has lost its addressing semantics and
      now serves solely to identify individual pieces of the Link State
      Database.  All addresses or Router IDs that were formerly
      expressed by the Link State ID are now carried in the LSA bodies.





Coltun, et al.          Expires December 3, 2006               [Page 11]


Internet-Draft                OSPF for IPv6                    June 2006


   o  Network-LSAs and link-LSAs are the only LSAs whose Link State ID
      carries additional meaning.  For these LSAs, the Link State ID is
      always the Interface ID of the originating router on the link
      being described.  For this reason, network-LSAs and link-LSAs are
      now the only LSAs whose size cannot be limited: a network-LSA MUST
      list all routers connected to the link and a link-LSA MUST list
      all of a router's addresses on the link.

   o  A new LSA called the intra-area-prefix-LSA has been introduced.
      This LSA carries all IPv6 prefix information that in IPv4 is
      included in router-LSAs and network-LSAs.  See Section 3.4.3.8 for
      details.

   o  Inclusion of a forwarding address or external route tag (see
      [EXTTAG]) in AS-external-LSAs is now optional.  In addition, AS-
      external-LSAs can now reference another LSA, for inclusion of
      additional route attributes that are outside the scope of the OSPF
      protocol.  For example, this could be used to attach BGP path
      attributes to external routes.


2.9  Handling unknown LSA types

   Handling of unknown LSA types has been made more flexible so that,
   based on LS type, unknown LSA types are either treated as having
   link-local flooding scope, or are stored and flooded as if they were
   understood.  This behavior is explicitly coded in the LSA Handling
   bit of the link state header's LS type field (see the U-bit in
   Appendix A.4.2.1).

   The IPv4 OSPF behavior of simply discarding unknown types is
   unsupported due to the desire to mix router capabilities on a single
   link.  Discarding unknown types causes problems when the Designated
   Router supports fewer options than the other routers on the link.

2.10  Stub/NSSA area support

   In OSPF for IPv4, stub and NSSA areas were designed to minimize link-
   state database and routing table sizes for the areas' internal
   routers.  This allows routers with minimal resources to participate
   in even very large OSPF routing domains.

   In OSPF for IPv6, the concept of stub and NSSA areas is retained.  In
   IPv6, of the mandatory LSA types, stub areas carry only router-LSAs,
   network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-
   prefix-LSAs.  NSSA areas are restricted to these types and, of
   course, NSSA-LSAs.  This is the IPv6 equivalent of the LSA types
   carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3



Coltun, et al.          Expires December 3, 2006               [Page 12]


Internet-Draft                OSPF for IPv6                    June 2006


   summary-LSAs and for NSSA areas: NSSA-LSAs.

2.11  Identifying neighbors by Router ID

   In OSPF for IPv6, neighboring routers on a given link are always
   identified by their OSPF Router ID.  This contrasts with the IPv4
   behavior where neighbors on point-to-point networks and virtual links
   are identified by their Router IDs while neighbors on broadcast,
   NBMA, and Point-to-Multipoint links are identified by their IPv4
   interface addresses.

   This change affects the reception of OSPF packets (see Section 8.2 of
   [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]) and the
   reception of Hello Packets (Section 10.5 of [OSPFV2]).

   The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.



































Coltun, et al.          Expires December 3, 2006               [Page 13]


Internet-Draft                OSPF for IPv6                    June 2006


3.  Implementation details

   When going from IPv4 to IPv6, the basic OSPF mechanisms remain
   unchanged from those documented in [OSPFV2].  These mechanisms are
   briefly outlined in Section 4 of [OSPFV2].  Both IPv6 and IPv4 have a
   link-state database composed of LSAs and synchronized between
   adjacent routers.  Initial synchronization is performed through the
   Database Exchange process, which includes the exchange of Database
   Description, Link State Request, and Link State Update packets.
   Thereafter database synchronization is maintained via flooding,
   utilizing Link State Update and Link State Acknowledgment packets.
   Both IPv6 and IPv4 use OSPF Hello Packets to discover and maintain
   neighbor relationships, as well as to elect Designated Routers and
   Backup Designated Routers on broadcast and NBMA links.  The decision
   as to which neighbor relationships become adjacencies, along with the
   basic ideas behind inter-area routing, importing external information
   in AS-external-LSAs, and the various routing calculations are also
   the same.

   In particular, the following IPv4 OSPF functionality described in
   [OSPFV2] remains completely unchanged for IPv6:


   o  Both IPv4 and IPv6 use OSPF packet types described in Section 4.3
      of [OSPFV2], namely: Hello, Database Description, Link State
      Request, Link State Update, and Link State Acknowledgment packets.
      While in some cases (e.g., Hello packets) their format has changed
      somewhat, the functions of the various packet types remain the
      same.

   o  The system requirements for an OSPF implementation remain
      unchanged, although OSPF for IPv6 requires an IPv6 protocol stack
      (from the network layer on down) since it runs directly over the
      IPv6 network layer.

   o  The discovery and maintenance of neighbor relationships, and the
      selection and establishment of adjacencies remain the same.  This
      includes election of the Designated Router and Backup Designated
      Router on broadcast and NBMA links.  These mechanisms are
      described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].

   o  The link types (or equivalently, interface types) supported by
      OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
      Point-to-Multipoint, and virtual links.

   o  The interface state machine, including the list of OSPF interface
      states and events, and the Designated Router and Backup Designated
      Router election algorithm, remain unchanged.  These are described



Coltun, et al.          Expires December 3, 2006               [Page 14]


Internet-Draft                OSPF for IPv6                    June 2006


      in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].

   o  The neighbor state machine, including the list of OSPF neighbor
      states and events, remain unchanged.  These are described in
      Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].

   o  Aging of the link-state database, as well as flushing LSAs from
      the routing domain through the premature aging process, remains
      unchanged from the description in Sections 14 and 14.1 of
      [OSPFV2].

   However, some OSPF protocol mechanisms have changed, as outlined in
   Section 2 above.  These changes are explained in detail in the
   following subsections, making references to the appropriate sections
   of [OSPFV2].

   The following subsections provide a recipe for turning an IPv4 OSPF
   implementation into an IPv6 OSPF implementation.

3.1  Protocol data structures

   The major OSPF data structures are the same for both IPv4 and IPv6:
   areas, interfaces, neighbors, the link-state database, and the
   routing table.  The top-level data structures for IPv6 remain those
   listed in Section 5 of [OSPFV2], with the following modifications:


   o  All LSAs with known LS type and AS flooding scope appear in the
      top-level data structure, instead of belonging to a specific area
      or link.  AS-external-LSAs are the only LSAs defined by this
      specification that have AS flooding scope.  LSAs with unknown LS
      type, U-bit set to 1 (flood even when unrecognized), and AS
      flooding scope also appear in the top-level data structure.


3.1.1  The Area Data structure

   The IPv6 area data structure contains all elements defined for IPv4
   areas in Section 6 of [OSPFV2].  In addition, all LSAs of known type
   which have area flooding scope are contained in the IPv6 area data
   structure.  This always includes the following LSA types: router-
   LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs,
   and intra-area-prefix-LSAs.  LSAs with unknown LS type, U-bit set to
   1 (flood even when unrecognized) and area scope also appear in the
   area data structure.  IPv6 routers implementing MOSPF add group-
   membership-LSAs to the area data structure.  NSSA-LSAs belong to an
   NSSA area's data structure.




Coltun, et al.          Expires December 3, 2006               [Page 15]


Internet-Draft                OSPF for IPv6                    June 2006


3.1.2  The Interface Data structure

   In OSPF for IPv6, an interface connects a router to a link.  The IPv6
   interface structure modifies the IPv4 interface structure (as defined
   in Section 9 of [OSPFV2]) as follows:


   Interface ID
      Every interface is assigned an Interface ID, which uniquely
      identifies the interface with the router.  For example, some
      implementations MAY be able to use the MIB-II IfIndex ([INTFMIB])
      as Interface ID.  The Interface ID appears in Hello packets sent
      out the interface, the link-local-LSA originated by router for the
      attached link, and the router-LSA originated by the router-LSA for
      the associated area.  It will also serve as the Link State ID for
      the network-LSA that the router will originate for the link if the
      router is elected Designated Router.

   Instance ID
      Every interface is assigned an Instance ID.  This should default
      to 0 and is only necessary to assign differently on those links
      that will contain multiple separate communities of OSPF Routers.
      For example, suppose that there are two communities of routers on
      a given ethernet segment that you wish to keep separate.
      The first community is assigned an Instance ID of 0 and all the
      routers in the first community will be assigned 0 as the Instance
      ID for interfaces to the ethernet.  An Instance ID of 1 is
      assigned to the other routers' interfaces to the ethernet.  The
      OSPF transmit and receive processing (see Section 3.2) will then
      keep the two communities separate.
      The instance ID for a virtual link is independent of the instance
      ID of the outgoing interface it uses in the transit area and is
      configurable.

   List of LSAs with link-local scope
      All LSAs with link-local scope and which were originated/flooded
      on the link belong to the interface structure that connects to the
      link.  This includes the collection of the link's link-LSAs.

   IP interface address
      For IPv6, the IPv6 address appearing in the source of OSPF packets
      sent out the interface is almost always a link-local address.  The
      one exception is for virtual links which MUST use one of the
      router's own global IPv6 addresses as IP interface address.







Coltun, et al.          Expires December 3, 2006               [Page 16]


Internet-Draft                OSPF for IPv6                    June 2006


   List of link prefixes
      A list of IPv6 prefixes can be configured for the attached link.
      These will be advertised by the router in link-LSAs, so that they
      can be advertised by the link's Designated Router in intra-area-
      prefix-LSAs.

   In OSPF for IPv6, each router interface has a single metric
   representing the cost of sending packets out the interface.  In
   addition, OSPF for IPv6 relies on the IP Authentication Header (see
   [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to
   ensure integrity and authentication/confidentiality of routing
   exchanges.  For that reason, AuType and Authentication key are not
   associated with IPv6 OSPF interfaces.

   Interface states, events, and the interface state machine remain
   unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of
   [OSPFV2] respectively.  The Designated Router and Backup Designated
   Router election algorithm also remains unchanged from the IPv4
   election in Section 9.4 of [OSPFV2].

3.1.3  The Neighbor Data Structure

   The neighbor structure performs the same function in both IPv6 and
   IPv4.  Namely, it collects all information required to form an
   adjacency between two routers, if an adjacency becomes necessary.
   Each neighbor structure is bound to a single OSPF interface.  The
   differences between the IPv6 neighbor structure and the neighbor
   structure defined for IPv4 in Section 10 of [OSPFV2] are:


   Neighbor's Interface ID
      The Interface ID that the neighbor advertises in its Hello Packets
      must be recorded in the neighbor structure.  The router will
      include the neighbor's Interface ID in the router's router-LSA
      when either a) advertising a point-to-point or point-to-multipoint
      link to the neighbor or b) advertising a link to a network where
      the neighbor has become Designated Router.

   Neighbor IP address
      Except on virtual links, the neighbor's IP address will be an IPv6
      link-local address.

   Neighbor's Designated Router
      The neighbor's choice of Designated Router is now encoded as a
      Router ID instead of as an IP address.






Coltun, et al.          Expires December 3, 2006               [Page 17]


Internet-Draft                OSPF for IPv6                    June 2006


   Neighbor's Backup Designated Router
      The neighbor's choice of Backup Designated Router is now encoded
      as a Router ID instead of as an IP address.

   Neighbor states, events, and the neighbor state machine remain
   unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of
   [OSPFV2] respectively.  The decision as to which adjacencies to form
   also remains unchanged from the IPv4 logic documented in Section 10.4
   of [OSPFV2].

3.2  Protocol Packet Processing

   OSPF for IPv6 runs directly over IPv6's network layer.  As such, it
   is encapsulated in one or more IPv6 headers with the Next Header
   field of the immediately encapsulating IPv6 header set to the value
   89.

   As for IPv4, in IPv6 OSPF routing protocol packets are sent along
   adjacencies only (with the exception of Hello packets, which are used
   to discover the adjacencies).  OSPF packet types and functions are
   the same in both IPv4 and IPv6, encoded by the Type field of the
   standard OSPF packet header.

3.2.1  Sending protocol packets

   When an IPv6 router sends an OSPF routing protocol packet, it fills
   in the fields of the standard OSPF for IPv6 packet header (see
   Appendix A.3.1) as follows:


   Version #
      Set to 3, the version number of the protocol as documented in this
      specification.

   Type
      The type of OSPF packet, such as Link state Update or Hello
      Packet.

   Packet length
      The length of the entire OSPF packet in bytes, including the
      standard OSPF packet header.

   Router ID
      The identity of the router itself (who is originating the packet).







Coltun, et al.          Expires December 3, 2006               [Page 18]


Internet-Draft                OSPF for IPv6                    June 2006


   Area ID
      The OSPF area for the interface that the packet is being sent on.

   Instance ID
      The OSPF Instance ID associated with the interface that the packet
      is being sent out of.

   Checksum
      The standard IPv6 16-bit one's complement checksum, covering the
      entire OSPF packet and prepended IPv6 pseudo-header (see
      Appendix A.3.1).

   Selection of OSPF routing protocol packets' IPv6 source and
   destination addresses is performed identically to the IPv4 logic in
   Section 8.1 of [OSPFV2].  The IPv6 destination address is chosen from
   among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP
   address associated with the other end of the adjacency (which in
   IPv6, for all links except virtual links, is an IPv6 link-local
   address).

   The sending of Link State Request Packets and Link State
   Acknowledgment Packets remains unchanged from the IPv4 procedures
   documented in Sections 10.9 and 13.5 of [OSPFV2] respectively.
   Sending Hello Packets is documented in Section 3.2.1.1, and the
   sending of Database Description Packets in Section 3.2.1.2.  The
   sending of Link State Update Packets is documented in Section 3.5.2.

3.2.1.1  Sending Hello packets

   IPv6 changes the way OSPF Hello packets are sent in the following
   ways (compare to Section 9.5 of [OSPFV2]):


   o  Before the Hello Packet is sent out an interface, the interface's
      Interface ID MUST be copied into the Hello Packet.

   o  The Hello Packet no longer contains an IP network mask, as OSPF
      for IPv6 runs per-link instead of per-subnet.

   o  The choice of Designated Router and Backup Designated Router are
      now indicated within Hellos by their Router IDs instead of by
      their IP interface addresses.  Advertising the Designated Router
      (or Backup Designated Router) as 0.0.0.0 indicates that the
      Designated Router (or Backup Designated Router) has not yet been
      chosen.

   o  The Options field within Hello packets has moved around, getting
      larger in the process.  More options bits are now possible.  Those



Coltun, et al.          Expires December 3, 2006               [Page 19]


Internet-Draft                OSPF for IPv6                    June 2006


      that MUST be set correctly in Hello packets are: The E-bit is set
      if and only if the interface attaches to a regular area, i.e., not
      a stub or NSSA area, the N-bit is set if and only if the interface
      attaches to an NSSA area (see [NSSA]), and the DC-bit is set if
      and only if the router wishes to suppress the sending of future
      Hellos over the interface (see [DEMAND]).  Unrecognized bits in
      the Hello Packet's Options field should be cleared.

   Sending Hello packets on NBMA networks proceeds for IPv6 in exactly
   the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].

3.2.1.2  Sending Database Description Packets

   The sending of Database Description packets differs from Section 10.8
   of [OSPFV2] in the following ways:


   o  The Options field within Database Description packets has moved
      around, getting larger in the process.  More options bits are now
      possible.  Those that MUST be set correctly in Database
      Description packets are: The MC-bit is set if and only if the
      router is forwarding multicast datagrams according to the MOSPF
      specification in [MOSPF], and the DC-bit is set if and only if the
      router wishes to suppress the sending of Hellos over the interface
      (see [DEMAND]).  Unrecognized bits in the Database Description
      Packet's Options field should be cleared.


3.2.2  Receiving protocol packets

   Whenever a router receives an OSPF protocol packet it is marked with
   the interface it was received on.  For routers that have virtual
   links configured, it may not be immediately obvious which interface
   to associate the packet with.  For example, consider the Router RT11
   depicted in Figure 6 of [OSPFV2].  If RT11 receives an OSPF protocol
   packet on its interface to Network N8, it may want to associate the
   packet with the interface to Area 2, or with the virtual link to
   Router RT10 (which is part of the backbone).  In the following, we
   assume that the packet is initially associated with the non-virtual
   link.

   In order for the packet to be passed to OSPF for processing, the
   following tests must be performed on the encapsulating IPv6 headers:


   o  The packet's IP destination address MUST be one of the IPv6
      unicast addresses associated with the receiving interface (this
      includes link-local addresses), or one of the IP multicast



Coltun, et al.          Expires December 3, 2006               [Page 20]


Internet-Draft                OSPF for IPv6                    June 2006


      addresses AllSPFRouters or AllDRouters.

   o  The Next Header field of the immediately encapsulating IPv6 header
      MUST specify the OSPF protocol (89).

   o  Any encapsulating IP Authentication Headers (see [IPAUTH]) and the
      IP Encapsulating Security Payloads (see [IPESP]) MUST be processed
      and/or verified to ensure integrity and authentication/
      confidentiality of OSPF routing exchanges.

   o  Locally originated packets SHOULD NOT be processed by OSPF except
      for support of multiple interfaces attached to the same link as
      described in Section 3.9.  A locally originated packet is
      identified as packet with a source address equal to one of the
      router's local addresses.

   After processing the encapsulating IPv6 headers, the OSPF packet
   header is processed.  The fields specified in the header must match
   those configured for the receiving interface.  If they do not, the
   packet SHOULD be discarded:


   o  The version number field MUST specify protocol version 3.

   o  The standard IPv6 16-bit one's complement checksum, covering the
      entire OSPF packet and prepended IPv6 pseudo-header, must be
      verified (see Appendix A.3.1).

   o  The Area ID found in the OSPF header must be verified.  If both of
      the following cases fail, the packet should be discarded.  The
      Area ID specified in the header must either:


      1.  Match the Area ID of the receiving interface.  In this case,
          unlike for IPv4, the IPv6 source address is not restricted to
          lie on the same IP subnet as the receiving interface.  IPv6
          OSPF runs per-link instead of per-IP-subnet.

      2.  Indicate the backbone.  In this case, the packet has been sent
          over a virtual link.  The receiving router must be an area
          border router, and the Router ID specified in the packet (the
          source router) must be the other end of a configured virtual
          link.  The receiving interface must also attach to the virtual
          link's configured transit area.  If all of these checks
          succeed, the packet is accepted and is from now on associated
          with the virtual link (and the backbone area).





Coltun, et al.          Expires December 3, 2006               [Page 21]


Internet-Draft                OSPF for IPv6                    June 2006


   o  The Instance ID specified in the OSPF header must match the
      receiving interface's Instance ID.

   o  Packets whose IP destination is AllDRouters should only be
      accepted if the state of the receiving interface is DR or Backup
      (see Section 9.1 [OSPFV2]).

   After header processing, the packet is further processed according to
   its OSPF packet type.  OSPF packet types and functions are the same
   for both IPv4 and IPv6.

   If the packet type is Hello, it should then be further processed by
   the Hello Protocol.  All other packet types are sent/received only on
   adjacencies.  This means that the packet must have been sent by one
   of the router's active neighbors.  The neighbor is identified by the
   Router ID appearing in the received packet's OSPF header.  Packets
   not matching any active neighbor are discarded.

   The receive processing of Database Description Packets, Link State
   Request Packets, and Link State Acknowledgment Packets is almost
   identical to the IPv4 procedures documented in Sections 10.6, 10.7,
   and 13.7 of [OSPFV2] respectively with the exceptions noted below.


   o  LSAs with unknown LS types in Database Description packets that
      have an acceptable flooding scope are processed the same as LSAs
      with known LS types.  In OSPFv2 [OSPF], these would result in the
      adjacency being brought down SequenceMismatch.

   The receiving of Hello Packets is documented in Section 3.2.2.1 and
   the receiving of Link State Update Packets is documented in
   Section 3.5.2.

3.2.2.1  Receiving Hello Packets

   The receive processing of Hello Packets differs from Section 10.5 of
   [OSPFV2] in the following ways:


   o  On all link types (e.g., broadcast, NBMA, point-to-point, etc),
      neighbors are identified solely by their OSPF Router ID.  For all
      link types except virtual links, the Neighbor IP address is set to
      the IPv6 source address in the IPv6 header of the received OSPF
      Hello packet.

   o  There is no longer a Network Mask field in the Hello Packet.





Coltun, et al.          Expires December 3, 2006               [Page 22]


Internet-Draft                OSPF for IPv6                    June 2006


   o  The neighbor's choice of Designated Router and Backup Designated
      Router is now encoded as an OSPF Router ID instead of an IP
      interface address.


3.3  The Routing table Structure

   The routing table used by OSPF for IPv4 is defined in Section 11 of
   [OSPFV2].  For IPv6 there are analogous routing table entries: there
   are routing table entries for IPv6 address prefixes and also for AS
   boundary routers.  The latter routing table entries are only used to
   hold intermediate results during the routing table build process (see
   Section 3.8).

   Also, to hold the intermediate results during the shortest-path
   calculation for each area, there is a separate routing table for each
   area holding the following entries:


   o  An entry for each router in the area.  Routers are identified by
      their OSPF router ID.  These routing table entries hold the set of
      shortest paths through a given area to a given router, which in
      turn allows calculation of paths to the IPv6 prefixes advertised
      by that router in intra-area-prefix-LSAs.  If the router is also
      an area-border router, these entries are also used to calculate
      paths for inter-area address prefixes.  If in addition the router
      is the other endpoint of a virtual link, the routing table entry
      describes the cost and viability of the virtual link.

   o  An entry for each transit link in the area.  Transit links have
      associated network-LSAs.  Both the transit link and the network-
      LSA are identified by a combination of the Designated Router's
      Interface ID on the link and the Designated Router's OSPF Router
      ID.  These routing table entries allow later calculation of paths
      to IP prefixes advertised for the transit link in intra-area-
      prefix-LSAs.

   The fields in the IPv4 OSPF routing table (see Section 11 of
   [OSPFV2]) remain valid for IPv6: Optional capabilities (routers
   only), path type, cost, type 2 cost, link state origin, and for each
   of the equal cost paths to the destination, the next hop and
   advertising router.

   For IPv6, the link-state origin field in the routing table entry is
   the router-LSA or network-LSA that has directly or indirectly
   produced the routing table entry.  For example, if the routing table
   entry describes a route to an IPv6 prefix, the link state origin is
   the router-LSA or network-LSA that is listed in the body of the



Coltun, et al.          Expires December 3, 2006               [Page 23]


Internet-Draft                OSPF for IPv6                    June 2006


   intra-area-prefix-LSA that has produced the route (see
   Appendix A.4.10).

3.3.1  Routing table lookup

   Routing table lookup (i.e., determining the best matching routing
   table entry during IP forwarding) is the same for IPv6 as for IPv4.

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-
   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 [OSPFV2], 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
   [OSPFV2] respectively.  However, the following fields have changed
   for IPv6:


   Options
      The Options field has been removed from the standard 20 byte LSA
      header and moved 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 Appendix A.2).  Additionally, 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 high order bit encoding the handling of unknown types and the
      next two bits encoding flooding scope.  See Appendix A.4.2.1 for



Coltun, et al.          Expires December 3, 2006               [Page 24]


Internet-Draft                OSPF for IPv6                    June 2006


      the current coding of the LS type field.

   Link State ID
      Link State ID remains at 32 bits in length.  However, 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.


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 [OSPFV2]).

   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:



Coltun, et al.          Expires December 3, 2006               [Page 25]


Internet-Draft                OSPF for IPv6                    June 2006


   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 on the appropriate interfaces.

   The list of events causing LSAs to be reoriginated for IPv4 is given
   in Section 12.4 of [OSPFV2].  The following events and/or actions are
   added for IPv6:


   o  The state or interface ID 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.  If
      the router is DR, the router may also need to (re)originate and/or
      flush the network LSA corresponding to the interface.

   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.

   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.

   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 [OSPFV2] 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.





Coltun, et al.          Expires December 3, 2006               [Page 26]


Internet-Draft                OSPF for IPv6                    June 2006


          ..........................................
          .                                  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




Coltun, et al.          Expires December 3, 2006               [Page 27]


Internet-Draft                OSPF for IPv6                    June 2006


3.4.3.1  LSA Options

   The Options field in LSAs should be coded as follows.  The V6-bit
   should be set unless the router will not participate in transit IPv6
   routing.  The E-bit should be clear if and only if the attached area
   is an OSPF stub or OSPF NSSA area.  The E-bit should always be set in
   AS scoped LSAs.  The MC-bit should be set if and only if the router
   is running MOSPF and the LSA is to be used the multicast SPF
   computation (see [MOSPF]).  The N-bit should be set if and only if
   the attached area is an OSPF NSSA area.  The R-bit should be set
   unless the router will not participate in any transit routing.  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
   [DEMAND]).  All unrecognized bits in the Options field should be
   cleared.

   The V6-bit and R-bit are only examined in Router-LSAs during the SPF
   computation.  In other LSA types containing options, they are set for
   information purposes only.

3.4.3.2  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.

   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 [OSPFV2].  Bit W
   should be coded according to [MOSPF].

   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 Appendix 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 (except in the case of multiple standby
   interfaces as described in Section 3.9).  All other interfaces to the
   area add zero, one, or more link descriptions.  The number and
   content of these 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



Coltun, et al.          Expires December 3, 2006               [Page 28]


Internet-Draft                OSPF for IPv6                    June 2006


   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
      packet, and the Neighbor Router ID field is set to the neighbor's
      Router ID.

   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.













Coltun, et al.          Expires December 3, 2006               [Page 29]


Internet-Draft                OSPF for IPv6                    June 2006


        ; 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
   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 for stub networks no longer appear in the router-LSA.
   Rather, they are included in intra-area-prefix-LSAs.

3.4.3.3  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 with an elected Designated Router that is
   fully adjacent with at least one other router on the link.  The
   network-LSA is originated by the link's Designated Router and lists
   all routers on the link with whom it is fully adjacent.

   The procedure for originating network-LSAs in IPv6 is the same as the
   IPv4 procedure documented in Section 12.4.2 of [OSPFV2], 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 originated by the link's
      Designated Router.





Coltun, et al.          Expires December 3, 2006               [Page 30]


Internet-Draft                OSPF for IPv6                    June 2006


   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


3.4.3.4  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 [OSPFV2], with the following exceptions:


   o  The Link State ID of an inter-area-prefix-LSA has lost all of its
      addressing semantics and 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 [MOSPF]).




Coltun, et al.          Expires December 3, 2006               [Page 31]


Internet-Draft                OSPF for IPv6                    June 2006


   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 of all of the individual
   component prefixes.  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


3.4.3.5  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 [OSPFV2],
   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 and now 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.




Coltun, et al.          Expires December 3, 2006               [Page 32]


Internet-Draft                OSPF for IPv6                    June 2006


   As an example, consider the OSPF Autonomous System depicted in Figure
   6 of [OSPFV2].  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.6  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 [OSPFV2], with the
   following exceptions:


   o  The Link State ID of an AS-external-LSA has lost all of its
      addressing semantics and 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 [MOSPF]).

   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 supported through the inclusion of the Referenced LS Type



Coltun, et al.          Expires December 3, 2006               [Page 33]


Internet-Draft                OSPF for IPv6                    June 2006


      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 [OSPFV2].  Assume that RT7 has learned its route to N12 via BGP,
   and that it wishes to advertise a Type 2 metric into the AS.  Also
   assume that 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 in order 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
        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.7  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 SHOULD NOT be
   originated for virtual links.

   Link-LSAs have three purposes:


   1.  They provide the router's link-local address to all other routers
       attached to the link.





Coltun, et al.          Expires December 3, 2006               [Page 34]


Internet-Draft                OSPF for IPv6                    June 2006


   2.  They inform other routers attached to the link of a list of IPv6
       prefixes to associate with the link.

   3.  They allow the router to assert a collection of Options bits in
       the network-LSA originated by the Designated Router on a
       broadcast or NBMA 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.2).

   o  Each IPv6 address prefix that has been configured on 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 associated interface data structure and floods the
   link-LSA on the link.  All other routers on the link will receive the
   link-LSA, but it will not be flooded on other links.

   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 result in the following
   link-LSA that RT3 will flood only on N3.  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.














Coltun, et al.          Expires December 3, 2006               [Page 35]


Internet-Draft                OSPF for IPv6                    June 2006


        ; 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 Priority = 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.8  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 either 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.  Each intra-area-prefix-LSA has a unique Link-State ID and
   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 and the Link State ID matches the neighbor's interface ID,



Coltun, et al.          Expires December 3, 2006               [Page 36]


Internet-Draft                OSPF for IPv6                    June 2006


      the list of prefixes in the link-LSA is copied into the 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 logically OR'ed together and a single
      instance of the duplicate prefix should be included in 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 prefixes for
   its attached stub links, looped back interfaces, and hosts.  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, the global scope IPv6
      addresses associated with the interface (if any) are copied into
      the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the
      PrefixLength set to 128, and the metric set to 0.  Otherwise, the
      list of 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 Appendix C.7) to the intra-area-prefix-
      LSA.

   o  If RTX has one or more virtual links configured through the area,
      it includes one of its global scope IPv6 interface addresses in
      the LSA (if it hasn't already), setting the LA-bit in the



Coltun, et al.          Expires December 3, 2006               [Page 37]


Internet-Draft                OSPF for IPv6                    June 2006


      PrefixOptions field, 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.

        ; RT4's 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
        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



Coltun, et al.          Expires December 3, 2006               [Page 38]


Internet-Draft                OSPF for IPv6                    June 2006


   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 this case, the Designated
   Router may not be running the other protocol suite, and so another of
   the link's routers may need to originate the intra-area-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 [OSPFV2].  In
   particular, the protocol processes for determining which LSA instance
   is newer (Section 13.1 of [OSPFV2]), responding to updates of self-
   originated LSAs (Section 13.4 of [OSPFV2]), sending Link State
   Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting
   LSAs (Section 13.6 of [OSPFV2]) and receiving Link State
   Acknowledgment packets (Section 13.7 of [OSPFV2]) are exactly the
   same for IPv6 and IPv4.

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

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 [OSPFV2].  For IPv6, all
   the steps are the same, except that Steps 2 and 3 are modified as



Coltun, et al.          Expires December 3, 2006               [Page 39]


Internet-Draft                OSPF for IPv6                    June 2006


   follows:


      (2)   Examine the LSA's LS type.  Discard the LSA and get
            the next one from the Link State Update packet if the
            interface area has been configured as a stub or
            NSSA area and the LS type indicates "AS flooding scope".

            This generalizes the IPv4 behavior where AS-external-LSAs or
            AS-scoped opaque LSAs [OPAQUE] are not flooded throughout
            stub or NSSA 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 [OSPFV2] 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 [OSPFV2].  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
   [OSPFV2]).  However, the list of eligible interfaces on 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.

   Choosing the set of eligible interfaces then breaks into the
   following cases:






Coltun, et al.          Expires December 3, 2006               [Page 40]


Internet-Draft                OSPF for IPv6                    June 2006


   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 on
      interfaces connecting to stub or NSSA 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 on which the LSA was
      received).

   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 the type understood).  In this
      case, select the eligible interfaces based on the encoded flooding
      scope the same as in Case 1 above.  However, in this case
      interfaces attached to stub and NSSA 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 [OSPFV2]).  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 document,
   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,
   not all LS types are understood by all routers, For 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
   attached link.



Coltun, et al.          Expires December 3, 2006               [Page 41]


Internet-Draft                OSPF for IPv6                    June 2006


   The previous paragraph solves a problem for 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 [MOSPF]).

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 data 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 [OSPFV2].  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 [OSPFV2]).  If this destination
      is an AS boundary router, it may also be necessary to re-examine
      all the AS-external-LSAs.

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

   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.

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
   [OSPFV2].  For IPv6, self-originated LSAs are those LSAs whose
   Advertising Router is equal to the router's own Router ID.



Coltun, et al.          Expires December 3, 2006               [Page 42]


Internet-Draft                OSPF for IPv6                    June 2006


3.7  Virtual links

   OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2].
   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 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.
      Hence, a Link-LSA SHOULD NOT be originated for a virtual link
      since the virtual link has no link-local address or associated
      prefixes.

   o  Likewise, the virtual neighbor's IPv6 address is an IPv6 address
      with 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 Section 3.4.3.8 and Section 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 [OSPFV2].  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 [OSPFV2] specifies
      that stub networks within router-LSAs be examined, IPv6 will
      instead examine prefixes within intra-area-prefix-LSAs.

   o  Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs
      and inter-area-router-LSAs respectively.




Coltun, et al.          Expires December 3, 2006               [Page 43]


Internet-Draft                OSPF for IPv6                    June 2006


   o  Addressing information is no longer encoded in Link State IDs and
      is now only found within the body of LSAs.

   o  In IPv6, a router can originate multiple router-LSAs,
      distinguished by Link State ID, within a single area.  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, the shortest-path tree calculation creates routing
   table entries for the area's routers and transit links. (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.3.

   Events generated as a result of routing table changes (Section 16.7
   of [OSPFV2]), and the equal-cost multipath logic (Section 16.8 of
   [OSPFV2]) 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
   [OSPFV2].  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 [OSPFV2] 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 [OSPFV2]):


   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.

   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 be processed as an aggregate, treating them as
      fragments of a single large router-LSA.  The Options field and the



Coltun, et al.          Expires December 3, 2006               [Page 44]


Internet-Draft                OSPF for IPv6                    June 2006


      router type bits (bits W, V, E, and B) should always be taken from
      router-LSAs 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 and the router LSA V6-bit or R-bit
      are not set in the LSA options, the transit link W is ignored and
      V's next link is examined.

   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 be 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 rather than 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 with the "LA-bit" set.

   o  Routing table entries for transit networks, which are no longer
      associated with IP networks, are also calculated in Step 4 and
      added to the per-area routing table.

   The next stage of the shortest path calculation proceeds similarly to
   the two steps of the second stage of Section 16.1 in [OSPFV2].
   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's 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.2  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 [OSPFV2]).  The only



Coltun, et al.          Expires December 3, 2006               [Page 45]


Internet-Draft                OSPF for IPv6                    June 2006


   difference is in calculating the next hop IPv6 address for a router
   (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 Appendix A.4.9) 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.3  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 [OSPFV2], 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
   [OSPFV2] can be performed instead of recalculating the entire routing
   table.

3.8.4  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 [OSPFV2],
   modified in the same way as the IPv6 inter-area route calculation in
   Section 3.8.3.

3.8.5  Calculating AS external routes

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






Coltun, et al.          Expires December 3, 2006               [Page 46]


Internet-Draft                OSPF for IPv6                    June 2006


   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.

   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 AS-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.

   o  AS Boundary Router (ASBR) and forwarding address selection will
      proceed the same as if RFC1583Compatibility is disabled.
      Furthermore, RFC1583Compatibility is not an OSPF for IPv6
      configuration parameter.  Refer to Appendix C.1.

   When a single AS-external-LSA has changed, the incremental
   calculations outlined in Section 16.6 of [OSPFV2] 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 associated with the same OSPF instance and area.  All interfaces
   will be used for the reception and transmission of data traffic while
   only a single interface sends and receives OSPF control traffic.  In
   more detail:


   o  Each of the multiple interfaces are assigned different Interface
      IDs.  A router will automatically detect that multiple interfaces
      are attached to the same link when a Hello packet is received with
      one of the router's link-local addresses as the source address and
      an Interface ID other than the Interface ID of the receiving
      interface.

   o  Each of the multiple interfaces MUST be configured with the same
      Interface Instance ID to be considered on the same link.  If an
      interface has multiple instance IDs, it will be grouped with other
      interfaces based on matching instance IDs.  Each instance ID will
      be treated uniquely with respect to groupings of multiple
      interfaces on the same link.  For example, if interface A is
      configured with instance IDs 1 and 35, and interface B is
      configured with Instance ID 35, interface B may be the Active



Coltun, et al.          Expires December 3, 2006               [Page 47]


Internet-Draft                OSPF for IPv6                    June 2006


      Interface for instance ID 35 but interface A will be active for
      Instance ID 1.

   o  The router will ignore OSPF packets other than Hello packets on
      all but one of the interfaces attached to the link.  It will only
      send its OSPF control packets (including Hello packets) on a
      single interface.  This interface is designated the Active
      Interface and other interfaces attached to the same link will be
      designated Standby Interfaces.  The choice of the Active interface
      is implementation dependent.  For example, the interface with the
      highest Interface ID could be chosen.  If the router is elected
      DR, it will be the Active interface's Interface ID that will be
      used as the network-LSA's Link State ID.

   o  All of the interfaces to the link (Active and Standby) will appear
      in the router-LSA.  In addition, a link-LSA will be generated for
      each of the interfaces.  In this way, all interfaces will be
      included in OSPF's routing calculations.

   o  Any link-local scope LSAs which are originated for a Standby
      Interface will be flooded over the Active Interface.
      If a Standby Interface goes down (administratively) then the link-
      local scope LSAs originated for the Standby Interfaces MUST be
      flushed on the Active Interface.

   o  Prefixes on Standby Interfaces will be processed the same way as
      prefixes on the Active Interface.  For example, if the router is
      the DR for the link, the Active Interface's prefixes are included
      in an intra-area-prefix-LSA which is associated with the Active
      Interface's network-LSA, prefixes from Standby Interfaces on the
      link will also be included in that intra-area-prefix LSA.
      Similarly, if the link is a stub link, then the prefixes for the
      Active and Standby Interfaces will all be included in the same
      intra-area-prefix-LSA which is associated with the router-LSA.

   o  If the Active Interface 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 or through
      internal mechanisms such as when the interface is disabled by a
      configuration change.

   o  If the network becomes partitioned with different local interfaces
      attaching to different network partitions, multiple interfaces
      will become Active Interfaces and function independently.

   o  During the SPF calculation when a network-LSA for a network which
      is directly connected to the root vertex is being examined, all of



Coltun, et al.          Expires December 3, 2006               [Page 48]


Internet-Draft                OSPF for IPv6                    June 2006


      the multiple interfaces to the link of adjacent router-LSAs must
      be found and used in the next-hop calculation.
      This can be accomplished during the back link check by examining
      each link of the router-LSA and making a list of the Interface IDs
      for those links which link back to the network-LSA.  The
      interfaces in this list are used as equal-cost paths when routes
      are installed in the routing table.

   o  The interface state machine is modified to add the state Standby.
      See Section 3.9.1 for a description of the Standby state.


3.9.1  Standby Interface State

   In this state, the interface is one of multiple interfaces to a link
   and this interface is designated Standby and is not sending or
   receiving control packets.  The interface will continue to receive
   the hello packets sent by the Active Interface.  The interface will
   maintain a timer, the Active Interface Timer, with the same interval
   as the RouterDeadInterval.  This timer will be reset whenever an OSPF
   hello packet is received from the Active Interface to the link.

   Two new events are added to the list of events which cause interface
   state changes: MultipleInterfacesToLink and ActiveInterfaceDead.  The
   descriptions of these events are as follows:


   MultipleInterfacesToLink
      An interfaces on the router has received a hello packet from
      another interface on the same router.  One of the interfaces is
      designated as the Active Interface, and the other interface is
      designated as a Standby Interface.  The Standby Interface
      transitions to the Standby state.

   ActiveInterfaceDead
      There has been an indication that a Standby Interface is no longer
      on a link with an Active Interface.  The firing of the Active
      Interface Timer is one indication, as it means that the Standby
      Interface has not received an OSPF hello packet from the Active
      Interface for the RouterDeadInterval.  Other indications may come
      from internal notifications, such as the Active Interface being
      disabled through a configuration change.  Any indication internal
      to the router, such that the router knows the Active Interface is
      no longer active on the link, can trigger the ActiveInterfaceDead
      event for a Standby Interface.

   Interface state machine additions include:




Coltun, et al.          Expires December 3, 2006               [Page 49]


Internet-Draft                OSPF for IPv6                    June 2006


        State(s):  Waiting, DR Other, Backup or DR

           Event:  MultipleInterfacesToLink

       New state:  Standby

          Action:  All interface variables are reset, and interface
                   timers disabled.  Also, all neighbor connections
                   associated with the interface are destroyed.  This
                   is done by generating the event KillNbr on all
                   associated neighbors. The Active Interface Timer is
                   started and the interface will listen for OSPF hello
                   packets from the Active Interface for the link.


        State(s):  Standby

           Event:  ActiveInterfaceDead

       New state:  Down

          Action:  The Active Interface Timer is disabled, then the
                   InterfaceUp event is invoked.




























Coltun, et al.          Expires December 3, 2006               [Page 50]


Internet-Draft                OSPF for IPv6                    June 2006


4.  Security Considerations

   When running over IPv6, OSPF relies on the IP Authentication Header
   (see [IPAUTH]) and the IP Encapsulating Security Payload (see
   [IPESP]) to ensure integrity and authentication/confidentiality of
   protocol packets.

   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,
   as implementation MUST check the IPSEC SA and local SA database to
   assure that the packet originates from a source that is trusted to
   run OSPF.






































Coltun, et al.          Expires December 3, 2006               [Page 51]


Internet-Draft                OSPF for IPv6                    June 2006


5.  IANA Considerations

   OSPF for IPv6 IANA considerations are documented in [OSPF-IANA].
















































Coltun, et al.          Expires December 3, 2006               [Page 52]


Internet-Draft                OSPF for IPv6                    June 2006


6.  Acknowledgments

   The RFC text was produced using Marshall Rose's xml2rfc tool.

   The following individuals contributed comments which were
   incorporated into this update:


   o  Harold Rabbie for his description of protocol details which needed
      to be clarified for OSPFv3 NSSAs.

   o  Nic Neate for his pointing out that there needed to be changes for
      unknown LSA types handling in the processing of database
      description packets.

   o  Jacek Kwiatkowski for being the first to point out that the V6 and
      R bits are not taken into account in the OSPFv3 intra-area SPF
      calculation.

   o  Michael Barnes recognized that the support for multiple interfaces
      to a single link was broken (see Section 3.9) and provided the
      description of the current protocol mechanisms.  Abhay Roy
      reviewed and suggested improvements to the mechanisms.

   o  Alan Davey reviewed and commented on draft revisions.

   o  Vivek Dubey reviewed and commented on draft revisions.

   o  Ramana Koppula reviewed and commented on draft revisions.

   o  Dow Street and Wayne Wheeler commented on the addition of the DN
      bit to OSPFv3.

   o  Mitchell Erblichs provided numerous editorial comments.

















Coltun, et al.          Expires December 3, 2006               [Page 53]


Internet-Draft                OSPF for IPv6                    June 2006


7.  References

7.1  Normative References

   [D-BIT]    Eric, E., Peter, P., and P. Pillay-Esnault, "Using an LSA
              Options Bit to Prevent Looping in BGP/MPLS IP VPNs",
              RFC XXXX, April 2005.

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

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

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

   [IP6ADDR]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

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

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

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

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

   [NSSA]     Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
              RFC 3101, January 2003.

   [OSPF-IANA]
              Kompella, K., "IANA Considerations for OSPF",
              draft-ietf-ospf-iana-00.txt (work in progress).

   [OSPF-TE]  Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
              Extensions to OSPF", RFC 3630, September 2003.

   [OSPFV2]   Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.





Coltun, et al.          Expires December 3, 2006               [Page 54]


Internet-Draft                OSPF for IPv6                    June 2006


7.2  Informative References

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

   [OPAQUE]   Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
              July 1998.

   [OSPFV3]   Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.


Authors' Addresses

   Rob Coltun
   Touch Acoustra
   3204 Brooklawn Terrace
   Chevy Chase, MD  20815
   USA

   Email: undisclosed


   Dennis Ferguson
   Juniper Networks
   1194 N. Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: dennis@juniper.net


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

   Email: jmoy@sycamorenet.com












Coltun, et al.          Expires December 3, 2006               [Page 55]


Internet-Draft                OSPF for IPv6                    June 2006


   Acee Lindem
   Cisco Systems, Inc
   7025 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

   Email: acee@cisco.com












































Coltun, et al.          Expires December 3, 2006               [Page 56]


Internet-Draft                OSPF for IPv6                    June 2006


Appendix 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 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
   multiple 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 size of
   OSPF packets sent over virtual links to 1280 bytes unless Path MTU
   Discovery is being performed [MTUDISC].

   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.





Coltun, et al.          Expires December 3, 2006               [Page 57]


Internet-Draft                OSPF for IPv6                    June 2006


      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.

   Seven 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
   unrecognized bits and process the packet or LSA normally.




Coltun, et al.          Expires December 3, 2006               [Page 58]


Internet-Draft                OSPF for IPv6                    June 2006


                               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 for details.

   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 [OSPFV2].

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

   N-bit
      This bit indicates whether or not the router is attached to an
      NSSA as specified in [NSSA].

   R-bit
      This bit (the `Router' bit) indicates whether the originator is an
      active router.  If the router bit is clear, then 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 [DEMAND].

   *-bit
      These bits are reserved for migration of OSPFv2 protocol
      extensions.


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 format is displayed and the packet's



Coltun, et al.          Expires December 3, 2006               [Page 59]


Internet-Draft                OSPF for IPv6                    June 2006


   component fields are defined.

   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.

   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.

       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 Appendix A.3.2 through
      Appendix A.3.6 for details.

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





Coltun, et al.          Expires December 3, 2006               [Page 60]


Internet-Draft                OSPF for IPv6                    June 2006


   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.

   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 traversing a virtual link are labeled
      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 [IPV6, 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 SHOULD be set to 0 when sending
      protocol packets and MUST be ignored when receiving protocol
      packets.


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



Coltun, et al.          Expires December 3, 2006               [Page 61]


Internet-Draft                OSPF for IPv6                    June 2006


   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-
   directional communication (the Router IDs of all neighbors whose
   Hellos have been recently received).

       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 Priority  |             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
      ([INTFMIB]).

   Rtr Priority
      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.







Coltun, et al.          Expires December 3, 2006               [Page 62]


Internet-Draft                OSPF for IPv6                    June 2006


   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.

   Designated Router ID
      The sending router's view of the identity of the Designated Router
      for this network.  The Designated Router is identified by its
      Router ID.  It is set to 0.0.0.0 if there is no Designated Router.

   Backup Designated Router ID
      The sending router's view of the identity of the Backup Designated
      Router for this network.  The Backup Designated Router is
      identified by its IP Router ID.  It is set to 0.0.0.0 if there is
      no Backup Designated Router.

   Neighbor ID
      The Router IDs of each router on the network with neighbor state
      1-Way or greater.


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
   and the other is 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.














Coltun, et al.          Expires December 3, 2006               [Page 63]


Internet-Draft                OSPF for IPv6                    June 2006


       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 packet and the Link State Acknowledgment
   packet.  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
   [OSPFV2].  The reception of Database Description packets is
   documented in Section 10.6 of [OSPFV2].


   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 [MTUDISC].
      Interface MTU should be set to 0 in Database Description packets
      sent over virtual links.



Coltun, et al.          Expires December 3, 2006               [Page 64]


Internet-Draft                OSPF for IPv6                    June 2006


   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 for both the master and slave routers have
      been exchanged.

   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 Appendix A.4.2.
   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 [OSPFV2].  The reception of Link State Request packets is
   documented in Section 10.7 of [OSPFV2].






Coltun, et al.          Expires December 3, 2006               [Page 65]


Internet-Draft                OSPF for IPv6                    June 2006


       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 without
   specifying its instance.  Link State Request packets are understood
   to be requests for the most recent instance of the specified LSAs.

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.













Coltun, et al.          Expires December 3, 2006               [Page 66]


Internet-Draft                OSPF for IPv6                    June 2006


       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
   Appendix A.4.2.  Detailed formats of the different types of LSAs are
   described Appendix 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 of
   implicitly acknowledged.  Explicit acknowledgment is accomplished
   through the sending and receiving of Link State Acknowledgment
   packets.  The sending of Link State Acknowledgment packets is
   documented in Section 13.5 of [OSPFV2].  The reception of Link State
   Acknowledgment packets is documented in Section 13.7 of [OSPFV2].

   Multiple LSAs MAY 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 to the multicast
   address AllSPFRouters, the multicast address AllDRouters, or to a
   neighbor's unicast address (see Section 13.5 of [OSPFV2] for
   details).

   The format of this packet is similar to that of the Data Description



Coltun, et al.          Expires December 3, 2006               [Page 67]


Internet-Draft                OSPF for IPv6                    June 2006


   packet.  The body of both packets is simply a list of LSA headers.


       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 Appendix 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 document defines eight distinct types of LSAs.  Each LSA begins
   with a standard 20 byte LSA header.  This header is explained in
   Appendix A.4.2.  Succeeding sections describe each LSA type
   individually.

   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, AS-
   external-LSAs, and NSSA-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 common to a
   flooding scope have the same collection of LSAs associated with that



Coltun, et al.          Expires December 3, 2006               [Page 68]


Internet-Draft                OSPF for IPv6                    June 2006


   flooding scope.  (See Section 3.5 for more information concerning the
   flooding algorithm).  This collection of LSAs is called the link-
   state database.

   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 [OSPFV2]).  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
   protocols, 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 Appendix 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
   Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and
   Appendix A.4.10.

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.  For
   example, they can indicate that prefixes are to be ignored in some
   cases or are to be marked as not readvertisable in others.

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









Coltun, et al.          Expires December 3, 2006               [Page 69]


Internet-Draft                OSPF for IPv6                    June 2006


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

   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.  If not set, it
      should be excluded.

   P-bit
      The "propagate" bit.  Set on NSSA area prefixes that should be
      readvertised by the translating NSSA area border [NSSA].

   DN-bit
      This bit controls an inter-area-prefix-LSAs or AS-external-LSAs
      re-advertisement in a VPN environment as specified in [D-BIT].


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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Coltun, et al.          Expires December 3, 2006               [Page 70]


Internet-Draft                OSPF for IPv6                    June 2006


   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 Appendix A.4.2.1 for a
      detailed description of LS type.

   LS State ID
      The originating router's identifier for the LSA.  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
      [OSPFV2] 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 [OSPFV2] for more details.

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


A.4.2.1  LSA 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          |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+



Coltun, et al.          Expires December 3, 2006               [Page 71]


Internet-Draft                OSPF for IPv6                    June 2006


   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

   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 originating link
     0  1    Area Scoping - Flooded only in originating area
     1  0    AS Scoping - Flooded throughout 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
   document, except for the group-membership-LSA (see [MOSPF]) and the
   NSSA-LSA (see [NSSA]).  As shown below, each LSA function code also
   implies a specific setting for the U, S1, and S2 bits.


            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    NSSA-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.2).  Router-LSAs are
   only flooded throughout a single area.



Coltun, et al.          Expires December 3, 2006               [Page 72]


Internet-Draft                OSPF for IPv6                    June 2006


       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|Nt|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.








Coltun, et al.          Expires December 3, 2006               [Page 73]


Internet-Draft                OSPF for IPv6                    June 2006


   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).

   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 [MOSPF]
      for details.

   Bit Nt
      When set, the router is an NSSA border router that is
      unconditionally translating NSSA LSAs into AS-External LSAs (Nt
      stands for NSSA translation).  Note that such routers have their
      NSSATranslatorRole area configuration parameter set to Always.
      [NSSA]

   Options
      The optional capabilities supported by the router, as documented
      in Appendix 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






Coltun, et al.          Expires December 3, 2006               [Page 74]


Internet-Draft                OSPF for IPv6                    June 2006


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

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

   Neighbor Interface ID
      The Interface ID the neighbor router has associated with the link,
      as advertised in the neighbor's hello packets.  For transit (type
      2) links, the link's Designated Router is the neighbor described.
      For other link types, the sole adjacent neighbor is described.

   Neighbor Router ID
      The Router ID the of the neighbor router.  For transit (type 2)
      links, the link's Designated Router is the neighbor described.
      For other link types, the sole adjacent neighbor is described.

   For transit (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
   includes two or more adjacent 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.3).















Coltun, et al.          Expires December 3, 2006               [Page 75]


Internet-Draft                OSPF for IPv6                    June 2006


       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.


A.4.5  Inter-Area-Prefix-LSAs

   Inter-area-prefix-LSAs have LS type equal to 0x2003.  These LSAs are
   the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see
   Section 12.4.3 of [OSPFV2]).  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.4).

   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.








Coltun, et al.          Expires December 3, 2006               [Page 76]


Internet-Draft                OSPF for IPv6                    June 2006


       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 router-LSAs.  When the inter-area-prefix-LSA is
      describing a route to a range of addresses (see Appendix 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
      Appendix A.4.1


A.4.6  Inter-Area-Router-LSAs

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







Coltun, et al.          Expires December 3, 2006               [Page 77]


Internet-Draft                OSPF for IPv6                    June 2006


       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 Appendix A.2.

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

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


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.6.

   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.






Coltun, et al.          Expires December 3, 2006               [Page 78]


Internet-Draft                OSPF for IPv6                    June 2006


       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)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   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 other LSAs (i.e., the same units
      as the interface costs in router-LSAs).

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







Coltun, et al.          Expires December 3, 2006               [Page 79]


Internet-Draft                OSPF for IPv6                    June 2006


   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
      Appendix 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.  It MUST
      NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an
      IPv6 Link-Local Address (Prefix FE80/10).  While OSPFv3 routes are
      normally installed with link-local addresses, an OSPFv3
      implementation advertising a forwarding address MUST advertise a
      global IPv6 address.  This global IPv6 address may be the next-hop
      gateway for external prefix or may be obtained through some other
      method (e.g., configuration).

   External Route Tag
      A 32-bit field which MAY be used to communicate additional
      information between AS boundary routers; see [EXTTAG] 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.

   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).  When present, Forwarding Address



Coltun, et al.          Expires December 3, 2006               [Page 80]


Internet-Draft                OSPF for IPv6                    June 2006


   always comes first, External Route Tag next, and the Referenced Link
   State ID last.

A.4.8  NSSA-LSAs

   NSSA-LSAs have LS type equal to 0x2007.  These LSAs are originated by
   AS boundary routers within an NSSA and describe destinations external
   to the AS that may or may not be propagated outside the NSSA (refer
   to [NSSA]).  Their format is exactly the same as AS-external LSAs as
   described in Appendix A.4.7.

   A global IPv6 address MUST be selected as forwarding address for
   NSSA-LSAs that are to be propagated by NSSA area border routers.  The
   selection should proceed the same as OSPF for IPv4 [NSSA] only a
   check must be added to assure IPv6 link-local address are not
   selected.

A.4.9  Link-LSAs

   Link-LSAs have LS type equal to 0x0008.  A router originates a
   separate link-LSA for each physical 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.

   2.  They inform other routers attached to the link of a list of IPv6
       prefixes to associate with the link.

   3.  They allow the router to assert a collection of Options bits in
       the network-LSA originated by the Designated Router on a
       broadcast or NBMA link.

   For details concerning the construction of Links-LSAs, see
   Section 3.4.3.7.

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










Coltun, et al.          Expires December 3, 2006               [Page 81]


Internet-Draft                OSPF for IPv6                    June 2006


       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 Priority  |                Options                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-                Link-local Interface Address                 -+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         # prefixes                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PrefixLength | PrefixOptions |             0                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix                         |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PrefixLength | PrefixOptions |             0                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix                         |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Rtr Priority
      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 by the Designated Router on
      broadcast or NBMA links.




Coltun, et al.          Expires December 3, 2006               [Page 82]


Internet-Draft                OSPF for IPv6                    June 2006


   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
      Appendix A.4.1


A.4.10  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 local router address, an attached stub
   network segment, or an attached transit network segment.  In IPv4,
   the first two were accomplished via the router's router-LSA and the
   last via a network-LSA.  In OSPF for IPv6, all addressing information
   that was advertised in router-LSAs and network-LSAs has been removed
   and is now advertised in intra-area-prefix-LSAs.  For details
   concerning the construction of intra-area-prefix-LSA, see
   Section 3.4.3.8.

   A router can originate multiple intra-area-prefix-LSAs for each
   router or transit network.  Each such LSA is distinguished by its
   unique Link State ID.




















Coltun, et al.          Expires December 3, 2006               [Page 83]


Internet-Draft                OSPF for IPv6                    June 2006


       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.

   Referenced LS type, Referenced Link State ID, and Referenced
   Advertising Router
      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.




Coltun, et al.          Expires December 3, 2006               [Page 84]


Internet-Draft                OSPF for IPv6                    June 2006


   The rest of the intra-area-prefix-LSA contains a list of IPv6
   prefixes to be associated with the router or transit link, as well
   as, their associated costs.


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

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







































Coltun, et al.          Expires December 3, 2006               [Page 85]


Internet-Draft                OSPF for IPv6                    June 2006


Appendix B.  Architectural Constants

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













































Coltun, et al.          Expires December 3, 2006               [Page 86]


Internet-Draft                OSPF for IPv6                    June 2006


Appendix 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.  Similarly, 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 due to a Router ID change, ID,
      the router should flush its self-originated LSAs from the routing
      domain (see Section 14.1 of [OSPFV2]).  Otherwise, they will
      persist for up to MaxAge seconds.

   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



Coltun, et al.          Expires December 3, 2006               [Page 87]


Internet-Draft                OSPF for IPv6                    June 2006


   inability for adjacencies to form between them, with a resulting
   hindrance to the flow of both routing protocol information 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.

   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 or NSSA area.  Also,
      virtual links cannot be configured through stub or NSSA areas.
      For more information, see Section 3.6 of [OSPFV2].

   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
      [OSPFV2] for more information.

   NSSATranslatorRole and TranslatorStabilityInterval
      These area parameters are described in Appendix D of [NSSA].






Coltun, et al.          Expires December 3, 2006               [Page 88]


Internet-Draft                OSPF for IPv6                    June 2006


   ImportSummaries
      When set to enabled, prefixes external to the area are imported
      into the area via the advertisement of inter-area-prefix-LSAs.
      When set to disabled, inter-area routes are not imported into the
      area.  The default setting is enabled.  This parameter is only
      valid for stub or NSSA areas.


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
      ([INTFMIB]).

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

   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



Coltun, et al.          Expires December 3, 2006               [Page 89]


Internet-Draft                OSPF for IPv6                    June 2006


      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 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
      RouterDeadInterval field.  This should be some multiple of the
      HelloInterval (e.g., 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 a point-to-point link with no global IPv6
   addresses in the graph for the backbone.  The virtual link must be



Coltun, et al.          Expires December 3, 2006               [Page 90]


Internet-Draft                OSPF for IPv6                    June 2006


   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
   Appendix C.3).  Virtual links do not have link-local addresses, but
   instead use one of the router's global-scope IPv6 addresses as the IP
   source in OSPF protocol packets it sends on 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 transit area intra-area path between the two endpoint routers.
   The parameter RxmtInterval may 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 long.

   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 or NSSA areas.  Additionally, an instance ID
   may be configured for virtual links from different protocol instances
   in order to utilize the same transit area (without requiring
   different router IDs for demultiplexing).

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 listing 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:


   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 an NBMA network first comes up, the router



Coltun, et al.          Expires December 3, 2006               [Page 91]


Internet-Draft                OSPF for IPv6                    June 2006


      only sends Hello Packets to those neighbors eligible to become
      Designated Router, until the identity of the Designated Router is
      elected.

   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 not defined.

C.7  Host route parameters

   Host prefixes are advertised in intra-area-prefix-LSAs.  They
   indicate either local 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.








Coltun, et al.          Expires December 3, 2006               [Page 92]


Internet-Draft                OSPF for IPv6                    June 2006


Appendix D.  Stub Area Unknown LSA Flooding Restriction Deprecated

   In RFC 2740 [RFC2740], flooding of unknown LSA was restricted within
   stub and NSSA areas.  The text describing this restriction is
   included below.

        However, unlike in IPv4, IPv6 allows LSAs with unrecognized
        LS types to be labeled "Store and flood the LSA, as if type
        understood" (see the U-bit in Appendix A.4.2.1).  Uncontrolled
        introduction of such LSAs could cause a stub area's link-state
        database to grow larger than its component routers' capacities.

        To guard against this, the following rule regarding stub areas
        has been established: an LSA whose LS type is unrecognized can
        only be flooded into/throughout a stub area if both a) the LSA
        has area or link-local flooding scope and b) the LSA has U-bit
        set to 0.  See Section 3.5 for details.

   This restriction has been deprecated.  OSPFv3 routers will flood link
   and area scope LSAs whose LS type is unrecognized and whose U-bit is
   set to 1 throughout stub and NSSA areas.  There are no backward
   compatibility issues other than OSPFv3 routers still supporting the
   restriction may not propagate newly defined LSA types.




























Coltun, et al.          Expires December 3, 2006               [Page 93]


Internet-Draft                OSPF for IPv6                    June 2006


Appendix E.  Change Log

E.1  Changes from RFC 2740 to 00 Version

   The section contains list of changes from RFC 2740 [OSPFV3]:


   o  Convert RFC 2740 text to XML format.

   o  Convert all the references in the document to symbolic references
      and correct the ones that were wrong.

   o  Fix some selected typographical errors.

   o  Remove references to the never-standardized external attributes
      LSA.

   o  Remove unreferenced or removed reference documents.


E.2  Changes from the 00 Version to the 01 Version

   The section contains list of changes from version 00 to version 01:


   o  Remove references to site-local addresses.

   o  Correct link local range in Section 3.4.3.7.

   o  Clarify interface IDs on virtual link in Section 2.4 and
      Appendix C.4.

   o  Clarify interface ID changes in Section 3.4.3.

   o  Clarify unknown LSA type handling in database description packets
      in Section 3.2.2.

   o  Clarify unknown LSA type handling in link state update packets in
      Section 3.5.1.

   o  Rewrite the confusing text regarding prefix inclusion in
      Section 3.4.3.8.

   o  Correct referenced LS types to the OSPFv3 types in
      Section 3.4.3.8.

   o  Indicate that transit links are ignored for routers that don't
      have the V6 or R bits set in their router LSA options.  See



Coltun, et al.          Expires December 3, 2006               [Page 94]


Internet-Draft                OSPF for IPv6                    June 2006


      Section 3.8.1.

   o  Correct field alignment in packet and LSA figures in Appendix A.

   o  Clarify that a forwarding address should never be a link-local
      address in Appendix A.4.7.

   o  Added more information for NSSA support in Section 3.8.5,
      Appendix A.4.3, and Appendix A.4.8.

   o  Added spacing before start of lists.


E.3  Changes from the 01 Version to the 02 Version

   The section contains list of changes from version 01 to version 02:


   o  Various typographical corrections.

   o  Clarification of support for multiple interfaces to a single link
      (see Section 3.9).


E.4  Changes from the 02 Version to the 03 Version

   The section contains list of changes from version 02 to version 03:


   o  Various typographical corrections.

   o  Clarification of reorigination of LSAs when a neighbor's interface
      ID changes (see Section 3.4.3).

   o  Clarification of the significance of Interface Instance ID when
      determining whether a router has multiple instances on the same
      link (see Section 3.9).

   o  Fix the RFC 2119 reference RFC and date.

   o  Add the DN bit to the options description since it will be
      published as an RFC soon.  Also reserve a bit for future OSPFv2
      extensions.


E.5  Changes from the 03 Version to the 04 Version

   The section contains list of changes from version 03 to version 04:



Coltun, et al.          Expires December 3, 2006               [Page 95]


Internet-Draft                OSPF for IPv6                    June 2006


   o  Various typographical corrections.

   o  Link-LSAs are not needed on virtual links.

   o  Capitalize MUST, MUST NOT, SHOULD, and MAY in places the usage
      impacts protocol operation and interoperability.

   o  Add reference to the IANA considerations document.


E.6  Changes from the 04 Version to the 05 Version

   The section contains list of changes from version 04 to version 05:


   o  Various typographical corrections.

   o  Document that RFC1583Compatibility need not be considered when
      calculating AS external routes in Section 3.8.5.

   o  Clarify global IPv6 address advertisement for a forwarding address
      in Appendix A.4.7.


E.7  Changes from the 05 Version to the 06 Version

   The section contains list of changes from version 05 to version 06:


   o  Move DN bit from LSA options to prefix options.

   o  Remove the restriction on flooding unknown LSA types for stub and
      NSSA areas.  Refer to Section 2.10.


E.8  Changes from the 06 Version to the 07 Version

   The section contains list of changes from version 06 to version 07:


   o  Mitchell Erblich's editorial comments.

   o  Move LSA option processing into its own subsection and make it
      applicable to all LSA types.  Refer to Section 3.4.3.1.







Coltun, et al.          Expires December 3, 2006               [Page 96]


Internet-Draft                OSPF for IPv6                    June 2006


E.9  Changes from the 07 Version to the 08 Version

   The section contains list of changes from version 07 to version 08:


   o  Fix problem with vertex reference in the intra-area SPF (see
      Section 3.8.1).


E.10  Changes from the 08 Version to the 09 Version

   The section contains list of changes from version 08 to version 09:


   o  Additional clarifications to support for multiple interfaces to a
      single link (see Section 3.9).

   o  Document exception condition for multiple interfaces to the same
      interface in (see Section 3.2.2).

   o  Remove reference to unnumbered link due to the lack of
      applicability in IPv6 (see Appendix C.4).





























Coltun, et al.          Expires December 3, 2006               [Page 97]


Internet-Draft                OSPF for IPv6                    June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Coltun, et al.          Expires December 3, 2006               [Page 98]