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]