IPv6 Working Group JinHyeock Choi Internet Draft Samsung AIT Expires: March 2004 Greg Daley Monash University CTIE October 2003 Router Advertisement Issues for Movement Detection/ Detection of Network Attachment draft-jinchoi-ipv6-cra-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC 2026]. 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. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - [RFC 2119] Abstract This draft presents the Router Advertisement issues for Movement Detection/ Detection of Network Attachment. Based on [RFC-2461], the information contained in RA is inadequate for efficient Movement Detection due to inconsistency and incompleteness. This draft describes the problems concerning Movement Detection and investigates the possible solutions. Table of Contents 1. Introduction...................................................2 2. The RA Information Issues......................................2 2.1 Link local scope of Router Address.........................2 Choi, Daley Expires - March 2004 [Page 1] Internet-Draft RA issues for MD/ DNA October 2003 2.2 Omission of Prefix Information.............................3 2.3 Lack of Solicitation Acknowledgement.......................4 2.4 Ambiguity of On-link information (L-bit)...................4 3. RA Optimized for Movement Detection............................5 3.1 Complete RA................................................5 3.2 RA with Link Identifier Option.............................6 Security Considerations...........................................6 References........................................................7 Acknowledgments...................................................8 Author's Addresses................................................8 1. Introduction Movement detection (MD) is one of a series of stages in accomplishing MIPv6 handover. As defined in the MIPv6 specification [MIPv6], detection of movement is accomplished through reception of Router Advertisements (RAs) and Neighbor Advertisements (NAs), and comparison of these messages with previously received router information. In brief, the Movement Detection process is as follows: 1) There is some hint that Mobile node (MN) may have moved to another subnet. This hint itself doesn't confirm movement. 2) Then the MN probes the current Access Router (AR) to check its (partial) reachability. 3) It also checks the validity of the current CoA. 4) If it turns out that the MN has actually moved, it searches for a new AR with Router Discovery. After an RA from a new AR arrives with necessary information, the MN performs further operations, forming a CoA and sending Binding Updates. To detect its movement, an MN should check the (partial) reachability of the current AR and the validity of the current IP address. For these, the information in Router Advertisement is essential. But, based on current definitions [RFC 2461], the information contained in an RA is inadequate for efficient MD due to inconsistency and incompleteness. 2. The RA Information Issues In this chapter, we describe the problems we encountered while working on Movement Detection and investigate the possible solutions. 2.1 Link local scope of Router Address Choi, Daley Expires - March 2004 [Page 2] Internet-Draft RA issues for MD/ DNA October 2003 The router address contained in an RA message is link-local scope. Neighbor Discovery [RFC 2461] only advertises a router's link-local address, by requiring this address to be used as the IP Source Address of each Router Advertisement. Hence its uniqueness can't be guaranteed outside of a link-instance. So if it happens that two different router interfaces have the same link-local address, a host can't detect that it has moved from one interface to another by checking the router address in RA messages. On the other hand, a host can't be sure that its current default router is reachable, even when it can communicate with the router, which has the same address as its current router address. That router may be a different one, which, though highly unlikely, happens to have the same link-local address as its current default router. Heuristically, a host can use link-layer addresses in Neighbor cache. After link change, if the router address and link-layer address in Neighbor Cache has not changed, i.e. a host can still communicate with those addresses, it's reasonable for the host to assume that current default router is still reachable. Reception of a Router Advertisement with the same on-link global prefix (L=1) from the same router's link-local, may be considered an authoritative indication that the router is still reachable. Or a router can advertise its global address, by using Router Address (R) bit in the Prefix Information option. When set, R bit indicates that the Prefix field contains a complete IP address assigned to the sending router. With the RA with R bit set, a node can check whether it can still hear from its current default router. 2.2 Omission of Prefix Information To check the validity of its IP address, a host should see whether the prefix of its IP address is advertised on the link to which it is currently attached. For this, a host checks whether the prefix of its IP address is in the Prefix Information Option of Router Advertisement messages. But an unsolicited Router Advertisement message can omit some prefixes for convenience, for example to save the bandwidth. So, checking the prefixes in an RA, an MN may make false assumption that the prefix of its current IP address is not supported in a new link, while that prefix is just omitted in that particular RA. Choi, Daley Expires - March 2004 [Page 3] Internet-Draft RA issues for MD/ DNA October 2003 Moreover, even though a RA message contains all the Prefix Information Options, a host has no way to know it. There is no indication. Hence, a host can't be sure that the prefix of its current IP address is not supported on the current link, even though the prefix is not contained in an RA message. The problem is 1) an RA may omit some Prefix Information Options and 2) even it has all the Prefix Information Options, there is no indication that it does. The possible solution for the above is the RA with 1) All the Prefix Information Options and 2) The indication that it contains all the Prefix Information Options. For 2), we may define a new bit in an RA message. We will give more detail in 3.1. 2.3 Lack of Solicitation Acknowledgement In Router Advertisement messages, there is no solicitation bit, as in Neighbor Advertisement. So when a node receives a RA, it can's be sure it's the reply to its Router Solicitation. To confirm bi- directional reachability, an additional NS/ NA exchange is mandatory. It may useful to assign S bit, in the case where we want nodes to be able to determine that they have received a solicited router advertisement. With S bit, a node can confirm reachability with only RS/ RA exchange. 2.4 Ambiguity of On-link information (L-bit) Currently confusion is caused by the attempt to overload on-link prefixes to mean some form of "link identifier". According to RFC 2461, on-link prefix means that this prefix can be used for on-link determination. A node can send packets directly to an address that falls in the on-link prefix without going through default routers. Any two nodes with the addresses having the same on- link prefix can communicate each other at the link layer. Also RFC 2461 allows the links without on-link prefixes, where all packets would be sent to a default router. Thus as RFC 2461 is designed, it is problematic for the on-link prefixes to be a link identifier. Choi, Daley Expires - March 2004 [Page 4] Internet-Draft RA issues for MD/ DNA October 2003 Reception of an RA with the L bit set to zero does not make any claims about the reachability of hosts on the current link. One of the implications of the unset L bit is that the subnet may be available through multiple interfaces on the same router, or through multiple routers on different links. One problem with RA message reception where the currently configured prefix is L=0, is that it is impossible to distinguish between RAs received from routers on different links, and L=0 Prefix advertisements received from a different routers on the same link link-local address on the same subnet, until bidirectional reachability checks have been performed with the current router. According to [RFC 2461], a router may advertise prefixes with L=0 and A=1. This implies that stateless address autoconfiguration is allowed for these prefixes [RFC 2462]. It is possible to show that in the absence of Address State on routers or ND proxying, duplicate addresses may be configured for a global address, when an address owner exists on another link of the same subnet. Even if address state (using DHC or otherwise) is maintained on a router, no current specification requires that hosts re-DAD global addresses while they remain within the subnet, even if routers change. This means that if a mobile host moves to another link within an IP subnet (with L=0), the router may be unaware that the host has moved, and have inaccurate information about which link the hosts are on. 3. RA Optimized for Movement Detection Our goal is to design an RA in such a way that an MN can detect its movement efficiently, quickly and precisely with as little signaling as possible. As described above, the information contained in a current RA message is inconsistent and incomplete for movement detection. The following proposals seek to facilitate efficient movement detection by including all the necessary information in an RA message. 3.1 Complete RA Since routers may neglect to send all prefixes in every advertisement, it is difficult for an MN to determine whether it is attached to a different subnet, when an RA received without its currently configured prefix. Even though an RA contains all the Prefixes, an MN has no way to know it. There is no indication. So still ambiguity remains. Choi, Daley Expires - March 2004 [Page 5] Internet-Draft RA issues for MD/ DNA October 2003 If a router is able to send an indication that the RA it sends contains all of the valid prefixes for a link-instance, then reception of an RA which contains a different set of prefixes indicates the presence of a different subnet. Moreover if an RA contains all the other options, for example link- layer address option, it will speed up movement detection. We propose to assign a new bit (Complete bit) in RA message to indicate its completeness. When Complete bit is set, it means the RA contains all the options (including all the Prefix Information Options). For efficient Movement Detection, we propose a RA with 1) AR's global IP address using R bit 2) All the options (including all the Prefix Information Options) 3) The indication that it has all the options (Complete bit) 4) S bit (Solicitation bit) to confirm reachability without NS/ NA exchange It may take too much bandwidth to advertise the above RAs constantly. To save bandwidth, a router may make a policy of sending a complete RA only when it receives a Router Solicitation. If necessary, we can combine S bit and Complete bit into one. 3.2 RA with Link Identifier Option Link Identifier Options aim to provide a consistent view of what constitutes a link for the purposes of movement detection. [HINDSIGHT] indicates that when an RA is received with a link identifier which is different to that currently received, that may be used as an indication that the current router is no longer present. [LinkID] attempts to create an automated mechanism such that all routers on the same link instance may arrive at a common identifier, even if they advertise a different set of prefixes, or fail to advertise all prefixes in every RA. Security Considerations Hosts which use single Router Advertisement messages to change routing configuration are always subject to possible attack, since reception of Router Advertisements from a bogus router can cause additional computation, configuration or signaling. Systems which accept such advertisements without checking their authority are Choi, Daley Expires - March 2004 [Page 6] Internet-Draft RA issues for MD/ DNA October 2003 particularly vulnerable, and are able to be fooled into denial of service or man-in the middle attacks by setting the bogus router as their default gateway. These attacks may be mitigated if hosts always check the validity of a router before changing their configuration by using secure router discovery. As defined in [SEND-01], Router Discovery is protected by delegation of routing authority from a trusted root. Hosts may check a new router by sending Delegation Chain Solicitation messages, and checking the trust chain received in a response Delegation Chain Advertisement (DCA). Existing specifications mean that the response DCA messages are sent after a delay of 0-500 ms (similar to the delay specified in RFC- 2461 for RA responses). While this may limit the rate at which movement is detected, it is important that hosts do not irrevocably change their routing before such authorizations are received. Particularly, it is important to give precendence to reachability confirmation from the configured (trusted) routerover computation and signalling requirements used to check authorization of a new router. References [RFC 2026] S. Bradner, "The Internet Standards Process ?Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2461] T. Narten, E.Nordmark, W. Simpson, "Neighbour Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", Internet Draft (work in progress), June 2003. [MDO] G. Daley, J. Choi, "Movement Detection Optimization in Mobile IPv6", Internet Draft (work in progress), May 2003. [DNA PS] J. Choi, G. Daley, "Detecting Network Attachment in IPv6 Problem Statement", Internet Draft (work in progress), October 2003. Choi, Daley Expires - March 2004 [Page 7] Internet-Draft RA issues for MD/ DNA October 2003 [LinkID] B. Pentland, G. Daley, J. Choi, "Router Advertisement Link Identification for Mobile IPv6 Movement Detection", Internet Draft (work in progress), May 2003. [SEND-01] J. Arkko et al.," SEcure Neighbor Discovery (SEND)", Internet Draft (work in progress), June 2003. [Hindsight] E. Nordmark, "MIPv6: from hindsight to foresight?", Internet Draft, November 2001. Acknowledgments Erik Nordmark has contributed significantly to work predating this draft on the ambiguity in On-link prefix. Also Ed Remmell's comments on the inconsistency of RA information were most illuminating. Thanks for Brett Pentland, Nick Moore and Youn-Hee Han for their contribution for this draft. Author's Addresses JinHyeock Choi i-Networking Lab Samsung AIT P.O. Box 111 Suwon 440-600 Korea Email: athene@sait.samsung.co.kr Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia Email: greg.daley@eng.monash.edu.au Choi, Daley Expires - March 2004 [Page 8]