home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft__misc / INV_ND.TXT < prev    next >
Text File  |  1997-08-04  |  17KB  |  532 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. IPng Working Group                          A. Conta (Lucent)
  8. INTERNET-DRAFT
  9.                                             July 1997
  10.  
  11.  
  12.         IPv6 Neighbor Discovery Extensions for Inverse Discovery
  13.  
  14.                              Specification
  15.  
  16.                    draft-conta-ipv6-nd_ext_ind-00.txt
  17.  
  18.  
  19. Status of this Memo
  20.  
  21.    This document is an Internet-Draft.  Internet-Drafts are working doc-
  22.    uments of the Internet Engineering Task Force (IETF), its Areas,  and
  23.    its  Working Groups. Note that other groups may also distribute work-
  24.    ing documents as Internet-Drafts.
  25.  
  26.    Internet-Drafts are draft  documents  valid  for  a  maximum  of  six
  27.    months.  Internet-Drafts  may  be  updated, replaced, or obsoleted by
  28.    other documents at any time.  It is not appropriate to  use  Internet
  29.    Drafts as reference material or to cite them other than as a "working
  30.    draft" or "work in progress."
  31.  
  32.    To learn the current status of any Internet-Draft, please  check  the
  33.    ``1id-abstracts.txt''  listing  contained  in  the  Internet-  Drafts
  34.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net  (Europe),
  35.    munnari.oz.au  (Pacific  Rim),  ds.internic.net  (US  East Coast), or
  36.    ftp.isi.edu (US West Coast).
  37.  
  38.    Distribution of this memo is unlimited.
  39.  
  40. Abstract
  41.  
  42.    This memo describes a mechanism that can be seen as an  extension  to
  43.    the  IPv6  Neighbor  Discovery.  It  allows  a node to solicit and be
  44.    advertized an  IPv6  address  corresponding  to  a  given  link-layer
  45.    address.  Because  the known parameter is the link layer address, the
  46.    mechanism is called  Inverse  Neighbor  Discovery.   It  specifically
  47.    applies  to  Frame  Relay  nodes that may have a Data Link Connection
  48.    Identifier  (DLCI),  the  Frame  Relay  equivalent  of  a  link-layer
  49.    address,  associated  with  an  established Permanent Virtual Circuit
  50.    (PVC), but do not know the IPv6 address of the node at the other  end
  51.    of  the  circuit.   It  may also apply to other networks with similar
  52.    behavior.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Conta                   Expires in six months       [Page 1]
  59.  
  60.  
  61.  
  62.  
  63. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  64.  
  65.  
  66. 1. Introduction
  67.  
  68.  
  69.    This document defines an extension mechanism  to  the  IPv6  Neighbor
  70.    Discovery that will allow a node to solicit and be advertised an IPv6
  71.    address corresponding to a  given  link-layer  address.  Because  the
  72.    input  parameter  is  the link layer address, the mechanism is called
  73.    Inverse Neighbor Discovery.
  74.  
  75.    The Inverse Neighbor Discovery (IND) specifically  applies  to  Frame
  76.    Relay  nodes.   Frame  Relay  permanent  virtual  circuits (PVCs) and
  77.    switched virtual circuits (SVCs) are identified by  each  node  in  a
  78.    Frame Relay network through a Data Link Connection Identifier (DLCI).
  79.    Each DLCI defines for a Frame Relay node a single virtual  connection
  80.    through the wide area network (WAN) and is the Frame Relay equivalent
  81.    to a link-layer address.
  82.  
  83.    Through specific  signaling  messages,  a  Frame  Relay  network  may
  84.    announce to a node a new virtual circuit with its corresponding DLCI.
  85.    However, the announcement being made at  link-layer  level  and  com-
  86.    pletely  independent  of  the  IPv6  protocol  does  not include IPv6
  87.    addressing information.  The  node  receiving  such  an  announcement
  88.    learns  about the new connection, and it is able to address the other
  89.    end of the virtual circuit at link layer level, but, a  configuration
  90.    or  mechanism for discovering an IPv6 address of the other end of the
  91.    virtual circuit is necessary.
  92.  
  93.    The IPv6 Inverse Neighbor Discovery (IND) will allow  a  Frame  Relay
  94.    node  to  discover  dynamically  an IPv6 address of a node associated
  95.    with a virtual circuit.  These extensions  can  be  used  with  other
  96.    links that similar to Frame Relay provide destination data link-layer
  97.    addresses without indicating corresponding IPv6 addresses.
  98.  
  99.    The keywords MUST, MUST NOT, MAY, OPTIONAL,   REQUIRED,  RECOMMENDED,
  100.    SHALL,  SHALL  NOT,  SHOULD,  SHOULD  NOT   are  to be interpreted as
  101.    defined in RFC 2119.
  102.  
  103.    There is a good number of similarities but also  differences  between
  104.    the mechanisms described here and those defined for InARP for IPv4 in
  105.    RFC 1293, and the updating "draft-ietf-ion-inarp-update-01.txt".
  106.  
  107. 2. Inverse Neighbor Discovery Messages
  108.  
  109.    The following messages are defined:
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Conta                   Expires in six months       [Page 2]
  118.  
  119.  
  120.  
  121.  
  122. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  123.  
  124.  
  125. 2.1.  Inverse Neighbor Discovery Solicitation Message
  126.  
  127.    Nodes send Inverse Neighbor Discovery  Solicitations  to  request  an
  128.    IPv6 address corresponding to a link-layer address of the target node
  129.    while also providing their own  link-layer  address  to  the  target.
  130.    Inverse  Neighbor Discovery Solicitations are link-layer unicast mes-
  131.    sages, but IPv6 multicasts, since the destination IPv6 address is not
  132.    known.
  133.  
  134.       0                   1                   2                   3
  135.       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
  136.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  137.      |     Type      |     Code      |          Checksum             |
  138.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  139.      |                           Reserved                            |
  140.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  141.      |   Options ...
  142.      +-+-+-+-+-+-+-+-+-+-+-+-
  143.  
  144.  
  145.    IP Fields:
  146.  
  147.       Source Address
  148.                      An  IPv6  address  assigned  to  the interface from
  149.                      which this message is sent.
  150.  
  151.       Destination Address
  152.                      The solicited-node multicast address.  It  contains
  153.                      the 24 bit normalised value of the DLCI.
  154.  
  155.  
  156.       Hop Limit      255
  157.  
  158.       Priority       15
  159.  
  160.       Authentication Header
  161.                      If a Security Association for the IP Authentication
  162.                      Header exists between the sender and  the  destina-
  163.                      tion  link-layer  address,  then  the sender SHOULD
  164.                      include this header.
  165.  
  166.  
  167.    ICMP Fields:
  168.  
  169.       Type           135 or [TBD] if considered as new message
  170.  
  171.       Code           0
  172.  
  173.  
  174.  
  175.  
  176. Conta                   Expires in six months       [Page 3]
  177.  
  178.  
  179.  
  180.  
  181. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  182.  
  183.  
  184.       Checksum       The ICMP checksum.  See [ICMPv6].
  185.  
  186.       Reserved       This field is unused.  It MUST be initialized to
  187.                      zero by the sender  and  MUST  be  ignored  by  the
  188.                      receiver.
  189.  
  190.    Required options:
  191.  
  192.       Source link-layer address
  193.                      The link-layer address of the sender.
  194.  
  195.                      For  Frame  Relay, the sender link-layer address is
  196.                      filled in by the receiver of this message.
  197.  
  198.       Destination link-layer address
  199.                      The link-layer address of the receiver.
  200.  
  201.                      For Frame Relay, both the above  addresses  are  in
  202.                      Q.922  format  (DLCI), which can have 10 (default),
  203.                      17, or 24 significant addressing bits.  The  option
  204.                      length (link-layer address) is expressed in 8 octet
  205.                      units,  therefore,  the  DLCI  will  have   to   be
  206.                      extracted  from  the  8 bytes based on the EA field
  207.                      (bit 0) of the second, third, or forth octet (EA  =
  208.                      1).  The C/R, FECN, BECN, DE fields do not have any
  209.                      significance for IND [IPv6FR].
  210.  
  211.       MTU            The MTU configured for this link (circuit).
  212.  
  213.  
  214.    Future  versions  of  this  protocol  may  add  other  option  types.
  215.    Receivers  MUST silently ignore any options they do not recognize and
  216.    continue processing the message.
  217.  
  218.  
  219.  
  220. 2.2   Inverse Neighbor Discovery Advertisement Message Format
  221.  
  222.    A node sends Inverse Neighbor Discovery Advertisements in response to
  223.    Inverse Neighbor Discovery Solicitations and sends unsolicited Neigh-
  224.    bor Advertisements in order to (unreliably) propagate new information
  225.    quickly.
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Conta                   Expires in six months       [Page 4]
  236.  
  237.  
  238.  
  239.  
  240. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  241.  
  242.  
  243.          0                   1                   2                   3
  244.          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
  245.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  246.         |     Type      |     Code      |          Checksum             |
  247.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  248.         |R|S|O|                     Reserved                            |
  249.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  250.         |                                                               |
  251.         +                                                               +
  252.         |                                                               |
  253.         +                       Target Address                          +
  254.         |                                                               |
  255.         +                                                               +
  256.         |                                                               |
  257.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  258.         |   Options ...
  259.         +-+-+-+-+-+-+-+-+-+-+-+-
  260.  
  261.  
  262.    IP Fields:
  263.  
  264.       Source Address
  265.                      An address assigned to the interface from which the
  266.                      advertisement is sent.
  267.  
  268.       Destination Address
  269.                      For solicited advertisements, the Source Address of an
  270.                      invoking Neighbor Solicitation.
  271.  
  272.                      For unsolicited advertisements typically the all-nodes
  273.                      multicast address.
  274.  
  275.       Hop Limit      255
  276.  
  277.       Priority       15
  278.  
  279.       Authentication Header
  280.                      If a Security Association for the IP Authentication
  281.                      Header exists between the sender and the destination
  282.                      address, then the sender SHOULD include this header.
  283.  
  284.  
  285.    ICMP Fields:
  286.  
  287.       Type           136
  288.  
  289.       Code           0
  290.  
  291.  
  292.  
  293.  
  294. Conta                   Expires in six months       [Page 5]
  295.  
  296.  
  297.  
  298.  
  299. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  300.  
  301.  
  302.       Checksum       The ICMP checksum.  See [ICMPv6].
  303.  
  304.       R              Router flag.  When set, the R-bit indicates that the
  305.                      sender is a router.  The R-bit is used by Neighbor
  306.                      Unreachability Detection to detect a router that
  307.                      changes to a host.
  308.  
  309.       S              Solicited flag.  When set, the S-bit indicates that
  310.                      the advertisement was sent in response to a Neighbor
  311.                      Solicitation from the Destination address.  The S-bit
  312.                      is used as a reachability confirmation for Neighbor
  313.                      Unreachability Detection.  It MUST NOT be set in
  314.                      multicast advertisements or in unsolicited unicast
  315.                      advertisements.
  316.  
  317.    Note  that  a Frame Relay link is a virtual circuit, which if brakes,
  318.    all participants to the circuit receive appropriate link  layer  sig-
  319.    naling, which can be propagated to the  upper layers, including IPv6.
  320.    Consequently, Neighbor Unreachability Detection is a  mechanism  that
  321.    doubles this function of the Frame Relay link, and as such it is less
  322.    useful than in datagram oriented links.
  323.  
  324.       O              Override flag.  When set, the O-bit indicates that
  325.                      the advertisement should override an existing cache
  326.                      entry  and  update  the  cached  link-layer to IPv6
  327.                      address mapping.  When it is not set the advertise-
  328.                      ment will not update a cached link-layer address to
  329.                      IPv6 address  mapping  though  it  will  update  an
  330.                      existing  Neighbor  Cache  entry  for which no IPv6
  331.                      address  is  known.   It  SHOULD  NOT  be  set   in
  332.                      solicited  advertisements for anycast addresses and
  333.                      in solicited proxy advertisements.   It  SHOULD  be
  334.                      set  in other solicited advertisements and in unso-
  335.                      licited advertisements.
  336.  
  337.       Reserved       29-bit unused field.  It MUST be initialized to zero
  338.                      by the sender and MUST be ignored by the receiver.
  339.  
  340.       Target Address
  341.                      For solicited advertisements, the IPv6 address
  342.                      corresponding to the Target Link-Layer  Address  in
  343.                      the  Inverse Neighbor Discover Solicitation message
  344.                      that prompted this  advertisement.   For  an  unso-
  345.                      licited advertisement, the IPv6 address whose link-
  346.                      layer address to IPv6 address mapping has  changed.
  347.                      The Target Address MUST NOT be a multicast address.
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Conta                   Expires in six months       [Page 6]
  354.  
  355.  
  356.  
  357.  
  358. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  359.  
  360.  
  361.    Required options:
  362.  
  363.       Target link-layer address
  364.                      The link-layer address of the target, i.e., the
  365.                      sender of the advertisement [IPV6FR].
  366.  
  367.       Source link-layer address
  368.                      The link-layer address of the source, i.e., the
  369.                      receiver of the advertisement [IPv6FR].
  370.  
  371.       MTU            The MTU configured for this link (circuit).
  372.  
  373.    Future  versions  of  this  protocol  may  add  other  option  types.
  374.    Receivers  MUST silently ignore any options they do not recognize and
  375.    continue processing the message.
  376.  
  377.  
  378. 3. Inverse Neighbor Discovery Conceptual Algorithm
  379.  
  380.    IND operates essentially the same as IPv6 ND with the exception  that
  381.    IND  uses  the  link-layer  address  of the destination node which is
  382.    already known, instead of a link-layer multicast. A  soliciting  node
  383.    formats  an  IND  solicitation message as defined above, encapsulates
  384.    the packet for the specific link-layer and sends it directly  to  the
  385.    target node.
  386.  
  387.    Upon  receiving  an IND solicitation, a Frame Relay node fills in the
  388.    source link-layer address field with the DLCI from  the  frame  link-
  389.    layer  header.  This  is necessary for the correct functioning of the
  390.    Frame Relay  mechanism.   Further  the  receiver  node  may  put  the
  391.    sender's IPv6 address/link-layer address mapping into its ND cache as
  392.    it would for a ND solicitation. However, unlike in the  case  of  ND,
  393.    all IND solicitations are destined and sent to the receiving node.
  394.  
  395.    For every IND solicitation, the receiving node may format in response
  396.    a proper advertisment using the link-layer source and target  address
  397.    pair  as  well as the IPv6 source address from the solicitation. If a
  398.    node is unable or unwilling to advertise, it  ignores  the  solicita-
  399.    tion.
  400.  
  401.    Because  IPv6 nodes may have multiple IPv6 addresses per interface, a
  402.    node responding to an IND solicitation MAY select  the  IPv6  address
  403.    which has the same prefix as the solicitor's node IPv6 address.
  404.  
  405.    When  the  soliciting node receives the IND advertisment, it resolves
  406.    the link-layer address to IPv6 address mapping in the ND cache.
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Conta                   Expires in six months       [Page 7]
  413.  
  414.  
  415.  
  416.  
  417. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  418.  
  419.  
  420.    Note:
  421.  
  422.    Although IND applies to circuit oriented links, like Frame Relay, for
  423.    which  a broken physical connectivity is detected in a timely fashion
  424.    by the link layer, and consequently the change of state is passed  to
  425.    upper  layer  protocols  such  as  IPv6, under certain circumstances,
  426.    information learned via IND may be aged or invalidated, and the  IPv6
  427.    Neighbor Unreachability Detection may be used as an additional mecha-
  428.    nism to refresh the link-layer to IPv6 address mapping.
  429.  
  430.  
  431. 4. Acknowledgments
  432.  
  433.    Thanks to Thomas Narten and Eric Nordmark who spent  time  discussing
  434.    the  idea  of Inverse Neighbor Discovery. Also thanks to Dan Harring-
  435.    ton, Milan Merhar, and Martin Mueller for a thorough reviewing.
  436.  
  437.  
  438.  
  439. 5. Security Considerations
  440.  
  441.    Security issues are not addressed in this memo at this time.
  442.  
  443.  
  444. 6. References
  445.  
  446.    [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci-
  447.    fication"
  448.  
  449.  
  450.    [RFC-1970]  T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for
  451.    IP Version 6 (IPv6)"
  452.  
  453.  
  454.    [RFC-1825] R. Atkinson, "Security Architecture for the Internet  Pro-
  455.    tocol"
  456.  
  457.  
  458.    [RFC-1826] R. Atkinson, "IP Authentication Header"
  459.  
  460.  
  461.    [RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers"
  462.  
  463.  
  464.    [RFC-1293]  T.  Bradley, C. Brown, "Inverse Address Resolution Proto-
  465.    col", 1/1992
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Conta                   Expires in six months       [Page 8]
  472.  
  473.  
  474.  
  475.  
  476. INTERNET-DRAFT      IPv6 Inverse Neighbor Discovery         29 July 1997
  477.  
  478.  
  479. 8. Authors' Addresses
  480.  
  481.  
  482.    Alex Conta
  483.    Lucent Technologies Inc.
  484.    300 Baker Ave, Suite 100
  485.    Concord, MA 01742
  486.    +1-508-287-2842
  487.  
  488.    email: aconta@lucent.com
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530. Conta                   Expires in six months       [Page 9]
  531.  
  532.