[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02
Network Working Group W A Simpson
Internet Draft Daydreamer
expires in six months October 1994
IPv6 Neighbor Discovery -- Processing
draft-simpson-ipv6-discov-process-00.txt
Status of this Memo
This document is a submission to the IPng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipng@sunroof.eng.sun.com mailing list.
Distribution of this memo is unlimited.
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 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 ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This document discusses the techniques for identification of and
forwarding to adjacent IPv6 nodes, including Next Hop Determination
and Router Discovery.
Simpson expires in six months [Page i]
DRAFT IPv6 Neighbor Discovery October 1994
1. Introduction
This document describes how to process ICMP Neighbor Discovery
messages
- to determine the availability of other IPv6 nodes as demand for
communication occurs;
- to detect the presence of available IPv6 routers;
- to learn the appropriate media address for sending to its
neighbors;
- and to self-configure using the Cluster prefix(es) for the link.
The design requirements are more completely described in [D-sign]. |
The ICMP packet formats are described in [D-form].
2. Sending Datagrams
The IPv6 node chooses the next hop for each datagram sent. If the |
Destination can be readily determined to be on an attached link, the |
datagram is sent directly to the Destination. Otherwise, it is sent
to a router.
2.1. Constants
GENERAL_SOLICITATION_INTERVAL 3 seconds
2.2. Hop Cache |
To efficiently send a series of datagrams to the same Destination, |
each node MUST keep a cache of prior decisions, indexed by |
Destination. The node uses the following basic algorithm on this |
cache to send a datagram:
(a) If the cache contains no information for a particular |
Destination, a determination is made where to send the
datagram. This is described in the "Next Hop Decision" section
which follows. |
(b) When the cache contains information for a particular |
Simpson expires in six months [Page 1]
DRAFT IPv6 Neighbor Discovery October 1994
Destination, the cache entry might point directly to the |
Destination, or to a router which handles the Destination.
(c) The cache entry contains the media address to be used to send |
the datagram. It also contains other information which records |
previous experience related to the Destination. |
(d) When the Destination is determined to be accessible through a |
router, the cache entry for the router is used to send the
datagram. The router cache entry might be duplicated in the |
Hop Cache, or a system of pointers could be used. In any case, |
the Hop Cache entry for the Destination MUST have the same |
LifeTime as the cache entry for the router. *
Each Hop Cache entry needs to include the following items: |
(1) LifeTime
(2) Next-hop interface (when a node is multi-homed)
(3) Next-hop media address
(4) Destination IPv6 Address
(5) Destination Cluster-prefix size
(6) Source IPv6 Address |
(7) Flow Label
(8) Path Maximum Transmission Unit |
(9) Path Round Trip Time |
While scanning or making changes to the Hop Cache entries, whenever |
the LifeTime expires in any entry that was created as a result of a
received advertisement, that entry is discarded.
Field (4) MAY be the full IPv6 Address of the Destination, or the |
Cluster which includes the Destination. This is determined by the
Cluster-prefix size in (5).
Field (7) SHOULD be included, as it is related to the Source in (6). |
DISCUSSION:
Each Hop Cache entry defines the end-points of an internetwork |
path. Although the connecting path may change dynamically in an
arbitrary way, the transmission characteristics of the path tend
to remain approximately constant over a time period longer than a
single typical host-host transport connection. Therefore, a Hop |
Cache entry is a natural place to cache data on the properties of
the path.
Examples of such properties might be the maximum unfragmented
datagram size, or the average round-trip delay measured by a
transport protocol. This data will generally be both gathered and
Simpson expires in six months [Page 2]
DRAFT IPv6 Neighbor Discovery October 1994
used by a higher layer protocol (that is, by TCP or by an
application using UDP). Experiments are currently in progress on
caching path properties in this manner.
There is no consensus on whether the Hop Cache should be keyed on |
destinations alone, or allow both node and Cluster addresses.
Those who favor the use of only node identifiers argue that:
(1) Redirect messages will generally result in entries keyed on
nodes. The simplest and most general scheme would be to
only use node identifiers.
(2) The internetwork layer may not always know the prefix-size
for a Cluster address in a complex environment.
(3) The use of only node identifiers may allow the Internet
architecture to be more easily extended in the future
without any change to the hosts.
The opposing view is that allowing a mixture of destination nodes |
and clusters in the Hop Cache:
(1) Saves memory space.
(2) Leads to a simpler data structure, easily combining the
cache with the tables of default and static routes.
(3) Provides a more useful place to cache path properties.
IMPLEMENTATION:
The cache needs to be large enough to include entries for the
maximum number of destinations that may be in use at one time.
A Hop Cache entry may also include control information used to |
choose an entry for replacement. This might take the form of a
"recently used" bit, a use count, or a last-used timestamp, for
example. It is recommended that it include the time of last
modification of the entry, for diagnostic purposes.
An implementation may wish to reduce the overhead of scanning |
the Hop Cache for every datagram to be transmitted. This may
be accomplished with a hash table to speed the lookup, or by
giving a connection-oriented transport protocol a "hint", or
temporary handle on the appropriate cache entry, to be passed
to the IP layer with each subsequent datagram.
A static route is typically a particular preset mapping for |
Destination or Cluster into a particular next-hop router. It
Simpson expires in six months [Page 3]
DRAFT IPv6 Neighbor Discovery October 1994
might also depend on the Type-of-Service. Static routes would
be setup by system administrators to override the normal
automatic routing mechanism, and handle exceptional situations.
However, any static routing information is a potential source
of failure as configurations change or equipment fails.
Although the Hop Cache, the lists of default routers, and a |
table of static routes are described as conceptually distinct,
in practice they may be combined into a single "routing table"
data structure.
2.3. Next Hop Decision
To decide if the destination is on an attached link, the following
algorithm MUST be used:
(a) For a multicast destination, simply pass the datagram to the
link-layer for any indicated interface(s).
(b) If no Router Advertisements have been heard, then the |
Destination is assumed to be on an attached link. For each |
interface, the Destination is located as described in the
"Media Address Determination" section which follows.
(c) If one or more Router Advertisements have been heard, the |
Routing-Information extension Cluster-bit indicates whether the |
Cluster-prefix is confined to a single link. The Destination |
is compared against the advertised Cluster-prefix. When there |
is an exact match, then the Destination is assumed to be on |
that specific link. The Destination is located as described in |
the "Media Address Determination" section which follows. |
(d) If one or more Router Advertisements have been heard, but the |
Cluster-bit is not set, or the Destination does not exactly |
match the advertised Cluster-prefixes, then the datagram is
sent to a single preferred router, as described in the "Router
Selection" section which follows. |
(e) For a multi-homed node, when one or more Router Advertisements
have been heard on some interfaces, but no Router
Advertisements have been heard on other interfaces, the |
datagram is duplicated, and sent to both the preferred router |
and all those interfaces without routers for which a peer |
entity is unknown. |
This allows a node to continue operation in the presence of
Simpson expires in six months [Page 4]
DRAFT IPv6 Neighbor Discovery October 1994
private or partitioned links. The correct interface will be
learned through the advertisements of the target node.
Every host MUST operate correctly in a minimal environment. For
example, if the host insists on finding at least one router to
initialize, the host will be unable to operate on an isolated link.
2.4. Media Address Determination
When the media address for a destination is unknown, the following
procedure is used:
(a) If the interface has no broadcast capability (a point-to-point |
link), and the peer entity is unknown, the datagram is sent on
that interface. No media address is needed. |
(b) If a virtual interface has no broadcast capability (a Frame-
Relay or X.25 link), the datagram is duplicated on each virtual
circuit for which there is no known peer entity, as if they
were each a separate point-to-point interface on a multi-homed
node. The media address used is determined by the virtual |
circuit setup. |
(c) If an interface has no multicast capability, the datagram is
sent as a link-layer broadcast. Note that the IPv6 Destination
is unchanged. |
(d) For an interface with multicast capability, the datagram is
sent as a link-layer multicast. Note that the IPv6 Destination
is unchanged.
The link-layer multicast address used is the exclusive-or of
every octet of the IPv6 Destination, added to the base
Solicited-Nodes multicast. This distributes the processing
load among 1/256 of the nodes, even when the nodes are not
attached to a prefix routed link. |
When there is no entry in the Hop Cache, a General Solicitation is |
sent immediately following the datagram, utilizing the same IPv6 |
Destination as the datagram. The same link-layer addressing rules of |
(a) to (d) apply. A Hop Cache entry is added with a LifeTime of |
GENERAL_SOLICITATION_INTERVAL, to inhibit sending of repeated |
solicitations. |
When there is already an entry in the Hop Cache for an unknown media
address, no further solicitations are sent until the cache entry
Simpson expires in six months [Page 5]
DRAFT IPv6 Neighbor Discovery October 1994
expires. |
On receipt of a unicast datagram from a unicast, broadcast or
multicast media address, if the IPv6 Destination does not match any
IPv6 IPv6 Address of the node, the datagram is silently discarded.
On receipt of a General Solicitation, the target node sends a General
Advertisement.
On receipt of a General Advertisement, all nodes which have a Hop |
Cache entry for the Source update the cache entry with the current
LifeTime and Media Address, and any other pertinent field values
implemented.
2.5. Router Selection
To decide which router to send a datagram, the following procedure is
used:
(a) Cluster-prefixes are learned from the Routing-Information
extension of Router Advertisements. The prefix-size is the
number of valid bits in the Cluster-prefix.
(b) The Source field of the datagram is compared to the list of |
Cluster-prefixes in the Router List.
(c) If a Cluster-prefix exactly matches the Source prefix extracted
by the same prefix-size, then that router is one of the
preferred routers for that Source. The node selects the
highest preference value of those matching routers.
(d) If there are no matching Cluster-prefixes, then there is no
preferred router for the Source. The node selects the highest
preference value among all routers.
(e) If that router is not the best next-hop to the Destination, |
that router will forward the datagram to the best next-hop, and |
return a Local Redirect message to the sending node.
(f) When the sending node receives a Local Redirect, it updates the |
next-hop in the appropriate Hop Cache entry, so that later |
datagrams to the same Destination will go directly to the best
next-hop.
Since the Cluster-prefix appropriate to the Destination address is
generally not known, a Network Redirect message SHOULD be treated
Simpson expires in six months [Page 6]
DRAFT IPv6 Neighbor Discovery October 1994
identically to a Host Redirect message. That is, the cache entry for
the Destination (only) would be updated (or created when an entry for
that node did not exist) for the new router.
DISCUSSION:
This recommendation is to protect against routers that erroneously
send Network Redirects for a prefix routed link, in violation of
the router requirements. (Do we still have the Network
Redirect???)
2.6. Dead Node Detection
The internetwork-layer MUST be able to detect the failure of a node |
that is listed in its Hop Cache.
Each cache entry has a LifeTime, which is obtained through the
Solicitation and Advertisement messages. When an entry expires, the |
routing availability of the Destination MUST be redetermined as if no
prior entry had existed.
Negative "advice" from other layers, such as excessive
retransmissions by a transport-layer protocol, or a down indication
from a link-layer, SHOULD be used to invalidate a cache entry.
Positive "advice" from other layers MUST NOT extend the LifeTime of a
cache entry.
ICMP Echo "pings" MUST NOT be used to actively check a cache entry.
Simpson expires in six months [Page 7]
DRAFT IPv6 Neighbor Discovery October 1994
3. Router Solicitation
Every IPv6 node MUST implement Router Solicitation.
When any node starts up, it MUST send the Router Solicitation to
prompt the advertisement of neighboring routers.
If (and only if) no advertisements from neighboring routers are
forthcoming, the node MAY retransmit the Router Solicitation a small
number of times, but then MUST desist from sending more
solicitations.
Any routers that subsequently start up, or that were not discovered
because of packet loss or temporary link partitioning, are eventually
discovered by reception of their periodic (unsolicited)
advertisements. Links that suffer high packet loss rates or frequent
partitioning are accommodated by increasing the rate of router
advertisements, rather than increasing the number of solicitations
that hosts are permitted to send.
3.1. Constants
MAX_SOLICITATIONS 3 transmissions
MAX_SOLICITATION_DELAY 1 second
ROUTER_SOLICITATION_INTERVAL 3 seconds
3.2. Implementation Details
A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages
from any of its interfaces after any of the following events:
- The interface is initialized at system startup time.
- The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management.
- A router has its forwarding capability turned off by system
management.
If a node chooses to send a solicitation after one of the above
events, it should delay transmission for a random amount of time
between 0 and MAX_SOLICITATION_DELAY. This serves to alleviate
Simpson expires in six months [Page 8]
DRAFT IPv6 Neighbor Discovery October 1994
congestion when many nodes start up on a link at the same time, such
as might happen after recovery from a power failure.
It is recommended that nodes include some unique value (such as one
of their interface or link-layer identifiers or addresses) in the
seed used to initialize their pseudo-random number generators.
Although the randomization range is specified in units of seconds,
the actual randomly-chosen value should not be in units of whole
seconds, but rather in units of the highest available timer
resolution.
The small number of retransmissions of a solicitation, which are
permitted if no advertisement is received, should be sent at
intervals of ROUTER_SOLICITATION_INTERVAL seconds without further
randomization.
Upon receiving a valid Router Advertisement subsequent to one of the
above events, the node MUST NOT send any solicitation on that
interface (even if no solicitation has been sent yet) until the next
time one of the above events occurs.
3.3. Validity Check
A non-router MUST silently discard any received Router Solicitation
messages.
A router MUST silently discard any received Router Solicitation
messages that do not satisfy the following validity checks:
- Version number is correct.
- ICMP Checksum is correct.
- ICMP length (derived from the payload length) is 16 or more
octets.
- For interfaces which are not point-to-point links, the Media-
Access extension MUST be present.
The IPv6 Source may have any unicast value, including Unknown (zero).
If the IPv6 Source does not match one of the router's own IPv6
Addresses on the arrival interface, under the Cluster-prefix
associated with that IPv6 Address, the sender may be considered a
Mobile Node. The location of every reachable Mobile Node is
maintained separately within the router.
Simpson expires in six months [Page 9]
DRAFT IPv6 Neighbor Discovery October 1994
4. Sending Router Advertisements
Every IPv6 router MUST implement Router Advertisements.
The router advertisements include such important information as a
Media Address for the router, other Cluster-prefixes directly
accessible through the router, and neighboring routers heard.
Identification
Each router advertisement includes one or more IPv6 Address
fields. These indicate the IPv6 Addresses which are presently in
use for the router.
Prefix Size
Each advertised IPv6 Address has an associated prefix-size. The
value ranges from 0 to 126, and indicates the number of bits in
the Identifier which define the Cluster-prefix for the link. A
value of zero indicates an end-point IPv6 Address. When the value
is not zero, the IPv6 Address may be used to discern Cluster-
prefix mapping.
If all advertised prefix-size values are zero, then prefix routing
is not in use on that link.
Preference
Each advertised IPv6 Address has an associated preference. This
is used by a host to choose a default router for the first-hop,
when the host has not yet been redirected or configured to use a
specific router for a particular Destination. |
The host is expected to choose from those routers that have the
highest preference level for the best Cluster-prefix match. When
there is no match, or prefix routing is not in use, the preference
value is used alone.
An administrator can configure router preference levels to
encourage or discourage the use of particular routers as the
default first-hop. The use of separate preferences per Cluster-
prefix allows the choice of different routers for each prefix,
when there are multiple prefixes in use for the same link. This
may be useful where multiple organizations share resources.
The preference value is not the same as the "metric" used in many
routing protocols. It is used only by hosts in determining the
default first-hop, rather than by routers in choosing a link for
Simpson expires in six months [Page 10]
DRAFT IPv6 Neighbor Discovery October 1994
transit traffic. The values are not additive. The range of
values is smaller, and a higher value indicates a higher
preference.
It should be understood that preference levels learned from router
advertisements do not affect any node's cached route entries. For
example, if a node has been redirected to use a particular router |
to reach a specific Destination, it continues to use that router |
for that Destination, even if it discovers another router with a
higher preference level. Preference levels influence the choice
of router only for a Destination for which there is no cached or |
configured route, or whose cached route points to a router that is
subsequently determined to be unreachable.
4.1. Constants
MAX_INITIAL_ADVERTISEMENTS 3 transmissions
MAX_INITIAL_ADVERT_INTERVAL 16 seconds
MAX_RESPONSE_DELAY 2 seconds
4.2. Configuration
A router MUST allow the following variables to be configured by
system management. Default values are specified which make it
unnecessary to re-configure these variables in most cases.
For each interface:
MaxAdvertisementInterval
The maximum time (in seconds) allowed between sending router
advertisements from the interface. Must be no less than 4 seconds
and no greater than 1800 seconds.
Default: 600 seconds
MinAdvertisementInterval
The minimum time (in seconds) allowed between sending unsolicited
router advertisements from the interface. Must be no less than 1
second and no greater than MaxAdvertisementInterval.
Simpson expires in six months [Page 11]
DRAFT IPv6 Neighbor Discovery October 1994
Default: 0.75 * MaxAdvertisementInterval
AdvertisementLifetime
The value (in seconds) to be placed in the Lifetime field of
router advertisements sent from the interface. Must be no less
than MaxAdvertisementInterval and no greater than 9000 seconds.
Default: 3 * MaxAdvertisementInterval
For each of the IPv6 Addresses of each interface:
Advertise
A flag indicating whether or not the IPv6 Address is to be
advertised.
Default: TRUE
PreferenceLevel
The preferability of the interface as a default router choice,
relative to other router interfaces serving the same Cluster-
prefix on the same link.
Values are in the range 0 to 255. Higher values mean more
preferable. The minimum value zero is reserved to indicate that
the IPv6 Address, even though it may be advertised, is not to be
used by neighboring hosts as a default router address. The
maximum value 255 is reserved to indicate that the preference was
locally configured, and not learned through advertisments.
Default: 128
It is useful to configure an IPv6 Address with a preference level of
zero (rather than simply setting its Advertise flag to FALSE) when
advertisements are being used for "black hole" detection. In
particular, a router that is to be used to reach only specific
destinations could advertise a preference level of zero (so that
neighboring hosts will not use it as a default router for reaching
arbitrary destinations) and a non-zero lifetime (so that neighboring
hosts that have been redirected or configured to use it can detect
its failure by timing out the reception of its advertisements).
DISCUSSION:
It has been suggested that, when the preference level of an IPv6
Simpson expires in six months [Page 12]
DRAFT IPv6 Neighbor Discovery October 1994
Address has not been explicitly configured, a router could set it
according to the metric of the router's "default route" (if it has
one), rather than defaulting as suggested above. Thus, a router
with a better metric for its default route would advertise a
higher preference level for its IPv6 Address. (Note that routing
metrics that are encoded such that "lower is better" would have to
be inverted before being used as preference levels in router
advertisement messages.) Such a strategy might reduce the amount
of redirect traffic on some links by making it more likely that
the host's first choice for reaching an arbitrary destination is
also the best choice.
On the other hand, redirect traffic is rarely a significant load
on a link, and there are some cases where such a strategy would
result in more redirect traffic (on links from which the most
frequently chosen destinations are best reached via routers other
than the one with the best default route). Also, since the
routing algorithms learn of neighboring routers from the
advertisements, and the default routes are learned from the
routing algorithms, the calculated preference may be unstable from
time to time. This document makes no recommendation concerning
this issue, and implementors are free to try such a strategy, as
long as they also support static configuration of preference
levels as specified above.
4.3. Implementation Details
The term "advertising interface" refers to any functioning and
enabled interface that has at least one IPv6 Address whose configured
Advertise flag is TRUE.
From each advertising interface, the router MUST transmit periodic
Advertisements.
CONTROVERSIAL:
A router MAY proxy for the identifers of other nodes, using the
Other-Identifier extension. This SHOULD only be used when the
router is translating to another internetwork protocol format.
The advertisements are not strictly periodic. The interval between
subsequent transmissions is randomized to reduce the probability of
synchronization with the advertisements from other routers on the
same link. This is done by maintaining a separate transmission
interval timer for each advertising interface. Each time an
advertisement is sent from an interface, that interface's timer is
Simpson expires in six months [Page 13]
DRAFT IPv6 Neighbor Discovery October 1994
reset to a uniformly-distributed random value between the configured
MinAdvertisementInterval and MaxAdvertisementInterval. Expiration of
the timer causes the next advertisement to be sent, and a new random
value to be chosen.
It is recommended that routers include some unique value (such as one
of their interface or link-layer addresses) in the seed used to
initialize their pseudo-random number generators. Although the
randomization range is configured in units of seconds, the actual
randomly-chosen values should not be in units of whole seconds, but
rather in units of the highest available timer resolution.
For the first few advertisements sent from an interface (up to
MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for
the initial advertisements increases the likelihood of a router being
discovered quickly when it first becomes available, in the presence
of possible packet loss.
An interface may become an advertising interface at times other than
system startup, as a result of recovery from an interface failure or
through actions of system management such as:
- enabling the interface, if it had been administratively disabled
and it has one or more IPv6 Addresses whose Advertise flag is
TRUE,
- enabling IPv6 forwarding capability (changing the node from a host
to a router), when the interface has one or more IPv6 Addresses
whose Advertise flag is TRUE,
- setting the Advertise flag of one or more of the interface's IPv6
Addresses to TRUE (or adding a new IPv6 Address with a TRUE
Advertise flag), when previously the interface had no IPv6 Address
whose Advertise flag was TRUE.
In such cases, the router must commence transmission of periodic
advertisements on the new advertising interface, limiting the first
few advertisements to intervals no greater than
MAX_INITIAL_ADVERT_INTERVAL. In the case of a host becoming a
router, the node must also join the all-routers multicast group on
all interfaces on which the router supports multicast (whether or not
they are advertising interfaces).
An interface MAY also cease to be an advertising interface, through
actions of system management such as:
Simpson expires in six months [Page 14]
DRAFT IPv6 Neighbor Discovery October 1994
- shutting down the node,
- administratively disabling the interface,
- disabling IPv6 forwarding capability (changing the node from a
router to a host),
- setting the Advertise flags of all of the interface's IPv6
Addresses to FALSE.
In such cases, the router MUST transmit a final multicast
advertisement on the interface, identical to its previous
transmission, but with a Lifetime field of zero. In the case of a
router becoming a host, the node must also depart from the all-
routers multicast group on all interfaces on which the router
supports multicast (whether or not they had been advertising
interfaces).
When the Advertise flag of one or more of an interface's IPv6
Addresses are set to FALSE by system management, but there remain
other IPv6 Addresses on that interface whose Advertise flags are
TRUE, the router SHOULD send a single multicast advertisement
containing only those IPv6 Addresses whose Advertise flags were set
to FALSE, with a Lifetime field of zero.
In addition to the periodic unsolicited advertisements, a router MUST
send advertisements in response to valid Router Advertisements or
Router Solicitations received on any of its advertising interfaces.
If the advertisement or solicitation does not contain any System-
Heard extension, and the time since the previous advertisement is
greater than MAX_INITIAL_ADVERT_INTERVAL, the router MUST multicast
an advertisement from that interface.
Whenever these response advertisements are sent, the advertisement
MUST be delayed for a small random interval not greater than
MAX_RESPONSE_DELAY, in order to prevent synchronization with other
responding routers, and to allow multiple closely-spaced
solicitations to be answered with a single advertisement. The
interface's interval timer is reset to a new random value, as with
unsolicited advertisements.
4.4. Validity Check
All nodes MUST silently discard any received Router Advertisement
messages that do not satisfy the following validity checks:
Simpson expires in six months [Page 15]
DRAFT IPv6 Neighbor Discovery October 1994
- Version is correct.
- ICMP Checksum is correct.
- ICMP length (derived from the payload length) is 16 or more
octets.
- At least one Routing-Information extension MUST be present.
- For interfaces which are not point-to-point links, the Media-
Access extension MUST be present.
Simpson expires in six months [Page 16]
DRAFT IPv6 Neighbor Discovery October 1994
5. Processing Router Advertisements
Each router saves the information contained in the advertisements, in
order to respond to future requests. Any other action on receipt of
such messages by a router (for example, as part of a "peer discovery"
process) is beyond the scope of this document.
Each host saves the information contained in the advertisements, in
order to determine the next-hop when sending datagrams. Hop
determination is elaborated in the "Sending Datagrams" chapter.
5.1. Configuration
5.1.1. Router List
Host Requirements -- Communication Layers [1], Section 3.3.1.6,
specifies that each host must support a configurable list of default
routers. The purpose of the Router Advertisement messages is to
eliminate the need to configure that list.
Each entry in the list contains (at least) the following configurable
variables:
RouterAddress
An IPv6 Address of a default router.
Default: (none)
Prefix Size
Each router entry has an associated prefix-size. The value ranges
from 0 to 126, and indicates the number of bits in the IPv6
Address which define the Cluster-prefix for the link. A value of
zero indicates an end-point IPv6 Address. When the value is not
zero, the IPv6 Address may be used to discern Cluster-prefix
mapping.
If all associated prefix-size values are zero, then prefix routing
is not in use on that link.
Default: 0
PreferenceLevel
The preferability of the RouterAddress as a default router choice,
Simpson expires in six months [Page 17]
DRAFT IPv6 Neighbor Discovery October 1994
relative to other router interfaces serving the same Cluster-
prefix on the same link. Host Requirements does not specify how
this value is to be encoded.
The values used here are defined as in Router Advertisements.
Values are in the range 0 to 255. Higher values mean more
preferable. The minimum value zero is reserved to indicate that
the IPv6 Address, even though it may be advertised, is not to be
used by neighboring hosts as a default router address. The
maximum value 255 is reserved to indicate that the preference was
locally configured, and not learned through advertisments.
Default: 255
Default routers and preference levels SHOULD NOT be configured
manually. On links for which router discovery is administratively
disabled, it MAY continue to be necessary to configure the default |
Router List in each host.
5.1.2. Address List
Each node requires at least one IPv6 Address.
Each IPv6 Address is bound to zero or more interfaces.
Each entry in the list contains (at least) the following configurable
variables:
IPv6 Address
The IPv6 Address which is presently in use for the node.
Default: None
Prefix Size
Each IPv6 Address entry bound to a link interface has an
associated prefix-size. The value ranges from 0 to 126, and
indicates the number of bits in the IPv6 Address which define the
Cluster-prefix for the link. A value of zero indicates an end-
point IPv6 Address. When the value is not zero, the IPv6 Address
may be used to discern Cluster-prefix mapping.
If all associated prefix-size values are zero, then prefix routing
is not in use on that link.
Simpson expires in six months [Page 18]
DRAFT IPv6 Neighbor Discovery October 1994
Default: 0
LifeTime
The value (in seconds) for the time that the IPv6 Address is
associated with an interface.
Default: 0
The Cluster-prefix(es) for a host interface SHOULD NOT be configured
manually.
The Cluster-prefix(es) for a router interface SHOULD be configured
manually, until such time in the future that an automatic algorithm
is developed.
5.2. Implementation Details
To process an Router Advertisement, the node scans the list of
extensions in it.
5.2.1. Media-Access
If a Media-Access extension is present, the Router List is updated |
with the information. The Media-Access extension MAY appear anywhere
in the list of extensions, but is most likely at the beginning or
end.
5.2.2. Change-Identifier
Change-Identifier extensions MUST preceed Routing-Information
extensions.
- If the prefix-size is zero, the IPv6 Address indicates the change
of a single node, without affecting other nodes on that link.
- If the prefix-size is not zero, the IPv6 Address indicates the
change of Cluster-prefix for all nodes on that link.
- The IPv6 Address and prefix-size are compared against any IPv6
Addresses defined for the node. If there is a match, a new IPv6
Address is associated with the node.
Simpson expires in six months [Page 19]
DRAFT IPv6 Neighbor Discovery October 1994
- If the new IPv6 Address is not already present in the receiving
interface list, a new entry is added to the list, containing the
IPv6 Address, prefix-size, and the Lifetime value from the
advertisement.
- If the new IPv6 Address is already present in the receiving
interface list as a result of a previously-received advertisement,
its LifeTime is reset to the value in the newly-received
advertisement.
- If the new IPv6 Address is already present in the receiving
interface list as a result of static configuration, no change is
made. There is no LifeTime associated with a configured IPv6
Address.
The node MUST continue to accept datagrams destined for the old
IPv6 Address, until such time as all stimulus for maintaining the
old IPv6 Address has expired. This implies that the node will
maintain a LifeTime for most sources of IPv6 Addresses, such as
DNS records and dynamic configuration.
5.2.3. Routing-Information
Routing-Information extensions MUST preceed Other-Identifier
extensions.
- If the prefix-size is not zero, the IPv6 Address and prefix-size
are compared against any IPv6 Addresses defined for the node. If
there is a match, the IPv6 Address is associated with the
interface on which the message was received, and the prefix-size
is set to the advertised prefix-size.
- If the IPv6 Address is not already present in the Router List, a |
new entry is added to the list, containing the IPv6 Address along
with its accompanying preference level, and the Lifetime value
from the advertisement.
- If the IPv6 Address is already present in the Router List as a |
result of a previously-received advertisement, its preference
level is updated and its LifeTime is reset to the value in the
newly-received advertisement.
- If the IPv6 Address is already present in the Router List as a |
result of static configuration, no change is made to its
preference level. There is no LifeTime associated with a
configured IPv6 Address.
Simpson expires in six months [Page 20]
DRAFT IPv6 Neighbor Discovery October 1994
Note that any router IPv4 Address acquired from the "Gateway"
subfield of the vendor extensions field of a BOOTP packet [11]
are considered to be configured; they are assigned the default
preference level of 255, and they do not have an associated
LifeTime.
Note further that any IPv6 Address found in the "giaddr" field
of a BOOTP packet [3] identifies a BOOTP forwarder which is not
necessarily a IPv6 router; such an IPv6 Address should not be
installed in the default Router List. |
To limit the storage needed for the default Router List, the host |
MAY choose not to store all of the router IPv6 Addresses
discovered via advertisements. The host SHOULD discard those IPv6
Addresses with lower preference levels in favor of those with
higher levels.
It is desirable to retain more than one default router in the
list; if the current choice of default router is discovered to be
down, the host may immediately choose another default router
without having to wait for the next advertisement to arrive.
Any router IPv6 Address advertised with a preference level of zero
is not to be used by the host as default router IPv6 Address. |
Such an IPv6 Address may be omitted from the default Router List,
unless its LifeTime is being used as a "black-hole" detection
mechanism.
5.2.4. Other-Identifier
The Other-Identifier extension is used to indicate IPv6 Addresses
which have no effect on the interface Cluster-prefix.
- If the IPv6 Address is not already present in the Router List, a |
new entry is added to the list, containing the IPv6 Address, the
preference level set to zero, and the Lifetime value from the
advertisement.
- If the IPv6 Address is already present in the Router List as a |
result of a previously-received advertisement, and its preference
level is zero, its LifeTime is reset to the value in the newly-
received advertisement.
- If the IPv6 Address is already present in the Router List as a |
result of static configuration, no change is made to its
preference level. There is no LifeTime associated with a
Simpson expires in six months [Page 21]
DRAFT IPv6 Neighbor Discovery October 1994
configured IPv6 Address.
To limit the storage needed for the default Router List, the host |
MAY choose not to store all of the other IPv6 Addresses discovered
via advertisements. The most preferred router is used for unknown
IPv6 Addresses, and it will send a redirect when appropriate.
5.2.5. System-Heard
The use of the System-Heard extension is described in a future Mobile
Discovery document.
Simpson expires in six months [Page 22]
DRAFT IPv6 Neighbor Discovery October 1994
A. Configuration Summary
Routers
A router requires at least one IPv6 Address to be configured.
For each interface, a prefix-size is assigned to each IPv6
Address, unless automatic prefix discovery is in place.
Note that this procedure minimizes the number of items to be
configured, and possible configuration errors.
Optionally, other values MAY be altered from their defaults, such
as preference and advertisement lifetime.
Optionally, routing protocols MAY require additional values to be
configured, such as metric and priority. Such functions are
beyond the scope of this document.
Hosts
Most hosts need no prior configuration.
A node attached to a multi-access media creates a local-use
unicast address from the media address.
A node attached to a point-to-point media (using the Point-to-
Point Protocol [RFC-1661]) can be dynamically assigned either a
global or local unicast address.
Other nodes require configuration of an IPv6 Address, as described
in the section "Address List".
When a router is present, a local-use unicast address MAY be
combined with a Cluster address learned from Router Advertisements
to form a routable IPv6 Address.
Simpson expires in six months [Page 23]
DRAFT IPv6 Neighbor Discovery October 1994
Security Considerations
Security issues are not discussed in this memo.
Acknowledgements
The document was initially composed of quotations from the RFC-1122
"Requirements for Internet Hosts -- Communication Layers", and RFC-
1256 "ICMP Router Discovery Messages".
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
Simpson expires in six months [Page 24]
DRAFT IPv6 Neighbor Discovery October 1994
Table of Contents
1. Introduction .......................................... 1
2. Sending Datagrams ..................................... 1
2.1 Constants ....................................... 1
2.2 Hop Cache ....................................... 1
2.3 Next Hop Decision ............................... 4
2.4 Media Address Determination ..................... 5
2.5 Router Selection ................................ 6
2.6 Dead Node Detection ............................. 7
3. Router Solicitation ................................... 8
3.1 Constants ....................................... 8
3.2 Implementation Details .......................... 8
3.3 Validity Check .................................. 9
4. Sending Router Advertisements ......................... 10
4.1 Constants ....................................... 11
4.2 Configuration ................................... 11
4.3 Implementation Details .......................... 13
4.4 Validity Check .................................. 15
5. Processing Router Advertisements ...................... 17
5.1 Configuration ................................... 17
5.1.1 Router List ..................................... 17
5.1.2 Address List .................................... 18
5.2 Implementation Details .......................... 19
5.2.1 Media-Access .................................... 19
5.2.2 Change-Identifier ............................... 19
5.2.3 Routing-Information ............................. 20
5.2.4 Other-Identifier ................................ 21
5.2.5 System-Heard .................................... 22
APPENDICES ................................................... 23
A. Configuration Summary ................................. 23
SECURITY CONSIDERATIONS ...................................... 24
ACKNOWLEDGEMENTS ............................................. 24
AUTHOR'S ADDRESS ............................................. 24
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/