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]