home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2492.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  21.4 KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Armitage
  8. Request for Comments: 2492                          Lucent Technologies
  9. Category: Standards Track                                   P. Schulter
  10.                                                BrightTiger Technologies
  11.                                                                 M. Jork
  12.                                                  Digital Equipment GmbH
  13.                                                            January 1999
  14.  
  15.                          IPv6 over ATM Networks
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Copyright Notice
  26.  
  27.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  28.  
  29. Abstract
  30.  
  31.    This document is a companion to the ION working group's architecture
  32.    document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".
  33.    It provides specific details on how to apply the IPv6 over NBMA
  34.    architecture to ATM networks. This architecture allows conventional
  35.    host-side operation of the IPv6 Neighbor Discovery protocol, while
  36.    also supporting the establishment of 'shortcut' ATM forwarding paths
  37.    (when using SVCs).  Operation over administratively configured Point
  38.    to Point PVCs is also supported.
  39.  
  40. 1. Introduction.
  41.  
  42.    This document is an ATM-specific companion document to the ION
  43.    working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
  44.    networks" specification [1].  Terminology and architectural
  45.    descriptions will not be repeated here.
  46.  
  47.    The use of ATM to provide point to point PVC service, or flexible
  48.    point to point and point to multipoint SVC service, is covered by
  49.    this document.
  50.  
  51.    A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
  52.    operation. An IPv6/ATM driver that supports the full SVC mode SHALL
  53.    also support PVC mode of operation.
  54.  
  55.  
  56.  
  57.  
  58. G. Armitage, et. al.        Standards Track                     [Page 1]
  59.  
  60. RFC 2492                 IPv6 over ATM Networks             January 1999
  61.  
  62.  
  63. 2. Specification Terminology
  64.  
  65.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  66.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  67.    document are to be interpreted as described in RFC 2119 [16].
  68.  
  69. 3. PVC Environments
  70.  
  71.    When the ATM network is used in PVC mode, each PVC will connect
  72.    exactly two nodes and the use of Neighbor Discovery and other IPv6
  73.    features is limited.  IPv6/ATM interfaces have only one neighbor on
  74.    each Link. The MARS and NHRP protocols are NOT necessary, since
  75.    multicast and broadcast operations collapse down to an ATM level
  76.    unicast operation. Dynamically discovered shortcuts are not
  77.    supported.
  78.  
  79.    The actual details of encapsulations, MTU, and link token generation
  80.    are provided in the following sections.
  81.  
  82.    This use of PVC links does not mandate, nor does it prohibit the use
  83.    of extensions to the Neighbor Discovery protocol which may be
  84.    developed for either general use of for use in PVC connections (for
  85.    example, Inverse Neighbor Discovery).
  86.  
  87.    Since ATM PVC links do not use link-layer addresses, the link-layer
  88.    address options SHOULD not be included in any ND message [11].  If a
  89.    link-layer address option is present in an ND message, then the
  90.    option SHOULD be ignored.
  91.  
  92.    A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
  93.    operation.  PVC only implementations are not required to support any
  94.    SVC mode of operation.
  95.  
  96. 3.1 Default Packet Encapsulation
  97.  
  98.    Following the model in RFC 1483 [2], AAL5 SHALL be the default
  99.    Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be
  100.    default encapsulation used by unicast and multicast packets across
  101.    pt-pt PVC links. As defined in [1], the default IPv6 packet
  102.    encapsulation SHALL be:
  103.  
  104.          [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
  105.              (LLC)       (OUI)     (PID)
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. G. Armitage, et. al.        Standards Track                     [Page 2]
  115.  
  116. RFC 2492                 IPv6 over ATM Networks             January 1999
  117.  
  118.  
  119. 3.2 Optional null encapsulation
  120.  
  121.    IPv6/ATM drivers MAY also support null encapsulation as a
  122.    configurable option. When null encapsulation is enabled, the IPv6
  123.    packet is passed directly to the AAL5 layer. Both ends of the PVC
  124.    MUST be configured to use null encapsulation. The PVC will not be
  125.    available for use by protocols other than IPv6.
  126.  
  127. 3.3 PPP encapsulation
  128.  
  129.    The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not
  130.    covered by this specification.
  131.  
  132. 3.4 MTU For PVC Environments
  133.  
  134.    The default IP MTU size for PVC links is 9180 bytes as specified in
  135.    [7].  Other IP MTU values MAY be used.
  136.  
  137. 3.5 Interface Token Formats in PVC Environments
  138.  
  139.    When the ATM network is used in PVC mode interface tokens SHALL be
  140.    generated using one of the methods described in section 5. Interface
  141.    tokens need only be unique between the two nodes on the PVC link.
  142.  
  143. 4 SVC environments
  144.  
  145. 4.1 SVC Specific Code Points
  146.  
  147. 4.1.1 ATM Adaptation Layer encapsulation for SVC environments
  148.  
  149.    Following the model in RFC 1483 [2], AAL5 SHALL be the default
  150.    Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the
  151.    default encapsulation used by unicast and multicast packets across
  152.    SVC links.
  153.  
  154. 4.1.2 Unicast Packet Encapsulation
  155.  
  156.    As defined in [1], the default IPv6 unicast packet encapsulation
  157.    SHALL be:
  158.  
  159.          [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
  160.              (LLC)       (OUI)     (PID)
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. G. Armitage, et. al.        Standards Track                     [Page 3]
  171.  
  172. RFC 2492                 IPv6 over ATM Networks             January 1999
  173.  
  174.  
  175. 4.1.3 Multicast packet encapsulation
  176.  
  177.    As defined in [1], the default IPv6 multicast packet encapsulation
  178.    SHALL be:
  179.  
  180.          [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6
  181.          packet]
  182.              (LLC)       (OUI)     (PID)    (mars encaps)
  183.  
  184.          The IPv6/ATM driver's Cluster Member ID SHALL be copied into
  185.          the 2 octet pkt$cmi field prior to transmission.
  186.  
  187. 4.1.4 Optional null encapsulation
  188.  
  189.    IPv6/ATM drivers MAY also support null encapsulation as a
  190.    configurable option. Null encapsulation SHALL only be used for
  191.    passing IPv6 packets from one IPv6/ATM driver to another. Null
  192.    encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM
  193.    driver and its local MARS.
  194.  
  195.    If null encapsulation is enabled, the IPv6 packet is passed directly
  196.    to the AAL5 layer. Both ends of the SVC MUST agree to use null
  197.    encapsulation during the call SETUP phase.  The SVC will not be
  198.    available for use by protocols other than IPv6.
  199.  
  200.    If null encapsulation is enabled on data SVCs between routers,
  201.    inter-router NHRP traffic SHALL utilize a separate, parallel SVC.
  202.  
  203.    Use of null encapsulation is not encouraged when IPv6/ATM is used
  204.    with MARS/NHRP/ND as described in [1].
  205.  
  206. 4.1.5 MARS control messages
  207.  
  208.    The encapsulation of MARS control messages (between MARS and MARS
  209.    Clients) remains the same as shown in RFC 2022 [3]:
  210.  
  211.       [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
  212.          (LLC)       (OUI)     (PID)
  213.  
  214.    The key control field values are:
  215.  
  216.       The mar$afn field remains 0x0F (ATM addresses)
  217.  
  218.       The mar$pro field SHALL be 0x86DD (IPv6)
  219.  
  220.       The mar$op.version field remains 0x00 (MARS)
  221.  
  222.  
  223.  
  224.  
  225.  
  226. G. Armitage, et. al.        Standards Track                     [Page 4]
  227.  
  228. RFC 2492                 IPv6 over ATM Networks             January 1999
  229.  
  230.  
  231.    The mar$spln and mar$tpln fields (where relevant) are either 0 (for
  232.    null or non-existent information) or 16 (for the full IPv6 protocol
  233.    address)
  234.  
  235.    The way in which ATM addresses are stored remains the same as shown
  236.    in RFC 2022 [3]
  237.  
  238. 4.1.6 NHRP control messages
  239.  
  240.    The encapsulation of NHRP control messages remains the same as shown
  241.    in RFC 2332 [4]:
  242.  
  243.       [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message]
  244.          (LLC)       (OUI)     (PID)
  245.  
  246.    The key control field values are:
  247.  
  248.       The ar$afn field remains 0x0F (ATM addresses)
  249.  
  250.       The ar$pro field SHALL be 0x86DD (IPv6)
  251.  
  252.       The ar$op.version field remains 0x01 (NHRP)
  253.  
  254.    The ar$spln and ar$tpln fields (where relevant) are either 0 (for
  255.    null or non-existent information) or 16 (for the full IPv6 protocol
  256.    address)
  257.  
  258.    The way in which ATM addresses are stored remains the same as shown
  259.    in RFC 2022 [3]
  260.  
  261. 4.1.7 Neigbor Discovery control messages
  262.  
  263.    Section 5.2 of [1] describes the ND Link-layer address option.  For
  264.    IPv6/ATM drivers, the subfields SHALL be encoded in the following
  265.    manner:
  266.  
  267.       [NTL] defines the type and length of the ATM number immediately
  268.       following the [STL] field. The format is as follows:
  269.  
  270.             7 6 5 4 3 2 1 0
  271.             +-+-+-+-+-+-+-+-+
  272.             |0|x|  length   |
  273.             +-+-+-+-+-+-+-+-+
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. G. Armitage, et. al.        Standards Track                     [Page 5]
  283.  
  284. RFC 2492                 IPv6 over ATM Networks             January 1999
  285.  
  286.  
  287.       The most significant bit is reserved and MUST be set to zero.  The
  288.       second most significant bit (x) is a flag indicating whether the
  289.       ATM number is in:
  290.  
  291.           ATM Forum AESA format (x = 0).
  292.           Native E.164 format (x = 1).
  293.  
  294.       The bottom 6 bits represent an unsigned integer value indicating
  295.       the length of the associated ATM address field in octets.
  296.  
  297.    The [STL] format is the same as the [NTL] field. Defines the length
  298.    of the subaddress field, if it exists. If it does not exist this
  299.    entire octet field MUST be zero. If the subaddress exists it will be
  300.    in AESA format, so flag x SHALL be zero.
  301.  
  302.    [NBMA Number] is a variable length field containing the ATM address
  303.    of the Link layer target. It is always present.
  304.  
  305.    [NBMA Subaddress] is a variable length field containing the ATM
  306.    subaddress of the Link layer target. It may or may not be present.
  307.    When it is not, the option ends after the [NBMA Number] (or any
  308.    additional padding for 8 byte alignment).
  309.  
  310.    The octet ordering of the [NBMA Number] and [NBMA Subaddress] fields
  311.    SHALL be the same as that used in MARS and NHRP control messages.
  312.  
  313. 4.2 UNI 3.0/3.1 signaling issues (SVC mode).
  314.  
  315.    When an IPv6 node places a call to another IPv6 node, it SHOULD
  316.    follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs
  317.    [9] and negotiating MTU.  The default IP MTU size on a LL is 9180
  318.    bytes as specified in [7].
  319.  
  320.    Note that while the procedures in [7] still apply to IPv6 over ATM,
  321.    IPv6 Path MTU Discovery [8] is used by nodes and routers rather than
  322.    IPv4 MTU discovery. Additionally, while IPv6 nodes are not required
  323.    to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it.
  324.    Also, since IPv6 nodes will negotiate an appropriate MTU for each VC,
  325.    Path MTU should never be triggered since neither node should ever
  326.    receive a Packet Too Big message to trigger Path MTU Discovery.  When
  327.    nodes are communicating via one or more routers Path MTU Discovery
  328.    will be used just as it is for legacy networks.
  329.  
  330. 5 Interface Tokens
  331.  
  332.    For both PVC and SVC modes of operation, one of the following methods
  333.    SHALL be used to generate Interface Tokens as required by section 5.1
  334.    of [1].
  335.  
  336.  
  337.  
  338. G. Armitage, et. al.        Standards Track                     [Page 6]
  339.  
  340. RFC 2492                 IPv6 over ATM Networks             January 1999
  341.  
  342.  
  343. 5.1 Interface Tokens Based on ESI values
  344.  
  345.    When the underlying ATM interface is identified by an ATM End System
  346.    Address (AESA, formerly known as an NSAPA), the interface token MAY
  347.    be formed from the ESI and SEL values in the AESA as follows:
  348.  
  349.           [0x00][ESI][SEL]
  350.  
  351.    [0x00] is a one octet field which is always set to 0.
  352.           Note that the bit corresponding to the EUI-64 Global/Local bit
  353.           [5] is always reset indicating that this address is not a
  354.           globally unique IPv6 interface token.
  355.  
  356.    [ESI] is a six octet field.
  357.           This field always contains the six octet ESI value for the
  358.           AESA used to address the specific instance of the IPv6/ATM
  359.           interface.
  360.  
  361.    [SEL] is a one octet field.
  362.           This field always contains the SEL value from the AESA used to
  363.           address the specific instance of the IPv6/ATM interface.
  364.  
  365. 5.2 Interface Tokens Based on 48 Bit MAC Values
  366.  
  367.    Where the underlying ATM NIC driver has access to a set of one or
  368.    more 48 bit MAC values unique to the ATM NIC (e.g. MAC addresses
  369.    configured into the NIC's ROM), the IPv6/ATM interface MAY use one of
  370.    these values to create a unique interface token as described in [10].
  371.  
  372. 5.3 Interface Tokens Based on EUI-64 Values
  373.  
  374.    Where the underlying ATM NIC driver has access to a set of one or
  375.    more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
  376.    addresses configured into the NIC's ROM), the IPv6/ATM interface
  377.    SHOULD use one of these values to create a unique interface token.
  378.    after inverting the Global/Local identifier bit [10].  (Any
  379.    relationship between these values and the ESI(s) registered with the
  380.    local ATM switch by the ATM driver are outside the scope of this
  381.    document.)
  382.  
  383.    When EUI-64 values are used for IPv6 interface tokens the only
  384.    modification allowed to the octet string read from the NIC is
  385.    inversion of the Global/Local identifier bit.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. G. Armitage, et. al.        Standards Track                     [Page 7]
  395.  
  396. RFC 2492                 IPv6 over ATM Networks             January 1999
  397.  
  398.  
  399. 5.4 Interface Tokens Based on Native E.164 Addresses
  400.  
  401.    When an interface uses Native E.164 addresses then the E.164 values
  402.    MAY be used to generate an interface token as follows:
  403.  
  404.           [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
  405.  
  406.    [D14] A single octet containing the semi-octet representing the most
  407.    significant E.164 digit shifted left four bits to the most
  408.    significant four bits of the octet.  The lower four bits MUST be set
  409.    to 0.  Note that the EUI-64 Global/Local indicator is set to 0
  410.    indicating that this is not a globally unique IPv6 interface token.
  411.  
  412.    [D13D12] A single octet containing the semi-octet representing the
  413.    second most significant E.164 digit [D13] shifted left four places to
  414.    the most significant bits of the octet, and the third most
  415.    significant semi-octet in the four least significant bits of the
  416.    octet.
  417.  
  418.    [D11D10] - [D1D0] Octets each containing two E.164 digits, one in the
  419.    most significant four bits, and one in the least significant four
  420.    bits as indicated.
  421.  
  422. 5.5 Nodes Without Unique Identifiers
  423.  
  424.    If no MAC, EUI-64, AESA, or E.164 value is available for generating
  425.    an interface token, then the interface token SHALL be generated as
  426.    described in Appendix A of [10].
  427.  
  428. 5.6 Multiple Logical Links on a Single Interface
  429.  
  430.    A logical ATM interface might be associated with a different SEL
  431.    field of a common AESA prefix, or a set of entirely separate ESIs
  432.    might have been registered with the local ATM switch to create a
  433.    range of unique AESAs.
  434.  
  435.    The minimum information required to uniquely identify each logical
  436.    ATM interface is (within the context of the local switch port) their
  437.    ESI+SEL combination.
  438.  
  439.    For the vhost case described in section 5.1.2 of [1], vhost SHALL
  440.    select a different interface token from the range of 64 bit values
  441.    available to the ATM NIC (as described in 4.1). Each vhost SHALL
  442.    implement IPv6/ATM interfaces in such a way that no two or more
  443.    vhosts end up advertising the same interface token onto the same LL.
  444.    (Conformance with this requirement may be achieved by choosing
  445.    different SEL values, ESI values, or both.)
  446.  
  447.  
  448.  
  449.  
  450. G. Armitage, et. al.        Standards Track                     [Page 8]
  451.  
  452. RFC 2492                 IPv6 over ATM Networks             January 1999
  453.  
  454.  
  455. 6. Conclusion and Open Issues.
  456.  
  457.    This document is an ATM-specific companion document to the ION
  458.    working group's, "IPv6 over Non Broadcast Multiple Access (NBMA)
  459.    networks" specification [1]. It specifies codepoints for the
  460.    administratively configured PVC, and dynamically established SVC,
  461.    modes of operation.
  462.  
  463.    There are no major open issues. Comments to the ION mailing list are
  464.    solicited (ion@nexen.com).
  465.  
  466. 7. Security Considerations
  467.  
  468.    While this proposal does not introduce any new security mechanisms
  469.    all current IPv6 security mechanisms will work without modification
  470.    for ATM.  This includes both authentication and encryption for both
  471.    Neighbor Discovery protocols as well as the exchange of IPv6 data
  472.    packets.
  473.  
  474. Acknowledgments
  475.  
  476.    The original IPv6/ATM work by G. Armitage occurred while employed at
  477.    Bellcore. Elements of section 4 were borrowed from Matt Crawford's
  478.    memo on IPv6 over Ethernet.
  479.  
  480.    The authors would like to thank Kazuhiko Yamamoto, Kenjiro Cho,
  481.    Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, and Atsushi
  482.    Hagiwara for their contributions based on actual PVC implementations.
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. G. Armitage, et. al.        Standards Track                     [Page 9]
  507.  
  508. RFC 2492                 IPv6 over ATM Networks             January 1999
  509.  
  510.  
  511. Authors' Addresses
  512.  
  513.    Grenville Armitage
  514.    Bell Laboratories, Lucent Technologies
  515.    101 Crawfords Corner Road
  516.    Holmdel, NJ 07733
  517.    USA
  518.  
  519.    EMail: gja@lucent.com
  520.  
  521.  
  522.    Peter Schulter
  523.    BrightTiger Technologies
  524.    125 Nagog Park
  525.    Acton, MA 01720
  526.  
  527.    EMail: paschulter@acm.org
  528.  
  529.  
  530.    Markus Jork
  531.    European Applied Research Center
  532.    Digital Equipment GmbH
  533.    CEC Karlsruhe
  534.    Vincenz-Priessnitz-Str. 1
  535.    D-76131 Karlsruhe
  536.    Germany
  537.  
  538.    EMail: jork@kar.dec.com
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. G. Armitage, et. al.        Standards Track                    [Page 10]
  563.  
  564. RFC 2492                 IPv6 over ATM Networks             January 1999
  565.  
  566.  
  567. References
  568.  
  569.    [1] Armitage, G., Schulter, P., Jork, M. and G. Harter, "IPv6 over
  570.        Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January
  571.        1999.
  572.  
  573.    [2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption
  574.        Layer 5", RFC 1483, July 1993.
  575.  
  576.    [3] Armitage, G., "Support for Multicast over UNI 3.1 based ATM
  577.        Networks", RFC 2022, November 1996.
  578.  
  579.    [4] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
  580.        "NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
  581.  
  582.    [5] "64-Bit Global Identifier Format Tutorial",
  583.        http://standards.ieee.org/db/oui/tutorials/EUI64.html.
  584.  
  585.    [6] Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D. and A.
  586.        Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
  587.        February 1995.
  588.  
  589.    [7] Atkinson, R., "Default IP MTU for use over ATM AAL5", RFC 1626,
  590.        May 1994.
  591.  
  592.    [8] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP
  593.        version 6", RFC 1981, August 1996.
  594.  
  595.    [9] ATM Forum, "ATM User Network Interface (UNI) Specification
  596.        Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood
  597.        Cliffs, NJ, June 1995.
  598.  
  599.    [10] Hinden, B. and S. Deering, "IP Version 6 Addressing
  600.         Architecture", RFC 2373, July 1998.
  601.  
  602.    [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
  603.         IP Version 6 (IPv6)", RFC 2461, December 1998.
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. G. Armitage, et. al.        Standards Track                    [Page 11]
  619.  
  620. RFC 2492                 IPv6 over ATM Networks             January 1999
  621.  
  622.  
  623. Full Copyright Statement
  624.  
  625.    Copyright (C) The Internet Society (1999).  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. G. Armitage, et. al.        Standards Track                    [Page 12]
  675.  
  676.