home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-ospfv6-03.txt < prev    next >
Text File  |  1996-11-25  |  175KB  |  5,154 lines
  1.  
  2.  
  3.  
  4.  
  5. Network    Working    Group                           R. Coltun
  6. Internet Draft                            FORE Systems
  7. Expiration Date: May 1997                     D.    Ferguson
  8. File name: draft-ietf-ospf-ospfv6-03.txt        Juniper    Networks
  9. Network    Working    Group                          J. Moy
  10. Internet Draft                    Cascade Communications Corp.
  11.                                November 1996
  12.  
  13.  
  14.                  OSPF for IPv6
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.  
  20.     This document is an    Internet-Draft.     Internet-Drafts are working
  21.     documents of the Internet Engineering Task Force (IETF), its areas,
  22.     and    its working groups.  Note that other groups may    also distribute
  23.     working documents as Internet-Drafts.
  24.  
  25.     Internet-Drafts are    draft documents    valid for a maximum of six
  26.     months and may be updated, replaced, or obsoleted by other documents
  27.     at any time.  It is    inappropriate to use Internet- Drafts as
  28.     reference material or to cite them other than as "work in progress".
  29.  
  30.     To learn the current status    of any Internet-Draft, please check the
  31.     "1id-abstracts.txt"    listing    contained in the Internet- Drafts Shadow
  32.     Directories    on ftp.is.co.za    (Africa), nic.nordu.net    (Europe),
  33.     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.     ftp.isi.edu    (US West Coast).
  35.  
  36. Abstract
  37.  
  38.     This document describes the    modifications to OSPF to support version
  39.     6 of the Internet Protocol (IPv6).    The fundamental    mechanisms of
  40.     OSPF (flooding, DR election, area support, SPF calculations, etc.)
  41.     remain unchanged. However, some changes have been necessary, either
  42.     due    to changes in protocol semantics between IPv4 and IPv6,    or
  43.     simply to handle the increased address size    of IPv6.
  44.  
  45.     Changes between OSPF for IPv4 and this document include the
  46.     following. Addressing semantics have been removed from OSPF    packets
  47.     and    the basic LSAs.    New LSAs have been created to carry IPv6
  48.     addresses and prefixes. OSPF now runs on a per-link    basis, instead
  49.     of on a per-IP-subnet basis. Flooding scope    for LSAs has been
  50.     generalized. Authentication    has been removed from the OSPF protocol
  51.     itself, instead relying on IPv6's Authentication Header and
  52.     Encapsulating Security Payload.
  53.  
  54.  
  55.  
  56. Coltun et al                            [Page 1]
  57.  
  58. Internet Draft             OSPF for IPv6           November 1996
  59.  
  60.  
  61.     Most packets in OSPF for IPv6 are almost as    compact    as those in OSPF
  62.     for    IPv4, even with    the larger IPv6    addresses. Most    field- and
  63.     packet-size    limitations present in OSPF for    IPv4 have been relaxed.
  64.     In addition, option    handling has been made more flexible.
  65.  
  66.     All    of OSPF    for IPv4's optional capabilities, including on-demand
  67.     circuit support, NSSA areas, and the multicast extensions to OSPF
  68.     (MOSPF) are    also supported in OSPF for IPv6.
  69.  
  70.     Please send    comments to ospf@gated.cornell.edu.
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Coltun et al                            [Page 2]
  113.  
  114. Internet Draft             OSPF for IPv6           November 1996
  115.  
  116.  
  117. Table of Contents
  118.  
  119.     1         Introduction ........................................... 5
  120.     1.1         Terminology ............................................ 5
  121.     2         Differences from OSPF for IPv4 ......................... 5
  122.     2.1         Protocol processing per-link, not per-subnet ........... 5
  123.     2.2         Removal of    addressing semantics ........................ 6
  124.     2.3         Addition of Flooding scope    ............................. 6
  125.     2.4         Explicit support for multiple instances per link ....... 7
  126.     2.5         Use of link-local addresses ............................ 7
  127.     2.6         Authentication changes ................................. 8
  128.     2.7         Packet format changes .................................. 8
  129.     2.8         LSA format    changes    ..................................... 9
  130.     2.9         Handling unknown LSA types    ............................ 11
  131.     2.10     Stub area support ..................................... 11
  132.     2.11     Identifying neighbors by Router ID    .................... 12
  133.     2.12     Removal of    TOS ........................................ 12
  134.     3         Implementation details ................................ 12
  135.     3.1         Protocol data structures .............................. 14
  136.     3.1.1    The Area Data structure ............................... 14
  137.     3.1.2    The Interface Data    structure .......................... 14
  138.     3.1.3    The Neighbor Data Structure ........................... 16
  139.     3.2         Protocol Packet Processing    ............................ 17
  140.     3.2.1    Sending protocol packets .............................. 17
  141.     3.2.1.1  Sending Hello packets ................................. 18
  142.     3.2.1.2  Sending Database Description Packets .................. 19
  143.     3.2.2    Receiving protocol    packets    ............................ 19
  144.     3.2.2.1  Receiving Hello Packets ............................... 21
  145.     3.3         The Routing table Structure ........................... 22
  146.     3.3.1    Routing table lookup .................................. 23
  147.     3.4         Link State    Advertisements ............................. 23
  148.     3.4.1    The LSA Header ........................................ 23
  149.     3.4.2    The link-state database ............................... 24
  150.     3.4.3    Originating LSAs ...................................... 25
  151.     3.4.3.1  Router-LSAs ........................................... 27
  152.     3.4.3.2  Network-LSAs .......................................... 29
  153.     3.4.3.3  Inter-Area-Prefix-LSAs ................................ 30
  154.     3.4.3.4  Inter-Area-Router-LSAs ................................ 31
  155.     3.4.3.5  AS-external-LSAs ...................................... 32
  156.     3.4.3.6  Link-LSAs ............................................. 34
  157.     3.4.3.7  Intra-Area-Prefix-LSAs ................................ 35
  158.     3.5         Flooding .............................................. 38
  159.     3.5.1    Receiving Link State Update packets ................... 39
  160.     3.5.2    Sending Link State    Update packets ..................... 39
  161.     3.5.3    Installing    LSAs in    the database ....................... 41
  162.     3.6         Definition    of self-originated LSAs    .................... 42
  163.     3.7         Virtual links ......................................... 42
  164.     3.8         Routing table calculation ............................. 43
  165.  
  166.  
  167.  
  168. Coltun et al                            [Page 3]
  169.  
  170. Internet Draft             OSPF for IPv6           November 1996
  171.  
  172.  
  173.     3.8.1    Calculating the shortest path tree    for an area ........ 44
  174.     3.8.1.1  The next hop calculation .............................. 45
  175.     3.8.2    Calculating the inter-area    routes ..................... 46
  176.     3.8.3    Examining transit areas' summary-LSAs ................. 46
  177.     3.8.4    Calculating AS external routes ........................ 46
  178.          References    ............................................ 48
  179.     A         OSPF data formats ..................................... 50
  180.     A.1         Encapsulation of OSPF packets ......................... 50
  181.     A.2         The Options field ..................................... 52
  182.     A.3         OSPF Packet Formats ................................... 54
  183.     A.3.1    The OSPF packet header ................................ 55
  184.     A.3.2    The Hello packet ...................................... 57
  185.     A.3.3    The Database Description packet ....................... 59
  186.     A.3.4    The Link State Request packet ......................... 61
  187.     A.3.5    The Link State Update packet .......................... 62
  188.     A.3.6    The Link State Acknowledgment packet .................. 63
  189.     A.4         LSA formats ........................................... 65
  190.     A.4.1    IPv6 Prefix Representation    ............................ 66
  191.     A.4.1.1  Prefix Options ........................................ 67
  192.     A.4.2    The LSA header ........................................ 68
  193.     A.4.2.1  LS    type ............................................... 70
  194.     A.4.3    Router-LSAs ........................................... 72
  195.     A.4.4    Network-LSAs .......................................... 75
  196.     A.4.5    Inter-Area-Prefix-LSAs ................................ 76
  197.     A.4.6    Inter-Area-Router-LSAs ................................ 78
  198.     A.4.7    AS-external-LSAs ...................................... 79
  199.     A.4.8    Link-LSAs ............................................. 82
  200.     A.4.9    Intra-Area-Prefix-LSAs ................................ 84
  201.     B         Architectural Constants ............................... 86
  202.     C         Configurable Constants ................................ 86
  203.     C.1         Global parameters ..................................... 86
  204.     C.2         Area parameters ....................................... 87
  205.     C.3         Router interface parameters ........................... 88
  206.     C.4         Virtual link parameters ............................... 89
  207.     C.5         NBMA network parameters ............................... 90
  208.     C.6         Point-to-MultiPoint network parameters ................ 91
  209.     C.7         Host route    parameters ................................. 91
  210.          Security Considerations ............................... 92
  211.          Authors' Addresses    .................................... 92
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224. Coltun et al                            [Page 4]
  225.  
  226. Internet Draft             OSPF for IPv6           November 1996
  227.  
  228.  
  229. 1.  Introduction
  230.  
  231.     This document describes the    modifications to OSPF to support version
  232.     6 of the Internet Protocol (IPv6).    The fundamental    mechanisms of
  233.     OSPF (flooding, DR election, area support, SPF calculations, etc.)
  234.     remain unchanged. However, some changes have been necessary, either
  235.     due    to changes in protocol semantics between IPv4 and IPv6,    or
  236.     simply to handle the increased address size    of IPv6.
  237.  
  238.     This document is organized as follows. Section 2 describes the
  239.     differences    between    OSPF for IPv4 and OSPF for IPv6    in detail.
  240.     Section 3 provides implementation details for the changes. Appendix
  241.     A gives the    OSPF for IPv6 packet and LSA formats. Appendix B lists
  242.     the    OSPF architectural constants. Appendix C describes configuration
  243.     parameters.
  244.  
  245.     1.1.  Terminology
  246.  
  247.     This document attempts to use terms from both the OSPF for IPv4
  248.     specification ([Ref1]) and the IPv6 protocol specifications
  249.     ([Ref14]). This    has produced a mixed result. Most of the terms
  250.     used both by OSPF and IPv6 have    roughly    the same meaning (e.g.,
  251.     interfaces). However, there are    a few conflicts. IPv6 uses
  252.     "link" similarly to IPv4 OSPF's    "subnet" or "network". In this
  253.     case, we have chosen to    use IPv6's "link" terminology. "Link"
  254.     replaces OSPF's    "subnet" and "network" in most places in this
  255.     document, although OSPF's Network-LSA remains unchanged    (and
  256.     possibly unfortunately,    a new Link-LSA has also    been created).
  257.  
  258.     The names of some of the OSPF LSAs have    also changed. See
  259.     Section    2.8 for    details.
  260.  
  261. 2.  Differences    from OSPF for IPv4
  262.  
  263.     Most of the    algorithms from    OSPF for IPv4 [Ref1] have preserved in
  264.     OSPF for IPv6. However, some changes have been necessary, either due
  265.     to changes in protocol semantics between IPv4 and IPv6, or simply to
  266.     handle the increased address size of IPv6.
  267.  
  268.     The    following subsections describe the differences between this
  269.     document and [Ref1].
  270.  
  271.     2.1.  Protocol processing per-link,    not per-subnet
  272.  
  273.     IPv6 uses the term "link" to indicate "a communication facility
  274.     or medium over which nodes can communicate at the link layer"
  275.     ([Ref14]).  "Interfaces" connect to links. Multiple IP subnets
  276.     can be assigned    to a single link, and two nodes    can talk
  277.  
  278.  
  279.  
  280. Coltun et al                            [Page 5]
  281.  
  282. Internet Draft             OSPF for IPv6           November 1996
  283.  
  284.  
  285.     directly over a    single link, even if they do not share a common
  286.     IP subnet (IPv6    prefix).
  287.  
  288.     For this reason, OSPF for IPv6 runs per-link instead of    the IPv4
  289.     behavior of per-IP-subnet. The terms "network" and "subnet" used
  290.     in the IPv4 OSPF specification ([Ref1])    should generally be
  291.     relaced    by link. Likewise, an OSPF interface now connects to a
  292.     link instead of    an IP subnet, etc.
  293.  
  294.     This change affects the    receiving of OSPF protocol packets, and
  295.     the contents of    Hello Packets and Network-LSAs.
  296.  
  297.     2.2.  Removal of addressing    semantics
  298.  
  299.     In OSPF    for IPv6, addressing semantics have been removed from
  300.     the OSPF protocol packets and the main LSA types, leaving a
  301.     network-protocol-independent core. In particular:
  302.  
  303.     o   IPv6 Addresses are not present in OSPF packets, except for
  304.         in LSA payloads carried by the Link    State Update Packets.
  305.         See    Section    2.7 for    details.
  306.  
  307.     o   Router-LSAs    and Network-LSAs no longer contain network
  308.         addresses, but simply express topology information.    See
  309.         Section 2.8    for details.
  310.  
  311.     o   OSPF Router    IDs, Area IDs and LSA Link State IDs remain at
  312.         the    IPv4 size of 32-bits. They can no longer be assigned as
  313.         (IPv6) addresses.
  314.  
  315.     o   Neighboring    routers    are now    always identified by Router ID,
  316.         where previously they had been identified by IP address on
  317.         broadcast and NBMA "networks".
  318.  
  319.     2.3.  Addition of Flooding scope
  320.  
  321.     Flooding scope for LSAs    has been generalized and is now
  322.     explicitly coded in the    LSA's LS type field. There are now three
  323.     separate flooding scopes for LSAs:
  324.  
  325.     o   Link-local scope. LSA is flooded only on the local link, and
  326.         no further.    Used for the new Link-LSA (see Section A.4.8).
  327.  
  328.     o   Area scope.    LSA is flooded throughout a single OSPF    area
  329.         only. Used for Router-LSAs,    Network-LSAs, Inter-Area-
  330.         Prefix-LSAs, Inter-Area-Router-LSAs    and Intra-Area-Prefix-
  331.         LSAs.
  332.  
  333.  
  334.  
  335.  
  336. Coltun et al                            [Page 6]
  337.  
  338. Internet Draft             OSPF for IPv6           November 1996
  339.  
  340.  
  341.     o   AS scope. LSA is flooded throughout    the routing domain. Used
  342.         for    AS-external-LSAs.
  343.  
  344.     2.4.  Explicit support for multiple    instances per link
  345.  
  346.     OSPF now supports the ability to run multiple OSPF protocol
  347.     instances on a single link. For    example, this may be required on
  348.     a NAP segment shared between several providers -- providers may
  349.     be running a separate OSPF routing domains that    want to    remain
  350.     separate even though they have one or more physical network
  351.     segments (i.e.,    links) in common. In OSPF for IPv4 this    was
  352.     supported in a haphazard fashion using the authentication fields
  353.     in the OSPF for    IPv4 header.
  354.  
  355.     Another    use for    running    multiple OSPF instances    is if you want,
  356.     for one    reason or another, to have a single link belong    to two
  357.     or more    OSPF areas.
  358.  
  359.     Support    for multiple protocol instances    on a link is
  360.     accomplished via an "Instance ID" contained in the OSPF    packet
  361.     header and OSPF    interface structures. Instance ID solely affects
  362.     the reception of OSPF packets.
  363.  
  364.     2.5.  Use of link-local addresses
  365.  
  366.     IPv6 link-local    addresses are for use on a single link,    for
  367.     purposes of neighbor discovery,    auto-configuration, etc. IPv6
  368.     routers    do not forward IPv6 datagrams having link-local    source
  369.     addresses [Ref15]. Link-local unicast addresses    are assigned
  370.     from the IPv6 address range FF80/10.
  371.  
  372.     OSPF for IPv6 assumes that each    router has been    assigned link-
  373.     local unicast addresses    on each    of the router's    attached
  374.     physical segments. On all OSPF interfaces except virtual links,
  375.     OSPF packets are sent using the    interface's associated link-
  376.     local unicast address as source. A router learns the link-local
  377.     addresses of all other routers attached    to its links, and uses
  378.     these addresses    as next    hop information    during packet
  379.     forwarding.
  380.  
  381.     On virtual links, global scope or site-local IP    addresses must
  382.     be used    as the source for OSPF protocol    packets.
  383.  
  384.     Link-local addresses appear in OSPF Link-LSAs (see Section
  385.     3.4.3.6). However, link-local addresses    are not    allowed    in other
  386.     OSPF LSA types.    In particular, link-local addresses cannot be
  387.     advertised in inter-area-prefix-LSAs (Section 3.4.3.3),    AS-
  388.     external-LSAs (Section 3.4.3.5)    or intra-area-prefix-LSAs
  389.  
  390.  
  391.  
  392. Coltun et al                            [Page 7]
  393.  
  394. Internet Draft             OSPF for IPv6           November 1996
  395.  
  396.  
  397.     (Section 3.4.3.7).
  398.  
  399.     2.6.  Authentication changes
  400.  
  401.     In OSPF    for IPv6, authentication has been removed from OSPF
  402.     itself.    The "AuType" and "Authentication" fields have been
  403.     removed    from the OSPF packet header, and all authentication
  404.     related    fields have been removed from the OSPF area and
  405.     interface structures.
  406.  
  407.     When running over IPv6,    OSPF relies on the IP Authentication
  408.     Header (see [Ref19]) and the IP    Encapsulating Security Payload
  409.     (see [Ref20]) to ensure    integrity and
  410.     authentication/confidentiality of routing exchanges.
  411.  
  412.     2.7.  Packet format    changes
  413.  
  414.     OSPF for IPv6 runs directly over IPv6. Aside from this,    all
  415.     addressing semantics have been removed from the    OSPF packet
  416.     headers, making    it essentially "network-protocol independent".
  417.     All addressing information is now contained in the various LSA
  418.     types only.
  419.  
  420.     In detail, changes in OSPF packet format consist of the
  421.     following:
  422.  
  423.     o   The    OSPF version number has    been increased from 2 to 3.
  424.  
  425.     o   The    Options    field in Hello Packets and Database description
  426.         Packets has    been expanded to 24-bits.
  427.  
  428.     o   The    Authentication and AuType fields have been removed from
  429.         the    OSPF packet header (see    Section    2.6).
  430.  
  431.     o   The    Hello packet now contains no address information at all,
  432.         and    includes a Interface ID    which the originating router has
  433.         assigned to    uniquely identify (among its own interfaces) its
  434.         interface to the link.  This Interface ID becomes the
  435.         Network-LSA's Link State ID, should    the router become
  436.         Designated Router on the link.
  437.  
  438.     o   Two    options    bits, the "R-bit" and the "V6-bit", have been
  439.         added to the Options field for processing Router-LSAs during
  440.         the    SPF calculation    (see Section A.2).  If the "R-bit" is
  441.         clear an OSPF speaker can participate in OSPF topology
  442.         distribution without being used to forward transit traffic;
  443.         this can be    used in    multi-homed hosts that want to
  444.         participate    in the routing protocol. The V6-bit specializes
  445.  
  446.  
  447.  
  448. Coltun et al                            [Page 8]
  449.  
  450. Internet Draft             OSPF for IPv6           November 1996
  451.  
  452.  
  453.         the    R-bit; if the V6-bit is    clear an OSPF speaker can
  454.         participate    in OSPF    topology distribution without being used
  455.         to forward IPv6 datagrams. If the R-bit is set and the V6-
  456.         bit    is clear, IPv6 datagrams are not forwarded but datagrams
  457.         belonging to another protocol family may be    forwarded.
  458.  
  459.     o   The    OSPF packet header now includes    an "Instance ID" which
  460.         allows multiple OSPF protocol instances to be run on a
  461.         single link    (see Section 2.4).
  462.  
  463.     2.8.  LSA format changes
  464.  
  465.     All addressing semantics have been removed from    the LSA    header,
  466.     and from Router-LSAs and Network-LSAs. These two LSAs now
  467.     describe the routing domain's topology in a network-protocol
  468.     independent manner. New    LSAs have been added to    distribute IPv6
  469.     address    information, and data required for next    hop resolution.
  470.     The names of some of IPv4's LSAs have been changed to be more
  471.     consistent with    each other.
  472.  
  473.     In detail, changes in LSA format consist of the    following:
  474.  
  475.     o   The    Options    field has been removed from the    LSA header,
  476.         expanded to    24 bits, and moved into    the body of Router-LSAs,
  477.         Network-LSAs, Inter-Area-Router-LSAs and Link-LSAs.    See
  478.         Section A.2    for details.
  479.  
  480.     o   The    LSA Type field has been    expanded (into the former
  481.         Options space) to 16 bits, with the    upper three bits
  482.         encoding flooding scope and    the handling of    unknown    LSA
  483.         types (see Section 2.9).
  484.  
  485.     o   Addresses in LSAs are now expressed    as [prefix, prefix
  486.         length] instead of [address, mask] (see Section A.4.1). The
  487.         default route is expressed as a prefix with    length 0.
  488.  
  489.     o   The    Router and Network LSAs    now have no address information,
  490.         and    are network-protocol-independent.
  491.  
  492.     o   Router interface information may be    spread across multiple
  493.         Router LSAs. Receivers must    concatenate all    the Router-LSAs
  494.         originated by a given router when running the SPF
  495.         calculation.
  496.  
  497.     o   A new LSA called the Link-LSA has been introduced. The LSAs
  498.         have local-link flooding scope; they are never flooded
  499.         beyond the link that they are associated with. Link-LSAs
  500.         have three purposes: 1) they provide the router's link-local
  501.  
  502.  
  503.  
  504. Coltun et al                            [Page 9]
  505.  
  506. Internet Draft             OSPF for IPv6           November 1996
  507.  
  508.  
  509.         address to all other routers attached to the link and 2)
  510.         they inform    other routers attached to the link of a    list of
  511.         IPv6 prefixes to associate with the    link and 3) they allow
  512.         the    router to assert a collection of Options bits to
  513.         associate with the Network-LSA that    will be    originated for
  514.         the    link. See Section A.4.8    for details.
  515.  
  516.         In IPv4, the router-LSA carries a router's IPv4 interface
  517.         addresses, the IPv4    equivalent of link-local addresses.
  518.         These are only used    when calculating next hops during the
  519.         OSPF routing calculation (see Section 16.1.1 of [Ref1]), so
  520.         they do not    need to    be flooded past    the local link;    hence
  521.         using link-LSAs to distribute these    addresses is more
  522.         efficient. Note that link-local addresses cannot be    learned
  523.         through the    reception of Hellos in all cases: on NBMA links
  524.         next hop routers do    not necessarily    exchange hellos, but
  525.         rather learn of each other's existence by way of the
  526.         Designated Router.
  527.  
  528.     o   The    Options    field in the Network LSA is set    to the logical
  529.         OR of the Options that each    router on the link advertises in
  530.         its    Link-LSA.
  531.  
  532.     o   Type-3 summary-LSAs    have been renamed "Inter-Area-Prefix-
  533.         LSAs". Type-4 summary LSAs have been renamed "Inter-Area-
  534.         Router-LSAs".
  535.  
  536.     o   The    Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-
  537.         Router-LSAs    and AS-external-LSAs has lost its addressing
  538.         semantics, and now serves solely to    identify individual
  539.         pieces of the Link State Database. All addresses or    Router
  540.         IDs    that formerly were expressed by    the Link State ID are
  541.         now    carried    in the LSA bodies.
  542.  
  543.     o   Network-LSAs and Link-LSAs are the only LSAs whose Link
  544.         State ID carries additional    meaning. For these LSAs, the
  545.         Link State ID is always the    Interface ID of    the originating
  546.         router on the link being described.    For this reason,
  547.         Network-LSAs and Link-LSAs are now the only    LSAs that cannot
  548.         be broken into arbitrarily small pieces.
  549.  
  550.     o   A new LSA called the Intra-Area-Prefix-LSA has been
  551.         introduced.    This LSA carries all IPv6 prefix information
  552.         that in IPv4 is included in    Router-LSAs and    Network-LSAs.
  553.         See    Section    A.4.9 for details.
  554.  
  555.     o   Inclusion of a forwarding address in AS-external-LSAs is now
  556.         optional, as is the    inclusion of an    external route tag (see
  557.  
  558.  
  559.  
  560. Coltun et al                               [Page 10]
  561.  
  562. Internet Draft             OSPF for IPv6           November 1996
  563.  
  564.  
  565.         [Ref5]). In    addition, AS-external-LSAs can now reference
  566.         another LSA, for inclusion of additional route attributes
  567.         that are outside the scope of the OSPF protocol itself. For
  568.         example, this can be used to attach    BGP path attributes to
  569.         external routes as proposed    in [Ref10].
  570.  
  571.     2.9.  Handling unknown LSA types
  572.  
  573.     Handling of unknown LSA    types has been made more flexible so
  574.     that, based on LS type,    unknown    LSA types are either treated as
  575.     having link-local flooding scope, or are stored    and flooded as
  576.     if they    were understood    (desirable for things like the proposed
  577.     External Attributes LSA    in [Ref10]). This behavior is explicitly
  578.     coded in the LSA Handling bit of the link state    header's LS type
  579.     field (see Section A.4.2.1).
  580.  
  581.     The IPv4 OSPF behavior of simply discarding unknown types is
  582.     unsupported due    to the desire to mix router capabilities on a
  583.     single link. Discarding    unknown    types causes problems when the
  584.     Designated Router supports fewer options than the other    routers
  585.     on the link.
  586.  
  587.     2.10.  Stub    area support
  588.  
  589.     In OSPF    for IPv4, stub areas were designed to minimize link-
  590.     state database and routing table sizes for the areas' internal
  591.     routers. This allows routers with minimal resources to
  592.     participate in even very large OSPF routing domains.
  593.  
  594.     In OSPF    for IPv6, the concept of stub areas is retained. In
  595.     IPv6, of the mandatory LSA types, stub areas carry only    router-
  596.     LSAs, network-LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and
  597.     Intra-Area-Prefix-LSAs.    This is    the IPv6 equivalent of the LSA
  598.     types carried in IPv4 stub areas: router-LSAs, network-LSAs and
  599.     type 3 summary-LSAs.
  600.  
  601.     However, unlike    in IPv4, IPv6 allows LSAs with unrecognized LS
  602.     types to be labeled "Store  and    flood the LSA, as if type
  603.     understood" (see the U-bit in Section A.4.2.1).    Uncontrolled
  604.     introduction of    such LSAs could    cause a    stub area's link-state
  605.     database to grow larger    than it's component routers' capacities.
  606.     To guard against this, the following rules regarding stub areas
  607.     have been established:
  608.  
  609.     (1) No LSAs with AS flooding scope can be flooded into/within
  610.         stub areas.    This generalizes the rule that AS-external-LSAs
  611.         are    not flooded into/throughout stub areas.
  612.  
  613.  
  614.  
  615.  
  616. Coltun et al                               [Page 11]
  617.  
  618. Internet Draft             OSPF for IPv6           November 1996
  619.  
  620.  
  621.     (2) No LSAs with U-bit set to 1    (flood even when LS type
  622.         unrecognized) should be flooded into/within    stub areas.
  623.  
  624.     Note that a router internal to a stub area may still get
  625.     unrecognized LSA types in its database,    but only when both a)
  626.     the LSAs have link-local or area flooding scope, and b)    the
  627.     router shares a    network    segment    with another router that does
  628.     understand the LSA's type.
  629.  
  630.     2.11.  Identifying neighbors by Router ID
  631.  
  632.     In OSPF    for IPv6, neighboring routers on a given link are always
  633.     identified by their OSPF Router    ID. This contrasts with    the IPv4
  634.     behavior where neighbors on point-to-point networks and    virtual
  635.     links are identified by    their Router IDs, and neighbors    on
  636.     broadcast, NBMA    and Point-to-MultiPoint    links are identified by
  637.     their IPv4 interface addresses.
  638.  
  639.     This change affects the    reception of OSPF packets (see Section
  640.     8.2 of [Ref1]),    the lookup of neighbors    (Section 10 of [Ref1])
  641.     and the    reception of Hello Packets in particular (Section 10.5
  642.     of [Ref1]).
  643.  
  644.     The Router ID of 0.0.0.0 is reserved, and should not be    used.
  645.  
  646.     2.12.  Removal of TOS
  647.  
  648.     The semantics of IPv4 TOS have not been    moved forward to IPv6.
  649.     Therefore, support for TOS in OSPF for IPv6 has    been removed.
  650.     This affects both LSA formats and routing calculations.
  651.  
  652.     The IPv6 header    does have a 24-bit Flow    Label field which may be
  653.     used by    a source to label those    packets    for which it requests
  654.     special    handling by IPv6 routers, such as non-default quality of
  655.     service    or "real-time" service.    The OSPF LSAs for IPv6 have been
  656.     organized so that future extensions to support routing based on
  657.     Flow Label are possible.
  658.  
  659. 3.  Implementation details
  660.  
  661.     When going from IPv4 to IPv6, the basic OSPF mechanisms remain
  662.     unchanged from those documented in [Ref1]. These mechanisms    are
  663.     briefly outlined in    Section    4 of [Ref1]. Both IPv6 and IPv4    have a
  664.     link-state database    composed of LSAs and synchronized between
  665.     adjacent routers. Initial synchronization is performed through the
  666.     Database Exchange process, through the exchange of Database
  667.     Description, Link State Request and    Link State Update packets.
  668.     Thereafter database    synchronization    is maintained via flooding,
  669.  
  670.  
  671.  
  672. Coltun et al                               [Page 12]
  673.  
  674. Internet Draft             OSPF for IPv6           November 1996
  675.  
  676.  
  677.     utilizing Link State Update    and Link State Acknowledgment packets.
  678.     Both IPv6 and IPv4 use OSPF    Hello Packets to disover and maintain
  679.     neighbor relationships, and    to elect Designated Routers and    Backup
  680.     Designated Routers on broadcast and    NBMA links. The    decision as to
  681.     which neighbor relationships become    adjacencies, along with    the
  682.     basic ideas    behind inter-area routing, importing external
  683.     information    in AS-external-LSAs and    the various routing calculations
  684.     are    also the same.
  685.  
  686.     In particular, the following IPv4 OSPF functionality described in
  687.     [Ref1] remains completely unchanged    for IPv6:
  688.  
  689.     o    Both IPv4 and IPv6 use OSPF packet types described in Section
  690.     4.3 of [Ref1], namely: Hello, Database Description, Link State
  691.     Request, Link State Update and Link State Acknowledgment
  692.     packets. While in some cases (e.g., Hello packets) their format
  693.     has changed somewhat, the functions of the various packet types
  694.     remains    the same.
  695.  
  696.     o    The system requirements    for an OSPF implementation remain
  697.     unchanged, although OSPF for IPv6 requires an IPv6 protocol
  698.     stack (from the    network    layer on down) since it    runs directly
  699.     over the IPv6 network layer.
  700.  
  701.     o    The discovery and maintenance of neighbor relationships, and the
  702.     selection and establishment of adjacencies remain the same. This
  703.     includes election of the Designated Router and Backup Designated
  704.     Router on broadcast and    NBMA links. These mechanisms are
  705.     described in Sections 7, 7.1, 7.2, 7.3,    7.4 and    7.5 of [Ref1].
  706.  
  707.     o    The link types (or equivalently, interface types) supported by
  708.     OSPF remain unchanged, namely: point-to-point, broadcast, NBMA,
  709.     Point-to-MultiPoint and    virtual    links.
  710.  
  711.     o    The interface state machine, including the list    of OSPF
  712.     interface states and events, and the Designated    Router and
  713.     Backup Designated Router election algorithm, remain unchanged.
  714.     These are described in Sections    9.1, 9.2, 9.3 and 9.4 of [Ref1].
  715.  
  716.     o    The neighbor state machine, including the list of OSPF neighbor
  717.     states and events, remain unchanged. These are described in
  718.     Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1].
  719.  
  720.     o    Aging of the link-state    database, as well as flushing LSAs from
  721.     the routing domain through the premature aging process,    remains
  722.     unchanged from the description in Sections 14 and 14.1 of
  723.     [Ref1].
  724.  
  725.  
  726.  
  727.  
  728. Coltun et al                               [Page 13]
  729.  
  730. Internet Draft             OSPF for IPv6           November 1996
  731.  
  732.  
  733.     However, some OSPF protocol    mechanisms have    changed, as outlined in
  734.     Section 2 above. These changes are explained in detail in the
  735.     following subsections, making references to    the appropriate    sections
  736.     of [Ref1].
  737.  
  738.     The    following subsections provide a    recipe for turning an IPv4 OSPF
  739.     implementation into    an IPv6    OSPF implementation.
  740.  
  741.     3.1.  Protocol data    structures
  742.  
  743.     The major OSPF data structures are the same for    both IPv4 and
  744.     IPv6:  areas, interfaces, neighbors, the link-state database and
  745.     the routing table. The top-level data structures for IPv6 remain
  746.     those listed in    Section    5 of [Ref1], with the following
  747.     modifications:
  748.  
  749.     o   All    LSAs with known    LS type    and AS flooding    scope appear in
  750.         the    top-level data structure, instead of belonging to a
  751.         specific area or link. AS-external-LSAs are    the only LSAs
  752.         defined by this specification which    have AS    flooding scope.
  753.         LSAs with unknown LS type, U-bit set to 1 (flood even when
  754.         unrecognized) and AS flooding scope    also appear in the top-
  755.         level data structure.
  756.  
  757.     o   Since IPv6 does not    have the concept of TOS, "TOS
  758.         capability"    is not a part of the OSPF fro IPv6
  759.         specification.
  760.  
  761.     3.1.1.    The Area Data structure
  762.  
  763.         The    IPv6 area data structure contains all elements defined
  764.         for    IPv4 areas in Section 6    of [Ref1]. In addition,    all LSAs
  765.         of known type which    have area flooding scope are contained
  766.         in the IPv6    area data structure. This always includes the
  767.         following LSA types: router-LSAs, network-LSAs, inter-area-
  768.         prefix-LSAs, inter-area-router-LSAs    and intra-area-prefix-
  769.         LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even
  770.         when unrecognized) and area    scope also appear in the area
  771.         data structure. IPv6 routers implementing MOSPF add    group-
  772.         membership-LSAs to the area    data structure.    Type-7-LSAs
  773.         belong to an NSSA area's data structure.
  774.  
  775.     3.1.2.    The Interface Data structure
  776.  
  777.         In OSPF for    IPv6, an interface connects a router to    a link.
  778.         The    IPv6 interface structure modifies the IPv4 interface
  779.         structure (as defined in Section 9 of [Ref1]) as follows:
  780.  
  781.  
  782.  
  783.  
  784. Coltun et al                               [Page 14]
  785.  
  786. Internet Draft             OSPF for IPv6           November 1996
  787.  
  788.  
  789.         Interface ID
  790.         Every interface    is assigned an Interface ID, which
  791.         uniquely identifies the    interface with the router. For
  792.         example, some implementations may be able to use the
  793.         MIB-II IfIndex as Interface ID.    The Interface ID appears
  794.         in Hello packets sent out the interface, the link-
  795.         local-LSA originated by    router for the attached    link,
  796.         and the    router-LSA originated by the router-LSA    for the
  797.         associated area. It will also serve as the Link    State ID
  798.         for the    network-LSA that the router will originate for
  799.         the link if the    router is elected Designated Router.
  800.  
  801.         Instance ID
  802.         Every interface    is assigned an Instance    ID. This should
  803.         default    to 0, and is only necessary to assign
  804.         differently on those links that    will contain multiple
  805.         separate communities of    OSPF Routers. For example,
  806.         suppose    that there are two communities of routers on a
  807.         given ethernet segment that you    wish to    keep separate.
  808.         The first community is given an    Instance ID of 0, by
  809.         assigning 0 as the Instance ID of all its routers'
  810.         interfaces to the ethernet. An Instance    ID of 1    is
  811.         assigned to the    other routers' interface to the
  812.         ethernet. The OSPF transmit and    receive    processing (see
  813.         Section    3.2) will then keep the    two communities
  814.         separate.
  815.  
  816.         List of LSAs with link-local scope
  817.         All LSAs with link-local scope and which were
  818.         originated/flooded on the link belong to the interface
  819.         structure which    connects to the    link. This includes the
  820.         collection of the link's link-LSAs.
  821.  
  822.         List of LSAs with unknown LS type
  823.         All LSAs with unknown LS type and U-bit    set to 0 (if
  824.         unrecognized, treat the    LSA as if it had link-local
  825.         flooding scope)    are kept in data structure for the
  826.         interface that received    the LSA.
  827.  
  828.         IP interface address
  829.         For IPv6, the IPv6 address appearing in    the source of
  830.         OSPF packets sent out the interface is almost always a
  831.         link-local address. The    one exception is for virtual
  832.         links, which must use one of the router's own site-local
  833.         or global IPv6 addresses as IP interface address.
  834.  
  835.         List of link prefixes
  836.         A list of IPv6 prefixes    can be configured for the
  837.  
  838.  
  839.  
  840. Coltun et al                               [Page 15]
  841.  
  842. Internet Draft             OSPF for IPv6           November 1996
  843.  
  844.  
  845.         attached link. These will be advertised    by the router in
  846.         link-LSAs, so that they    can be advertised by the link's
  847.         Designated Router in intra-area-prefix-LSAs.
  848.  
  849.         There is only a single interface output cost, as IPv6 has no
  850.         concept of TOS. In addition, OSPF for IPv6 relies on the IP
  851.         Authentication Header (see [Ref19])    and the    IP Encapsulating
  852.         Security Payload (see [Ref20]) to ensure integrity and
  853.         authentication/confidentiality of routing exchanges.  For
  854.         that reason, AuType    and Authentication key are not
  855.         associated with IPv6 OSPF interfaces.
  856.  
  857.         Interface states, events, and the interface    state machine
  858.         remain unchanged from IPv4,    and are    documented in Sections
  859.         9.1, 9.2 and 9.3 of    [Ref1] respectively. The Designated
  860.         Router and Backup Designated Router    election algorithm also
  861.         remains unchanged from the IPv4 election in    Section    9.4 of
  862.         [Ref1].
  863.  
  864.     3.1.3.    The Neighbor Data Structure
  865.  
  866.         The    neighbor structure performs the    same function in both
  867.         IPv6 and IPv4. Namely, it collects all information required
  868.         to form an adjacency between two routers, if an adjacency
  869.         becomes necessary. Each neighbor structure is bound    to a
  870.         single OSPF    interface. The differences between the IPv6
  871.         neighbor structure and the neighbor    structure defined for
  872.         IPv4 in Section 10 of [Ref1] are:
  873.  
  874.         Neighbor's Interface ID
  875.         The Interface ID that the neighbor advertises in its
  876.         Hello Packets must be recorded in the neighbor
  877.         structure. The router will include the neighbor's
  878.         Interface ID in    the router's router-LSA    when either a)
  879.         advertising a point-to-point link to the neighbor or b)
  880.         advertising a link to a    network    where the neighbor has
  881.         become Designated Router.
  882.  
  883.         Neighbor IP    address
  884.         Except on virtual links, the neighbor's    IP address will
  885.         be an IPv6 link-local address.
  886.  
  887.         Neighbor's Designated Router
  888.         The neighbor's choice of Designated Router is now
  889.         encoded    as Router ID, instead of as an IP address.
  890.  
  891.         Neighbor's Backup Designated Router
  892.         The neighbor's choice of Designated Router is now
  893.  
  894.  
  895.  
  896. Coltun et al                               [Page 16]
  897.  
  898. Internet Draft             OSPF for IPv6           November 1996
  899.  
  900.  
  901.         encoded    as Router ID, instead of as an IP address.
  902.  
  903.         Neighbor states, events, and the neighbor state machine
  904.         remain unchanged from IPv4,    and are    documented in Sections
  905.         10.1, 10.2 and 10.3    of [Ref1] respectively.    The decision as
  906.         to which adjacencies to form also remains unchanged    from the
  907.         IPv4 logic documented in Section 10.4 of [Ref1].
  908.  
  909.     3.2.  Protocol Packet Processing
  910.  
  911.     OSPF for IPv6 runs directly over IPv6's    network    layer. As such,
  912.     it is encapsulated in one or more IPv6 headers,    with the Next
  913.     Header field of    the immediately    encapsulating IPv6 header set to
  914.     the value 89. OSPF protocol packets should be given precedence
  915.     over regular IPv6 data traffic,    in both    sending    and receiving.
  916.     as an aid towards accomplishing    this precedence, OSPF routing
  917.     protocol packets are sent with IPv6 Priority field set to 7
  918.     (internet control traffic).
  919.  
  920.     As for IPv4, in    IPv6 OSPF routing protocol packets are sent
  921.     along adjacencies only (with the exception of Hello packets,
  922.     which are used to discover the adjacencies). OSPF packet types
  923.     and functions are the same in both IPv4    and IPv4, encoded by the
  924.     Type field of the standard OSPF    packet header.
  925.  
  926.     3.2.1.    Sending    protocol packets
  927.  
  928.         When an IPv6 router    sends an OSPF routing protocol packet,
  929.         it fills in    the fields of the standard OSPF    for IPv6 packet
  930.         header (see    Section    A.3.1) as follows:
  931.  
  932.         Version #
  933.         Set to 3, the version number of    the protocol as
  934.         documented in this specification.
  935.  
  936.         Type
  937.         The type of OSPF packet, such as Link state Update or
  938.         Hello Packet.
  939.  
  940.         Packet length
  941.         The length of the entire OSPF packet in    bytes, including
  942.         the standard OSPF packet header.
  943.  
  944.         Router ID
  945.         The identity of    the router itself (who is originating
  946.         the packet).
  947.  
  948.  
  949.  
  950.  
  951.  
  952. Coltun et al                               [Page 17]
  953.  
  954. Internet Draft             OSPF for IPv6           November 1996
  955.  
  956.  
  957.         Area ID
  958.         The OSPF area that the packet is being sent into.
  959.  
  960.         Instance ID
  961.         The OSPF Instance ID associated    with the interface that
  962.         the packet is being sent out of.
  963.  
  964.         Checksum
  965.         The standard IP    16-bit one's complement    checksum of the
  966.         entire OSPF packet.
  967.  
  968.         Selection of OSPF routing protocol packets'    IPv6 source and
  969.         destination    addresses is performed identically to the IPv4
  970.         logic in Section 8.1 of [Ref1]. The    IPv6 destination address
  971.         is chosen from among the addresses AllSPFRouters,
  972.         AllDRouters    and the    Neighbor IP address associated with the
  973.         other end of the adjacency (which in IPv6, for all links
  974.         except virtual links, is an    IPv6 link-local    address).
  975.  
  976.         The    sending    of Link    State Request Packets and Link State
  977.         Acknowledgment Packets remains unchanged from the IPv4
  978.         procedures documented in Sections 10.9 and 13.5 of [Ref1]
  979.         respectively. Sending Hello    Packets    is documented in Section
  980.         3.2.1.1, and the sending of    Database Description Packets in
  981.         Section 3.2.1.2. The sending of Link State Update Packets is
  982.         documented in Section 3.5.2.
  983.  
  984.         3.2.1.1.  Sending Hello packets
  985.  
  986.         IPv6 changes the way OSPF Hello    packets    are sent in the
  987.         following ways (compare    to Section 9.5 of [Ref1]):
  988.  
  989.         o   Before the Hello Packet is sent out    an interface,
  990.             the    interface's Interface ID must be copied    into the
  991.             Hello Packet.
  992.  
  993.         o   The    Hello Packet no    longer contains    an IP network
  994.             mask, as OSPF for IPv6 runs    per-link instead of
  995.             per-subnet.
  996.  
  997.         o   The    choice of Designated Router and    Backup
  998.             Designated Router are now indicated    within Hellos by
  999.             their Router IDs, instead of by their IP interface
  1000.             addresses.    Advertising the    Designated Router (or
  1001.             Backup Designated Router) as 0.0.0.0 indicates that
  1002.             the    Designated Router (or Backup Designated    Router)
  1003.             has    not yet    been chosen.
  1004.  
  1005.  
  1006.  
  1007.  
  1008. Coltun et al                               [Page 18]
  1009.  
  1010. Internet Draft             OSPF for IPv6           November 1996
  1011.  
  1012.  
  1013.         o   The    Options    field within Hello packets has moved
  1014.             around, getting larger in the process. More    options
  1015.             bits are now possible. Those that must be set
  1016.             correctly in Hello packets are: The    E-bit is set if
  1017.             and    only if    the interface attaches to a non-stub
  1018.             area, the N-bit is set if and only if the interface
  1019.             attaches to    an NSSA    area (see [Ref9]), and the DC-
  1020.             bit    is set if and only if the router wishes    to
  1021.             suppress the sending of future Hellos over the
  1022.             interface (see [Ref11]). Unrecognized bits in the
  1023.             Hello Packet's Options field should    be cleared.
  1024.  
  1025.         Sending    Hello packets on NBMA networks proceeds    for IPv6
  1026.         in exactly the same way    as for IPv4, as    documented in
  1027.         Section    9.5.1 of [Ref1].
  1028.  
  1029.         3.2.1.2.  Sending Database Description Packets
  1030.  
  1031.         The sending of Database    Description packets differs from
  1032.         Section    10.8 of    [Ref1] in the following    ways:
  1033.  
  1034.         o   The    Options    field within Database Description
  1035.             packets has    moved around, getting larger in    the
  1036.             process. More options bits are now possible. Those
  1037.             that must be set correctly in Database Description
  1038.             packets are: The MC-bit is set if and only if the
  1039.             router is forwarding multicast datagrams according
  1040.             to the MOSPF specification in [Ref7].  Unrecognized
  1041.             bits in the    Database Description Packet's Options
  1042.             field should be cleared.
  1043.  
  1044.     3.2.2.    Receiving protocol packets
  1045.  
  1046.         Whenever an    OSPF protocol packet is    received by the    router
  1047.         it is marked with the interface it was received on.     For
  1048.         routers that have virtual links configured,    it may not be
  1049.         immediately    obvious    which interface    to associate the packet
  1050.         with.  For example,    consider the Router RT11 depicted in
  1051.         Figure 6 of    [Ref1].     If RT11 receives an OSPF protocol
  1052.         packet on its interface to Network N8, it may want to
  1053.         associate the packet with the interface to Area 2, or with
  1054.         the    virtual    link to    Router RT10 (which is part of the
  1055.         backbone).    In the following, we assume that the packet is
  1056.         initially associated with the non-virtual link.
  1057.  
  1058.         In order for the packet to be passed to OSPF for processing,
  1059.         the    following tests    must be    performed on the encapsulating
  1060.         IPv6 headers:
  1061.  
  1062.  
  1063.  
  1064. Coltun et al                               [Page 19]
  1065.  
  1066. Internet Draft             OSPF for IPv6           November 1996
  1067.  
  1068.  
  1069.         o    The packet's IP    destination address must be one    of the
  1070.         IPv6 unicast addresses associated with the receiving
  1071.         interface (this    includes link-local addresses),    or one
  1072.         of the IP multicast addresses AllSPFRouters or
  1073.         AllDRouters.
  1074.  
  1075.         o    The Next Header    field of the immediately encapsulating
  1076.         IPv6 header must specify the OSPF protocol (89).
  1077.  
  1078.         o    Any encapsulating IP Authentication Headers (see
  1079.         [Ref19]) and the IP Encapsulating Security Payloads (see
  1080.         [Ref20]) must be processed and/or verified to ensure
  1081.         integrity and authentication/confidentiality of    OSPF
  1082.         routing    exchanges.
  1083.  
  1084.         o    Locally    originated packets should not be passed    on to
  1085.         OSPF.  That is,    the source IPv6    address    should be
  1086.         examined to make sure this is not a multicast packet
  1087.         that the router    itself generated.
  1088.  
  1089.         After processing the encapsulating IPv6 headers, the OSPF
  1090.         packet header is processed.     The fields specified in the
  1091.         header must    match those configured for the receiving
  1092.         interface.    If they    do not,    the packet should be discarded:
  1093.  
  1094.         o    The version number field must specify protocol version
  1095.         3.
  1096.  
  1097.         o    The standard IP    16-bit one's complement    checksum of the
  1098.         entire OSPF packet must    be verified.
  1099.  
  1100.         o    The Area ID found in the OSPF header must be verified.
  1101.         If both    of the following cases fail, the packet    should
  1102.         be discarded.  The Area    ID specified in    the header must
  1103.         either:
  1104.  
  1105.         (1) Match the Area ID of the receiving interface. In
  1106.             this case, unlike for IPv4,    the IPv6 source    address
  1107.             is not restricted to lie on    the same IP subnet as
  1108.             the    receiving interface. IPv6 OSPF runs per-link,
  1109.             instead of per-IP-subnet.
  1110.  
  1111.         (2) Indicate the backbone.  In this case, the packet has
  1112.             been sent over a virtual link.  The    receiving router
  1113.             must be an area border router, and the Router ID
  1114.             specified in the packet (the source    router)    must be
  1115.             the    other end of a configured virtual link.     The
  1116.             receiving interface    must also attach to the    virtual
  1117.  
  1118.  
  1119.  
  1120. Coltun et al                               [Page 20]
  1121.  
  1122. Internet Draft             OSPF for IPv6           November 1996
  1123.  
  1124.  
  1125.             link's configured Transit area.  If    all of these
  1126.             checks succeed, the    packet is accepted and is from
  1127.             now    on associated with the virtual link (and the
  1128.             backbone area).
  1129.  
  1130.         o    The Instance ID    specified in the OSPF header must match
  1131.         the receiving interface's Instance ID.
  1132.  
  1133.         o    Packets    whose IP destination is    AllDRouters should only
  1134.         be accepted if the state of the    receiving interface is
  1135.         DR or Backup (see Section 9.1).
  1136.  
  1137.         After header processing, the packet    is further processed
  1138.         according to it OSPF packet    type. OSPF packet types    and
  1139.         functions are the same for both IPv4 and IPv6.
  1140.  
  1141.         If the packet type is Hello, it should then    be further
  1142.         processed by the Hello Protocol.  All other    packet types are
  1143.         sent/received only on adjacencies.    This means that    the
  1144.         packet must    have been sent by one of the router's active
  1145.         neighbors. The neighbor is identified by the Router    ID
  1146.         appearing the the received packet's    OSPF header. Packets not
  1147.         matching any active    neighbor are discarded.
  1148.  
  1149.         The    receive    processing of Database Description Packets, Link
  1150.         State Request Packets and Link State Acknowledgment    Packets
  1151.         remains unchanged from the IPv4 procedures documented in
  1152.         Sections 10.6, 10.7    and 13.7 of [Ref1] respectively. The
  1153.         receiving of Hello Packets is documented in    Section    3.2.2.1,
  1154.         and    the receiving of Link State Update Packets is documented
  1155.         in Section 3.5.1.
  1156.  
  1157.         3.2.2.1.  Receiving    Hello Packets
  1158.  
  1159.         The receive processing of Hello    Packets    differs    from
  1160.         Section    10.5 of    [Ref1] in the following    ways:
  1161.  
  1162.         o   On all link    types (e.g., broadcast,    NBMA, point-to-
  1163.             point, etc), neighbors are identified solely by
  1164.             their OSPF Router ID. For all link types except
  1165.             virtual links, the Neighbor    IP address is set to the
  1166.             IPv6 source    address    in the IPv6 header of the
  1167.             received OSPF Hello    packet.
  1168.  
  1169.         o   There is no    longer a Network Mask field in the Hello
  1170.             Packet.
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176. Coltun et al                               [Page 21]
  1177.  
  1178. Internet Draft             OSPF for IPv6           November 1996
  1179.  
  1180.  
  1181.         o   The    neighbor's choice of Designated    Router and
  1182.             Backup Designated Router is    now encoded as an OSPF
  1183.             Router ID instead of an IP interface address.
  1184.  
  1185.     3.3.  The Routing table Structure
  1186.  
  1187.     The routing table used by OSPF for IPv4    is defined in Section 11
  1188.     of [Ref1]. For IPv6 there are analogous    routing    table entries:
  1189.     there are routing table    entries    for IPv6 address prefixes, and
  1190.     also for AS boundary routers. The latter routing table entries
  1191.     are only used to hold intermediate results during the routing
  1192.     table build process (see Section 3.8).
  1193.  
  1194.     Also, to hold the intermediate results during the shortest-path
  1195.     calculation for    each area, there is a separate routing table for
  1196.     each area holding the following    entries:
  1197.  
  1198.     o   An entry for each router in    the area. Routers are identified
  1199.         by their OSPF router ID. These routing table entries hold
  1200.         the    set of shortest    paths through a    given area to a    given
  1201.         router, which in turn allows calculation of    paths to the
  1202.         IPv6 prefixes advertised by    that router in Intra-area-
  1203.         prefix-LSAs. If the    router is also an area-border router,
  1204.         these entries are also used    to calculate paths for inter-
  1205.         area address prefixes. If in addition the router is    the
  1206.         other endpoint of a    virtual    link, the routing table    entry
  1207.         describes the cost and viability of    the virtual link.
  1208.  
  1209.     o   An entry for each transit link in the area.    Transit    links
  1210.         have associated network-LSAs. Both the transit link    and the
  1211.         network-LSA    are identified by a combination    of the
  1212.         Designated Router's    Interface ID on    the link and the
  1213.         Designated Router's    OSPF Router ID.    These routing table
  1214.         entries allow later    calculation of paths to    IP prefixes
  1215.         advertised for the transit link in intra-area-prefix-LSAs.
  1216.  
  1217.     Since IPv6 does    not support the    concept    of Type    of Service
  1218.     (TOS), there are no longer separate sets of paths for each TOS.
  1219.     The rest of the    fields in the IPv4 OSPF    routing    table (see
  1220.     Section    11 of [Ref1]) remain valid for IPv6: Optional
  1221.     capabilities (routers only), path type,    cost, type 2 cost, link
  1222.     state origin, and for each of the equal    cost paths to the
  1223.     destination, the next hop and advertising router (inter-area and
  1224.     AS external paths only).
  1225.  
  1226.     For IPv6, the link-state origin    field in the routing table entry
  1227.     is the router-LSA or network-LSA that has directly or indirectly
  1228.     produced the routing table entry. For example, if the routing
  1229.  
  1230.  
  1231.  
  1232. Coltun et al                               [Page 22]
  1233.  
  1234. Internet Draft             OSPF for IPv6           November 1996
  1235.  
  1236.  
  1237.     table entry describes a    route to an IPv6 prefix, the link state
  1238.     origin is the router-LSA or network-LSA    that is    listed in the
  1239.     body of    the intra-area-prefix-LSA that has produced the    route
  1240.     (see Section A.4.9).
  1241.  
  1242.     3.3.1.    Routing    table lookup
  1243.  
  1244.         Routing table lookup (i.e.,    determining the    best matching
  1245.         routing table entry    during IP forwarding) is the same for
  1246.         IPv6 as for    IPv4, except that Type of Service is not taken
  1247.         into account. The lookup consists of the first three steps
  1248.         of Section 11.1 in [Ref1], ignoring    the last step that
  1249.         concerns only TOS.
  1250.  
  1251.     3.4.  Link State Advertisements
  1252.  
  1253.     For IPv6, the OSPF LSA header has changed slightly, with the LS
  1254.     type field expanding and the Options field being moved into the
  1255.     body of    appropriate LSAs. Also,    the formats of some LSAs have
  1256.     changed    somewhat (namely router-LSAs, network-LSAs and AS-
  1257.     external-LSAs),    while the names    of other LSAs have been    changed
  1258.     (type 3    and 4 summary-LSAs are now inter-area-prefix-LSAs and
  1259.     inter-area-router-LSAs respectively) and additional LSAs have
  1260.     been added (Link-LSAs and Intra-Area-Prefix-LSAs). Since IPv6
  1261.     does not support TOS, TOS is no    longer encoded within LSAs.
  1262.  
  1263.     These changes will be described    in detail in the following
  1264.     subsections.
  1265.  
  1266.     3.4.1.    The LSA    Header
  1267.  
  1268.         In both IPv4 and IPv6, all OSPF LSAs begin with a standard
  1269.         20 byte LSA    header.    However, the contents of this 20 byte
  1270.         header have    changed    in IPv6. The LS    age, Advertising Router,
  1271.         LS Sequence    Number,    LS checksum and    length fields within the
  1272.         LSA    header remain unchanged, as documented in Sections
  1273.         12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of    [Ref1]
  1274.         respectively.  However, the    following fields have changed
  1275.         for    IPv6:
  1276.  
  1277.         Options
  1278.         The Options field has been removed from    the standard 20
  1279.         byte LSA header, and into the body of router-LSAs,
  1280.         network-LSAs, inter-area-router-LSAs and link-LSAs. The
  1281.         size of    the Options field has increased    from 8 to 24
  1282.         bits, and some of the bit definitions have changed (see
  1283.         Section    A.2). In addition a separate PrefixOptions
  1284.         field, 8 bits in length, is attached to    each prefix
  1285.  
  1286.  
  1287.  
  1288. Coltun et al                               [Page 23]
  1289.  
  1290. Internet Draft             OSPF for IPv6           November 1996
  1291.  
  1292.  
  1293.         advertised within the body of an LSA.
  1294.  
  1295.         LS type
  1296.         The size of the    LS type    field has increased from 8 to 16
  1297.         bits, with the top two bits encoding flooding scope and
  1298.         the next bit encoding the handling of unknown LS types.
  1299.         See Section A.4.2.1 for    the current coding of the LS
  1300.         type field.
  1301.  
  1302.         Link State ID
  1303.         Link State ID remains at 32 bits in length, but    except
  1304.         for network-LSAs and link-LSAs,    Link State ID has shed
  1305.         any addressing semantics. For example, an IPv6 router
  1306.         originating multiple AS-external-LSAs could start by
  1307.         assigning the first a Link State ID of 0.0.0.1,    the
  1308.         second a Link State ID of 0.0.0.2, and so on. Instead of
  1309.         the IPv4 behavior of encoding the network number within
  1310.         the AS-external-LSA's Link State ID, the IPv6 Link State
  1311.         ID simply serves as a way to differentiate multiple LSAs
  1312.         originated by the same router.
  1313.  
  1314.         For network-LSAs, the Link State ID is set to the
  1315.         Designated Router's Interface ID on the    link. When a
  1316.         router originates a Link-LSA for a given link, its Link
  1317.         State ID is set    equal to the router's Interface    ID on
  1318.         the link.
  1319.  
  1320.     3.4.2.    The link-state database
  1321.  
  1322.         In IPv6, as    in IPv4, individual LSAs are identified    by a
  1323.         combination    of their LS type, Link State ID    and Advertising
  1324.         Router fields. Given two instances of an LSA, the most
  1325.         recent instance is determined by examining the LSAs' LS
  1326.         Sequence Number, using LS checksum and LS age as tiebreakers
  1327.         (see Section 13.1 of [Ref1]).
  1328.  
  1329.         In IPv6, the link-state database is    split across three
  1330.         separate data structures. LSAs with    AS flooding scope are
  1331.         contained within the top-level OSPF    data structure (see
  1332.         Section 3.1) as long as either their LS type is known or
  1333.         their U-bit    is 1 (flood even when unrecognized); this
  1334.         includes the AS-external-LSAs. LSAs    with area flooding scope
  1335.         are    contained within the appropriate area structure    (see
  1336.         Section 3.1.1) as long as either their LS type is known or
  1337.         their U-bit    is 1 (flood even when unrecognized); this
  1338.         includes router-LSAs, network-LSAs,    inter-area-prefix-LSAs,
  1339.         inter-area-router-LSAs, and    intra-area-prefix-LSAs.    LSAs
  1340.         with unknown LS type and U-bit set to 0 and/or link-local
  1341.  
  1342.  
  1343.  
  1344. Coltun et al                               [Page 24]
  1345.  
  1346. Internet Draft             OSPF for IPv6           November 1996
  1347.  
  1348.  
  1349.         flooding scope are contained within    the appropriate
  1350.         interface structure    (see Section 3.1.2); this includes
  1351.         link-LSAs.
  1352.  
  1353.         To lookup or install an LSA    in the database, you first
  1354.         examine the    LS type    and the    LSA's context (i.e., to    which
  1355.         area or link does the LSA belong). This information    allows
  1356.         you    to find    the correct list of LSAs, all of the same LS
  1357.         type, where    you then search    based on the LSA's Link    State ID
  1358.         and    Advertising Router.
  1359.  
  1360.     3.4.3.    Originating LSAs
  1361.  
  1362.         The    process    of reoriginating an LSA    in IPv6    is the same as
  1363.         in IPv4:  the LSA's    LS sequence number is incremented, its
  1364.         LS age is set to 0,    its LS checksum    is calculated, and the
  1365.         LSA    is added to the    link state database and    flooded    out the
  1366.         appropriate    interfaces.
  1367.  
  1368.         To the list    of events causing LSAs to be reoriginated, which
  1369.         for    IPv4 is    given in Section 12.4 of [Ref1], the following
  1370.         events are added for IPv6:
  1371.  
  1372.         o    The Interface ID of a neighbor changes.    This may cause a
  1373.         new instance of    a router-LSA to    be originated for the
  1374.         associated area.
  1375.  
  1376.         o    A new prefix is    added to an attached link, or a    prefix
  1377.         is deleted (both through configuration). This causes the
  1378.         router to reoriginate its link-LSA for the link, or, if
  1379.         it is the only router attached to the link, causes the
  1380.         router to reoriginate an intra-area-prefix-LSA.
  1381.  
  1382.         o    A new link-LSA is received, causing the    link's
  1383.         collection of prefixes to change. If the router    is
  1384.         Designated Router for the link,    it originates a    new
  1385.         intra-area-prefix-LSA.
  1386.  
  1387.         Detailed construction of the seven required    IPv6 LSA types
  1388.         is supplied    by the following subsections. In order to
  1389.         display example LSAs, the network map in Figure 15 of [Ref1]
  1390.         has    been reworked to show IPv6 addressing, resulting in
  1391.         Figure 1. The OSPF cost of each interface is has been
  1392.         displayed in Figure    1. The assignment of IPv6 prefixes to
  1393.         network links is shown in Table 1. A single    area address
  1394.         range has been configured for Area 1, so that outside of
  1395.         Area 1 all of its prefixes are covered by a    single route to
  1396.         5f00:0000:c001::/48. The OSPF interface IDs    and the    link-
  1397.  
  1398.  
  1399.  
  1400. Coltun et al                               [Page 25]
  1401.  
  1402. Internet Draft             OSPF for IPv6           November 1996
  1403.  
  1404.  
  1405.         local addresses for    the router interfaces in Figure    1 are
  1406.         given in Table 2.
  1407.  
  1408.  
  1409.  
  1410.                Network   IPv6 prefix
  1411.                __________________________________
  1412.                N1         5f00:0000:0c01:0200::/56
  1413.                N2         5f00:0000:0c01:0300::/56
  1414.                N3         5f00:0000:0c01:0100::/56
  1415.                N4         5f00:0000:0c01:0400::/56
  1416.  
  1417.  
  1418.              Table 1: IPv6 link    prefixes for sample network
  1419.  
  1420.  
  1421.  
  1422.  
  1423.  
  1424.  
  1425.  
  1426.           ..........................................
  1427.           .                     Area 1.
  1428.           .    +                   .
  1429.           .    |                   .
  1430.           .    | 3+---+1               .
  1431.           .  N1    |--|RT1|-----+               .
  1432.           .    |  +---+      \               .
  1433.           .    |           \  ______       .
  1434.           .    +        \/     \    1+---+
  1435.           .            *    N3      *------|RT4|------
  1436.           .    +        /\_______/     +---+
  1437.           .    |           /     |           .
  1438.           .    | 3+---+1     /         |           .
  1439.           .  N2    |--|RT2|-----+        1|           .
  1440.           .    |  +---+       +---+       .
  1441.           .    |           |RT3|----------------
  1442.           .    +           +---+       .
  1443.           .                 |2           .
  1444.           .                 |           .
  1445.           .              +------------+       .
  1446.           .                 N4           .
  1447.           ..........................................
  1448.  
  1449.  
  1450.             Figure 1: Area 1 with IP addresses shown
  1451.  
  1452.  
  1453.  
  1454.  
  1455.  
  1456. Coltun et al                               [Page 26]
  1457.  
  1458. Internet Draft             OSPF for IPv6           November 1996
  1459.  
  1460.  
  1461.  
  1462.          Router      interface   Interface    ID   link-local    address
  1463.          ______________________________________________________
  1464.          RT1      to N1          1             fe80:0001::RT1
  1465.               to N3          2             fe80:0002::RT1
  1466.          RT2      to N2          1             fe80:0001::RT2
  1467.               to N3          2             fe80:0002::RT2
  1468.          RT3      to N3          1             fe80:0001::RT3
  1469.               to N4          2             fe80:0002::RT3
  1470.          RT4      to N3          1             fe80:0001::RT4
  1471.  
  1472.  
  1473.           Table    2: OSPF    Interface IDs and link-local addresses
  1474.  
  1475.  
  1476.         3.4.3.1.  Router-LSAs
  1477.  
  1478.         The LS type of a router-LSA is set to the value    0x2001.
  1479.         Router-LSAs have area flooding scope. A    router may
  1480.         originate one or more router-LSAs for a    given area.
  1481.         Taken together,    the collection of router-LSAs originated
  1482.         by the router for an area describes the    collected states
  1483.         of all the router's interface to the area. When    multiple
  1484.         router-LSAs are    used, they are distinguished by    their
  1485.         Link State ID fields.
  1486.  
  1487.         The Options field in the router-LSA should be coded as
  1488.         follows. The V6-bit should be set. The E-bit should be
  1489.         clear if and only if the area is an OSPF stub area. The
  1490.         MC-bit should be set if    and only if the    router is
  1491.         running    MOSPF (see [Ref8]). The    N-bit should be    set if
  1492.         and only if the    area is    an OSPF    NSSA area. The R-bit
  1493.         should be set. The DC-bit should be set    if and only if
  1494.         the router can correctly process the DoNotAge bit when
  1495.         it appears in the LS age field of LSAs (see [Ref11]).
  1496.         All unrecognized bits in the Options field should be
  1497.         cleared
  1498.  
  1499.         To the left of the Options field, the router capability
  1500.         bits V,    E and B    should be coded    according to Section
  1501.         12.4.1 of [Ref1]. Bit W    should be coded    according to
  1502.         [Ref8].
  1503.  
  1504.         Each of    the router's interfaces    to the area are    then
  1505.         described by appending "link descriptions" to the
  1506.         router-LSA. Each link description is 16    bytes long,
  1507.         consisting of 5    fields:    (link) Type, Metric, Interface
  1508.         ID, Neighbor Interface ID and Neighbor Router ID (see
  1509.  
  1510.  
  1511.  
  1512. Coltun et al                               [Page 27]
  1513.  
  1514. Internet Draft             OSPF for IPv6           November 1996
  1515.  
  1516.  
  1517.         Section    A.4.3).    Interfaces in state "Down" or "Loopback"
  1518.         are not    described (although looped back    interfaces can
  1519.         contribute prefixes to Intra-Area-Prefix-LSAs).    Nor are
  1520.         interfaces without any full adjacencies    described. All
  1521.         other interfaces to the    area add zero, one or more link
  1522.         descriptions, the number and content of    which depend on
  1523.         the interface type. Within each    link description, the
  1524.         Metric field is    always set the interface's output cost
  1525.         and the    Interface ID field is set to the interface's
  1526.         OSPF Interface ID.
  1527.  
  1528.         Point-to-point interfaces
  1529.             If the neighboring router is fully adjacent, add a
  1530.             Type 1 link    description (point-to-point). The
  1531.             Neighbor Interface ID field    is set to the Interface
  1532.             ID advertised by the neighbor in its Hello packets,
  1533.             and    the Neighbor Router ID field is    set to the
  1534.             neighbor's Router ID.
  1535.  
  1536.         Broadcast and NBMA interfaces
  1537.             If the router is fully adjacent to the link's
  1538.             Designated Router, or if the router    itself is
  1539.             Designated Router and is fully adjacent to at least
  1540.             one    other router, add a single Type    2 link
  1541.             description    (transit network). The Neighbor
  1542.             Interface ID field is set to the Interface ID
  1543.             advertised by the Designated Router    in its Hello
  1544.             packets, and the Neighbor Router ID    field is set to
  1545.             the    Designated Router's Router ID.
  1546.  
  1547.         Virtual    links
  1548.             If the neighboring router is fully adjacent, add a
  1549.             Type 4 link    description (virtual). The Neighbor
  1550.             Interface ID field is set to the Interface ID
  1551.             advertised by the neighbor in its Hello packets, and
  1552.             the    Neighbor Router    ID field is set    to the
  1553.             neighbor's Router ID. Note that the    output cost of a
  1554.             virtual link is calculated during the routing table
  1555.             calculation    (see Section 3.7).
  1556.  
  1557.         Point-to-MultiPoint interfaces
  1558.             For    each fully adjacent neighbor associated    with the
  1559.             interface, add a separate Type 1 link description
  1560.             (point-to-point) with Neighbor Interface ID    field
  1561.             set    to the Interface ID advertised by the neighbor
  1562.             in its Hello packets, and Neighbor Router ID field
  1563.             set    to the neighbor's Router ID.
  1564.  
  1565.  
  1566.  
  1567.  
  1568. Coltun et al                               [Page 28]
  1569.  
  1570. Internet Draft             OSPF for IPv6           November 1996
  1571.  
  1572.  
  1573.         As an example, consider    the router-LSA that router RT3
  1574.         would originate    for Area 1 in Figure 1.    Only a single
  1575.         interface must be described, namely that which connects
  1576.         to the transit network N3. It assumes that RT4 has bee
  1577.         elected    Designated Router of Network N3.
  1578.  
  1579.           ; RT3's router-LSA for Area 1
  1580.  
  1581.           LS age = 0             ;newly    (re)originated
  1582.           LS type = 0x2001         ;router-LSA
  1583.           Link State ID    = 0         ;first    fragment
  1584.           Advertising Router = 192.1.1.3 ;RT3's    Router ID
  1585.           bit E    = 0             ;not an AS boundary router
  1586.           bit B    = 1             ;area border router
  1587.           Options = (V6-bit|E-bit|R-bit)
  1588.               Type = 2               ;connects to    N3
  1589.               Metric = 1           ;cost to N3
  1590.               Interface    ID = 1           ;RT3's Interface ID on N3
  1591.               Neighbor Interface ID = 1       ;RT4's Interface ID on N3
  1592.               Neighbor Router ID = 192.1.1.4 ; RT4's Router ID
  1593.  
  1594.         If for example another router was added    to Network N4,
  1595.         RT3 would have to advertise a second link description
  1596.         for its    connection to (the now transit)    network    N4. This
  1597.         could be accomplished by reoriginating the above
  1598.         router-LSA, this time with two link descriptions. Or, a
  1599.         separate router-LSA could be originated    with a separate
  1600.         Link State ID (e.g., using a Link State    ID of 1) to
  1601.         describe the connection    to N4.
  1602.  
  1603.         Host routes no longer appear in    the router-LSA,    but are
  1604.         instead    included in intra-area-prefix-LSAs.
  1605.  
  1606.         3.4.3.2.  Network-LSAs
  1607.  
  1608.         The LS type of a network-LSA is    set to the value 0x2002.
  1609.         Network-LSAs have area flooding    scope. A network-LSA is
  1610.         originated for every transit broadcast or NBMA link, by
  1611.         the link's Designated Router. Transit links are    those
  1612.         that have two or more attached routers.    The network-LSA
  1613.         lists all routers attached to the link.
  1614.  
  1615.         The procedure for originating network-LSAs in IPv6 is
  1616.         the same as the    IPv4 procedure documented in Section
  1617.         12.4.2 of [Ref1], with the following exceptions:
  1618.  
  1619.         o   An IPv6 network-LSA's Link State ID    is set to the
  1620.             Interface ID of the    Designated Router on the link.
  1621.  
  1622.  
  1623.  
  1624. Coltun et al                               [Page 29]
  1625.  
  1626. Internet Draft             OSPF for IPv6           November 1996
  1627.  
  1628.  
  1629.         o   IPv6 network-LSAs do not contain a Network Mask. All
  1630.             addressing information formerly contained in the
  1631.             IPv4 network-LSA has now been consigned to intra-
  1632.             Area-Prefix-LSAs.
  1633.  
  1634.         o   The    Options    field in the network-LSA is set    to the
  1635.             logical OR of the Options fields contained within
  1636.             the    link's associated link-LSAs.  In this way, the
  1637.             network link exhibits a capability when at least one
  1638.             of the link's routers requests that    the capability
  1639.             be asserted.
  1640.  
  1641.         As an example, assuming    that Router RT4    has been elected
  1642.         Designated Router of Network N3    in Figure 1, the
  1643.         following network-LSA is originated:
  1644.  
  1645.           ; Network-LSA    for Network N3
  1646.  
  1647.           LS age = 0             ;newly    (re)originated
  1648.           LS type = 0x2002         ;network-LSA
  1649.           Link State ID    = 1         ;RT4's    Interface ID on    N3
  1650.           Advertising Router = 192.1.1.4 ;RT4's    Router ID
  1651.           Options = (V6-bit|E-bit|R-bit)
  1652.              Attached Router = 192.1.1.4    ;Router    ID
  1653.              Attached Router = 192.1.1.1    ;Router    ID
  1654.              Attached Router = 192.1.1.2    ;Router    ID
  1655.              Attached Router = 192.1.1.3    ;Router    ID
  1656.  
  1657.         3.4.3.3.  Inter-Area-Prefix-LSAs
  1658.  
  1659.         The LS type of an inter-area-prefix-LSA    is set to the
  1660.         value 0x2003. Inter-area-prefix-LSAs have area flooding
  1661.         scope. In IPv4,    inter-area-prefix-LSAs were called type
  1662.         3 summary-LSAs.    Each inter-area-prefix-LSA describes a
  1663.         prefix external    to the area, yet internal to the
  1664.         Autonomous System.
  1665.  
  1666.         The procedure for originating inter-area-prefix-LSAs in
  1667.         IPv6 is    the same as the    IPv4 procedure documented in
  1668.         Sections 12.4.3    and 12.4.3.1 of    [Ref1],    with the
  1669.         following exceptions:
  1670.  
  1671.         o   The    Link State ID of an inter-area-prefix-LSA has
  1672.             lost all of    its addressing semantics, and instead
  1673.             simply serves to distinguish multiple inter-area-
  1674.             prefix-LSAs    that are originated by the same    router.
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680. Coltun et al                               [Page 30]
  1681.  
  1682. Internet Draft             OSPF for IPv6           November 1996
  1683.  
  1684.  
  1685.         o   The    prefix is described by the PrefixLength,
  1686.             PrefixOptions and Address Prefix fields embedded
  1687.             within the LSA body. Network Mask is no longer
  1688.             specified.
  1689.  
  1690.         o   The    NU-bit in the PrefixOptions field should be
  1691.             clear. The coding of the MC-bit depends upon
  1692.             whether, and if so how, MOSPF is operating in the
  1693.             routing domain (see    [Ref8]).
  1694.  
  1695.         o   Link-local addresses can never be advertised in
  1696.             inter-area-prefix-LSAs.
  1697.  
  1698.         As an example, the following shows the inter-area-
  1699.         prefix-LSA that    Router RT4 originates into the OSPF
  1700.         backbone area, condensing all of Area 1's prefixes into
  1701.         the single prefix 5f00:0000:c001::/48. The cost    is set
  1702.         to 4, which is the maximum cost    to all of the prefix'
  1703.         individual components. The prefix is padded out    to an
  1704.         even number of 32-bit words, so    that it    consumes 64-bits
  1705.         of space instead of 48 bits.
  1706.  
  1707.           ; Inter-area-prefix-LSA for Area 1 addresses
  1708.           ; originated by Router RT4 into the backbone
  1709.  
  1710.           LS age = 0              ;newly (re)originated
  1711.           LS type = 0x2003          ;inter-area-prefix-LSA
  1712.           Advertising Router = 192.1.1.4       ;RT4's ID
  1713.           Metric = 4              ;maximum to components
  1714.           PrefixLength = 48
  1715.           PrefixOptions    = 0
  1716.           Address Prefix = 5f00:0000:c001 ;padded to 64-bits
  1717.  
  1718.         3.4.3.4.  Inter-Area-Router-LSAs
  1719.  
  1720.         The LS type of an inter-area-router-LSA    is set to the
  1721.         value 0x2004. Inter-area-router-LSAs have area flooding
  1722.         scope. In IPv4,    inter-area-router-LSAs were called type
  1723.         4 summary-LSAs.    Each inter-area-router-LSA describes a
  1724.         path to    a destination OSPF router (an ASBR) that is
  1725.         external to the    area, yet internal to the Autonomous
  1726.         System.
  1727.  
  1728.         The procedure for originating inter-area-router-LSAs in
  1729.         IPv6 is    the same as the    IPv4 procedure documented in
  1730.         Section    12.4.3 of [Ref1], with the following exceptions:
  1731.  
  1732.  
  1733.  
  1734.  
  1735.  
  1736. Coltun et al                               [Page 31]
  1737.  
  1738. Internet Draft             OSPF for IPv6           November 1996
  1739.  
  1740.  
  1741.         o   The    Link State ID of an inter-area-router-LSA is no
  1742.             longer the destination router's OSPF Router    ID, but
  1743.             instead simply serves to distinguish multiple
  1744.             inter-area-router-LSAs that    are originated by the
  1745.             same router. The destination router's Router ID is
  1746.             now    found in the body of the LSA.
  1747.  
  1748.         o   The    Options    field in an inter-area-router-LSA should
  1749.             be set equal to the    Options    field contained    in the
  1750.             destination    router's own router-LSA. The Options
  1751.             field thus describes the capabilities supported by
  1752.             the    destination router.
  1753.  
  1754.         As an example, consider    the OSPF Autonomous System
  1755.         depicted in Figure 6 of    [Ref1].    Router RT4 would
  1756.         originate into Area 1 the following inter-area-router-
  1757.         LSA for    destination router RT7.
  1758.  
  1759.           ; inter-area-router-LSA for AS boundary router RT7
  1760.           ; originated by Router RT4 into Area 1
  1761.  
  1762.           LS age = 0              ;newly (re)originated
  1763.           LS type = 0x2004          ;inter-area-router-LSA
  1764.           Advertising Router = 192.1.1.4  ;RT4's ID
  1765.           Options = (V6-bit|E-bit|R-bit)  ;RT7's capabilities
  1766.           Metric = 14              ;cost    to RT7
  1767.           Destination Router ID    = Router RT7's ID
  1768.  
  1769.         3.4.3.5.  AS-external-LSAs
  1770.  
  1771.         The LS type of an AS-external-LSA is set to the    value
  1772.         0x4005.    AS-external-LSAs have AS flooding scope. Each
  1773.         AS-external-LSA    describes a path to a prefix external to
  1774.         the Autonomous System.
  1775.  
  1776.         The procedure for originating AS-external-LSAs in IPv6
  1777.         is the same as the IPv4    procedure documented in    Section
  1778.         12.4.4 of [Ref1], with the following exceptions:
  1779.  
  1780.         o   The    Link State ID of an AS-external-LSA has    lost all
  1781.             of its addressing semantics, and instead simply
  1782.             serves to distinguish multiple AS-external-LSAs that
  1783.             are    originated by the same router.
  1784.  
  1785.         o   The    prefix is described by the PrefixLength,
  1786.             PrefixOptions and Address Prefix fields embedded
  1787.             within the LSA body. Network Mask is no longer
  1788.             specified.
  1789.  
  1790.  
  1791.  
  1792. Coltun et al                               [Page 32]
  1793.  
  1794. Internet Draft             OSPF for IPv6           November 1996
  1795.  
  1796.  
  1797.         o   The    NU-bit in the PrefixOptions field should be
  1798.             clear. The coding of the MC-bit depends upon
  1799.             whether, and if so how, MOSPF is operating in the
  1800.             routing domain (see    [Ref8]).
  1801.  
  1802.         o   Link-local addresses can never be advertised in AS-
  1803.             external-LSAs.
  1804.  
  1805.         o   The    forwarding address is present in the AS-
  1806.             external-LSA if and    only if    the AS-external-LSA's
  1807.             bit    F is set.
  1808.  
  1809.         o   The    external route tag is present in the AS-
  1810.             external-LSA if and    only if    the AS-external-LSA's
  1811.             bit    T is set.
  1812.  
  1813.         o   The    capability for an AS-external-LSA to reference
  1814.             another LSA    has been included, by inclusion    of the
  1815.             Referenced LS Type field and the optional Referenced
  1816.             Link State ID field    (the latter present if and only
  1817.             if Referenced LS Type is non-zero).    This capability
  1818.             is for future use; for now Referenced LS Type should
  1819.             be set to 0.
  1820.  
  1821.         As an example, consider    the OSPF Autonomous System
  1822.         depicted in Figure 6 of    [Ref1].    Assume that RT7    has
  1823.         learned    its route to N12 via BGP, and that it wishes to
  1824.         advertise a Type 2 metric into the AS.    Further    assume
  1825.         the the    IPv6 prefix for    N12 is the value
  1826.         5f00:0000:0a00::/40.  RT7 would    then originate the
  1827.         following AS-external-LSA for the external network N12.
  1828.         Note that within the AS-external-LSA, N12's prefix
  1829.         occupies 64 bits of space, to maintain 32-bit alignment.
  1830.  
  1831.           ; AS-external-LSA for    Network    N12,
  1832.           ; originated by Router RT7
  1833.  
  1834.           LS age = 0              ;newly (re)originated
  1835.           LS type = 0x4005          ;AS-external-LSA
  1836.           Link State ID    = 123          ;or something else
  1837.           Advertising Router = Router RT7's ID
  1838.           bit E    = 1              ;Type 2 metric
  1839.           bit F    = 0              ;no forwarding address
  1840.           bit T    = 1              ;external    route tag included
  1841.           Metric = 2
  1842.           PrefixLength = 40
  1843.           PrefixOptions    = 0
  1844.           Referenced LS    Type = 0      ;no Referenced Link State    ID
  1845.  
  1846.  
  1847.  
  1848. Coltun et al                               [Page 33]
  1849.  
  1850. Internet Draft             OSPF for IPv6           November 1996
  1851.  
  1852.  
  1853.           Address Prefix = 5f00:0000:0a00 ;padded to 64-bits
  1854.           External Route Tag = as per BGP/OSPF interaction
  1855.  
  1856.         3.4.3.6.  Link-LSAs
  1857.  
  1858.         The LS type of a Link-LSA is set to the    value 0x0008.
  1859.         Link-LSAs have link-local flooding scope. A router
  1860.         originates a separate Link-LSA for each    attached link
  1861.         that supports 2    or more    (including the originating
  1862.         router itself) routers.
  1863.  
  1864.         Link-LSAs have three purposes: 1) they provide the
  1865.         router's link-local address to all other routers
  1866.         attached to the    link and 2) they inform    other routers
  1867.         attached to the    link of    a list of IPv6 prefixes    to
  1868.         associate with the link    and 3) they allow the router to
  1869.         assert a collection of Options bits in the Network-LSA
  1870.         that will be originated    for the    link.
  1871.  
  1872.         A Link-LSA for a given Link L is built in the following
  1873.         fashion:
  1874.  
  1875.         o   The    Link State ID is set to    the router's Interface
  1876.             ID on Link L.
  1877.  
  1878.         o   The    Router Priority    of the router's    interface to
  1879.             Link L is inserted into the    Link-LSA.
  1880.  
  1881.         o   The    Link-LSA's Options field is set    to those bits
  1882.             that the router wishes set in Link L's Network LSA.
  1883.  
  1884.         o   The    router inserts its link-local address on Link L
  1885.             into the Link-LSA. This information    will be    used
  1886.             when the other routers on Link L do    their next hop
  1887.             calculations (see Section 3.8.1.1).
  1888.  
  1889.         o   Each IPv6 address prefix that has been configured
  1890.             into the router for    Link L is added    to the Link-LSA,
  1891.             by specifying values for PrefixLength,
  1892.             PrefixOptions, and Address Prefix fields.
  1893.  
  1894.         After building a Link-LSA for a    given link, the    router
  1895.         installs the link-LSA into the associate interface data
  1896.         structure and floods the Link-LSA onto the link. All
  1897.         other routers on the link will receive the Link-LSA, but
  1898.         it will    go no further.
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904. Coltun et al                               [Page 34]
  1905.  
  1906. Internet Draft             OSPF for IPv6           November 1996
  1907.  
  1908.  
  1909.         As an example, consider    the Link-LSA that RT3 will build
  1910.         for N3 in Figure 1. Suppose that the prefix
  1911.         5f00:0000:0c01:0100::/56 has been configured within RT3
  1912.         for N3.    This will give rise to the following Link-LSA,
  1913.         which RT3 will flood onto N3, but nowhere else.    Note
  1914.         that not all routers on    N3 need    be configured with the
  1915.         prefix;    those not configured will learn    the prefix when
  1916.         receiving RT3's    Link-LSA.
  1917.  
  1918.           ; RT3's Link-LSA for N3
  1919.  
  1920.           LS age = 0              ;newly (re)originated
  1921.           LS type = 0x0008          ;Link-LSA
  1922.           Link State ID    = 1          ;RT3's Interface ID on N3
  1923.           Advertising Router = 192.1.1.3 ;RT3's    Router ID
  1924.           Rtr Pri = 1              ;RT3's N3    Router Priority
  1925.           Options = (V6-bit|E-bit|R-bit)
  1926.           Link-local Interface Address = fe80:0001::RT3
  1927.           # prefixes = 1
  1928.           PrefixLength = 56
  1929.           PrefixOptions    = 0
  1930.           Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits
  1931.  
  1932.         3.4.3.7.  Intra-Area-Prefix-LSAs
  1933.  
  1934.         The LS type of an intra-area-prefix-LSA    is set to the
  1935.         value 0x2009. Intra-area-prefix-LSAs have area flooding
  1936.         scope. An intra-area-prefix-LSA    has one    of two
  1937.         functions. It associates a list    of IPv6    address    prefixes
  1938.         with a transit network link by referencing a network-
  1939.         LSA, or    associates a list of IPv6 address prefixes with
  1940.         a router by referencing    a router-LSA. A    sub network
  1941.         link's prefixes    are associated with its    attached router.
  1942.  
  1943.         A router may originate multiple    intra-area-prefix-LSAs
  1944.         for a given area, distinguished    by their Link State ID
  1945.         fields.
  1946.  
  1947.         A network link's Designated Router originates an intra-
  1948.         area-prefix-LSA    to advertise the link's    prefixes
  1949.         throughout the area. For a link    L, L's Designated Router
  1950.         builds an intra-area-prefix-LSA    in the following
  1951.         fashion:
  1952.  
  1953.         o   In order to    indicate that the prefixes are to be
  1954.             associated with the    Link L,    the fields Referenced LS
  1955.             type, Referenced Link State    ID, and    Referenced
  1956.             Advertising    Router are set to the corresponding
  1957.  
  1958.  
  1959.  
  1960. Coltun et al                               [Page 35]
  1961.  
  1962. Internet Draft             OSPF for IPv6           November 1996
  1963.  
  1964.  
  1965.             fields in Link L's Network LSA (namely LS type, Link
  1966.             State ID, and Advertising Router respectively). This
  1967.             means that Referenced LS Type is set to 0x2002,
  1968.             Referenced Link State ID is    set to the Designated
  1969.             Router's Interface ID on Link L, and Referenced
  1970.             Advertising    Router is set to the Designated    Router's
  1971.             Router ID.
  1972.  
  1973.         o   Each Link-LSA associated with Link L is examined
  1974.             (these are in the Designated Router's interface
  1975.             structure for Link L). If the Link-LSA's Advertising
  1976.             Router is fully adjacent to    the Designated Router,
  1977.             the    list of    prefixes in the    Link-LSA is copied into
  1978.             the    intra-area-prefix-LSA that is being built.
  1979.             Prefixes having the    NU-bit and/or LA-bit set in
  1980.             their Options field    should not be copied, nor should
  1981.             link-local addresses be copied.  Each prefix is
  1982.             described by the PrefixLength, PrefixOptions, and
  1983.             Address Prefix fields. Multiple prefixes having the
  1984.             same PrefixLength and Address Prefix are considered
  1985.             to be duplicates; in this case their Prefix    Options
  1986.             fields should be merged by logically OR'ing    the
  1987.             fields together, and a single resulting prefix
  1988.             should be copied into the intra-area-prefix-LSA. The
  1989.             Metric field for all prefixes is set to 0.
  1990.  
  1991.         o   The    "# prefixes" field is set to the number    of
  1992.             prefixes that the router has copied    into the LSA. If
  1993.             necessary, the list    of prefixes can    be spread across
  1994.             multiple intra-area-prefix-LSAs in order to    keep the
  1995.             LSA    size small.
  1996.  
  1997.         A router builds    an intra-area-prefix-LSA to advertise
  1998.         its own    prefixes, and those of its attached stub network
  1999.         links. A Router    RTX would build    its intra-area-prefix-
  2000.         LSA in the following fashion:
  2001.  
  2002.         o   In order to    indicate that the prefixes are to be
  2003.             associated with the    Router RTX itself, RTX sets
  2004.             Referenced LS type to 0x2001, Referenced Link State
  2005.             ID to 0, and Referenced Advertising    Router to RTX's
  2006.             own    Router ID.
  2007.  
  2008.         o   Router RTX examines    its list of interfaces to the
  2009.             area. If the interface is in state Down, its
  2010.             prefixes are not included. If the interface    has been
  2011.             reported in    RTX's router-LSA as a Type 2 link
  2012.             description    (link to transit network), its prefixes
  2013.  
  2014.  
  2015.  
  2016. Coltun et al                               [Page 36]
  2017.  
  2018. Internet Draft             OSPF for IPv6           November 1996
  2019.  
  2020.  
  2021.             are    not included (they will    be included in the
  2022.             intra-area-prefix-LSA for the link instead). If the
  2023.             interface type is point-to-point or    Point-to-
  2024.             MultiPoint,    or the interface is in state Loopback,
  2025.             the    site-local and global scope IPv6 addresses
  2026.             associated with the    interface (if any) are copied
  2027.             into the intra-area-prefix-LSA, setting the    LA-bit
  2028.             in the PrefixOptions field,    and setting the
  2029.             PrefixLength to 128    and the    Metric to 0.  Otherwise,
  2030.             the    list of    site-local and global prefixes
  2031.             configured in RTX for the link are copied into the
  2032.             intra-area-prefix-LSA by specifying    the
  2033.             PrefixLength, PrefixOptions, and Address Prefix
  2034.             fields. The    Metric field for each of these prefixes
  2035.             is set to the interface's output cost.
  2036.  
  2037.         o   RTX    adds the IPv6 prefixes for any directly    attached
  2038.             hosts (see Section C.7) to the intra-area-prefix-
  2039.             LSA.
  2040.  
  2041.         o   If RTX has one or more virtual links configured
  2042.             through the    area, it includes one of its site-local
  2043.             or global scope IPv6 interface addresses in    the LSA
  2044.             (if    it hasn't already), setting the    LA-bit in the
  2045.             PrefixOptions field, and setting the PrefixLength to
  2046.             128    and the    Metric to 0. This information will be
  2047.             used later in the routing calculation so that the
  2048.             two    ends of    the virtual link can discover each
  2049.             other's IPv6 addresses.
  2050.  
  2051.         o   The    "# prefixes" field is set to the number    of
  2052.             prefixes that the router has copied    into the LSA. If
  2053.             necessary, the list    of prefixes can    be spread across
  2054.             multiple intra-area-prefix-LSAs in order to    keep the
  2055.             LSA    size small.
  2056.  
  2057.         For example, the intra-area-prefix-LSA originated by RT4
  2058.         for Network N3 (assuming that RT4 is N3's Designated
  2059.         Router), and the intra-area-prefix-LSA originated into
  2060.         Area 1 by Router RT3 for its own prefixes, are pictured
  2061.         below.
  2062.  
  2063.           ; Intra-area-prefix-LSA
  2064.           ; for    network    link N3
  2065.  
  2066.           LS age = 0              ;newly (re)originated
  2067.           LS type = 0x2009          ;Link-LSA
  2068.           Link State ID    = 5          ;or something
  2069.  
  2070.  
  2071.  
  2072. Coltun et al                               [Page 37]
  2073.  
  2074. Internet Draft             OSPF for IPv6           November 1996
  2075.  
  2076.  
  2077.           Advertising Router = 192.1.1.4 ;RT4's    Router ID
  2078.           # prefixes = 1
  2079.           Referenced LS    type = 0x2002 ;network-LSA reference
  2080.           Referenced Link State    ID = 1
  2081.           Referenced Advertising Router    = 192.1.1.4
  2082.           PrefixLength = 56          ;N3's prefix
  2083.           PrefixOptions    = 0
  2084.           Metric = 0
  2085.           Address Prefix = 5f00:0000:c001:0100 ;pad
  2086.  
  2087.           ; RT3's Intra-area-prefix-LSA
  2088.           ; for    its own    prefixes
  2089.  
  2090.           LS age = 0              ;newly (re)originated
  2091.           LS type = 0x2009          ;Link-LSA
  2092.           Link State ID    = 177          ;or something
  2093.           Advertising Router = 192.1.1.3 ;RT3's    Router ID
  2094.           # prefixes = 1
  2095.           Referenced LS    type = 0x2001 ;router-LSA reference
  2096.           Referenced Link State    ID = 0
  2097.           Referenced Advertising Router    = 192.1.1.3
  2098.           PrefixLength = 56          ;N4's prefix
  2099.           PrefixOptions    = 0
  2100.           Metric = 2              ;N4 interface cost
  2101.           Address Prefix = 5f00:0000:c001:0400 ;pad
  2102.  
  2103.     3.5.  Flooding
  2104.  
  2105.     Most of    the flooding algorithm remains unchanged from the IPv4
  2106.     flooding mechanisms described in Section 13 of [Ref1]. In
  2107.     particular, the    processes for determining which    LSA instance is
  2108.     newer (Section 13.1 of [Ref1]),    responding to updates of self-
  2109.     originated LSAs    (Section 13.4 of [Ref1]), sending Link State
  2110.     Acknowledgment packets (Section    13.5 of    [Ref1]), retransmitting
  2111.     LSAs (Section 13.6 of [Ref1]) and receiving Link State
  2112.     Acknowledgment packets (Section    13.7 of    [Ref1])    are exactly the
  2113.     same for IPv6 and IPv4.
  2114.  
  2115.     However, the addition of flooding scope    and handling options for
  2116.     unrecognized LSA types (see Section A.4.2.1) has caused    some
  2117.     changes    in the OSPF flooding algorithm:    the reception of Link
  2118.     State Updates (Section 13 in [Ref1]) and the sending of    Link
  2119.     State Updates (Section 13.3 of [Ref1]) must take into account
  2120.     the LSA's scope    and U-bit setting. Also, installation of LSAs
  2121.     into the OSPF database (Section    13.2 of    [Ref1])    causes different
  2122.     events in IPv6,    due to the reorganization of LSA types and
  2123.     contents in IPv6. These    changes    are described in detail    below.
  2124.  
  2125.  
  2126.  
  2127.  
  2128. Coltun et al                               [Page 38]
  2129.  
  2130. Internet Draft             OSPF for IPv6           November 1996
  2131.  
  2132.  
  2133.     3.5.1.    Receiving Link State Update packets
  2134.  
  2135.         The    encoding of flooding scope in the LS type and the need
  2136.         to process unknown LS types    causes modifications to    the
  2137.         processing of received Link    State Update packets. As in
  2138.         IPv4, each LSA in a    received Link State Update packet is
  2139.         examined. In IPv4, eight steps are executed    for each LSA, as
  2140.         described in Section 13 of [Ref1]. For IPv6, all the steps
  2141.         are    the same, except that Steps 2 and 3 are    modified as
  2142.         follows:
  2143.  
  2144.         (2)    Examine    the LSA's LS type.  If the LS type is unknown,
  2145.         the area has been configured as    a stub area, and either
  2146.         the LSA's flooding scope is set    to "AS flooding    scope"
  2147.         or the U-bit of    the LS type is set to 1    (flood even when
  2148.         unrecognized), then discard the    LSA and    get the    next one
  2149.         from the Link State Update Packet. This    generalizes the
  2150.         IPv4 behavior where AS-external-LSAs are not flooding
  2151.         into/throughout    stub areas. See    Section    2.10 for more
  2152.         details.
  2153.  
  2154.         (3)    Else if    the flooding scope of the LSA is set to
  2155.         "reserved", discard the    LSA and    get the    next one from
  2156.         the Link State Update Packet.
  2157.  
  2158.         Steps 5b (sending Link State Update    packets) and 5d
  2159.         (installing    LSAs in    the link state database) in Section 13
  2160.         of [Ref1] are also somewhat    different for IPv6, as described
  2161.         in Sections    3.5.2 and 3.5.3    below.
  2162.  
  2163.     3.5.2.    Sending    Link State Update packets
  2164.  
  2165.         The    sending    of Link    State Update packets is    described in
  2166.         Section 13.3 of [Ref1]. For    IPv4 and IPv6, the steps for
  2167.         sending a Link State Update    packet are the same (steps 1
  2168.         through 5 of Section 13.3 in [Ref1]). However, the list of
  2169.         eligible interfaces    out which to flood the LSA is different.
  2170.         For    IPv6, the eligible interfaces are selected based on the
  2171.         following factors:
  2172.  
  2173.         o    The LSA's flooding scope.
  2174.  
  2175.         o    For LSAs with area or link-local flooding scoping, the
  2176.         particular area    or interface that the LSA is associated
  2177.         with.
  2178.  
  2179.         o    Whether    the LSA    has a recognized LS type.
  2180.  
  2181.  
  2182.  
  2183.  
  2184. Coltun et al                               [Page 39]
  2185.  
  2186. Internet Draft             OSPF for IPv6           November 1996
  2187.  
  2188.  
  2189.         o    The setting of the U-bit in the    LS type. If the    U-bit is
  2190.         set to 0, unrecognized LS types    are treated as having
  2191.         link-local scope. If set to 1, unrecognized LS types are
  2192.         stored and flooded as if they were recognized.
  2193.  
  2194.         Choosing the set of    eligible interfaces then breaks    into the
  2195.         following cases:
  2196.  
  2197.         Case 1
  2198.         The LSA's LS type is recognized. In this case, the set
  2199.         of eligible interfaces is set depending    on the flooding
  2200.         scope encoded in the LS    type. If the flooding scope is
  2201.         "AS flooding scope", the eligible interfaces are all
  2202.         router interfaces excepting virtual links and those
  2203.         connecting to stub areas. If the flooding scope    is "area
  2204.         flooding scope", the set of eligible interfaces    are
  2205.         those interfaces connecting to the LSA's associated
  2206.         area. If the flooding scope is "link-local flooding
  2207.         scope",    then there is a    single eligible    interface, the
  2208.         one connecting to the LSA's associated link (which, when
  2209.         the LSA    is received in a Link State Update packet, is
  2210.         also the interface the LSA was received    on).
  2211.  
  2212.         Case 2
  2213.         The LS type is unrecognized, and the U-bit in the LS
  2214.         Type is    set to 0 (treat    the LSA    as if it had link-local
  2215.         flooding scope). In this case there is a single    eligible
  2216.         interface, namely, the interface on which the LSA was
  2217.         received.
  2218.  
  2219.         Case 3
  2220.         The LS type is unrecognized, and the U-bit in the LS
  2221.         Type is    set to 1 (store    and flood the LSA, as if type
  2222.         understood). In    this case, select the eligible
  2223.         interfaces based on the    encoded    flooding scope as in
  2224.         Case 1 above. However, in this case interfaces attaching
  2225.         to stub    areas are excluded regardless of flooding scope.
  2226.  
  2227.         A further decision must sometimes be made before adding an
  2228.         LSA    to a given neighbor's link-state retransmission    list
  2229.         (Step 1d in    Section    13.3 of    [Ref1]). If the    LS type    is
  2230.         recognized by the router, but not by the neighbor (as can be
  2231.         determined by examining the    Options    field that the neighbor
  2232.         advertised in its Database Description packet) and the LSA's
  2233.         U-bit is set to 0, then the    LSA should be added to the
  2234.         neighbor's link-state retransmission list if and only if
  2235.         that neighbor is the Designated Router or Backup Designated
  2236.         Router for the attached link. The LS types described in
  2237.  
  2238.  
  2239.  
  2240. Coltun et al                               [Page 40]
  2241.  
  2242. Internet Draft             OSPF for IPv6           November 1996
  2243.  
  2244.  
  2245.         detail by this memo, namely    router-LSAs (LS    type 0x2001),
  2246.         network-LSAs (0x2002), Inter-Area-Prefix-LSAs (0x2003),
  2247.         Inter-Area-Router-LSAs (0x2004), AS-External-LSAs (0x4005),
  2248.         Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are
  2249.         assumed to be understood by    all routers. However, as an
  2250.         example the    group-membership-LSA (0x2006) is understood only
  2251.         by MOSPF routers and since it has its U-bit    set to 0, it
  2252.         should only    be forwarded to    a non-MOSPF neighbor (determined
  2253.         by examining the MC-bit in the neighbor's Database
  2254.         Description    packets' Options field)    when the neighbor is
  2255.         Designated Router or Backup    Designated Router for the
  2256.         attached link.
  2257.  
  2258.         The    previous paragraph solves a problem in IPv4 OSPF
  2259.         extensions such as MOSPF, which require that the Designated
  2260.         Router support the extension in order to have the new LSA
  2261.         types flooded across broadcast and NBMA networks (see
  2262.         Section 10.2 of [Ref8]).
  2263.  
  2264.     3.5.3.    Installing LSAs    in the database
  2265.  
  2266.         There are three separate places to store LSAs, depending on
  2267.         their flooding scope. LSAs with AS flooding    scope are stored
  2268.         in the global OSPF data structure (see Section 3.1)    as long
  2269.         as their LS    type is    known or their U-bit is    1. LSAs    with
  2270.         area flooding scope    are stored in the appropriate area data
  2271.         structure (see Section 3.1.1) as long as their LS type is
  2272.         known or their U-bit is 1. LSAs with link-local flooding
  2273.         scope, and those LSAs with unknown LS type and U-bit set to
  2274.         0 (treat the LSA as    if it had link-local flooding scope) are
  2275.         stored in the appropriate interface    structure.
  2276.  
  2277.         When storing the LSA into the link-state database, a check
  2278.         must be made to see    whether    the LSA's contents have    changed.
  2279.         Changes in contents    are indicated exactly as in Section 13.2
  2280.         of [Ref1]. When an LSA's contents have been    changed, the
  2281.         following parts of the routing table must be recalculated,
  2282.         based on the LSA's LS type:
  2283.  
  2284.         Router-LSAs, Network-LSAs and Intra-Area-Prefix-LSAs
  2285.         The entire routing table is recalculated, starting with
  2286.         the shortest path calculation for each area (see Section
  2287.         3.8).
  2288.  
  2289.         Link-LSAs
  2290.         The next hop of    some of    the routing table's entries,
  2291.         which is always    an IPv6    link-local address, may    need to
  2292.         be recalculated. Link-local LSAs provide the OSPF Router
  2293.  
  2294.  
  2295.  
  2296. Coltun et al                               [Page 41]
  2297.  
  2298. Internet Draft             OSPF for IPv6           November 1996
  2299.  
  2300.  
  2301.         ID to link-local address mapping used in the next hop
  2302.         calculation. See Section 3.8.1.1 for details.
  2303.  
  2304.         Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
  2305.         The best route to the destination described by the LSA
  2306.         must be    recalculated (see Section 16.5 in [Ref1]).  If
  2307.         this destination is an AS boundary router, it may also
  2308.         be necessary to    re-examine all the AS-external-LSAs.
  2309.  
  2310.         AS-external-LSAs
  2311.         The best route to the destination described by the AS-
  2312.         external-LSA must be recalculated (see Section 16.6 in
  2313.         [Ref1]).
  2314.  
  2315.         As in IPv4,    any old    instance of the    LSA must be removed from
  2316.         the    database when the new LSA is installed.     This old
  2317.         instance must also be removed from all neighbors' Link state
  2318.         retransmission lists.
  2319.  
  2320.     3.6.  Definition of    self-originated    LSAs
  2321.  
  2322.     In IPv6    the definition of a self-originated LSA    has been
  2323.     simplified from    the IPv4 definition appearing in Sections 13.4
  2324.     and 14.1 of [Ref1]. For    IPv6, self-originated LSAs are those
  2325.     LSAs whose Advertising Router is equal to the router's own
  2326.     Router ID.
  2327.  
  2328.     3.7.  Virtual links
  2329.  
  2330.     OSPF virtual links for IPv4 are    described in Section 15    of
  2331.     [Ref1].    Virtual    links are the same in IPv6, with the following
  2332.     exceptions:
  2333.  
  2334.     o   LSAs having    AS flooding scope are never flooded over virtual
  2335.         adjacencies, nor are LSAs with AS flooding scope summarized
  2336.         over virtual adjacencies during the    Database Exchange
  2337.         process. This is a generalization of the IPv4 treatment of
  2338.         AS-external-LSAs.
  2339.  
  2340.     o   The    IPv6 interface address of a virtual link must be an IPv6
  2341.         address having site-local or global    scope, instead of the
  2342.         link-local addresses used by other interface types.    This
  2343.         address is used as the IPv6    source for OSPF    protocol packets
  2344.         sent over the virtual link.
  2345.  
  2346.     o   Likewise, the virtual neighbor's IPv6 address is an    IPv6
  2347.         address with site-local or global scope. To    enable the
  2348.         discovery of a virtual neighbor's IPv6 address during the
  2349.  
  2350.  
  2351.  
  2352. Coltun et al                               [Page 42]
  2353.  
  2354. Internet Draft             OSPF for IPv6           November 1996
  2355.  
  2356.  
  2357.         routing calculation, the neighbor advertises its virtual
  2358.         link's IPv6    interface address in an    Intra-Area-Prefix-LSA
  2359.         originated for the virtual link's transit area (see    Sections
  2360.         3.4.3.7 and    3.8.1).
  2361.  
  2362.     o   Like all other IPv6    OSPF interfaces, virtual links are
  2363.         assigned unique (within the    router)    Interface IDs. These are
  2364.         advertised in Hellos sent over the virtual link, and in the
  2365.         router's router-LSAs.
  2366.  
  2367.     o   IPv6 has no    concept    of TOS,    so all discussions of TOS in
  2368.         Section 15 of [Ref1] are not applicable to OSPF for    IPv6.
  2369.  
  2370.     3.8.  Routing table    calculation
  2371.  
  2372.     The IPv6 OSPF routing calculation proceeds along the same lines
  2373.     as the IPv4 OSPF routing calculation, following    the five steps
  2374.     specified by Section 16    of [Ref1]. High    level differences
  2375.     between    the IPv6 and IPv4 calculations include:
  2376.  
  2377.     o   Prefix information has been    removed    from router-LSAs, and
  2378.         now    is advertised in intra-area-prefix-LSAs. Whenever [Ref1]
  2379.         specifies that stub    networks within    router-LSAs be examined,
  2380.         IPv6 will instead examine prefixes within intra-area-
  2381.         prefix-LSAs.
  2382.  
  2383.     o   Type 3 and 4 summary-LSAs have been    renamed    inter-area-
  2384.         prefix-LSAs    and inter-area-router-LSAs (respectively).
  2385.  
  2386.     o   Addressing information is no longer    encoded    in Link    State
  2387.         IDs, and must instead be found within the body of LSAs.
  2388.  
  2389.     o   In IPv6, a router can originate multiple router-LSAs within
  2390.         a single area, distinguished by Link State ID. These
  2391.         router-LSAs    must be    treated    as a single aggregate by the
  2392.         area's shortest path calculation (see Section 3.8.1).
  2393.  
  2394.     o   IPv6 has no    concept    of TOS;    all TOS    routing    calculations in
  2395.         [Ref1] are inapplicable to OSPF for    IPv6. In particular,
  2396.         Section 16.9 of [Ref1] can be ignored for IPv6.
  2397.  
  2398.     For each area, routing table entries have been created for the
  2399.     area's routers and transit links, in order to store the    results
  2400.     of the area's shortest-path tree calculation (see Section
  2401.     3.8.1).    These entries are then used when processing intra-area-
  2402.     prefix-LSAs, inter-area-prefix-LSAs and    inter-area-router-LSAs,
  2403.     as described in    Section    3.8.2.
  2404.  
  2405.  
  2406.  
  2407.  
  2408. Coltun et al                               [Page 43]
  2409.  
  2410. Internet Draft             OSPF for IPv6           November 1996
  2411.  
  2412.  
  2413.     Events generated as a result of    routing    table changes (Section
  2414.     16.7 of    [Ref1]), and the equal-cost multipath logic (Section
  2415.     16.8 of    [Ref1])    are identical for both IPv4 and    IPv6.
  2416.  
  2417.     3.8.1.    Calculating the    shortest path tree for an area
  2418.  
  2419.         The    IPv4 shortest path calculation is contained in Section
  2420.         16.1 of [Ref1].  The graph used by the shortest-path tree
  2421.         calculation    is identical for both IPv4 and IPv6. The graph's
  2422.         vertices are routers and transit links, represented    by
  2423.         router-LSAs    and network-LSAs respectively. A router    is
  2424.         identified by its OSPF Router ID, while a transit link is
  2425.         identified by its Designated Router's Interface ID and OSPF
  2426.         Router ID. Both routers and    transit    links have associated
  2427.         routing table entries within the area (see Section 3.3).
  2428.  
  2429.         Section 16.1 of [Ref1] splits up the shortest path
  2430.         calculations into two stages. First    the Dijkstra calculation
  2431.         is performed, and then the stub links are added onto the
  2432.         tree as leaves. The    IPv6 calculation maintains this    split.
  2433.  
  2434.         The    Dijkstra calculation for IPv6 is identical to that
  2435.         specified for IPv4,    with the following exceptions
  2436.         (referencing the steps from    the Dijkstra calculation as
  2437.         described in Section 16.1 of [Ref1]):
  2438.  
  2439.         o    The Vertex ID for a router is the OSPF Router ID. The
  2440.         Vertex ID for a    transit    network    is a combination of the
  2441.         Interface ID and OSPF Router ID    of the network's
  2442.         Designated Router.
  2443.  
  2444.         o    In Step    2, when    a router Vertex    V has just been    added to
  2445.         the shortest path tree,    there may be multiple LSAs
  2446.         associated with    the router. All    Router-LSAs with
  2447.         Advertising Router set to V's OSPF Router ID must
  2448.         processed as an    aggregate, treating them as fragments of
  2449.         a single large router-LSA. The Options field and the
  2450.         router type bits (bits W, V, E and B) should always be
  2451.         taken from "fragment" with the smallest    Link State ID.
  2452.  
  2453.         o    Step 2a    is not needed in IPv6, as there    are no longer
  2454.         stub network links in router-LSAs.
  2455.  
  2456.         o    In Step    2b, if W is a router, there may    again be
  2457.         multiple LSAs associated with the router. All Router-
  2458.         LSAs with Advertising Router set to W's    OSPF Router ID
  2459.         must processed as an aggregate,    treating them as
  2460.         fragments of a single large router-LSA.
  2461.  
  2462.  
  2463.  
  2464. Coltun et al                               [Page 44]
  2465.  
  2466. Internet Draft             OSPF for IPv6           November 1996
  2467.  
  2468.  
  2469.         o    In Step    4, there are now per-area routing table    entries
  2470.         for each of an area's routers, instead of just the area
  2471.         border routers.    These entries subsume all the
  2472.         functionality of IPv4's    area border router routing table
  2473.         entries, including the maintenance of virtual links.
  2474.         When the router    added to the area routing table    in this
  2475.         step is    the other end of a virtual link, the virtual
  2476.         neighbor's IP address is set as    follows: The collection
  2477.         of intra-area-prefix-LSAs originated by    the virtual
  2478.         neighbor is examined, with the virtual neighbor's IP
  2479.         address    being set to the first prefix encountered having
  2480.         the "LA-bit" set.
  2481.  
  2482.         o    Routing    table entries for transit networks, which are no
  2483.         longer associated with IP networks, are    also modified in
  2484.         Step 4.
  2485.  
  2486.         The    next stage of the shortest path    calculation proceeds
  2487.         similarly to the two steps of the second stage of Section
  2488.         16.1 in [Ref1]. However, instead of    examining the stub links
  2489.         within router-LSAs,    the list of the    area's intra-area-
  2490.         prefix-LSAs    is examined. A prefix advertisement whose "NU-
  2491.         bit" is set    should not be included in the routing
  2492.         calculation. The cost of any advertised prefix is the sum of
  2493.         the    prefix'    advertised metric plus the cost    to the transit
  2494.         vertex (either router or transit network) identified by
  2495.         intra-area-prefix-LSA's Referenced LS type,    Referenced Link
  2496.         State ID and Referenced Advertising    Router fields. This
  2497.         latter cost    is stored in the transit vertex' routing table
  2498.         entry for the area.
  2499.  
  2500.         3.8.1.1.  The next hop calculation
  2501.  
  2502.         In IPv6, the calculation of the    next hop's IPv6    address
  2503.         (which will be a link-local address) proceeds along the
  2504.         same lines as the IPv4 next hop    calculation (see Section
  2505.         16.1.1 of [Ref1]). The only difference is in calculating
  2506.         the next hop IPv6 address for a    router (call it    Router
  2507.         X) which shares    a link with the    calculating router. In
  2508.         this case the calculating router assigns the next hop
  2509.         IPv6 address to    be the link-local interface address
  2510.         contained in Router X's    Link-LSA (see Section A.4.8) for
  2511.         the link. This procedure is necessary since on some
  2512.         links, such as NBMA links, the two routers need    not be
  2513.         neighbors, and therefore might not be exchanging OSPF
  2514.         Hellos.
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520. Coltun et al                               [Page 45]
  2521.  
  2522. Internet Draft             OSPF for IPv6           November 1996
  2523.  
  2524.  
  2525.     3.8.2.    Calculating the    inter-area routes
  2526.  
  2527.         Calculation    of inter-area routes for IPv6 proceeds along the
  2528.         same lines as the IPv4 calculation in Section 16.2 of
  2529.         [Ref1], with the following modifications:
  2530.  
  2531.         o    The names of the Type 3    summary-LSAs and Type 4
  2532.         summary-LSAs have been changed to inter-area-prefix-LSAs
  2533.         and inter-area-router-LSAs respectively.
  2534.  
  2535.         o    The Link State ID of the above LSA types no longer
  2536.         encodes    the network or router described    by the LSA.
  2537.         Instead, an address prefix is contained    in the body of
  2538.         an inter-area-prefix-LSA, and a    described router's OSPF
  2539.         Router ID is carried in    the body of an inter-area-
  2540.         router-LSA.
  2541.  
  2542.         o    Prefixes having    the "NU-bit" set in their Prefix Options
  2543.         field should be    ignored    by the inter-area route
  2544.         calculation.
  2545.  
  2546.         When a single inter-area-prefix-LSA    or inter-area-router-LSA
  2547.         has    changed, the incremental calculations outlined in
  2548.         Section 16.5 of [Ref1] can be performed instead of
  2549.         recalculating the entire routing table.
  2550.  
  2551.     3.8.3.    Examining transit areas' summary-LSAs
  2552.  
  2553.         Examination    of transit areas' summary-LSAs in IPv6 proceeds
  2554.         along the same lines as the    IPv4 calculation in Section 16.3
  2555.         of [Ref1], modified    in the same way    as the IPv6 inter-area
  2556.         route calculation in Section 3.8.2.
  2557.  
  2558.     3.8.4.    Calculating AS external    routes
  2559.  
  2560.         The    IPv6 AS    external route calculation proceeds along the
  2561.         same lines as the IPv4 calculation in Section 16.4 of
  2562.         [Ref1], with the following exceptions:
  2563.  
  2564.         o    The Link State ID of the AS-external-LSA types no longer
  2565.         encodes    the network described by the LSA. Instead, an
  2566.         address    prefix is contained in the body    of an AS-
  2567.         external-LSA.
  2568.  
  2569.         o    The default route is described by AS-external-LSAs which
  2570.         advertise zero length prefixes.
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576. Coltun et al                               [Page 46]
  2577.  
  2578. Internet Draft             OSPF for IPv6           November 1996
  2579.  
  2580.  
  2581.         o    Instead    of comparing the AS-external-LSA's Forwarding
  2582.         address    field to 0.0.0.0 to see    whether    a forwarding
  2583.         address    has been used, bit F of    the external-LSA is
  2584.         examined. A forwarding address is in use if and    only if
  2585.         bit F is set.
  2586.  
  2587.         o    Prefixes having    the "NU-bit" set in their Prefix Options
  2588.         field should be    ignored    by the inter-area route
  2589.         calculation.
  2590.  
  2591.         When a single AS-external-LSA has changed, the incremental
  2592.         calculations outlined in Section 16.6 of [Ref1] can    be
  2593.         performed instead of recalculating the entire routing table.
  2594.  
  2595.  
  2596.  
  2597.  
  2598.  
  2599.  
  2600.  
  2601.  
  2602.  
  2603.  
  2604.  
  2605.  
  2606.  
  2607.  
  2608.  
  2609.  
  2610.  
  2611.  
  2612.  
  2613.  
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632. Coltun et al                               [Page 47]
  2633.  
  2634. Internet Draft             OSPF for IPv6           November 1996
  2635.  
  2636.  
  2637. References
  2638.  
  2639.     [Ref1]  Moy, J., "OSPF Version 2", Internet    Draft, <draft-ietf-
  2640.         ospf-version2-08.txt>, Cascade, September 1996.
  2641.  
  2642.     [Ref2]  McKenzie, A., "ISO Transport Protocol specification    ISO DP
  2643.         8073", RFC 905, ISO, April 1984.
  2644.  
  2645.     [Ref3]  McCloghrie,    K., and    M. Rose, "Management Information Base
  2646.         for    network    management of TCP/IP-based internets: MIB-II",
  2647.         STD    17, RFC    1213, Hughes LAN Systems, Performance Systems
  2648.         International, March 1991.
  2649.  
  2650.     [Ref4]  Fuller, V.,    T. Li, J. Yu, and K. Varadhan, "Classless
  2651.         Inter-Domain Routing (CIDR): an Address Assignment and
  2652.         Aggregation    Strategy", RFC1519, BARRNet, cisco, MERIT,
  2653.         OARnet, September 1993.
  2654.  
  2655.     [Ref5]  Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP---
  2656.         OSPF Interaction", RFC1745,    December 1994
  2657.  
  2658.     [Ref6]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
  2659.         1700, USC/Information Sciences Institute, October 1994.
  2660.  
  2661.     [Ref7]  deSouza, O., and M.    Rodrigues, "Guidelines for Running OSPF
  2662.         Over Frame Relay Networks",    RFC 1586, March    1994.
  2663.  
  2664.     [Ref8]  Moy, J., "Multicast    Extensions to OSPF", RFC 1584, Proteon,
  2665.         Inc., March    1994.
  2666.  
  2667.     [Ref9]  Coltun, R. and V. Fuller, "The OSPF    NSSA Option", RFC 1587,
  2668.         RainbowBridge Communications, Stanford University, March
  2669.         1994.
  2670.  
  2671.     [Ref10] Ferguson, D., "The OSPF External Attributes    LSA",
  2672.         unpublished.
  2673.  
  2674.     [Ref11] Moy, J., "Extending    OSPF to    Support    Demand Circuits", RFC
  2675.         1793, Cascade, April 1995.
  2676.  
  2677.     [Ref12] Mogul, J. and S. Deering, "Path MTU    Discovery", RFC    1191,
  2678.         DECWRL, Stanford University, November 1990.
  2679.  
  2680.     [Ref13] Rekhter, Y.    and T. Li, "A Border Gateway Protocol 4    (BGP-
  2681.         4)", RFC 1771, T.J.    Watson Research    Center,    IBM Corp., cisco
  2682.         Systems, March 1995.
  2683.  
  2684.  
  2685.  
  2686.  
  2687.  
  2688. Coltun et al                               [Page 48]
  2689.  
  2690. Internet Draft             OSPF for IPv6           November 1996
  2691.  
  2692.  
  2693.     [Ref14] Deering, S.    and R. Hinden, "Internet Protocol, Version 6
  2694.         (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon
  2695.         Networks, December 1995.
  2696.  
  2697.     [Ref15] Deering, S.    and R. Hinden, "IP Version 6 Addressing
  2698.         Architecture", RFC 1884, Xerox PARC, Ipsilon Networks,
  2699.         December 1995.
  2700.  
  2701.     [Ref16] Conta, A. and S. Deering, "Internet    Control    Message    Protocol
  2702.         (ICMPv6) for the Internet Protocol Version 6 (IPv6)
  2703.         Specification" RFC 1885, Digital Equipment Corporation,
  2704.         Xerox PARC,    December 1995.
  2705.  
  2706.     [Ref17] Narten, T.,    E. Nordmark and    W. Simpson, "Neighbor Discovery
  2707.         for    IP Version 6 (IPv6)", RFC 1970,    August 1996.
  2708.  
  2709.     [Ref18] McCann, J.,    S. Deering and J. Mogul, "Path MTU Discovery for
  2710.         IP version 6", RFC 1981, August 1996.
  2711.  
  2712.     [Ref19] Atkinson, R., "IP Authentication Header", RFC 1826,    Naval
  2713.         Research Laboratory, August    1995.
  2714.  
  2715.     [Ref20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
  2716.         1827, Naval    Research Laboratory, August 1995.
  2717.  
  2718.  
  2719.  
  2720.  
  2721.  
  2722.  
  2723.  
  2724.  
  2725.  
  2726.  
  2727.  
  2728.  
  2729.  
  2730.  
  2731.  
  2732.  
  2733.  
  2734.  
  2735.  
  2736.  
  2737.  
  2738.  
  2739.  
  2740.  
  2741.  
  2742.  
  2743.  
  2744. Coltun et al                               [Page 49]
  2745.  
  2746. Internet Draft             OSPF for IPv6           November 1996
  2747.  
  2748.  
  2749. A. OSPF    data formats
  2750.  
  2751.     This appendix describes the    format of OSPF protocol    packets    and OSPF
  2752.     LSAs.  The OSPF protocol runs directly over    the IPv6 network layer.
  2753.     Before any data formats are    described, the details of the OSPF
  2754.     encapsulation are explained.
  2755.  
  2756.     Next the OSPF Options field    is described.  This field describes
  2757.     various capabilities that may or may not be    supported by pieces of
  2758.     the    OSPF routing domain. The OSPF Options field is contained in OSPF
  2759.     Hello packets, Database Description    packets    and in OSPF LSAs.
  2760.  
  2761.     OSPF packet    formats    are detailed in    Section    A.3.
  2762.  
  2763.     A description of OSPF LSAs appears in Section A.4. This section
  2764.     describes how IPv6 address prefixes    are represented    within LSAs,
  2765.     details the    standard LSA header, and then provides formats for each
  2766.     of the specific LSA    types.
  2767.  
  2768. A.1 Encapsulation of OSPF packets
  2769.  
  2770.     OSPF runs directly over the    IPv6's network layer.  OSPF packets are
  2771.     therefore encapsulated solely by IPv6 and local data-link headers.
  2772.  
  2773.     OSPF does not define a way to fragment its protocol    packets, and
  2774.     depends on IPv6 fragmentation when transmitting packets larger than
  2775.     the    link MTU. If necessary,    the length of OSPF packets can be up to
  2776.     65,535 bytes.  The OSPF packet types that are likely to be large
  2777.     (Database Description Packets, Link    State Request, Link State
  2778.     Update, and    Link State Acknowledgment packets) can usually be split
  2779.     into several separate protocol packets, without loss of
  2780.     functionality.  This is recommended; IPv6 fragmentation should be
  2781.     avoided whenever possible.    Using this reasoning, an attempt should
  2782.     be made to limit the sizes of OSPF packets sent over virtual links
  2783.     to 576 bytes unless    Path MTU Discovery is being performed.
  2784.  
  2785.     The    other important    features of OSPF's IPv6    encapsulation are:
  2786.  
  2787.     o    Use of IPv6 multicast.    Some OSPF messages are multicast, when
  2788.     sent over broadcast networks.  Two distinct IP multicast
  2789.     addresses are used.  Packets sent to these multicast addresses
  2790.     should never be    forwarded; they    are meant to travel a single hop
  2791.     only. As such, the multicast addresses have been chosen    with
  2792.     link-local scope, and packets sent to these addresses should
  2793.     have their IPv6    Hop Limit set to 1.
  2794.  
  2795.     AllSPFRouters
  2796.         This multicast address has been assigned the value FF02::5.
  2797.  
  2798.  
  2799.  
  2800. Coltun et al                               [Page 50]
  2801.  
  2802. Internet Draft             OSPF for IPv6           November 1996
  2803.  
  2804.  
  2805.         All    routers    running    OSPF should be prepared    to receive
  2806.         packets sent to this address.  Hello packets are always sent
  2807.         to this destination.  Also,    certain    OSPF protocol packets
  2808.         are    sent to    this address during the    flooding procedure.
  2809.  
  2810.     AllDRouters
  2811.         This multicast address has been assigned the value FF02::6.
  2812.         Both the Designated    Router and Backup Designated Router must
  2813.         be prepared    to receive packets destined to this address.
  2814.         Certain OSPF protocol packets are sent to this address
  2815.         during the flooding    procedure.
  2816.  
  2817.     o    OSPF is    IP protocol 89.     This number should be inserted    in the
  2818.     Next Header field of the encapsulating IPv6 header.
  2819.  
  2820.     o    Routing    protocol packets are sent with IPv6 Priority field set
  2821.     to 7 (internet control traffic).  OSPF protocol    packets    should
  2822.     be given precedence over regular IPv6 data traffic, in both
  2823.     sending    and receiving.
  2824.  
  2825.  
  2826.  
  2827.  
  2828.  
  2829.  
  2830.  
  2831.  
  2832.  
  2833.  
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852.  
  2853.  
  2854.  
  2855.  
  2856. Coltun et al                               [Page 51]
  2857.  
  2858. Internet Draft             OSPF for IPv6           November 1996
  2859.  
  2860.  
  2861. A.2 The    Options    field
  2862.  
  2863.     The    24-bit OSPF Options field is present in    OSPF Hello packets,
  2864.     Database Description packets and certain LSAs (router-LSAs,
  2865.     network-LSAs, inter-area-router-LSAs and link-LSAs). The Options
  2866.     field enables OSPF routers to support (or not support) optional
  2867.     capabilities, and to communicate their capability level to other
  2868.     OSPF routers.  Through this    mechanism routers of differing
  2869.     capabilities can be    mixed within an    OSPF routing domain.
  2870.  
  2871.     An option mismatch between routers can cause a variety of behaviors,
  2872.     depending on the particular    option.    Some option mismatches prevent
  2873.     neighbor relationships from    forming    (e.g., the E-bit below); these
  2874.     mismatches are discovered through the sending and receiving    of Hello
  2875.     packets. Some option mismatches prevent particular LSA types from
  2876.     being flooded across adjacencies (e.g., the    MC-bit below); these are
  2877.     discovered through the sending and receiving of Database Description
  2878.     packets. Some option mismatches prevent routers from being included
  2879.     in one or more of the various routing calculations because of their
  2880.     reduced functionality (again the MC-bit is an example); these
  2881.     mismatches are discovered by examining LSAs.
  2882.  
  2883.     Six    bits of    the OSPF Options field have been assigned. Each    bit is
  2884.     described briefly below. Routers should reset (i.e.     clear)
  2885.     unrecognized bits in the Options field when    sending    Hello packets or
  2886.     Database Description packets and when originating LSAs. Conversely,
  2887.     routers encountering unrecognized Option bits in received Hello
  2888.     Packets, Database Description packets or LSAs should ignore    the
  2889.     capability and process the packet/LSA normally.
  2890.  
  2891.                 1              2
  2892.     0 1 2 3    4 5 6 7    8 9 0 1    2 3 4 5    6 7 8  9  0  1    2  3
  2893.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
  2894.        | | | | | | | | | | | | | | | | | | |DC|    R| N|MC| E|V6|
  2895.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
  2896.  
  2897.                  The Options field
  2898.  
  2899.  
  2900.     V6-bit
  2901.     If this    bit is clear, the router/link should be    excluded from
  2902.     IPv6 routing calculations. See Section 3.8 of this memo.
  2903.  
  2904.     E-bit
  2905.     This bit describes the way AS-external-LSAs are    flooded, as
  2906.     described in Sections 3.6, 9.5,    10.8 and 12.1.2    of [Ref1].
  2907.  
  2908.  
  2909.  
  2910.  
  2911.  
  2912. Coltun et al                               [Page 52]
  2913.  
  2914. Internet Draft             OSPF for IPv6           November 1996
  2915.  
  2916.  
  2917.     MC-bit
  2918.     This bit describes whether IP multicast    datagrams are forwarded
  2919.     according to the specifications    in [Ref7].
  2920.  
  2921.     N-bit
  2922.     This bit describes the handling    of Type-7 LSAs,    as specified in
  2923.     [Ref8].
  2924.  
  2925.     R-bit
  2926.     This bit (the `Router' bit) indicates whether the originator is
  2927.     an active router.  If the router bit is    clear routes which
  2928.     transit    the advertising    node cannot be computed. Clearing the
  2929.     router bit would be appropriate    for a multi-homed host that
  2930.     wants to participate in    routing, but does not want to forward
  2931.     non-locally addressed packets.
  2932.  
  2933.     DC-bit
  2934.     This bit describes the router's    handling of demand circuits, as
  2935.     specified in [Ref10].
  2936.  
  2937.  
  2938.  
  2939.  
  2940.  
  2941.  
  2942.  
  2943.  
  2944.  
  2945.  
  2946.  
  2947.  
  2948.  
  2949.  
  2950.  
  2951.  
  2952.  
  2953.  
  2954.  
  2955.  
  2956.  
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963.  
  2964.  
  2965.  
  2966.  
  2967.  
  2968. Coltun et al                               [Page 53]
  2969.  
  2970. Internet Draft             OSPF for IPv6           November 1996
  2971.  
  2972.  
  2973. A.3 OSPF Packet    Formats
  2974.  
  2975.     There are five distinct OSPF packet    types.    All OSPF packet    types
  2976.     begin with a standard 16 byte header.  This    header is described
  2977.     first.  Each packet    type is    then described in a succeeding section.
  2978.     In these sections each packet's division into fields is displayed,
  2979.     and    then the field definitions are enumerated.
  2980.  
  2981.     All    OSPF packet types (other than the OSPF Hello packets) deal with
  2982.     lists of LSAs.  For    example, Link State Update packets implement the
  2983.     flooding of    LSAs throughout    the OSPF routing domain. The format of
  2984.     LSAs is described in Section A.4.
  2985.  
  2986.     The    receive    processing of OSPF packets is detailed in Section 3.2.2.
  2987.     The    sending    of OSPF    packets    is explained in    Section    3.2.1.
  2988.  
  2989.  
  2990.  
  2991.  
  2992.  
  2993.  
  2994.  
  2995.  
  2996.  
  2997.  
  2998.  
  2999.  
  3000.  
  3001.  
  3002.  
  3003.  
  3004.  
  3005.  
  3006.  
  3007.  
  3008.  
  3009.  
  3010.  
  3011.  
  3012.  
  3013.  
  3014.  
  3015.  
  3016.  
  3017.  
  3018.  
  3019.  
  3020.  
  3021.  
  3022.  
  3023.  
  3024. Coltun et al                               [Page 54]
  3025.  
  3026. Internet Draft             OSPF for IPv6           November 1996
  3027.  
  3028.  
  3029. A.3.1 The OSPF packet header
  3030.  
  3031.     Every OSPF packet starts with a standard 16    byte header. Together
  3032.     with the encapsulating IPv6    headers, the OSPF header contains all
  3033.     the    information necessary to determine whether the packet should be
  3034.     accepted for further processing.  This determination is described in
  3035.     Section 3.2.2 of this memo.
  3036.  
  3037.  
  3038.     0            1            2            3
  3039.     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
  3040.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3041.        |   Version #   |     Type      |     Packet    length           |
  3042.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3043.        |              Router ID                   |
  3044.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3045.        |               Area    ID                   |
  3046.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3047.        |       Checksum           |  Instance ID  |      0           |
  3048.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3049.  
  3050.  
  3051.  
  3052.     Version #
  3053.     The OSPF version number.  This specification documents version 3
  3054.     of the OSPF protocol.
  3055.  
  3056.     Type
  3057.     The OSPF packet    types are as follows. See Sections A.3.2 through
  3058.     A.3.6 for details.
  3059.  
  3060.  
  3061.  
  3062.               Type     Description
  3063.               ________________________________
  3064.               1     Hello
  3065.               2     Database Description
  3066.               3     Link State Request
  3067.               4     Link State Update
  3068.               5     Link State Acknowledgment
  3069.  
  3070.  
  3071.  
  3072.  
  3073.     Packet length
  3074.     The length of the OSPF protocol    packet in bytes.  This length
  3075.     includes the standard OSPF header.
  3076.  
  3077.  
  3078.  
  3079.  
  3080. Coltun et al                               [Page 55]
  3081.  
  3082. Internet Draft             OSPF for IPv6           November 1996
  3083.  
  3084.  
  3085.     Router ID
  3086.     The Router ID of the packet's source.
  3087.  
  3088.     Area ID
  3089.     A 32 bit number    identifying the    area that this packet belongs
  3090.     to.  All OSPF packets are associated with a single area.  Most
  3091.     travel a single    hop only.  Packets travelling over a virtual
  3092.     link are labelled with the backbone Area ID of 0.
  3093.  
  3094.     Checksum
  3095.     The standard IP    checksum of the    entire contents    of the packet,
  3096.     starting with the OSPF packet header. This checksum is
  3097.     calculated as the 16-bit one's complement of the one's
  3098.     complement sum of all the 16-bit words in the packet.  If the
  3099.     packet's length    is not an integral number of 16-bit words, the
  3100.     packet is padded with a    byte of    zero before checksumming.
  3101.  
  3102.     Instance ID
  3103.     Enables    multiple instances of OSPF to be run over a single link.
  3104.     Each protocol instance would be    assigned a separate Instance ID;
  3105.     the Instance ID    has local link significance only. Received
  3106.     packets    whose Instance ID is not equal to the receiving
  3107.     interface's Instance ID    are discarded.
  3108.  
  3109.     0    These fields are reserved.  They must be 0.
  3110.  
  3111.  
  3112.  
  3113.  
  3114.  
  3115.  
  3116.  
  3117.  
  3118.  
  3119.  
  3120.  
  3121.  
  3122.  
  3123.  
  3124.  
  3125.  
  3126.  
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132.  
  3133.  
  3134.  
  3135.  
  3136. Coltun et al                               [Page 56]
  3137.  
  3138. Internet Draft             OSPF for IPv6           November 1996
  3139.  
  3140.  
  3141. A.3.2 The Hello    packet
  3142.  
  3143.     Hello packets are OSPF packet type 1.  These packets are sent
  3144.     periodically on all    interfaces (including virtual links) in    order to
  3145.     establish and maintain neighbor relationships.  In addition, Hello
  3146.     Packets are    multicast on those links having    a multicast or broadcast
  3147.     capability,    enabling dynamic discovery of neighboring routers.
  3148.  
  3149.     All    routers    connected to a common link must    agree on certain
  3150.     parameters (HelloInterval and RouterDeadInterval).    These parameters
  3151.     are    included in Hello packets, so that differences can inhibit the
  3152.     forming of neighbor    relationships. The Hello packet    also contains
  3153.     fields used    in Designated Router election (Designated Router ID and
  3154.     Backup Designated Router ID), and fields used to detect bi-
  3155.     directionality (the    Router IDs of all neighbors whose Hellos have
  3156.     been recently received).
  3157.  
  3158.  
  3159.     0            1            2            3
  3160.     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
  3161.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3162.        |      3           |       1       |     Packet    length           |
  3163.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3164.        |              Router ID                   |
  3165.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3166.        |               Area    ID                   |
  3167.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3168.        |       Checksum           |  Instance ID  |      0           |
  3169.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3170.        |             Interface ID                   |
  3171.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3172.        |    Rtr    Pri    |          Options                   |
  3173.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3174.        |     HelloInterval           |    RouterDeadInterval     |
  3175.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3176.        |            Designated Router ID               |
  3177.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3178.        |         Backup    Designated Router ID               |
  3179.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3180.        |              Neighbor ID                   |
  3181.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3182.        |                  ...                   |
  3183.  
  3184.  
  3185.  
  3186.     Interface ID
  3187.     32-bit number uniquely identifying this    interface among    the
  3188.     collection of this router's interfaces.    For example, in    some
  3189.  
  3190.  
  3191.  
  3192. Coltun et al                               [Page 57]
  3193.  
  3194. Internet Draft             OSPF for IPv6           November 1996
  3195.  
  3196.  
  3197.     implementations    it may be possible to use the MIB-II IfIndex.
  3198.  
  3199.     Rtr    Pri
  3200.     This router's Router Priority.    Used in    (Backup) Designated
  3201.     Router election.  If set to 0, the router will be ineligible to
  3202.     become (Backup)    Designated Router.
  3203.  
  3204.     Options
  3205.     The optional capabilities supported by the router, as documented
  3206.     in Section A.2.
  3207.  
  3208.     HelloInterval
  3209.     The number of seconds between this router's Hello packets.
  3210.  
  3211.     RouterDeadInterval
  3212.     The number of seconds before declaring a silent    router down.
  3213.  
  3214.     Designated Router ID
  3215.     The identity of    the Designated Router for this network,    in the
  3216.     view of    the sending router.  The Designated Router is identified
  3217.     by its Router ID. Set to 0.0.0.0 if there is no    Designated
  3218.     Router.
  3219.  
  3220.     Backup Designated Router ID
  3221.     The identity of    the Backup Designated Router for this network,
  3222.     in the view of the sending router.  The    Backup Designated Router
  3223.     is identified by its IP    Router ID.  Set    to 0.0.0.0 if there is
  3224.     no Backup Designated Router.
  3225.  
  3226.     Neighbor ID
  3227.     The Router IDs of each router from whom    valid Hello packets have
  3228.     been seen recently on the network.  Recently means in the last
  3229.     RouterDeadInterval seconds.
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244.  
  3245.  
  3246.  
  3247.  
  3248. Coltun et al                               [Page 58]
  3249.  
  3250. Internet Draft             OSPF for IPv6           November 1996
  3251.  
  3252.  
  3253. A.3.3 The Database Description packet
  3254.  
  3255.     Database Description packets are OSPF packet type 2.  These    packets
  3256.     are    exchanged when an adjacency is being initialized.  They    describe
  3257.     the    contents of the    link-state database.  Multiple packets may be
  3258.     used to describe the database.  For    this purpose a poll-response
  3259.     procedure is used.    One of the routers is designated to be the
  3260.     master, the    other the slave.  The master sends Database Description
  3261.     packets (polls) which are acknowledged by Database Description
  3262.     packets sent by the    slave (responses).  The    responses are linked to
  3263.     the    polls via the packets' DD sequence numbers.
  3264.  
  3265.  
  3266.     0            1            2            3
  3267.     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
  3268.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3269.        |      3           |       2       |     Packet    length           |
  3270.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3271.        |              Router ID                   |
  3272.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3273.        |               Area    ID                   |
  3274.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3275.        |       Checksum           |  Instance ID  |      0           |
  3276.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3277.        |0|0|0|0|0|I|M|MS          Options                   |
  3278.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3279.        |             DD    sequence number                   |
  3280.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3281.        |                                   |
  3282.        +-                                  -+
  3283.        |                                   |
  3284.        +-               An LSA Header                  -+
  3285.        |                                   |
  3286.        +-                                  -+
  3287.        |                                   |
  3288.        +-                                  -+
  3289.        |                                   |
  3290.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3291.        |                  ...                   |
  3292.  
  3293.  
  3294.     The    format of the Database Description packet is very similar to
  3295.     both the Link State    Request    and Link State Acknowledgment packets.
  3296.     The    main part of all three is a list of items, each    item describing
  3297.     a piece of the link-state database.     The sending of    Database
  3298.     Description    Packets    is documented in Section 10.8 of [Ref1].  The
  3299.     reception of Database Description packets is documented in Section
  3300.     10.6 of [Ref1].
  3301.  
  3302.  
  3303.  
  3304. Coltun et al                               [Page 59]
  3305.  
  3306. Internet Draft             OSPF for IPv6           November 1996
  3307.  
  3308.  
  3309.     I-bit
  3310.     The Init bit.  When set    to 1, this packet is the first in the
  3311.     sequence of Database Description Packets.
  3312.  
  3313.     M-bit
  3314.     The More bit.  When set    to 1, it indicates that    more Database
  3315.     Description Packets are    to follow.
  3316.  
  3317.     MS-bit
  3318.     The Master/Slave bit.  When set    to 1, it indicates that    the
  3319.     router is the master during the    Database Exchange process.
  3320.     Otherwise, the router is the slave.
  3321.  
  3322.     Options
  3323.     The optional capabilities supported by the router, as documented
  3324.     in Section A.2.
  3325.  
  3326.     DD sequence    number
  3327.     Used to    sequence the collection    of Database Description    Packets.
  3328.     The initial value (indicated by    the Init bit being set)    should
  3329.     be unique.  The    DD sequence number then    increments until the
  3330.     complete database description has been sent.
  3331.  
  3332.  
  3333.     The    rest of    the packet consists of a (possibly partial) list of the
  3334.     link-state database's pieces.  Each    LSA in the database is described
  3335.     by its LSA header.    The LSA    header is documented in    Section    A.4.1.
  3336.     It contains    all the    information required to    uniquely identify both
  3337.     the    LSA and    the LSA's current instance.
  3338.  
  3339.  
  3340.  
  3341.  
  3342.  
  3343.  
  3344.  
  3345.  
  3346.  
  3347.  
  3348.  
  3349.  
  3350.  
  3351.  
  3352.  
  3353.  
  3354.  
  3355.  
  3356.  
  3357.  
  3358.  
  3359.  
  3360. Coltun et al                               [Page 60]
  3361.  
  3362. Internet Draft             OSPF for IPv6           November 1996
  3363.  
  3364.  
  3365. A.3.4 The Link State Request packet
  3366.  
  3367.     Link State Request packets are OSPF    packet type 3.    After exchanging
  3368.     Database Description packets with a    neighboring router, a router may
  3369.     find that parts of its link-state database are out-of-date.     The
  3370.     Link State Request packet is used to request the pieces of the
  3371.     neighbor's database    that are more up-to-date.  Multiple Link State
  3372.     Request packets may    need to    be used.
  3373.  
  3374.     A router that sends    a Link State Request packet has    in mind    the
  3375.     precise instance of    the database pieces it is requesting. Each
  3376.     instance is    defined    by its LS sequence number, LS checksum,    and LS
  3377.     age, although these    fields are not specified in the    Link State
  3378.     Request Packet itself.  The    router may receive even    more recent
  3379.     instances in response.
  3380.  
  3381.     The    sending    of Link    State Request packets is documented in Section
  3382.     10.9 of [Ref1].  The reception of Link State Request packets is
  3383.     documented in Section 10.7 of [Ref1].
  3384.  
  3385.  
  3386.     0            1            2            3
  3387.     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
  3388.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3389.        |      3           |       3       |     Packet    length           |
  3390.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3391.        |              Router ID                   |
  3392.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3393.        |               Area    ID                   |
  3394.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3395.        |       Checksum           |  Instance ID  |      0           |
  3396.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3397.        |           0           |       LS type           |
  3398.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3399.        |               Link State ID                   |
  3400.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3401.        |             Advertising Router                   |
  3402.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3403.        |                  ...                   |
  3404.  
  3405.  
  3406.     Each LSA requested is specified by its LS type, Link State ID, and
  3407.     Advertising    Router.     This uniquely identifies the LSA, but not its
  3408.     instance.  Link State Request packets are understood to be requests
  3409.     for    the most recent    instance (whatever that    might be).
  3410.  
  3411.  
  3412.  
  3413.  
  3414.  
  3415.  
  3416. Coltun et al                               [Page 61]
  3417.  
  3418. Internet Draft             OSPF for IPv6           November 1996
  3419.  
  3420.  
  3421. A.3.5 The Link State Update packet
  3422.  
  3423.     Link State Update packets are OSPF packet type 4.  These packets
  3424.     implement the flooding of LSAs.  Each Link State Update packet
  3425.     carries a collection of LSAs one hop further from their origin.
  3426.     Several LSAs may be    included in a single packet.
  3427.  
  3428.     Link State Update packets are multicast on those physical networks
  3429.     that support multicast/broadcast.  In order    to make    the flooding
  3430.     procedure reliable,    flooded    LSAs are acknowledged in Link State
  3431.     Acknowledgment packets.  If    retransmission of certain LSAs is
  3432.     necessary, the retransmitted LSAs are always carried by unicast Link
  3433.     State Update packets. For more information on the reliable flooding
  3434.     of LSAs, consult Section 3.5.
  3435.  
  3436.  
  3437.     0            1            2            3
  3438.     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
  3439.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3440.        |      3           |       4       |     Packet    length           |
  3441.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3442.        |              Router ID                   |
  3443.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3444.        |               Area    ID                   |
  3445.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3446.        |       Checksum           |  Instance ID  |      0           |
  3447.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3448.        |                # LSAs                   |
  3449.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3450.        |                                   |
  3451.        +-                                 +-+
  3452.        |                 LSAs                   |
  3453.        +-                                 +-+
  3454.        |                  ...                   |
  3455.  
  3456.  
  3457.  
  3458.     # LSAs
  3459.     The number of LSAs included in this update.
  3460.  
  3461.  
  3462.     The    body of    the Link State Update packet consists of a list    of LSAs.
  3463.     Each LSA begins with a common 20 byte header, described in Section
  3464.     A.4.2. Detailed formats of the different types of LSAs are described
  3465.     in Section A.4.
  3466.  
  3467.  
  3468.  
  3469.  
  3470.  
  3471.  
  3472. Coltun et al                               [Page 62]
  3473.  
  3474. Internet Draft             OSPF for IPv6           November 1996
  3475.  
  3476.  
  3477. A.3.6 The Link State Acknowledgment packet
  3478.  
  3479.     Link State Acknowledgment Packets are OSPF packet type 5.  To make
  3480.     the    flooding of LSAs reliable, flooded LSAs    are explicitly
  3481.     acknowledged.  This    acknowledgment is accomplished through the
  3482.     sending and    receiving of Link State    Acknowledgment packets.    The
  3483.     sending of Link State Acknowledgement packets is documented    in
  3484.     Section 13.5 of [Ref1].  The reception of Link State Acknowledgement
  3485.     packets is documented in Section 13.7 of [Ref1].
  3486.  
  3487.     Multiple LSAs can be acknowledged in a single Link State
  3488.     Acknowledgment packet.  Depending on the state of the sending
  3489.     interface and the sender of    the corresponding Link State Update
  3490.     packet, a Link State Acknowledgment    packet is sent either to the
  3491.     multicast address AllSPFRouters, to    the multicast address
  3492.     AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for
  3493.     details).
  3494.  
  3495.     The    format of this packet is similar to that of the    Data Description
  3496.     packet.  The body of both packets is simply    a list of LSA headers.
  3497.  
  3498.  
  3499.     0            1            2            3
  3500.     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
  3501.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3502.        |      3           |       5       |     Packet    length           |
  3503.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3504.        |              Router ID                   |
  3505.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3506.        |               Area    ID                   |
  3507.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3508.        |       Checksum           |  Instance ID  |      0           |
  3509.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3510.        |                                   |
  3511.        +-                                  -+
  3512.        |                                   |
  3513.        +-              An LSA Header                  -+
  3514.        |                                   |
  3515.        +-                                  -+
  3516.        |                                   |
  3517.        +-                                  -+
  3518.        |                                   |
  3519.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3520.        |                  ...                   |
  3521.  
  3522.  
  3523.     Each acknowledged LSA is described by its LSA header.  The LSA
  3524.     header is documented in Section A.4.2.  It contains    all the
  3525.  
  3526.  
  3527.  
  3528. Coltun et al                               [Page 63]
  3529.  
  3530. Internet Draft             OSPF for IPv6           November 1996
  3531.  
  3532.  
  3533.     information    required to uniquely identify both the LSA and the LSA's
  3534.     current instance.
  3535.  
  3536.  
  3537.  
  3538.  
  3539.  
  3540.  
  3541.  
  3542.  
  3543.  
  3544.  
  3545.  
  3546.  
  3547.  
  3548.  
  3549.  
  3550.  
  3551.  
  3552.  
  3553.  
  3554.  
  3555.  
  3556.  
  3557.  
  3558.  
  3559.  
  3560.  
  3561.  
  3562.  
  3563.  
  3564.  
  3565.  
  3566.  
  3567.  
  3568.  
  3569.  
  3570.  
  3571.  
  3572.  
  3573.  
  3574.  
  3575.  
  3576.  
  3577.  
  3578.  
  3579.  
  3580.  
  3581.  
  3582.  
  3583.  
  3584. Coltun et al                               [Page 64]
  3585.  
  3586. Internet Draft             OSPF for IPv6           November 1996
  3587.  
  3588.  
  3589. A.4 LSA    formats
  3590.  
  3591.     This memo defines seven distinct types of LSAs.  Each LSA begins
  3592.     with a standard 20 byte LSA    header.     This header is    explained in
  3593.     Section A.4.2.  Succeeding sections    then diagram the separate LSA
  3594.     types.
  3595.  
  3596.     Each LSA describes a piece of the OSPF routing domain.  Every router
  3597.     originates a router-LSA. A network-LSA is advertised for each link
  3598.     by its Designated Router. A    router's link-local addresses are
  3599.     advertised to its neighbors    in link-LSAs. IPv6 prefixes are
  3600.     advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs and
  3601.     AS-external-LSAs.  Location    of specific routers can    be advertised
  3602.     across area    boundaries in inter-area-router-LSAs. All LSAs are then
  3603.     flooded throughout the OSPF    routing    domain.     The flooding algorithm
  3604.     is reliable, ensuring that all routers have    the same collection of
  3605.     LSAs.  (See    Section    3.5 for    more information concerning the    flooding
  3606.     algorithm).     This collection of LSAs is called the link-state
  3607.     database.
  3608.  
  3609.     From the link state    database, each router constructs a shortest path
  3610.     tree with itself as    root.  This yields a routing table (see    Section
  3611.     11 of [Ref1]).  For    the details of the routing table build process,
  3612.     see    Section    3.8.
  3613.  
  3614.  
  3615.  
  3616.  
  3617.  
  3618.  
  3619.  
  3620.  
  3621.  
  3622.  
  3623.  
  3624.  
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.  
  3635.  
  3636.  
  3637.  
  3638.  
  3639.  
  3640. Coltun et al                               [Page 65]
  3641.  
  3642. Internet Draft             OSPF for IPv6           November 1996
  3643.  
  3644.  
  3645. A.4.1 IPv6 Prefix Representation
  3646.  
  3647.     IPv6 addresses are bit strings of length 128. IPv6 routing
  3648.     algorithms,    and OSPF for IPv6 in particular, advertise IPv6    address
  3649.     prefixes. IPv6 address prefixes are    bit strings whose length ranges
  3650.     between 0 and 128 bits (inclusive).
  3651.  
  3652.     Within OSPF, IPv6 address prefixes are always represented by a
  3653.     combination    of three fields: PrefixLength, PrefixOptions, and
  3654.     Address Prefix. PrefixLength is the    length in bits of the prefix.
  3655.     PrefixOptions is an    8-bit field describing various capabilities
  3656.     associated with the    prefix (see Section A.4.2). Address Prefix is an
  3657.     encoding of    the prefix itself as an    even multiple of 32-bit    words,
  3658.     padding with zero bits as necessary; this encoding consumes
  3659.     (PrefixLength + 31)    / 32) 32-bit words.
  3660.  
  3661.     The    default    route is represented by    a prefix of length 0.
  3662.  
  3663.     Examples of    IPv6 Prefix representation in OSPF can be found    in
  3664.     Sections A.4.5, A.4.7, A.4.8 and A.4.9.
  3665.  
  3666.  
  3667.  
  3668.  
  3669.  
  3670.  
  3671.  
  3672.  
  3673.  
  3674.  
  3675.  
  3676.  
  3677.  
  3678.  
  3679.  
  3680.  
  3681.  
  3682.  
  3683.  
  3684.  
  3685.  
  3686.  
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692.  
  3693.  
  3694.  
  3695.  
  3696. Coltun et al                               [Page 66]
  3697.  
  3698. Internet Draft             OSPF for IPv6           November 1996
  3699.  
  3700.  
  3701. A.4.1.1    Prefix Options
  3702.  
  3703.     Each prefix    is advertised along with an 8-bit field    of capabilities.
  3704.     These serve    as input to the    various    routing    calculations, allowing,
  3705.     for    example, certain prefixes to be    ignored    in some    cases, or to be
  3706.     marked as not readvertisable in others.
  3707.  
  3708.                0  1  2    3  4  5     6  7
  3709.               +--+--+--+--+--+--+--+--+
  3710.               |     |  |  |  | P|MC|LA|NU|
  3711.               +--+--+--+--+--+--+--+--+
  3712.  
  3713.               The Prefix Options field
  3714.  
  3715.  
  3716.     NU-bit
  3717.     The "no    unicast" capability bit. If set, the prefix should be
  3718.     excluded from IPv6 unicast calculations, otherwise it should be
  3719.     included.
  3720.  
  3721.     LA-bit
  3722.     The "local address" capability bit. If set, the    prefix is
  3723.     actually an IPv6 interface address of the advertising router.
  3724.  
  3725.     MC-bit
  3726.     The "multicast"    capability bit.    If set,    the prefix should be
  3727.     included in IPv6 multicast routing calculations, otherwise it
  3728.     should be excluded.
  3729.  
  3730.     P-bit
  3731.     The "propagate"    bit. Set on NSSA area prefixes that should be
  3732.     readvertised at    the NSSA area border.
  3733.  
  3734.  
  3735.  
  3736.  
  3737.  
  3738.  
  3739.  
  3740.  
  3741.  
  3742.  
  3743.  
  3744.  
  3745.  
  3746.  
  3747.  
  3748.  
  3749.  
  3750.  
  3751.  
  3752. Coltun et al                               [Page 67]
  3753.  
  3754. Internet Draft             OSPF for IPv6           November 1996
  3755.  
  3756.  
  3757. A.4.2 The LSA header
  3758.  
  3759.     All    LSAs begin with    a common 20 byte header.  This header contains
  3760.     enough information to uniquely identify the    LSA (LS    type, Link State
  3761.     ID,    and Advertising    Router).  Multiple instances of    the LSA    may
  3762.     exist in the routing domain    at the same time.  It is then necessary
  3763.     to determine which instance    is more    recent.     This is accomplished by
  3764.     examining the LS age, LS sequence number and LS checksum fields that
  3765.     are    also contained in the LSA header.
  3766.  
  3767.  
  3768.     0            1            2            3
  3769.     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
  3770.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3771.        |        LS age           |       LS type           |
  3772.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3773.        |            Link State ID                   |
  3774.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3775.        |             Advertising Router                   |
  3776.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3777.        |             LS    sequence number                   |
  3778.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3779.        |     LS checksum           |         length           |
  3780.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3781.  
  3782.  
  3783.  
  3784.     LS age
  3785.     The time in seconds since the LSA was originated.
  3786.  
  3787.     LS type
  3788.     The LS type field indicates the    function performed by the LSA.
  3789.     The high-order three bits of LS    type encode generic properties
  3790.     of the LSA, while the remainder    (called    LSA function code)
  3791.     indicate the LSA's specific functionality. See Section A.4.2.1
  3792.     for a detailed description of LS type.
  3793.  
  3794.     Link State ID
  3795.     Together with LS type and Advertising Router, uniquely
  3796.     identifies the LSA in the link-state database.
  3797.  
  3798.     Advertising    Router
  3799.     The Router ID of the router that originated the    LSA.  For
  3800.     example, in network-LSAs this field is equal to    the Router ID of
  3801.     the network's Designated Router.
  3802.  
  3803.     LS sequence    number
  3804.     Detects    old or duplicate LSAs.    Successive instances of    an LSA
  3805.  
  3806.  
  3807.  
  3808. Coltun et al                               [Page 68]
  3809.  
  3810. Internet Draft             OSPF for IPv6           November 1996
  3811.  
  3812.  
  3813.     are given successive LS    sequence numbers.  See Section 12.1.6 in
  3814.     [Ref1] for more    details.
  3815.  
  3816.     LS checksum
  3817.     The Fletcher checksum of the complete contents of the LSA,
  3818.     including the LSA header but excluding the LS age field. See
  3819.     Section    12.1.7 in [Ref1] for more details.
  3820.  
  3821.     length
  3822.     The length in bytes of the LSA.     This includes the 20 byte LSA
  3823.     header.
  3824.  
  3825.  
  3826.  
  3827.  
  3828.  
  3829.  
  3830.  
  3831.  
  3832.  
  3833.  
  3834.  
  3835.  
  3836.  
  3837.  
  3838.  
  3839.  
  3840.  
  3841.  
  3842.  
  3843.  
  3844.  
  3845.  
  3846.  
  3847.  
  3848.  
  3849.  
  3850.  
  3851.  
  3852.  
  3853.  
  3854.  
  3855.  
  3856.  
  3857.  
  3858.  
  3859.  
  3860.  
  3861.  
  3862.  
  3863.  
  3864. Coltun et al                               [Page 69]
  3865.  
  3866. Internet Draft             OSPF for IPv6           November 1996
  3867.  
  3868.  
  3869. A.4.2.1    LS type
  3870.  
  3871.     The    LS type    field indicates    the function performed by the LSA.  The
  3872.     high-order three bits of LS    type encode generic properties of the
  3873.     LSA, while the remainder (called LSA function code)    indicate the
  3874.     LSA's specific functionality. The format of    the LS type is as
  3875.     follows:
  3876.  
  3877.                       1
  3878.     0  1  2     3  4  5  6  7    8  9  0     1  2  3  4  5
  3879.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3880.       |U |S2|S1|       LSA Function    Code          |
  3881.       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  3882.  
  3883.     The    U bit indicates    how the    LSA should be handled by a router which
  3884.     does not recognize the LSA's function code.     Its values are:
  3885.  
  3886.  
  3887.  
  3888.       U-bit      LSA Handling
  3889.       ____________________________________________________________
  3890.       0      Treat    the LSA    as if it had link-local    flooding scope
  3891.       1      Store    and flood the LSA, as if type understood
  3892.  
  3893.  
  3894.  
  3895.     The    S1 and S2 bits indicate    the flooding scope of the LSA.    The
  3896.     values are:
  3897.  
  3898.  
  3899.  
  3900.     _______________________________________________________________________
  3901.     0     0    Link-Local Scoping. Flooded only on link it is originated    on.
  3902.     0     1    Area Scoping. Flooded to all routers in the originating area
  3903.     1     0    AS Scoping. Flooded to all routers in the    AS
  3904.     1     1    Reserved
  3905.  
  3906.  
  3907.  
  3908.  
  3909.     The    LSA function codes are defined as follows. The origination and
  3910.     processing of these    LSA function codes are defined elsewhere in this
  3911.     memo, except for the group-membership-LSA (see [Ref7]) and the
  3912.     Type-7-LSA (see [Ref8]). Each LSA function code also implies a
  3913.     specific setting for the U,    S1 and S2 bits,    as shown below.
  3914.  
  3915.  
  3916.  
  3917.  
  3918.  
  3919.  
  3920. Coltun et al                               [Page 70]
  3921.  
  3922. Internet Draft             OSPF for IPv6           November 1996
  3923.  
  3924.  
  3925.  
  3926.           LSA function code      LS Type   Description
  3927.           ___________________________________________________
  3928.           1              0x2001    Router-LSA
  3929.           2              0x2002    Network-LSA
  3930.           3              0x2003    Inter-Area-Prefix-LSA
  3931.           4              0x2004    Inter-Area-Router-LSA
  3932.           5              0x4005    AS-External-LSA
  3933.           6              0x2006    Group-membership-LSA
  3934.           7              0x2007    Type-7-LSA
  3935.           8              0x0008    Link-LSA
  3936.           9              0x2009    Intra-Area-Prefix-LSA
  3937.  
  3938.  
  3939.  
  3940.  
  3941.  
  3942.  
  3943.  
  3944.  
  3945.  
  3946.  
  3947.  
  3948.  
  3949.  
  3950.  
  3951.  
  3952.  
  3953.  
  3954.  
  3955.  
  3956.  
  3957.  
  3958.  
  3959.  
  3960.  
  3961.  
  3962.  
  3963.  
  3964.  
  3965.  
  3966.  
  3967.  
  3968.  
  3969.  
  3970.  
  3971.  
  3972.  
  3973.  
  3974.  
  3975.  
  3976. Coltun et al                               [Page 71]
  3977.  
  3978. Internet Draft             OSPF for IPv6           November 1996
  3979.  
  3980.  
  3981. A.4.3 Router-LSAs
  3982.  
  3983.     Router-LSAs    have LS    type equal to 0x2001.  Each router in an area
  3984.     originates one or more router-LSAs.     The complete collection of
  3985.     router-LSAs    originated by the router describe the state and    cost of
  3986.     the    router's interfaces to the area. For details concerning    the
  3987.     construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are
  3988.     flooded throughout a single    area only.
  3989.  
  3990.  
  3991.     0            1            2            3
  3992.     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
  3993.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3994.        |        LS age           |0|0|1|        1           |
  3995.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3996.        |            Link State ID                   |
  3997.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3998.        |             Advertising Router                   |
  3999.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4000.        |             LS    sequence number                   |
  4001.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4002.        |     LS checksum           |         length           |
  4003.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4004.        |    0  |W|V|E|B|         Options                   |
  4005.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4006.        |     Type      |       0       |       Metric           |
  4007.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4008.        |               Interface ID                   |
  4009.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4010.        |            Neighbor Interface ID               |
  4011.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4012.        |             Neighbor Router ID                   |
  4013.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4014.        |                  ...                   |
  4015.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4016.        |     Type      |       0       |       Metric           |
  4017.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4018.        |               Interface ID                   |
  4019.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4020.        |            Neighbor Interface ID               |
  4021.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4022.        |             Neighbor Router ID                   |
  4023.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4024.        |                  ...                   |
  4025.  
  4026.  
  4027.     A single router may    originate one or more Router LSAs, distinguished
  4028.     by their Link-State    IDs (which are chosen arbitrarily by the
  4029.  
  4030.  
  4031.  
  4032. Coltun et al                               [Page 72]
  4033.  
  4034. Internet Draft             OSPF for IPv6           November 1996
  4035.  
  4036.  
  4037.     originating    router).  The Options field and    V, E and B bits    should
  4038.     be the same    in all Router LSAs from    a single originator.  However,
  4039.     in the case    of a mismatch the values in the    LSA with the lowest Link
  4040.     State ID take precedence. When more    than one Router    LSA is received
  4041.     from a single router, the links are    processed as if    concatenated
  4042.     into a single LSA.
  4043.  
  4044.  
  4045.     bit    V
  4046.     When set, the router is    an endpoint of one or more fully
  4047.     adjacent virtual links having the described area as Transit area
  4048.     (V is for virtual link endpoint).
  4049.  
  4050.     bit    E
  4051.     When set, the router is    an AS boundary router (E is for
  4052.     external).
  4053.  
  4054.     bit    B
  4055.     When set, the router is    an area    border router (B is for    border).
  4056.  
  4057.     bit    W
  4058.     When set, the router is    a wild-card multicast receiver.     When
  4059.     running    MOSPF, these routers receive all multicast datagrams,
  4060.     regardless of destination. See Sections    3, 4 and A.2 of    [Ref8]
  4061.     for details.
  4062.  
  4063.     Options
  4064.     The optional capabilities supported by the router, as documented
  4065.     in Section A.2.
  4066.  
  4067.  
  4068.     The    following fields are used to describe each router interface.
  4069.     The    Type field indicates the kind of interface being described.  It
  4070.     may    be an interface    to a transit network, a    point-to-point
  4071.     connection to another router or a virtual link.  The values    of all
  4072.     the    other fields describing    a router interface depend on the
  4073.     interface's    Type field.
  4074.  
  4075.  
  4076.     Type
  4077.     The kind of interface being described.    One of the following:
  4078.  
  4079.  
  4080.  
  4081.  
  4082.  
  4083.  
  4084.  
  4085.  
  4086.  
  4087.  
  4088. Coltun et al                               [Page 73]
  4089.  
  4090. Internet Draft             OSPF for IPv6           November 1996
  4091.  
  4092.  
  4093.  
  4094.          Type    Description
  4095.          __________________________________________________
  4096.          1    Point-to-point connection to another router
  4097.          2    Connection to a    transit    network
  4098.          3    Reserved
  4099.          4    Virtual    link
  4100.  
  4101.  
  4102.  
  4103.  
  4104.     Metric
  4105.     The cost of using this router interface, for outbound traffic.
  4106.  
  4107.     Interface ID
  4108.     The Interface ID assigned to the interface being described. See
  4109.     Sections 3.1.2 and C.3.
  4110.  
  4111.     Neighbor Interface ID
  4112.     The Interface ID the neighbor router (or the attached link's
  4113.     Designated Router, for Type 2 interfaces) has been advertising
  4114.     in hello packets sent on the attached link.
  4115.  
  4116.     Neighbor Router ID
  4117.     The Router ID the neighbor router (or the attached link's
  4118.     Designated Router, for Type 2 interfaces).
  4119.  
  4120.     For Type 2 links, the combination of Neighbor Interface    ID and
  4121.     Neighbor Router    ID allows the network-LSA for the attached link
  4122.     to be found in the link-state database.
  4123.  
  4124.  
  4125.  
  4126.  
  4127.  
  4128.  
  4129.  
  4130.  
  4131.  
  4132.  
  4133.  
  4134.  
  4135.  
  4136.  
  4137.  
  4138.  
  4139.  
  4140.  
  4141.  
  4142.  
  4143.  
  4144. Coltun et al                               [Page 74]
  4145.  
  4146. Internet Draft             OSPF for IPv6           November 1996
  4147.  
  4148.  
  4149. A.4.4 Network-LSAs
  4150.  
  4151.     Network-LSAs have LS type equal to 0x2002.    A network-LSA is
  4152.     originated for each    broadcast and NBMA link    in the area which
  4153.     supports two or more routers.  The network-LSA is originated by the
  4154.     link's Designated Router.  The LSA describes all routers attached to
  4155.     the    link, including    the Designated Router itself.  The LSA's Link
  4156.     State ID field is set to the Interface ID that the Designated Router
  4157.     has    been advertising in Hello packets on the link.
  4158.  
  4159.     The    distance from the network to all attached routers is zero.  This
  4160.     is why the metric fields need not be specified in the network-LSA.
  4161.     For    details    concerning the construction of network-LSAs, see Section
  4162.     3.4.3.2.
  4163.  
  4164.  
  4165.     0            1            2            3
  4166.     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
  4167.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4168.        |        LS age           |0|0|1|        2           |
  4169.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4170.        |            Link State ID                   |
  4171.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4172.        |             Advertising Router                   |
  4173.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4174.        |             LS    sequence number                   |
  4175.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4176.        |     LS checksum           |         length           |
  4177.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4178.        |      0           |          Options                   |
  4179.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4180.        |            Attached Router                   |
  4181.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4182.        |                  ...                   |
  4183.  
  4184.  
  4185.  
  4186.     Attached Router
  4187.     The Router IDs of each of the routers attached to the link.
  4188.     Actually, only those routers that are fully adjacent to    the
  4189.     Designated Router are listed.  The Designated Router includes
  4190.     itself in this list.  The number of routers included can be
  4191.     deduced    from the LSA header's length field.
  4192.  
  4193.  
  4194.  
  4195.  
  4196.  
  4197.  
  4198.  
  4199.  
  4200. Coltun et al                               [Page 75]
  4201.  
  4202. Internet Draft             OSPF for IPv6           November 1996
  4203.  
  4204.  
  4205. A.4.5 Inter-Area-Prefix-LSAs
  4206.  
  4207.     Inter-Area-Prefix-LSAs have    LS type    equal to 0x2003.  These    LSAs are
  4208.     are    the IPv6 equivalent of OSPF for    IPv4's type 3 summary-LSAs (see
  4209.     Section 12.4.3 of [Ref1]).    Originated by area border routers, they
  4210.     describe routes to IPv6 address prefixes that belong to other areas.
  4211.     A separate Inter-Area-Prefix-LSA is    originated for each IPv6 address
  4212.     prefix. For    details    concerning the construction of Inter-Area-
  4213.     Prefix-LSAs, see Section 3.4.3.3.
  4214.  
  4215.     For    stub areas, Inter-Area-Prefix-LSAs can also be used to describe
  4216.     a (per-area) default route.     Default summary routes    are used in stub
  4217.     areas instead of flooding a    complete set of    external routes.  When
  4218.     describing a default summary route,    the Inter-Area-Prefix-LSA's
  4219.     PrefixLength is set    to 0.
  4220.  
  4221.  
  4222.     0            1            2            3
  4223.     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
  4224.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4225.        |        LS age           |0|0|1|        3           |
  4226.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4227.        |            Link State ID                   |
  4228.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4229.        |             Advertising Router                   |
  4230.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4231.        |             LS    sequence number                   |
  4232.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4233.        |     LS checksum           |         length           |
  4234.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4235.        |      0           |          Metric               |
  4236.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4237.        | PrefixLength  | PrefixOptions |          (0)           |
  4238.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4239.        |             Address Prefix                   |
  4240.        |                  ...                   |
  4241.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4242.  
  4243.  
  4244.     Metric
  4245.     The cost of this route.     Expressed in the same units as    the
  4246.     interface costs    in the router-LSAs. When the Inter-Area-Prefix-
  4247.     LSA is describing a route to a range of    addresses (see Section
  4248.     C.2) the cost is set to    the maximum cost to any    reachable
  4249.     component of the address range.
  4250.  
  4251.     PrefixLength, PrefixOptions    and Address Prefix
  4252.     Representation of the IPv6 address prefix, as described    in
  4253.  
  4254.  
  4255.  
  4256. Coltun et al                               [Page 76]
  4257.  
  4258. Internet Draft             OSPF for IPv6           November 1996
  4259.  
  4260.  
  4261.     Section    A.4.1.
  4262.  
  4263.  
  4264.  
  4265.  
  4266.  
  4267.  
  4268.  
  4269.  
  4270.  
  4271.  
  4272.  
  4273.  
  4274.  
  4275.  
  4276.  
  4277.  
  4278.  
  4279.  
  4280.  
  4281.  
  4282.  
  4283.  
  4284.  
  4285.  
  4286.  
  4287.  
  4288.  
  4289.  
  4290.  
  4291.  
  4292.  
  4293.  
  4294.  
  4295.  
  4296.  
  4297.  
  4298.  
  4299.  
  4300.  
  4301.  
  4302.  
  4303.  
  4304.  
  4305.  
  4306.  
  4307.  
  4308.  
  4309.  
  4310.  
  4311.  
  4312. Coltun et al                               [Page 77]
  4313.  
  4314. Internet Draft             OSPF for IPv6           November 1996
  4315.  
  4316.  
  4317. A.4.6 Inter-Area-Router-LSAs
  4318.  
  4319.     Inter-Area-Router-LSAs have    LS type    equal to 0x2004.  These    LSAs are
  4320.     are    the IPv6 equivalent of OSPF for    IPv4's type 4 summary-LSAs (see
  4321.     Section 12.4.3 of [Ref1]).    Originated by area border routers, they
  4322.     describe routes to routers in other    areas.    (To see    why it is
  4323.     necessary to advertise the location    of each    ASBR, consult Section
  4324.     16.4 in [Ref1].)  Each LSA describes a route to a single router. For
  4325.     details concerning the construction    of Inter-Area-Router-LSAs, see
  4326.     Section 3.4.3.4.
  4327.  
  4328.  
  4329.     0            1            2            3
  4330.     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
  4331.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4332.        |        LS age           |0|0|1|          4               |
  4333.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4334.        |            Link State ID                   |
  4335.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4336.        |             Advertising Router                   |
  4337.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4338.        |             LS    sequence number                   |
  4339.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4340.        |     LS checksum           |         length           |
  4341.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4342.        |      0           |          Options               |
  4343.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4344.        |      0           |          Metric               |
  4345.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4346.        |             Destination Router    ID               |
  4347.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4348.  
  4349.  
  4350.     Options
  4351.     The optional capabilities supported by the router, as documented
  4352.     in Section A.2.
  4353.  
  4354.     Metric
  4355.     The cost of this route.     Expressed in the same units as    the
  4356.     interface costs    in the router-LSAs.
  4357.  
  4358.     Destination    Router ID
  4359.     The Router ID of the router being described by the LSA.
  4360.  
  4361.  
  4362.  
  4363.  
  4364.  
  4365.  
  4366.  
  4367.  
  4368. Coltun et al                               [Page 78]
  4369.  
  4370. Internet Draft             OSPF for IPv6           November 1996
  4371.  
  4372.  
  4373. A.4.7 AS-external-LSAs
  4374.  
  4375.     AS-external-LSAs have LS type equal    to 0x4005.  These LSAs are
  4376.     originated by AS boundary routers, and describe destinations
  4377.     external to    the AS.    Each LSA describes a route to a    single IPv6
  4378.     address prefix. For    details    concerning the construction of AS-
  4379.     external-LSAs, see Section 3.4.3.5.
  4380.  
  4381.     AS-external-LSAs can be used to describe a default route.  Default
  4382.     routes are used when no specific route exists to the destination.
  4383.     When describing a default route, the AS-external-LSA's PrefixLength
  4384.     is set to 0.
  4385.  
  4386.  
  4387.     0            1            2            3
  4388.     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
  4389.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4390.        |        LS age           |0|1|0|        5           |
  4391.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4392.        |            Link State ID                   |
  4393.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4394.        |             Advertising Router                   |
  4395.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4396.        |             LS    sequence number                   |
  4397.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4398.        |     LS checksum           |         length           |
  4399.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4400.        |     |E|F|T|         Metric                   |
  4401.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4402.        | PrefixLength  | PrefixOptions |     Referenced    LS Type           |
  4403.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4404.        |             Address Prefix                   |
  4405.        |                  ...                   |
  4406.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4407.        |                                   |
  4408.        +-                                  -+
  4409.        |                                   |
  4410.        +-          Forwarding Address (Optional)              -+
  4411.        |                                   |
  4412.        +-                                  -+
  4413.        |                                   |
  4414.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4415.        |          External Route Tag (Optional)               |
  4416.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4417.        |        Referenced Link    State ID (Optional)           |
  4418.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4419.  
  4420.  
  4421.  
  4422.  
  4423.  
  4424. Coltun et al                               [Page 79]
  4425.  
  4426. Internet Draft             OSPF for IPv6           November 1996
  4427.  
  4428.  
  4429.     bit    E
  4430.     The type of external metric.  If bit E is set, the metric
  4431.     specified is a Type 2 external metric.    This means the metric is
  4432.     considered larger than any intra-AS path.  If bit E is zero, the
  4433.     specified metric is a Type 1 external metric.  This means that
  4434.     it is expressed    in the same units as the link state metric
  4435.     (i.e., the same    units as interface cost).
  4436.  
  4437.     bit    F
  4438.     If set,    a Forwarding Address has been included in the LSA.
  4439.  
  4440.     bit    T
  4441.     If set,    an External Route Tag has been included    in the LSA.
  4442.  
  4443.     Metric
  4444.     The cost of this route.     Interpretation    depends    on the external
  4445.     type indication    (bit E above).
  4446.  
  4447.     PrefixLength, PrefixOptions    and Address Prefix
  4448.     Representation of the IPv6 address prefix, as described    in
  4449.     Section    A.4.1.
  4450.  
  4451.     Referenced LS type
  4452.     If non-zero, an    LSA with this LS type is to be associated with
  4453.     this LSA (see Referenced Link State ID below).
  4454.  
  4455.     Forwarding address
  4456.     A fully    qualified IPv6 address (128 bits).  Included in    the LSA
  4457.     if and only if bit F has been set.  If included, Data traffic
  4458.     for the    advertised destination and TOS will be forwarded to this
  4459.     address. Must not be set to the    IPv6 Unspecified Address
  4460.     (0:0:0:0:0:0:0:0).
  4461.  
  4462.     External Route Tag
  4463.     A 32-bit field which may be used to communicate    additional
  4464.     information between AS boundary    routers; see [Ref5] for    example
  4465.     usage. Included    in the LSA if and only if bit T    has been set.
  4466.  
  4467.     Referenced Link State ID
  4468.     Included if and    only if    Reference LS Type is non-zero.    If
  4469.     included, additional information concerning the    advertised
  4470.     external route can be found in the LSA having LS type equal to
  4471.     "Referenced LS Type", Link State ID equal to "Referenced Link
  4472.     State ID" and Advertising Router the same as that specified in
  4473.     the AS-external-LSA's link state header. This additional
  4474.     information is not used    by the OSPF protocol itself.  It may be
  4475.     used to    communicate information    between    AS boundary routers; the
  4476.     precise    nature of such information is outside the scope    of this
  4477.  
  4478.  
  4479.  
  4480. Coltun et al                               [Page 80]
  4481.  
  4482. Internet Draft             OSPF for IPv6           November 1996
  4483.  
  4484.  
  4485.     specification.
  4486.  
  4487.     All, none or some of the fields labeled Forwarding address,    External
  4488.     Route Tag and Referenced Link State    ID may be present in the AS-
  4489.     external-LSA (as indicated by the setting of bit F,    bit T and
  4490.     Referenced LS type respectively). However, when present Forwarding
  4491.     Address always comes first,    with External Route Tag    always preceding
  4492.     Referenced Link State ID.
  4493.  
  4494.  
  4495.  
  4496.  
  4497.  
  4498.  
  4499.  
  4500.  
  4501.  
  4502.  
  4503.  
  4504.  
  4505.  
  4506.  
  4507.  
  4508.  
  4509.  
  4510.  
  4511.  
  4512.  
  4513.  
  4514.  
  4515.  
  4516.  
  4517.  
  4518.  
  4519.  
  4520.  
  4521.  
  4522.  
  4523.  
  4524.  
  4525.  
  4526.  
  4527.  
  4528.  
  4529.  
  4530.  
  4531.  
  4532.  
  4533.  
  4534.  
  4535.  
  4536. Coltun et al                               [Page 81]
  4537.  
  4538. Internet Draft             OSPF for IPv6           November 1996
  4539.  
  4540.  
  4541. A.4.8 Link-LSAs
  4542.  
  4543.     Link-LSAs have LS type equal to 0x0008.  A router originates a
  4544.     separate Link-LSA for each link it is attached to. These LSAs have
  4545.     local-link flooding    scope; they are    never flooded beyond the link
  4546.     that they are associated with. Link-LSAs have three    purposes: 1)
  4547.     they provide the router's link-local address to all    other routers
  4548.     attached to    the link and 2)    they inform other routers attached to
  4549.     the    link of    a list of IPv6 prefixes    to associate with the link and
  4550.     3) they allow the router to    assert a collection of Options bits to
  4551.     associate with the Network-LSA that    will be    originated for the link.
  4552.  
  4553.     A link-LSA's Link State ID is set equal to the originating router's
  4554.     Interface ID on the    link.
  4555.     0            1            2            3
  4556.     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
  4557.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4558.        |        LS age           |0|0|0|         8           |
  4559.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4560.        |            Link State ID                   |
  4561.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4562.        |              Advertising Router               |
  4563.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4564.        |              LS sequence number               |
  4565.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4566.        |     LS checksum           |         length           |
  4567.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4568.        |    Rtr    Pri    |         Options               |
  4569.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4570.        |                                   |
  4571.        +-                                  -+
  4572.        |                                   |
  4573.        +-          Link-local Interface Address              -+
  4574.        |                                   |
  4575.        +-                                  -+
  4576.        |                                   |
  4577.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4578.        |              # prefixes                   |
  4579.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4580.        |  PrefixLength | PrefixOptions |          (0)           |
  4581.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4582.        |             Address Prefix                   |
  4583.        |                  ...                   |
  4584.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4585.        |                  ...                   |
  4586.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4587.        |  PrefixLength | PrefixOptions |          (0)           |
  4588.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4589.  
  4590.  
  4591.  
  4592. Coltun et al                               [Page 82]
  4593.  
  4594. Internet Draft             OSPF for IPv6           November 1996
  4595.  
  4596.  
  4597.        |             Address Prefix                   |
  4598.        |                  ...                   |
  4599.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4600.  
  4601.     Rtr    Pri
  4602.     The Router Priority of the interface attaching the originating
  4603.     router to the link.
  4604.  
  4605.     Options
  4606.     The set    of Options bits    that the router    would like set in the
  4607.     Network-LSA that will be originated for    the link.
  4608.  
  4609.     Link-local Interface Address
  4610.     The originating    router's link-local interface address on the
  4611.     link.
  4612.  
  4613.     # prefixes
  4614.     The number of IPv6 address prefixes contained in the LSA.
  4615.  
  4616.     The    rest of    the link-LSA contains a    list of    IPv6 prefixes to be
  4617.     associated with the    link.
  4618.  
  4619.     PrefixLength, PrefixOptions    and Address Prefix
  4620.     Representation of an IPv6 address prefix, as described in
  4621.     Section    A.4.1.
  4622.  
  4623.  
  4624.  
  4625.  
  4626.  
  4627.  
  4628.  
  4629.  
  4630.  
  4631.  
  4632.  
  4633.  
  4634.  
  4635.  
  4636.  
  4637.  
  4638.  
  4639.  
  4640.  
  4641.  
  4642.  
  4643.  
  4644.  
  4645.  
  4646.  
  4647.  
  4648. Coltun et al                               [Page 83]
  4649.  
  4650. Internet Draft             OSPF for IPv6           November 1996
  4651.  
  4652.  
  4653. A.4.9 Intra-Area-Prefix-LSAs
  4654.  
  4655.     Intra-Area-Prefix-LSAs have    LS type    equal to 0x2009. A router uses
  4656.     Intra-Area-Prefix-LSAs to advertise    one or more IPv6 address
  4657.     prefixes that are associated with a) the router itself, b) an
  4658.     attached stub network segment or c)    an attached transit network
  4659.     segment. In    IPv4, a) and b)    were accomplished via the router's
  4660.     router-LSA,    and c) via a network-LSA. However, in OSPF for IPv6 all
  4661.     addressing information has been removed from router-LSAs and
  4662.     network-LSAs, leading to the introduction of the Intra-Area-Prefix-
  4663.     LSA.
  4664.  
  4665.     A router can originate multiple Intra-Area-Prefix-LSAs for each
  4666.     router or transit network; each such LSA is    distinguished by its
  4667.     Link State ID.
  4668.  
  4669.     0            1            2            3
  4670.     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
  4671.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4672.        |        LS age           |0|0|1|          9           |
  4673.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4674.        |            Link State ID                   |
  4675.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4676.        |             Advertising Router                   |
  4677.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4678.        |             LS    sequence number                   |
  4679.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4680.        |     LS checksum           |         length           |
  4681.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4682.        |      # prefixes           |     Referenced    LS type           |
  4683.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4684.        |           Referenced Link State ID               |
  4685.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4686.        |        Referenced Advertising Router               |
  4687.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4688.        |  PrefixLength | PrefixOptions |       Metric           |
  4689.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4690.        |            Address    Prefix                   |
  4691.        |                  ...                   |
  4692.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4693.        |                  ...                   |
  4694.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4695.        |  PrefixLength | PrefixOptions |       Metric           |
  4696.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4697.        |            Address    Prefix                   |
  4698.        |                  ...                   |
  4699.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4700.  
  4701.  
  4702.  
  4703.  
  4704. Coltun et al                               [Page 84]
  4705.  
  4706. Internet Draft             OSPF for IPv6           November 1996
  4707.  
  4708.  
  4709.     # prefixes
  4710.     The number of IPv6 address prefixes contained in the LSA.
  4711.  
  4712.     Referenced LS type,    Referenced Link    State ID and Referenced
  4713.     Advertising Router
  4714.     Identifies the router-LSA or network-LSA with which the    IPv6
  4715.     address    prefixes should    be associated. If Referenced LS    type is
  4716.     1, the prefixes    are associated with a router-LSA, Referenced
  4717.     Link State ID should be    0 and Referenced Advertising Router
  4718.     should be the originating router's Router ID. If Referenced LS
  4719.     type is    2, the prefixes    are associated with a network-LSA,
  4720.     Referenced Link    State ID should    be the Interface ID of the
  4721.     link's Designated Router and Referenced    Advertising Router
  4722.     should be the Designated Router's Router ID.
  4723.  
  4724.     The    rest of    the Intra-Area-Prefix-LSA contains a list of IPv6
  4725.     prefixes to    be associated with the router or transit link, together
  4726.     with the cost of each prefix.
  4727.  
  4728.     PrefixLength, PrefixOptions    and Address Prefix
  4729.     Representation of an IPv6 address prefix, as described in
  4730.     Section    A.4.1.
  4731.  
  4732.     Metric
  4733.     The cost of this prefix.  Expressed in the same    units as the
  4734.     interface costs    in the router-LSAs.
  4735.  
  4736.  
  4737.  
  4738.  
  4739.  
  4740.  
  4741.  
  4742.  
  4743.  
  4744.  
  4745.  
  4746.  
  4747.  
  4748.  
  4749.  
  4750.  
  4751.  
  4752.  
  4753.  
  4754.  
  4755.  
  4756.  
  4757.  
  4758.  
  4759.  
  4760. Coltun et al                               [Page 85]
  4761.  
  4762. Internet Draft             OSPF for IPv6           November 1996
  4763.  
  4764.  
  4765. B. Architectural Constants
  4766.  
  4767.     Architectural constants for    the OSPF protocol are defined in
  4768.     Appendix C of [Ref1]. The only difference for OSPF for IPv6    is that
  4769.     DefaultDestination is encoded as a prefix of length    0 (see Section
  4770.     A.4.1).
  4771.  
  4772. C. Configurable    Constants
  4773.  
  4774.     The    OSPF protocol has quite    a few configurable parameters.    These
  4775.     parameters are listed below.  They are grouped into    general
  4776.     functional categories (area    parameters, interface parameters, etc.).
  4777.     Sample values are given for    some of    the parameters.
  4778.  
  4779.     Some parameter settings need to be consistent among    groups of
  4780.     routers.  For example, all routers in an area must agree on    that
  4781.     area's parameters, and all routers attached    to a network must agree
  4782.     on that network's HelloInterval and    RouterDeadInterval.
  4783.  
  4784.     Some parameters may    be determined by router    algorithms outside of
  4785.     this specification (e.g., the address of a host connected to the
  4786.     router via a SLIP line).  From OSPF's point    of view, these items are
  4787.     still configurable.
  4788.  
  4789.     C.1    Global parameters
  4790.  
  4791.     In general, a separate copy of the OSPF    protocol is run    for each
  4792.     area.  Because of this,    most configuration parameters are
  4793.     defined    on a per-area basis.  The few global configuration
  4794.     parameters are listed below.
  4795.  
  4796.  
  4797.     Router ID
  4798.         This is a 32-bit number that uniquely identifies the router
  4799.         in the Autonomous System. If a router's OSPF Router    ID is
  4800.         changed, the router's OSPF software    should be restarted
  4801.         before the new Router ID takes effect. Before restarting in
  4802.         order to change its    Router ID, the router should flush its
  4803.         self-originated LSAs from the routing domain (see Section
  4804.         14.1 of [Ref1]), or    they will persist for up to MaxAge
  4805.         minutes.
  4806.  
  4807.         Because the    size of    the Router ID is smaller than an IPv6
  4808.         address, it    cannot be set to one of    the router's IPv6
  4809.         addresses (as is commonly done for IPv4). Possible Router ID
  4810.         assignment procedures for IPv6 include: a) assign the IPv6
  4811.         Router ID as one of    the router's IPv4 addresses or b) assign
  4812.         IPv6 Router    IDs through some local administrative procedure
  4813.  
  4814.  
  4815.  
  4816. Coltun et al                               [Page 86]
  4817.  
  4818. Internet Draft             OSPF for IPv6           November 1996
  4819.  
  4820.  
  4821.         (similar to    procedures used    by manufacturers to assign
  4822.         product serial numbers).
  4823.  
  4824.         The    Router ID of 0.0.0.0 is    reserved, and should not be
  4825.         used.
  4826.  
  4827.     C.2    Area parameters
  4828.  
  4829.     All routers belonging to an area must agree on that area's
  4830.     configuration.    Disagreements between two routers will lead to
  4831.     an inability for adjacencies to    form between them, with    a
  4832.     resulting hindrance to the flow    of routing protocol and    data
  4833.     traffic.  The following    items must be configured for an    area:
  4834.  
  4835.  
  4836.     Area ID
  4837.         This is a 32-bit number that identifies the    area.  The Area
  4838.         ID of 0 is reserved    for the    backbone.
  4839.  
  4840.     List of    address    ranges
  4841.         Address ranges control the advertisement of    routes across
  4842.         area boundaries. Each address range    consists of the
  4843.         following items:
  4844.  
  4845.         [IPv6 prefix, prefix length]
  4846.             Describes the collection of    IPv6 addresses contained
  4847.             in the address range.
  4848.  
  4849.         Status  Set    to either Advertise or DoNotAdvertise.    Routing
  4850.             information    is condensed at    area boundaries.
  4851.             External to    the area, at most a single route is
  4852.             advertised (via a inter-area-prefix-LSA) for each
  4853.             address range. The route is    advertised if and only
  4854.             if the address range's Status is set to Advertise.
  4855.             Unadvertised ranges    allow the existence of certain
  4856.             networks to    be intentionally hidden    from other
  4857.             areas. Status is set to Advertise by default.
  4858.  
  4859.     ExternalRoutingCapability
  4860.         Whether AS-external-LSAs will be flooded into/throughout the
  4861.         area.  If AS-external-LSAs are excluded from the area, the
  4862.         area is called a "stub".  Internal to stub areas, routing to
  4863.         external destinations will be based    solely on a default
  4864.         inter-area route.  The backbone cannot be configured as a
  4865.         stub area.    Also, virtual links cannot be configured through
  4866.         stub areas.     For more information, see Section 3.6 of
  4867.         [Ref1].
  4868.  
  4869.  
  4870.  
  4871.  
  4872. Coltun et al                               [Page 87]
  4873.  
  4874. Internet Draft             OSPF for IPv6           November 1996
  4875.  
  4876.  
  4877.     StubDefaultCost
  4878.         If the area    has been configured as a stub area, and    the
  4879.         router itself is an    area border router, then the
  4880.         StubDefaultCost indicates the cost of the default inter-
  4881.         area-prefix-LSA that the router should advertise into the
  4882.         area. See Section 12.4.3.1 of [Ref1] for more information.
  4883.  
  4884.     C.3    Router interface parameters
  4885.  
  4886.     Some of    the configurable router    interface parameters (such as
  4887.     Area ID, HelloInterval and RouterDeadInterval) actually    imply
  4888.     properties of the attached links, and therefore    must be
  4889.     consistent across all the routers attached to that link.  The
  4890.     parameters that    must be    configured for a router    interface are:
  4891.  
  4892.  
  4893.     IPv6 link-local    address
  4894.         The    IPv6 link-local    address    associated with    this interface.
  4895.         May    be learned through auto-configuration.
  4896.  
  4897.     Area ID
  4898.         The    OSPF area to which the attached    link belongs.
  4899.  
  4900.     Instance ID
  4901.         The    OSPF protocol instance associated with this OSPF
  4902.         interface. Defaults    to 0.
  4903.  
  4904.     Interface ID
  4905.         32-bit number uniquely identifying this interface among the
  4906.         collection of this router's    interfaces. For    example, in some
  4907.         implementations it may be possible to use the MIB-II
  4908.         IfIndex.
  4909.  
  4910.     IPv6 prefixes
  4911.         The    list of    IPv6 prefixes to associate with    the link. These
  4912.         will be advertised in intra-area-prefix-LSAs.
  4913.  
  4914.     Interface output cost(s)
  4915.         The    cost of    sending    a packet on the    interface, expressed in
  4916.         the    link state metric.  This is advertised as the link cost
  4917.         for    this interface in the router's router-LSA. The interface
  4918.         output cost    must always be greater than 0.
  4919.  
  4920.     RxmtInterval
  4921.         The    number of seconds between LSA retransmissions, for
  4922.         adjacencies    belonging to this interface.  Also used    when
  4923.         retransmitting Database Description    and Link State Request
  4924.         Packets.  This should be well over the expected round-trip
  4925.  
  4926.  
  4927.  
  4928. Coltun et al                               [Page 88]
  4929.  
  4930. Internet Draft             OSPF for IPv6           November 1996
  4931.  
  4932.  
  4933.         delay between any two routers on the attached link.     The
  4934.         setting of this value should be conservative or needless
  4935.         retransmissions will result.  Sample value for a local area
  4936.         network: 5 seconds.
  4937.  
  4938.     InfTransDelay
  4939.         The    estimated number of seconds it takes to    transmit a Link
  4940.         State Update Packet    over this interface.  LSAs contained in
  4941.         the    update packet must have    their age incremented by this
  4942.         amount before transmission.     This value should take    into
  4943.         account the    transmission and propagation delays of the
  4944.         interface.    It must    be greater than    0.  Sample value for a
  4945.         local area network:    1 second.
  4946.  
  4947.     Router Priority
  4948.         An 8-bit unsigned integer.    When two routers attached to a
  4949.         network both attempt to become Designated Router, the one
  4950.         with the highest Router Priority takes precedence.    If there
  4951.         is still a tie, the    router with the    highest    Router ID takes
  4952.         precedence.     A router whose    Router Priority    is set to 0 is
  4953.         ineligible to become Designated Router on the attached link.
  4954.         Router Priority is only configured for interfaces to
  4955.         broadcast and NBMA networks.
  4956.  
  4957.     HelloInterval
  4958.         The    length of time,    in seconds, between the    Hello Packets
  4959.         that the router sends on the interface.  This value    is
  4960.         advertised in the router's Hello Packets.  It must be the
  4961.         same for all routers attached to a common link.  The smaller
  4962.         the    HelloInterval, the faster topological changes will be
  4963.         detected; however, more OSPF routing protocol traffic will
  4964.         ensue.  Sample value for a X.25 PDN: 30 seconds.  Sample
  4965.         value for a    local area network (LAN): 10 seconds.
  4966.  
  4967.     RouterDeadInterval
  4968.         After ceasing to hear a router's Hello Packets, the    number
  4969.         of seconds before its neighbors declare the    router down.
  4970.         This is also advertised in the router's Hello Packets in
  4971.         their RouterDeadInterval field.  This should be some
  4972.         multiple of    the HelloInterval (say 4).  This value again
  4973.         must be the    same for all routers attached to a common link.
  4974.  
  4975.     C.4    Virtual    link parameters
  4976.  
  4977.     Virtual    links are used to restore/increase connectivity    of the
  4978.     backbone.  Virtual links may be    configured between any pair of
  4979.     area border routers having interfaces to a common (non-backbone)
  4980.     area.  The virtual link    appears    as an unnumbered point-to-point
  4981.  
  4982.  
  4983.  
  4984. Coltun et al                               [Page 89]
  4985.  
  4986. Internet Draft             OSPF for IPv6           November 1996
  4987.  
  4988.  
  4989.     link in    the graph for the backbone.  The virtual link must be
  4990.     configured in both of the area border routers.
  4991.  
  4992.     A virtual link appears in router-LSAs (for the backbone) as if
  4993.     it were    a separate router interface to the backbone.  As such,
  4994.     it has most of the parameters associated with a    router interface
  4995.     (see Section C.3).  Virtual links do not have link-local
  4996.     addresses, but instead use one of the router's global-scope or
  4997.     site-local IPv6    addresses as the IP source in OSPF protocol
  4998.     packets    it sends along the virtual link.  Router Priority is not
  4999.     used on    virtual    links. Interface output    cost is    not configured
  5000.     on virtual links, but is dynamically set to be the cost    of the
  5001.     intra-area path    between    the two    endpoint routers.  The parameter
  5002.     RxmtInterval must be configured, and should be well over the
  5003.     expected round-trip delay between the two routers.  This may be
  5004.     hard to    estimate for a virtual link; it    is better to err on the
  5005.     side of    making it too large.
  5006.  
  5007.     A virtual link is defined by the following two configurable
  5008.     parameters: the    Router ID of the virtual link's    other endpoint,
  5009.     and the    (non-backbone) area through which the virtual link runs
  5010.     (referred to as    the virtual link's Transit area).  Virtual links
  5011.     cannot be configured through stub areas.
  5012.  
  5013.     C.5    NBMA network parameters
  5014.  
  5015.     OSPF treats an NBMA network much like it treats    a broadcast
  5016.     network.  Since    there may be many routers attached to the
  5017.     network, a Designated Router is    selected for the network.  This
  5018.     Designated Router then originates a network-LSA, which lists all
  5019.     routers    attached to the    NBMA network.
  5020.  
  5021.     However, due to    the lack of broadcast capabilities, it may be
  5022.     necessary to use configuration parameters in the Designated
  5023.     Router selection.  These parameters will only need to be
  5024.     configured in those routers that are themselves    eligible to
  5025.     become Designated Router (i.e.,    those router's whose Router
  5026.     Priority for the network is non-zero), and then    only if    no
  5027.     automatic procedure for    discovering neighbors exists:
  5028.  
  5029.  
  5030.     List of    all other attached routers
  5031.         The    list of    all other routers attached to the NBMA network.
  5032.         Each router    is configured with its Router ID and IPv6 link-
  5033.         local address on the network.  Also, for each router listed,
  5034.         that router's eligibility to become    Designated Router must
  5035.         be defined.     When an interface to a    NBMA network comes up,
  5036.         the    router sends Hello Packets only    to those neighbors
  5037.  
  5038.  
  5039.  
  5040. Coltun et al                               [Page 90]
  5041.  
  5042. Internet Draft             OSPF for IPv6           November 1996
  5043.  
  5044.  
  5045.         eligible to    become Designated Router, until    the identity of
  5046.         the    Designated Router is discovered.
  5047.  
  5048.     PollInterval
  5049.         If a neighboring router has    become inactive    (Hello Packets
  5050.         have not been seen for RouterDeadInterval seconds),    it may
  5051.         still be necessary to send Hello Packets to    the dead
  5052.         neighbor.  These Hello Packets will    be sent    at the reduced
  5053.         rate PollInterval, which should be much larger than
  5054.         HelloInterval.  Sample value for a PDN X.25    network: 2
  5055.         minutes.
  5056.  
  5057.     C.6    Point-to-MultiPoint network parameters
  5058.  
  5059.     On Point-to-MultiPoint networks, it may    be necessary to
  5060.     configure the set of neighbors that are    directly reachable over
  5061.     the Point-to-MultiPoint    network. Each neighbor is configured
  5062.     with its Router    ID and IPv6 link-local address on the network.
  5063.     Designated Routers are not elected on Point-to-MultiPoint
  5064.     networks, so the Designated Router eligibility of configured
  5065.     neighbors is undefined.
  5066.  
  5067.     C.7    Host route parameters
  5068.  
  5069.     Host routes are    advertised in intra-area-prefix-LSAs as    fully
  5070.     qualified IPv6 prefixes    (i.e., prefix length set equal to 128
  5071.     bits).    They indicate either router interfaces to point-to-point
  5072.     networks, looped router    interfaces, or IPv6 hosts that are
  5073.     directly connected to the router (e.g.,    via a PPP connection).
  5074.     For each host directly connected to the    router,    the following
  5075.     items must be configured:
  5076.  
  5077.  
  5078.     Host IPv6 address
  5079.         The    IPv6 address of    the host.
  5080.  
  5081.     Cost of    link to    host
  5082.         The    cost of    sending    a packet to the    host, in terms of the
  5083.         link state metric. However,    since the host probably    has only
  5084.         a single connection    to the internet, the actual configured
  5085.         cost(s) in many cases is unimportant (i.e.,    will have no
  5086.         effect on routing).
  5087.  
  5088.     Area ID
  5089.         The    OSPF area to which the host belongs.
  5090.  
  5091.  
  5092.  
  5093.  
  5094.  
  5095.  
  5096. Coltun et al                               [Page 91]
  5097.  
  5098. Internet Draft             OSPF for IPv6           November 1996
  5099.  
  5100.  
  5101. Security Considerations
  5102.  
  5103.     When running over IPv6, OSPF relies    on the IP Authentication Header
  5104.     (see [Ref19]) and the IP Encapsulating Security Payload (see
  5105.     [Ref20]) to    ensure integrity and authentication/confidentiality of
  5106.     routing exchanges.
  5107.  
  5108. Authors    Addresses
  5109.  
  5110.     Rob    Coltun
  5111.     FORE Systems
  5112.     Phone: (301) 571-2521
  5113.     Email: rcoltun@fore.com
  5114.  
  5115.     Dennis Ferguson
  5116.     Juniper Networks
  5117.     101    University Avenue, Suite 240
  5118.     Palo Alto, CA  94301
  5119.     Phone: (415) 614-4143
  5120.     Email: dennis@jnx.com
  5121.  
  5122.     John Moy
  5123.     Cascade Communications Corp.
  5124.     5 Carlisle Road
  5125.     Westford, MA 01886
  5126.     Phone: (508) 952-1367
  5127.     Fax:   (508) 392-9250
  5128.     Email: jmoy@casc.com
  5129.  
  5130.     This document expires in May 1997.
  5131.  
  5132.  
  5133.  
  5134.  
  5135.  
  5136.  
  5137.  
  5138.  
  5139.  
  5140.  
  5141.  
  5142.  
  5143.  
  5144.  
  5145.  
  5146.  
  5147.  
  5148.  
  5149.  
  5150.  
  5151.  
  5152. Coltun et al                               [Page 92]
  5153.  
  5154.