idnits 2.17.1 draft-sarikaya-dime-prefix-delegation-ps-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 398. 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 == Line 305 has weird spacing: '...d Fixed and M...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 22, 2008) is 5905 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) == Unused Reference: 'RFC2119' is defined on line 281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 Summary: 2 errors (**), 0 flaws (~~), 6 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 25, 2008 Huawei USA 5 J. Korhonen 6 TeliaSonera Corporation 7 February 22, 2008 9 Problem Statement and Requirements for Diameter Prefix Delegation 10 Application 11 draft-sarikaya-dime-prefix-delegation-ps-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 25, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document provides problem statement for Diameter prefix 45 delegation application. The document also identifies application 46 scenarios and requirements on Diameter prefix delegation application. 48 Table of Contents 50 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Prefix Management in Access Routers . . . . . . . . . . . 4 55 4.2. Prefix Management in Local Mobility Anchors . . . . . . . 5 56 4.3. Prefix Management for Mobile Routers . . . . . . . . . . . 5 57 5. Requirements on AAA-based Prefix Delegation Application . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 9.2. Informative references . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Introduction and Motivation 69 Prefix assignment for an IPv6 node (host or router) is essential to 70 IPv6 address formulation. Even though IPv6 address space is large 71 enough, it still makes sense for operators to manage addresses in a 72 central way, e.g. using central DHCPv6 servers or AAA servers. 73 Delegating prefix from a central server to a prefix user (e.g. a 74 router) needs communication between different network entities. 76 Prefix delegation is widely discussed in IETF 16NG, NEMO, and NETLMM 77 Working Groups. Corresponding solutions are also introduced. But 78 these solutions only solve a part of the problem. In 16NG, an Access 79 Router allocates a mobile node's prefix using Router Advertisement 80 message defined in [RFC4861]. There is no discussion about how the 81 Access Router acquires prefixes from external entity. NEMO deals 82 with synchronization of Mobile Network prefixes between a Mobile 83 Router and a Home Agent, while the method is agnostic to the way that 84 a Home Agent gets prefixes from back end servers. In Proxy Mobile 85 IPv6 [I-D.ietf-netlmm-proxymip6], Proxy Binding Update and Proxy 86 Binding Acknowledgement messages are used to allocate prefixes from a 87 Local Mobile Anchor to a mobile node, but how the Local Mobile Anchor 88 gets prefixes from external server is out of the scope. 90 [RFC3633] defines Prefix Delegation options and procedures to provide 91 a mechanism for automated delegation of IPv6 prefixes using the 92 Dynamic Host Configuration Protocol (DHCP). But there is no existing 93 mechanism to manage prefixes dynamically by an AAA server. 95 Making use of AAA infrastructure for prefix management can solve the 96 aforementioned problems in a uniform way. 98 2. Terminology 99 Prefix Delegation (PD): The process by which a router obtains a 100 prefix dynamically. 102 3. Problem Statement 104 AAA servers managing IP address is a convention. [RFC2865] defines 105 attribute Framed-IP-Address for allocating IPv4 address for a host. 107 AAA servers statically configuring IPv6 prefixes is also a 108 convention. [RFC3162] introduces Framed-IPv6-Prefix attribute for 109 configuring IPv6 prefixes for a host. This configuration is static 110 because Framed-IPv6-Prefix carries a number of prefixes only. 111 Lifetime values for each prefix can not be carried. 113 Existing AAA (RADIUS and Diameter) mechanisms can't accomodate prefix 114 delegation. [RFC4818] designs Delegated-IPv6-Prefix attribute which 115 is used for delegating prefixes. However in [RFC4818], the 116 recommended usage scenario is AAA server configures the delegating 117 server with some prefixes and then DHCP Prefix Delegation [RFC3633] 118 can be used to delegate these prefixes to the requesting router. 119 Also Delegated-IPv6-Prefix carries a number of prefixes only. 120 Lifetime values for each prefix can not be carried. 122 In a prefix delegation application, the requesting router requests 123 prefixes from the delegating server. The delegating server replies 124 with one or more prefixes. When the lifetime of the prefix(es) 125 expires, the requesting router renews its request for the prefix(es). 127 4. Application Scenarios 129 Diameter prefix delegation application has the applications that are 130 described in this section. 132 4.1. Prefix Management in Access Routers 134 [RFC4968] provides different IPv6 link models that are suitable for 135 IEEE 802.16 based networks and provides analysis of various 136 considerations for each link model and the applicability of each link 137 model under different deployment scenarios. As to IPv6 addressing, 138 there are two models, shared link model and point-to-point link 139 model. In the former model, an IPv6 prefix is shared by multiple 140 MNs. While in the latter model, a prefix is only assigned to one 141 interface of MN. Different MNs can't share a prefix, and an 142 interface can have multiple prefixes. [RFC5121] specifies the 143 addressing and operation of IPv6 over the IPv6 specific part of the 144 packet convergence sub-layer of IEEE Std 802.16e [802.16e], and 145 point-to-point link model is recommended. 147 Also, 3GPP/3GPP2 have earlier adopted the point-to-point link model 148 [RFC3314]. 150 A mobile node and an Access Router are connected via a point-to-point 151 connection at the IPv6 layer. Hence each mobile node can be 152 considered to be on a separate subnet. The prefixes for the mobile 153 node are advertised through Router Advertisement message [RFC4861]. 154 When an MN attaches an Access Router(AR), the AR requests one or more 155 prefixes for the MN from an external server or a local prefix pool. 156 When the MN detaches the AR, the prefixes should be released. When 157 an operator wants to renumber its network, prefixes with different 158 lifetime are advertised to the MN. 160 Diameter prefix delegation application can be the mechanism to deal 161 with how AR acquires and manages these prefixes. 163 4.2. Prefix Management in Local Mobility Anchors 165 [I-D.ietf-netlmm-proxymip6] enables mobility support to a host 166 without requiring its participation in any mobility related 167 signaling. Point-to-point access link is supported. It assumes that 168 the mobile node and the Mobile Access Gateway (MAG) are the only two 169 nodes on the access link. Figure 1 shows a typical process for MN to 170 request it's home network prefix. 172 MN MAG LMA Server 173 |------>| | | 1. RtSol 174 | |------->| | 2. PBU (HNP=0) 175 | | |<------>| 3. Prefix Exchange 176 | |<-------| | 4. PBA (HNP) 177 |<------| | | 5. RA(HNP) 179 Figure 1: Prefix Delegation in Proxy Mobile IPv6 181 1. An MN solicits a router advertisement (RtSol) for stateless 182 address configuration. 183 2. The Mobile Access Gateway (MAG) sends Proxy Binding Update (PBU) 184 message to Local Mobility Anchor (LMA) and with Home Network 185 Prefix (HNP) to zero. 186 3. No details are provided in [I-D.ietf-netlmm-proxymip6] on how LMA 187 manages prefixes. This is one of the motivations to design a 188 Diameter application for prefix delegation. 189 4. The LMA replies PBU with Proxy Binding Acknowledgement (PBA) and 190 sets MN's prefix to HNP field of PBA. 191 5. MAG advertises prefixes to MN with Router Advertisement (RA) for 192 stateless address configuration. 194 4.3. Prefix Management for Mobile Routers 196 [I-D.ietf-nemo-prefix-delegation] specifies mechanism for a Mobile 197 Router(MR) to synchronize its Mobile Network Prefixes with its Home 198 Agents and obtain new ones dynamically. Figure 2 shows the process 199 that a Mobile Router requests prefixes from a Home Agent. 201 MR HA Server 202 | | | 203 |------->| | 1. BU 204 | | | 205 | |<------>| 2. Prefix Exchange 206 | | | 207 |<-------| | 3. BA 208 | | | 210 Figure 2: Prefix Delegation in NEMO 212 1. Mobile Network Prefix request option defined in 213 [I-D.ietf-nemo-prefix-delegation] is included in the Binding 214 Update(BU) to indicate to the Home Agent(HA) that the MR wishes 215 to get new prefixes assigned to it for use as Mobile Networks 216 Prefixes. 217 2. The HA requests prefix from an external entity. There is no 218 further description in [I-D.ietf-nemo-prefix-delegation]. The 219 problem can also be solved by defining a new Diameter 220 application. 221 3. Mobile Network Prefix Confirm option defined in 222 [I-D.ietf-nemo-prefix-delegation] is included in the Binding 223 Acknowledgement to allocate prefixes to the MR. 225 Mobile Network Prefix Confirm option carries the prefix lifetime. 226 Prefixes can be refreshed either by MR sending a BU or by HA sending 227 a BA. 229 5. Requirements on AAA-based Prefix Delegation Application 231 AAA-based prefix delegation (PD) application MUST run between a 232 requesting router (RR), e.g. AR, LMA, MR, etc. and a delegating 233 server (DS) which MUST be AAA server. 235 AAA-based PD application MUST support the AAA client as RR to request 236 prefixes from an AAA server as DS. AAA-based PD application MUST 237 support the client as RR to give back the prefixes to AAA server as 238 DS. 240 If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices 241 connected to the requesting router (RR), the certificate or the 242 information needed to obtain a certificate entitling RR to advertise 243 the prefix delegated to it SHOULD be sent by the delegating router. 245 In point-to-point link operation, the requesting router MUST identify 246 the interface of MN in its request. The requesting router MAY 247 provide a prefix hint, e.g. of length /48 to which the delegating 248 server MUST reply with one or more prefixes, e.g. of length /64. 250 In point-to-point operation, the delegating server MAY assign the 251 prefix(es) and related parameters such as the lifetime and the 252 certificates to MN from MN's profile. 254 AAA-based prefix delegation application SHOULD support prefix release 255 procedures. 257 The AAA client as RR is responsible for renewing the prefixes when 258 the lifetime expires. The AAA client as RR SHOULD be able to extend 259 the lifetime of the prefixes using messages designed for this 260 purpose. 262 It SHOULD be possible to renumber the prefixes delegated by AAA 263 server. The AAA server as DS SHOULD initiate prefix renumbering 264 process. 266 6. Security Considerations 268 This document is a problem statement that does not by itself 269 introduce any security issues. 271 7. IANA Considerations 273 None. 275 8. Acknowledgements 277 9. References 279 9.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 285 Attribute", RFC 4818, April 2007. 287 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 288 Host Configuration Protocol (DHCP) version 6", RFC 3633, 289 December 2003. 291 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 292 "Remote Authentication Dial In User Service (RADIUS)", 293 RFC 2865, June 2000. 295 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 296 RFC 3162, August 2001. 298 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 299 Neighbor Discovery (SEND)", RFC 3971, March 2005. 301 9.2. Informative references 303 [802.16e] Institute of Electrical and Electronics Engineer, 304 "Amendment for Physical and Medium Access Control Layers 305 for Combined Fixed and Mobile Operation in Licensed 306 Bands", IEEE 802.16e/D12. 308 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 309 Madanapalli, "Transmission of IPv6 via the IPv6 310 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 311 February 2008. 313 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 314 Based Networks", RFC 4968, August 2007. 316 [I-D.ietf-nemo-prefix-delegation] 317 Kniveton, T. and P. Thubert, "Mobile Network Prefix 318 Delegation", draft-ietf-nemo-prefix-delegation-02 (work in 319 progress), August 2007. 321 [I-D.ietf-netlmm-proxymip6] 322 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 323 and B. Patil, "Proxy Mobile IPv6", 324 draft-ietf-netlmm-proxymip6-10 (work in progress), 325 February 2008. 327 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 328 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 329 September 2007. 331 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 332 Generation Partnership Project (3GPP) Standards", 333 RFC 3314, September 2002. 335 Authors' Addresses 337 Behcet Sarikaya 338 Huawei USA 339 1700 Alma Dr. Suite 500 340 Plano, TX 75075 342 Phone: +1 972-509-5599 343 Email: sarikaya@ieee.org 345 Frank Xia 346 Huawei USA 347 1700 Alma Dr. Suite 500 348 Plano, TX 75075 350 Phone: +1 972-509-5599 351 Email: xiayangsong@huawei.com 353 Jouni Korhonen 354 TeliaSonera Corporation 355 P.O.Box 970 356 FI-00051 Sonera, FINLAND 358 Email: Jouni.korhonen@teliasonera.com 360 Full Copyright Statement 362 Copyright (C) The IETF Trust (2008). 364 This document is subject to the rights, licenses and restrictions 365 contained in BCP 78, and except as set forth therein, the authors 366 retain all their rights. 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 371 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 372 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Intellectual Property 378 The IETF takes no position regarding the validity or scope of any 379 Intellectual Property Rights or other rights that might be claimed to 380 pertain to the implementation or use of the technology described in 381 this document or the extent to which any license under such rights 382 might or might not be available; nor does it represent that it has 383 made any independent effort to identify any such rights. Information 384 on the procedures with respect to rights in RFC documents can be 385 found in BCP 78 and BCP 79. 387 Copies of IPR disclosures made to the IETF Secretariat and any 388 assurances of licenses to be made available, or the result of an 389 attempt made to obtain a general license or permission for the use of 390 such proprietary rights by implementers or users of this 391 specification can be obtained from the IETF on-line IPR repository at 392 http://www.ietf.org/ipr. 394 The IETF invites any interested party to bring to its attention any 395 copyrights, patents or patent applications, or other proprietary 396 rights that may cover technology that may be required to implement 397 this standard. Please address the information to the IETF at 398 ietf-ipr@ietf.org. 400 Acknowledgment 402 Funding for the RFC Editor function is provided by the IETF 403 Administrative Support Activity (IASA).