idnits 2.17.1 draft-ietf-mip6-radius-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 on line 1134. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1152. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1158. ** 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. 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 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 (October 25, 2006) is 6391 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: '18' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1088, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-01 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-03 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-06 -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '11') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '14') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '15') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '16') (Obsoleted by RFC 7155) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chowdhury 3 Internet-Draft Starent Networks 4 Intended status: Standards Track A. Lior 5 Expires: April 28, 2007 Bridgewater Systems 6 H. Tschofenig 7 Siemens 8 October 25, 2006 10 RADIUS Mobile IPv6 Support 11 draft-ietf-mip6-radius-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 April 28, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 A Mobile IPv6 node requires a home agent(HA) address, a home 45 address(HOA), and IPsec security association with its HA before it 46 can start utilizing Mobile IPv6 service. RFC 3775 requires that some 47 or all of these parameters are statically configured. Ongoing work 48 aims to make this information dynamically available to the mobile 49 node. An important aspect of the Mobile IPv6 bootstrapping solution 50 is to support interworking with existing authentication, 51 authorization and accounting (AAA) infrastructure. This document 52 defines new attributes to facilitate Mobile IPv6 bootstrapping via a 53 RADIUS infrastructure. This information exchange may take place as 54 part of the initial network access authentication procedure or as 55 part of a separate protocol exchange between the mobile node, the HA 56 and the AAA infrastructure. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Integrated Scenario . . . . . . . . . . . . . . . . . . . 6 64 3.2. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 7 65 4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 9 66 4.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 9 67 4.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 9 68 4.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 9 69 4.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 9 70 4.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 9 71 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 10 73 5.2. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 11 74 5.3. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 11 75 5.4. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 12 76 5.5. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 13 77 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.1. Integrated Scenario (MSA=ASA) . . . . . . . . . . . . . . 16 79 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 16 80 6.1.2. HA allocation in the ASP (visited network) . . . . . . 17 81 6.2. Split Scenario (MSA!=ASA) . . . . . . . . . . . . . . . . 18 82 6.2.1. Mobile Service Provider and Mobile Service 83 Authorizer are the same entity. . . . . . . . . . . . 18 84 6.2.2. Mobile Service Provider and Mobile Service 85 Authorizer are different entities. . . . . . . . . . . 20 86 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 21 87 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 21 88 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 21 89 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 22 90 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 22 91 7.5. Provisioning of Configuration Parameters . . . . . . . . . 22 92 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 23 93 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 24 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 99 13.2. Informative References . . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . . . . 31 103 1. Introduction 105 Mobile IPv6 specification [5] requires a Mobile Node (MN) to perform 106 registration with a HA with information about its current point of 107 attachment (Care-of Address). The HA creates and maintains binding 108 between the MN's HOA and the MN's Care-of Address. 110 In order to register with a HA, the MN needs to know some information 111 such as, the Home Link prefix, the HA Address, the HOA, the Home Link 112 prefix Length and security related information in order to secure the 113 Binding Update. 115 The aforementioned set of information may be statically provisioned 116 in the MN. However, static provisioning of this information has its 117 drawbacks. It increases provisioning and network maintenance burden 118 for the operator. Moreover, static provisioning does not allow load 119 balancing, failover, opportunistic home link assignment etc. For 120 example, the user may be accessing the network from a location that 121 may be geographically far away from the preconfigured home link; the 122 administrative burden to configure the MN's with the respective 123 addresses is large and the ability to react on environmental changes 124 is minimal. In these situations static provisioning may not be 125 desirable. 127 Dynamic assignment of Mobile IPv6 home registration information is a 128 desirable feature for ease of deployment and network maintenance. 129 For this purpose, the RADIUS infrastructure, which is used for access 130 authentication, can be leveraged to assign some or all of the 131 necessary parameters. The RADIUS server in the Access Service 132 Provider (ASP) or in the Mobility Service Provider's (MSP) network 133 may return these parameters to the AAA client. The AAA client might 134 either be the NAS, in case of the integrated scenario, or the HA, in 135 case of the split scenario. The terms integrated and split are 136 described in the terminology section and were introduced in [6]. 138 2. Terminology 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [1]. 144 General mobility terminology can be found in [7]. The following 145 additional terms, as defined in [6], are used in this document: 147 Access Service Authorizer (ASA): 149 A network operator that authenticates a MN and establishes the 150 MN's authorization to receive Internet service. 152 Access Service Provider (ASP): 154 A network operator that provides direct IP packet forwarding to 155 and from the MN. 157 Mobility Service Authorizer (MSA): 159 A service provider that authorizes Mobile IPv6 service. 161 Mobility Service Provider (MSP): 163 A service provider that provides Mobile IPv6 service. In order to 164 obtain such service, the MN must be authenticated and authorized 165 to obtain the Mobile IPv6 service. 167 Split Scenario: 169 A scenario where the mobility service and the network access 170 service are authorized by different entities. 172 Integrated Scenario: 174 A scenario where the mobility service and the network access 175 service are authorized by the same entity. 177 3. Solution Overview 179 This document addresses the authentication, authorization and 180 accounting functionality required by for the MIPv6 bootstrapping as 181 outlined in the MIPv6 bootstrapping problem statement document (see 182 [6]). As such, the AAA functionality for the integrated and the 183 split scenario needs to be defined. This requires the ability to 184 offer support for the HA to AAA server and the network access server 185 to AAA server communication. 187 To highlight the main use cases, we briefly describe the integrated 188 and the split scenarios in Section 3.1 and Section 3.2, respectively. 190 3.1. Integrated Scenario 192 In the integrated scenario MIPv6 bootstrapping is provided as part of 193 the network access authentication procedure. Figure 1 shows the 194 participating entity. 196 +---------------------------+ +-----------------+ 197 |Access Service Provider | |ASA/MSA/(/MSP) | 198 |(Mobility Service Provider)| | | 199 | | | +-------+ | 200 | +-------+ | | |Remote | | 201 | |Local | RADIUS | | |RADIUS | | 202 | |RADIUS |-------------------------|Server | | 203 | |Proxy | | | +-------+ | 204 | +-------+ | | ^ | 205 | ^ ^ | | |RADIUS | 206 | | | | | | | 207 | | | | | v | 208 | |RADIUS | | +-------+ | 209 | | | +-------+ | | |Local | | 210 | | | RADIUS |Home | | | |Home | | 211 | | +------->|Agent | | | |Agent | | 212 | | |in ASP | | | +-------+ | 213 | v +-------+ | +-----------------+ 214 +-------+ IEEE | +-----------+ +-------+ | 215 |Mobile | 802.1X | |NAS / Relay| |DHCPv6 | | 216 |Node |----------+-|RADIUS |---|Server | | 217 | | PANA,... | |Client | | | | 218 +-------+ DHCP | +-----------+ +-------+ | 219 +---------------------------+ 221 Figure 1: Mobile IPv6 Service Access in the Integrated Scenario 223 In the typical Mobile IPv6 access scenario as shown above, the MN 224 attaches in a ASP's network. During this network attachment 225 procedure, the NAS/RADIUS client interacts with the MN. As shown in 226 Figure 1, the authentication and authorization happens via a RADIUS 227 infrastructure. 229 At the time of authorizing the user for IPv6 access, the RADIUS 230 server in the MSA detects that the user is authorized for Mobile IPv6 231 access. Based on the MSA's policy, the RADIUS server may allocate 232 several parameters to the MN for use during the subsequent Mobile 233 IPv6 protocol interaction with the HA. 235 Depending on the details of the solution interaction with the DHCPv6 236 server may be required, as described in [2]. 238 3.2. Split Scenario 240 In the split scenario, Mobile IPv6 bootstrapping is not provided as 241 part of the network access authentication procedure. The Mobile IPv6 242 bootstrapping procedure is executed with the Mobility Service 243 Provider when desired by the MN. Two variations can be considered: 245 1. the MSA and the MSP are the same entity. 247 2. the MSA and the MSP are different entities. 249 Since scenario (1) is the more generic scenario we show it in 250 Figure 2. 252 +----------------------+ 253 | | 254 |Mobility +-------+ | 255 |Service |Remote | | 256 |Authorizer |RADIUS | | 257 |(MSA) |Server | | 258 | +-------+ | 259 +---------------^------+ 260 | 261 |RADIUS 262 | 263 | 264 +---------------------------------|------+ 265 |Mobility Service Provider (MSP) v | 266 +-------+ | +-----------+ +-------+ | 267 |Mobile | MIPv6 / | |HA/ | RADIUS |Local | | 268 |Node |-------------|RADIUS |-------------- |RADIUS | | 269 | | IKEv2 | |Client | |Proxy | | 270 +-------+ | +-----------+ +-------+ | 271 +----------------------------------------+ 273 Figure 2: Mobile IPv6 service access in the split scenario (MSA != 274 MSP) 276 As shown in Figure 2 the interaction between the RADIUS client and 277 the RADIUS server is triggered by the protocol interaction between 278 the MN and the HA/RADIUS client using IKEv2 (see [3] and [8]). The 279 HA / RADIUS Client interacts with the RADIUS infrastructure to 280 perform authentication, authorization, accounting and parameter 281 bootstrapping. The exchange is triggered by the home agent and an 282 interaction with the RADIUS infrastructure is initiated. When the 283 protocol exchange is completed then the HA needs to possess the 284 Mobile IPv6 specific parameters (see [6]). 286 Additionally, the MN might instruct the RADIUS server (via the home 287 agent) to perform a dynamic DNS update. 289 4. RADIUS Attribute Overview 291 4.1. MIP6-HA Attribute 293 The RADIUS server may decide to assign a HA to the MN that is in 294 close proximity to the point of attachment (e.g., determined by the 295 NAS-ID). There may be other reasons for dynamically assigning HAs to 296 the MN, for example to share the traffic load. The attribute also 297 contains the prefix length so that the MN can easily infer the Home 298 Link prefix from the HA address. 300 4.2. MIP6-HA-FQDN Attribute 302 The RADIUS server may assign an FQDN of the HOA to the MN. The 303 mobile node can perform DNS query with the FQDN to derive the HA 304 address. 306 4.3. MIP6-HL-Prefix Attribute 308 For the same reason as the HA assignment, the RADIUS server may 309 assign a Home Link that is in close proximity to the point of 310 attachment (NAS-ID). The MN can perform [5] specific procedures to 311 discover other information for Mobile IPv6 registration. 313 4.4. MIP6-HOA Attribute 315 The RADIUS server may assign a HOA to the MN. This allows the 316 network operator to support mobile devices that are not configured 317 with static addresses. The attribute also contains the prefix length 318 so that the MN can easily infer the Home Link prefix from the HA 319 address. 321 4.5. MIP6-DNS-MO Attribute 323 By using this payload the RADIUS client instructs the RADIUS server 324 to perform a dynamic DNS update. When this payload is included in 325 the reverse direction, i.e., from the RADIUS server to the RADIUS 326 client, it informs about the status of the dynamic DNS update. When 327 the payload is sent from the RADIUS client to the RADIUS server then 328 the response MUST include the MIP6-DNS-MO attribute. 330 5. RADIUS attributes 332 This section defines format and syntax for the attribute that carries 333 the Mobile IPv6 parameters that are described in the previous 334 section. 336 The attributes MAY be present in Access-Accept, Accounting-Request. 338 5.1. MIP6-HA Attribute 340 This attribute is sent by the RADIUS server to the NAS in an Access- 341 Accept packet. The attribute carries the assigned HA address. 343 This attribute MAY be sent by the NAS to the RADIUS server in an 344 Access-Request packet as a hint to suggest a dynamic HA that may be 345 assigned to the MN. The RADIUS server MAY use this value or may 346 ignore this suggestion. 348 If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- 349 FQDN SHOULD appear in accounting packets to indicate the identity of 350 the serving HA for this session. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | Reserved | Prefix-Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | | 359 | IPv6 address of assigned HA | 360 | | 361 | | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Type: 366 ASSIGNED-HA-ADDR-TYPE to be defined by IANA. 368 Length: 370 = 20 octets 372 Reserved: 374 Reserved for future use. The bits MUST be set to zero by the 375 sender, and MUST be ignored by the receiver. 377 Prefix-Length: 379 This field indicates the prefix length of the Home Link. 381 IPv6 address of assigned HA: 383 128-bit IPv6 address of the assigned HA. 385 5.2. MIP6-HA-FQDN Attribute 387 This attribute is sent by the RADIUS server to the NAS in an Access- 388 Accept packet. The attribute carries the FQDN of the assigned HA. 390 This attribute MAY be sent by the NAS to the RADIUS server in an 391 Access-Request packet as a hint to suggest a dynamic HA that may be 392 assigned to the MN. The RADIUS server MAY use this value or may 393 ignore this suggestion. 395 If available at the NAS, at least MIP6-HA-FQDN attribute and/or 396 MIP6-HA SHOULD appear in accounting packets to indicate the identity 397 of the serving HA for this session. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | FQDN of the assigned HA ..... 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | ... 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Type: 409 ASSIGNED-HA-FQDN-TYPE to be defined by IANA. 411 Length: 413 Variable length. 415 FQDN of the assigned HA: 417 The data field MUST contain a FQDN as described in [9]. 419 5.3. MIP6-HL-Prefix Attribute 421 This attribute is sent by the RADIUS-MIP server to the NAS in an 422 Access-Accept packet. The attribute carries the assigned Home Link 423 prefix. 425 This attribute MAY be sent by the NAS to the RADIUS server in an 426 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 427 attribute as a hint to suggest a Home Link prefix that may be 428 assigned to the MN. The RADIUS server MUST use this value if it 429 accepts the NAS's HA suggestion. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | Reserved | Prefix-Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | | 438 | Home Link Prefix | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Type: 444 ASSIGNED-HL-TYPE to be defined by IANA. 446 Length: 448 >= 4 octets + the minimum length of a prefix. 450 Reserved: 452 Reserved for future use. The bits MUST be set to zero by the 453 sender, and MUST be ignored by the receiver. 455 Prefix-Length: 457 This field indicates the prefix length of the Home Link. 459 Home Link Prefix: 461 Home Link prefix (upper order bits) of the assigned Home Link 462 where the MN should send binding update. 464 5.4. MIP6-HOA Attribute 466 This attribute is sent by the RADIUS server to the NAS in an Access- 467 Accept packet. The attribute carries the assigned Home IPv6 Address 468 for the MN. 470 This attribute MAY be sent by the NAS to the RADIUS server in an 471 Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN 472 attribute as a hint to suggest a Home Address that may be assigned to 473 the MN. The RADIUS server MUST use this value if it accepts the 474 NAS's HA suggestion. 476 If available at the NAS, this attribute SHOULD appear in the 477 accounting packets so that the IPv6 addressed used for this session 478 is known in the accounting stream. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | Reserved | Prefix-Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | 486 | | 487 | Assigned IPv6 HOA | 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Type: 493 ASSIGNED-HOA-TYPE to be defined by IANA. 495 Length: 497 = 20 octets. 499 Reserved: 501 Reserved for future use. The bits MUST be set to zero by the 502 sender, and MUST be ignored by the receiver. 504 Prefix-Length: 506 This field indicates the prefix length of the Home Link. 508 Assigned IPv6 HOA: 510 IPv6 HOA that is assigned to the MN. 512 5.5. MIP6-DNS-MO Attribute 514 The MIP6-DNS-MO attribute is used for triggering a DNS update by the 515 RADIUS server and to return the result to the RADIUS client. The 516 request MUST carry the MN's FQDN but the attribute carried in 517 response to the request MAY not carry a FQDN value. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type | Length | Reserved-1 | Status | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |R| Reserved-2 | FQDN ... 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Type: 529 DNS-UPDATE-TYPE to be defined by IANA. 531 Length: 533 Variable length. 535 Reserved-1: 537 Reserved for future use. The bits MUST be set to zero by the 538 sender, and MUST be ignored by the receiver. 540 Status: 542 This 8 bit unsigned integer field indicates the result of the 543 dynamic DNS update procedure as defined in [3]. This field 544 MUST be set to 0 and ignored by the RADIUS server when the 545 MIP6-DNS-MO is sent from the RADIUS client to the RADIUS 546 server. When the MIP6-DNS-MO is provided in the response, 547 values of the Status field less than 128 indicate that the 548 dynamic DNS update was performed successfully by the RADIUS 549 server. Values greater than or equal to 128 indicate that the 550 dynamic DNS update was not successfully completed. The 551 following values for the Status field are currently defined: 553 0 DNS update performed 555 128 Reason unspecified 557 129 Administratively prohibited 559 130 DNS Update Failed 561 R flag: 563 If this bit for the R flag is set then the RADIUS client 564 requests the RADIUS server to remove the DNS entry identified 565 by the FQDN included in this attribute. If not set, the RADIUS 566 client is requesting the RADIUS server to create or update a 567 DNS entry with the FQDN specified in this attribute and the 568 Home Address carried in another attribute specified in this 569 document. 571 Reserved-2: 573 Reserved for future use. The bits MUST be set to zero by the 574 sender, and MUST be ignored by the receiver. 576 FQDN of the MN: 578 In an Access-Request packet the data field MUST contain a FQDN. 579 In an Access-Accept packet the data field MAY contain an FQDN. 580 FQDN is described in [9]. 582 6. Message Flows 584 6.1. Integrated Scenario (MSA=ASA) 586 This section is based on [2] and uses the previously defined RADIUS 587 attributes. 589 6.1.1. HA allocation in the MSP 591 RADIUS is used to authenticate the MN, to authorize it for the 592 mobility service and to send information about the assigned HA to the 593 NAS. 595 | 596 --------------ASP------>|<--ASA+MSA-- 597 | 598 +----+ +------+ +-------+ +-------+ 599 | | |RADIUS| | | | | 600 | | |Client| | | | | 601 | MN | |NAS/ | | DHCP | |Home | 602 | | |DHCP | | Server| |RADIUS | 603 | | |Relay | | | |Server | 604 +----+ +------+ +-------+ +-------+ 605 | | | | 606 | 1 | 1 | | 607 |<------------->|<---------------------->| 608 | | | | 609 | | | | 610 | 2 | | | 611 |-------------->| | | 612 | | | | 613 | | 3 | | 614 | |------------>| | 615 | | | | 616 | | 4 | | 617 | |<------------| | 618 | | | | 619 | 5 | | | 620 |<--------------| | | 621 | | | | 623 HA allocation in the MSP 625 In step (1), the MN executes the normal network access authentication 626 procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS 627 acts as an authenticator in "pass-through" mode, i.e., the endpoint 628 of the authentication dialogue is the MN's home RADIUS server. This 629 is the typical scenario in case the messages involved in the 630 authentication protocol are transported in EAP. 632 As per [10], the NAS encapsulates/decapsulates EAP packets into/from 633 RADIUS packets until an Access-Response (either an Access-Accept or 634 an Access/Reject packet is received by the NAS). This concludes the 635 network access authentication phase. 637 Depending on the RADIUS server configuration, the MIP6-HA attribute 638 or the the MIP6-HA-FQDN attribute may be appended to the Access- 639 Accept packet. In the latter case the MN needs to perform a DNS 640 query in order to discover the HA address. 642 The MIP6-HA or MIP6-HA-FQDN attribute is appended to the Access- 643 Accept in case the home RADIUS server knows or has allocated a HA to 644 the Access-Request (this is assumed in this scenario). 646 In step (2) the MN sends a DHCPv6 Information Request message to 647 all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code 648 for the Home Network Identifier Option shall be included in that 649 message. The Home Network Identifier Option should have id-type of 650 1, the message is a request to discover home network information that 651 pertains to the given realm, i.e., the user's home domain (identified 652 by the NAI of the MN). The OPTION_CLIENTID is set by the MN to 653 identify itself to the DHCP server. 655 In step (3) the DHCP relay agent forwards this request to the DHCP 656 server. The OPTION_MIP6-RELAY-Option is included in this forwarded 657 message. This option carries the RADIUS MIP6-HA Attribute from the 658 Access-Accept packet. 660 In step (4), the DHCP server identifies the client (by DUID) and 661 finds out that it requests HA information in the MSP (by the Home 662 Network Identifier Option = 1). The DHCP server extracts the HA 663 address from OPTION_MIP6-RELAY-Option and places it into Home Network 664 Information Option in the Reply message. 666 In step (5), the Relay Agent forwards the Reply Message to the MN. 667 On reception of this message, the HA address or the FQDN of the home 668 agent is available at the MN. 670 6.1.2. HA allocation in the ASP (visited network) 672 This scenario is similar to the one described in Section 6.1.1. The 673 difference is in step (2), where the type-id field in the Home 674 Network Identifier Option is set to zero, indicating that a HA is 675 requested in the ASP instead of in the MSP. Thus, the information 676 received by the home RADIUS server, via the DHCP relay, in the 677 OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP 678 server allocates a HA from its list of possible HAs and returns it in 679 the Reply message (Home Network Information Option). 681 6.2. Split Scenario (MSA!=ASA) 683 6.2.1. Mobile Service Provider and Mobile Service Authorizer are the 684 same entity. 686 The assumption in this scenario is that the MN has the domain name of 687 the MSP preconfigured. 689 In this scenario there is no relationship between the network access 690 authentication procedure and the MIPv6 bootstrapping procedure. 692 In order to learn the IP address of the HA, the MN either performs a 693 DNS lookup of the HA Name or a DNS lookup by service name. In the 694 first case, the MN is preconfigured with the FQDN of the HA, and thus 695 sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request 696 for IPv6 address of HA). A DNS reply message is returned by the DNS 697 server with the HA address. 699 The MN then runs IKEv2 [11] with the HA in order to set up IPsec SAs 700 (MN-HA). As part of this,the MN authenticates itself to the RADIUS 701 server in the MSA domain, and obtains authorization for mobility 702 service (including the Home Address). 704 The MN shares credentials with the RADIUS server in the MSA domain. 705 The RADIUS communication between the HA and the this RADIUS server is 706 also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP 707 within IKEv2 [11], the MN is authenticated and authorized for the 708 IPv6 mobility service and is also assigned a HOA. 710 The setup of SAs and mutual authentication between MN and AAAH using 711 RADIUS (and EAP) is similar to the one described for Diameter 712 protocol in [12]. The described mechanism ensureas that common 713 keying material will be available at the MN and HA after successful 714 completion. 716 ----------------------------ASP--------->|<-----MSA/MSP 718 +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ 719 | MN |<----------->| HA |<-------------------->|Remote RADIUS Server| 720 +----+ +----+ +--------------------+ 722 MN HA Remote RADIUS server 723 -- -- -------------------- 724 IKE_SA_INIT 725 <------------------------------> 727 HDR, SK{IDi,[CERTREQ,] [IDr,] 728 SAi2, TSi, TSr} 729 -------------------------------> 730 RADIUS Access-Request(EAP-Response) 731 ----------------------------------> 732 RADIUS Access-Challenge(EAP-Request) 733 <----------------------------------- 734 HDR, SK {IDr, [CERT,] AUTH, 735 EAP } 736 <------------------------------- 737 HDR, SK {EAP} 738 --------------------------------> 739 RADIUS Access-Request(EAP-Response) 740 ----------------------------------> 741 RADIUS Access-Challenge(EAP-Request) 742 <----------------------------------- 743 HDR, SK{EAP-Request} 744 <------------------------------- 745 HDR, SK{EAP-Response} 746 --------------------------------> 747 RADIUS Access-Request(EAP-Response) 748 ----------------------------------> 749 ... ... 751 RADIUS Access-Accept(EAP-Success) 752 <------------------------ 754 HDR, SK{EAP-Success} 755 <------------------------------- 756 HDR, SK{AUTH} 757 -------------------------------> 758 HDR, SK {AUTH, SAr2, TSi, TSr } 759 <------------------------------- 761 Split Scenario Exchange 763 MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages 764 defined in the IKEv2 specification [11], negotiating crypto 765 algorithms and running DH key exchange). IKEv2 supports integration 766 with EAP. The MN indicates its desire to use EAP by not including 767 the AUTH payload in the third message. However, it indicates its 768 identity (NAI) by using the IDi field. If the HA supports EAP for 769 authentication, as per [10] it forwards the identity to the Remote 770 RADIUS server by sending a RADIUS Access-Request packet containing 771 the identity in the EAP-Payload AVP and in the RADIUS User-Name 772 attribute. Based on this identity, the Remote RADIUS server chooses 773 authentication method and sends the first EAP-Request in the RADIUS 774 Access-Challenge packet. During the EAP authentication phase, the HA 775 relays EAP packets between the MN and the Remote RADIUS server. If 776 the authentication succeeds and if the MN is authorized to use Mobile 777 IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept 778 packet containing the EAP-Success and the AAA-Key derived from the 779 EAP authentication method. EAP authentication methods that do not 780 derive keys are not recommended. This key is used by both MN and HA 781 to generate the AUTH payload. In subsequent messages, MN and HA 782 setup IPsec SAs for Mobile IPv6. 784 6.2.2. Mobile Service Provider and Mobile Service Authorizer are 785 different entities. 787 The HA address discovery is performed as described in Section 6.2.1. 789 -----------ASP--------->|<-----MSP------------------->|<-----MSA-------- 791 +----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ 792 | MN |<----------> | HA |<----------->|Local |<---------->|Remote| 793 +----+ +----+ |RADIUS| |RADIUS| 794 |Proxy | |Server| 795 +------+ +------+ 797 MSP#MSA Exchange 799 The scenario is similar to previously described scenarios with the 800 difference of utilizing AAA roaming agreements between the MSP and 801 the MSA. 803 7. Goals for the HA-AAA Interface 805 Here, we follow the classification and labels listed in the MIPv6- 806 AAA-Goals document [13]. 808 7.1. General Goals 810 G1.1-G1.4 Security 812 These are standard requirements for a AAA protocol - mutual 813 authentication, integrity, replay protection, confidentiality. IPsec 814 can be used to achieve the goals. Goal G1.5 regarding inactive peer 815 detection needs further investigations since heartbeat messages do 816 not exist (like in the Diameter case, Watch-Dog-Request/Answer). 818 7.2. Service Authorization 820 G2.1. The AAA-HA interface should allow the use of Network Access 821 Identifier (NAI) to identify the MN. The User-Name attribute can be 822 used for the purpose to carry the NAI. 824 G2.2 The HA should be able to query the AAAH server to verify Mobile 825 IPv6 service authorization for the MN. Any node implementing RADIUS 826 functionality[4] can possibly initiate a request message. In 827 combination with the ability of the RADIUS protocol to carry EAP 828 messages [10] , our solution will enable an HA to query a RADIUS 829 server and verify MIPv6 authorization for the MN. 831 G2.3 The AAAH server should be able to enforce explicit operational 832 limitations and authorization restrictions on the HA (e.g., packet 833 filters, QoS parameters). Work in progress in the area, including 834 NAS-Filter-Rule, RADIUS quality of service support, prepaid 835 extensions etc. is performed. The relevant attributes may be reused 836 for providing required functionality over the AAAH-HA interface. 838 G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 839 session by the AAAH server, e.g., authorization lifetime, extension 840 of the authorization lifetime and explicit session termination by the 841 AAAH server side. 843 The attribute Session-Timeout may be sent in Access-Challenge or 844 Access-Accept packet by the RADIUS server, thus limiting the 845 authorization session duration. In order to reauthenticate/ 846 reauthorize the user, the Termination-Action attribute can be 847 included, with value 1, meaning the NAS should send a new RADIUS- 848 Request packet. Additional AVPs for dealing with pre-paid sessions 849 (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are 850 specified in RADIUS prepaid extension. Exchanging of application 851 specific authorization request/answer messages provides extension of 852 the authorization session (e.g., Authorize Only Access-Request sent 853 by the HA (NAS) to the RADIUS server). Initiation of the re- 854 authorization by both sides could be supported. Both sides could 855 initiate session termination - the RADIUS server by sending 856 Disconnect message [14]. 858 7.3. Accounting 860 G3.1 The AAA-HA interface must support the transfer of accounting 861 records needed for service control and charging. These include (but 862 may not be limited to): time of binding cache entry creation and 863 deletion, octets sent and received by the MN in bi-directional 864 tunneling, etc. 866 The requirements for accounting over the AAAH-HA interface does not 867 require enhancements to the existing accounting functionality. 869 7.4. MN Authentication 871 G4.1 The AAA-HA interface MUST support pass-through EAP 872 authentication with the HA working as EAP authenticator operating in 873 pass-through mode and the AAAH server working as back-end 874 authentication server. 876 These issues require the functionality of AAAH server working as a 877 back-end authentication server and HA working as NAS and EAP 878 authenticator in pass-through mode for providing a MN authentication. 879 This document suggests this mode of operation in the context of the 880 relevant scenarios. 882 7.5. Provisioning of Configuration Parameters 884 G5.1 The HA should be able to communicate to the AAAH server the HOA 885 allocated to the MN (e.g. for allowing the AAAH server to perform DNS 886 update on behalf of the MN). 888 This document describes needed AVPs for this purpose, see section 889 "DNS Update Mobility Option Attribute" 891 8. Table of Attributes 893 The following tables provides a guide to which attributes may be 894 found in RADIUS packet and in what number. 896 The following defines the meaning of the notation used in the following 897 tables: 899 0 This attribute MUST NOT be present. 900 0-1 Zero or one instance of this attribute MAY be present. 902 Request Accept Reject Challenge Type Attribute 904 0-1[a] 0-1[a] 0 0 MIP6-HA-TYPE MIP6-HA Attribute 905 0-1[a] 0-1[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 906 0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 907 0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA Attribute 908 0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 910 Notes: 911 [a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet. 913 [b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request 914 then these attributes MUST also be present in the Access-Request. 915 If the RADIUS server accepts the NAS suggestion for the HA, then 916 the RADIUS server MUST also include the values received for these 917 attributes in the Access-Accept. 919 As used in accounting packets: 921 Request Interim Stop Type Attribute 923 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 924 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 925 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 926 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 927 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 929 9. Diameter Considerations 931 When used in Diameter, the attributes defined in this specification 932 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 933 attribute compatibility space). No additional Diameter Code values 934 are therefore allocated. The data types and flag rules for the 935 attributes are as follows: 937 +---------------------+ 938 | AVP Flag rules | 939 |----+-----+----+-----|----+ 940 | | |SHLD| MUST| | 941 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 942 -------------------------------|----+-----+----+-----|----| 943 MIP6-HA Address | M | P | | V | Y | 944 MIP6-HA-FQDN UTF8String | M | P | | V | Y | 945 MIP6-HL-Prefix OctetString| M | P | | V | Y | 946 MIP6-HOA Address | M | P | | V | Y | 947 MIP6-DNS-MO OctetString| M | P | | V | Y | 948 -------------------------------|----+-----+----+-----|----| 950 Other than MIP6-HA and HOA-IPv6, the attributes in this specification 951 have no special translation requirements for Diameter to RADIUS or 952 RADIUS to Diameter gateways; they are copied as is, except for 953 changes relating to headers, alignment, and padding. See also [15] 954 Section 4.1 and [16] Section 9. MIP6-HA and HOA-IPv6 must be 955 translated between their RADIUS representation of String to a 956 Diameter Address format which requires that the AddressType field be 957 set to 2 for IP6 (IP version 6) 959 What this specification says about the applicability of the 960 attributes for RADIUS Access-Request packets applies in Diameter to 961 AA-Request [16] or Diameter-EAP-Request [17]. What is said about 962 Access-Challenge applies in Diameter to AA-Answer [16] or Diameter- 963 EAP-Answer [17] with Result-Code AVP set to 964 DIAMETER_MULTI_ROUND_AUTH. 966 What is said about Access-Accept applies in Diameter to AA-Answer or 967 Diameter-EAP-Answer messages that indicate success. Similarly, what 968 is said about RADIUS Access-Reject packets applies in Diameter to AA- 969 Answer or Diameter-EAP-Answer messages that indicate failure. 971 What is said about Accounting-Request applies to Diameter Accounting- 972 Request [16] as well. 974 10. Security Considerations 976 Assignment of these values to a user should be based on successful 977 authentication of the user at the NAS and/or at the HA. The RADIUS 978 server should only assign these values to a user who is authorized 979 for Mobile IPv6 service (this check could be performed with the 980 user's subscription profile in the Home Network). 982 The NAS and the HA to the RADIUS server transactions must be 983 adequately secured. Otherwise there is a possibility that the user 984 may receive fraudulent values from a rogue RADIUS server potentially 985 hijacking the user's Mobile IPv6 session. 987 These new attributes do not introduce additional security 988 considerations besides the ones identified in [4]. 990 11. IANA Considerations 992 The following RADIUS attribute Type values MUST be assigned by IANA. 994 MIP6-HA-TYPE 996 MIP6-HA-FQDN-TYPE 998 MIP6-HL-PREFIX-TYPE 1000 MIP6-HOA-TYPE 1002 MIP6-DNS-MO-TYPE 1004 12. Acknowledgements 1006 We would like to thank the following individuals for their review and 1007 constructive comments during the development of this document: 1009 Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, 1010 Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. 1012 13. References 1014 13.1. Normative References 1016 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1017 Levels", BCP 14, RFC 2119, March 1997. 1019 [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 1020 the Integrated Scenario", 1021 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 1022 progress), June 2006. 1024 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 1025 draft-ietf-mip6-bootstrapping-split-03 (work in progress), 1026 October 2006. 1028 [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1029 Authentication Dial In User Service (RADIUS)", RFC 2865, 1030 June 2000. 1032 13.2. Informative References 1034 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1035 IPv6", RFC 3775, June 2004. 1037 [6] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 1038 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 1039 progress), May 2006. 1041 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 1042 RFC 3753, June 2004. 1044 [8] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with 1045 IKEv2 and the revised IPsec Architecture", 1046 draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. 1048 [9] Mockapetris, P., "Domain names - implementation and 1049 specification", STD 13, RFC 1035, November 1987. 1051 [10] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 1052 In User Service) Support For Extensible Authentication Protocol 1053 (EAP)", RFC 3579, September 2003. 1055 [11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1056 RFC 4306, December 2005. 1058 [12] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", 1059 draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), 1060 October 2005. 1062 [13] Giaretta, G., "AAA Goals for Mobile IPv6", 1063 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1064 September 2006. 1066 [14] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 1067 "Dynamic Authorization Extensions to Remote Authentication Dial 1068 In User Service (RADIUS)", RFC 3576, July 2003. 1070 [15] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 1071 "Diameter Base Protocol", RFC 3588, September 2003. 1073 [16] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1074 Network Access Server Application", RFC 4005, August 2005. 1076 [17] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1077 Authentication Protocol (EAP) Application", RFC 4072, 1078 August 2005. 1080 [18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1081 "DNS Security Introduction and Requirements", RFC 4033, 1082 March 2005. 1084 [19] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1085 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1086 Agents", RFC 3776, June 2004. 1088 [20] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1089 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1090 April 1997. 1092 Authors' Addresses 1094 Kuntal Chowdhury 1095 Starent Networks 1096 30 International Place 1097 Tewksbury, MA 01876 1098 US 1100 Phone: +1 214-550-1416 1101 Email: kchowdhury@starentnetworks.com 1103 Avi Lior 1104 Bridgewater Systems 1105 303 Terry Fox Drive, Suite 100 1106 Ottawa, Ontario 1107 Canada K2K 3J1 1109 Phone: +1 613-591-6655 1110 Email: avi@bridgewatersystems.com 1112 Hannes Tschofenig 1113 Siemens 1114 Otto-Hahn-Ring 6 1115 Munich, Bavaria 81739 1116 Germany 1118 Email: Hannes.Tschofenig@siemens.com 1120 Full Copyright Statement 1122 Copyright (C) The Internet Society (2006). 1124 This document is subject to the rights, licenses and restrictions 1125 contained in BCP 78, and except as set forth therein, the authors 1126 retain all their rights. 1128 This document and the information contained herein are provided on an 1129 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1130 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1131 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1132 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1133 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1134 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1136 Intellectual Property 1138 The IETF takes no position regarding the validity or scope of any 1139 Intellectual Property Rights or other rights that might be claimed to 1140 pertain to the implementation or use of the technology described in 1141 this document or the extent to which any license under such rights 1142 might or might not be available; nor does it represent that it has 1143 made any independent effort to identify any such rights. Information 1144 on the procedures with respect to rights in RFC documents can be 1145 found in BCP 78 and BCP 79. 1147 Copies of IPR disclosures made to the IETF Secretariat and any 1148 assurances of licenses to be made available, or the result of an 1149 attempt made to obtain a general license or permission for the use of 1150 such proprietary rights by implementers or users of this 1151 specification can be obtained from the IETF on-line IPR repository at 1152 http://www.ietf.org/ipr. 1154 The IETF invites any interested party to bring to its attention any 1155 copyrights, patents or patent applications, or other proprietary 1156 rights that may cover technology that may be required to implement 1157 this standard. Please address the information to the IETF at 1158 ietf-ipr@ietf.org. 1160 Acknowledgment 1162 Funding for the RFC Editor function is provided by the IETF 1163 Administrative Support Activity (IASA).