IPv6 Working Group G. Daley Internet-Draft Monash University CTIE Expires: December 16, 2004 June 17, 2004 Preempting IPv6 Neighbour Discovery draft-daley-ipv6-preempt-nd-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract In certain circumstances, a host knows that it will be receiving data at an IP address for which its neighbours have no neighbour cache entry. Where the expected packets are required to be received promptly, or there is significant chance of packet loss in a neighbour discovery exchange from the peer to the host, it may be advantageous to install a neighbour cache entry on the peer before it is required. This document proposes a mechanism whereby hosts can choose to preemptively populate their peer's neighbour cache to forestall later Daley Expires December 16, 2004 [Page 1] Internet-Draft Preemptive ND June 2004 neighbour discovery exchanges. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Preempting Neighbour Discovery with NS . . . . . . . . . . 3 2.2 Preempting Neighbour Discovery with RS . . . . . . . . . . 4 3. Applicability to Particular Media . . . . . . . . . . . . . . 5 3.1 Properties of 802.11 Wireless LAN . . . . . . . . . . . . 5 3.2 Preempting Neighbour Discovery on 802.11 . . . . . . . . . 5 4. Relationship to Other Protocols . . . . . . . . . . . . . . . 6 4.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Fast Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 7 4.3 Duplicate Address Detection . . . . . . . . . . . . . . . 7 4.4 Address Resolution Protocol . . . . . . . . . . . . . . . 8 5. Configuration Parameters . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Daley Expires December 16, 2004 [Page 2] Internet-Draft Preemptive ND June 2004 1. Introduction For hosts which have tight delay bounds on packet reception and response, loss of neighbour solicitation or advertisement messages can significantly hamper the operation of upper-layer protocols and applications. For such hosts, it may be possible that have recently started using an address and have not sent any Neighbour Advertisements for it. If the host then knows that a packet is expected at that address, it knows that Neighbour Discovery exchange is imminent. In this case, it may be possible for a host to attempt to create neighbour cache state on its peer or peers in order to facilitate the delivery of packets, and remove Neighbour Discovery from the critical path. Additionally, where a host knows that a link contains lossy media where loss of messages (or particular types of messages) are common, it can use its existing knowledge of peers and topology to send messages which will create on neighbour cache state on peers without the peer subsequently sending solicitations. Even in the case a host's solicitation is itself lost, the peer will not yet have lost a solicitation, and will not be hampered by the delay of RetransTimer milliseconds (typically 1,000) between sending of one solicitation and the next[1]. 2. Protocol Operation Neighbour Discovery is a basic service for IPv6 hosts today and has a wide deployed base [1][9]. Therefore optimizations to neighbour discovery performance need to be able to interoperate with optimizations to neighbour discovery procedures 2.1 Preempting Neighbour Discovery with NS Multicast Neighbour Solicitations are sent to peer devices containing Source Link-Layer Address Options (SLLAOs), which update their peer's neighbour caches, adding a STALE entry for the soliciting address. This stale entry can be used by the peer immediately without invoking neighbour discovery procedures. The peer will then send a Neighbour Advertisement to the original host. Reception of this advertisement is not critical to the procedures in this document, but indicates that the neighbour cache entry was created. Daley Expires December 16, 2004 [Page 3] Internet-Draft Preemptive ND June 2004 In this case, the amount of signalling is approximately the same as the neighbour discovery exchange which would have been required without the preemptive solicitation. Where a peer has already been discovered (for example through Router Advertisement), it is also possible to send unicast solicitations containing SLLAO from the host to guarantee a unique response, or to improve robustness on a particular medium. This is useful where the transmission of unicast from the host has better propagation properties than multicast. 2.2 Preempting Neighbour Discovery with RS In one of the most common cases, the peer is one of the routers on a link. An on-link prefix having been been learnt using router discovery. The host is likely then to have the routers' link-layer addresses (from a received Source Link-Layer Address Option), to use in packet transmission, but the host's global address will not be in the router's neighbour cache. While a host is transmitting, and knows that packets are likely to start arriving from off link, it may not necessarily know which router will forward responding packets to the host. Since it does not know which of the routers to create neighbour cache state, a host MAY send a router solicitation containing a SLLAO to the all-routers group. In this case all routers who receive the solicitation will create a neighbour cache entry and are likely to respond, although their responses will be randomly delayed so that they do not transmit simultaneously. Even though a particular router may not have responded, the neighbour cache entry exists from the time when the solicitation was received, and therefore will allow packet delivery. Using this version of the protocol, an additional burden is placed on the wireless link, as router advertisements are often significantly larger than neighbour discovery messages. Additionally, when the router solicitation goes to all-routers, all routers will respond. If unicast advertisements are sent, the effect of this is limited to a single wireless cell. Otherwise multicast advertisements will propagate to all cells, consuming bandwidth equally. Therefore, hosts SHOULD only use this version if they are unsure which router packets will be returning through. Daley Expires December 16, 2004 [Page 4] Internet-Draft Preemptive ND June 2004 3. Applicability to Particular Media Not all media will benefit from the reliability aspects of these procedures, although most will be able to move the ND exchange from the critical path for packet delivery. Below, a case study of the applicability of these procedures to 802.11 Wireless LAN is made. 3.1 Properties of 802.11 Wireless LAN In 802.11, transmissions may collide with peers, or momentary interference may prevent a wireless device from receiving a packet. Since it may not always be possible to determine that a collision has occurred (transmitters may not be able to listen when transmitting), explicit acknowledgments are used to ensure that packets have been received. If no acknowledgment is received within a timeout, the packet is rescheduled and retransmitted by the MAC, until it is acknowledged, or abandoned. For 802.11 devices which are communicating amongst themselves, or when an Access Point bridges a packet from the wired to the wireless LAN, packets are addressed and transmitted directly to their destination Station (STA). If the packet is unicast, it is acknowledged by the destination. If the packet has a multicast destination it may be receivable by more than one station on the LAN. No device acknowledges the multicast transmission, in order to avoid ACK implosion. Therefore multicast packets in this case may not be transmitted unless the transmitter receives explicit indication of a collision. When performing bridging from Wireless LAN to LAN, 802.11 functions as a strictly point-to-point oriented protocol. Stations select a particular access point to send frames through, and 802.11 frames are addressed via them. Upon reception, such frames are acknowledged and then bridged. At this time, the eventual destination of the frame is checked, which may me multicast or unicast. Of the four transfer modes, considered, only the multicast channel from an AP to a wireless LAN is unacknowledged. It may therefore be significantly less reliable to send multicast messages toward a wireless LAN than Multicast going toward the wired network, or any unicast message. 3.2 Preempting Neighbour Discovery on 802.11 Neighbour Discovery exchanges when transmitting data from a peer on a wired LAN to a a host on a Wireless LAN can be made more robust Daley Expires December 16, 2004 [Page 5] Internet-Draft Preemptive ND June 2004 simply by reversing the directions of the messages. This is because the multicast solicitation to the peer is sent reliably (being bridged through a particular AP), and any responses are sent to the wireless host's unicast address. Even if a responding advertisement is multicast (in the case a Router Solicitation was sent) and lost, the neighbour cache state was created on each of the routers on the wired link. 4. Relationship to Other Protocols A number of protocols either interact with the procedure provided in this document, or have attempted to achieve similar aims. Interactions with other protocols are described. Differences with and advantages over existing protocols are elaborated. 4.1 Mobile IPv6 Upon a Mobile IPv6 mobile node's arrival on a link, it exchanges link-scoped signalling until it is able to configure an address. The mobile node then sends mobility messages to begin aiming correspondent nodes' tunnel end points to the visited address [6]. The mobility messages which are sent all require acknowledgments to be received, or will be followed by data flows directly from the correspondent nodes. The Mobile Node will know of the requirements of existing upper-layer protocol sessions, and of the requirement to receive data subsequent to mobility signalling . Therefore reception of these messages may be expected, and neighbour cache entries preemptively installed according to the procedures outlined above. An additional benefit which accrues to Mobile IPv6 hosts which preemptively install neighbour cache entries in a peer is that a double timeout may be avoided in the case of packet loss. The Mobile IPv6 retransmission timer for mobility signalling starts at 1 second, and the default retransmission timer for Neighbour Solicitations (RetransTimer is 1000ms). Since a peer router will always receive the responding mobility message from off link after the initial transmission of the mobility message, loss of a Neighbour Solicitation from a peer router (or its NA response) will cause RetransTimer to expire just after the mobile node's retransmission of the mobility message. Daley Expires December 16, 2004 [Page 6] Internet-Draft Preemptive ND June 2004 In the case that a preemptive neighbour solicitation does not receive a neighbour advertisement, a similar double-timeout may occur. In order to minimize this possibility, a host may temporarily lower RetransTimer by a configurable value RetransTimerDelta, which reduces the expiry time of the first retransmission of the Neighbour Solicitation. This reduction should allow the retransmitted solicitation to create neighbour cache state on the router, in time to deliver any queued mobility signalling. 4.2 Fast Mobile IPv6 The experimental Fast MobileIPv6 (FMIPv6) protocol makes use of a Fast Neighbour Advertisement message to install Neighbour Cache state on a router immediately upon attaching to a network [10]. This mechanism requires explicit support from the router to interpret this message and install the IP-layer to link-layer mapping into the neighbour cache. Conversely, the mechanism described in this document is a stand-alone mechanism which requires neither support for mobility management on a host, nor support for new messages or options on a peer. It is able to install Neighbour Cache entries on any node which supports IPv6 Neighbour Discovery. This is a critical advantage when deploying enhanced hosts on otherwise unmodified networks. For the FMIPv6 case, there is no explicit acknowledgment of Fast Neighbour Advertisement, and no retransmission mechanisms are defined. Similarly, in this document, retransmission is not explicitly required, although hosts are aware of the success of their transmission, upon reception of a corresponding advertisement. It is quite possible that the lack of a second link seizure in the FMIPv6 case has advantages on low bandwidth and constrained links. This is a trade-off which is unavoidable when sending solicitations, as they are almost certainly going to be responded to if received. FMIPv6 Fast Neighbour Advertisement also provides a neighbour cache entry in the REACHABLE, rather than the STALE state. Entries being in the STALE state is not a major issue if the host is itself transmitting packets in response to received data, as upper layer confirmation procedures may remove the need for subsequent NS/NA exchange in any case [1]. 4.3 Duplicate Address Detection According to Stateless Address Autoconfiguration [5], when a host is still performing Duplicate Address Detection (DAD), its address is tentative and not able to be used for packet reception., Additionally, it is unable to create neighbour cache entries on Daley Expires December 16, 2004 [Page 7] Internet-Draft Preemptive ND June 2004 peers. Optimistic Duplicate Address Detection is used on autoconfigured addresses where the chance of collision with another node configuring the same address is low. It allows reception of packets at tentative addresses, and creation of neighbour cache state on peers, with the requirement that existing valid state not be modified [11]. To this end, it prevents the use of Source Link-Layer Address Options in ND Solicitation messages, since they override existing entries. In order to allow for the installation of neighbour cache entries in a non-destructive way, Tentative Source Link-Layer Address Options (TSLLAOs) have been proposed [12]. These options are able to be sent by optimistic nodes in any solicitation message where Source Link-Layer Address Options (SLLAOs) are not mandated in [1]. Where a peer receives a solicitation containing TSLLAOs, and there is no conflicting neighbour cache entry, an entry is made in the same fashion as with solicitations containing Source Link-Layer Address Options. In this case the solicitation's behaviour is the same as a non-tentative solicitation, and has the same benefits for packet exchange. Using these options (instead of SLLAOs) significantly reduces advantage of attempting preemptive solicitations if the options aren't understood by peers. This is because the tentative options will themselves be ignored by the peer, and no link-layer address will be placed in its neighbour cache (although one will be created if it didn't exist). The responding advertisement message will be scheduled, and then the peer will send a Neighbour Solicitation to the host, in order to resolve its link-layer address. Since this neighbour discovery exchange is subject to the same transmission environment as the standard neighbour discovery, such Neighbour Solicitation packets may be lost. The only advantage in this case is that the peer is now more likely to have an existing neighbour cache entry (if it received the original NS with the TSLLAO). sending a Neighbour Advertisement with a solicited=1 flag at some short delay after non-reception of a responding NS or Advertisement will then update the peers Neighbour Cache entry to REACHABLE state. 4.4 Address Resolution Protocol The Address Resolution Protocol (ARP) was defined to allow nodes to exchange and store information about their peers IP-Layer to Daley Expires December 16, 2004 [Page 8] Internet-Draft Preemptive ND June 2004 link-layer address mappings, which could then be used to encapsulate packets when transmitting to them [8]. A core of the features in ARP have migrated to IPv6 Neighbour Discovery. Importantly for this document, the existing mechanisms from ARP which allow REQUEST (solicitation) messages to create cache entries in order for responses to allow REPLY (advertisement) messages to be sent to the host directly. In the ARP RFC, a suggestion is made that hosts update existing cache entries by sending gratuitous REQUEST messages. In the case mentioned though, only existing entries would have been updated, and no response would have been generated [8]. The same function is available today in IPv6 Neighbour Discover by sending a Neighbour Advertisement to all-nodes with the Override flag set. 5. Configuration Parameters The following configuration parameter MAY be set in order to speed up the first retransmission of Neighbour Solicitations. Such configuration MAY be made automatically dependent on the link type, as defined in an 'IPv6 over ' document. RetransTimerDelta: number of milliseconds earlier that the retransmission timer is called back for preemptive Neighbour Solicitations. Minimum: 0 Default: 0 Maximum: minimum(0.6 * RetransTimer,1000) 6. IANA Considerations No new options or messages are defined in this document. 7. Security Considerations The use of the Router Solicitation version of this protocol may be dangerous on some link-layers where bandwidth is particularly constrained. On such links, this mechanism SHOULD NOT be used, although it MAY be possible to use preemptive Neighbour Solicitation. This protocol uses the existing neighbour Discovery mechanisms and is therefore subject to the same threats as Neighbour Discovery [7]. Daley Expires December 16, 2004 [Page 9] Internet-Draft Preemptive ND June 2004 Therefore hosts SHOULD use SEND procedures to protect signalling, and ensure that inappropriate trust isn't extended to unauthorized devices [3]. 8. Acknowledgments The issue of packet loss on neighbour solicitation was discussed a long time ago within the CTIE team, particularly with Richard Nelson, Brett Pentland and Nick Moore. At the time the focus was on IP Mobility, where other configuration delays were making their impact felt more greatly (and thus got the attention). 9. References 9.1 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. 9.2 Informative References [4] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [8] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [9] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-09 (work in progress), May Daley Expires December 16, 2004 [Page 10] Internet-Draft Preemptive ND June 2004 2004. [10] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-01 (work in progress), February 2004. [11] Moore, N., "Optimistic Duplicate Address Detection", draft-ietf-ipv6-optimistic-dad-00 (work in progress), March 2004. [12] Daley, G., Nordmark, E. and N. Moore, "Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in progress), June 2004. Author's Address Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Daley Expires December 16, 2004 [Page 11] Internet-Draft Preemptive ND June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daley Expires December 16, 2004 [Page 12]