Internet Draft






ION/IPng Working Group                                  A. Conta
INTERNET-DRAFT                                          (Lucent)
                                                        A. Malis
                                                        (Ascend)
                                                        M. Mueller
                                                        (Lucent)
                                                        November 1997


         Transmission of IPv6 Packets over Frame Relay Networks

                             Specification

                     draft-conta-ion-ipv6-fr-00.txt


Status of this Memo

   This document is  an  Internet-Draft.   Internet-Drafts  are  working
   documents  of  the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups  may  also  distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft  documents  valid  for  a  maximum  of  six
   months.  Internet-Drafts  may  be  updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to  use  Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet-Draft, please  check  the
   ``1id-abstracts.txt''  listing  contained  in  the  Internet-  Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net  (Europe),
   munnari.oz.au  (Pacific  Rim),  ds.internic.net  (US  East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   This memo describes mechanisms for the transmission of  IPv6  packets
   over Frame Relay networks.

1. Introduction


   This document specifies the frame format  for  transmission  of  IPv6
   packets  over  Frame Relay networks, the method of forming IPv6 link-
   local addresses on Frame Relay links, and the  mapping  of  the  IPv6



conta & malis & mueller   Expires in six months     [Page 1]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


   addresses to Frame Relay addresses.  It also specifies the content of
   the  Source/Target  link-layer  address  option  used  in    Neighbor
   Discovery  [ND]  or  Inverse  Neighbor  Discovery [IND] messages when
   those messages are transmitted over a Frame Relay link.  It  is  part
   of  a  set of specifications that define such IPv6 mechanisms for Non
   Broadcast Multi Access (NBMA) media [IPV6_NBMA],  [IPv6_ATM],  and  a
   larger  set  that  defines  such  mechanisms for specific link layers
   [IPv6_ETH], [IPv6_FDDI], [IPv6_PPP], [IPv6_ATM], etc...

   The information in this document applies to Frame Relay devices which
   serve  as  end  stations  (DTEs)  on  a public or private Frame Relay
   network (for example, provided by a common  carrier  or  PTT.)  Frame
   Relay  end  stations  can  be IPv6 hosts or routers. In this document
   they are referred to as nodes.

   In a Frame Relay network, a  number  of  virtual  circuits  form  the
   connections  between the attached stations (nodes). The resulting set
   of interconnected devices forms a private Frame Relay group which may
   be  either  fully  interconnected  with  a complete "mesh" of virtual
   circuits, or only partially interconnected.   In  either  case,  each
   virtual  circuit is uniquely identified at each Frame Relay interface
   (card)  by  a  Data  Link  Connection  Identifier  (DLCI).   In  most
   circumstances,  DLCIs  have strictly local significance at each Frame
   Relay interface.

   A Frame Relay virtual circuit acts like a virtual-link (also referred
   to  as logical-link), with its own link parameters, distinct from the
   parameters of other virtual circuits established on the same wire  or
   fiber.  Such  parameters  are  the  input/output  maximum frame size,
   incoming/outgoing  requested/agreed   throughput,   incoming/outgoing
   acceptable      throughput,     incoming/outgoing     burst     size,
   incoming/outgoing frame rate.

   By default a DLCI is 10 bits in length.  Frame  Relay  specifications
   define  also  16,  17, or 23 bit DLCIs. The former is not used, while
   the latter two are suggested for use with SVCs.

   Frame Relay virtual  circuits  can  be  created  administratively  as
   Permanent  Virtual  Circuits  --  PVCs  -- or dynamically as Switched
   Virtual Circuits -- SVCs.  The mechanisms defined  in  this  document
   are  intended  to  apply  to  both permanent and switched Frame Relay
   virtual circuits (PVCs, and  respectively  SVCs),  whether  they  are
   point to point or point to multi-point.

   The keywords MUST, MUST NOT, MAY, OPTIONAL,   REQUIRED,  RECOMMENDED,
   SHALL,  SHALL  NOT,  SHOULD,  SHOULD  NOT   are  to be interpreted as
   defined in RFC 2119.




conta & malis & mueller   Expires in six months     [Page 2]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


2. Maximum Transmission Unit

   IPv6 requires a minimum MTU size of 576 [TBD] octets.

   In general, Frame Relay devices are  configured  to  have  a  maximum
   frame  size  of at least 1600 octets. Therefore, the default IPv6 MTU
   size for a Frame Relay interface is considered to be 1592.

   A smaller than default frame size can be configured but of course not
   smaller than the minimum IPv6 MTU.

   An adequate larger than default IPv6 MTU can be configured  to  avoid
   fragmentation.  The  maximum  frame  size  is  controlled  by the CRC
   generation mechanisms employed at the HDLC level. CRC16 will  protect
   frames  up  to  4096  bytes  in  length,  which reduces the effective
   maximum frame size to approximately  4088  bytes.  A  larger  desired
   frame  size  (such as that used by FDDI or Token Ring), would require
   the CRC32 mechanism,  which  is  not  yet  widely  used  and  is  not
   mandatory for frame relay systems conforming to Frame Relay Forum and
   ITU-T standards.

   In   general,   if    upper    layers    provide    adequate    error
   protection/detection    mechanisms,    implementations    may   allow
   configuring a Frame Relay link with a larger than 4080  octets  frame
   size  but  with a lesser error protection/detection mechanism at link
   layer. However, because IPv6 relies on  the  upper  and  lower  layer
   error detection, configuring the IPv6 MTU to a value larger than 4080
   is strongly discouraged.

   Although a Frame Relay circuit  allows  the  definition  of  distinct
   maximum   frame  sizes  for  input  and  output,  for  simplification
   purposes, this specification assumes symmetry, i.e. the same MTU  for
   both input and output.

   Furthermore, implementations may limit the setting of the Frame Relay
   maximum frame size to the interface (link, or card) level, which then
   is enforced on all of the PVCs or SVCs on  that  interface  (on  that
   link,  or  card).  For  an  SVC,  the  maximum  frame  size parameter
   negotiated during  circuit  setup  will  not  exceed  the  configured
   maximum frame size.


3. Frame format

   The IPv6 frame encapsulation for Frame Relay (for both PVCs and SVCs)
   follows  [ENCAPS], which allows a VC to carry IPv6 packets along with
   other protocol packets. The NLPID frame format is used, in which  the
   IPv6 NLPID has a value of 0x8E:



conta & malis & mueller   Expires in six months     [Page 3]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


            0                       1                       (Octets)
           +-----------------------+-----------------------+
(Octets)0  |                                               |
           /                 Q.922 Address                 /
           /            (length 'n' equals 2 or 4)         /
           |                                               |
           +-----------------------+-----------------------+
        n  | Control (UI)  0x03    |      NLPID  0x8E      |  NLPID
           +-----------------------+-----------------------+  indicating
      n+2  |                       .                       |  IPv6
           /                       .                       /
           /                  IPv6 packet                  /
           |                       .                       |
           +-----------------------+-----------------------+

       "n" is the length of the Q.922  address  which  can  be  2  or  4
       octets.

       The Q.922 representation of a DLCI  (in  canonical  order  -  the
       first  bit  is  stored in the least significant, i.e., the right-
       most bit of a byte in memory) [CANON]is the following:


            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        1  |  DLCI(low order)      |  0  |  0  |  0  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              10 bits DLCI

            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        1  |  DLCI                 |  0  |  0  |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        2  |             DLCI(low order)             |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        3  |       unused (set to 0)           |  1  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              17 bits DLCI







conta & malis & mueller   Expires in six months     [Page 4]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


            7     6     5     4     3     2     1     0      (bit order)
           +-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0  |            DLCI(high order)       |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----
        1  |  DLCI                 |  0  |  0  |  0  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        2  |             DLCI                        |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
        3  |       DLCI (low order)            |  0  |  1  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

              23 bits DLCI


   The encapsulation of data or control messages  exchanged  by  various
   protocols  that  use  SNAP encapsulation (with their own PIDs) is not
   affected, The encoding  of  the  IPv6  protocol  identifier  in  such
   messages  MUST  be  done  according  to  the  specifications of those
   protocols, and [ASSNUM].


4. Stateless Autoconfiguration

   An interface identifier [AARCH] for an  IPv6  Frame  Relay  interface
   must  be  unique on a Frame Relay link [AARCH], and must be unique on
   each of the virtual links represented by the VCs  terminated  on  the
   interface.

   The interface identifier for the Frame  Relay  interface  is  locally
   generated by the IPv6 module.

   Each virtual circuit in a Frame Relay network is uniquely  identified
   on a Frame Relay interface by a DLCI. Furthermore, a DLCI can be seen
   as an identification of the end point of a virtual circuit on a Frame
   Relay   interface.  Since  each  Frame  Relay  VC  is  configured  or
   established separately, and acts  like  an  independent  virtual-link
   from  other  VCs  in  the network, or on the interface, link, wire or
   fiber, it seems beneficial to view each VC's termination point on the
   Frame  Relay interface as a "pseudo-interface" or "logical-interface"
   overlaid  on  the  Frame  Relay  interface.  Furthermore,  it   seems
   beneficial   to   be   able   to   generate  and  associate  an  IPv6
   autoconfigured address (including an IPv6 link local address) to each
   "pseudo-interface",  i.e.  end-point  of a VC, i.e. to each DLCI on a
   Frame Relay interface.

   In order to achieve the  benefits  described  above,  the  mechanisms
   specified  in  this  document  suggest  constructing  the Frame Relay
   interface identifier from 3 distinct fields (Fig.1):



conta & malis & mueller   Expires in six months     [Page 5]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


  (a)  The  "EUI  bits"  field.  Bits  6  and  7  of  the  first  octet,
       representing   the   EUI-64  "universal/local"  and  respectively
       "individual/group" bits converted to IPv6 use. The former is  set
       to zero to reflect that the 64 bit interface identifier value has
       local significance [AARCH]. The latter is set to 0 to reflect the
       unicast address [AARCH].


  (b)  The "Mid" field. A 38 bit  field  which  is  generated  with  the
       purpose of adding uniqueness to the interface identifier.


  (c)  The "DLCI" field. A 24 bit field that MAY hold a 10,  17,  or  23
       bit DLCI value which MUST be extended with 0's to 24 bits. A DLCI
       based interface identifier -- which  contains  a  valid  DLCI  --
       SHOULD be generated as a result of successfully establishing a VC
       -- PVC or SVC.

       If a DLCI is not known, the field MUST be set to the "unspecified
       DLCI" value which consists of setting each of the 24 bits to 1.

   Since DLCIs are local to a Frame Relay node, it is possible  to  have
   Frame  Relay  distinct  virtual circuits within a Frame Relay network
   identified with the same DLCI values.

             7     6     5     4     3     2     1     0      (bit order)
            +-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0  |                                   |"EUI bits" |
            +                                   +-----+-----+
         1  |                                               |
            +                                               +
         2  |                   "Mid"                       |
            +                                               +
         3  |                                               |
            +                                               +
         4  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
         5  |                                               |
            +                                               +
         6  |                    "DLCI"                     |
            +                                               +
         7  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+

            Fig.1

   The  Duplicate  Address  Detection  specified  in  [CONF]   is   used
   repeatedly  during  the  interface  identifier and local-link address



conta & malis & mueller   Expires in six months     [Page 6]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


   generation process, until the generated identifier  and  consequently
   the link-local address on the link -- VC -- are unique.


4.1  Generating the "Mid" field.

   The "Mid" can be  generated  in  multiple  ways.  This  specification
   suggests two mechanisms:

(b.1)  "Use of Local Administrative Numbers"

       The "Mid" is filled with the result of merging:

  (b.1.1)  A random number of 6 bits in length (Fig.2).


  (b.1.2)  The Frame Relay Node Identifier --  16  bits  --  is  a  user
           administered  value  used  to  locally identify a Frame Relay
           node (Fig.2).


  (b.1.3)  The Frame Relay Link Identifier -- 16 bits -- is a  numerical
           representation of the Frame Relay interface or link (Fig.2).

             7     6     5     4     3     2     1     0      (bit order)
            +-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0  |          Random Number            |    MBZ    |
            +-----------------------------------+-----+-----+
         1  |                                               |
            +          Frame Relay Node Identifier          +
         2  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
         3  |                                               |
            +          Frame Relay Link Identifier          +
         4  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
         5  |                                               |
            +                                               +
         6  |                    "DLCI"                     |
            +                                               +
         7  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+

            Fig.2

   or,





conta & malis & mueller   Expires in six months     [Page 7]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


(b.2)  "Use of E.164 numbers"

       If a Frame Relay interface has an  E.164  number  (address),  the
       "Mid"  field  MUST be filled in with a number resulted from it as
       follows:  the number represented by the 15 decimal digits of  the
       E.164 number is  binary encoded and truncated to 38 bits (Fig.3).
       Since  the  Frame  Relay  interface  identifier  has  a   "local"
       significance,  the  use  of  the  E.164  based  value has no real
       practical purposes other than adding to  the  uniqueness  of  the
       interface identifier on the link. Therefore the truncation can be
       performed on the high order or low order bits. If the high  order
       bits  truncation  does  not  provide  uniqueness  on  the link --
       perhaps the DLCI value is not unique -- this  most  likely  means
       that  the  VC  spans  more  than  a national and/or international
       destination area, and therefore the truncation of the  low  order
       bits should be performed next, which most likely will provide the
       desired uniqueness.

             7     6     5     4     3     2     1     0      (bit order)
            +-----+-----+-----+-----+-----+-----+-----+-----+
(Octets) 0  | High Order of E.164 Based Value   |    MBZ    |
            +-                                 -+-----+-----+
         1  |                                               |
            +                                               +
         2  |            Low order of                       |
            +            E.164 Address Based Value          +
         3  |                                               |
            +                                               +
         4  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+
         5  |                                               |
            +                                               +
         6  |                    "DLCI"                     |
            +                                               +
         7  |                                               |
            +-----+-----+-----+-----+-----+-----+-----+-----+

            Fig.3



5. Link-Local Addresses

   The IPv6 link-local address [AARCH] for an IPv6 Frame Relay interface
   is  formed  by  appending the interface identifier, formed as defined
   above, to the prefix FE80::/64 [AARCH].





conta & malis & mueller   Expires in six months     [Page 8]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


       10 bits            54 bits                  64 bits
     +----------+-----------------------+----------------------------+
     |1111111010|         (zeros)       |Frame Relay Interface Ident.|
     +----------+-----------------------+----------------------------+


6. Address Mapping -- Unicast, Multicast

   The procedure for mapping IPv6 addresses to link-layer  addresses  is
   described  in  [ND].  Additionally,  extensions to Neighbor Discovery
   (ND) that allow the mapping of link-layer addresses to IPv6 addresses
   are  defined  as  Inverse  Neighbor  Discovery  (IND)  in [IND]. This
   document defines the formats of the link-layer address fields used by
   ND and IND.

   The  Source/Target  Link-layer  Address  option  used   in   Neighbor
   Discovery  and  Inverse Neighbor Discovery messages for a Frame Relay
   link follows the general rules defined by [ND].  IPv6  addresses  can
   map  two  type  of  identifiers  equivalent  to link-layer addresses:
   DLCIs, and E.164 numbers.  Therefore, for Frame Relay  this  document
   defines  for  the  ND  and  IND messages Link-Layer Address field two
   distinct formats:


   (a)  DLCI format -- used in ND and/or IND messages on VCs  that  were
        established  prior  to the ND or IND message exchange --  mostly
        PVCs.  The  use  on  SVCs  makes  sense  with  Inverse  Neighbor
        Discovery  [IND]  messages  if  IND is employed after successful
        establishing of an SVC to gather information  about  other  IPv6
        addresses assigned to the remote node and that SVC.  The "O" bit
        MUST be clear in the Neighbor  Discovery  Advertisement  message
        containing  such  a Link-Layer Address format. This ensures that
        an existing cache entry that maps an IPv6 address  to  an  E.164
        address is not overwritten.


   (b)  E.164 format -- used mostly prior to establishing a new SVC,  to
        get  the Frame Relay remote node identifier (link-layer address)
        mapping  a  certain  IPv6  address.  The  "O"  bit  in  the   ND
        advertisement  message  MAY  be  set  to  1,  in  order to allow
        refreshing a cache entry which maps an IPv6 address to an  E.164
        address.


   The "DLCI format" is defined as follows:






conta & malis & mueller   Expires in six months     [Page 9]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          0  |                      Type                     |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          1  |                     Length                    |
             +-----+-----+-----+-----+-----+-----+-----+-----+

   with a DLCI (Q.922 address) encoded as option value:

              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          2  |                                   |  1  |  1  |
             +              unused               +-----+-----+
          3  |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          4  |            DLCI(high order)       |  0  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          5  |  DLCI(low order)      |  0  |  0  |  0  |  1  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          6  |                                               |
             +                   Padding                     +
          7  |                   (zeros)                     |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                 10 bits DLCI

              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          2  |                                   |  1  |  1  |
             +              unused               +-----+-----+
          3  |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          4  |            DLCI(high order)       |  0  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          5  |  DLCI                 |  0  |  0  |  0  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          6  |             DLCI(low order)             |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          7  |       unused (set to 0)           |  1  |  1  |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                 17 bits DLCI









conta & malis & mueller   Expires in six months    [Page 10]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          2  |                                   |  1  |  1  |
             +              unused               +-----+-----+
          3  |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          4  |            DLCI(high order)       |  0  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----
          5  |  DLCI                 |  0  |  0  |  0  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          6  |             DLCI                        |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          7  |       DLCI (low order)            |  0  |  1  |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                 23 bits DLCI


     Option fields:

        Type        1 for Source Link-layer address.
                    2 for Target Link-layer address.

        Length      1 (in units of 8 octets)

        Link-Layer Address        The DLCI encoded as a Q.922 address.

      Description

        The "DLCI format" option value field has two components:


        (a)  Address Type -- encoded in the first two bits of the  first
             two  octets.  Both  bits  are set to 1 to indicate the DLCI
             format. The rest of the bits in the two  first  octets  are
             not  used  -- they MUST be set to zero on transmit and MUST
             be ignored by the receiver.


        (b)  DLCI -- encoded as a Q.922 address padded with zeros to the
             last  octet  of the 6 octets available for the entire Link-
             Layer Address field of this format.

   The "E.164 format" is defined as follows:







conta & malis & mueller   Expires in six months    [Page 11]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          0  |                      Type                     |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          1  |                     Length                    |
             +-----+-----+-----+-----+-----+-----+-----+-----+

   with an E.164 address encoded as option value:

              7     6     5     4     3     2     1     0      (bit order)
             +-----+-----+-----+-----+-----+-----+-----+-----+
          2  |             size                  |  1  |  0  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          3  |            not-used (zeros)                   |
             +-----+-----+-----+-----+-----+-----+-----+-----+
          4  |                                               |
             /          BCD encoded E.164 number             /
             /                                               /
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
      4+size |                                               |
             +                   Padding                     +
          16 |                   (zeros)                     |
             +-----+-----+-----+-----+-----+-----+-----+-----+


      Option fields:

        Type        1 for Source Link-layer address.
                    2 for Target Link-layer address.

        Length      2 (in units of 8 octets)

        Link-Layer Address       The E.164 address encoded in Binary
                                 Coded Decimal (BCD).

   Description

     The "E.164 format" option value has three components:


     (a)  Address Type -- encoded in the first two bits of the first two
          octets.   The  first bit is set to 0, the second bit is set to
          1.


     (b)  Size -- encoded in the last 6 bits of the  first  two  octets.
          The  maximum  length  is 15. The rest of the bits in the first



conta & malis & mueller   Expires in six months    [Page 12]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


          two octets are not used  --  they  MUST  be  set  to  zero  on
          transmit and MUST be ignored on receive.


     (c)  E.164 address (number) --  encoded  in  BCD  (two  digits  per
          octet). If the E.164 has an even number of digits the encoding
          will fill all encoding octets -- half the number of digits. If
          the E.164 number has an odd number of digits, the lowest order
          digit fills only half of an octet -- it is placed in the first
          4  bits  of the last octet of the E.164 BCD encoding. The rest
          of the field up to the last octet of the 14  octets  available
          is padded with zeros.

   Editor's note: this section will  need  to  also  specify  the  I.121
   address  format  and  possibly  the  NSAP format (work in progress in
   FRF).


7. Sending Neighbor Discovery Messages

   Frame Relay networks do not provide  link-layer  native  multicasting
   mechanisms.  For  the  correct  functioning of the Neighbor Discovery
   mechanisms, link-layer multicasting must be emulated.

   One simple way of emulating multicasting for Neighbor Discovery  (ND)
   is to send frames carrying ND multicast packets to all VCs on a Frame
   Relay interface. This applies to ND messages addressed to  both  all-
   node and solicited-node multicast addresses.


8. Receiving Neighbor Discovery Messages

   The Neighbor Discovery Solicitation messages received by a  node  may
   need  preprocessing before being processed by the ND protocol engine.
   If such a message carries a DLCI  format  Source  link-layer  address
   option,  the  DLCI  value  in  the  Source link-layer address MUST be
   replaced with the appropriate format (see previous sections)  of  the
   DLCI  value  from  the Frame Relay header of the frame containing the
   message. This is required for the correct further  interpretation  of
   the field during the ND protocol engine processing.


9. Security Considerations

   The mechanisms defined in this document for generating an IPv6  Frame
   Relay interface identifier are intended to provide uniqueness at link
   level -- virtual  circuit.  The  protection  against  duplication  is
   achieved by way of IPv6 Stateless Autoconfiguration Duplicate Address



conta & malis & mueller   Expires in six months    [Page 13]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


   Detection mechanisms. Security protection against forgery or accident
   at the level of the mechanisms described here is provided by the IPv6
   security mechanisms applied to Neighbor  Discovery  [ND]  or  Inverse
   Neighbor Discovery [IND] messages.


10.Acknowledgments

   Thanks to D. Harrington, and M. Merhar for reviewing   this  document
   and  providing useful suggestions. Also thanks to G. Armitage for his
   reviewing and suggestions. More [TBD].

11.References

   [IPv6] RFC 1883 S. Deering, R. Hinden, "Internet Protocol  Version  6
   Specification"


   [AARCH]R. Hinden, S. Deering "IPv6 Addressing Architecture"


   [ND] RFC 1970, T. Narten, E. Nordmark, W.Simpson "Neighbor  Discovery
   for IP Version 6 (IPv6)"


   [CONF]  RFC   1971,   S.   Thomson,   T.   Narten   "IPv6   Stateless
   Autoconfiguration"


   [IPv6_NBMA] G. Armitage, P. Schulter, M. York, G. Harter, "IPv6  over
   NBMA networks", 


   [IPv6_ATM] G. Armitage, P. Schulter, M. York, G. Harter,  "IPv6  over
   ATM Networks", 


   [IPv6_ETH] M. Crowford "Transmission of IPv6  packets  over  Ethernet
   Networks", 


   [IPv6_FDDI] M. Crowford  "Transmission  of  IPv6  packets  over  FDDI
   Networks", 


   [IPv6_TR] T. Narten, M. Crowford, M.  Thomas  "Transmission  of  IPv6
   packets   over   Token   Ring   Networks",  



conta & malis & mueller   Expires in six months    [Page 14]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997


   [ENCAPS]C. Brown, A. Malis, "Multiprotocol  Interconnect  over  Frame
   Relay", <draft-ietf-ion-fr-update-03.txt>.


   [IND] A. Conta, A. Malis, "Extensions to IPv6 Neighbor Discovery  for
   Inverse Discovery", <draft-conta-ion-ipv6-ind-00.txt>


   [RFC2119]  S.  Bradner  "Key  words  for  use  in  RFCs  to  indicate
   Requirement Levels", RFC 2119.


   [RFC2200] J. Postel "Assigned Numbers", RFC 2200.


12.Authors' Addresses

   Alex Conta
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742
   +1-978-287-2842
   email: aconta@lucent.com

   Andrew Malis
   Ascend Communications
   1 Robbins Rd
   Westford, MA 01886
   +1-978-952-7414
   email: malis@ascend.com

   Martin Mueller
   Lucent Technologies Inc.
   300 Baker Ave, Suite 100
   Concord, MA 01742
   +1-978-287-2833
   email:  memueller@lucent.com














conta & malis & mueller   Expires in six months    [Page 15]




INTERNET-DRAFT       IPv6 over Frame Relay Networks    November 17, 1997





















































conta & malis & mueller   Expires in six months    [Page 16]

944