contrib/bind9/doc/rfc/rfc2374.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        R. Hinden
   8 Request for Comments: 2374                                       Nokia
   9 Obsoletes: 2073                                              M. O'Dell
  10 Category: Standards Track                                        UUNET
  11                                                             S. Deering
  12                                                                  Cisco
  13                                                              July 1998
  14
  15
  16            An IPv6 Aggregatable Global Unicast Address Format
  17
  18 Status of this Memo
  19
  20    This document specifies an Internet standards track protocol for the
  21    Internet community, and requests discussion and suggestions for
  22    improvements.  Please refer to the current edition of the "Internet
  23    Official Protocol Standards" (STD 1) for the standardization state
  24    and status of this protocol.  Distribution of this memo is unlimited.
  25
  26 Copyright Notice
  27
  28    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  29
  30 1.0 Introduction
  31
  32    This document defines an IPv6 aggregatable global unicast address
  33    format for use in the Internet.  The address format defined in this
  34    document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
  35    Addressing Architecture" [ARCH].  It is designed to facilitate
  36    scalable Internet routing.
  37
  38    This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
  39    Address Format".  RFC 2073 will become historic.  The Aggregatable
  40    Global Unicast Address Format is an improvement over RFC 2073 in a
  41    number of areas.  The major changes include removal of the registry
  42    bits because they are not needed for route aggregation, support of
  43    EUI-64 based interface identifiers, support of provider and exchange
  44    based aggregation, separation of public and site topology, and new
  45    aggregation based terminology.
  46
  47    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  48    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  49    document are to be interpreted as described in [RFC 2119].
  50
  51
  52
  53
  54
  55
  56
  57
  58 Hinden, et. al.             Standards Track                     [Page 1]
  59 \f
  60 RFC 2374           IPv6 Global Unicast Address Format          July 1998
  61
  62
  63 2.0 Overview of the IPv6 Address
  64
  65    IPv6 addresses are 128-bit identifiers for interfaces and sets of
  66    interfaces.  There are three types of addresses: Unicast, Anycast,
  67    and Multicast.  This document defines a specific type of Unicast
  68    address.
  69
  70    In this document, fields in addresses are given specific names, for
  71    example "subnet".  When this name is used with the term "ID" (for
  72    "identifier") after the name (e.g., "subnet ID"), it refers to the
  73    contents of the named field.  When it is used with the term "prefix"
  74    (e.g.  "subnet prefix") it refers to all of the addressing bits to
  75    the left of and including this field.
  76
  77    IPv6 unicast addresses are designed assuming that the Internet
  78    routing system makes forwarding decisions based on a "longest prefix
  79    match" algorithm on arbitrary bit boundaries and does not have any
  80    knowledge of the internal structure of IPv6 addresses.  The structure
  81    in IPv6 addresses is for assignment and allocation.  The only
  82    exception to this is the distinction made between unicast and
  83    multicast addresses.
  84
  85    The specific type of an IPv6 address is indicated by the leading bits
  86    in the address.  The variable-length field comprising these leading
  87    bits is called the Format Prefix (FP).
  88
  89    This document defines an address format for the 001 (binary) Format
  90    Prefix for Aggregatable Global Unicast addresses. The same address
  91    format could be used for other Format Prefixes, as long as these
  92    Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
  93    Format Prefix is defined here.
  94
  95 3.0 IPv6 Aggregatable Global Unicast Address Format
  96
  97    This document defines an address format for the IPv6 aggregatable
  98    global unicast address assignment.  The authors believe that this
  99    address format will be widely used for IPv6 nodes connected to the
 100    Internet.  This address format is designed to support both the
 101    current provider-based aggregation and a new type of exchange-based
 102    aggregation.  The combination will allow efficient routing
 103    aggregation for sites that connect directly to providers and for
 104    sites that connect to exchanges.  Sites will have the choice to
 105    connect to either type of aggregation entity.
 106
 107
 108
 109
 110
 111
 112
 113
 114 Hinden, et. al.             Standards Track                     [Page 2]
 115 \f
 116 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 117
 118
 119    While this address format is designed to support exchange-based
 120    aggregation (in addition to current provider-based aggregation) it is
 121    not dependent on exchanges for it's overall route aggregation
 122    properties.  It will provide efficient route aggregation with only
 123    provider-based aggregation.
 124
 125    Aggregatable addresses are organized into a three level hierarchy:
 126
 127       - Public Topology
 128       - Site Topology
 129       - Interface Identifier
 130
 131    Public topology is the collection of providers and exchanges who
 132    provide public Internet transit services.  Site topology is local to
 133    a specific site or organization which does not provide public transit
 134    service to nodes outside of the site.  Interface identifiers identify
 135    interfaces on links.
 136
 137         ______________                  ______________
 138     --+/              \+--------------+/              \+----------
 139       (       P1       )    +----+    (       P3       )  +----+
 140       +\______________/     |    |----+\______________/+--|    |--
 141       |                  +--| X1 |                       +| X2 |
 142       | ______________  /   |    |-+    ______________  / |    |--
 143       +/              \+    +-+--+  \  /              \+  +----+
 144       (       P2       )     / \     +(      P4        )
 145     --+\______________/     /   \      \______________/
 146            |               /     \           |      |
 147            |              /       |          |      |
 148            |             /        |          |      |
 149           _|_          _/_       _|_        _|_    _|_
 150          /   \        /   \     /   \      /   \  /   \
 151         ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
 152          \___/        \___/     \___/      \___/  \___/
 153                                   |          / \
 154                                  _|_       _/_  \   ___
 155                                 /   \     /   \  +-/   \
 156                                ( S.D )   ( S.E )  ( S.F )
 157                                 \___/     \___/    \___/
 158
 159    As shown in the figure above, the aggregatable address format is
 160    designed to support long-haul providers (shown as P1, P2, P3, and
 161    P4), exchanges (shown as X1 and X2), multiple levels of providers
 162    (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
 163    (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
 164    Organizations who connect to these exchanges will also subscribe
 165    (directly, indirectly via the exchange, etc.) for long-haul service
 166    from one or more long-haul providers.  Doing so, they will achieve
 167
 168
 169
 170 Hinden, et. al.             Standards Track                     [Page 3]
 171 \f
 172 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 173
 174
 175    addressing independence from long-haul transit providers.  They will
 176    be able to change long-haul providers without having to renumber
 177    their organization.  They can also be multihomed via the exchange to
 178    more than one long-haul provider without having to have address
 179    prefixes from each long-haul provider.  Note that the mechanisms used
 180    for this type of provider selection and portability are not discussed
 181    in the document.
 182
 183 3.1 Aggregatable Global Unicast Address Structure
 184
 185    The aggregatable global unicast address format is as follows:
 186
 187      | 3|  13 | 8 |   24   |   16   |          64 bits               |
 188      +--+-----+---+--------+--------+--------------------------------+
 189      |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
 190      |  | ID  |   |  ID    |  ID    |                                |
 191      +--+-----+---+--------+--------+--------------------------------+
 192
 193      <--Public Topology--->   Site
 194                            <-------->
 195                             Topology
 196                                      <------Interface Identifier----->
 197
 198    Where
 199
 200       FP           Format Prefix (001)
 201       TLA ID       Top-Level Aggregation Identifier
 202       RES          Reserved for future use
 203       NLA ID       Next-Level Aggregation Identifier
 204       SLA ID       Site-Level Aggregation Identifier
 205       INTERFACE ID Interface Identifier
 206
 207    The following sections specify each part of the IPv6 Aggregatable
 208    Global Unicast address format.
 209
 210 3.2 Top-Level Aggregation ID
 211
 212    Top-Level Aggregation Identifiers (TLA ID) are the top level in the
 213    routing hierarchy.  Default-free routers must have a routing table
 214    entry for every active TLA ID and will probably have additional
 215    entries providing routing information for the TLA ID in which they
 216    are located.  They may have additional entries in order to optimize
 217    routing for their specific topology, but the routing topology at all
 218    levels must be designed to minimize the number of additional entries
 219    fed into the default free routing tables.
 220
 221
 222
 223
 224
 225
 226 Hinden, et. al.             Standards Track                     [Page 4]
 227 \f
 228 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 229
 230
 231    This addressing format supports 8,192 (2^13) TLA ID's.  Additional
 232    TLA ID's may be added by either growing the TLA field to the right
 233    into the reserved field or by using this format for additional format
 234    prefixes.
 235
 236    The issues relating to TLA ID assignment are beyond the scope of this
 237    document.  They will be described in a document under preparation.
 238
 239 3.3 Reserved
 240
 241    The Reserved field is reserved for future use and must be set to
 242    zero.
 243
 244    The Reserved field allows for future growth of the TLA and NLA fields
 245    as appropriate.  See section 4.0 for a discussion.
 246
 247 3.4 Next-Level Aggregation Identifier
 248
 249    Next-Level Aggregation Identifier's are used by organizations
 250    assigned a TLA ID to create an addressing hierarchy and to identify
 251    sites.  The organization can assign the top part of the NLA ID in a
 252    manner to create an addressing hierarchy appropriate to its network.
 253    It can use the remainder of the bits in the field to identify sites
 254    it wishes to serve.  This is shown as follows:
 255
 256       |  n  |      24-n bits     |   16   |    64 bits      |
 257       +-----+--------------------+--------+-----------------+
 258       |NLA1 |      Site ID       | SLA ID | Interface ID    |
 259       +-----+--------------------+--------+-----------------+
 260
 261    Each organization assigned a TLA ID receives 24 bits of NLA ID space.
 262    This NLA ID space allows each organization to provide service to
 263    approximately as many organizations as the current IPv4 Internet can
 264    support total networks.
 265
 266    Organizations assigned TLA ID's may also support NLA ID's in their
 267    own Site ID space.  This allows the organization assigned a TLA ID to
 268    provide service to organizations providing public transit service and
 269    to organizations who do not provide public transit service.  These
 270    organizations receiving an NLA ID may also choose to use their Site
 271    ID space to support other NLA ID's.  This is shown as follows:
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Hinden, et. al.             Standards Track                     [Page 5]
 283 \f
 284 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 285
 286
 287    |  n  |      24-n bits     |   16   |    64 bits      |
 288    +-----+--------------------+--------+-----------------+
 289    |NLA1 |      Site ID       | SLA ID | Interface ID    |
 290    +-----+--------------------+--------+-----------------+
 291
 292          |  m  |    24-n-m    |   16   |    64 bits      |
 293          +-----+--------------+--------+-----------------+
 294          |NLA2 |   Site ID    | SLA ID | Interface ID    |
 295          +-----+--------------+--------+-----------------+
 296
 297                |  o  |24-n-m-o|   16   |    64 bits      |
 298                +-----+--------+--------+-----------------+
 299                |NLA3 | Site ID| SLA ID | Interface ID    |
 300                +-----+--------+--------+-----------------+
 301
 302    The design of the bit layout of the NLA ID space for a specific TLA
 303    ID is left to the organization responsible for that TLA ID.  Likewise
 304    the design of the bit layout of the next level NLA ID is the
 305    responsibility of the previous level NLA ID.  It is recommended that
 306    organizations assigning NLA address space use "slow start" allocation
 307    procedures similar to [RFC2050].
 308
 309    The design of an NLA ID allocation plan is a tradeoff between routing
 310    aggregation efficiency and flexibility.  Creating hierarchies allows
 311    for greater amount of aggregation and results in smaller routing
 312    tables.  Flat NLA ID assignment provides for easier allocation and
 313    attachment flexibility, but results in larger routing tables.
 314
 315 3.5 Site-Level Aggregation Identifier
 316
 317    The SLA ID field is used by an individual organization to create its
 318    own local addressing hierarchy and to identify subnets.  This is
 319    analogous to subnets in IPv4 except that each organization has a much
 320    greater number of subnets.  The 16 bit SLA ID field support 65,535
 321    individual subnets.
 322
 323    Organizations may choose to either route their SLA ID "flat" (e.g.,
 324    not create any logical relationship between the SLA identifiers that
 325    results in larger routing tables), or to create a two or more level
 326    hierarchy (that results in smaller routing tables) in the SLA ID
 327    field.  The latter is shown as follows:
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Hinden, et. al.             Standards Track                     [Page 6]
 339 \f
 340 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 341
 342
 343    |  n  |   16-n     |              64 bits                |
 344    +-----+------------+-------------------------------------+
 345    |SLA1 |   Subnet   |            Interface ID             |
 346    +-----+------------+-------------------------------------+
 347
 348          | m  |16-n-m |              64 bits                |
 349          +----+-------+-------------------------------------+
 350          |SLA2|Subnet |            Interface ID             |
 351          +----+-------+-------------------------------------+
 352
 353    The approach chosen for structuring an SLA ID field is the
 354    responsibility of the individual organization.
 355
 356    The number of subnets supported in this address format should be
 357    sufficient for all but the largest of organizations.  Organizations
 358    which need additional subnets can arrange with the organization they
 359    are obtaining Internet service from to obtain additional site
 360    identifiers and use this to create additional subnets.
 361
 362 3.6 Interface ID
 363
 364    Interface identifiers are used to identify interfaces on a link.
 365    They are required to be unique on that link.  They may also be unique
 366    over a broader scope.  In many cases an interfaces identifier will be
 367    the same or be based on the interface's link-layer address.
 368    Interface IDs used in the aggregatable global unicast address format
 369    are required to be 64 bits long and to be constructed in IEEE EUI-64
 370    format [EUI-64].  These identifiers may have global scope when a
 371    global token (e.g., IEEE 48bit MAC) is available or may have local
 372    scope where a global token is not available (e.g., serial links,
 373    tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
 374    EUI-64 terminology) in the EUI-64 identifier must be set correctly,
 375    as defined in [ARCH], to indicate global or local scope.
 376
 377    The procedures for creating EUI-64 based Interface Identifiers is
 378    defined in [ARCH].  The details on forming interface identifiers is
 379    defined in the appropriate "IPv6 over <link>" specification such as
 380    "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
 381
 382 4.0 Technical Motivation
 383
 384    The design choices for the size of the fields in the aggregatable
 385    address format were based on the need to meet a number of technical
 386    requirements.  These are described in the following paragraphs.
 387
 388    The size of the Top-Level Aggregation Identifier is 13 bits.  This
 389    allows for 8,192 TLA ID's.  This size was chosen to insure that the
 390    default-free routing table in top level routers in the Internet is
 391
 392
 393
 394 Hinden, et. al.             Standards Track                     [Page 7]
 395 \f
 396 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 397
 398
 399    kept within the limits, with a reasonable margin, of the current
 400    routing technology.  The margin is important because default-free
 401    routers will also carry a significant number of longer (i.e., more-
 402    specific) prefixes for optimizing paths internal to a TLA and between
 403    TLAs.
 404
 405    The important issue is not only the size of the default-free routing
 406    table, but the complexity of the topology that determines the number
 407    of copies of the default-free routes that a router must examine while
 408    computing a forwarding table.  Current practice with IPv4 it is
 409    common to see a prefix announced fifteen times via different paths.
 410
 411    The complexity of Internet topology is very likely to increase in the
 412    future.  It is important that IPv6 default-free routing support
 413    additional complexity as well as a considerably larger internet.
 414
 415    It should be noted for comparison that at the time of this writing
 416    (spring, 1998) the IPv4 default-free routing table contains
 417    approximately 50,000 prefixes.  While this shows that it is possible
 418    to support more routes than 8,192 it is matter of debate if the
 419    number of prefixes supported today in IPv4 is already too high for
 420    current routing technology.  There are serious issues of route
 421    stability as well as cases of providers not supporting all top level
 422    prefixes.  The technical requirement was to pick a TLA ID size that
 423    was below, with a reasonable margin, what was being done with IPv4.
 424
 425    The choice of 13 bits for the TLA field was an engineering
 426    compromise.  Fewer bits would have been too small by not supporting
 427    enough top level organizations.  More bits would have exceeded what
 428    can be reasonably accommodated, with a reasonable margin, with
 429    current routing technology in order to deal with the issues described
 430    in the previous paragraphs.
 431
 432    If in the future, routing technology improves to support a larger
 433    number of top level routes in the default-free routing tables there
 434    are two choices on how to increase the number TLA identifiers.  The
 435    first is to expand the TLA ID field into the reserved field.  This
 436    would increase the number of TLA ID's to approximately 2 million.
 437    The second approach is to allocate another format prefix (FP) for use
 438    with this address format.  Either or a combination of these
 439    approaches allows the number of TLA ID's to increase significantly.
 440
 441    The size of the Reserved field is 8 bits.  This size was chosen to
 442    allow significant growth of either the TLA ID and/or the NLA ID
 443    fields.
 444
 445    The size of the Next-Level Aggregation Identifier field is 24 bits.
 446
 447
 448
 449
 450 Hinden, et. al.             Standards Track                     [Page 8]
 451 \f
 452 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 453
 454
 455    This allows for approximately sixteen million NLA ID's if used in a
 456    flat manner.  Used hierarchically it allows for a complexity roughly
 457    equivalent to the IPv4 address space (assuming an average network
 458    size of 254 interfaces).  If in the future additional room for
 459    complexity is needed in the NLA ID, this may be accommodated by
 460    extending the NLA ID into the Reserved field.
 461
 462    The size of the Site-Level Aggregation Identifier field is 16 bits.
 463    This supports 65,535 individual subnets per site.  The design goal
 464    for the size of this field was to be sufficient for all but the
 465    largest of organizations.  Organizations which need additional
 466    subnets can arrange with the organization they are obtaining Internet
 467    service from to obtain additional site identifiers and use this to
 468    create additional subnets.
 469
 470    The Site-Level Aggregation Identifier field was given a fixed size in
 471    order to force the length of all prefixes identifying a particular
 472    site to be the same length (i.e., 48 bits).  This facilitates
 473    movement of sites in the topology (e.g., changing service providers
 474    and multi-homing to multiple service providers).
 475
 476    The Interface ID Interface Identifier field is 64 bits.  This size
 477    was chosen to meet the requirement specified in [ARCH] to support
 478    EUI-64 based Interface Identifiers.
 479
 480 5.0 Acknowledgments
 481
 482    The authors would like to express our thanks to Thomas Narten, Bob
 483    Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
 484    Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
 485    for their review and constructive comments.
 486
 487 6.0 References
 488
 489    [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
 490              RFC 1881, December 1995.
 491
 492    [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
 493              RFC 2373, July 1998.
 494
 495    [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
 496              1995.
 497
 498    [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
 499              Autoconfiguration", RFC 1971, August 1996.
 500
 501    [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
 502              Networks", Work in Progress.
 503
 504
 505
 506 Hinden, et. al.             Standards Track                     [Page 9]
 507 \f
 508 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 509
 510
 511    [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
 512              Registration Authority",
 513              http://standards.ieee.org/db/oui/tutorials/EUI64.html,
 514              March 1997.
 515
 516    [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
 517              Networks", Work in Progress.
 518
 519    [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
 520              (IPv6) Specification", RFC 1883, December 1995.
 521
 522    [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
 523              and J. Postel, "Internet Registry IP Allocation
 524              Guidelines", BCP 12, RFC 1466, November 1996.
 525
 526    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 527              Requirement Levels", BCP 14, RFC 2119, March 1997.
 528
 529 7.0 Security Considerations
 530
 531    IPv6 addressing documents do not have any direct impact on Internet
 532    infrastructure security.  Authentication of IPv6 packets is defined
 533    in [AUTH].
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Hinden, et. al.             Standards Track                    [Page 10]
 563 \f
 564 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 565
 566
 567 8.0 Authors' Addresses
 568
 569    Robert M. Hinden
 570    Nokia
 571    232 Java Drive
 572    Sunnyvale, CA 94089
 573    USA
 574
 575    Phone: 1 408 990-2004
 576    EMail: hinden@iprg.nokia.com
 577
 578
 579    Mike O'Dell
 580    UUNET Technologies, Inc.
 581    3060 Williams Drive
 582    Fairfax, VA 22030
 583    USA
 584
 585    Phone: 1 703 206-5890
 586    EMail: mo@uunet.uu.net
 587
 588
 589    Stephen E. Deering
 590    Cisco Systems, Inc.
 591    170 West Tasman Drive
 592    San Jose, CA 95134-1706
 593    USA
 594
 595    Phone: 1 408 527-8213
 596    EMail: deering@cisco.com
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Hinden, et. al.             Standards Track                    [Page 11]
 619 \f
 620 RFC 2374           IPv6 Global Unicast Address Format          July 1998
 621
 622
 623 9.0  Full Copyright Statement
 624
 625    Copyright (C) The Internet Society (1998).  All Rights Reserved.
 626
 627    This document and translations of it may be copied and furnished to
 628    others, and derivative works that comment on or otherwise explain it
 629    or assist in its implementation may be prepared, copied, published
 630    and distributed, in whole or in part, without restriction of any
 631    kind, provided that the above copyright notice and this paragraph are
 632    included on all such copies and derivative works.  However, this
 633    document itself may not be modified in any way, such as by removing
 634    the copyright notice or references to the Internet Society or other
 635    Internet organizations, except as needed for the purpose of
 636    developing Internet standards in which case the procedures for
 637    copyrights defined in the Internet Standards process must be
 638    followed, or as required to translate it into languages other than
 639    English.
 640
 641    The limited permissions granted above are perpetual and will not be
 642    revoked by the Internet Society or its successors or assigns.
 643
 644    This document and the information contained herein is provided on an
 645    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 646    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 647    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 648    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 649    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Hinden, et. al.             Standards Track                    [Page 12]
 675 \f