home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ion-ipv6-atm-00.txt < prev    next >
Text File  |  1997-10-13  |  18KB  |  561 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet-Draft                                       Grenville Armitage
  8.                                                     Lucent Technologies
  9.                                                          Peter Schulter
  10.                                                BrightTiger Technologies
  11.                                           Markus Jork, Geraldine Harter
  12.                                                                 Digital
  13.                                                      October 11th, 1997
  14.  
  15.  
  16.                          IPv6 over ATM Networks
  17.                     <draft-ietf-ion-ipv6-atm-00.txt>
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This document was submitted to the IETF Internetworking over NBMA
  23.    (ION) WG.  Publication of this document does not imply acceptance by
  24.    the ION WG of any ideas expressed within.  Comments should be
  25.    submitted to the ion@nexen.com mailing list.
  26.  
  27.    Distribution of this memo is unlimited.
  28.  
  29.    This memo is an internet draft. Internet Drafts are working documents
  30.    of the Internet Engineering Task Force (IETF), its Areas, and its
  31.    Working Groups. Note that other groups may also distribute working
  32.    documents as Internet Drafts.
  33.  
  34.    Internet Drafts are draft documents valid for a maximum of six
  35.    months. Internet Drafts may be updated, replaced, or obsoleted by
  36.    other documents at any time. It is not appropriate to use Internet
  37.    Drafts as reference material or to cite them other than as a "working
  38.    draft" or "work in progress".
  39.  
  40.    To learn the current status of any Internet-Draft, please check the
  41.    "lid-abstracts.txt" listing contained in the Internet-Drafts shadow
  42.    directories on ds.internic.net (US East Coast), nic.nordu.net
  43.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  44.    Rim).
  45.  
  46. Abstract
  47.  
  48.    This document is a companion to the ION working group's architecture
  49.    document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'.
  50.    It provides specific details on how to apply the IPv6 over NBMA
  51.    architecture to ATM networks. This architecture allows conventional
  52.    host-side operation of the IPv6 Neighbor Discovery protocol, while
  53.    also supporting the establishment of 'shortcut' ATM forwarding paths
  54.    (when using SVCs).  Operation over administratively configured Point
  55.    to Point PVCs is also supported.
  56.  
  57. Revision History
  58.  
  59.       September 1997, split draft-ietf-ion-tn-01.txt apart to isolate
  60.          the ATM specific details from the NBMA-generic architecture.
  61.  
  62.  
  63. Armitage, et al.              Expires April 11th, 1998           [Page 1]
  64.  
  65.  
  66. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  67.  
  68.  
  69.          New name of this document: draft-ietf-ion-ipv6-atm-00.txt,
  70.          containing the ATM-specific details. (General architecture
  71.          document now: draft-ietf-ion-ipv6-00.txt.)
  72.  
  73.  
  74.  
  75. 1. Introduction.
  76.  
  77.    This document is an ATM-specific companion document to the ION
  78.    working group's "IPv6 over Non Broadcast Multiple Access (NBMA)
  79.    networks" specification [1].  Terminology and architectural
  80.    descriptions will not be repeated here.
  81.  
  82.    The use of ATM to provide point to point PVC service, or flexible
  83.    point to point and point to multipoint SVC service, is covered by
  84.    this document.
  85.  
  86.    A minimally conforming IPv6/ATM driver SHALL support the PVC mode of
  87.    operation. An IPv6/ATM driver that supports the full SVC mode SHALL
  88.    also support PVC mode of operation.
  89.  
  90.  
  91. 2. Specification Terminology
  92.  
  93.    The following terminology is used in the items of specification in
  94.    this document:
  95.  
  96.        o MUST, SHALL, or MANDATORY -- the item is an absolute
  97.          requirement of the specification.
  98.  
  99.        o SHOULD or RECOMMENDED -- the item should generally be followed
  100.          for all but exceptional circumstances.
  101.  
  102.        o MAY or OPTIONAL -- the item is truly optional and may be
  103.          followed or ignored according to the needs of the implementor.
  104.  
  105.    They are to be interpreted as described in RFC 2119 [16].
  106.  
  107.  
  108. 3. ATM specific codepoints and parameters.
  109.  
  110. 3.1 Packet encapsulation for PVC environments
  111.  
  112.    Following the model in RFC 1483 [2], AAL5 SHALL be the default
  113.    Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be
  114.    default encapsulation used by unicast and multicast packets across
  115.    pt-pt PVC links. As defined in [1], the default IPv6 packet
  116.    encapsulation SHALL be:
  117.  
  118.          [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
  119.              (LLC)       (OUI)     (PID)
  120.  
  121. 3.1.1 Optional null encapsulation
  122.  
  123.  
  124.  
  125. Armitage, et al.              Expires April 11th, 1998           [Page 2]
  126.  
  127.  
  128. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  129.  
  130.  
  131.    IPv6/ATM drivers MAY also support null encapsulation as a
  132.    configurable option. When null encapsulation is enabled, the IPv6
  133.    packet is passed directly to the AAL5 layer. Both ends of the PVC
  134.    MUST be configured to use null encapsulation. The PVC will not be
  135.    available for use by protocols other than IPv6.
  136.  
  137. 3.1.2 PPP encapsulation
  138.  
  139.    The concatentation of IPv6 over PPP with PPP over AAL5 PVCs is not
  140.    covered by this specification.
  141.  
  142. 3.2 Packet encapsulation for SVC environments
  143.  
  144.    Following the model in RFC 1483 [2], AAL5 SHALL be the default
  145.    Adaptation Layer service, and (LLC/SNAP) encapsulation SHALL be the
  146.    default encapsulation used by unicast and multicast packets across
  147.    SVC links.
  148.  
  149. 3.2.1 Unicast packet encapsulation
  150.  
  151.    As defined in [1], the default IPv6 unicast packet encapsulation
  152.    SHALL be:
  153.  
  154.          [0xAA-AA-03][0x00-00-00][0x86-DD][IPv6 packet]
  155.              (LLC)       (OUI)     (PID)
  156.  
  157. 3.2.2 Multicast packet encapsulation
  158.  
  159.    As defined in [1], the default IPv6 multicast packet encapsulation
  160.    SHALL be:
  161.  
  162.          [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet]
  163.              (LLC)       (OUI)     (PID)    (mars encaps)
  164.  
  165.          The IPv6/ATM driver's Cluster Member ID SHALL be copied into
  166.          the 2 octet pkt$cmi field prior to transmission.
  167.  
  168. 3.2.3 Optional null encapsulation
  169.  
  170.    IPv6/ATM drivers MAY also support null encapsulation as a
  171.    configurable option. Null encapsulation SHALL only be used for
  172.    passing IPv6 packets from one IPv6/ATM driver to another. Null
  173.    encapsulation SHALL NOT be used on the pt-pt SVC between the IPv6/ATM
  174.    driver and its local MARS.
  175.  
  176.    If null encapsulation is enabled, the IPv6 packet is passed directly
  177.    to the AAL5 layer. Both ends of the SVC MUST agree to use null
  178.    encapsulation during the call SETUP phase.  The SVC will not be
  179.    available for use by protocols other than IPv6.
  180.  
  181.    If null encapsulation is enabled on data SVCs between routers,
  182.    inter-router NHRP traffic SHALL utilize a separate, parallel SVC.
  183.  
  184.    Use of null encapsulation is not encouraged when IPv6/ATM is used
  185.  
  186.  
  187. Armitage, et al.              Expires April 11th, 1998           [Page 3]
  188.  
  189.  
  190. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  191.  
  192.  
  193.    with MARS/NHRP/ND as described in [1].
  194.  
  195. 3.3 MARS control messages
  196.  
  197.    The encapsulation of MARS control messages (between MARS and MARS
  198.    Clients) remains the same as shown in RFC 2022 [3]:
  199.  
  200.       [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
  201.          (LLC)       (OUI)     (PID)
  202.  
  203.    The key control field values are:
  204.  
  205.       The mar$afn field remains 0x0F (ATM addresses)
  206.  
  207.       The mar$pro field SHALL be 0x86DD (IPv6)
  208.  
  209.       The mar$op.version field remains 0x00 (MARS)
  210.  
  211.    The mar$spln and mar$tpln fields (where relevant) are either 0 (for
  212.    null or non-existent information) or 16 (for the full IPv6 protocol
  213.    address)
  214.  
  215.    No changes to the way ATM addresses are stored in [3].
  216.  
  217. 3.4 NHRP control messages
  218.  
  219.    The encapsulation of NHRP control messages remains the same as shown
  220.    in RFC xxxx [4]:
  221.  
  222.       [0xAA-AA-03][0x00-00-5E][0x00-03][NHRP control message]
  223.          (LLC)       (OUI)     (PID)
  224.  
  225.    The key control field values are:
  226.  
  227.       The ar$afn field remains 0x0F (ATM addresses)
  228.  
  229.       The ar$pro field SHALL be 0x86DD (IPv6)
  230.  
  231.       The ar$op.version field remains 0x01 (NHRP)
  232.  
  233.    The ar$spln and ar$tpln fields (where relevant) are either 0 (for
  234.    null or non-existent information) or 16 (for the full IPv6 protocol
  235.    address)
  236.  
  237.    No changes to the way ATM addresses are stored in [3].
  238.  
  239. 3.5 Neigbor Discovery control messages
  240.  
  241.    Section 5.2 of [1] describes the ND Link-layer address option.  For
  242.    IPv6/ATM drivers, the subfields SHALL be encoded in the following
  243.    manner:
  244.  
  245.       [NTL] defines the type and length of the ATM number immediately
  246.       following the [STL] field. The format is as follows:
  247.  
  248.  
  249. Armitage, et al.              Expires April 11th, 1998           [Page 4]
  250.  
  251.  
  252. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  253.  
  254.  
  255.             7 6 5 4 3 2 1 0
  256.             +-+-+-+-+-+-+-+-+
  257.             |0|x|  length   |
  258.             +-+-+-+-+-+-+-+-+
  259.  
  260.       The most significant bit is reserved and MUST be set to zero.  The
  261.       second most significant bit (x) is a flag indicating whether the
  262.       ATM number is in:
  263.  
  264.           ATM Forum AESA format (x = 0).
  265.           Native E.164 format (x = 1).
  266.  
  267.       The bottom 6 bits represent an unsigned integer value indicating
  268.       the length of the associated ATM address field in octets.
  269.  
  270.    The [STL] format is the same as the [NTL] field. Defines the length
  271.    of the subaddress field, if it exists. If it does not exist this
  272.    entire octet field MUST be zero. If the subaddress exists it will be
  273.    in AESA format, so flag x SHALL be zero.
  274.  
  275.    [NBMA Number] is a variable length field containing the ATM address
  276.    of the Link layer target. It is always present.
  277.  
  278.    [NBMA Subaddress] is a variable length field containing the ATM
  279.    subaddress of the Link layer target. It may or may not be present.
  280.    When it is not, the option ends after the [NBMA Number] (or any
  281.    additional padding for 8 byte alignment).
  282.  
  283.    The octet ordering of the [NBMA Number] and [NBMA Subaddress] fields
  284.    SHALL be the same as that used in MARS and NHRP control messages.
  285.  
  286.  
  287. 4. Interface Tokens
  288.  
  289.    For both PVC and SVC modes of operation, one of the following methods
  290.    SHALL be used to generate Interface Tokens as required by section 5.1
  291.    of [1].
  292.  
  293. 4.1 Interface Tokens Based on MAC or ESI values
  294.  
  295.    When the underlying ATM interface is identified by an ATM End System
  296.    Address (AESA, formerly known as an NSAPA), the interface token MAY
  297.    be formed from the ESI and SEL values in the AESA as follows:
  298.  
  299.           [0x00][ESI][SEL]
  300.  
  301.    [0x00] is a one octet field which is always set to 0.
  302.           Note that the bit corresponding to the EUI-64 Global/Local bit
  303.           [5] is always reset indicating that this address is not a
  304.           globally unique IPv6 interface token.
  305.  
  306.    [ESI] is a six octet field.
  307.           This field always contains the six octet ESI value for the
  308.           AESA used to address the specific instance of the IPv6/ATM
  309.  
  310.  
  311. Armitage, et al.              Expires April 11th, 1998           [Page 5]
  312.  
  313.  
  314. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  315.  
  316.  
  317.           interface.
  318.  
  319.    [SEL] is a one octet field.
  320.           This field always contains the SEL value from the AESA used to
  321.           address the specific instance of the IPv6/ATM interface.
  322.  
  323. 4.2 Interface Tokens Based on EUI-64 Values
  324.  
  325.    Where the underlying ATM NIC driver has access to a set of one or
  326.    more 64 bit EUI-64 values unique to the ATM NIC (e.g. EUI-64
  327.    addresses configured into the NIC's ROM), the IPv6/ATM interface
  328.    SHOULD use one of these values to create a unique interface token.
  329.    after inverting the Global/Local identifier bit.  (Any relationship
  330.    between these values and the ESI(s) registered with the local ATM
  331.    switch by the ATM driver are outside the scope of this document.)
  332.  
  333.    When EUI-64 values are used for IPv6 interface tokens the only
  334.    modification allowed to the octet string read from the NIC is
  335.    inversion of the Global/Local identifier bit.
  336.  
  337. 4.3 Interface Tokens Based on Native E.164 Addresses
  338.  
  339.    When an interface uses Native E.164 addresses then the E.164 values
  340.    MAY be used to generate an interface token as follows:
  341.  
  342.           [D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]
  343.  
  344.    [D14] A single octet containing the semi-octet representing the most
  345.    significant E.164 digit shifted left four bits to the most
  346.    significant four bits of the octet.  The lower four bits MUST be set
  347.    to 0.  Note that the EUI-64 Global/Local indicator is set to 0
  348.    indicating that this is not a globally unique IPv6 interface token.
  349.  
  350.    [D13D12] A single octet containing the semi-octet representing the
  351.    second most significant E.164 digit [D13] shifted left four places to
  352.    the most significant bits of the octet, and the third most
  353.    significant semi-octet in the four least significant bits of the
  354.    octet.
  355.  
  356.    [D11D10] - [D1D0] Octets each containing two E.164 digits, one in the
  357.    most significant four bits, and one in the least significant four
  358.    bits as indicated.
  359.  
  360. 4.5 Multiple Logical Links on a Single Interface
  361.  
  362.    A logical ATM interface might be associated with a different SEL
  363.    field of a common AESA prefix, or a set of entirely separate ESIs
  364.    might have been registered with the local ATM switch to create a
  365.    range of unique AESAs.
  366.  
  367.    The minimum information required to uniquely identify each logical
  368.    ATM interface is (within the context of the local switch port) their
  369.    ESI+SEL combination.
  370.  
  371.  
  372.  
  373. Armitage, et al.              Expires April 11th, 1998           [Page 6]
  374.  
  375.  
  376. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  377.  
  378.  
  379.    For the vhost case described in section 5.1.2 of [1], vhost SHALL
  380.    select a different interface token from the range of 64 bit values
  381.    available to the ATM NIC (as described in 4.1). Each vhost SHALL
  382.    implement IPv6/ATM interfaces in such a way that no two or more
  383.    vhosts end up advertising the same interface token onto the same LL.
  384.    (Conformance with this requirement may be achieved by choosing
  385.    different SEL values, ESI values, or both.)
  386.  
  387.  
  388. 5. UNI 3.0/3.1 signaling issues (SVC mode).
  389.  
  390.    When an IPv6 node places a call to another IPv6 node, it SHOULD
  391.    follow the procedures in [6] and [7] for signalling UNI 3.0/3.1 SVCs
  392.    [9] and negotiating MTU.  The default MTU size on a LL is 9188 bytes
  393.    as specified in [7].
  394.  
  395.    Note that while the procedures in [7] still apply to IPv6 over ATM,
  396.    IPv6 Path MTU Discovery [8] is used by nodes and routers rather than
  397.    IPv4 MTU discovery. Additionally, while IPv6 nodes are not required
  398.    to implement Path MTU Discovery, IPv6/ATM nodes SHOULD implement it.
  399.    Also, since IPv6 nodes will negotiate an appropriate MTU for each VC,
  400.    Path MTU should never be triggered since neither node should ever
  401.    receive a Packet Too Big message to trigger Path MTU Discovery.  When
  402.    nodes are communicating via one or more routers Path MTU Discovery
  403.    will be used just as it is for legacy networks.
  404.  
  405.  
  406. 6. Conclusion and Open Issues.
  407.  
  408.    This document is an ATM-specific companion document to the ION
  409.    working group's "IPv6 over Non Broadcast Multiple Access (NBMA)
  410.    networks" specification [1]. It specifies codepoints for the
  411.    administratively configured PVC, and dynamically established SVC,
  412.    modes of operation.
  413.  
  414.    There are no major open issues. Comments to the ION mailing list are
  415.    solicited (ion@nexen.com).
  416.  
  417.  
  418. 7. Security Consideration
  419.  
  420.    While this proposal does not introduce any new security mechanisms
  421.    all current IPv6 security mechanisms will work without modification
  422.    for ATM.  This includes both authentication and encryption for both
  423.    Neighbor Discovery protocols as well as the exchange of IPv6 data
  424.    packets.
  425.  
  426.  
  427. Acknowledgments
  428.  
  429.    The original IPv6/ATM work by G. Armitage occurred while employed at
  430.    Bellcore. Elements of section 4 were borrowed from Matt Crawford's
  431.    draft on IPv6 over Ethernet.
  432.  
  433.  
  434.  
  435. Armitage, et al.              Expires April 11th, 1998           [Page 7]
  436.  
  437.  
  438. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  439.  
  440.  
  441. Author's addresses
  442.  
  443.    Grenville Armitage
  444.    Bell Laboratories, Lucent Technologies
  445.    101 Crawfords Corner Road
  446.    Holmdel, NJ 07733
  447.    USA
  448.    Email: gja@lucent.com
  449.  
  450.    Peter Schulter
  451.    BrightTiger Technologies
  452.    125 Nagog Park
  453.    Acton, MA 01720
  454.    Email: paschulter@acm.org
  455.  
  456.    Markus Jork
  457.    European Applied Research Center
  458.    Digital Equipment Corporation
  459.    CEC Karlsruhe
  460.    Vincenz-Priessnitz-Str. 1
  461.    D-76131 Karlsruhe
  462.    Germany
  463.    email: jork@kar.dec.com
  464.  
  465.    Geraldine Harter
  466.    Digital UNIX Networking
  467.    Digital Equipment Corporation
  468.    110 Spit Brook Road
  469.    Nashua, NH 03062
  470.    Email: harter@zk3.dec.com
  471.  
  472. References.
  473.  
  474.    [1] G. Armitage, P.Schulter, M. Jork, G. Harter, "IPv6 over Non-
  475.    Broadcast Multiple Access (NBMA) networks", INTERNET DRAFT, draft-
  476.    ietf-ion-ipv6-00.txt, October 1997
  477.  
  478.    [2] J. Heinanen, "Multiprotocol Encapsulation over ATM Adaption Layer
  479.    5", RFC 1483, USC/Information Science Institute, July 1993.
  480.  
  481.    [3] G.J. Armitage, "Support for Multicast over UNI 3.1 based ATM
  482.    Networks", RFC 2022, Bellcore, November 1996.
  483.  
  484.    [4] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)",
  485.    INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, March 1997.
  486.  
  487.    [5] "64-Bit Global Identifier Format Tutorial",
  488.    http://standards.ieee.org/db/oui/tutorials/EUI64.html.
  489.  
  490.    [6] M. Perez, et al, "ATM Signalling Support for IP over ATM", RFC
  491.    1755, February 1995
  492.  
  493.    [7] R. Atkinson, "Default IP MTU for use over ATM AAL5", RFC 1626,
  494.    May 1994
  495.  
  496.  
  497. Armitage, et al.              Expires April 11th, 1998           [Page 8]
  498.  
  499.  
  500. Internet Draft       draft-ietf-ion-ipv6-atm-00.txt   October 11th, 1997
  501.  
  502.  
  503.    [8] J. McCann, et al, "Path MTU Discovery for IP version 6", RFC
  504.    1981, August 1996
  505.  
  506.    [9] ATM Forum, "ATM User Network Interface (UNI) Specification
  507.    Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
  508.    NJ, June 1995.
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  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. Armitage, et al.              Expires April 11th, 1998           [Page 9]
  560.  
  561.