One document matched: draft-jinchoi-ipv6-cra-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:39:02 |