Network Working Group                                         Robert Elz
Internet Draft                                   University of Melbourne
Expiration Date: June 1996                                 December 1995


          Identifying Interfaces in IPv6 link-local addresses

                      draft-ietf-ipngwg-iid-00.txt


1. 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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "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).

2. Abstract

   This draft proposes a change to the way that IPv6 link local
   addresses are constructed, so that a node can guarantee that all of
   its link local addresses are unique within the node.  The current
   definition of a link local address, a well known prefix, some number
   of zero bits, and a link specific unique token, ensures that it will
   be unique on the link, which is what is required for communications
   using those addresses over the link, but does not require uniqueness
   of the addresses within a node.  In some cases all of a nodes
   interfaces may share the same link local address.  Even the
   possibility of this means that link local addresses, which may in
   some situations be the only addresses that exist, cannot be used for
   internal definition of interfaces, or other purposes within the node.
   This draft suggests a method by which nodes may overcome this
   problem, by redefining the bits between the prefix and the token to
   be available to be used by the node to cause the addresses to be
   unique.





kre                                                             [Page 1]


Internet Draft        draft-ietf-ipngwg-iid-00.txt         December 1995


3. Introduction

   IPv6 created link local addresses, by which all interfaces could
   always be numbered, regardless of any other addressing which may, or
   may not, be available.  These addresses are only suitable for
   communicating within that link, and are only unique on the link.
   [Addrconf] defines link local addresses, the various IPv6 over foo
   specs define mechanisms for generating link local addresses such that
   they are highly likely to be unique, and [addrconf] defines methods
   for detecting most cases in which this procedure has failed to
   generate unique link local addresses.

   However, nothing, so far, has defined any method for ensuring that
   link local addresses are unique within a node, nor for that matter,
   for justifying that any such uniqueness is useful.  This draft
   attempts to achieve both of those purposes.

   It is intended that this draft serve the purpose of encouraging
   debate and discussion on this issue, and then perhaps cause some
   modifications to published RFCs, or other drafts.  It is not intended
   that this draft ever, itself, be more widely published.  Because of
   this, several terms (eg: "addrconf") are not defined here, and
   assumed to be understood by the reader.  Examination of IPv6 RFCs and
   drafts should provide explanations.

4. Identifying Interfaces

   It is usual for a node with more than one interface to need, from
   time to time, a mechanism to identify a particular interface amongst
   the interfaces available.  Currently, with IPv4, this has been done
   on an ad hoc basis, as IPv4 addresses could not be used.  Not all
   interfaces necessarily posses an IPv4 address.

   However, with IPv6, all (IPv6) interfaces will have a link local
   address.  This address is intended to allow communications over the
   attached links and so is defined to be usable only on that link.

   With a minor modification, the link local address could also serve
   the purpose of identifying interfaces within a node for IPv6.  This
   relies upon all interfaces having a link local address, however this
   is already specified by [addrconf].  It also relies on the link local
   addresses being unique within the node, which is a property they do
   not currently have.

   If this is adopted, link local addresses could become the standard
   method for interface identification for IPv6, eliminating the various
   methods used for IPv4, none of them very satisfactory.




kre                                                             [Page 2]


Internet Draft        draft-ietf-ipngwg-iid-00.txt         December 1995


5. The method.

   A link local address is created by taking a well known prefix
   (FE80::/10) [addrspec] and appending a link dependent unique token in
   the low order bits [addrconf].  The precise method, and means of
   generating the unique token is specified in the various "IP over foo"
   specifications for links of type "foo" [IPv6/Ether, IPv6/FDDI, ...].

   For the purposes of this draft, the current [addrspec] link local
   address shall be considered to be comprised of three fields, the
   prefix, the intermediate-zeroes, and the token.

   This draft proposes inserting a new field between the token and the
   prefix.  That is, the intermediate-zeroes will be split into two
   fields, which we shall call the interface identifier, and the
   discretionary bits.

   The interface identifier will be node defined with the sole purpose
   of disambiguating interfaces within a node if the token required on
   several links happens to be the same.

   The discretionary bits can be used by the node for any purpose, and
   are no longer required to be zero.

   The new interface identifier field will be placed in towards the left
   of the link local address.  This is to guarantee that it can be in
   the same positions for all link types, regardless of the length of
   the token to be appended.  This guarantees that if the interface
   identifier is unique within the node for all interfaces, then the
   generated link local addresses will also be unique within the node
   for all interfaces, regardless of the values of the discretionary
   bits or token.  It also achieves maximal benefit for the "::"
   notational convention by keeping as many zeroes as possible in
   contiguous positions, though implementations are permitted to place
   any value they desire in the discretionary bits.

   It is suggested that the low order 16 bits of the high order 32 bits
   of the link local address be allocated to interface identifier.  This
   allows another 6 bits between the current defined prefix, and the new
   field, which will be reserved for future use, potentially to define a
   different format for link local addresses at some future date.  Using
   high order bits also has ramifications (or more precisely non-
   ramifications) with respect to multicast address selection for
   neighbour discovery, which will be expanded upon below.  The various
   "IP over foo" specifications will be altered to show this field.

   The "addrconf" specification will define the contents of the
   interface identifier field.  This will specify that a node may insert



kre                                                             [Page 3]


Internet Draft        draft-ietf-ipngwg-iid-00.txt         December 1995


   any value in this field that it desires, but that it is intended that
   the field be used to cause all link local addresses assigned to the
   node to be unique.  It will be recommended that nodes use the field
   to hold some interface hardware-specific value (or software-specific,
   for virtual interfaces) which is likely to remain constant over time,
   even if similar interfaces are added or removed.  Thus, this field
   alone will be unique amongst all interfaces to the node, and so is
   sufficient to identify interfaces, regardless of whether or not the
   token varies from one interface to another.

   The discretionary bits may be used by the implementation for any
   purpose.

6. Duplicate address detection

   [Addrconf] specifies that any address generated by a node must be
   tested for uniqueness by being tested by the Duplicate Address
   Detection (DAD) algorithm.

   For link local addresses as originally defined, this amounts to a
   test for uniqueness of the link specific token on the link, as all
   other bits in the address are the same for all nodes.

   [Addrconf] uses this feature to permit DAD to be avoided for
   additional addresses created from the same token on the same link,
   when created in a standard manner - such as that specified for
   stateless autoconfiguration in [addrconf].  Such addresses are formed
   the same way in all nodes on the link, with the token inserted -
   known uniqueness of the token guarantees uniqueness within the same
   scope of the other generated address.  Uniqueness in wider scopes is
   derived from the known properties of the prefix to which the token is
   appended.

   As modified here, performing DAD on the link local address does not
   any longer amount to any uniqueness guarantee of the token, as two
   link local addresses (from different nodes) may have the same token,
   yet differ in interface identifier, or discretionary bits.

   To avoid the extra burden of testing all autonomously configured
   addresses, this drafts specifies than when testing a link local
   address for uniqueness using DAD, the address tested shall be formed
   with the interface identifier and discretionary bits, that is, the
   intermediate-zeroes, set to zero.  This is the same address that was
   previously tested.

   Whenever a node receives a Neighbour Solicitation packet containing a
   target address with prefix FE80::/16 it should consider only those 16
   bits, and the final token bits when comparing the target address



kre                                                             [Page 4]


Internet Draft        draft-ietf-ipngwg-iid-00.txt         December 1995


   requested, and its own link local address for the link, all other
   bits of both the target address sought, and the local link local
   address should be considered to be zero.

   The Neighbour Advertisement returned in response to receiving a
   Neighbour Solicitation containing a target address with prefix
   FE80::/16 should contain the responding node's link local address on
   the link, as the target address, whatever address was actually in the
   Neighbour Solicitation.

   When receiving Neighbour Advertisement packets during the DAD
   process, and the target address therein has a prefix of FE80::/16,
   the node must consider only the prefix, and token when comparing the
   returned target address and the tentative link local address for the
   node.   The intermediate-zeroes bits must, for this purpose, and only
   this purpose, be treated as if they were set to zero in both
   addresses.

   This procedure then returns DAD of the link local address to being a
   uniqueness test of the token on the link, which then allows the token
   to be used to generate other unique addresses without testing those -
   including the link local address as defined here.

   [Discovery] will be updated to include these procedures.

7. Multicast Address Generation

   [Discovery] specifies the algorithm by which the solicited-node
   multicast address is generated.  That uses only the low bits of the
   IPv6 address.  By positioning the interface identifier in the upper
   bits of the link local address, the same solicited-node multicast
   address will be generated, whatever interface identifier is chosen.
   On some media, the token might not be 32 bits wide.  In such cases
   the node may choose to use some of the bits used for multicast
   address generation for other purposes.  This draft strongly
   recommends against this practice, but does not prohibit it.  However,
   nodes must be prepared to receive Neighbour Solicitation packets sent
   to either the node's link local address, or to the address formed
   from the prefix FE80::/16 and the interface token, with zeroes
   between (in the intermediate-zeroes field).  This may mean accepting
   two different multicast addresses where one would ordinarily be
   sufficient.









kre                                                             [Page 5]


Internet Draft        draft-ietf-ipngwg-iid-00.txt         December 1995


8. Rationale

   By guaranteeing that all interfaces have unique addresses within the
   node, the node can use those unique addresses to identify the
   interface, rather than having to invent some new name space for this
   purpose.  Using addresses also allows all the standard tools to be
   used for interface identification, that are used for host
   identification.  Interfaces can be named by Domain Name System names,
   which can be manipulated in the same way as other DNS names, and
   translated by standard routines into the addresses used as interface
   identifiers.

   Because a link local address must exist for all interfaces [addrconf]
   and must always be generated in a standard way, the address is
   effectively available for internal uses instantly the interface is
   made known to the rest of the system - even before DAD is performed.
   This means that no other interface identification is required, the
   unique link local address can be, if the implementation desires, the
   only interface identification provided.  If DAD fails, [addrconf]
   specifies that the interface be shut down, even then the link local
   address will still be unique within the node, and can still be used
   to refer to the inactive interface.

9. Security Considerations

   Addressing and security are unrelated concepts.  Attempts to pretend
   otherwise are misguided.

10. References

   To be supplied: IPv6 spec, IPv6 addressing spec, Addrconf, Neighbour
   Discovery, IPv6 over ethernet, IPv6 over FDDI, etc.

   These are all available as either Internet Drafts or RFCs.

11. Acknowledgements

   My thanks to Matt Crawford for assisting getting this draft into a
   semi-presentable state, which is not to imply that he agrees with the
   proposal.











kre                                                             [Page 6]