draft-ietf-dna-protocol-00.txt   draft-ietf-dna-protocol-01.txt 
DNA Working Group J. Kempf DNA Working Group J. Kempf
Internet-Draft DoCoMo Communications Labs USA Internet-Draft DoCoMo Communications Labs USA
Expires: August 30, 2006 S. Narayanan Expires: December 27, 2006 S. Narayanan
Panasonic Panasonic
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
B. Pentland, Ed. B. Pentland, Ed.
Monash University CTIE Monash University CTIE
JH. Choi JH. Choi
Samsung AIT Samsung AIT
February 26, 2006 June 25, 2006
Detecting Network Attachment in IPv6 Networks (DNAv6) Detecting Network Attachment in IPv6 Networks (DNAv6)
draft-ietf-dna-protocol-00.txt draft-ietf-dna-protocol-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2006. This Internet-Draft will expire on December 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Efficient detection of network attachment in IPv6 needs the following Efficient detection of network attachment in IPv6 needs the following
two components: a method for the host to query routers on the link to 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 identify the link (Link Identification) and a method for the routers
skipping to change at page 3, line 42 skipping to change at page 3, line 42
5.1.10 Removing a Prefix from an Interface . . . . . . . . 20 5.1.10 Removing a Prefix from an Interface . . . . . . . . 20
5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21
5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21
5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21
5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22
5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22 5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22
5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23 5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23
5.2.5 Processing Router Advertisements . . . . . . . . . . . 23 5.2.5 Processing Router Advertisements . . . . . . . . . . . 23
5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25 5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 28 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 29
6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 28 6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 29
6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 28 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . 29
7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 28 7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29
7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29 7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1 Normative References . . . . . . . . . . . . . . . . . . 30 10.1 Normative References . . . . . . . . . . . . . . . . . . 31
10.2 Informative References . . . . . . . . . . . . . . . . . 30 10.2 Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 32 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . 35
1. Introduction 1. Introduction
The proposed scheme in this memo is built upon the following The proposed scheme in this memo is built upon the following
solutions catalogued in [16]: Complete RA is used for the link solutions catalogued in [16]: Complete RA is used for the link
identification, and Hash-based Fast RA is used to achieve fast identification, and Hash-based Fast RA is used to achieve fast
response to RS messages. Aspects of prefix-based LinkID and response to RS messages. Aspects of prefix-based LinkID and
Requested Landmark are included to allow for a decrease in the packet Requested Landmark are included to allow for a decrease in the packet
sizes associated with Complete RA. sizes associated with Complete RA.
skipping to change at page 17, line 7 skipping to change at page 17, line 7
first 64 bits of an SHA-1 hash of the source address. The entry's first 64 bits of an SHA-1 hash of the source address. The entry's
expiry time is updated. expiry time is updated.
Regardless of the state of the FastRA flag, each PIO in the RA is Regardless of the state of the FastRA flag, each PIO in the RA is
examined. If the prefix is not in the router's DNARouterPrefixList examined. If the prefix is not in the router's DNARouterPrefixList
and not in the router's AdvPrefixList [3], it is added to the and not in the router's AdvPrefixList [3], it is added to the
DNARouterPrefixList, and its expiry time is set. DNARouterPrefixList, and its expiry time is set.
5.1.5 Processing Router Solicitations 5.1.5 Processing Router Solicitations
All Router Advertisements sent by a DNA router MUST have the "F" flag The usual response to a Router Solicitation SHOULD be a unicast RA.
set so that hosts processing them know that they can count on the However, to keep control of the rate of unicast RAs sent, a token
content being interpretable according to this specification. bucket is used. The token bucket is filled at one token every
UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored.
The usual response to an RS SHOULD be a unicast RA. However, to keep When a Router Solicitation is received, the router checks if it is
control of the rate of unicast RAs sent, a token bucket is used. The possible to send a unicast response. A unicast response requires
token bucket is filled at one token every UnicastRAInterval. A that the following conditions to be met:
maximum of MaxUnicastRABurst tokens are stored.
In order to respond to a Router Solicitation, the router SHOULD o A unicast send token is available.
generate a Complete RA as specified in Section 5.1.6. The Router
Advertisement MUST include the LinkID, as described in Section 5.1.7.
If a unicast send token is available AND the source address of the o The source address of the Router Solicitation is NOT the
Router Solicitation is NOT the unspecified address (::), then a token unspecified address (::).
is removed and the Router Advertisement is scheduled for transmission
as specified in Section 5.1.8.
If no unicast send token is available OR the source address of the If a unicast response is possible and the Router Solicitation
Router Solicitation is the unspecified address, then if there is no contains a Landmark Option whose prefix is included in
multicast RA scheduled for transmission in the next MulticastRADelay DNARouterPrefixList or AdvPrefixList, the router SHOULD send an
the RA MUST be sent to the link-scoped all-nodes multicast address at abbreviated Router Advertisement.
the current time plus MulticastRADelay.
If no unicast send token is available OR the source address of the This abbreviated advertisement includes only the Landmark Option,
Router Solicitation is the unspecified address but there is a with the "Y" flag set, plus the base RA header and any SEND options
multicast RA scheduled for transmission in the next MulticastRADelay, as appropriate. The FastRA flag MUST be set. The Complete flag MUST
then the Router Solicitation MUST be dropped. NOT be set. This is the one exception where the LinkID MAY be
omitted as the Y flag implies that link change has not occured and
that the previously received LinkID is still current.
5.1.5.1 Space Optimized Advertisements If there is NO Landmark Option in the received Router Solicitation or
it contains a Landmark Option whose prefix is NOT included in
DNARouterPrefixList or AdvPrefixList or a unicast response is not
possible, then the router SHOULD generate a Complete RA as specified
in Section 5.1.6. The Router Advertisement MUST include the LinkID,
as described in Section 5.1.7.
If the Router Solicitation contains a Landmark Option whose prefix is If a unicast response is possible, then a token is removed and the
included in DNARouterPrefixList or AdvPrefixList AND the Router Advertisement is scheduled for transmission as specified in
corresponding Router Advertisement will be unicast, the router MAY Section 5.1.8.
send an abbreviated Router Advertisement.
The abbreviated advertisement includes only the Landmark Option, with If a unicast response is not possible and there is no multicast RA
the "Y" flag set, plus the base RA header and any SEND options as already scheduled for transmission in the next MulticastRADelay the
appropriate. The Complete flag MUST NOT be set. This is the one RA MUST be sent to the link-scoped all-nodes multicast address at the
exception where the LinkID MAY be omitted as the Y flag implies that current time plus MulticastRADelay.
link change has not occured.
Some prefixes may also be omitted from unsolicited Router If a unicast response is not possible but there is a multicast RA
Advertisements, as described in Section 5.1.9. already scheduled for transmission in the next MulticastRADelay, then
the Router Solicitation MUST be silently discarded.
5.1.6 Complete Router Advertisements 5.1.6 Complete Router Advertisements
A CompleteRA is formed as follows: A CompleteRA is formed as follows:
Starting with a Router Advertisement with all fixed options (MTU, Starting with a Router Advertisement with all fixed options (MTU,
Advertisement Interval, flags, etc.), the FastRA flag is set. As Advertisement Interval, flags, etc.), the FastRA flag is set. As
many Prefix Information Options for explicitly configured prefixes as many Prefix Information Options for explicitly configured prefixes as
will fit are added to the Router Advertisement. If there is will fit are added to the Router Advertisement. If there is
sufficient room, a Learned Prefix Option as defined in Section 4.4 sufficient room, a Learned Prefix Option as defined in Section 4.4
skipping to change at page 24, line 26 skipping to change at page 24, line 26
DNAHostPrefixList, then the host can conclude that it has changed DNAHostPrefixList, then the host can conclude that it has changed
link and SHOULD initiate re-configuration using the information in link and SHOULD initiate re-configuration using the information in
the received Router Advertisement. the received Router Advertisement.
If the received RA is not complete, contains no prefixes that are If the received RA is not complete, contains no prefixes that are
stored in DNAHostPrefixList, does not contain a Landmark Option stored in DNAHostPrefixList, does not contain a Landmark Option
that matches a corresponding option in the most recent RS and that matches a corresponding option in the most recent RS and
contains no LinkID, then the host SHOULD use CPL logic to decide contains no LinkID, then the host SHOULD use CPL logic to decide
whether or not to reconfigure as described in [15]. whether or not to reconfigure as described in [15].
If the destination address of the received RA is a unicast address,
the host knows the router heard its RS, and hence it SHOULD mark that
router's Neighbor Cache Entry [3] as REACHABLE.
5.2.5.1 Maintaining the DNAHostPrefixList 5.2.5.1 Maintaining the DNAHostPrefixList
If a Router Advertisement does not indicate a link change, the host If a Router Advertisement does not indicate a link change, the host
updates its DNAHostPrefixList, adding any new prefixes if necessary. updates its DNAHostPrefixList, adding any new prefixes if necessary.
If the Router Advertisement has the C flag set, then the host SHOULD If the Router Advertisement has the C flag set, then the host SHOULD
make the DNAHostPrefixList match the contents of the advertisement. make the DNAHostPrefixList match the contents of the advertisement.
Any new prefixes are added and any prefixes in the list that are Any new prefixes are added and any prefixes in the list that are
absent in the advertisement are removed. Expiry times on prefixes absent in the advertisement are removed. Expiry times on prefixes
are updated if the prefix was contained in a PIO, but not if it was are updated if the prefix was contained in a PIO, but not if it was
skipping to change at page 25, line 5 skipping to change at page 24, line 47
If the Router Advertisement does not have the C flag set, then the If the Router Advertisement does not have the C flag set, then the
host SHOULD add any new prefixes and update expiry times as above, host SHOULD add any new prefixes and update expiry times as above,
but SHOULD NOT remove any entries from DNAHostPrefixList. but SHOULD NOT remove any entries from DNAHostPrefixList.
When initiating reconfiguration due to link change, the host MUST When initiating reconfiguration due to link change, the host MUST
remove all prefixes in the DNAHostPrefixList and repopulate it with remove all prefixes in the DNAHostPrefixList and repopulate it with
the prefixes in the Prefix Information Options and Learned Prefix the prefixes in the Prefix Information Options and Learned Prefix
Option, if any, in the RA. Option, if any, in the RA.
5.2.5.2 Router Reachability Detection and Default Router Selection
The receipt of a unicast RA from a router in response to a multicast
RS indicates that the host has bi-directional reachability with the
routers that responded. Such reachability is necessary for the host
to use a router as a default router, in order to have packets routed
off the host's current link. If the destination address of the
received RA is a unicast address, the host knows the router heard its
RS, and therefore that the host has reachability with the router.
Prior to sending a DNA RS in response to an indication of link
change, the host SHOULD set all Neighbor Cache entries for routers on
its Default Router List to STALE. When the host receives an RA in
reply to the RS, the host SHOULD mark that router's Neighbor Cache
Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
REACHABLE state if one does not currently exist.
The host SHOULD also update its Default Router List in the following
fashion. If any of the routers returning RAs are already on the
default router list, the host SHOULD use the information in the RA to
update the Default Route List entry with the new information. The
host SHOULD add entries to the Default Router List for any routers
returning RAs that are not on the list. The host SHOULD confine
selection of a router from the Default Router List to those routers
whose Neighbor Cache entries are in the REACHABLE state. Note that
the Default Router List SHOULD be updated as described here
regardless of whether the RA indicates that the host has changed to a
new IP link, since changes in router reachability are possible on
some link types even if the host remains on the same IP link.
Note that this procedure does not prevent a MN from sending packets
to its current default router while the RA solicitation is in
progress and if reachability with the current default router is
unchanged, there should be no change in default router after the RA
solicitation completes. If the current default router is still
reachable, it will forward the packets.
5.2.6 DNA and Address Configuration 5.2.6 DNA and Address Configuration
When a host moves to a new point of attachment, a potential exists 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 for a change in the validity of its unicast and multicast addresses
on that network interface. In this section, host processing for on that network interface. In this section, host processing for
address configuration is specified. The section considers both address configuration is specified. The section considers both
statelessly and statefully configured addresses. statelessly and statefully configured addresses.
5.2.6.1 Duplicate Address Detection 5.2.6.1 Duplicate Address Detection
 End of changes. 23 change blocks. 
56 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/