Internet DRAFT - draft-pentland-dna-protocol
draft-pentland-dna-protocol
DNA Working Group J. Kempf
Internet-Draft DoCoMo Communications Labs USA
Expires: January 19, 2006 S. Narayanan
Panasonic
E. Nordmark
Sun Microsystems
B. Pentland, Ed.
Monash University CTIE
July 18, 2005
Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-pentland-dna-protocol-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Efficient detection of network attachment in IPv6 needs the following
two components: a method for the host to query routers on the link to
identify the link (Link Identification) and a method for the routers
Kempf, et al. Expires January 19, 2006 [Page 1]
Internet-Draft DNAv6 July 2005
on the link to consistently respond to such a query with minimal
delay (Fast RA). Solving the link identification based strictly on
RFC 2461 is difficult because of the flexibilities offered to routers
in terms of prefixes advertised in a router advertisement (RA)
message. Similarly, the random delay in responding to router
solicitation messages imposed by RFC 2461 makes to it difficult to
achieve fast RA. A known set of solutions to these two problems was
identified and catalogued by the DNA design team. In this memo, an
integrated solution is presented, based on a sub-set of the
catalogued solutions. This integrated solution consolidates most of
the advantages of all known solutions while addressing most of the
disadvantages.
Kempf, et al. Expires January 19, 2006 [Page 2]
Internet-Draft DNAv6 July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6
3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6
3.3 Fast Router Advertisement . . . . . . . . . . . . . . . . 7
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8
4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9
4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10
5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 12
5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 12
5.1.2 Router Configuration Variables . . . . . . . . . . . . 13
5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 14
5.1.4 Processing Router Advertisements . . . . . . . . . . . 15
5.1.5 Processing Router Solicitations . . . . . . . . . . . 15
5.1.6 Complete Router Advertisements . . . . . . . . . . . . 16
5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16
5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 17
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 17
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18
5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 18
5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 19
5.2.5 Processing Router Advertisements . . . . . . . . . . . 19
5.2.6 DNA and Address Configuration . . . . . . . . . . . . 20
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23
6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 23
6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 24
7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 24
7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
Kempf, et al. Expires January 19, 2006 [Page 3]
Internet-Draft DNAv6 July 2005
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1 Normative References . . . . . . . . . . . . . . . . . . . 26
11.2 Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 30
Kempf, et al. Expires January 19, 2006 [Page 4]
Internet-Draft DNAv6 July 2005
1. Introduction
The proposed scheme in this memo is built upon the following
solutions catalogued in [15]: Complete RA and Requested Landmark are
used for the link identification, and Hash-based Fast RA is used to
achieve fast response to RS messages. The reasoning behind these
choices will become evident as the whole scheme and its advantages
are understood.
2. Terms and Abbreviations
There is an existing DNA terminology draft [12]. This draft does not
introduce any new terminology not already used by existing drafts.
The term "link" is used as defined in RFC 2460 [2]. NOTE: this is
completely different from the term "link" as used by IEEE 802, etc.
3. Overview
The DNA protocol presented in this document tries to achieve the
following objectives:
o Eliminate the delays introduced by RFC 2461 in discovering the
configuration.
o Make it possible for the hosts to accurately detect the identity
of their current link from a single RA.
o Keep the packets relatively small in size.
The approach described in this memo is based on the combination of
Requested Landmark and CompleteRA for link identification and the
Hash-based Fast RA mechanism. The rest of the document refers to
this approach by the term "DNAv6".
DNAv6 assumes that the host's wireless link interface software and
hardware is capable of delivering a 'link up' event notification when
layer 2 on the host is configured and sufficiently stable for IP
traffic. This event notification acts as a hint to the layer 3 DNA
procedures to check whether or not the host is attached to the same
link as before. DNAv6 also assumes that an interface on the host is
never connected to two links at the same time. In the case that the
layer 2 technology is capable of having multiple attachments (for
instance, multiple layer 2 associations or connections) at the same
time, DNAv6 requires the individual layer-2 associations to be
represented as separate (virtual interfaces) to layer 3 and DNAv6 in
particular.
Kempf, et al. Expires January 19, 2006 [Page 5]
Internet-Draft DNAv6 July 2005
3.1 What Identifies a Link?
DNAv6 identifies a link by the set of prefixes that are assigned to
the link, which is quite natural and doesn't require introducing any
new form of identifier. However, this choice implies that the
protocol needs to be robust against changes in the set of prefixes
assigned to a link, including the case when a link is renumbered and
the prefix is later reassigned to a different link. The protocol
handles this quite well during graceful renumbering (when the valid
lifetime of the prefix is allowed to decrease to zero before it is
removed and perhaps reassigned to a different link), however, it can
also cope with "flash" renumbering and reassignment but not in an
optimized fashion.
3.2 Link Identification
DNAv6 is based on using a Router Solicitation/Router Advertisement
exchange to both verify whether the host has changed link, and if it
has, provide the host with the configuration information for the new
link. This uses a technique called a "landmark", where the host
chooses one of the prefixes as a landmark prefix, and then includes
this in the Router Solicitation message in the form of a question "am
I still connected to the link which has this prefix?". The landmark
is carried in a new option, called the Landmark Option.
In the case when the host is still attached to the same link, which
might occur when the host has changed from using one layer 2 access
point to another, but the access points are on the same link, the
Router Advertisement(s) it receives will contain a "yes, that prefix
is on this link" answer, and no other information. Thus, such RA
messages are quite small.
In the case when the landmark prefix is unknown to the responding
router, the host will receive a "No" answer to its landmark question,
and also the information it needs to configure itself for the new
link. The routers try to include as much information as possible in
such messages, so that the host can be informed of all the prefixes
assigned to the new link as soon as possible.
The router advertisement messages are larger than the solicitations,
and with multiple routers on the link there will be multiple
advertisements sent for each solicitation. This amplification can be
used by an attacker to cause a Denial of Service attack. Such
attacks are limited by applying a rate limit on the unicast Router
Advertisements sent directly in response to each solicitation, and
using multicast RAs when the rate limit is exceeded.
When the multicast method is used, there are no explicit answers to
Kempf, et al. Expires January 19, 2006 [Page 6]
Internet-Draft DNAv6 July 2005
the landmark questions, instead the router(s) include information so
that the hosts themselves can answer their landmark questions. This
information consists of the prefixes a router would advertise itself
as per RFC 2461, and also, the prefixes learned from other routers on
the link that are not being advertised by itself. These learned
prefixes are included in a new DNA Option in the Router
Advertisement.
When the resulting multicast RA carries all the prefixes known to the
router, the RA is marked as "complete" using a new bit in the
message. When a host receives a complete multicast RA, the host can
easily decide whether it is attached to the same link or not from the
single RA. Thus, unlike CPL [14], the host does not have to wait for
multiple advertisements before making a decision.
In order for the routers be able to both respond to the landmark
questions and send the complete RAs, the routers need to track the
prefixes that other routers advertise on the link. This process is
initialized when a router is enabled, by sending a Router
Solicitation and collecting the resulting RAs, and then multicasting
a few RAs more rapidly as already suggested in RFC 2461. This
process ensures with high probability that all the routers have the
same notion of the set of prefixes assigned to the link.
3.3 Fast Router Advertisement
According to RFC 2461 a solicited Router Advertisement should have a
random delay between 0 and 500 milliseconds, to avoid the
advertisements from all the routers colliding on the link causing
congestion and higher probability of packet loss. In addition, RFC
2461 suggests that the RAs be multicast, and multicast RAs are rate
limited to one message every 3 seconds. This implies that the
response to a RS might be delayed up to 3.5 seconds.
DNAv6 avoids this delay by using a different mechanism to ensure that
two routers will not respond at exactly the same time while allowing
one of the routers on the link to respond immediately. Since the
hosts might be likely to use the first responding router as the first
choice from their default router list, the mechanism also ensures
that the same router doesn't respond first to the RSs from different
hosts.
The mechanism is based on the routers on the link determining (from
the same RAs that are used in section Section 3.1 to determine all
the prefixes assigned to the link), the link-local addresses of all
the other routers on the link. With this loosely consistent list,
each router can independently compute some function of the (link-
local) source address of the RS and each of the routers' link-local
Kempf, et al. Expires January 19, 2006 [Page 7]
Internet-Draft DNAv6 July 2005
addresses. The results of that function are then compared to create
a ranking, and the ranking determines the delay each router will use
when responding to the RS. The router which is ranked as #0 will
respond with a zero delay.
If the routers become out-of-sync with respect to their learned
router lists, two or more routers may respond with the same delay,
but over time the routers will converge on their lists of learned
routers on the link.
4. Message Formats
This memo defines two new flags for inclusion in the router
advertisement message and two new options.
4.1 Router Advertisement
DNAv6 modifies the format of the Router Advertisement message by
adding a flag bit to indicate that the router sending the message is
participating in the DNAv6 protocol as well as a flag to indicate the
completeness of the set of prefixes included in the Router
Advertisement. The new message format is as follows:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
DNA (D)
The DNA (D) bit indicates that the router sending the RA is
participating in the DNAv6 protocol. Other routers should include
this router in calculating response delay tokens.
Kempf, et al. Expires January 19, 2006 [Page 8]
Internet-Draft DNAv6 July 2005
Complete (C)
The Complete (C) bit indicates that the Router Advertisement
contains PIOs for all prefixes explicitly configured on the
sending router, and, if other routers on the link are advertising
additional prefixes, a DNA Option containing all additional
prefixes that the router has heard from other routers on the link.
Reserved (R)
The reserved field is reduced from 3 bits to 1 bit.
4.2 Landmark Option
The Landmark Option is used by hosts in a Router Solicitation message
to ask the routers on a link if the specified prefix is being
advertised by some router on the link. It is used by routers in a
Router Advertisement to reply to a corresponding question in a Router
Solicitation, indicating whether the prefix referred to is being
advertised by any router on the link.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pref Length |Y|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Landmark Prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets. Set to 2 or 3.
Pref Length
Kempf, et al. Expires January 19, 2006 [Page 9]
Internet-Draft DNAv6 July 2005
An 8 bit unsigned integer representing the number of bits in the
prefix to be used for matching.
Yes (Y)
The Yes (Y) bit, when included in a Landmark Option in a Router
Advertisement, indicates that the prefix referred to in the Prefix
field of this option is being advertised by one or more routers on
the current link. In a Landmark Option in a Router Solicitation,
this bit MUST be set to zero and ignored by receivers.
No (N)
The No (N) bit, when included in a Landmark Option in a Router
Advertisement, indicates that the prefix referred to in the Prefix
field of this option is not being advertised by any router on the
current link. In a Landmark Option in a Router Solicitation, this
bit MUST be set to zero and ignored by receivers.
Reserved
A 38 bit unused field. It MUST be initialised to zero by the
sender, and ignored by the receiver.
Prefix
A prefix being used by the host currently for a global IPv6
address, padded at the right with zeros. If the prefix length is
less than 65 bits, only 64 bits need be included, otherwise 128
bits are included.
4.3 DNA Option
The DNA Option (DNAO) is used by a router to indicate prefixes that
are being advertised in PIOs by other routers on the link, but not by
itself.
Kempf, et al. Expires January 19, 2006 [Page 10]
Internet-Draft DNAv6 July 2005
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Len 1 | Prefix Len 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Prefix Len N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix N +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA
Length
8 bit unsigned integer indicating the length of the option in
units of 8 octets.
Prefix Len
Kempf, et al. Expires January 19, 2006 [Page 11]
Internet-Draft DNAv6 July 2005
One or more fields (N) each consisting of an 8-bit unsigned
integer representing the prefix lengths of the following prefixes.
The Prefix Len fields are ordered the same as the Prefix fields so
that the first Prefix Len field represents the prefix length of
the prefix contained in the first prefix field, and so on.
Padding
Zero padding sufficient to align the following prefix field on an
8-octet boundary.
Prefix
One or more fields (N) each containing a 128-bit address
representing a prefix that has been heard on the link but is not
explicitly configured on this router.
Description
This option MUST only be included in a Router Advertisement. This
option contains prefixes that are being advertised on the link but
are not explicitly configured on the sending router. The router
MUST NOT include any prefixes with a zero valid lifetime in the
DNAO.
5. DNA Operation
5.1 DNA Router Operation
Routers MUST collect information about the other routers that are
advertising on the link.
5.1.1 Data Structures
The routers maintain a set of conceptual data structures for each
interface to track the prefixes advertised by other routers on the
link, and also the set of DNA routers (the routers that will quickly
respond to RSs) on the link.
For each interface, routers maintain a list of all prefixes
advertised on the link. The list will be referred to in this
document as "DNAPrefixList". For each prefix the router MUST store
sufficient information to identify the prefix and to know when to
remove the prefix entry from the list. This may be achieved by
storing the following information:
Kempf, et al. Expires January 19, 2006 [Page 12]
Internet-Draft DNAv6 July 2005
1. Prefix
2. Prefix length
3. Valid lifetime
4. Time last refreshed
For each interface, routers also maintain a list of the other routers
advertising on the link. The list will be referred to in this memo
as "DNARouterList". For each router from which a Router
Advertisement is received with the DNA flag set, the following
information MUST be stored:
1. Source address of advertising router
2. Token equal to the first 64 bits of an SHA-1 hash of the above
address
3. Time last refreshed
Each router MUST include itself in the DNARouterList and generate a
token for itself as describe above based on the link-local address
used in its RA messages.
5.1.2 Router Configuration Variables
A DNAv6 router MUST allow for the following conceptual variables to
be configured by the system management. Default values are set to
ease configuration load.
UnicastRAInterval
The interval corresponding to the maximum average rate of Router
Solicitations that the router is prepared to service with unicast
responses. This is the interval at which the token bucket
controlling the unicast responses is replenished.
Default: 50 milliseconds
MaxUnicastRABurst
The maximum size burst of Router Solicitations that the router is
prepared to service with unicast responses. This is the maximum
number of tokens allowed in the token bucket controlling the
unicast responses.
Kempf, et al. Expires January 19, 2006 [Page 13]
Internet-Draft DNAv6 July 2005
Default: 20
RASeparation
The separation between responses from different routers on the
same link to a single Router Solicitation.
Default: 20 milliseconds
MulticastRADelay
The delay to be introduced when scheduling a multicast RA in
response to a RS message when the token bucket is empty.
Default: 3000 milliseconds
FastRAThreshold
The maximum number of fast responses that a host should receive
when soliciting for Router Advertisements.
Default: 3
5.1.3 Bootstrapping DNA Data Structures
When an interface on a router first starts up, it SHOULD transmit up
to MAX_RTR_SOLICITATIONS Router Solicitations separated by
RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other
routers and prefixes active on the link.
Upon startup, a router interface SHOULD also send a few unsolicited
Router Advertisements as recommended in Section 6.2.4 of RFC 2461
[3], in order to inform others routers on the link of its presence.
During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) *
RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface
both sends unsolicited Router Advertisements and responds to Router
Solicitations, but with a few restrictions on the message content.
Router Advertisements MUST NOT include any DNA specific options
except that the DNA flag MUST be set. The DNA flag is set so that
other routers will know to include this router in their timing
calculations for fast RA transmission. Other DNA options are omitted
because the router may have incomplete information during bootstrap.
During the bootstrap period, the timing of Router Advertisement
transmission is as specified in RFC 2461.
Kempf, et al. Expires January 19, 2006 [Page 14]
Internet-Draft DNAv6 July 2005
5.1.4 Processing Router Advertisements
When a router receives a Router Advertisement, it first validates the
RA as per the rules in RFC 2461, and then performs the actions
specified in RFC 2461. In addition, each valid Router Advertisement
is processed as follows:
If the DNA flag is set in the RA, the router checks if there is an
entry in its DNARouterList. Thus it looks up the source address of
the RA in that list and, if not found, a new entry is added to
DNARouterList, including the source address and a token equal to the
first 64 bits of an SHA-1 hash of the source address. The entry's
'Time last refreshed' is updated.
Regardless of the state of the DNA flag, each PIO in the RA is
examined. If the prefix is not in the router's DNAPrefixList, it is
added, along with the lifetime and refresh information.
5.1.5 Processing Router Solicitations
The usual response to an RS SHOULD be a unicast RA. However, to keep
control of the rate of unicast RAs sent, a token bucket is used. The
token bucket is filled at one token every UnicastRAInterval. A
maximum of MaxUnicastRABurst tokens are stored.
When a Router Solicitation is received, if a unicast send token is
available then:
If the source address of the Router Solicitation is the
Unspecified Address, then the router builds a Complete RA as
specified in Section 5.1.6 and schedules it for multicast
transmission as per RFC 2461.
If the source address of the RS is NOT the unspecified address,
the router consumes one unicast send token and then builds a
Router Advertisement as follows:
The DNA flag is set.
If the RS contains a Landmark Option whose prefix matches one
of those in the interface's DNAPrefixList, then the Landmark
option with the Landmark prefix is included in the RA but with
the Yes flag set. All configuration related options (MTU,
Advertisement Interval, etc., including PIOs) SHOULD NOT be
included as this information is already known to the host.
SEND options, if any, MUST NOT be omitted. At this point the
RA is ready for transmission, and is scheduled as specified in
Section 5.1.7.
Kempf, et al. Expires January 19, 2006 [Page 15]
Internet-Draft DNAv6 July 2005
If the RS contains a Landmark Option whose prefix does not
match any of those in the interface's stored prefix list, then
the Landmark option with the Landmark prefix is included in the
RA but with the No flag set. All fixed options (MTU,
Advertisement Interval, flags, etc.) are added to the Router
Advertisement. Prefix Information Options for any explicitly
configured prefixes SHOULD be added to the Router
Advertisement, while the DNAO for learned prefixes SHOULD NOT
be added. If there is insufficient room to fit all of the
PIOs, an additional Router Advertisement is built after
consuming another token, if available. At this point the
Router Advertisement is ready for transmission, and is
scheduled as specified in Section 5.1.7.
If the RS does not contain a Landmark Option, then the router
builds a complete RA as specified in Section 5.1.6 and
schedules it for unicast transmission as specified in
Section 5.1.7.
If no unicast send token is available in the token bucket, AND there
are no existing scheduled multicast RAs, the router MUST construct a
Complete RA as specified in Section 5.1.6 and schedule it for
transmission after MulticastRADelay.
Otherwise it is not possible to send a fast unicast response and a
multicast Complete RA is already scheduled so therefore the Router
Solicitation MUST be dropped.
5.1.6 Complete Router Advertisements
A CompleteRA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the DNA flag is set. As many
Prefix Information Options for explicitly configured prefixes as will
fit are added to the Router Advertisement. If there is sufficient
room, a DNA option as defined in Section 4.3 containing as many of
the learned prefixes as will fit is added.
It may not be possible to include all of the prefixes in use on the
link due to MTU or administrative limitations. If all Prefix
Information Options and a DNA Option containing all of the learned
prefixes were included in the RA, then the Complete flag in the
Router Advertisement header is set.
5.1.7 Scheduling Fast Router Advertisements
RAs may need to be delayed to avoid collisions in the case that there
Kempf, et al. Expires January 19, 2006 [Page 16]
Internet-Draft DNAv6 July 2005
is more than one router on a link. The delay is calculated by
determining a ranking for the router for the received RS, and
multiplying that by RASeparation.
A token is needed from the RS to calculate the router's ranking. The
low order 64 bits of the RS source address MUST be used as the RS
token.
A router's ranking is determined by taking the XOR of the RS token
and each of the stored router tokens. The results of these XOR
operations are sorted lowest to highest, doing comparisons byte-by-
byte starting with the least significant byte. The router
corresponding to the first entry in the sorted list is ranked zero,
the second, one, and so on.
Note: it is not necessary for a router to actually sort the whole
list. Each router just needs to determine its own position in the
sorted list.
If Rank < FastRAThreshold, then the RA MUST be scheduled for
transmission in Rank * RASeparation milliseconds. When the router is
ranked as zero, the resulting delay is zero, thus the RA SHOULD be
sent immediately.
If Rank >= FastRAThreshold, then the RA MUST be replaced with a
Complete RA, if it is not one already, and scheduled for multicast
transmission as in RFC 2461.
5.1.8 Scheduling Unsolicited Router Advertisements
Unsolicited router advertisements MUST be scheduled as per RFC 2461
SHOULD be Complete RAs. This recommendation is made to keep the
multicast RA messages transmitted on the link looking the same,
whether they are responses to solicitation that are unable to be
unicast or the unsolicited RA messages transmitted based on RFC 2461.
5.2 DNA Host Operation
Hosts collect information about the prefixes available on the link to
which they are connected to facilitate change detection.
5.2.1 Data Structures
Hosts MUST maintain a list of prefixes advertised on the link. This
is separate from the RFC 2461 "Prefix List" and will be referred to
here as the "DNAPrefixList". All prefixes SHOULD be stored, however
an upper bound MUST be placed on the number stored to prevent
overflow. For each prefix stored the host MUST store the following
Kempf, et al. Expires January 19, 2006 [Page 17]
Internet-Draft DNAv6 July 2005
information:
1. Prefix
2. Prefix length
3. Valid lifetime
4. Time last refreshed
If a host is not able to store this information for every prefix,
there is a risk that the host will incorrectly decide that it has
moved to a new link, when it receives advertisements from a non-DNA
router.
Prefix information entry MUST be removed from the DNAPrefixList when
its valid lifetime expires or if the entry has not been refreshed in
the last 1.5 hours.
Hosts MUST also maintain a "Landmark Prefix" as described in
Section 5.2.3.
5.2.2 Host Configuration Variables
Hosts MUST make use of the following conceptual variables and they
SHOULD be configurable:
DNASameLinkDADFlag
Boolean value indicating whether or not a host should re-run DAD
when DNA indicates that link change has not occurred.
Default: False
5.2.3 Selection of a Landmark Prefix
For each interface, hosts MUST choose a prefix to use as a Landmark
Prefix in Router Solicitations. The following rules are used in
selecting the landmark prefix:
The prefix MUST have a non-zero valid lifetime.
The prefix MUST be one the host is using for one of its non-link-
local IPv6 addresses.
The prefix SHOULD be chosen as the one with the longest preferred
lifetime, but it is not necessary to switch to different prefix if
Kempf, et al. Expires January 19, 2006 [Page 18]
Internet-Draft DNAv6 July 2005
the preferred lifetime of the current landmark prefix changes.
5.2.4 Sending Router Solicitations
Upon the occurrence of a Layer 2 link-up event notification, hosts
SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting
and/or hysteresis to this behaviour as appropriate to the link
technology subject to the reliability of the hints.
Hosts SHOULD include a Landmark Option (LO) in the RS message with
the landmark prefix chosen based on the rules in section
Section 5.2.3.
Hosts MUST include a tentative source link layer address option
(TSLLAO) in the RS message [16]. The router solicitation message is
sent to the All_Routers_Multicast address and the source address MUST
be the link local address of the host.
The host MUST consider its link local address to be in the
"Optimistic" state for duplicate address detection [6] until either
the returned RA confirms that the host has not switched to a new link
or, if an link change has occurred, the host has performed optimistic
duplicate address detection for the address.
5.2.5 Processing Router Advertisements
When the host receives a Router Advertisement, the host checks for
the conditions and derives the associated conclusions given below:
If the received Router Advertisement message was sent unicast to the
host:
If the unicast Router Advertisement contains a Landmark Option
that matches the Landmark Option in the last transmitted Router
Solicitation, and the 'Y' bit is set in the received Landmark
option, then that indicates that no link change has occurred and
current configuration can be assumed to be still current.
Instead if the 'N' bit is set in the received Landmark Option, a
change of link is indicated and the host SHOULD initiate
reconfiguration using the information in the Router Advertisement.
Since the host received a unicast RA from the router, the host
knows the router heard its RS, hence it SHOULD mark that router as
REACHABLE from a Neighbor Unreachability Perspective.
If a Router Advertisement is received with a multicast destination
Kempf, et al. Expires January 19, 2006 [Page 19]
Internet-Draft DNAv6 July 2005
address and the DNA flag is set, check if the received RA is a
Complete RA by checking the Complete (C) bit in the RA message.
If the RA is a Complete RA and the landmark prefix is not included
in either a PIO or DNAO, then the host can conclude that it has
changed link and SHOULD initiate re-configuration using the
information in the received router advertisement.
If the RA is a Complete RA and the the landmark prefix is included
in either a PIO or DNAO, then the host can conclude that it has
not changed link.
If the received RA is not complete then the host SHOULD use CPL
logic to decide whether or not to reconfigure as described in
[14].
If the DNA flag is not set then the host SHOULD use CPL logic to
decide whether or not to reconfigure as described in [14].
When initiating reconfiguration due to link change, the host MUST
remove all prefixes in the DNAPrefixList and repopulate it with the
prefixes in the Prefix Information Options in the RA.
5.2.6 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists
for a change in the validity of its unicast and multicast addresses
on that network interface. In this section, host processing for
address configuration is specified. The section considers both
statelessly and statefully configured addresses.
5.2.6.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [6]
for autoconfiguring unicast link local addresses. If a DNA host uses
address autoconfiguration [7] for global unicast addresses, the DNA
host MUST support optimistic Duplicate Address Detection for
autoconfiguring global unicast addresses.
5.2.6.2 DNA and the Address Autoconfiguration State Machine
When a link level event occurs on a network interface indicating that
the host has moved from one point of attachment to another, it is
possible that a change in the reachability of the addresses
associated with that interface may occur. Upon detection of such a
link event and prior to sending the RS initiating a DNA exchange, a
DNA host MUST change the state of addresses associated with the
interface in the following way (address state designations follow RFC
Kempf, et al. Expires January 19, 2006 [Page 20]
Internet-Draft DNAv6 July 2005
2461):
o Addresses in the "Preferred" state are moved to the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate
Address Detection.
o Addresses in the "Optimistic" state remain in the "Optimistic"
state, but the host defers sending out an NS to initiate Duplicate
Address Detection.
o Addresses in the "Deprecated" state remain in the "Deprecated"
state.
o No addresses should be in the "Tentative" state, since this state
is unnecessary for nodes that support optimistic Duplicate Address
Detection.
A host MUST keep track of which "Preferred" addresses are moved to
the "Optimistic" state, so it is possible to know which addresses
were in the "Preferred" state and which were in the "Optimistic"
state prior to the change in point of attachment.
In order to perform the DNA transaction, the DNA host SHOULD select
one of the unicast link local addresses that was in the "Preferred"
state prior to switching to "Optimistic" and utilize that as the
source address on the DNA RS. If the host had no "Preferred" unicast
link local address but did have an address in the "Optimistic" state,
it MUST utilize such an address as the source address. If the host
currently has no unicast link local addresses, it MUST construct one
and put it into the "Optimistic" state and note this address as
having been in the "Optimistic" state previously, but defer sending
the NS to confirm. Note that the presence of a duplicate unicast
link local address on the link will not interfere with the ability of
the link to route a unicast DNA RA from the router back to the host
nor will it result in corruption of the router's neighbor cache,
because the TSLLA option is included in the RS and is utilized by the
router on the RA frame without changing the neighbor cache.
When the host receives unicast or multicast RAs from the router, if
the host determines from the received RAs that it has moved to a new
link, the host MUST immediately move all unicast global addresses to
the "Deprecated" state and configure new addresses using the subnet
prefixes obtained from the RA. For all unicast link local addresses,
the host MUST initiate NS signaling for optimistic Duplicate Address
Detection to confirm the uniqueness of the unicast link local
addresses on the new link.
If the host determines from the received RAs that it has not moved to
Kempf, et al. Expires January 19, 2006 [Page 21]
Internet-Draft DNAv6 July 2005
a new link (i.e. the link has not changed) and the previous state of
an address was "Optimistic", then the host MUST send an NS to confirm
that the address is unique on the link. This is required because
optimistic Duplicate Address Detection may not have completed on the
previous point of attachment, so the host may not have confirmed
address uniqueness. If the previous state of an address was
"Preferred", whether or not the host initiates optimistic Duplicate
Address Detection depends on the configurable DNASameLinkDADFlag
flag. A host MUST forgo sending an NS to confirm uniqueness if the
value of the DNASameLinkDAD flag is False. If, however, the
DNASameLinkDAD flag is True, the host MUST perform optimistic
duplicate address detection on its unicast link local and unicast
global addresses to determine address uniqueness.
5.2.6.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [8] requires hosts to send a DHCPv6 CONFIRM
message when a change in point of attachment is detected. Since the
DNA protocol provides the same level of movement detection as the
DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the
DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive
signaling. If, however, a non-DNA RA is received, the host SHOULD
use the DHCPv6 CONFIRM message as described in RFC 3315 [8] rather
than wait for additional RAs to perform CPL, since this will reduce
the amount of time required for the host to confirm whether or not it
has moved to a new link. If the CONFIRM message validates the
addresses, the host can continue to use them.
When a DNA RA is received and the received RA indicates that the host
has not moved to a new link, the host SHOULD apply the same rules to
interpreting the 'M' flag in the received RA and any subsequently
received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA
is received with the 'M' flag set, then the 'M' flag value is copied
into the ManagedFlag, and if the ManagedFlag changes from False to
True the host should run DHCPv6, but if the ManagedFlag changes from
True to False, the host should continue to run DHCPv6. If, however,
the value of the ManagedFlag remains the same both before and after
the change in point of attachment on the same link has been
confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain
new addresses, since the old addresses will continue to be valid.
If the DNA RA indicates that the host has moved to a new link or the
DHCPv6 CONFIRM indicates that the addresses are invalid, the host
MUST move its old addresses to the "Deprecated" state and MUST run
DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is
4-message exchange, however, this exchange allows for redundancy
(multiple DHCPv6 servers) without wasting addresses, as addresses are
only provisionally assigned to a host until the host chooses and
Kempf, et al. Expires January 19, 2006 [Page 22]
Internet-Draft DNAv6 July 2005
requests one of the provisionally assigned addresses. If the DNA
host supports the Rapid Commit Option [8], the host SHOULD use the
Rapid Commit Option in order to shorten the exchange from 4 messages
to 2 messages.
5.2.6.4 Packet Delivery During DNA
The specification of packet delivery before, during, and immediately
after DNA when a change in point of attachment occurs is out of scope
for this document. The details of how packets are delivered depends
on the mobility management protocols (if any) available to the host's
stack.
5.2.6.5 Multicast Address Configuration
If the returning RAs indicate that the host has not moved to a new
link, no further action is required for multicast addresses to which
the host has subscribed using MLD Report [9]. In particular, the
host MUST NOT perform MLD signaling for any multicast addresses
unless such signaling was not performed prior to movement to the new
point of attachment. For example, if an address is put into the
"Optimistic" state prior to movement but the MLD Report for the
Solicited_Node_Multicast_Address is not sent prior to movement to a
new point of attachment, the host MUST send the MLD Report on the new
point of attachment prior to performing optimistic Duplicate Address
Detection. The host SHOULD use the procedure described below for
sending an MLD Report.
If, on the other hand, the DNA RA indicates that the host has moved
to a new link, the host MUST issue a new MLD Report to the router for
subscribed multicast addresses. MLD signaling for the
Solicited_Node_Multicast_Addresses [7] MUST be sent prior to
performing signaling for optimistic DAD.
To avoid lengthy delays in address reconfiguration, it is RECOMMENDED
that the host send the MLD Report for newly configured addresses
immediately, as soon as the addresses have been constructed, rather
than waiting for a random backoff.
Hosts MUST defer MLD signaling until after the results of DNA have
confirmed whether or not a link change has occurred.
6. Backward Compatibility
6.1 Non DNA Host with DNA Routers
The RS message sent by non-DNA hosts will not contain any of the new
options defined by this document. The host will receive a Complete
Kempf, et al. Expires January 19, 2006 [Page 23]
Internet-Draft DNAv6 July 2005
RA in response to the solicitation message and process it as per RFC
2461. This means that it will drop the unrecognised DNA option, but
process the included PIOs and non-DNA flags normally.
6.2 DNA Host with Non-DNA Routers
The routers will behave based in the recommendations of RFC 2461 [3]
and ignore the new options defined in this memo. Hosts will receive
RA message without the DNA bit in the RA header set and will fallback
on CPL for link identification. Obviously, the objective of
receiving fast response for RS message can not be achieved.
7. Security Considerations
The two security threats discussed in Section 7.1 and Section 7.2 are
part of the discussion catalogued as Issue 14 in Section 9.
7.1 Amplification Effect
With N routers on a link, each RS message sent on the link will have
N RA responses sent on the link within (N-1) * RASeparation time.
The rate control mechanism specified by this memo only controls the
rate of RA messages generated by each of the routers. But, since
there is no theoretical restriction on the number of routers on the
link, this amplification can deteriorate the performance of the nodes
on the link. The routers could mitigate this effect by aggregating
multiple RA messages into a single multicast RA message. When a RS
message is received, except for the router chosen to respond first,
all the other routers have a delay introduced before they respond to
the RS message. Also, when the token bucket is empty (see
Section 7.2), the routers will have to wait for a token to be
generated before responding. If multiple RS messages are received
during this wait time, the routers MAY choose to aggregate the
responses to a single multicast RA message. Aggregation can be done
by creating a Complete RA message as specified by Section 5.1.6.
But, since MIN_DELAY_BETWEEN_RAS restriction for multicast RA
messages is inherited by this document, such aggregations are only
possible every MIN_DELAY_BETWEEN_RAS (3 seconds).
7.2 Attacks on the Token Bucket
A host on the link could easily drain the token bucket(s) of the
router(s) on the link by continuously sending RS messages on the
link. For example, if a host sends one RS message every
UnicastRAInterval, and send a additional RS every third
UnicastRAInterval, the token bucket in the router(s) on the link will
drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units.
For the recommended values of UnicastRAInterval and
Kempf, et al. Expires January 19, 2006 [Page 24]
Internet-Draft DNAv6 July 2005
MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear
whether arrival of such RS messages can be recognized by the router
as a DoS attack. This attack can also be mitigated by aggregating
responses. Since only one aggregation is possible in this interval
due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able
protect the tokens in the bucket.
7.3 Attacks on DNA Hosts
RFC 3756 outlines a collection of threats involving rouge routers.
Since DNAv6 requires a host to obtain trustworthy responses from
routers, such threats are relevant to DNAv6. In order to counter
such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router
discovery.
8. IANA Considerations
This memo defines two new Neighbor Discovery [3] options, which must
be assigned Option Type values within the option numbering space for
Neighbor Discovery messages:
1. The Landmark option, described in Section 4.2; and
2. The DNA option, described in Section 4.3.
9. Open Issues
A list of open issues in the proposed design has been identified and
catalogued at:
http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASolution1.
The following is a sample of the open issues, please refer to the
above link for details.
Issue 006: Congestion control in hosts
The draft currently does not discuss congestion control in hosts
and thus if there is no response to an RS, a host will follow RFC
2461 and send MAX_RTR_SOLICITATIONS separated by
RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals).
Should we specify some kind of exponential backoff to improve
response performance for DNAv6 routers or should we try to
maintain compatibility with RFC 2461?
Issue 009: LNOLO vs matched prefix
Kempf, et al. Expires January 19, 2006 [Page 25]
Internet-Draft DNAv6 July 2005
If there is a landmark option with 'N' bit set in an RA, and *in
the same RA* there is PIO that matches another prefix that the
host believes is on the current link, what should the host
conclude?
Issue 010: Host response to inconsistent information
What does the host do if it receives multiple RAs that have
conflicting information?
Issue 012: Network renumbering - guidelines for deployment
What does the draft need to say about network renumbering?
Recommendations about not flash renumbering? Explanation of
effects of flash renumbering?
Issue 013: Lifetime of learned prefixes and routers
Since the maximum possible values for lifetimes of routers and
prefixes could be very high, should we put an upper limit on how
long learned prefixes and routers information can be stored by
routers?
10. Acknowledgments
The design presented in this document was generated by discussions
among the members of the DNA design team (JinHyeock Choi, Tero
Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett
Pentland). The spirited debates on the design, advantages and dis-
advantages of various DNA solutions helped creation of this document.
Thanks to Greg Daley and Subba Reddy for their review of this
document, and thanks also to other members of the DNA working group
for their helpful comments.
11. References
11.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
Kempf, et al. Expires January 19, 2006 [Page 26]
Internet-Draft DNAv6 July 2005
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004.
[6] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
draft-ietf-ipv6-optimistic-dad-05 (work in progress),
February 2005.
11.2 Informative References
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462 2462, December 1998.
[8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[10] Choi, J., "Detecting Network Attachment in IPv6 Goals",
draft-ietf-dna-goals-04 (work in progress), December 2004.
[11] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network
Attachment in IPv6 - Best Current Practices",
draft-narayanan-dna-bcp-00 (work in progress), June 2004.
[12] Yamamoto, S., "Detecting Network Attachment Terminology",
draft-yamamoto-dna-term-00 (work in progress), February 2004.
[13] Manner, J. and M. Kojo, "Mobility Related Terminology",
draft-ietf-seamoby-mobility-terminology-06 (work in progress),
February 2004.
[14] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005.
[15] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005.
[16] Daley, G., "Tentative Source Link-Layer Address Options for
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in
progress), June 2004.
Kempf, et al. Expires January 19, 2006 [Page 27]
Internet-Draft DNAv6 July 2005
Authors' Addresses
James Kempf
DoCoMo Communications Labs USA
USA
Phone:
Email: kempf@docomolabs-usa.com
Sathya Narayanan
Panasonic Digital Networking Lab
Two Research Way, 3rd Floor
Princeton, NJ 08536
USA
Phone: 609 734 7599
Email: sathya@Research.Panasonic.COM
URI:
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Mountain View, CA
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Brett Pentland (editor)
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 5245
Email: brett.pentland@eng.monash.edu.au
Appendix A. How the Goals are Met?
The DNA goals document [10] contains a list of goals identified by G1
to G10. This is also enumerated in the solutions discussion document
[15] generated by the DNA design team. This section discusses how
the proposed scheme addresses each of these goals.
Kempf, et al. Expires January 19, 2006 [Page 28]
Internet-Draft DNAv6 July 2005
G1 The answer to the landmark question confirms whether link change
has occurred and if it has the RA contains sufficient information
for the host to commence re-configuration. If a multicast RA is
used it contains a complete list of prefixes advertised on the
link allowing the host to determine whether link change has
occurred and to re-configure if necessary.
G2 Under normal circumstances the host will receive a RA response
within round-trip time and some processing time on the router. If
the first RA message is lost, if another router is on the link, a
second RA should arrive within a slot time and so on.
G3 Non movement scenarios will be correctly identified because the
landmark will be confirmed by the router(s) on the link.
G4 A single RS/RA message exchange is initiated in response to a hint
that link change may have occurred.
G5 The existing RS/RA signalling is used along with unsolicited RA
messages. Some new options and flags are proposed.
G6 Only link scope signaling is used.
G7 SEND can be used to protect the RS and RA messages exchanged.
G8 If SEND is not deployed, then a rogue device could cause a host to
think its configuration is invalid by sending an RA that answers
the RS question incorrectly. A similar effect is already
possible, however, by a rogue device sending an RA with valid
prefixes with zero lifetimes.
G9 The CPL logic allows a graceful fallback position for dealing with
non-DNA routers and non DNA hosts will still receive the benefit
of receiving an RA response from its current router faster than
RFC 2461.
G10 This technique is carried out on an interface by interface basis.
A host with multiple interfaces can get information about changes
to configuration on each interface, but would need a higher level
process to decide how the information from the various interfaces
relates to each other.
Kempf, et al. Expires January 19, 2006 [Page 29]
Internet-Draft DNAv6 July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kempf, et al. Expires January 19, 2006 [Page 30]
