idnits 2.17.1 draft-sarikaya-mext-homelink-prefix-delegation-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Prefixes can be released in two ways, prefix aging or DHCP release procedure. In the former way, a prefix SHOULD not be used by an MN when the prefix ages, and the DHCP Server can delegate it to another MN. A prefix lifetime is delivered from the DHCPv6 server to the requesting router (HA) through DHCP IA_PD Prefix option [RFC3633] and RA Prefix Information option [RFC4861]. -- 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 (February 17, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-devarapalli-mext-mipv6-home-link-00 ** Downref: Normative reference to an Informational draft: draft-devarapalli-mext-mipv6-home-link (ref. 'I-D.devarapalli-mext-mipv6-home-link') ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3576 (Obsoleted by RFC 5176) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Expires: August 20, 2008 Huawei USA 5 February 17, 2008 7 Prefix Management for MIPv6 Home Link Operation over P2P Links 8 draft-sarikaya-mext-homelink-prefix-delegation-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 In Mobile IPv6 home link operation on point-to-point links requires 42 that one prefix can only be assigned to one mobile node by the home 43 agent (HA) and different mobile nodes can not share this home network 44 prefix. Managing Per-MN home network prefixes is likely to increase 45 the processing load at the HA. Based on the idea that DHCPv6 servers 46 can manage prefixes, we propose a new technique in which HA offloads 47 delegation and release tasks of the prefixes to the DHCPv6 server. 48 HA requests a prefix for an incoming mobile station to the DHCPv6 49 server. Based on this prefix, the mobile node can create a home 50 address. When the mobile node leaves the network, the prefix is 51 returned to the DHCPv6 server. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Mobile IPv6 Home Network Prefix Delegation . . . . . . . . . . 4 58 4. Prefix Release Procedure . . . . . . . . . . . . . . . . . . . 5 59 5. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction 71 Mobile IPv6 (MIPv6) provides client-based mobility solution to the 72 mobile nodes (MN). In point-to-point links, home link operation 73 should make sure to assign a unique prefix to MN. MN's home address 74 should be configured from the home network prefix (HNP). However, in 75 per-MN prefix model, prefix management is an issue. 77 When an MN enters the network, its HA requests one or more prefixes 78 for the MN for MIPv6. The prefixes should be released when the MN 79 leaves the network. When an operator wants to renumber its network, 80 the prefixes with different lifetime are advertised to the MN. 82 DHCPv6 is a preferable way to manage the prefixes. AAA protocols, 83 RADIUS or Diameter, can be involved in prefix allocation as defined 84 in [RFC4818]. However, an AAA-based prefix delegation application is 85 yet to be defined. 87 In this document we propose DHCPv6 based home network prefix 88 allocation to MIPv6 MNs. Section 3 describes Mobile IPv6 home link 89 prefix allocation, Section 4 describes how prefixes are released and 90 Section 5 presents miscellaneous considerations that apply. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in BCP 14 [RFC2119]. 98 This document uses the terminology defined in [RFC3315], [RFC3633]. 99 All MIPv6 related terms are defined in [RFC3775]. 101 3. Mobile IPv6 Home Network Prefix Delegation 103 Home agents (HA) MUST use per-MN home network prefixes in order to 104 avoid multi-link subnet issues. Prefix management becomes an issue 105 for HAs. DHCPv6 based prefix delegation can be used for this purpose 106 as part of home link operation 107 [I-D.devarapalli-mext-mipv6-home-link]. 109 Mobile IPv6 per-MN prefix delegation procedure is shown in Figure 1 110 using DHCPv6. 112 MN AR HA DHCPS AAA 113 |-------|--------|--------|--------| 1. IKEv2 SA Establishment 114 | |------->| | | 2. CFG_REQUEST 115 | | |------->| | 3. DHCP Solicit 116 | | |<-------| | 4. DHCP Advertise 117 | | |------->| | 5. DHCP Request (HNP) 118 | | |<-------| | 6. DHCP Reply (HNP) 119 | |<-------| | | 7. CFG_REPLY (HoA) with 120 |-------|--------|--------|--------| IKEv2 SA Establishment 121 |<------| | | | 8. RA for CoA 122 |------>| | | | 9. DAD NS for CoA 124 Figure 1: Prefix request procedure 126 1. MN solicits security association establishment using IKEv2. 127 2. HA gets configuration request message [RFC4877]. 128 3. DHCP Client at the HA initiates DHCP Solicit procedure to request 129 prefixes for the MN. HA creates and transmits a Solicit message 130 as described in sections 17.1.1, "Creation of Solicit Messages" 131 and 17.1.2, "Transmission of Solicit Messages" of RFC 3315. HA 132 creates an IA_PD and assigns it an IAID. HA MUST include the 133 IA_PD option in the Solicit message. 134 4. The DHCP server sends an Advertise message to HA in the same way 135 as described in section 17.2.2, "Creation and transmission of 136 Advertise messages" of RFC 3315. 138 5. HA uses the same message exchanges as described in section 18, 139 "DHCP Client-Initiated Configuration Exchange" of RFC 3315 to 140 obtain or update prefixes from a DHCP server. HA and the DHCP 141 server use the IA_PD Prefix option to exchange information about 142 prefixes in much the same way as IA Address options are used for 143 assigned addresses. 144 6. HA stores the prefix information it received in the Reply 145 message. 146 7. HA sends back the reply to configuration request with HoA. MN 147 uses HoA in sending BU message to register its care of address. 148 8. The care of address configuration. 149 9. The care of address configuration. 151 Note that home address can be assigned during the bootstrapping 152 process and downloaded into the AR as part of the policy store. In 153 this case, HA will be triggered by HAAA-HA protocol and HA MUST get a 154 per-MN prefix from DHCP server using steps 3-6 in Figure 1 and MUST 155 assign HoA from this prefix. 157 MN can receive the bootstrapping parameters by sending DHCP Info- 158 Request message and receiving DHCP Info-Reply message. 160 4. Prefix Release Procedure 162 Prefixes can be released in two ways, prefix aging or DHCP release 163 procedure. In the former way, a prefix SHOULD not be used by an MN 164 when the prefix ages, and the DHCP Server can delegate it to another 165 MN. A prefix lifetime is delivered from the DHCPv6 server to the 166 requesting router (HA) through DHCP IA_PD Prefix option [RFC3633] and 167 RA Prefix Information option [RFC4861]. 169 In case of Mobile IPv6, Figure 2 can be used to release prefixes. 171 MN HA DHCPS 172 |------->| | 1. MN's link down 173 | |------->| 2. DHCP Release (HNP) 174 | |<-------| 3. DHCP Reply 175 | | | 177 Figure 2: MIPv6 Prefix release 179 HA MUST release MN's home link prefix when MN returns home and goes 180 off. The prefix release signaling is as shown in Figure 2. 182 Site renumbering is an open issue for RADIUS/ Diameter protocols to 183 manage prefixes. [RFC3576] MAY be used for renumbering. 185 5. Miscellaneous Considerations 187 The considerations on how to generate IAIDs and to delegate prefixes 188 described in [I-D.sarikaya-16ng-prefix-delegation] on the access 189 routers (AR) apply here on the the home agents (HA). 191 6. Security Considerations 193 This draft introduces no additional messages. Comparing to 194 [RFC3633], there is no additional threats to be introduced. DHCPv6 195 security procedures apply. 197 7. IANA considerations 199 None. 201 8. Acknowledgements 203 9. References 205 9.1. Normative References 207 [I-D.devarapalli-mext-mipv6-home-link] 208 Devarapalli, V., Kant, N., and H. Lim, "Mobile IPv6 Home 209 Link Operation over SDO point-to-point links", 210 draft-devarapalli-mext-mipv6-home-link-00 (work in 211 progress), February 2008. 213 [I-D.sarikaya-16ng-prefix-delegation] 214 Xia, F. and B. Sarikaya, "Using DHCPv6 for Prefix 215 Delegation in IEEE 802.16 Networks", 216 draft-sarikaya-16ng-prefix-delegation-02 (work in 217 progress), November 2007. 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 223 and M. Carney, "Dynamic Host Configuration Protocol for 224 IPv6 (DHCPv6)", RFC 3315, July 2003. 226 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 227 Aboba, "Dynamic Authorization Extensions to Remote 228 Authentication Dial In User Service (RADIUS)", RFC 3576, 229 July 2003. 231 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 232 Host Configuration Protocol (DHCP) version 6", RFC 3633, 233 December 2003. 235 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 236 in IPv6", RFC 3775, June 2004. 238 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 239 Attribute", RFC 4818, April 2007. 241 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 242 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 243 September 2007. 245 9.2. Informative References 247 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 248 IKEv2 and the Revised IPsec Architecture", RFC 4877, 249 April 2007. 251 Authors' Addresses 253 Behcet Sarikaya 254 Huawei USA 255 1700 Alma Dr. Suite 100 256 Plano, TX 75075 258 Email: sarikaya@ieee.org 260 Frank Xia 261 Huawei USA 262 1700 Alma Dr. Suite 100 263 Plano, TX 75075 265 Phone: +1 972-509-5599 266 Email: xiayangsong@huawei.com 268 Full Copyright Statement 270 Copyright (C) The IETF Trust (2008). 272 This document is subject to the rights, licenses and restrictions 273 contained in BCP 78, and except as set forth therein, the authors 274 retain all their rights. 276 This document and the information contained herein are provided on an 277 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 278 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 279 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 280 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 281 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 282 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 284 Intellectual Property 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be 293 found in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this 299 specification can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Acknowledgment 310 Funding for the RFC Editor function is provided by the IETF 311 Administrative Support Activity (IASA).