One document matched: draft-ietf-ipngwg-iid-01.txt
Differences from draft-ietf-ipngwg-iid-00.txt
Network Working Group Robert Elz
Internet Draft University of Melbourne
Expiration Date: August 1996 February 1996
Identifying Interfaces in IPv6 link-local addresses
draft-ietf-ipngwg-iid-01.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-01.txt February 1996
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, implementations could, if they wanted, use link
local addresses as their standard method for interface identification
for IPv6, eliminating the various methods used for IPv4, often not
very satisfactory.
kre [Page 2]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
Many IPv4 implementations have used the concatenation of a variable
length interface-type string, with a number indicating which
interface of that type this is (eg: "le1", or "fta0"). This has
multiple drawbacks, for coding it means the need to deal with a
different kind of label than the addresses that are used to refer to
interfaces on all other nodes, there is usually no stable number
which can be expected to remain invariant over hardware
reconfigurations (installing a new interface may change the number
assigned to one that was otherwise untouched), and there are usually
no tools available for mapping more user friendly (or stable) names
to these identifiers.
Without this change, using link local addresses to identify
interfaces is not possible, unless an implementation can guarantee,
by some other means, that the tokens used by all interfaces will
differ, always.
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
kre [Page 3]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
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
"IPv6 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
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
kre [Page 4]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
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, for which the size will be determined
by the nature of the link over which the NS is received, when
comparing the target address 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.
Note that as defined here, an implementation that chooses not to make
use of the interface identifier or discretionary bits fields, and
always uses them as intermediate-zeroes as currently defined, need
change its implementation in only one very minor way. Received NS
packets for DAD will contain zeroes in all relevant bits, and thus
will appear as if this specification did not exist. The returned NA
kre [Page 5]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
from the node will contain the interface link local address, just as
now, which will be the address with the intermediate-zeroes field.
Ordinary NS and NA packets directed to and from the node, will
contain the node's link local address, as always, whatever bits it
contains, as would any other packets to or from the node using its
link local address. The one change is that while the node is
performing DAD, if it receives an NA in response to its NS, it must
compare only the prefix, and token fields, as the returned NA may
contain any value in the interface identifier and discretionary bits
fields.
[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 be less than 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.
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
kre [Page 6]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
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.
With all interfaces identified by unique intra-node addresses,
implementations can, if they desire, make use of address fields in
the regular API for interface identification. For example, an
application might make use of source routing via a local interface in
order to direct packets to be transmitted over a specific link -
which would not imply that a routing header would be present in the
packet transmitted if the local address was all it contained, or that
that address would ever be present in a transmitted routing header.
Directing packets through specific interfaces, especially if
unnumbered, has not been easy, or even possible, in many current IP
implementations.
Implementations with multiple tokens available to create link local
addresses have the opportunity to connect multiple interfaces to one
link if that will produce a useful configuration - perhaps to achieve
higher bandwidth through a switch that permits multiple parallel
conversations. An implementation with only a single token would need
to invent a token, which is certainly not to be recommended, survive
with a shared link local address, or modify some other part of the
link local address, presumably using the technique described here.
With unique link local addresses, stateful autoconfiguration could be
used to obtain other addressing, where stateless autoconfiguration
would generate the same addresses for all such interfaces. Without
that, there would be no unique token for DHCP to use to assign
different addresses,
Where the node concerned is participating in routing protocols, such
as OSPF for IPv6, it also seems that having multiple interfaces on
one link sharing the same link local address might be a problem.
(Precise details unavailable...)
kre [Page 7]
Internet Draft draft-ietf-ipngwg-iid-01.txt February 1996
9. Security Considerations
Addressing and security are unrelated concepts. Attempts to pretend
otherwise are misguided.
10. References
[IPv6] "Internet Protocol, Version 6 (IPv6) Specification",
S. Deering, R. Hinden, RFC1883, January 4, 1996.
[Addrspec] "IP Version 6 Addressing Architecture",
R. Hinden, S. Deering, RFC1884, January 4, 1996.
[IPv6/Ether] "A Method for the Transmission of IPv6 Packets over
Ethernet Networks"
Matt Crawford, Work In Progress (soon to be an RFC).
[IPv6/FDDI] "A Method for the Transmission of IPv6 Packets over
FDDI Networks"
Matt Crawford, Work In Progress (soon to be an RFC).
[Discovery] "Neighbor Discovery for IP Version 6 (IPv6)"
Thomas Narten, Erik Nordmark, W A Simpson,
Work In Progress (soon to be an RFC).
[Addrconf] "IPv6 Stateless Address Autoconfiguration"
Susan Thomson, Thomas Narten,
Work In Progress (soon to be an RFC).
[DHCPv6] "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
J. Bound, C. Perkins,
Work In Progress (soon to be an RFC).
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. Also to Dennis Ferguson for pointing out additional
justification for use of a method like this.
kre [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 06:17:31 |