Network Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track G. Daley
Expires: April 17, 2008 NetStar Networks
October 15, 2007
Simple procedures for Detecting Network Attachment in IPv6
draft-krishnan-dna-simple-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Detecting Network Attachment allows hosts to assess if its existing
addressing or routing configuration is valid for a newly connected
network.
This document provides simple procedures for detecting network
attachment in IPv6 hosts, and procedures for routers to support such
services.
Krishnan & Daley Expires April 17, 2008 [Page 1]
Internet-Draft Simple procedures for DNAv6 October 2007
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNA Roles . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
3. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Link-Layer Indication . . . . . . . . . . . . . . . . . . 4
3.2. Optimistic DAD . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Router Solicitation . . . . . . . . . . . . . . . . . . . 5
3.4. Neighbour Solicitation . . . . . . . . . . . . . . . . . . 5
3.5. Response Gathering . . . . . . . . . . . . . . . . . . . . 6
3.6. Further Host Operations . . . . . . . . . . . . . . . . . 6
3.6.1. Actions upon return to a link . . . . . . . . . . . . 6
3.6.2. Actions upon arrival at a new link . . . . . . . . . . 6
4. Router Operations . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Tentative Option Processing . . . . . . . . . . . . . . . 7
4.2. Fast Unicast Response to Router Solicitation . . . . . . . 7
4.2.1. Fast Router Initialization . . . . . . . . . . . . . . 7
4.2.2. Fast Router Advertisement Transmission . . . . . . . . 8
4.3. Additional Router Procedures . . . . . . . . . . . . . . . 8
5. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Remaining Issues . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Krishnan & Daley Expires April 17, 2008 [Page 2]
Internet-Draft Simple procedures for DNAv6 October 2007
1. Requirements notation
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 [1].
2. Introduction
Hosts require procedures to simply and reliably identify if they have
moved to a different IP network to the one which they have been
recently connected. In order to detect change, router and neighbour
discovery messages are used to collect reachability and configuration
information. This information is used to detect whether the existing
router and address prefixes are likely to be present.
This document incorporates feedback from host and router operating
systems implementors, which seeks to make implementation and adoption
of IPv6 change detection procedures simple for general use.
2.1. DNA Roles
Detecting Network Attachment is performed by hosts by sending IPv6
neighbour discovery and router discovery messages to routers after
connecting to a network.
Routers adopt procedures which allow for fast unicast Router
Advertisement (RA) messages.
The host detects that the link-layer may have changed, and then
probes the network with Router Solicitations (RSs) and Neighbour
Solicitations (NSs). The host uses advertisements to determine if
the routers it currently has configured are still available.
2.2. Applicability
There are a series of assumptions about the network environment which
underpin these procedures.
o Routers do not send Router Advertisements from the same Link-Local
address on different interfaces (on different links).
o All the prefixes advertised on the link need to fit into a single
RA. This implies that the number of prefixes on the link needs to
be limited. e.g. 15 prefixes per link.
o All routers on the link advertise the same subnet prefixes.
Krishnan & Daley Expires April 17, 2008 [Page 3]
Internet-Draft Simple procedures for DNAv6 October 2007
o The number of advertising routers on the link needs to be limited.
e.g. 4. But in realistic deployment scenarios, this would already
be the case.
o Hosts receive indications when a link-layer comes up. Without
this, they would not know when to commence the DNA procedure.
If these assumptions do not hold, host change detection systems will
not function optimally. In that case, they may occasionally detect
change spuriously, or experience some delay in detecting network
attachment.
If systems do not meet these assumptions or if systems seek
deterministic change detection operations they are directed to follow
the complete dna procedure as defined in [6].
3. Host Operations
When a host has an existing configuration for IP address prefixes and
next hop routing, it may be disconnected from its link-layer, and
then subsequently reconnect the link-layer on the same interface.
When the link-layer becomes available again, it is important to
determine whether the existing addressing and routing configuration
are still valid.
In order to determine this, the host undertakes detecting network
attachment.
The steps involved in basic detection of network attachment are:
o Link-Layer Indication
o Optimistic DAD
o Router Solicitation
o Neighbour Solicitations to prior router(s)
o Response gathering and assessment
These steps are described below.
3.1. Link-Layer Indication
In order to start Detection of network attachment procedures, a host
typically requires a link-layer indication that the medium has become
Krishnan & Daley Expires April 17, 2008 [Page 4]
Internet-Draft Simple procedures for DNAv6 October 2007
available [7].
When the indication is received, the host marks all currently
configured (non-tentative) IP addresses to Optimistic state [5].
3.2. Optimistic DAD
All Router Solicitations and unicast Neighbour Solicitations sent for
DNA purposes while addresses are in optimistic state SHOULD include
the Tentative Option [4].
This allows for DAD-safe transmission of unicast response to
solicitation, even if the router has no existing Neighbour Cache
entry for the solicitor.
3.3. Router Solicitation
The primary mechanism for used to detect network attachment in IPv6
is router solicitation and advertisement. When a host receives a
link-layer indication, it SHOULD send a Router Solicitation to the
All-routers address containing one of the host's optimistic unicast
source address [2][5].
3.4. Neighbour Solicitation
The host will have configuration for addresses configured from
prefixes advertised on one or more routers.
In order to gain a quick confirmation that a host has returned to one
of the links associated with these existing prefixes, the host can
send Neighbour Solicitations.
The host may select one of its configured next hop routers from each
of zero, one or two previously connected links, and send a unicast
Neighbour Solicitation to each of these [2][5]. If the addresses
obtained from a previous router are no longer valid, the host SHOULD
NOT send a Neighbour Solicitation to that router.
Please note that the Neighbour Solicitations SHOULD be sent in
parallel with the Router Solicitations. Since sending NSs is just an
optimization, doing the NSs and RSs in parallel ensures that the
procedure does not run solower than it would if it only used an RS.
Be aware that each unicast solicitation which is not successful may
cause packet flooding in bridged networks, if the networks are not
properly configured. This is further described in Section 6. Where
flooding may cause performance issues within the LAN, host SHOULD
limit the number of unicast solicitations.
Krishnan & Daley Expires April 17, 2008 [Page 5]
Internet-Draft Simple procedures for DNAv6 October 2007
3.5. Response Gathering
The Simple IPv6 DNA assessment on the host relies upon tying
advertised prefixes to the advertising routers. Reception of an
advertisement from a router which is known to advertise a prefix can
be used to indicate that the address prefix is available for
configuration.
Where a responding Neighbour Advertisement is received from a
previously configured router, the host MUST verify if the hardware
address of the router matches the one that was previously known. If
it does, the host can decide that it hasn't changed networks, and MAY
continue to use the existing prefixes with high probability.
Reception of a Router Advertisement which contains prefixes which
intersect with those previously advertised by a known router
indicates that the host has returned to that link with high
likelihood.In this case the host can decide that it hasn't changed
networks, and MAY continue to use the existing prefixes with high
probability.
Additionally, where a host receives a solicited router advertisement
after sending an RS for the purpose of detecting network attachment,
and this prefix contains only prefixes which are disjoint from known
advertised prefixes, the host SHOULD conclude with high probability
that it has moved to a different link.
3.6. Further Host Operations
Operations subsequent to detecting network attachment depend upon
whether change was detected.
3.6.1. Actions upon return to a link
Upon arrival at a previously visited link, the host should assess
whether it can use the existing configured addresses using Optimistic
Duplicate Address Detection [5].
Also, the host SHOULD rejoin any solicited nodes' multicast groups
for addresses it continues to use, and select a default router [2].
3.6.2. Actions upon arrival at a new link
Upon arrival on a new link, the host should unconfigure its existing
addresses and routers, and begin address configuration techniques, as
indicated in the received Router Advertisement [2][8].
The host MAY keep information about prefixes advertised by routers
Krishnan & Daley Expires April 17, 2008 [Page 6]
Internet-Draft Simple procedures for DNAv6 October 2007
from the prior link, for the purposes of subsequent change detection
operations.
4. Router Operations
Routers wishing to support host change detection need to provide them
with quick responses to queries. Basic support for DNA for IPv6
requires two basic operations.
These procedures allow for a host to receive immediate response to a
router solicitation, and may simplify a host's internal change
detection operations.
The simple IPv6 DNA router components are:
1. Tentative Option processing
2. Fast Unicast Response to Solicitation with Token Buckets
These are described in the following sections.
4.1. Tentative Option Processing
Hosts checking their network attachment are unsure of their address
status, and may be using Tentative link-layer addressing information
in their router or neighbour solicitations.
A router which desires to support hosts' DNA operations MUST process
Tentative Options from unicast source addressed Router and Neighbour
Solicitations, as described in [4] .
4.2. Fast Unicast Response to Router Solicitation
In order to provide fast response to router solicitation the router
removes the random delay before sending a unicast response to a
Router Solicitation.
4.2.1. Fast Router Initialization
Where many routers routers are performing Fast RAs though, this may
induce large jitter times for traffic on the medium. The router has
a responsibility to determine if fast responses are applicable,
particularly if there are too many routers to provide fast response.
Within this specification, it is suggested that the router determine
if there are three or more routers other routers on the link. With
four routers, the mean delay before RA reception with RFC 2461 timers
Krishnan & Daley Expires April 17, 2008 [Page 7]
Internet-Draft Simple procedures for DNAv6 October 2007
is < 80 milliseconds.
Upon becoming a router for an interface or an interface becomes
available for transmission on a router, the router MUST send three
(3) Router Solicitations in order to check if there are any other
routers.
If there are responses from three or more routers, the router SHOULD
send unicast Router Advertisemens using delays as specified in
RFC2461 [2].
Additionally, it MUST send three (3) unsolicited Router
Advertisements separated by MIN_DELAY_BETWEEN_RAS.
A router MAY listen to other routers' advertisements and disable Fast
Router advertisements if the total number of routers on a link
exceeds three.
4.2.2. Fast Router Advertisement Transmission
To control the rate at which Router Advertisements are sent, the
router maintains a token bucket per-interface, whereby fast RAs are
only transmitted when a token is available [6].
The bucket receives a token every UNICAST_RA_INTERVAL, unless the
bucket already contains MAX_UNICAST_RA_BURST tokens.
When the router receives a Router Solicitation containing a unicast
source address it MAY send a unicast router advertisement to the
solicitor's address without delay if there are remaining tokens in
the bucket. Each such transmission consumes one token.
When there are no remaining tokens, the router SHOULD send a
solicited Router Advertisement, as described in RFC 2461 [2].
4.3. Additional Router Procedures
As described, the system used here may not be applicable to all
environments. Therefore the fast response advertisement mechanisms
for simple IPv6 DNA MUST be configurable. When disabled the host
would revert to existing IPv6 Neighbour discovery behaviour [2].
5. Constants
These constants are described as in [6].
Krishnan & Daley Expires April 17, 2008 [Page 8]
Internet-Draft Simple procedures for DNAv6 October 2007
UNICAST_RA_INTERVAL
Definition: The interval corresponding to the maximum average
rate of Router Solicitations that the router is prepared to
service with unicast responses. This is the interval at which
the token bucket controlling the unicast responses is
replenished.
Value: 50 milliseconds
MAX_UNICAST_RA_BURST
Definition: The maximum size burst of Router Solicitations that
the router is prepared to service with unicast responses. This
is the maximum number of tokens allowed in the token bucket
controlling the unicast responses.
Value: 20
SEND_NA_GRACE_TIME
Definition: An optional period to wait after Neighbour
Solicitation before adopting a non-SEND RA's link change
information.
Value: 40 milliseconds
6. Remaining Issues
These issues are still outstanding within the document, and the
simple DNA solution in general.
Identification of Fast advertising Simple DNA routers to other
routers.
Other protocols attempt to desynchronize Router Advertisements
while still allowing fast RA response [6].
In an environment where it is safe to use Simple DNA, it may
not be necessary to worry about sending RAs at the same time as
other routers.
In the case where this specification's Fast Advertisements
cause problems due to contention with more sophisticated RA
delivery schemes, it SHOULD be turned off as described in
Section 4.3.
Krishnan & Daley Expires April 17, 2008 [Page 9]
Internet-Draft Simple procedures for DNAv6 October 2007
Rate limitation for solicitations.
In some circumstances, the rate of transmissions for
solicitations may need to be restricted or limited. This
depends highly upon the movement pattern and quality of link-
layer indications. Hysteresis mechanisms which slow or prevent
solicitation operations may be necessary to prevent damage to
the local network environment.
Particularly, transmission of unicast solicitations may cause
packet flooding across a bridged network if received on a
network where the link-layer unicast destination is unknown.
This shouldn't cause wireless link utilization, where base
stations maintain state about attached subscribers.
Hosts MAY implement hysteresis mechanisms to pace solicitations
where necessary to prevent damage to a particular medium.
Implementors should be aware that when such hysteresis is
triggered, Detecting Network Attachment may be slowed, which
may affect application traffic.
7. IANA Considerations
There are no changes to IANA registries required in this document
8. Security Considerations
When providing fast responses to router solicitations, it is possible
to cause collisions with other signaling packets on contention based
media. This can cause repeated packet loss or delay when multiple
routers are present on the link.
As such the fast router advertisement system is NOT RECOMMENDED in
this form for media which are susceptible to collision loss. Such
environments may be better served using the procedures defined in
[6].
A host may receive Router Advertisements from non SEND devices, after
receiving a link-layer indications. While it is necessary to assess
quickly whether a host has moved to another network, it is important
that the host's current secured SEND [3] router information is not
replaced by an attacker which spoofs an RA and purports to change the
link.
As such, the host SHOULD send a Neighbour Solicitation to the
existing SEND router upon link-up indication as described above in
Krishnan & Daley Expires April 17, 2008 [Page 10]
Internet-Draft Simple procedures for DNAv6 October 2007
Section 3.1. The host SHOULD then ensure that unsecured router
information does not cause deletion of existing SEND state, within
MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to
respond.
The host MAY delay SEND_NA_GRACE_TIME after transmission before
adopting a new default router, if it is operating on a network where
there is significant threat of RA spoofing.
Even if SEND signatures on RAs are used, it may not be immediately
clear if the router is authorized to make such advertisements. As
such, a host SHOULD NOT treat such devices as secure until and unless
authorization delegation discovery is successful.
It is easy for hosts soliciting without SEND to deplete a SEND
router's fast advertisement token buckets, and consume additional
bandwidth. As such, a router MAY choose to preserve a portion of
their token bucket to serve solicitations with SEND signatures.
9. Acknowledgments
This document is the product of a discussion between the authors had
with Bernard Aboba, Thomas Narten, Erik Nordmark and Dave Thaler at
IETF 69. The authors would like to thank them for clearly detailing
the requirements of the solution and the goals it needed to meet and
for helping to explore the solution space. The authors would like to
thank the authors and editors of the complete DNA specification for
detailing the overall problem space and solutions. The authors would
like to thank Jari Arkko for driving the evolution of a simple and
probabilistic DNA solution. The authors would like to thank Bernard
Aboba, Thomas Narten and Sathya Narayan for performing reviews on the
document and providing valuable comments to drive the document
forward.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Krishnan & Daley Expires April 17, 2008 [Page 11]
Internet-Draft Simple procedures for DNAv6 October 2007
[4] Daley, G., Nordmark, E., and N. Moore, "Tentative Options for
IPv6 Neighbour Discovery", draft-ietf-dna-tentative-01 (work in
progress), July 2007.
[5] Moore, N., "Optimistic Duplicate Address Detection for IPv6",
RFC RFC4429, April 2006.
[6] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol (work in progress), June 2007.
10.2. Informative References
[7] Yegin, A., "Link-layer Event Notifications for Detecting Network
Attachments", draft-ietf-dna-link-information-03 (work in
progress), October 2005.
[8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Greg Daley
NetStar Networks
Level 9/636 St Kilda Rd
Melbourne, Victoria 3004
Australia
Phone: +61 405 494849
Email: gdaley@netstarnetworks.com
Krishnan & Daley Expires April 17, 2008 [Page 12]
Internet-Draft Simple procedures for DNAv6 October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Krishnan & Daley Expires April 17, 2008 [Page 13]