idnits 2.17.1 draft-chowdhury-dhc-mip6-agentop-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 433), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 8) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 200: '... The Relay Agent MAY append these opti...' RFC 2119 keyword, line 325: '...rameters, the MN MUST look for the Aut...' RFC 2119 keyword, line 326: '...included, the MN MUST validate the aut...' RFC 2119 keyword, line 328: '...succeeds, the MN SHALL accept the rece...' RFC 2119 keyword, line 333: '...DHCP relay agent MUST append the DHC R...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 15, 2004) is 7133 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) == Missing Reference: 'HA' is mentioned on line 101, but not defined == Missing Reference: 'HoA' is mentioned on line 101, but not defined -- Possible downref: Normative reference to a draft: ref. 'MIP6-RADIUS' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Chowdhury 2 Internet-Draft J. Bharatia 3 Expires: April 15, 2005 Nortel Networks 4 October 15, 2004 6 DHCP Relay Agent Option to Support Mobile IPv6 bootstrapping 7 draft-chowdhury-dhc-mip6-agentop-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 15, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines a new DHCPv6 option and number of sub-options 41 for DHCP Relay Agent to facilitate Mobile IPv6 bootstrapping along 42 with a AAA infrastructure. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 48 2.1 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 6 49 2.2 Home Link Prefix . . . . . . . . . . . . . . . . . . . . . 6 50 2.3 Home Address . . . . . . . . . . . . . . . . . . . . . . . 6 51 2.4 Home Link Prefix Length . . . . . . . . . . . . . . . . . 6 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4. DHC Relay Agent Option to carry Mobile IPv6 parameters . . . . 8 54 4.1 Home Agent sub-option . . . . . . . . . . . . . . . . . . 8 55 4.2 Home Link Prefix sub-option . . . . . . . . . . . . . . . 9 56 4.3 Home Address sub-option . . . . . . . . . . . . . . . . . 9 57 4.4 Home Link Prefix Length sub-option . . . . . . . . . . . . 10 58 4.5 Authenticity sub-option . . . . . . . . . . . . . . . . . 10 59 5. DHC Client Operation Considerations . . . . . . . . . . . . . 12 60 6. DHC Relay agent Considerations . . . . . . . . . . . . . . . . 13 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 66 Intellectual Property and Copyright Statements . . . . . . . . 17 68 1. Introduction 70 In an access network, typically the user's device (Mobile Node) 71 provides authentication credentials to the Access Device for 72 authentication and authorization (e.g. PAP/CHAP). This Access 73 Device may be the Network Access Server (NAS) or an Access Router 74 (AR). Upon receipt of this authentication and authorization 75 information from the user, the Access Device relays it to the Home 76 AAA server. 78 Based on the home network's policy, the Home AAA server verifies the 79 user's profile and includes a set of Mobile IPv6 specific information 80 in the resulting response to the Access Device. Upon receiving the 81 set of information from the Home AAA server, the Access Device needs 82 to convey them to the user. 84 In the networks where DHCPv6 [RFC3315] is used for configuration 85 purposes, the Access Device may act as a DHCPv6 relay agent. In this 86 context the Access Device can relay the received information to the 87 DHCP Client (MN) while sending REPLY message or ADVERTISE message to 88 the DHCP client. 90 An example call flow is shown below: 92 MN/DHCC NAS/DHCR AAA DHCS 93 | 1. access auth-req | | | 94 |---------------------->| 2.auth-req | | 95 | |--------------------->| | 96 | | | | 97 | | 3.auth-rep[HA, HoA] | | 98 | 4.access auth-rep |<---------------------| | 99 |<----------------------| | | 100 | | | | 101 | 5.Store [HA,HoA] | | 102 | | | | 103 | 6.DHC Request | | | 104 |---------------------->| | | 105 | | | | 106 | | 7.RELAY-FORW | | 107 | |------------------------------->| 108 | | | | 109 | | 8.RELAY-REPL | | 110 | |<-------------------------------| 111 | | | | 112 | 9.DHC Reply [HA, HoA]| | | 113 |<----------------------| | | 114 | | | | 116 In this example call flow: 118 1. The Mobile Node sends an access-authentication request to the 119 NAS. 121 2. The NAS sends an authentication and authorization request (e.g. 122 Access-Request for RADIUS or AA-Request for DIAMETER). 124 3. The AAA server authenticates and authorizes the MN and assigns 125 Home Agent (HA) and Home Address for the Mobile Node(MN)'s subsequent 126 Mobile IPv6 access. 128 4. The NAS responds to the MN. At this step the network access 129 authentication and authorization is complete. 131 5. The NAS stores the received HA and HoA information. 133 6. The DHC client (DHCC) in the MN sends a DHCP Request to the DHC 134 relay agents anycast address. The NAS/DHC Relay Agent (DHCR) 135 receives the request. 137 7. The DHCR relays the Request to the DHC Server (DHCS). 139 8. The DHCS responds back to the DHCR. 141 9. The DHCR responds back to the DHCC with a DHC Reply message. 142 Along with the message the DHCR appends the DHC Relay Agent Option 143 for Mobile IPv6 to convey HA and HoA information to the MN. 145 The AAA procedures using RADIUS is defined in [MIP6-RADIUS]. 147 2. Overview 149 In the typical Mobile IPv6 access scenario, the MN attaches in an 150 access network for IPv6 service prior to performing Mobile IPv6 home 151 registration. During this attach procedure, the NAS authenticates 152 and authorizes the MN for IPv6 access service. 154 At the time of authorizing the user, the Home AAA server detects that 155 the user is authorized for Mobile IPv6 access. Based on Home network 156 providers policy, the Home AAA server may allocate several parameters 157 to the MN for user during the subsequent Mobile IPv6 access. A list 158 of such parameters is described in this section. 160 2.1 Home Agent 162 The Home network provider may decide to assign a Home Agent to the MN 163 which is in close proximity to the point of attachment (NAS-ID). 164 There may be other reasons for assigning Home Agents to the MN, e.g. 165 load sharing in the network. The Home network may also assign a list 166 of Home Agents for the MN to choose. 168 2.2 Home Link Prefix 170 The Home network may assign a Home Link that is in close proximity to 171 the point of attachment (NAS-ID). The reason for doing that are 172 similar to that of the HA. The MN can perform [RFC3775] specific 173 procedures to discover other information for Mobile IPv6 174 registration. 176 2.3 Home Address 178 The Home AAA server may assign Home Address to the MN. This allows 179 the network operator to support mobile devices that are not 180 configured with static addresses. 182 2.4 Home Link Prefix Length 184 The Home AAA server may indicate the prefix length of Mobile's 185 assigned Home Link when assigning the Home Agent and/or Home Address 186 to the MN. This assists the MN to infer the Home Link (HL) prefix 187 information from the assigned HA and/or HoA values. 189 3. Terminology 191 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 193 this document are to be interpreted as described in RFC 2119. 195 4. DHC Relay Agent Option to carry Mobile IPv6 parameters 197 This section defines format and syntax for the option that carries 198 the Mobile IPv6 parameters described in section 2. 200 The Relay Agent MAY append these options with the REPLY, ADVERTISE 201 messages. 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | OPTION_MIP6-Option | option-len | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 . sub-options . 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 option-code OPTION_MIP6_option (TBD by IANA). 212 option-len Length of OPTION_MIP6-Option. 214 sub-options A series of sub-options carrying MIP6 215 information such as HA address, HoA, 216 HL etc. 218 4.1 Home Agent sub-option 220 This sub-option carries the assigned Home Agent to the DHCP Client. 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | sub-option=1 | sub-option-len | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 . . 227 . assigned-MIP6-HA . 228 . . 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 sub-option-code MIP6 Home Agent (1). 233 option-len Length of assigned HA fields. 235 assigned-MIP6-HA The address of the Home Agent 236 assigned by the AAA server. 238 4.2 Home Link Prefix sub-option 240 This sub-option carries the assigned Home Link prefix to the DHC 241 Client. 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | sub-option = 2 | sub-option-len | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 . . 248 . assigned-MIP6-HL . 249 . . 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 sub-option-code MIP6 Home Link Prefix (2). 254 option-len Length of assigned HL fields. 256 assigned-MIP6-HL The prefix of the Home Link that is 257 assigned by the AAA server. 259 4.3 Home Address sub-option 261 This sub-option carries the assigned Home Address by the AAA server 262 to the DHC Client. 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | sub-option = 3 | sub-option-len | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 . . 269 . assigned-MIP6-HoA . 270 . . 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 sub-option-code MIP6 Home Address (3). 275 option-len Length of assigned HoA field. 277 assigned-MIP6-HoA HoA assigned by the AAA server. 279 4.4 Home Link Prefix Length sub-option 281 This sub-option carries the Home Link Prefix Length so that the MN 282 can infer the Home Link prefix from the assigned HA and/or HoA. 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | sub-option = 4 | sub-option-len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 . Home Link Prefix Length . 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 sub-option-code Home Link Prefix Length (4). 293 option-len Length of assigned Home Link Prefix 294 Length. 296 Home Link Prefix Length of the Home Link Prefix in 297 Length octets. 299 4.5 Authenticity sub-option 301 This sub-option carries the secure checksum of the assigned values. 302 The purpose is to allow the MN to validate that the received 303 information is indeed from the Home AAA with which the MN shares a 304 secret. The secure checksum is computed by: 306 HMAC-SHA-1 (shared secret between MN and the Home AAA, assigned 307 values). 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | sub-option = 5 | sub-option-len | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 . authenticator . 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 sub-option-code Secure Checksum (6). 318 option-len Length of authenticator. 320 authenticator secure checksum. 322 5. DHC Client Operation Considerations 324 Upon receiving the DHC Relay Agent Option carrying Mobile IPv6 325 parameters, the MN MUST look for the Authenticity sub-option. If 326 included, the MN MUST validate the authenticator by computing an 327 HMAC-SHA-1 of the received values in other sub-options. If the 328 validation succeeds, the MN SHALL accept the received values for 329 Mobile IPv6 registration. 331 6. DHC Relay agent Considerations 333 The DHCP relay agent MUST append the DHC Relay Agent Option defined 334 in this document while sending REPLY and ADVERTISEMENT messages to 335 the DHC Client when the MIP6 informations are received from the Home 336 AAA as per [MIP6-RADIUS]. 338 7. Security Considerations 340 The options introduced in this document may be used by a rogue relay 341 agent to insert data in the REPLY and ADVERTISE messages. The result 342 could be that the MN may be mislead to send Mobile IPv6 BU to a wrong 343 Home Agent. In this case the MN's security credentials could be 344 exposed to a rogue HA. However, if the Authenticity sub-option is in 345 use, the likelihood of a rouge relay agent inserting malicious data 346 or modifying received parameters can be greatly mitigated. 347 Therefore, it is strongly recommended that the authenticity 348 sub-option be included in OPTION_MIP6-Option. 350 8. IANA Considerations 352 IANA needs to assign the option code for OPTION_MIP6-Option. The 353 IANA also needs to assign sub-option-codes for Home Agent, Home Link 354 Prefix, Home Address, Home Link Prefix Length, and the Authenticity 355 sub-options defined in this document. 357 9. Acknowledgements 359 TBD. 361 10 Normative References 363 [MIP6-RADIUS] 364 Chowdhury et. al., K., "RADIUS Attributes for Mobile IPv6 365 bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 366 (work in progress), July 2004. 368 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 369 M. Carney, "Dynamic Host Configuration Protocol for IPv6 370 (DHCPv6)", RFC 3315, July 2003. 372 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 373 in IPv6", RFC 3775, June 2004. 375 Authors' Addresses 377 Kuntal Chowdhury 378 Nortel Networks 379 2221 Lakeside Blvd. 380 Richardson, TX 75082 381 US 383 Phone: +1 972-685-7788 384 EMail: chowdury@nortelnetworks.com 386 Jayshree Bharatia 387 Nortel Networks 388 2221 Lakeside Blvd. 389 Richardson, TX 75082 390 US 392 Phone: +1 972-684-5767 393 EMail: jayshree@nortelnetworks.com 395 Intellectual Property Statement 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 424 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 425 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 426 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The Internet Society (2004). This document is subject 432 to the rights, licenses and restrictions contained in BCP 78, and 433 except as set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.