One document matched: draft-daley-ipv6-preempt-nd-00.txt
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 <link-type>' 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]
| PAFTECH AB 2003-2026 | 2026-04-24 03:08:20 |