Internet DRAFT - draft-chen-dnav6-apid
draft-chen-dnav6-apid
DNA BoF Zhigao Chen
Internet Draft Juh Khang Loh
Document: draft-chen-dnav6-apid-00.txt Panasonic Singapore Labs
Expires: August 8, 2004 February 9, 2004
IPv6 Detecting Network Attachment Based on Access Point ID
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes an IPv6 network attachment detection
mechanism in which access routers disseminate the identifiers of on-
link access points reported by hosts. By caching the identifiers,
hosts assess the likelihood of an L3 link change right after an
access point change. The hosts are hence able to quickly determine
whether an existing IP address configuration can be reused or a new
one should be acquired. The mechanism aims to achieve fast L3
connectivity re-establishment with less signaling overhead.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
Chen & Loh Expires - August 2004 [Page 1]
Internet-Draft APID-based DNAv6 February 2004
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Overview.......................................................4
3.1 Movement Scenarios.........................................4
3.2 Reporting an APID..........................................5
3.3 Disseminating an APID List.................................5
3.4 Reachability Test and Address Validation...................6
4. New IPv6 Neighbor Discovery Options............................7
4.1 New APID Option Format.....................................7
4.2 New APID List Option Format................................8
5. Conceptual Model...............................................9
5.1 Conceptual Data Structures.................................9
5.2 Garbage Collection........................................10
6. Additional Operation for Hosts................................10
6.1 Receiving L2 Link-up Hints................................11
6.2 Receiving Unicast Router Advertisements...................12
6.3 Receiving Multicast Router Advertisements.................12
7. Additional Operation for Access Routers.......................13
7.1 Receiving Unicast Router Solicitations....................13
7.2 Receiving Multicast Router Solicitations..................14
8. Protocol Constants............................................14
9. IANA Considerations...........................................14
10. Security Considerations......................................14
11. Acknowledgements.............................................15
References.......................................................15
Appendix A: Applicability to Movement Detection..................16
Authors' Address.................................................17
Intellectual Property Statement..................................17
Full Copyright Statement.........................................18
1. Introduction
When attaching to a network, a host acquires IPv6 address(es) by
performing Duplicate Address Detection (DAD) followed by router
discovery [ADDRCONF]. Fast network attachment detection is desirable
especially when a host with ongoing sessions intermittently changes
its point of attachment from one access point to another. If router
discovery is done before or in parallel with DAD, solicited Router
Advertisements (RA) have to be sent in multicast since no unicast
address is yet assigned to the host at the time of sending Router
Solicitation (RS).
The link layer handover taking place during the access point change
does not necessarily constitute an L3 link change. The IPv6 address
configuration available on the host might still be valid and reusable
after the access point change. As a result, the acquisition of a new
Chen & Loh Expires - August 2004 [Page 2]
Internet-Draft APID-based DNAv6 February 2004
IPv6 address is not always necessary. To confirm the validity of the
address configuration, the reachability test of the default router
and the validation of the IP address are believed to be imperative
[DNAPS-00].
R and S bits for RA are proposed in [RA-00] to provide more adequate
information for network attachment detection. R bit together with
the global scope router address in a Prefix Information Option
enables a host to unambiguously determine if a received RA is from a
specific router. S bit enables reachability test to be done in RS/RA
exchange without additional NS/NA.
An access point identifier is generally supplied in an L2 Link-up
hint [L2HINT-00], which is available to a host upon establishing an
L2 link with an access point. This information can be used to assist
hosts in detecting network attachment efficiently.
2. Terminology
The following terminology and abbreviation are used in the document.
AP Access Point. A generic access point is an L2 entity
which extends an L2 link in a wired network over a
wireless link, for example an access point in Wireless LAN
and Bluetooth, an SGSN in GPRS.
APID Access Point Identifier. An identifier of an access point
unique within an access network, for example the MAC
address of an access point in IEEE 802.11, the AP ID of an
access point in HIPERLAN, the BD ADDR of an access point
in Bluetooth, the RAI of an SGSN in GPRS.
AR Access Router. An L3 entity resides in an access network
and provides L3 connectivity to hosts. An AR is connected
to one or multiple APs.
CurDefAR Current Default Access Router. A default router used by a
host prior to an L2 handover.
NewDefAR New Default Access Router. A default router to be used by
a host subsequent to an L2 handover. If the two APs
involved in the L2 handover are on the same L3 link, the
NewDefAR is the same one as the CurDefAR.
PreDefAR Previous Default Access Router. A default router used by
a host prior to the last L2 handover. If the two APs
involved in the L2 handover are on the same L3 link, the
PreDefAR is the same one as the CurDefAR.
Chen & Loh Expires - August 2004 [Page 3]
Internet-Draft APID-based DNAv6 February 2004
3. Overview
The document presents a Detecting Network Attachment (DNA) mechanism
to allow hosts to reuse their existing IPv6 address configuration
after an L2 handover. In the proposal, hosts report the identifiers
of unknown APs using RS, and ARs disseminate the identifiers of all
on-link APs using RA to the hosts on the local link. Hosts store the
APIDs disseminated by their default ARs (at least include CurDefAR
and PreDefAR, whether to include more previous default ARs is up to
individual implementers) in an APID Cache.
As soon as an L2 link is up, a host searches its APID Cache for the
APID supplied in the Link-up hint. If the APID is found present, the
host perceives it remains on the same link or comes back to a link
where its current or previous address configuration is probably valid
respectively. Once reachability test and address validation pass,
the host fast re-establishes L3 connectivity with the existing
address.
3.1 Movement Scenarios
This section describes the movement scenarios where a current or
previous address configuration can probably be reused. Figure 1
shows a typical layout of APs and ARs in an access network. There
could be multiple ARs on a L3 link, although for simplicity only the
host's default AR is shown in the figure.
+--+--+ +--+--+
| AR1 | | AR2 |
+--+--+ +--+--+
| |
+---------+---------+ |
~~~~~~~~|~~~~~~~~~ ~~~~~~~~|~~~~~~~~ ~~~~~~~~|~~~~~~~~
/ | \/ | \/ | \
/ +--+--+ /\ +--+--+ /\ +--+--+ \
/ | AP1 | / \ | AP2 | / \ | AP3 | \
/ +-----+ / \ +-----+ / \ +-----+ \
| | | | | |
| M1 ---|--> | +---|--> | |
| | | | | | |
| M2 ---|--> | +---|-- M3 | |
| | | | | |
\ \ / \ / /
\ \ / \ / /
\ Cell1 \/ Cell2 \/ Cell3 /
\ /\ /\ /
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
Figure 1: Movement Scenarios
Chen & Loh Expires - August 2004 [Page 4]
Internet-Draft APID-based DNAv6 February 2004
o Visit an unknown AP on the same link (M1)
A host moves into Cell2 for the first time and changes its network
attachment from AP1 to AP2. The APID of AP2 is not present in its
APID Cache, which may be because AP2 has not been reported to AR1
yet or because AR1 disseminated the APID in Cell1 at a time when
the host is away. AR1 is host's CurDefAR and NewDefAR.
o Visit a known AP on the same link (M2)
A host moves into Cell2 and changes its network attachment from
AP1 to AP2. The APID of AP2 is present in its APID Cache as the
host has received a dissemination containing the APID before the
movement. AR1 is the host's CurDefAR and NewDefAR.
o Visit a known AP on a different link (M3)
A host moves out of Cell3 and moves back in by changing its
network attachment to AP3 again. As long as the host is not away
from the L3 link for long, the APID of AP3 is still kept in its
APID Cache. AR1 is the host's CurDefAR and AR2 is its PreDefAR
and NewDefAR.
3.2 Reporting an APID
The mechanism requires a host to report any APID not present in its
APID Cache. A new APID Option is defined for RS in Section 4.1 to
convey an APID.
There are two types of reporting depending on a host's movement
scenario. A host reports an APID normally in a unicast RS to its
NewDefAR after acquiring a new address configuration through DAD and
router discovery. For M1, a host MAY report the APID in a multicast
RS to all the on-link ARs in a hope of realizing the reusability of
its current address configuration (see Section 6.1 for details).
ARs might take some time to learn all their on-link APIDs (called
APID List thereinafter) depending on how soon hosts discover new APs.
The sooner hosts discover and report new APIDs, the faster ARs build
up their APID Lists.
3.3 Disseminating an APID List
When receiving an RS with a reported APID, an AR searches its APID
List and disseminates its APID List only when necessary. A new APID
List Option is defined for RA in Section 4.2 to convey an APID List.
Chen & Loh Expires - August 2004 [Page 5]
Internet-Draft APID-based DNAv6 February 2004
If the APID is not found, the AR adds it into its APID List and
includes the updated APID List in the outgoing solicited RA. The RA
is sent in multicast so that the new APID is disseminated on the
link.
If the APID is present, the AR does not include its APID List in the
outgoing solicited RA for the sake of saving bandwidth. However, the
AR MUST include its APID List, if it is the recipient of a unicast
reporting or it identifies itself being the sender's CurDefAR (see
Section 7.2 for details). This ensures the host reporting the APID
updates its APID Cache. The RA is sent in accordance with [NDv6].
In addition to report-triggered dissemination, an AR SHOULD also
include its APID List in unsolicited RAs at a suitable interval.
3.4 Reachability Test and Address Validation
To ascertain the reusability of an existing address configuration
after recognizing an APID, a host performs reachability test and
address validation. This DNAv6 mechanism utilizes R and S bits in
testing the reachability of a default AR.
The host speculates the L3 link does not change, if the APID is
associated with its CurDefAR in the APID Cache. As the L2 handover
latency is considerably short, it is arguably assumed that the host's
current address is not in use by others. As such, DAD is omitted and
the host only needs to test the reachability of the CurDefAR. It
sends a unicast RS using its current link-local address. In
response, the CurDefAR unicasts a solicited RA to the host with R and
S bits set.
The host speculates it is back to a previous L3 link, if the APID is
associated with its PreDefAR in the APID Cache. The host must
perform DAD to validate its previous link-local address and test the
reachability of the PreDefAR. They are done in parallel in order to
be fast. While performing Optimistic DAD [ODAD-03], the host sends a
unicast RS to the PreDefAR using the tentative address. Thus, the
PreDefAR can still unicast a solicited RA to the host with R and S
bits set instead of multicasting the RA. Since the possibility of
address collision on a revisited link is expected to be less than
that on a new link, it makes sense to use Optimistic DAD that is only
useful for very small possibility of collision.
In case of no reply from the default AR being tested, the host MAY
send the RS a few more times in a way similar to Neighbor
Unreachability Detection [NDv6]. Once the AR is determined
unreachable or duplicate address is detected, the host MUST acquire a
new address through router discovery (and DAD, if needed).
Chen & Loh Expires - August 2004 [Page 6]
Internet-Draft APID-based DNAv6 February 2004
To summarize, with APID and the associated default AR information a
host is able to re-establish L3 connectivity faster, whenever a valid
IP address configuration is available. If the host suspects it is on
the same link after an L2 handover, it only needs to perform
reachability test. If the host suspects it is on a link visited
recently (lifetime for configuration has not expired), it in parallel
performs DAD and reachability test. The reachability test in both
cases is carried out using a unicast RS and RA exchange. Sending the
RS with unicast address allows the random delay before sending the
solicited RA to be removed (see Section 7.1) thus further reducing
the overall latency. Moreover, the unicast RS/RA exchange also leads
to less traffic and less disruption to other hosts, compared to
multicast RS/RA exchange ordinarily used.
4. New IPv6 Neighbor Discovery Options
The proposal extends Neighbor Discovery [NDv6] by defining a new APID
Option for RS messages and a new APID List Option for RA messages.
4.1 New APID Option Format
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ CurDefAR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| APID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type TBD. The type value is to be assigned by IANA.
Length The length of the option (including the type and
length fields) in units of 8 octets.
Reserved 16-bit unused field. It MUST be initiated to zero
by the sender and MUST be ignored by the receiver.
CurDefAR Address
Chen & Loh Expires - August 2004 [Page 7]
Internet-Draft APID-based DNAv6 February 2004
The global scope IPv6 address of the sender's
CurDefAR. It MUST be initiated to zero by the
sender and MUST be ignored by the receiver if the
Option is included in a unicast RS.
APID A reported APID. The content and format of this
field, such as byte and bit ordering, vary with
different L2 technologies. The field is of
variable length. For example, it is 6 bytes for an
802.11 APID. If an APID is not aligned on octet
boundary, bit padding MUST be used to ensure that.
Padding bits MUST be set to zero.
Description
The APID Option contains an APID discovered and
reported by the sender of the packet. It is used
in RS messages and MUST be silently ignored for
other Neighbor Discovery messages.
4.2 New APID List Option Format
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 | Num of APID | IDLen | Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. APID List .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type TBD. The type value is to be assigned by IANA.
Length The length of the option (including the type and
length fields) in units of 8 octets.
Num of APID 8-bit unsigned integer. The number of APIDs in the
APID List.
IDLen 4-bit unsigned integer. The length of an APID in
units of octets. The value varies with different
L2 technologies, e.g. 6 for an 802.11 BSSID (IEEE
802 address) and 1 for a HIPERLAN AP ID (10 bits).
Chen & Loh Expires - August 2004 [Page 8]
Internet-Draft APID-based DNAv6 February 2004
Rsrvd 4-bit unused reserved field. It MUST be initiated
to zero by the sender and MUST be ignored by the
receiver.
APID List A list of APIDs disseminated by the sender. If an
APID is not aligned on octet boundary, bit padding
MUST be used. The receiver is to delimitate APID
according to the value in the IDLen field. Padding
bits MUST be set to zero.
Description
The APID List Option contains the identifiers of
all the on-link APs that the sender learns about.
The APID List Option is used in RA messages and
MUST be silently ignored for other Neighbor
Discovery messages.
5. Conceptual Model
This section describes the conceptual model of one possible data
structure organization that hosts and ARs maintain to support this
DNAv6 mechanism. The described organization is provided to
facilitate the explanation of how the entities behave. It does not
mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document.
5.1 Conceptual Data Structures
An AR needs to keep a list, for each interface attached to AP(s), of
reported APIDs in order to disseminate to hosts (via the interface).
APID List - An identifier list of all the APs on-link to one of
the AR's interfaces. APID List entries are created
from the information in the APID Option of a received
RS. Each APID List entry is associated with an
APExiryTimer to flush out the entry once stale.
A host needs to keep an APID Cache to identify whether an APID is
associated with an existing address configuration.
APID Cache - A cache that stores the APID(s) disseminated by the
host's current and previous default AR(s) and some
relevant information of the default AR(s). APID
Cache entries are created from the information in the
APID List Option and the Prefix Information Option of
a received RA.
Each APID Cache entry contains an APID, the global
Chen & Loh Expires - August 2004 [Page 9]
Internet-Draft APID-based DNAv6 February 2004
scope address of the default AR to which the AP is
attached (to verify if an RA comes from the AR whose
reachability is being tested), a flag indicating
that the default AR is a PreDefAR or a CurDefAR
(called DefARType in this document), the link layer
address of the default AR (to send a unicast RS
directly to the default AR during Optimistic DAD),
and the prefix(es) advertised by the default AR (to
time out the APID Cache entry).
The global scope router address is extracted from the
Prefix Information Option of a received RA with R bit
set. A host MUST keep the link layer address of its
default AR to prepare for future reachability test.
APID is chosen as the primary key for APID Cache
entries. In practice, prefixes might already be
stored in the Prefix List [NDv6]. Hence, only their
pointers are needed to be stored in APID Cache.
5.2 Garbage Collection
To limit the storage for the APID List and the APID Cache, an AR and
a host SHOULD flush out stale entries using the following rules.
* APID List on an AR:
- When a new APID is reported, an APID List entry is created and
the associated APExpiryTimer starts.
- When an APID is reported again, the APID List entry is refreshed
by resetting and restarting the APExpiryTimer.
- An APID List entry is removed if not refreshed within
AP_ENTRY_EXPIRY_TIME minutes.
* APID Cache on a host:
- When the invalidation timer for a prefix expires, the
corresponding prefix element in APID Cache entries is cleared.
- Once all the prefix elements of a default AR are cleared, all the
APID Cache entries associated with the default AR are removed.
6. Additional Operation for Hosts
This section describes the operation required for hosts to support
the APID-based DNAv6 mechanism in addition to that in [NDv6].
Chen & Loh Expires - August 2004 [Page 10]
Internet-Draft APID-based DNAv6 February 2004
6.1 Receiving L2 Link-up Hints
Upon establishing a new L2 link with an AP, a host receives a Link-up
hint. Its APID Cache is searched for the APID contained in the hint.
In the case that the APID is already present in an APID Cache entry,
the host retrieves the information elements of the entry.
o If the DefARType flag indicates the default AR is its CurDefAR, it
is more than likely the host is still on the same L3 link. To
ascertain its current address configuration is still valid, the
host MUST send a unicast RS to the CurDefAR. DAD SHOULD be
skipped because the address is virtually impossible to be taken
during link layer handover.
o If the DefARType flag indicates the default AR is its PreDefAR, it
is more than likely the host is back to a previous L3 link. Since
not all the prefixes advertised by the AR have expired after being
away for a while, its previous address configuration might still
be valid. To ascertain the speculation, the host MUST perform
Optimistic DAD and meanwhile send a unicast RS, via the path of
the new L2 link, to the PreDefAR.
During Optimistic DAD, Neighbor Discovery messages sent by the
host, such as the unicast RS and the NS announcing the tentative
address, MUST NOT contain Source Link Layer Address Option. This
is to avoid overriding the Neighbor Caches of neighbors as
required by Optimistic DAD. The host uses the retrieved link
layer address to transmit the unicast RS over link layer.
In the case that the APID is not present, normally there is no
reusable address configuration available, e.g. a host moves from a
non-coverage area; or it just (re)initialized its radio interface; or
the APID Cache entry was purged. Therefore, a new address
configuration must be acquired through DAD and router discovery
described in [ADDRCONF]. Being not urgent, APID reporting is done
after that by sending a unicast RS with an APID Option to the
NewDefAR.
However, in M1 of Figure 1 a host in fact remains on current link
despite the absence of the APID. If it wishes to reuse its current
address configuration, the APID SHOULD be reported in multicast. In
practice, the host may speculate L3 link is unchanged (due to some
clues or rules depending on implementation) and perform router
discovery. The host's CurDefAR, if reachable, is responsive to
router discovery. It is desirable to perform router discovery
(together with reporting the APID) as soon as possible in order to
let the CurDefAR quickly indicate its presence. As such, router
discovery is chosen to be done in parallel with DAD by sending an RS
Chen & Loh Expires - August 2004 [Page 11]
Internet-Draft APID-based DNAv6 February 2004
to all-routers multicast address (FF02::2). The RS has to use the
unspecified address (0:0:0:0:0:0:0:0) as Source Address and include
an APID Option. The CurDefAR Address field and the APID field of the
Option are filled in with the global scope address of the CurDefAR
and the new APID respectively. Note that the DAD can be aborted once
the host receives the indication from its CurDefAR (see Section 6.3).
In the above all cases, sending an RS SHOULD still be delayed by a
random time as specified in [NDv6]. To cover the possibility of a
report being lost or damaged, the host MAY repeat sending the RS once
or twice after a certain delay.
6.2 Receiving Unicast Router Advertisements
While waiting for a reachability test result, a host performs the
operation below if a unicast RA with S and R bits set is received.
o If the address in the Prefix Information Option of the RA is
identical to the global scope address of the host's CurDefAR
previously retrieved from the APID Cache, the bi-directional
reachability between the host and the CurDefAR is confirmed. As a
result, the host continues to use its current address
configuration to obtain L3 connectivity.
o If the address in the Prefix Information Option of the RA is
identical to the global scope address of the host's PreDefAR
previously retrieved from the APID Cache, the bi-directional
reachability between the host and the PreDefAR is confirmed. As a
result, the host can reuse its previous address configuration to
obtain L3 connectivity as long as no duplication is detected.
After that, a Neighbor Advertisement with O bit set SHOULD be sent
to all nodes to update their Neighbor Caches with the address
binding. If duplication is detected, the host MUST resort to
manual configuration and perform router discovery again.
While expecting an APID List dissemination after unicast reporting an
APID, a host MUST update its APID Cache if a unicast RA with an APID
List Option is received. A new APID Cache entry is created for each
APID not present in the APID Cache. The associated default AR of the
new entries is set to the sender of the RA, and the DefARType flag is
set to CurDefAR. The global address, link layer address and prefix
elements of the associated AR in these entries are to be extracted
from the RA.
6.3 Receiving Multicast Router Advertisements
A received multicast RA with an APID List Option could be either
solicited by an APID report or advertised by the sender periodically.
Chen & Loh Expires - August 2004 [Page 12]
Internet-Draft APID-based DNAv6 February 2004
In the former case, the receiver may or may not be the one performing
the report.
o If a host is expecting an APID List after multicast reporting an
APID, i.e. in M1, it updates its APID Cache according to the
received APID List.
The host should extract the sender's global scope address from the
Prefix Information Option when R bit is set in the RA. If the
address is identical to that its CurDefAR's address, it suggests
the host remains on the same link. It SHOULD abort DAD, if still
in progress, and continue to use its current address.
o If a host is expecting an APID List after unicast reporting an
APID, it MUST update its APID Cache. A new APID Cache entry is
created for each APID not present in the APID Cache. The
associated default AR of the new entries is set to the sender of
the RA, and the DefARType flag is set to CurDefAR. The global
address, link layer address and prefix elements of the associated
AR in these entries are to be extracted from the RA.
o If a host is not expecting an APID List, i.e. just passively
receiving a dissemination either solicited by others or
periodically advertised, it does not need to update its APID Cache
unless the sender of the RA is its CurDefAR.
7. Additional Operation for Access Routers
This section describes the operation required for ARs to support the
APID-based DNAv6 mechanism in addition to that specified in [NDv6].
7.1 Receiving Unicast Router Solicitations
o The receipt of a unicast RS without an APID Option suggests the
sender is testing the reachability of the AR. In response, the AR
MUST set S and R bits and include a Prefix Information Option in
the outgoing solicited RA to convey the global scope address of
its receiving interface. Note that no random delay is required
before sending the RA [1] because it is in response to a unicast
RS, which does not cause the collision of simultaneous RAs.
o The receipt of a unicast RS with an APID Option suggests the
sender is reporting an APID after acquiring a new address
configuration. If the reported APID is present in the APID List
of the AR, i.e. already disseminated before, the AR sends the
solicited RA with its APID List to the sender only. Otherwise,
the AR updates its APID List and sends the solicited RA with the
List to all-nodes multicast address. Thus, other hosts can update
their APID Caches at the same time. In both cases, the AR SHOULD
Chen & Loh Expires - August 2004 [Page 13]
Internet-Draft APID-based DNAv6 February 2004
set S and R bits and include a Prefix Information Option in the
RA so that the receiver(s) can record the AR's global address.
[1]: RFC 2461 states that RAs sent in response to an RS MUST be
delayed by a random time. This is because it assumes an RS is
typically multicast to all-routers only (see Section 4.1 of RFC
2461). The use of unicast RS in this DNAv6 mechanism need not
be restricted by the requirement. Actually with FastRA adopted
the requirement is expected to be relaxed in the later version
of RFC 2461 even for multicast RS.
7.2 Receiving Multicast Router Solicitations
The receipt of a multicast RS with an APID Option suggests the sender
is suspecting it remains on current link. It is performing router
discovery and APID reporting to expect a reply from its CurDefAR.
The receiver has to send the solicited RA in multicast because the
Source Address of the RS is the unspecified address. A Prefix
Information Option SHOULD be included in the RA with S and R bits set
to convey the global scope address of the receiving interface.
o If the reported APID is not present in the AR's APID List, the
APID is added to the List. An APID List Option MUST be included
in the RA. Multicasting the RA allows other hosts not knowing the
ARID to update their APID Caches as well.
o If the reported APID is already present, the solicited RA does not
include an APID List Option (unless the receiver is the CurDefAR)
in order to suppress redundant APID List dissemination.
o When the address assigned to the receiving interface matches the
CurDefAR Address in the APID Option of the RS, the AR realizes
it is the CurDefAR of the sender. It MUST include its APID List
in the RA regardless whether the APID is new. This is to allow
the host reporting the APID to quickly update its APID Cache.
8. Protocol Constants
AP_ENTRY_EXPIRY_TIME TBD. The value might depend on how often
an AP is disabled due to failure, system
management or other reasons.
9. IANA Considerations
Allocation by the IANA of two Neighbor Discovery option types for the
APID Option and the APID List Option is requested.
10. Security Considerations
Chen & Loh Expires - August 2004 [Page 14]
Internet-Draft APID-based DNAv6 February 2004
Since the DNAv6 mechanism is built on Neighbor Discovery, RS and RA
in particular, its trust models and threats are similar to those
presented in [SENDPS-04]. Specific attacks are identified bellow.
1. An attacker "kills" a default AR by launching a classic DoS
attack or by sending a spoofed RA with a zero Router Lifetime.
Deceived into believing that the default AR is unreachable, the
hosts are unable to reuse the available address configuration
resulting in a DoS attack. It becomes a redirect attack, if a
malicious AR masquerades the default AR or is chosen as a default
AR after the failure of reachability test.
2. An attacker reports a falsified APID, which is then disseminated
by an AR to other hosts on the link. An AP configured with the
APID and an AR disguised as the AR are set up on a separate
link. When the hosts roam to the coverage of the AP and attach
to the AP, they will perform reachability test with the default
AR. Similar to 1, the hosts are exposed to a DoS/redirect
attack.
3. An attacker reports the APID of an AP belonging to another link.
The APID is then disseminated by an AR to other hosts on the
link. When those hosts roam to the coverage of the AP and attach
to the AP, the reachability test will never be successful as the
AR is not on the link, resulting in a DoS attack. This becomes a
redirect attack if a malicious AR masquerading their default ARs
is present on the link.
4. An attacker spoofs hosts with a bogus APID List. Similar to 2
and 3, the hosts are exposed to DoS/redirect attack.
The problem for these attacks is essentially whether reported APIDs
and disseminated APID Lists are trustworthy. Hence, ensuring the
integrity and authentication of RS and RA messages and certifying the
authority of ARs are the key. Possible approach to the problem is to
apply the relevant mechanism in [SEND-00], particularly certificate
chains and Signature Option. On the other hand, validating the
integrity and authenticity of L2 Link-up hints is necessary to
mitigate the attacks.
11. Acknowledgements
The authors would like to thank Makis Kasapidis and Sathya Narayanan
for their comments that helped writing this document.
References
[NDv6] Narten, T., E. Nordmark, and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
Chen & Loh Expires - August 2004 [Page 15]
Internet-Draft APID-based DNAv6 February 2004
1998.
[ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address
Autoconfiguration", RFC 2462, December 1998.
[KEYWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[DNAPS-00] Choi, J. and G. Daley, "Detecting Network Attachment in
IPv6 Problem Statement", Internet Draft (work in
progress), October 2003.
[RA-00] Choi, J. and G. Daley, "Router Advertisement Issues for
Movement Detection/ Detection of Network Attachment",
Internet Draft (work in progress), October 2003.
[ODAD-03] Moore, N., "Optimistic Duplicate Address Detection",
Internet Draft (work in progress), September 2003.
[L2HINT-00] Yegin, A., et al., "Link-layer Hints for Detecting
Network Attachments", Internet Draft (work in progress),
October 2003.
[SENDPS-04] Nikander, P., et al., "IPv6 Neighbor Discovery Trust
Models and Threats", Internet Draft (work in progress),
October 2003.
[SEND-00] Arkko, J., et al., "Secure Neighbor Discovery", Internet
Draft (work in progress), October 2003.
[MIP6-24] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support
in IPv6", Internet Draft (work in progress), June 2003.
[MD-01] Daley, G. and J. Choi, "Movement Detection Optimization
in Mobile IPv6", Internet Draft (expired), May 2003.
Appendix A: Applicability to Movement Detection
This mechanism can also be used as an alternative movement detection
method for Mobile IPv6 [MIP6-24] except that DAD is not needed.
In short, a mobile host parallelly performs reachability test and
prefix validation using a unicast RS/RA exchange, after an APID from
a Link-up hint is found associated with its CurDefAR in APID Cache.
Obviously, the APID-based method allows the mobile host to detect no
movement (i.e. L3 handover) faster, compared to the generic method in
MIPv6 where reachability test (using NS/NA probing) and prefix
validation (using RS/RA) are done separately and sequentially. Upon
being indicated an unrecognized APID, a mobile host realizes a
Chen & Loh Expires - August 2004 [Page 16]
Internet-Draft APID-based DNAv6 February 2004
movement right away. The efficient detection is thanks to the
information stored in APID Cache.
Compared with the movement detection optimization using multicast RS
probing [MD-01], the use of unicast RS in the APID-based mechanism
dispenses with the random delay before sending an RA and does not
lead to excessive multicast traffic. The association between APID
and default AR information in APID Cache complements the information
from L2 hints and thus diminishes movement ambiguity to a great
extent.
Authors' Address
Zhigao Chen
Email: zgchen@psl.com.sg
Phone: +65-6550-5319
Juh Khang Loh
Email: jkloh@psl.com.sg
Phone: +65-6550-5313
Address:
Panasonic Singapore Laboratories
Blk 1022 Tai Seng Avenue #06-3530
Singapore 534415
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Chen & Loh Expires - August 2004 [Page 17]
Internet-Draft APID-based DNAv6 February 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Chen & Loh Expires - August 2004 [Page 18]
