Internet DRAFT - draft-jinchoi-dna-protocol2
draft-jinchoi-dna-protocol2
DNA WG JinHyeock. Choi
Internet-Draft Samsung AIT
Expires: December 30, 2005 Syam. Madanapalli
Samsung ISO
June 28, 2005
DNA Solution: Link Identifier based approach
draft-jinchoi-dna-protocol2-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 December 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
DNA solution consists of 1)link identity detection with a single RA
and 2)quick RA acquisition. This draft presents the first component
based on Link Identifier. It describes a way for link identity
detection with prefix based Link Identifier, 'linkid prefix'. While
this document doesn't include the second component, any quick RA
acquisition scheme will work with the proposal. The draft is the
result of DNA DT discussion.
Choi & Madanapalli Expires December 30, 2005 [Page 1]
Internet-Draft linkid prefix June 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Checking for link change with Link Identifier . . . . . . 3
1.2 Link Identifier based on Prefix . . . . . . . . . . . . . 3
1.3 Protocol overview . . . . . . . . . . . . . . . . . . . . 4
2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Linkid prefix . . . . . . . . . . . . . . . . . . . . . . 5
2.2 LEAST_VALID_LIFETIME . . . . . . . . . . . . . . . . . . . 5
2.3 Linkid lifetime . . . . . . . . . . . . . . . . . . . . . 5
2.4 Linkid Prefix list (LinkidPrefixList) . . . . . . . . . . 6
2.5 LPIO (Learned Prefix Information Option) . . . . . . . . . 7
2.6 Identifier bit (I-bit) . . . . . . . . . . . . . . . . . . 7
3. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 8
3.2 Collecting the prefixes . . . . . . . . . . . . . . . . . 8
3.3 Selecting the linkid prefix . . . . . . . . . . . . . . . 9
3.4 Advertising the linkid prefix . . . . . . . . . . . . . . 9
3.5 Graceful linkid prefix change . . . . . . . . . . . . . . 9
3.5.1 When a new linkid prefix is added. . . . . . . . . . . 10
3.5.2 When the linkid prefix lifetime decreases to
LEAST_VALID_LIFETIME. . . . . . . . . . . . . . . . . 10
3.5.3 When the linkid prefix is removed while its
lifetime is greater than LEAST_VALID_LIFETIME. . . . . 10
3.5.4 When the Linkid prefix (Learned Prefix) is not
advertised in the last 1.5 hours . . . . . . . . . . . 12
4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Managing the LinkidPrefixList . . . . . . . . . . . . . . 13
4.2 Checking for link change . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Issue 001: LPIO format . . . . . . . . . . . . . . . . . . 17
7.2 Issue 002: Advertising old linkid prefix . . . . . . . . . 17
7.3 Issue 003: Flash renumbering and early reassignment . . . 18
7.4 Issue 004: DAD Interaction . . . . . . . . . . . . . . . . 18
7.5 Issue 005: MLD Interaction . . . . . . . . . . . . . . . . 18
7.6 Issue 006: Sending RA before completing prefix
collection . . . . . . . . . . . . . . . . . . . . . . . . 18
7.7 Issue 007: Linkid prefix option for RS message . . . . . . 18
7.8 Issue 008: Linkid Selection Scheme . . . . . . . . . . . . 19
8. Comparison with landmark based approach . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1 Normative References . . . . . . . . . . . . . . . . . . . 22
10.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Choi & Madanapalli Expires December 30, 2005 [Page 2]
Internet-Draft linkid prefix June 2005
1. Introduction
Upon establishing a new link-layer connection, a host should detect
the identity of the currently attached link to ascertain the validity
of the existing IP configuration. If the host is attached to a
different link, it also needs to acquire the IP configuration for the
new link [4].
DNA solution should be able to 1) check for link change with a single
RA (Router Advertisement) and 2) get the RA with minimum latency [8].
This draft presents only the first component, link identity
detection. But the proposed Link Identifier based scheme can work
with any existing quick RA acquisition method, such as FRD in [16],
FastRA in [17] or Hash based scheme in [13].
1.1 Checking for link change with Link Identifier
Usually a host receives the link information with RA (Router
Advertisement) messages. But it's difficult for a host to correctly
check for link change with a single RA message.
It may be better to design a new way to represent a link, 'Link
Identifier'. Each link has its unique Link Identifier and all
routers in the link advertise the same Link Identifier in RAs. With
a Link Identifier, an RA can represent link identity properly and
hosts can check for link change immediately without resorting to
approximate knowledge.
When a host receives an RA with the same Link Identifier, it still
remains at the same link. If it receives an RA with a different Link
Identifier, a link change has occurred and the host is attached to a
different link.
1.2 Link Identifier based on Prefix
We may define a new option for linkid. In [14] Erik Nordmark
proposed a new option, Location Indication Option and Brett Pentland
submitted a draft on linkid [15].
Global prefix is another possible candidate for use as linkid (Link
Identifier). If all routers on the link advertise the same prefix as
the linkid, the prefix can properly represent the link identity.
Prefixes would have the advantage of being globally unique and
requires no additional RA bytes if a router is already advertising
the prefix. Only an added flag is needed to indicate that it is also
a linkid (Link Identifier). Linkid may need to change as the
prefixes used on a link change.
Choi & Madanapalli Expires December 30, 2005 [Page 3]
Internet-Draft linkid prefix June 2005
1.3 Protocol overview
The routers on the link collects the prefixes on the link and, as the
linkid, pick the smallest prefix among the prefixes with lifetime
greater than 3 hours. We call such a prefix 'linkid prefix'.
The routers advertise the linkid prefix in every RA.
If the linkid prefix belongs to the advertising router, it includes
the linkid prefix in PIO (Prefix Information Option) with identifier
bit (I-bit) set, which indicates that the prefix is the linkid.
If not, the router includes the linkid prefix in LPIO (Learned Prefix
Information Option) with identifier bit (I-bit) set, which also
indicates that the prefix is the linkid.
The routers use a single linkid prefix at any given time, but due to
the possibility that the linkid prefix changing (e.g., when a link is
renumbered), the hosts track the list of linkid prefixes they've
received in the last 1.5 hours to generate "the linkid prefix list
(LinkidPrefixList)".
Take notice that the above doesn't mean that multiple linkid prefixes
are assigned on a link at the same time. Not like prefix, the linkid
is supposed to be unique at a given moment and the LinkidPrefixList
would have only one element for the most of time.
Whenever the host receives an RA with a linkid prefix, a host
extracts the prefix to store it in the LinkidPrefixList.
If the host receives an RA with a linkid prefix and the RA also
includes a linkid prefix the host knows of, it assumes that it still
remains at the same link.
If the host receives an RA with a linkid prefix and the RA doesn't
include a linkid prefix the host knows of, it assumes that it has
moved to a new link. The host also discards the existing
LinkidPrefixList and starts a new one.
This is rather intuitive description and Sec 4 gives more rigorous
and detailed one.
Choi & Madanapalli Expires December 30, 2005 [Page 4]
Internet-Draft linkid prefix June 2005
2. New Terms
2.1 Linkid prefix
A prefix which plays the role of linkid (Link Identifier).
2.2 LEAST_VALID_LIFETIME
Only a prefix with valid lifetime greater than LEAST_VALID_LIFETIME
can be a linkid prefix. When the lifetime of a linkid prefix becomes
less than LEAST_VALID_LIFETIME, it can no longer be a Link
Identifier.
For the time being, we set the LEAST_VALID_LIFETIME as 3 hours.
LEAST_VALID_LIFETIME is introduced to gracefully change the linkid
prefix as described in Sec 3.4.
2.3 Linkid lifetime
RFC 2461 [1] defines default valid lifetime as 30 days and default
preferred lifetime as 7 days, which may be too long for a linkid
prefix.
Hence, for a linkid prefix, a host keeps a separate lifetime, 'linkid
lifetime'.
For each linkid prefix, whenever a host receives an RA with the
prefix, the host sets the linkid lifetime as 1.5 hour and starts
timer.
When linkid lifetime expires, the host no longer uses the prefix as a
linkid. But the host may keep the prefix as an ordinary prefix until
its valid lifetime expires.
According to RFC 2461 [1], the maximum of MaxRtrAdvInterval is 1800
secs. Hence, because all RAs are supposed to carry the linkid
prefix, linkid lifetime expiration means that the host has lost at
least 3 RAs.
Linkid lifetime is introduced to gracefully change the linkid prefix
as described in Sec 3.4. It is also intended to deal with flash
renumbering and early reassignment as below.
When a linkid prefix is removed from a link, it is recommended that
the linkid prefix should not be re-assigned to other link in 3 hours.
The above means that if a host sees the valid prefix which was a
Choi & Madanapalli Expires December 30, 2005 [Page 5]
Internet-Draft linkid prefix June 2005
linkid and its linkid lifetime is still left, the host still remains
at the same link.
Sub-sec 7.3 gives the detailed analysis.
2.4 Linkid Prefix list (LinkidPrefixList)
A host keeps the linkid prefix list (LinkidPrefixList) per a link.
The LinkidPrefixList is the set of linkid prefixes the host has
received in the last 1.5 hours.
If the host has declared the movement to a different link, it needs
to discard the LinkidPrefixList from the old link.
When the host receives a prefix with identifier bit (I-bit) set, it
keeps the prefix in the LinkidPrefixList for the next 1.5 hours.
Take notice that the prefix in the LinkidPrefixList may not be the
linkid anymore. Also it's possible for the LinkidPrefixList has more
than one prefix.
This is for graceful linkid prefix change. When a linkid prefix is
changed in a link, there may be some flapping for a while. A router
may advertise the new linkid prefix, whereas the other one the old
one. Hence hosts can confuse this as frequent link changes.
To prevent this, hosts keep the LinkidPrefixList and assume they are
still at the same link, if they see the prefix in the
LinkidPrefixList.
We illuminate the role of the LinkidPrefixList with the following
example. Assume a link with two routers R1 and R2. R1 advertise the
linkid prefix P1 and R2 advertises the prefix P2. At this stage,
hosts would have the LinkidPrefixList {P1}.
R2 starts advertising a new prefix P3, which happens to be the
smallest one, hence a new linkid prefix. R2 sends an RA with P3
(with I-bit set) and P1 (without I-bit set). A host sees the RA with
a new linkid prefix but will not assume a link change because of P1.
The host simply adds P3 to its LinkidPrefixList and the
LinkidPrefixList becomes {P1, P3}.
Then because of packet loss R1 doesn't receive the RA and sends an RA
with P1 (with I-bit set) but without P3. The host sees an another RA
with a different linkid prefix but will not assume a link change
because of P1. The LinkidPrefixList is still {P1, P3}
Afterwards R1 belatedly notices a linkid change and starts
Choi & Madanapalli Expires December 30, 2005 [Page 6]
Internet-Draft linkid prefix June 2005
advertising P3 as the linkid prefix. Again the host doesn't assume a
link change because of P1 and the LinkidPrefixList is {P1, P3}.
During the whole transition period, the prefix P1 in the
LinkidPrefixList plays the role of assuring hosts of no link change.
2.5 LPIO (Learned Prefix Information Option)
When routers advertise learned prefixes, they use LPIO instead of
ordinary PIO.
LPIO format is TBD but it at least needs to include
o prefix length
o prefix
o Identifier bit (I-bit) (indicating the prefix in the LPIO is the
linkid)
Sub-sec 7.1 gives the detailed discussion about LPIO format.
2.6 Identifier bit (I-bit)
A bit in PIO or LPIO which indicates that the prefix in this option
is the linkid prefix.
Identifer bit (I-bit) format is TBD.
Choi & Madanapalli Expires December 30, 2005 [Page 7]
Internet-Draft linkid prefix June 2005
3. Router Operations
3.1 Data Structures
The routers maintains a set of prefixes advertised by other routers
in the link (called as "learned prefix list (LearnedPrefixList)") per
interface. For each learned prefix, routers maintain the following
information
o Prefix
o Prefix Length
o Valid Life Time
o Last Refreshed Time
For each linkid prefix, routers also need to maintain the time when
the prefix stops being advertised as the linkid prefix. This time
needs to be maintained for both learned prefixes and the prefixes
advertised by the router.
Note that an implementation need not have the data structures as
described above as long as the external behavior is consistent with
that described in this document.
3.2 Collecting the prefixes
To select the linkid prefix, routers should collect all the prefixes
on the link.
A router, when it boots or is configured to act as a router (Sec
6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to gather
prefixes.
Sending one RS and waiting for 4 seconds might suffice; optionally
retransmitting the RS once or twice and waiting a total of 8 or 12
seconds gives higher confidence.
From the received RAs, the router extracts only the valid prefixes in
PIO and generate the "learned prefix list (LearnedPrefixList)". It
is noted that the prefixes the router advertises itself (the
AdvPrefixList in RFC 2461 [1]) are not included in the
LearnedPrefixList.
The router takes the union of the learned prefix list and the
prefixes the router itself advertises to generate the complete prefix
list as defined in [9]
Choi & Madanapalli Expires December 30, 2005 [Page 8]
Internet-Draft linkid prefix June 2005
Once that process is complete, the router will send RAs and respond
to RSs, but not before that.
After initial RS/ RA exchange, the router can send a few closely
spaced RAs as specified in RFC 2461 [1] to quickly spread its own
information on the link.
Whenever a router receives a new prefix in PIO, it will update its
learned prefix list.
Take notice that, for prefix list generation, a router only takes the
prefixes in PIO into consideratoin.
3.3 Selecting the linkid prefix
Among the prefixes 1) whose valid lifetime is greater than
LEAST_VALID_LIFETIME, i.e. 3 hours and 2) which is received within
1.5 hours in case of a learned prefix, the router picks the smallest
prefix as the linkid prefix.
* There are other ways to determine the linkid prefix. We may choose
any subset of the complete prefix list and pick the smallest or
greatest one of it.
When a router receives a new prefix in PIO, (with or without
identifier bit (I-bit) set), if the prefix is smaller than the
current linkid prefix and has valid lifetime greather than 3 hours,
the router selects the new prefix as a new linkid prefix.
In case the new prefix smaller than the current linkid prefix is
advertised in LPIO, the router doesn't change the linkid prefix.
3.4 Advertising the linkid prefix
Whenever a router sends an RA, whether solicited or unsolicited, it
includes the linkid prefix in it. Hence, all RAs carry the linkid
prefix.
When a router advertises the linkid prefix, if the linkid prefix is
explicitly configured on the router, it sends it in PIO with I-bit
set.
If not, the router sends the linkid prefix in LPIO with I-bit set.
3.5 Graceful linkid prefix change
Basic idea is, when a router changes a linkid prefix, for the time
being, it sends both 1) new linkid prefix with I-bit set and 2) old
Choi & Madanapalli Expires December 30, 2005 [Page 9]
Internet-Draft linkid prefix June 2005
linkid prefix without I-bit set to notify hosts that only linkid has
been changed without a link change.
3.5.1 When a new linkid prefix is added.
When a router starts advertising a new prefix, if the prefix happens
to be the smallest one in the link, a linkid prefix needs to be
changed.
First the router sends to all-node multicast address an RA with 1)
new linkid prefix with I-bit set and 2) old linkid prefix without
I-bit set several times.
Upon receiving this RA, because new prefix is smaller than the
current linkid prefix, routers would change the linkid prefix to the
new one.
Old linkid prefix (whether its I-bit set or not) assures hosts that
they still remain at the same link. So hosts would simply update its
LinkidPrefixList without any outward activity, such as sending an RS.
3.5.2 When the linkid prefix lifetime decreases to
LEAST_VALID_LIFETIME.
When the valid lifetime of the linkid prefix becomes
LEAST_VALID_LIFETIME, i.e. 3 hours, it is no longer a linkid.
A router decreases the prefix lifetime in real-time and at the moment
the prefix lifetime becomes 3 hours, the router selects a new linkid
prefix and stops advertising the I-bit on the (old) linkid prefix.
For the time being, when the router sends RA, it includes 1) new
linkid prefix with I-bit set and 2) old linkid prefix without I-bit
set to assure hosts that they still remain at the same link.
3.5.3 When the linkid prefix is removed while its lifetime is greater
than LEAST_VALID_LIFETIME.
A router may want to remove the linkid prefix before the valid
lifetime decreases to 3 hours.
When a router stops advertising a linkid prefix, it removes the
prefix in two steps as below.
First the router picks the second smallest prefix as the new linkid
prefix.
It sends to all node multcast address an RA with 1) new linkid prefix
Choi & Madanapalli Expires December 30, 2005 [Page 10]
Internet-Draft linkid prefix June 2005
with I-bit set and 2) old linkid prefix with 2 hours as valid
lifetime & without I-bit set.
Upon receiving this RA, routers would see the (old) linkid prefix in
PIO with the valid lifetime less than LEAST_VALID_LIFETIME. Hence
they also would select the second smallest one as the new linkid and
starts advertising it with I-bit set.
When hosts receives this RA, they would have non-zero linkid lifetime
for the (old) linkid prefix, becuase, at least, two RAs with (old)
linkid prefix were sent within 1 hour according to MaxRtrAdvInterval
value defined in [1]. Therefore, hosts would update its linkid
prefix but would not assume a link change because of (old) linkid
prefix.
Upon sending such an RA several times, once the router is sure that
all routers have changed their linkid, it can remove the (old) prefix
linkid entirely by advertising the prefix with zero lifetime value.
For example, assume a router R advertise the linkid prefix P1 and the
second smallest prefix is P2.
When the valid lifetime of P1 is 7 days, R wants to remove P1 from
the link.
If R immediately advertises an RA with 1) P1 with zero lifetime and
2) P2 with I-bit set, hosts may treat this as a link change, because
they would discard P1 entirely when seeing it with zero lifetime.
So instead, R removes P1 in two steps. First, R advertises an RA
with 1) P1 with lifetime 2 hours and 2) P2 with I-bit set.
Then hosts would know this is just a linkid change without a link
change from (old) linkid prefix P1. Also other routers would know P1
is no longer linkid prefix, because P1 has lifetime less than
LEAST_VALID_LIFETIME.
After a while, when R is sure that all nodes on the link have
perceived linkid change, it can safely remove P1 by advertising it
with zero lifetime.
Also it's recommended that once a prefix has been advertised with a
lifetime that results in a prefix invalidation at time Ti, then the
router should advertise the prefix with a valid lifetime=0 until time
Ti has passed.
Choi & Madanapalli Expires December 30, 2005 [Page 11]
Internet-Draft linkid prefix June 2005
3.5.4 When the Linkid prefix (Learned Prefix) is not advertised in the
last 1.5 hours
If the Linkid prefix advertised by the router is learned prefix and
it was not refreshed in the last 1.5 hours, the router will select
new Linkid prefix and advertises the previous Linkid prefix as old
linkid for next 1.5 hours.
Choi & Madanapalli Expires December 30, 2005 [Page 12]
Internet-Draft linkid prefix June 2005
4. Host Operations
4.1 Managing the LinkidPrefixList
While routers manage a single linkid prefix, hosts track all the
linkid prefixes it has seen in the last 1.5 hours to keep the linkid
prefix list (LinkidPrefixList) per a link.
When the host has decides it has moved to a different link, it
discards the LinkidPrefixList from the old link.
If a host has no linkid prefix, i.e. its LinkidPrefixList is empty,
it sends an RS according to the procedure defined in RFC 2461 [1] to
acquire one.
After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no
RA with a linkid prefix arrives, the host assumes it is at a non-
supporting link and falls back on CPL [9].
Whenever a host receives an RA, it checks whether the RA includes a
prefix with identifier bit (I-bit) set.
If the RA contains such a prefix, the host extracts the prefix and
sets its linkid lifetime as 1.5 hour and starts timer.
The linkid lifetime for the prefix should decrement in real time that
is, at any point in time they will be the remaining lifetime. An
implementation could handle that by recording the 'expire' time for
the information, or by periodically decrementing the remaining
lifetime.
Then the host check for link change as described in Sub-sec 4.2. If
the host assumes a link change, it discards the current
LinkidPrefixList and makes a new LinkidPrefixList with the new prefix
with I-bit set. If not, the host adds the new linkid prefix to the
current LinkidPrefixList (unless the prefix already belongs to the
LinkidPrefixList).
The host keeps a linkid prefix in the LinkidPrefixList as long as it
has non-zero linkid lifetime and valid (prefix) lifetime.
When the linkid lifetime for the prefix expires, the prefix becomes
an ordinary prefix. Hosts remove it from the LinkidPrefixList but
keep it until its valid lifetime expires.
Take notice that, when the LinkidPrefixList becomes empty, i.e. the
linkid lifetime of all prefixes in the LinkidPrefixList expires, the
host doesn't assume a link change.
Choi & Madanapalli Expires December 30, 2005 [Page 13]
Internet-Draft linkid prefix June 2005
A prefix in the LinkidPrefixList may become invalid (as a prefix).
The prefix may be advertised with zero lifetime or the host moves to
an another link. In those cases, the host discards the prefix just
like an ordinary prefix according to RFC 2461 [1].
4.2 Checking for link change
When a host doesn't have a linkid prefix, i.e. its LinkidPrefixList
is empty, it relies on CPL [9] to check for link change.
When a host with a linkid prefix receives a hint of a possible link
change, such as Link Up event notification [10], it may send an RS to
all-router multicast address to get an RA with a linkid prefix.
After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no
RA with a linkid prefix arrives, the host assumes it is at a non DNA
link and falls back on CPL [9].
When a host with a linkid prefix receives an RA, whether solicited or
unsolicited, that includes a prefix with I-bit set, the host compares
its LinkidPrefixList with the set of prefixes in the RA.
If there is a common prefix, i.e. the RA also includes the prefix in
the LinkidPrefixList, the host assumes that it still remains at the
same link.
Note that the common prefix need not be the linkid prefix in the RA.
If not, the host assumes that it has moved to a new link, discards
its LinkidPrefixList and starts a new one.
Choi & Madanapalli Expires December 30, 2005 [Page 14]
Internet-Draft linkid prefix June 2005
5. IANA Considerations
This draft will define one new Neighbor Discovery [1] option and a
new flag in PIO (Prefix Information Option), which must be assigned
Option Type values within the option numbering space for Neighbor
Discovery messages:
1. LPIO (Learned Prefix Information Option), described in Sec 2.
2. Identifier bit (I-bit) in PIO (Prefix Information Option),
described in Sec 2.
Choi & Madanapalli Expires December 30, 2005 [Page 15]
Internet-Draft linkid prefix June 2005
6. Security Considerations
Because this DNA proposal is based on Neighbor Discovery, its trust
models and threats are similar to the ones presented in [7]. Nodes
connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks. Use of SEND [6] to
secure Neighbor Discovery are important in achieving reliable
detection of network attachment. This DNA proposal SHOULD
incorporate the solutions developed in IETF SEND WG if available,
where assessment indicates such procedures are required.
Choi & Madanapalli Expires December 30, 2005 [Page 16]
Internet-Draft linkid prefix June 2005
7. Open Issues
7.1 Issue 001: LPIO format
For LPIO format, there are two approaches under consideration:
1. A minimalist DNA approach - just carry what DNA needs
2. A complete copy of the PIO (Prefix Information Option)
For the first case, we can use the following option similar to
landmark option in [13] that includes only prefix length, prefix and
identifier bit (I-bit).
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 |I| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Linkid Prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the second case, we can reuse PIO format with a different code.
The learning router would not assume it knows anything about the PIO
it received but blindly send it (after only changing the option code
to "LPIO").
The choice has to do with guessing how the PIO might evolve over time
(new flags etc and their semantics). Perhaps the second approach
might help as the PIO content evolves but, at this point, it is hard
to tell.
We don't see much utility for a middle ground where LPIO includes
some things which DNA doesn't need, but doesn't include everything
that was in the PIO.
7.2 Issue 002: Advertising old linkid prefix
When a router changes a linkid prefix, to notify hosts that only
linkid has been changed without a link change, the router sends both
1) new linkid prefix with I-bit set and 2) old linkid prefix without
I-bit set for a while. It is needed to set a normative value about
how long the router keeps advertising old linkid prefix after linkid
Choi & Madanapalli Expires December 30, 2005 [Page 17]
Internet-Draft linkid prefix June 2005
change. The value under consideration is 1.5 hour.
7.3 Issue 003: Flash renumbering and early reassignment
A useful definition of flash renumbering is that the prefix is
removed from a link earlier than its latest advertised expiry time.
We define "flash renumbering and early reassignment", as the above
plus the prefix being assign to another link before the latest
advertised expiry time on the old link.
Flash renumbering and early reassignment does have potential impact
on DNA, (when using prefixes to identify links), because the host
might move "in parallel" with the reassigned prefix, and therefor
fails to detect movement when it in fact moved. Note that the prefix
might have been advertised with a zero valid lifetime on the link,
but the host might not notice this since it might already have
disconnected from the old link when these RAs were sent.
To resolve this issue, this draft proposes that, when a linkid prefix
is removed from a link, the linkid prefix should not be re-assigned
to other link in 3 hours. With the above, a host would not see the
same linkid prefix in two different links because linkid lifetime is
1.5 hour.
7.4 Issue 004: DAD Interaction
The draft needs to describe the DNA interaction with DAD such as what
steps a host should go through with respect to DAD. The procedure
under consideration is described in Sec 3 in [8]
7.5 Issue 005: MLD Interaction
The draft needs to describe the DNA interaction with MLD such as what
steps a host should go through with respect to MLD. The procedure
under consideration is described in Sec 3 in [8]
7.6 Issue 006: Sending RA before completing prefix collection
According to Sec 6.1, routers can't respond at all to RSs before
completion of the soliciting phase. Brett Pentland proposed to relax
this restriction.
7.7 Issue 007: Linkid prefix option for RS message
Right now, when a host sends an RS, it doesn't notify its linkid
prefix. But it may be useful for a host to select a prefix in its
linkid prefix list to put it in an RS, so that, upon reception of the
linkid prefix, routers can determine whether the host remains at the
Choi & Madanapalli Expires December 30, 2005 [Page 18]
Internet-Draft linkid prefix June 2005
same link and send only the minimal information in case of non-link
change.
For this, we may define new linkid prefix options for RS messages as
below.
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 Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Linkid prefix ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Further analysis such as trade-off between bandwidth saving and added
complexity is necessary to ascertain the usefulness of this linkid
prefix option.
7.8 Issue 008: Linkid Selection Scheme
Right now, routers select the smallest prefix among the prefixes on a
link as the linkid prefix. However, there are other ways to select
the linkid from the complete prefix list. In fact any deterministic
selecting algorithm can do.
Syam Madanapalli suggested that routers use the longest valid prefix
time as the selector for the linkid prefix because this way linkid
will be valid for more time. Greg Daley proposed to select the most
(natively) advertised prefix as the linkid because it's guaranteed to
produce the minimum number of additionally advertised prefixes.
Choi & Madanapalli Expires December 30, 2005 [Page 19]
Internet-Draft linkid prefix June 2005
8. Comparison with landmark based approach
We present a bit of comparison between linkid based approach in this
draft and landmark based approach defined in [13].
C1 Linkid scheme does not add any extra options in an RS, whereas
landmark scheme adds a new landmark option in an RS.
C2 In linkid scheme, when solicited, routers can send either unicast
RA or multicast RA. Whereas, in landmark scheme, the usual
response to an RS should be an unicast RA. Hence a soliciting RS
should carry TSLLAO [19] and a mechanism is needed to limit the
rate at which unicast RAs are sent.
C3 Linkid scheme works well when a link has lots of prefixes; in
particular when there are so many prefixes that all the PIOs &
LPIOs can not fit in one RA to form a Complete RA.
C4 When a prefix is added or removed in a link, routers may give
conflicting information about link identity. Linkid scheme can
correctly check for link change even under such an inconsistency.
Choi & Madanapalli Expires December 30, 2005 [Page 20]
Internet-Draft linkid prefix June 2005
9. 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). Design Team members privide enlightening feedback and
sometimes even more. Parts of this draft are direct cut and paste
from the Design Team mailing list.
Choi & Madanapalli Expires December 30, 2005 [Page 21]
Internet-Draft linkid prefix June 2005
10. References
10.1 Normative References
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Choi, J., "Goals of Detecting Network Attachment in IPv6",
draft-ietf-dna-goals-04 (work in progress), December 2004.
10.2 Informative References
[5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[6] 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.
[7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[8] Choi, J. and E. Nordmark, "DNA solution framework",
draft-ietf-dna-soln-frame-00 (work in progress), April 2005.
[9] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-00 (work in progress),
April 2005.
[10] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-01 (work
in progress), February 2005.
[11] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005.
[12] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005.
[13] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-pentland-dna-protocol-00 (work in progress),
Choi & Madanapalli Expires December 30, 2005 [Page 22]
Internet-Draft linkid prefix June 2005
May 2005.
[14] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001.
[15] Pentland, B., "Router Advertisement Link Identification for
Mobile IPv6 Movement Detection",
draft-pentland-mobileip-linkid-03 (work in progress),
October 2004.
[16] Choi, J., "Fast Router Discovery with RA Caching",
draft-jinchoi-dna-frd-00 (work in progress), July 2004.
[17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
progress), July 2004.
[18] Daley, G., "Deterministic Fast Router Advertisement
Configuration", draft-daley-dna-det-fastra-01 (work in
progress), October 2004.
[19] Daley, G., "Tentative Source Link-Layer Address Options for
IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in
progress), February 2005.
Authors' Addresses
JinHyeock Choi
Samsung AIT
Communication & N/W Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
Email: jinchoe@samsung.com
Syam Madanapalli
Samsung ISO
3/1 Millers Road
Bangalore 560 052
INDIA
Phone: +91-8-51197777
Email: syam@samsung.com
Choi & Madanapalli Expires December 30, 2005 [Page 23]
Internet-Draft linkid prefix June 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.
Choi & Madanapalli Expires December 30, 2005 [Page 24]
