doc/rfc/rfc3162.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           B. Aboba
   8 Request for Comments: 3162                                     Microsoft
   9 Category: Standards Track                                        G. Zorn
  10                                                            Cisco Systems
  11                                                                D. Mitton
  12                                                    Circular Logic UnLtd.
  13                                                              August 2001
  14
  15
  16                             RADIUS and IPv6
  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 (2001).  All Rights Reserved.
  29
  30 Abstract
  31
  32    This document specifies the operation of RADIUS (Remote
  33    Authentication Dial In User Service) when run over IPv6 as well as
  34    the RADIUS attributes used to support IPv6 network access.
  35
  36 1.  Introduction
  37
  38    This document specifies the operation of RADIUS [4]-[8] over IPv6
  39    [13] as well as the RADIUS attributes used to support IPv6 network
  40    access.
  41
  42    Note that a NAS sending a RADIUS Access-Request may not know a-priori
  43    whether the host will be using IPv4, IPv6, or both.  For example,
  44    within PPP, IPv6CP [11] occurs after LCP, so that address assignment
  45    will not occur until after RADIUS authentication and authorization
  46    has completed.
  47
  48    Therefore it is presumed that the IPv6 attributes described in this
  49    document MAY be sent along with IPv4-related attributes within the
  50    same RADIUS message and that the NAS will decide which attributes to
  51    use.  The NAS SHOULD only allocate addresses and prefixes that the
  52    client can actually use, however.  For example, there is no need for
  53
  54
  55
  56
  57
  58 Aboba, et al.               Standards Track                     [Page 1]
  59 \f
  60 RFC 3162                    RADIUS and IPv6                  August 2001
  61
  62
  63    the NAS to reserve use of an IPv4 address for a host that only
  64    supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does
  65    not require allocation of an IPv6 prefix.
  66
  67    The NAS can provide IPv6 access natively, or alternatively, via other
  68    methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14].  The
  69    choice of method for providing IPv6 access has no effect on RADIUS
  70    usage per se, although if it is desired that an IPv6 within IPv4
  71    tunnel be opened to a particular location, then tunnel attributes
  72    should be utilized, as described in [6], [7].
  73
  74 1.1.  Requirements language
  75
  76    In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
  77    "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
  78    described in [1].
  79
  80 2.  Attributes
  81
  82 2.1.  NAS-IPv6-Address
  83
  84    Description
  85
  86       This Attribute indicates the identifying IPv6 Address of the NAS
  87       which is requesting authentication of the user, and SHOULD be
  88       unique to the NAS within the scope of the RADIUS server.  NAS-
  89       IPv6-Address is only used in Access-Request packets.  NAS-IPv6-
  90       Address and/or NAS-IP-Address MAY be present in an Access-Request
  91       packet; however, if neither attribute is present then NAS-
  92       Identifier MUST be present.
  93
  94    A summary of the NAS-IPv6-Address Attribute format is shown below.
  95    The fields are transmitted from left to right.
  96
  97     0                   1                   2                   3
  98     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
  99    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 100    |     Type      |    Length     |             Address
 101    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 102                                 Address
 103    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 104                                 Address
 105    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 106                                 Address
 107    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 108                Address             |
 109    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 110
 111
 112
 113
 114 Aboba, et al.               Standards Track                     [Page 2]
 115 \f
 116 RFC 3162                    RADIUS and IPv6                  August 2001
 117
 118
 119    Type
 120
 121       95 for NAS-IPv6-Address
 122
 123    Length
 124
 125       18
 126
 127    Address
 128
 129       The Address field is 16 octets.
 130
 131 3.2.  Framed-Interface-Id
 132
 133    Description
 134
 135       This Attribute indicates the IPv6 interface identifier to be
 136       configured for the user.  It MAY be used in Access-Accept packets.
 137       If the Interface-Identifier IPv6CP option [11] has been
 138       successfully negotiated, this Attribute MUST be included in an
 139       Access-Request packet as a hint by the NAS to the server that it
 140       would prefer that value.  It is recommended, but not required,
 141       that the server honor the hint.
 142
 143    A summary of the Framed-Interface-Id Attribute format is shown below.
 144    The fields are transmitted from left to right.
 145
 146     0                   1                   2                   3
 147     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
 148    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 149    |     Type      |    Length     |             Interface-Id
 150    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 151                                 Interface-Id
 152    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 153           Interface-Id             |
 154    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 155
 156    Type
 157
 158       96 for Framed-Interface-Id
 159
 160    Length
 161
 162       10
 163
 164    Interface-Id
 165
 166       The Interface-Id field is 8 octets.
 167
 168
 169
 170 Aboba, et al.               Standards Track                     [Page 3]
 171 \f
 172 RFC 3162                    RADIUS and IPv6                  August 2001
 173
 174
 175 2.3.  Framed-IPv6-Prefix
 176
 177    Description
 178
 179       This Attribute indicates an IPv6 prefix (and corresponding route)
 180       to be configured for the user.  It MAY be used in Access-Accept
 181       packets, and can appear multiple times.  It MAY be used in an
 182       Access-Request packet as a hint by the NAS to the server that it
 183       would prefer these prefix(es), but the server is not required to
 184       honor the hint.  Since it is assumed that the NAS will plumb a
 185       route corresponding to the prefix, it is not necessary for the
 186       server to also send a Framed-IPv6-Route attribute for the same
 187       prefix.
 188
 189    A summary of the Framed-IPv6-Prefix Attribute format is shown below.
 190    The fields are transmitted from left to right.
 191
 192     0                   1                   2                   3
 193     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
 194    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 195    |     Type      |    Length     |  Reserved     | Prefix-Length |
 196    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 197                                 Prefix
 198    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 199                                 Prefix
 200    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 201                                 Prefix
 202    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 203                                 Prefix                             |
 204    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 205
 206    Type
 207
 208       97 for Framed-IPv6-Prefix
 209
 210    Length
 211
 212       At least 4 and no larger than 20.
 213
 214    Reserved
 215
 216       This field, which is reserved and MUST be present, is always set
 217       to zero.
 218
 219    Prefix-Length
 220
 221       The length of the prefix, in bits.  At least 0 and no larger than
 222       128.
 223
 224
 225
 226 Aboba, et al.               Standards Track                     [Page 4]
 227 \f
 228 RFC 3162                    RADIUS and IPv6                  August 2001
 229
 230
 231    Prefix
 232
 233       The Prefix field is up to 16 octets in length.  Bits outside of
 234       the Prefix-Length, if included, must be zero.
 235
 236 2.4.  Login-IPv6-Host
 237
 238    Description
 239
 240       This Attribute indicates the system with which to connect the
 241       user, when the Login-Service Attribute is included.  It MAY be
 242       used in Access-Accept packets.  It MAY be used in an Access-
 243       Request packet as a hint to the server that the NAS would prefer
 244       to use that host, but the server is not required to honor the
 245       hint.
 246
 247    A summary of the Login-IPv6-Host Attribute format is shown below.
 248    The fields are transmitted from left to right.
 249
 250     0                   1                   2                   3
 251     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
 252    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 253    |     Type      |    Length     |             Address
 254    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 255                                 Address
 256    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 257                                 Address
 258    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 259                                 Address
 260    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 261             Address                |
 262    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 263
 264    Type
 265
 266       98 for Login-IPv6-Host
 267
 268    Length
 269
 270       18
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Aboba, et al.               Standards Track                     [Page 5]
 283 \f
 284 RFC 3162                    RADIUS and IPv6                  August 2001
 285
 286
 287    Address
 288
 289       The Address field is 16 octets in length.  The value
 290       0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD
 291       allow the user to select an address or name to be connected to.
 292       The value 0 indicates that the NAS SHOULD select a host to connect
 293       the user to.  Other values indicate the address the NAS SHOULD
 294       connect the user to.
 295
 296 2.5.  Framed-IPv6-Route
 297
 298    Description
 299
 300       This Attribute provides routing information to be configured for
 301       the user on the NAS.  It is used in the Access-Accept packet and
 302       can appear multiple times.
 303
 304    A summary of the Framed-IPv6-Route Attribute format is shown below.
 305    The fields are transmitted from left to right.
 306
 307     0                   1                   2
 308     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 309    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 310    |     Type      |    Length     |  Text ...
 311    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
 312
 313    Type
 314
 315       99 for Framed-IPv6-Route
 316
 317    Length
 318
 319       >=3
 320
 321    Text
 322
 323       The Text field is one or more octets, and its contents are
 324       implementation dependent.  The field is not NUL (hex 00)
 325       terminated.  It is intended to be human readable and MUST NOT
 326       affect operation of the protocol.
 327
 328       For IPv6 routes, it SHOULD contain a destination prefix optionally
 329       followed by a slash and a decimal length specifier stating how
 330       many high order bits of the prefix to use.  That is followed by a
 331       space, a gateway address, a space, and one or more metrics
 332       (encoded in decimal) separated by spaces.  Prefixes and addresses
 333       are formatted as described in [16].  For example,
 334       "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
 335
 336
 337
 338 Aboba, et al.               Standards Track                     [Page 6]
 339 \f
 340 RFC 3162                    RADIUS and IPv6                  August 2001
 341
 342
 343       Whenever the gateway address is the IPv6 unspecified address the
 344       IP address of the user SHOULD be used as the gateway address.  The
 345       unspecified address can be expressed in any of the acceptable
 346       formats described in [16].  For example, "2000:0:0:106::/64 :: 1".
 347
 348 2.6.  Framed-IPv6-Pool
 349
 350    Description
 351
 352       This Attribute contains the name of an assigned pool that SHOULD
 353       be used to assign an IPv6 prefix for the user.  If a NAS does not
 354       support multiple prefix pools, the NAS MUST ignore this Attribute.
 355
 356    A summary of the Framed-IPv6-Pool Attribute format is shown below.
 357    The fields are transmitted from left to right.
 358
 359     0                   1                   2
 360     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 361    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 362    |     Type      |    Length     |     String...
 363    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 364
 365    Type
 366
 367       100 for Framed-IPv6-Pool
 368
 369    Length
 370
 371       >= 3
 372
 373    String
 374
 375       The string field contains the name of an assigned IPv6 prefix pool
 376       configured on the NAS.  The field is not NUL (hex 00) terminated.
 377
 378 3.  Table of Attributes
 379
 380    The following table provides a guide to which attributes may be found
 381    in which kinds of packets, and in what quantity.
 382
 383    Request Accept Reject Challenge Accounting  #  Attribute
 384                                    Request
 385    0-1     0      0      0         0-1        95  NAS-IPv6-Address
 386    0-1     0-1    0      0         0-1        96  Framed-Interface-Id
 387    0+      0+     0      0         0+         97  Framed-IPv6-Prefix
 388    0+      0+     0      0         0+         98  Login-IPv6-Host
 389    0       0+     0      0         0+         99  Framed-IPv6-Route
 390    0       0-1    0      0         0-1       100  Framed-IPv6-Pool
 391
 392
 393
 394 Aboba, et al.               Standards Track                     [Page 7]
 395 \f
 396 RFC 3162                    RADIUS and IPv6                  August 2001
 397
 398
 399 4.  References
 400
 401    [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
 402          Levels", BCP 14, RFC 2119, March, 1997.
 403
 404    [2]   Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
 405          10646", RFC 2044, October 1996.
 406
 407    [3]   Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
 408          Implementation in Roaming", RFC 2607, June 1999.
 409
 410    [4]   Rigney, C., Rubens, A., Simpson, W. and S. Willens,  "Remote
 411          Authentication Dial In User Service (RADIUS)", RFC 2865, June
 412          2000.
 413
 414    [5]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 415
 416    [6]   Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
 417          Modifications for Tunnel Protocol Support", RFC 2867, June
 418          2000.
 419
 420    [7]   Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
 421          and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
 422          RFC 2868, June 2000.
 423
 424    [8]   Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
 425          RFC 2869, June 2000.
 426
 427    [9]   Kent S. and R. Atkinson, "Security Architecture for the
 428          Internet Protocol", RFC 2401, November 1998.
 429
 430    [10]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
 431          Considerations Section in RFCs", BCP 26, RFC 2434, October
 432          1998.
 433
 434    [11]  Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
 435          December 1998.
 436
 437    [12]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
 438          IPv4 Clouds", RFC 3056, February 2001.
 439
 440    [13]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
 441          Specification", RFC 2460, December 1998.
 442
 443    [14]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
 444          Domains without Explicit Tunnels", RFC 2529, March 1999.
 445
 446
 447
 448
 449
 450 Aboba, et al.               Standards Track                     [Page 8]
 451 \f
 452 RFC 3162                    RADIUS and IPv6                  August 2001
 453
 454
 455    [15]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
 456          Hosts and Routers", RFC 2893, August 2000.
 457
 458    [16]  Hinden, R. and S. Deering, "IP Version 6 Addressing
 459          Architecture", RFC 2373, July 1998.
 460
 461 5.  Security Considerations
 462
 463    This document describes the use of RADIUS for the purposes of
 464    authentication, authorization and accounting in IPv6-enabled
 465    networks.  In such networks, the RADIUS protocol may run either over
 466    IPv4 or over IPv6.  Known security vulnerabilities of the RADIUS
 467    protocol are described in [3], [4] and [8].
 468
 469    Since IPSEC [9] is mandatory to implement for IPv6, it is expected
 470    that running RADIUS implementations supporting IPv6 will typically
 471    run over IPSEC.  Where RADIUS is run over IPSEC and where
 472    certificates are used for authentication, it may be desirable to
 473    avoid management of RADIUS shared secrets, so as to leverage the
 474    improved scalability of public key infrastructure.
 475
 476    Within RADIUS, a shared secret is used for hiding of attributes such
 477    as User-Password [4] and Tunnel-Password [7].  In addition, the
 478    shared secret is used in computation of the Response Authenticator
 479    [4], as well as the Message-Authenticator attribute [8].  Therefore,
 480    in RADIUS a shared secret is used to provide confidentiality as well
 481    as integrity protection and authentication.  As a result, only use of
 482    IPSEC ESP with a non-null transform can provide security services
 483    sufficient to substitute for RADIUS application-layer security.
 484    Therefore, where IPSEC AH or ESP null is used, it will typically
 485    still be necessary to configure a RADIUS shared secret.
 486
 487    However, where RADIUS is run over IPSEC ESP with a non-null
 488    transform, the secret shared between the NAS and the RADIUS server
 489    MAY NOT be configured.  In this case, a shared secret of zero length
 490    MUST be assumed.
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Aboba, et al.               Standards Track                     [Page 9]
 507 \f
 508 RFC 3162                    RADIUS and IPv6                  August 2001
 509
 510
 511 6.  IANA Considerations
 512
 513    This document requires the assignment of six new RADIUS attribute
 514    numbers for the following attributes:
 515
 516       NAS-IPv6-Address
 517       Framed-Interface-Id
 518       Framed-IPv6-Prefix
 519       Login-IPv6-Host
 520       Framed-IPv6-Route
 521       Framed-IPv6-Pool
 522
 523    See section 3 for the registered list of numbers.
 524
 525 7.  Acknowledgments
 526
 527    The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ
 528    Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent
 529    for contributions to this document.
 530
 531
 532
 533
 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 Aboba, et al.               Standards Track                    [Page 10]
 563 \f
 564 RFC 3162                    RADIUS and IPv6                  August 2001
 565
 566
 567 8.  Authors' Addresses
 568
 569    Bernard Aboba
 570    Microsoft Corporation
 571    One Microsoft Way
 572    Redmond, WA 98052
 573
 574    Phone: +1 425 936 6605
 575    Fax:   +1 425 936 7329
 576    EMail: bernarda@microsoft.com
 577
 578
 579    Glen Zorn
 580    Cisco Systems, Inc.
 581    500 108th Avenue N.E., Suite 500
 582    Bellevue, WA 98004
 583
 584    Phone: +1 425 471 4861
 585    EMail: gwz@cisco.com
 586
 587
 588    Dave Mitton
 589    Circular Logic UnLtd.
 590    733 Turnpike Street #154
 591    North Andover, MA 01845
 592
 593    Phone: 978 683-1814
 594    Email: david@mitton.com
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Aboba, et al.               Standards Track                    [Page 11]
 619 \f
 620 RFC 3162                    RADIUS and IPv6                  August 2001
 621
 622
 623 Full Copyright Statement
 624
 625    Copyright (C) The Internet Society (2001).  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 Acknowledgement
 652
 653    Funding for the RFC Editor function is currently provided by the
 654    Internet Society.
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Aboba, et al.               Standards Track                    [Page 12]
 675 \f