idnits 2.17.1 draft-krishnan-mext-hld-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 176. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 200. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 2008) is 5869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational G. Tsirtsis 5 Expires: October 2, 2008 Qualcomm 6 March 31, 2008 8 MIPv6 Home Link Detection 9 draft-krishnan-mext-hld-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The MIPv6 bootstrapping procedure allows the mobile node to 43 dynamically discover its home prefix using an IKEv2 exchange. Since 44 the home prefix is not statically configured on the mobile node, 45 there is a need to specify a mechanism for the mobile node to detect 46 if it is on its home link. This document specifies one such 47 mechanism. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Proposed method . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 3 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 8. Normative References . . . . . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 60 Intellectual Property and Copyright Statements . . . . . . . . . . 6 62 1. Requirements notation 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Introduction 70 A Mobile IPv6 node requires a Home Agent address, a home address, and 71 IPsec security associations with its Home Agent before it can start 72 utilizing Mobile IPv6 service. The base MIPv6 RFC [RFC3775] requires 73 that some or all of these are statically configured. The MIPv6 74 bootstrapping work specified in [RFC5026] describes how the MN can 75 acquire such information dynamically. 77 3. Proposed method 79 This document proposes using the information available from Router 80 Advertisements on the local link and the configuration information 81 acquired using the IKEv2 exchange as specified in [RFC5026] to 82 determine whether or not it has attached to its home link. It uses 83 the Prefix Information Option(s) received in the Router 84 Advertisements and the MIP6_HOME_PREFIX configuration payload 85 received from the HA. The MN performs this home link detection 86 procedure by following the steps described in Section 4. 88 4. Mobile Node Operation 90 When an MN arrives on a new link it performs the following steps to 91 determine if it is on the home link. 92 o The MN sends out a Router Solicitation 93 o The MN receives a Router Advertisement in response with one or 94 more Prefix Information Options as specified in [RFC4861]. 95 o The MN autoconfigures an address from one of the received prefixes 96 that have the autonomous address configuration flag set. This 97 address is referred to as the Current MN Address (CMA) 98 o The MN stores all the prefix(es) received along with their prefix 99 lengths in the RA in a conceptual list called the Current Link 100 Prefix List (CLPL) 101 o The MN uses the CMA to initiate the bootstrapping procedure 102 described in [RFC5026]. The MN MUST include the MIP6_HOME_PREFIX 103 attribute in the CFG_REQUEST message. 104 o The MN receives the home prefix and the corresponding prefix 105 length from the HA contained in the MIP6_HOME_PREFIX attribute in 106 the CFG_REPLY message. The MN stores it in a conceptual variable 107 called the HomePrefix. 108 o The MN iterates through the CLPL and compares HomePrefix to each 109 of the entries there in turn. 110 o If one (or more) of the entries in the CLPL matches the 111 HomePrefix, the MN can determine that it has attached to its home 112 link 113 o If none of the entries in the CLPL matches the HomePrefix, the MN 114 can determine that it has not attached to its home link 116 5. Acknowledgements 118 The authors would like to thank Gerardo Giaretta, Hesham Soliman, 119 Julien Laganier and Vijay Devarapalli for their contributions to this 120 document. 122 6. IANA Considerations 124 This document does not require any action from the IANA. 126 7. Security Considerations 128 This document does not create any new security issues other than 129 those specified in [RFC3775] and [RFC5026] 131 8. Normative References 133 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 134 Requirement Levels", BCP 14, RFC 2119, March 1997. 136 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 137 in IPv6", RFC 3775, June 2004. 139 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 140 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 141 September 2007. 143 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 144 Bootstrapping in Split Scenario", RFC 5026, October 2007. 146 Authors' Addresses 148 Suresh Krishnan 149 Ericsson 150 8400 Decarie Blvd. 151 Town of Mount Royal, QC 152 Canada 154 Phone: +1 514 345 7900 x42871 155 Email: suresh.krishnan@ericsson.com 157 George Tsirtsis 158 Qualcomm 160 Email: tsirtsis@googlemail.com 162 Full Copyright Statement 164 Copyright (C) The IETF Trust (2008). 166 This document is subject to the rights, licenses and restrictions 167 contained in BCP 78, and except as set forth therein, the authors 168 retain all their rights. 170 This document and the information contained herein are provided on an 171 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 172 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 173 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 174 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 175 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 176 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 178 Intellectual Property 180 The IETF takes no position regarding the validity or scope of any 181 Intellectual Property Rights or other rights that might be claimed to 182 pertain to the implementation or use of the technology described in 183 this document or the extent to which any license under such rights 184 might or might not be available; nor does it represent that it has 185 made any independent effort to identify any such rights. Information 186 on the procedures with respect to rights in RFC documents can be 187 found in BCP 78 and BCP 79. 189 Copies of IPR disclosures made to the IETF Secretariat and any 190 assurances of licenses to be made available, or the result of an 191 attempt made to obtain a general license or permission for the use of 192 such proprietary rights by implementers or users of this 193 specification can be obtained from the IETF on-line IPR repository at 194 http://www.ietf.org/ipr. 196 The IETF invites any interested party to bring to its attention any 197 copyrights, patents or patent applications, or other proprietary 198 rights that may cover technology that may be required to implement 199 this standard. Please address the information to the IETF at 200 ietf-ipr@ietf.org. 202 Acknowledgment 204 Funding for the RFC Editor function is provided by the IETF 205 Administrative Support Activity (IASA).