One document matched: draft-arkko-mip6-3775bis-ndmobext-00.txt
Network Working Group J. Arkko
Internet-Draft Ericsson
Updates: 3775,2461 (if approved) C. Perkins
Expires: August 31, 2006 Nokia Research Center
D. Johnson
Rice University
February 27, 2006
IPv6 Neighbor Discovery Extensions for Mobility
draft-arkko-mip6-3775bis-ndmobext-00
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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This specification extends IPv6 Neighbor Discovery with features that
are useful for mobile nodes. These features provide information for
the purposes of detecting the loss of Router Advertisements,
determining the global address of the router, or for discovering
which routers are also Mobile IPv6 home agents. These extensions are
Arkko, et al. Expires August 31, 2006 [Page 1]
Internet-Draft ND Mobility Extensions February 2006
required for Mobile IPv6 operation, but they are also useful for any
type of nomadic or mobile nodes. This document revises a part of RFC
3775 which originally defined these extensions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. General Extensions . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Router Address Extension for Prefix Information Option . . 3
3.2. Advertisement Interval Option . . . . . . . . . . . . . . 5
3.3. Changes to Sending Router Advertisements . . . . . . . . . 6
4. Extensions for Mobile IPv6 Support . . . . . . . . . . . . . . 8
4.1. Modified Router Advertisement Message . . . . . . . . . . 8
4.2. Home Agent Information Option . . . . . . . . . . . . . . 9
4.3. Home Agents List . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC 3775 . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Arkko, et al. Expires August 31, 2006 [Page 2]
Internet-Draft ND Mobility Extensions February 2006
1. Introduction
This specification extends IPv6 Neighbor Discovery with features that
are useful for mobile nodes. These features provide information for
the purposes of detecting the loss of Router Advertisements,
determining the global address of the router, or for discovering
Mobile IPv6 home agents (see RFC 3775 [RFC3775]). This specification
also relaxes the timing constraints related to the sending of the
Router Advertisements.
These extensions are complementary to other protocol enhancements,
including those defined in [I-D.pentland-dna-protocol3] for fast
detection of network attachments.
The extensions in this specification are required for Mobile IPv6
operation, but they are also useful for any type of nomadic or mobile
nodes. The generally useful extensions are introduced in Section 3
and the Mobile IPv6 specific extensions in Section 4.
2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119].
3. General Extensions
3.1. Router Address Extension for Prefix Information Option
Knowledge of a router's global address can be useful in many cases,
including the building of a list of home agents in Mobile IPv6
[RFC3775].
However, Neighbor Discovery [I-D.ietf-ipv6-2461bis] only advertises a
router's link- local address, by requiring this address to be used as
the IP Source Address of each Router Advertisement.
This specification extends Neighbor Discovery to allow a router to
advertise its global address, by the addition of a single flag bit in
the format of a Prefix Information option for use in Router
Advertisement messages. The format of the Prefix Information option
is as follows:
Arkko, et al. Expires August 31, 2006 [Page 3]
Internet-Draft ND Mobility Extensions February 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally
specified for Neighbor Discovery [I-D.ietf-ipv6-2461bis]:
Router Address (R)
1-bit router address flag. When set, indicates that the Prefix
field contains a complete IP address assigned to the sending
router. The indicated prefix is the first Prefix Length bits of
the Prefix field. The router IP address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.
Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
In a Router Advertisement, a Mobile IPv6 home agent MUST, and all
other routers MAY, include at least one Prefix Information option
with the Router Address (R) bit set. Neighbor Discovery specifies
that, if including all options in a Router Advertisement causes the
size of the Advertisement to exceed the link MTU, multiple
Advertisements can be sent, each containing a subset of the options
[I-D.ietf-ipv6-2461bis]. Also, when sending unsolicited multicast
Arkko, et al. Expires August 31, 2006 [Page 4]
Internet-Draft ND Mobility Extensions February 2006
Router Advertisements more frequently than the limit specified in
Neighbor Discovery [I-D.ietf-ipv6-2461bis], the sending router need
not include all options in each of these Advertisements. However, in
both of these cases the router SHOULD include at least one Prefix
Information option with the Router Address (R) bit set in each such
advertisement, if this bit is set in some advertisement sent by the
router.
In addition, the following requirement can assist mobile nodes in
movement detection. Barring changes in the prefixes for the link,
routers that send multiple Router Advertisements with the Router
Address (R) bit set in some of the included Prefix Information
options SHOULD provide at least one option and router address which
stays the same in all of the Advertisements.
3.2. Advertisement Interval Option
The Advertisement Interval option is used in Router Advertisement
messages to advertise the interval at which the sending router sends
unsolicited multicast Router Advertisements. The format of the
Advertisement Interval option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are defined as follows:
Type
7
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) is in units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Arkko, et al. Expires August 31, 2006 [Page 5]
Internet-Draft ND Mobility Extensions February 2006
Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent
by this router on this network interface. Using the conceptual
router configuration variables defined by Neighbor Discovery
[I-D.ietf-ipv6-2461bis], this field MUST be equal to the value
MaxRtrAdvInterval, expressed in milliseconds.
Routers MAY include this option in their Router Advertisements. All
IPv6 routers SHOULD be able to send it, to aid movement detection by
mobile nodes. The use of this option SHOULD be configurable.
If Router Advertisements that a mobile node receives include an
Advertisement Interval option, the mobile node may use its
Advertisement Interval field as an indication of the frequency with
which it should expect to continue to receive future Advertisements
from that router. This field specifies the minimum rate (the maximum
amount of time between successive Advertisements) that the mobile
node should expect. If this amount of time elapses without the
mobile node receiving any Advertisement from this router, the mobile
node can be sure that at least one Advertisement sent by the router
has been lost. The mobile node can then implement its own policy to
determine how many lost Advertisements from its current default
router constitute an L3 handover indication.
This option MUST be silently ignored for other Neighbor Discovery
messages.
3.3. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [I-D.ietf-ipv6-2461bis]
limits routers to a minimum interval of 3 seconds between sending
unsolicited multicast Router Advertisement messages from any given
network interface (limited by MinRtrAdvInterval and
MaxRtrAdvInterval), stating that:
"Routers generate Router Advertisements frequently enough that
hosts will learn of their presence within a few minutes, but not
frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability
Detection algorithm provides failure detection."
This limitation, however, is not suitable to providing timely
movement detection for mobile nodes. Mobile nodes detect their own
movement by learning the presence of new routers as the mobile node
moves into wireless transmission range of them (or physically
connects to a new wired network), and by learning that previous
Arkko, et al. Expires August 31, 2006 [Page 6]
Internet-Draft ND Mobility Extensions February 2006
routers are no longer reachable. Mobile nodes need to quickly detect
when they move to a link served by a new router, so that they can
acquire a new care-of address, register this address in a Mobile IPv6
homea agent (for instance), and notify correspondent nodes as needed.
One method which can provide for faster movement detection, is to
increase the rate at which unsolicited Router Advertisements are
sent. This specification relaxes this limit such that routers MAY
send unsolicited multicast Router Advertisements more frequently.
This method can be applied where the router is expecting to provide
service to mobile nodes.
All IPv6 routers SHOULD be able to support a faster rate. The
minimum allowed values are:
o MinRtrAdvInterval 0.03 seconds
o MaxRtrAdvInterval 0.07 seconds
In the case where the minimum intervals and delays are used, the mean
time between unsolicited multicast router advertisements is 50 ms.
Use of these modified limits MUST be configurable. Systems where
these values are available MUST NOT default to them, and SHOULD
default to values specified in Neighbor Discovery [I-D.ietf-ipv6-
2461bis]. Knowledge of the type of network interface and operating
environment SHOULD be taken into account in configuring these limits
for each network interface. This is important with some wireless
links, where increasing the frequency of multicast beacons can cause
considerable overhead. Routers SHOULD adhere to the intervals
specified in Neighbor Discovery [I-D.ietf-ipv6-2461bis], if this
overhead is likely to cause service degradation.
Additionally, the possible low values of MaxRtrAdvInterval may cause
some problems with movement detection in some mobile nodes. To
ensure that this is not a problem, Routers SHOULD add 20 ms to any
Advertisement Intervals sent in RAs, which are below 200 ms, in order
to account for scheduling granularities on both the MN and the
Router.
Note that multicast Router Advertisements are not always required in
wireless networks that have limited bandwidth, as mobility detection
or link changes in such networks may also be done at lower layers.
Router advertisements in such networks SHOULD be sent only when
solicited. In such networks it SHOULD be possible to disable
unsolicited multicast Router Advertisements on specific interfaces.
The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set
to some high values.
Arkko, et al. Expires August 31, 2006 [Page 7]
Internet-Draft ND Mobility Extensions February 2006
Similarly, routers that support a faster rate MUST allow this
variable to be configured by system management:
MinDelayBetweenRAs Default: 3 seconds,
Min: 0.03 seconds
The value MinDelayBetweenRAs overrides the value of the protocol
constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
[I-D.ietf-ipv6-2461bis]. This variable SHOULD be set to
MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds.
Mobile IPv6 Home agents MUST include the Source Link-Layer Address
option in all Router Advertisements they send. This simplifies the
process of returning home, as discussed in [RFC3775].
Note that according to Neighbor Discovery [I-D.ietf-ipv6-2461bis],
AdvDefaultLifetime is by default based on the value of
MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime
field of Router Advertisements. Given that this field is expressed
in seconds, a small MaxRtrAdvInterval value can result in a zero
value for this field. To prevent this, routers SHOULD keep
AdvDefaultLifetime in at least one second, even if the use of
MaxRtrAdvInterval would result in a smaller value.
4. Extensions for Mobile IPv6 Support
4.1. Modified Router Advertisement Message
A single flag bit to indicates that the router sending the Router
Advertisement message [I-D.ietf-ipv6-2461bis] is serving as a Mobile
IPv6 home agent on this link. The format of the Router Advertisement
message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Arkko, et al. Expires August 31, 2006 [Page 8]
Internet-Draft ND Mobility Extensions February 2006
This format represents the following changes over that originally
specified for Neighbor Discovery [I-D.ietf-ipv6-2461bis]:
Home Agent (H)
The Home Agent (H) bit is set in a Router Advertisement to
indicate that the router sending this Router Advertisement is also
functioning as a Mobile IPv6 home agent on this link.
Reserved
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
Mobile IPv6 home agents MUST support this format and related
processing rules in Section 4.3.
4.2. Home Agent Information Option
The Home Agent Information option is used in Router Advertisements
sent by a Mobile IPv6 home agent to advertise information specific to
this router's functionality as a home agent. The format of the Home
Agent Information option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are defined as follows:
Type
8
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The value of this
field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Arkko, et al. Expires August 31, 2006 [Page 9]
Internet-Draft ND Mobility Extensions February 2006
Home Agent Preference
16-bit unsigned integer. The preference for the home agent
sending this Router Advertisement, for use in ordering the
addresses returned to a mobile node in the Home Agent Addresses
field of a Home Agent Address Discovery Reply message. Higher
values mean more preferable. If this option is not included in a
Router Advertisement in which the Home Agent (H) bit is set, the
preference value for this home agent MUST be considered to be 0.
Greater values indicate a more preferable home agent than lower
values.
Mobile IPv6 home agents SHOULD support a configuration mechanism
to allow a system administrator to manually set the value to be
sent in this field. In addition, the sending home agent MAY
dynamically set the Home Agent Preference value, for example
basing it on the number of mobile nodes it is currently serving or
on its remaining resources for serving additional mobile nodes;
such dynamic settings are beyond the scope of this document. Any
such dynamic setting of the Home Agent Preference, however, MUST
set the preference appropriately, relative to the default Home
Agent Preference value of 0 that may be in use by some home agents
on this link (i.e., a home agent not including a Home Agent
Information option in its Router Advertisements will be considered
to have a Home Agent Preference value of 0).
Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the home
agent in units of seconds. The default value is the same as the
Router Lifetime, as specified in the main body of the Router
Advertisement. The maximum value corresponds to 18.2 hours. A
value of 0 MUST NOT be used. The Home Agent Lifetime applies only
to this router's usefulness as a home agent; it does not apply to
information contained in other message fields or options.
Mobile IPv6 home agents MUST support this option and related process
rules in Section 4.3.
Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which
the Home Agent (H) bit (see Section 4.1) is not set. If this option
is not included in a Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to be
the same as the Router Lifetime in the Router Advertisement. If
multiple Advertisements are being sent instead of a single larger
unsolicited multicast Advertisement, all of the multiple
Advertisements with the Router Address (R) bit set MUST include this
Arkko, et al. Expires August 31, 2006 [Page 10]
Internet-Draft ND Mobility Extensions February 2006
option with the same contents, otherwise this option MUST be omitted
from all Advertisements.
This option MUST be silently ignored for other Neighbor Discovery
messages.
If both the Home Agent Preference and Home Agent Lifetime are set to
their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home
agent.
4.3. Home Agents List
Each Mobile IPv6 home agent MUST maintain a conceptual data structure
called the Home Agents List.
The Home Agents List is maintained by each home agent, recording
information about each router on the same link that is acting as a
home agent. This list is used by the dynamic home agent address
discovery mechanism from [RFC3775]. A router is known to be acting
as a home agent, if it sends a Router Advertisement in which the Home
Agent (H) bit is set. When the lifetime for a list entry (defined
below) expires, that entry is removed from the Home Agents List. The
Home Agents List is similar to the Default Router List conceptual
data structure maintained by each host for Neighbor Discovery
[I-D.ietf-ipv6-2461bis]. The Home Agents List MAY be implemented in
any manner consistent with the external behavior described in this
document.
Each home agent maintains a separate Home Agents List for each link
on which it is serving as a home agent. A new entry is created or an
existing entry is updated in response to receipt of a valid Router
Advertisement in which the Home Agent (H) bit is set. Each Home
Agents List entry conceptually contains the following fields:
o The link-local IP address of a home agent on the link. This
address is learned through the Source Address of the Router
Advertisements received from the router.
o One or more global IP addresses for this home agent. Global
addresses are learned through Prefix Information options with the
Router Address (R) bit set and received in Router Advertisements
from this link-local address. Global addresses for the router in
a Home Agents List entry MUST be deleted once the prefix
associated with that address is no longer valid.
o The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement
Arkko, et al. Expires August 31, 2006 [Page 11]
Internet-Draft ND Mobility Extensions February 2006
received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home
Agent Lifetime field in the option (if present); otherwise, the
lifetime is initialized from the Router Lifetime field in the
received Router Advertisement. If Home Agents List entry lifetime
reaches zero, the entry MUST be deleted from the Home Agents List.
o The preference for this home agent; higher values indicate a more
preferable home agent. The preference value is taken from the
Home Agent Preference field in the received Router Advertisement,
if the Router Advertisement contains a Home Agent Information
Option and is otherwise set to the default value of 0. A home
agent uses this preference in ordering the Home Agents List when
it sends an ICMP Home Agent Address Discovery message.
On receipt of a valid Router Advertisement, as defined in the
processing algorithm specified for Neighbor Discovery, the home agent
performs the following steps in addition to any steps already
required of it by Neighbor Discovery:
o If the Home Agent (H) bit in the Router Advertisement is not set,
delete the sending node's entry in the current Home Agents List
(if one exists). Skip all the following steps.
o Otherwise, extract the Source Address from the IP header of the
Router Advertisement. This is the link-local IP address on this
link of the home agent sending this Advertisement.
o Determine the preference for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the
preference is taken from the Home Agent Preference field in the
option; otherwise, the default preference of 0 MUST be used.
o Determine the lifetime for this home agent. If the Router
Advertisement contains a Home Agent Information Option, then the
lifetime is taken from the Home Agent Lifetime field in the
option; otherwise, the lifetime specified by the Router Lifetime
field in the Router Advertisement SHOULD be used.
o If the link-local address of the home agent sending this
Advertisement is already present in this home agent's Home Agents
List and the received home agent lifetime value is zero,
immediately delete this entry in the Home Agents List.
o Otherwise, if the link-local address of the home agent sending
this Advertisement is already present in the receiving home
agent's Home Agents List, reset its lifetime and preference to the
values determined above.
Arkko, et al. Expires August 31, 2006 [Page 12]
Internet-Draft ND Mobility Extensions February 2006
o If the link-local address of the home agent sending this
Advertisement is not already present in the Home Agents List
maintained by the receiving home agent, and the lifetime for the
sending home agent is non-zero, create a new entry in the list,
and initialize its lifetime and preference to the values
determined above.
o If the Home Agents List entry for the link-local address of the
home agent sending this Advertisement was not deleted as described
above, determine any global address(es) of the home agent based on
each Prefix Information option received in this Advertisement in
which the Router Address (R) bit is set (Section 3.1). Add all
such global addresses to the list of global addresses in this Home
Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for
each valid home agent address until that entry's lifetime expires,
after which time the entry MUST be deleted.
5. Security Considerations
This specification allows additional information to be provided about
routers on this link. Disclosure of this information is usually not
a problem, and where it is, controlling access to the link helps
avoid this problem along with many others.
Spoofing this information can, however, be problematic in certain
cases. For instance, sending a spoofed Router Advertisement with a
smaller Advertisement Interval than what is really in use may
convince other nodes on the link to believe that they have moved.
This vulnerability can be addressed in the same way as other Router
Discovery information can be protected, for instance, by employing
SEND [RFC3971]. Similarly, attackers may spoof information related
to Mobile IPv6 home agents available on this link. However, the
discovery of home agents as such does not lead nodes into believing
that these are indeed legitimate home agents, even if this
information was secured at the Router Discovery level. An actual use
of the home agent requires mutual authentication between the mobile
node and the home agents.
6. IANA Considerations
This document defines two Neighbor Discovery options (Section 3.2 and
Section 4.2), which have already been assigned Option Type values 7
and 8 within the option numbering space for Neighbor Discovery
messages per RFC 3775. No new IANA action is required.
Arkko, et al. Expires August 31, 2006 [Page 13]
Internet-Draft ND Mobility Extensions February 2006
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-05 (work in progress),
October 2005.
7.2. Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.pentland-dna-protocol3]
Pentland, B., "Detecting Network Attachment in IPv6
Networks (DNAv6)", draft-pentland-dna-protocol3-00 (work
in progress), October 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Appendix A. Changes from RFC 3775
This document provides no protocol changes or extensions over what
was defined in RFC 3775 [RFC3775]. Security considerations for these
extensions have, however, been provided.
Appendix B. Acknowledgements
The authors wish to thank everyone involved in the creation of RFC
3775, and Thomas Narten for suggesting specific parts of document the
document that could be in different specifications.
Charlie Perkins and Dave Johnson are listed as authors of this draft
due them being authors of RFC 3775.
Arkko, et al. Expires August 31, 2006 [Page 14]
Internet-Draft ND Mobility Extensions February 2006
Authors' Addresses
Jari Arkko
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@ericsson.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
USA
Email: charliep@iprg.nokia.com
David B. Johnson
Rice University
Dept. of Computer Science, MS 132
6100 Main Street
Houston TX 77005-1892
USA
Email: dbj@cs.rice.edu
Arkko, et al. Expires August 31, 2006 [Page 15]
Internet-Draft ND Mobility Extensions February 2006
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 (2006). 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.
Arkko, et al. Expires August 31, 2006 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:17:19 |