idnits 2.17.1 draft-ietf-dime-mip6-integrated-03.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1091. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1097. 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 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2007) is 6276 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 (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4640 == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-03 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen (ed.) 3 Extensions (DIME) TeliaSonera 4 Internet-Draft J. Bournelle 5 Intended status: Standards Track France Telecom R&D 6 Expires: August 16, 2007 H. Tschofenig 7 Siemens Networks GmbH & Co KG 8 C. Perkins 9 Nokia Research Center 10 K. Chowdhury 11 Starent Networks 12 February 12, 2007 14 Diameter Mobile IPv6: NAS <-> HAAA Support 15 draft-ietf-dime-mip6-integrated-03.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 16, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 A Mobile IPv6 node requires a Home Agent address, a home address, and 49 a security association with its Home Agent before it can start 50 utilizing Mobile IPv6. RFC 3775 requires that some or all of these 51 parameters are statically configured. Ongoing Mobile IPv6 52 bootstrapping work aims to make this information dynamically 53 available to the Mobile Node. An important aspect of the Mobile IPv6 54 bootstrapping solution is to support interworking with existing 55 authentication, authorization and accounting infrastructure. This 56 document describes the MIPv6 bootstrapping using the Diameter Network 57 Access Server (NAS) <-> home Authentication, Authorization and 58 Accounting server (HAAA) interface. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Commands, AVPs and Advertising Application Support . . . . . . 7 66 4.1. Advertising Application Support . . . . . . . . . . . . . 7 67 4.2. Command Codes . . . . . . . . . . . . . . . . . . . . . . 7 68 4.3. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 7 69 4.4. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 8 70 4.5. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 9 71 4.6. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 10 72 4.7. Attribute Value Pair Definitions . . . . . . . . . . . . . 11 73 4.7.1. MIP6-Home-Agent-Address AVP . . . . . . . . . . . . . 11 74 4.7.2. MIP6-Home-Agent-FQDN AVP . . . . . . . . . . . . . . . 11 75 4.7.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . 12 76 4.7.4. MIP4-Home-Agent-Address AVP . . . . . . . . . . . . . 12 77 4.7.5. MIP6-Home-Address AVP . . . . . . . . . . . . . . . . 12 78 4.8. Capability Advertisement . . . . . . . . . . . . . . . . . 12 79 5. Diameter Client and Server Behavior During MIPv6 80 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.1. Client (NAS) Behavior . . . . . . . . . . . . . . . . . . 13 82 5.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 14 83 6. Example Message Flows . . . . . . . . . . . . . . . . . . . . 15 84 6.1. EAP-based authentication . . . . . . . . . . . . . . . . . 15 85 6.2. Integrated scenario and HA allocation in MSP . . . . . . . 16 86 6.3. Integrated scenario and HA allocation in ASP . . . . . . . 18 87 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 19 88 7.1. DER and DEA Commands AVP Table . . . . . . . . . . . . . . 19 89 7.2. AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 20 90 8. MIPv6 Bootstrapping NAS - HAAA Interface AVPs . . . . . . . . 21 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 94 12. Revision history . . . . . . . . . . . . . . . . . . . . . . . 23 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 99 Intellectual Property and Copyright Statements . . . . . . . . . . 27 101 1. Introduction 103 The Mobile IPv6 (MIPv6) specification [RFC3775] requires a Mobile 104 Node (MN) to perform registration with a Home Agent (HA) with 105 information about its current point of attachment (Care-of Address). 106 The HA creates and maintains binding between the MN's Home Address 107 and the MN's Care-of Address. 109 In order to register with a HA, the MN needs to know some information 110 such as, the Home Link prefix, the HA address, the Home Address(es), 111 the Home Link prefix Length and security association related 112 information. 114 The aforementioned set of information may be statically provisioned 115 in the MN. However, static provisioning of this information becomes 116 easily provisioning and network administratiOn burden for an 117 operator. Moreover, static provisioning does not address load 118 balancing, failover, opportunistic home link assignment and assigment 119 of local home agents in close proximity to the MN. Also the ability 120 to react on sudden environmental or topological changes is minimal. 121 In a light of above issues static provisioning may not be desirable. 123 Dynamic assignment of MIPv6 home registration information is a 124 desirable feature for ease of deployment and network maintenance. 125 For this purpose, the AAA infrastructure, which is used for access 126 authentication, can be leveraged to assign some or all of the 127 necessary parameters. The Diameter server in Access Service 128 Provider's (ASP) or in Mobility Service Provider's (MSP) network may 129 return these parameters to the AAA client. Regarding the 130 bootstrapping procedures, the AAA client might either be the NAS, in 131 case of the integrated scenario, or the HA, in case of the split 132 scenario [I-D.ietf-mip6-bootstrapping-split]. The terms integrated 133 and split are described in the terminology section and were 134 introduced in [RFC4640] and [I-D.ietf-mip6-aaa-ha-goals]. 136 2. Terminology and Abbreviations 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC2119 [RFC2119]. 142 General mobility terminology can be found in [RFC3753]. The 143 following additional terms, as defined in [RFC4640], are used in this 144 document: 146 Access Service Authorizer (ASA): 148 A network operator that authenticates a MN and establishes the 149 MN's authorization to receive Internet service. 151 Access Service Provider (ASP): 153 A network operator that provides direct IP packet forwarding to 154 and from the MN. 156 Mobility Service Authorizer (MSA): 158 A service provider that authorizes MIPv6 service. 160 Mobility Service Provider (MSP): 162 A service provider that provides MIPv6 service. In order to 163 obtain such service, the MN must be authenticated and authorized 164 to obtain the MIPv6 service. 166 Split scenario: 168 A scenario where the mobility service and the network access 169 service are authorized by different entities. 171 Integrated Scenario: 173 A scenario where the mobility service and the network access 174 service are authorized by the same entity. 176 Network Access Server (NAS): 178 A device that provides an access service for a user to a network. 180 Home AAA (HAAA): 182 An authentication, authorization and accounting server located in 183 user's home network. 185 3. Overview 187 This document addresses the authentication, authorization and 188 accounting functionality required by for the MIPv6 bootstrapping as 189 outlined in the MIPv6 bootstrapping problem statement document 190 [RFC4640]. This document focuses on the Diameter based AAA 191 functionality for the NAS - HAAA interface. 193 In the integrated scenario MIPv6 bootstrapping is provided as part of 194 the network access authentication procedure. Figure 1 shows the 195 participating entities. This document, however, only concentrates on 196 the NAS, possible local Diameter proxies and the home Diameter 197 server. 199 +---------------------------+ +-----------------+ 200 |Access Service Provider | |ASA/MSA/(MSP) | 201 |(Mobility Service Provider)| | | 202 | | | | 203 | +--------+ | | +--------+ | 204 | |Local | Diameter | | |Home | | 205 | |Diameter|<---------------------->|Diameter| | 206 | |Proxy | | | |Server | | 207 | +--------+ | | +--------+ | 208 | ^ ^ | | ^ | 209 | | | | | | | 210 | | | | | | | 211 | Diameter | | v | 212 | | | +-------+ | | +-------+ | 213 | | | |Home | | | |Home | | 214 | | +-------->|Agent | | | |Agent | | 215 | | |in ASP | | | |in MSP | | 216 | v +-------+ | | +-------+ | 217 +-------+ IEEE | +-----------+ +-------+ | +-----------------+ 218 |Mobile | 802.1X | |NAS/Relay | |DHCPv6 | | 219 |Node |------------|Diameter |---|Server | | 220 | | PANA,... | |Client | | | | 221 +-------+ DHCP | +-----------+ +-------+ | 222 +---------------------------+ 224 Figure 1: Mobile IPv6 Bootstrapping in the Integrated Scenario 226 In a typical MIPv6 access scenario the MN is attached to an ASP's 227 network. During the network attachment procedure, the NAS/Diameter 228 client interacts with the MN. 230 During the time of authentication the Diameter server in the MSA 231 detects that the user is also authorized for MIPv6 access. Based on 232 the MSA's policy, the Diameter server may return several MIPv6 233 bootstrapping related parameters. 235 Depending on the details of the bootstrapping solution interaction 236 with the DHCPv6 server may be required, as described in 237 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. However, the Diameter 238 based NAS - HAAA interface described in this document is not tied to 239 DHCPv6 as the only possible MIPv6 bootstrapping method. 241 4. Commands, AVPs and Advertising Application Support 243 This section describes command codes, defines AVPs and advertised 244 application identifiers for the Diameter MIPv6 bootstrapping in the 245 NAS - HAAA interface. 247 4.1. Advertising Application Support 249 Diameter nodes conforming to this specification SHOULD include the 250 value of 1 (NASREQ application) or 5 (EAP application) in the Auth- 251 Application-Id or the Acct-Application-Id AVP in the Capabilities- 252 Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588]. 254 4.2. Command Codes 256 This document re-uses the Diameter NASREQ application [RFC4072] and 257 the EAP application commands [RFC4005]. The following commands are 258 used to carry MIPv6 related bootstrapping AVPs: 260 Command-Name Abbrev. Code Reference Application 262 Diameter-EAP-Request DER 268 RFC 4072 EAP 263 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 265 AA-Request AAR 265 RFC 4005 NASREQ 266 AA-Answer AAA 265 RFC 4005 NASREQ 268 Figure 2: MIPv6 Bootstrapping NAS - HAAA Interface Command Codes 270 When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- 271 Termination-Request (STR), Session-Termination-Answer (STA), Abort- 272 Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request 273 (ACR), and Accounting-Answer (ACA) commands are used together with 274 the MIPv6 bootstrapping NAS - HAAA interface, they follow the rules 275 in the Diameter NASREQ [RFC4005], EAP [RFC4072] and RFC 3588 276 [RFC3588] applications. The accounting commands use the Application 277 Identifier value of 3 (Diameter Base Accounting); the others use 0 278 (Diameter Common Messages). 280 4.3. Diameter-EAP-Request (DER) 282 The Diameter-EAP-Request (DER) command [RFC4072], indicated by the 283 Command-Code field set to 268 and the 'R' bit set in the Command 284 Flags field, may be sent by the NAS to the Diameter server providing 285 network access authentication and authorization services. At the 286 same time with the network access authentication and authorization 287 the NAS MAY indicate the access network capability of MIPv6 288 bootstrapping and optionally also the capability of a local HA 289 assignment. 291 The message format is the same as defined in [RFC4072] with an 292 addition of optional MIPv6 bootstrapping NAS - HAAA interface AVPs to 293 indicate capabilities of the NAS and the ASP: 295 ::= < Diameter Header: 268, REQ, PXY > 296 < Session-Id > 297 { Auth-Application-Id } 298 { Origin-Host } 299 { Origin-Realm } 300 { Destination-Realm } 301 { Auth-Request-Type } 303 [ MIP6-Home-Agent-Address ] 304 [ MIP6-Home-Agent-FQDN ] 305 [ MIP6-Home-Link-Prefix ] 306 [ MIP6-Home-Address ] 307 [ MIP4-Home-Agent-Address ] 309 [ Destination-Host ] 310 ... 311 * [ AVP ] 313 Figure 3: Diameter EAP Request Command 315 4.4. Diameter-EAP-Answer (DEA) 317 The Diameter-EAP-Answer (DEA) message define in [RFC4072], indicated 318 by the Command-Code field set to 268 and 'R' bit cleared in the 319 Command Flags field is sent in response to the Diameter-EAP-Request 320 message (DER). If the network access authentication procedure was 321 successful then the response MAY include any set of MIP6-Home-Agent- 322 Address AVP, MIP6-Home-Link-Prefix, MIP6-Home-Agent-FQDN, MIP6-Home- 323 Address and MIP4-Home-Agent-address AVPs. 325 The message format is the same as defined in [RFC4072] with an 326 addition of optional MIPv6 bootstrapping NAS - HAAA AVPs: 328 ::= < Diameter Header: 268, PXY > 329 < Session-Id > 330 { Auth-Application-Id } 331 { Auth-Request-Type } 332 { Result-Code } 333 { Origin-Host } 334 { Origin-Realm } 336 [ MIP6-Home-Agent-Address ] 337 [ MIP6-Home-Agent-FQDN ] 338 [ MIP6-Home-Link-Prefix ] 339 [ MIP6-Home-Address ] 340 [ MIP4-Home-Agent-Address ] 342 [ User-Name ] 343 ... 344 * [ AVP ] 346 Figure 4: Diameter EAP Answer Command 348 4.5. AA-Request (AAR) 350 The AA-Request (AAR) message, indicated by the Command-Code field set 351 to 265 and 'R' bit set in the Command Flags field, may be sent by the 352 NAS to the Diameter server providing network access configuration 353 services. At the same time with the network access configuration the 354 NAS MAY request HA assignment, to authorize for mobility service 355 usage and optionally to indicate the support of possible local HA 356 assignment. 358 The message format is the same as defined in [RFC4005] with an 359 addition of optional MIPv6 bootstrapping NAS - HAAA AVPs: 361 ::= < Diameter Header: 265, REQ, PXY > 362 < Session-Id > 363 { Auth-Application-Id } 364 { Origin-Host } 365 { Origin-Realm } 366 { Destination-Realm } 367 { Auth-Request-Type } 369 [ MIP6-Home-Agent-Address ] 370 [ MIP6-Home-Agent-FQDN ] 371 [ MIP6-Home-Link-Prefix ] 372 [ MIP6-Home-Address ] 373 [ MIP4-Home-Agent-Address ] 375 [ Destination-Host ] 376 ... 377 * [ AVP ] 379 Figure 5: AA Request Command 381 4.6. AA-Answer (AAA) 383 The AA-Answer (AAA) message, indicated by the Command-Code field set 384 to 265 and 'R' bit cleared in the Command Flags field is sent in 385 response to the AA-Request (AAR) message for confirmation of the 386 result of MIPv6 HA bootstrapping. If the network access 387 authentication procedure was successful then the response MAY include 388 any set of MIP6-Home-Agent-Address AVP, MIP6-Home-Link-Prefix, MIP6- 389 Home-Agent-FQDN, MIP6-Home-Address and MIP4-Home-Agent-address AVPs. 391 The message format is the same as defined in [RFC4005] with an 392 addition of optional MIPv6 bootstrapping NAS - HAAA interface AVPs: 394 ::= < Diameter Header: 265, PXY > 395 < Session-Id > 396 { Auth-Application-Id } 397 { Auth-Request-Type } 398 { Result-Code } 399 { Origin-Host } 400 { Origin-Realm } 402 [ MIP6-Home-Agent-Address ] 403 [ MIP6-Home-Agent-FQDN ] 404 [ MIP6-Home-Link-Prefix] 405 [ MIP6-Home-Address ] 406 [ MIP4-Home-Agent-address ] 408 [ User-Name ] 409 ... 410 * [ AVP ] 412 Figure 6: AA Answer Command 414 4.7. Attribute Value Pair Definitions 416 4.7.1. MIP6-Home-Agent-Address AVP 418 The MIP6-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 419 and contains the MIPv6 HA address and the prefix length of the said 420 address. The AVP is a discriminated union, representing IPv6 address 421 in network byte order. The first two octets of this AVP represents 422 the home link prefix length followed by 16 octets of the IPv6 423 address. 425 The Diameter server MAY decide to assign a MIPv6 HA to the MN that is 426 in close proximity to the point of attachment (e.g. determined by the 427 NAS-Identifier). There may be other reasons for dynamically 428 assigning HAs to the MN, for example to share the traffic load. The 429 AVP also contains the prefix length so that the MN can easily infer 430 one of the possible Home Link prefixes from the HA address. 432 This AVP MAY also be sent by the NAS to the Diameter server in a 433 request message as a hint to suggest a dynamic HA may be assigned to 434 the MN. Based on local policy information the Diameter server may 435 decide to follow the hint or to override this suggestion with its 436 preferred HA IP address. 438 4.7.2. MIP6-Home-Agent-FQDN AVP 440 The MIP6-Home-Agent-FQDN AVP (AVP Code TBD) is of type UTF8String and 441 contains the FQDN of a MIPv6 HA. The usage of this AVP is equivalent 442 to the MIP6-Home-Agent-Address AVP except that the host using the 443 FQDN needs to perform a DNS query in order to discover the HA 444 address. 446 4.7.3. MIP6-Home-Link-Prefix AVP 448 The MIP6-Home-Link-Prefix AVP (AVP Code TBD) is of type OctetString 449 and contains the MIPv6 home link prefix. There may be reasons for 450 the Diameter server to dynamically assigning home link prefix to the 451 MN, for example one that is in close proximity to the point of 452 attachment. 454 The MN can perform RFC 3775 [RFC3775] specific procedures to discover 455 other information for MIPv6 registration. 457 4.7.4. MIP4-Home-Agent-Address AVP 459 The MIP4-Home-Agent-Address AVP (AVP Code TBD) is of type OctetString 460 and contains the IPv4 HA address and the prefix length of the said 461 address. The AVP is a discriminated union, representing IPv4 address 462 in network byte order. The first two octets of this AVP represents 463 the home link prefix length followed by 4 octets of the IPv4 address. 465 The Diameter server MAY decide to assign a MIPv4 HA to the MN in a 466 case where dual stack Mobile IP is supported 467 [I-D.ietf-mip6-nemo-v4traversal]. 469 4.7.5. MIP6-Home-Address AVP 471 The MIP6-Home-Address AVP (AVP Code TBD) is of type OctetString and 472 contains the MIPv6 Home Address and the prefix length of the said 473 address. The AVP is a discriminated union, representing IPv6 address 474 in network byte order. The first two octets of this AVP represents 475 the Home Address prefix length followed by 16 octets of the IPv6 476 address. 478 The Diameter server MAY assign a home address to the MN. This allows 479 the network operator to support MNs that are not configured with 480 static addresses. The attribute also contains the prefix length so 481 that the MN can easily infer the home link prefix from the HA 482 address. 484 4.8. Capability Advertisement 486 The NAS/ASP may include any MIPv6 bootstrapping AVPs in the DER or 487 AAR messages in order to advertise its MIPv6 bootstrapping 488 capabilities to the Diameter server. This capability advertisement 489 may also be used to propose locally allocated mobility agents, 490 locally allocated prefix or home address to the Diameter server. As 491 an example the MIP6-Home-Agent-Address AVP could contain the IP 492 address of the locally allocated HA. 494 If the MIP6-Home-Agent-Address AVP is only used as a MIPv6 495 bootstrapping capability indicator then the IP address MUST be set to 496 unspecified address (::/128). The MIP6-Home-Agent-FQDN AVP SHOULD 497 NOT be used for the capability advertisement if it does not name a 498 locally allocated HA. 500 5. Diameter Client and Server Behavior During MIPv6 Bootstrapping 502 This section describes the Diameter server and client behavior in 503 case of the MIPv6 bootstrapping in the integrated scenario. The text 504 makes several assumptions. 506 o The Diameter server supports at least the Diameter BASE, EAP and 507 NASREQ applications. 508 o The Diameter client (i.e., the NAS) supports at least the Diameter 509 BASE, EAP and NASREQ applications. 510 o The MN uses such network access authentication method and 511 credentials that are supported by the NAS/ASP and ASA/MSA. 512 o The MN has been provisioned with a MIPv6 service. 514 5.1. Client (NAS) Behavior 516 If the ASP/NAS does not support MIPv6 integrated scenario 517 bootstrapping then the NAS either selects the basic Diameter NASREQ 518 or EAP application depending on which authentication method gets 519 used. Naturally after a successful or a failed authentication the 520 NAS does not have to carry out any MIPv6 bootstrapping related 521 procedures. 523 Next, we describe two different scenarios for the network access 524 authentication when the ASP/NAS supports MIPv6 integrated scenario 525 bootstrapping. 527 1) The MN uses some EAP-based method for network access 528 authentication. In this scenario the NAS uses commands originally 529 defined for the EAP application. 530 2) The MN uses a non-EAP-based network access authentication 531 procedure. In this scenario the NAS uses the Diameter NASREQ 532 application commands. 534 The NAS may include the MIPv6 NAS - HAAA AVPs in the DER or in the 535 AAR messages. This serves two purposes. Firstly the NAS/ASP may 536 advertise its MIPv6 bootstrapping capability to the Diameter server. 538 Secondly the NAS/ASP may suggest locally allocated HAs to the 539 Diameter server. Whether the locally allocated HAs are allowed for 540 the forthcoming MIPv6 session depends on the MN's subscription and 541 the ASA/MSA(/MSP) policies. If the NAS/ASP only wants to advertise 542 its capability for local agent allocation but does not want to 543 provide any specific agent at this point of time (e.g. that is left 544 for later steps during the actual Mobile IP registration) the AVPs 545 MUST contain values described in Section 4.8. 547 If the network access authentication failed the NAS receives 548 appropriate error codes as defined for the Diameter EAP or NASREQ 549 applications. The NAS does not allow the MN to access the network 550 and does not do any MIPv6 bootstrapping related procedures. 552 If the network access authentication completed successfully, the NAS 553 looks for HA defining AVPs in the reply messages (either DEA or AAA 554 depending on the used authentication method). The NAS associates the 555 received bootstrapping information to the MN that initiated the 556 access authentication and stores the information internally (storing 557 time is determined by the ASP policy). The stored bootstrapping 558 information is then available for the NAS and the DHCP relay for 559 later step during the MN bootstrapping process. 561 The actual bootstrapping from the MN point of view takes place after 562 the network access authentication has completed. The bootstrapping 563 may be realized e.g. using DHCP as defined in 564 [I-D.ietf-mip6-bootstrapping-integrated-dhc] and [RFC2132]. 566 The MN has no consistent way of indicating to the NAS that it 567 supports MIPv6 integrated scenario way of bootstrapping during the 568 network access authentication. Subsequently the NAS has no 569 possibilities to find out whether the terminal attempting to 570 authenticate is actually a MN with MIPv6 bootstrapping functionality 571 prior the network access authentication has completed. Thus, it is 572 possible that the NAS initiates MIPv6 integrated scenario 573 bootstrapping configuration even if the MN is not able to make any 574 use of it later. The Diameter server in the ASA/MSA might be able to 575 detect this situation during the authentication phase based on the 576 information in the subscriber database assuming the ASA is able to 577 verify whether the MN has been provisioned with a MIPv6 service (from 578 the MSA/MSP). 580 5.2. Server Behavior 582 If the NAS/ASP does not support MIPv6 integrated scenario 583 bootstrapping then the NAS either selects the Diameter NASREQ or EAP 584 application depending on which access authentication method the MN 585 has to use to authenticate. In this case the NAS does not either 586 include any MIPv6 NAS - HAAA interface AVPs as a hint of the 587 bootstrapping capability in the NAS/ASP. The Diameter server in the 588 ASA/MSA(/MSP) detects this case (based on AVPs that serve as a 589 capability hint) and does not have to carry out any MIPv6 590 bootstrapping related procedures. However, as the capability 591 advertisement mechanism described in this document serves only as an 592 optional hint, the Diameter server should not entirely rely on the 593 received capability hints but also base its working logic on 594 subscription information and general MSA(/MSP) policies. 596 Next we describe two different scenarios for the network access 597 authentication when the NAS/ASP supports MIPv6 integrated scenario 598 bootstrapping. 600 1) The MN uses some EAP-based method to authenticate to the network 601 and the NAS uses Diameter EAP application commands. Depending on 602 the ASA/MSA(/MSP) policy the Diameter server SHOULD assign a MIPv6 603 HA to the MN and include corresponding MIP6-Home-Agent-Address, 604 the MIP6-Home-Agent-FQDN AVPs and the MIP6-Home-Link-Prefix in the 605 final DEA message. 606 2) The MN uses some other than EAP-based method to authenticate to 607 the network and the NAS uses Diameter NASREQ application commands. 608 Depending on the ASA/MSA(/MSP) policy the Diameter server SHOULD 609 assign a MIPv6 HA to the MN and include corresponding MIP6-Home- 610 Agent-Address, the MIP6-Home-Agent-FQDN AVPs and the MIP6-Home- 611 Link-Prefix in the final AAA message. 613 If the Diameter request message contained any MIPv6 NAS -HAAA 614 interface AVPs the Diameter server should regard them as a hint of 615 the MIPv6 bootstrapping capability in the NAS/ASP. Any of these AVPs 616 may contain values as described in Section 4.8 which indicate the 617 NAS/ASP would like to locally allocate a HA or a home link to the MN. 618 The Diameter server may or may not honor the NAS/ASP hint based on 619 the MN's subscription and ASA/MAS(/MSP) policies. 621 6. Example Message Flows 623 6.1. EAP-based authentication 625 This section shows basic message flows of MIPv6 integrated scenario 626 bootstrapping and dynamic HA assignment. In the Figure 7 network 627 access authentication is based on EAP (e.g. 802.11i/802.1X). The NAS 628 informs the home Diameter server that HA assignment in the foreign 629 network is possible. The Diameter server assigns the MN a HA either 630 in the home MSP or in the ASP. The assignment procedure is out of 631 scope of this document. The Diameter server then replies to the NAS 632 with HA related bootstrapping information. 634 NAS Local proxy Home server 635 | | | 636 | Diameter-EAP-Request | | 637 | MIP6-Home-Agent-Address(IPv6 address) | 638 | MIP6-Home-Agent-FQDN=visited_ha6.example.com | 639 | MIP4-Home-Agent-Address(IPv4 address) | 640 | MIP6-Home-Link-Prefix(IPv6 prefix) | 641 | MIP6-Home-Address(IPv6 address) | 642 | Auth-Request-Type=AUTHORIZE_AUTHENTICATE | 643 | EAP-Payload(EAP Start) | | 644 |------------------------------->|------------------------------->| 645 | | | 646 | : | 647 : ...more EAP Request/Response pairs... : 648 | : | 649 | | | 650 | | Diameter-EAP-Answer | 651 | MIP6-Home-Agent-Address(IPv6 address) | 652 | MIP6-Home-Agent-FQDN=ha.example.com | 653 | MIP6-Home-Address(IPv6 address) | 654 | | Result-Code=DIAMETER_SUCCESS | 655 | | EAP-Payload(EAP Success) | 656 | | EAP-Master-Session-Key | 657 | | (authorization AVPs) | 658 | | ... | 659 |<-------------------------------|<-------------------------------| 660 | | | 662 Figure 7: MIPv6 integrated scenario bootstrapping and NAS - HAAA 663 interface example when EAP is used for access authentication 665 6.2. Integrated scenario and HA allocation in MSP 667 Diameter is used to authenticate and authorize the MN for the 668 mobility service, and to send information about the allocated HA to 669 the NAS. In this example scenario the MN uses DHCP for its IP 670 address configuration. 672 | 673 --------------ASP------>|<--ASA/MSA/(MSP)-- 674 | 675 +----+ +--------+ +-------+ +--------+ 676 | | |Diameter| | | | | 677 | | | Client | | | | | 678 | MN | | NAS/ | | DHCP | | Home | 679 | | | DHCP | | Server| |Diameter| 680 | | | Relay | | | | Server | 681 +-+--+ +----+---+ +---+---+ +--------+ 682 | | | | 683 | 1 | 2 | | 684 |<------------->|<----------------------->| 685 | | | | 686 | | | | 687 | 3 | | | 688 |-------------->| | | 689 | | | | 690 | | 4 | | 691 | |------------>| | 692 | | | | 693 | | 5 | | 694 | |<------------| | 695 | | | | 696 | 6 | | | 697 |<--------------| | | 698 | | | | 700 Figure 8: HA allocation in MSP 702 1) The MN executes the normal network access authentication procedure 703 (IEEE 802.11i/802.1X, PANA, ...) with the NAS. The NAS acts as an 704 authenticator in "pass-through" mode. The other endpoint of the 705 authentication dialogue is the MN's home Diameter server. This is 706 a typical scenario for e.g. EAP-based authentication methods. 707 The NAS includes at least one of the NAS-HAAA interface AVPs in 708 the DER or in the AAR messages to indicate MIPv6 bootstrapping 709 capability. For example the NAS could include MIP6-Home-Agent- 710 Address AVP with 0::/128 as the HA address (the NAS has no 711 particular HA to propose to the Diameter server). 713 2) Depending on the Diameter server configuration and the 714 subscription profile, the MIP6-Home-Agent-Address AVP or the MIP6- 715 Home-Agent-FQDN AVP may be appended to the DEA or to the AAA 716 message, assuming the home Diameter server knows or has allocated 717 a HA to the MN. In case the MIP6-Home-Agent-FQDN AVP was returned 718 the MN ultimately needs to perform a DNS query in order to 719 discover the HA address. For example the home Diameter server 720 could return the following AVPs: 722 o MIP6-Home-Agent-Address = 2001:2001:6000:302::1/64 723 o MIP6-Home-Address = 2001:2001:6000:302::dead:beef/64 724 o MIP6-Home-Link-Prefix = 2001:2001:6000:302::/64 726 3) the MN sends a DHCPv6 Information Request message to 727 all_DHCP_Relay_Agents_and_Servers address. In the OPTION_ORO, 728 Option Code for the Home Network Identifier Option shall be 729 included in that message 730 [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The Home Network 731 Identifier Option should have id-type of 1, the message is a 732 request to discover home network information that pertains to the 733 given realm, i.e., the user's home domain (identified by the NAI 734 of the MN). The OPTION_CLIENTID is set by the MN to identify 735 itself to the DHCP server. 737 Steps 4 to 6 are not relevant in NAS-HAAA Diameter interface point of 738 view and are not described in this document. Refer 739 [I-D.ietf-mip6-bootstrapping-integrated-dhc] for detailed information 740 about the rest of the integrated scenario bootstrapping procedure. 742 6.3. Integrated scenario and HA allocation in ASP 744 This scenario is similar to the one described in Section 6.2 and 745 illustrated in Figure 8. There are slight differences in steps 2) 746 and 3). 748 2) The NAS/ASP has allocated a local HA (e.g. with IP address 2001: 749 788:1:c020::1/64) and a local prefix, and proposes those to MN's 750 home Diameter server. For example the NAS includes following AVPs 751 in the DER or in the AAR messages: 753 o MIP6-Home-Agent-Address = 2001:788:1:c020::1/64 754 o MIP6-Home-Link-Prefix = 2001:788:1:c020::/64 756 Depending on the Diameter server configuration and the 757 subscription profile, the Diameter server either accepts or 758 rejects the HA IP address (or FQDN) proposed by the NAS/ASP. If 759 the Diameter server accepts the proposed HA the AVP containing the 760 HA information is returned as is back to the NAS. In this example 761 the returned IP6-Home-Agent-Address AVP would contain the same 762 2001:788:1:c020::1/64 IP address value. On the orher hand if the 763 Diameter server does not accept the proposed HA, the Diameter 764 server overwrites the MIP6-Home-Agent-Address AVP value with an IP 765 address of the preferred HA (e.g. 2001:2001:6000::1/64) and 766 returns the new IP address back to the NAS/ASP (the MIP6-Home- 767 Agent-FQDN AVP is handled in the same way when present). This is 768 also an indication to the NAS/ASP that locally allocated HAs are 769 not to be used. In a case when the home Diameter server accepted 770 the NAS/ASP proposed local HA the home Diameter server would 771 return e.g. the following AVPs: 773 o MIP6-Home-Agent-Address = 2001:788:1:c020::1/64 774 o MIP6-Home-Link-Prefix = 2001:788:1:c020::/64 776 3) The type-id field in the Home Network Identifier Option is set to 777 zero, indicating that a HA is requested in the ASP instead of in 778 the MSP. Depending on the result of the phase 2) the DHCP relay 779 agent places in the OPTION_MIP6-RELAY-Option either the locally 780 allocated HA information or the HA information that was returned 781 (overwritten) by home Diameter server. 783 7. AVP Occurrence Tables 785 7.1. DER and DEA Commands AVP Table 787 The following table lists the additional MIPv6 bootstrapping NAS - 788 HAAA interface AVPs that optionally may be present in the DER and DEA 789 Commands, as defined in this document and in [RFC4072]. 791 +---------------+ 792 | Command-Code | 793 |-------+-------+ 794 Attribute Name | DER | DEA | 795 -------------------------------+-------+-------+ 796 MIP6-Home-Agent-Address [ab] | 0-1 | 0-1 | 797 MIP6-Home-Agent-FQDN [ab] | 0-1 | 0-1 | 798 MIP4-Home-Agent-Address | 0-1 | 0-1 | 799 MIP6-Home-Link-Prefix [cd] | 0-1 | 0-1 | 800 MIP6-Home-Address [cd] | 0-1 | 0-1 | 801 +-------+-------+ 802 Notes: 803 [a] Either MIP6-Home-Agent-Address or MIP6-Home-Agent-FQDN 804 MAY appear in DER or DEA Commands. 806 [b] If the Diameter server accepts the NAS suggestion for 807 the HA, then the Diameter server MUST also include the 808 values received in these AVPs in the DEA Command. 810 [c] Either MIP6-Home-Link-Prefix or MIP6-Home-Address MAY 811 appear in DER or DEA Commands. 813 [d] If either MIP6-Home-Address or MIP6-Home-Link-Prefix are 814 present in the DER Command then the corresponding AVP MUST 815 also be included in the DEA Command. If the Diameter server 816 accepts the NAS suggestion for the HoA or for the Prefix 817 then the Diameter server MUST also include values received 818 in these AVPs in the DEA Command. 820 Figure 9: DER and DEA Commands AVP Table 822 7.2. AAR and AAA Commands AVP Table 824 The following table lists the additional MIPv6 bootstrapping NAS - 825 HAAA interface AVPs that may optionally be present in the AAR and AAA 826 Commands, as defined in this document and in [RFC4005]. 828 +---------------+ 829 | Command-Code | 830 |-------+-------+ 831 Attribute Name | AAR | AAA | 832 -------------------------------|-------+-------| 833 MIP6-Home-Agent-Address [ab] | 0-1 | 0-1 | 834 MIP6-Home-Agent-FQDN [ab] | 0-1 | 0-1 | 835 MIP4-Home-Agent-Address | 0-1 | 0-1 | 836 MIP6-Home-Link-Prefix [cd] | 0-1 | 0-1 | 837 MIP6-Home-Address [cd] | 0-1 | 0-1 | 838 +-------+-------+ 839 Notes: 840 [a] Either MIP6-Home-Agent-Address or MIP6-Home-Agent-FQDN 841 MAY appear in AAR or AAA Commands. 843 [b] If the Diameter server accepts the NAS suggestion for 844 the HA, then the Diameter server MUST also include the 845 values received in these AVPs in the AAA Command. 847 [c] Either MIP6-Home-Link-Prefix or MIP6-Home-Address MAY 848 appear in AAR or AAA Commands. 850 [d] If either MIP6-Home-Address or MIP6-Home-Link-Prefix are 851 present in the AAR Command then the corresponding AVP MUST 852 also be included in the AAA Command. If the Diameter server 853 accepts the NAS suggestion for the HoA or for the Prefix 854 then the Diameter server MUST also include values received 855 in these AVPs in the AAA Command. 857 Figure 10: AAR and AAA Commands AVP Table 859 8. MIPv6 Bootstrapping NAS - HAAA Interface AVPs 861 This section defines the AVPs that are specific to Diameter MIPv6 862 bootstrapping NAS - HAAA interface and MAY be included in the 863 Diameter EAP [RFC4072] and the NASREQ [RFC4005] applications messages 864 listed in Section 4 of this document. The Diameter AVP rules are 865 defined in the Diameter Base [RFC3588], Section 4. These AVP rules 866 are observed in AVPs defined in this section. 868 The following table describes the Diameter AVPs, their AVP Code 869 values, types, possible flag values, and whether the AVP MAY be 870 encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules 871 for AVPs in section 4.5. 873 +---------------------+ 874 | AVP Flag rules | 875 +----+-----+----+-----+----+ 876 AVP Section | | |SHLD|MUST | | 877 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 878 -----------------------------------------+----+-----+----+-----+----+ 879 MIP6-Home-Agent- TBD 4.7.1 OctetString| | P | | M,V | Y | 880 Address | | | | | | 881 MIP6-Home-Agent- TBD 4.7.2 UTF8String | | P | | M,V | Y | 882 FQDN | | | | | | 883 MIP4-Home-Agent- TBD 4.7.4 OctetString| | P | | M,V | Y | 884 address | | | | | | 885 MIP6-Home-Link- TBD 4.7.3 Unsigned32 | | P | | M,V | Y | 886 Prefix | | | | | | 887 MIP6-Home-Address TBD 4.7.5 OctetString| | P | | M,V | Y | 888 -----------------------------------------+----+-----+----+-----+----+ 890 Figure 11: AVP Flag Rules Table 892 9. IANA Considerations 894 This specification defines the following new AVPs: 896 MIP6-Home-Agent-Address is set to TBD 897 MIP6-Home-Agent-FQDN is set to TBD 898 MIP4-Home-Agent-Address is set to TBD 899 MIP6-Home-Link-Prefix is set to TBD 900 MIP6-Home-Address is set to TBD 902 10. Security Considerations 904 The security considerations for the Diameter interaction required to 905 accomplish the integrated scenario are described in 906 [I-D.ietf-mip6-bootstrapping-integrated-dhc] . Additionally, the 907 security considerations of the Diameter base protocol [RFC3588], 908 Diameter NASREQ application [RFC4005] / Diameter EAP [RFC4072] 909 application (with respect to network access authentication and the 910 transport of keying material) are applicable to this document. 912 11. Acknowledgements 914 This document is heavily based on the ongoing work for RADIUS MIPv6 915 interaction. Hence, credits go to respective authors for their work 916 with draft-ietf-mip6-radius-00.txt. Furthermore, the author would 917 like to thank the authors of draft-le-aaa-diameter-mobileipv6-04.txt 918 (Franck Le, Basavaraj Patil, Charles E. Perkins, Stefano Faccin) for 919 their work in context of MIPv6 Diameter interworking. Their work 920 influenced this document. Julien Bournelle would like to thank GET/ 921 INT since he began to work on this document while he was in their 922 employ. 924 12. Revision history 926 The following changes were made to the -01 version of the draft: 928 o The document title was changed to "The NAS - HAAA Interface for 929 MIPv6 Bootstrapping". 930 o Added HAAA and NAS to terminology section". 931 o Changed NAS application to NASREQ application.". 932 o Changed "Integrated Scenario" to NAS-HAAA interface". 933 o The separate Diameter Application-ID for MIPv6 bootstrapping 934 (MIP6BSTI) got removed and all bootstrapping is based on Diameter 935 EAP application and Diameter NAS application. 936 o MIPv6-Bootstrapping-Feature AVP was removed and General text 937 regarding to the capability advertisement based on optional AVPs 938 was added. 939 o The capability exchange was modified so that the NAS may suggest a 940 specific HA to the AAAH. Original MIPv6-Bootstrapping-Feature AVP 941 was replaces with a possibility to include any bootstrapping AVP 942 to the Diameter AAR or DER messages as a capability and local 943 allocation hint. 945 The following changes were made to the -02 version of the draft: 947 o Section 7 NAS - HAAA Interface AVPs flags were corrected. 'M' 948 flag was listed as MUST even if it should have been MUST NOT. 949 o General shortening of the text. 950 o Addition of the MIP6-Home-Address AVP. 951 o Checked against draft-ietf-mip6-radius-01. 952 o Addition of noted & constrains to AVP tables. 953 o Miscellaneous corrections like Mobile IPv6 -> MIPv6. 954 o Added signaling examples for HA assignment from MSP, and local HA 955 assignment. 957 The following changes were made to the -03 version of the draft: 959 o Section 7.1 corrected case [d] mixed AVPs. 960 o Section 7.2 corrected case [d] mixed AVPs. 962 13. References 963 13.1. Normative References 965 [I-D.ietf-mip6-aaa-ha-goals] 966 Giaretta, G., "AAA Goals for Mobile IPv6", 967 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 968 September 2006. 970 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 971 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 972 Integrated Scenario", 973 draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in 974 progress), February 2007. 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", March 1997. 979 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 980 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 982 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 983 in IPv6", RFC 3775, June 2004. 985 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 986 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, 987 September 2006. 989 13.2. Informative References 991 [I-D.ietf-mip6-bootstrapping-split] 992 Giaretta, G., "Mobile IPv6 bootstrapping in split 993 scenario", draft-ietf-mip6-bootstrapping-split-04 (work in 994 progress), December 2006. 996 [I-D.ietf-mip6-nemo-v4traversal] 997 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 998 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03 999 (work in progress), October 2006. 1001 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1002 Extensions", RFC 2132, March 1997. 1004 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1005 RFC 3753, June 2004. 1007 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1008 "Diameter Network Access Server Application", RFC 4005, 1009 August 2005. 1011 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1012 Authentication Protocol (EAP) Application", RFC 4072, 1013 August 2005. 1015 Authors' Addresses 1017 Jouni Korhonen 1018 TeliaSonera 1019 Teollisuuskatu 13 1020 Sonera FIN-00051 1021 Finland 1023 Email: jouni.korhonen@teliasonera.com 1025 Julien Bournelle 1026 France Telecom R&D 1027 38-4O rue du general Leclerc 1028 Issy-Les-Moulineaux 92794 1029 France 1031 Email: julien.bournelle@orange-ftgroup.com 1033 Hannes Tschofenig 1034 Siemens Networks GmbH & Co KG 1035 Otto-Hahn-Ring 6 1036 Munich, Bavaria 81739 1037 Germany 1039 Email: Hannes.Tschofenig@siemens.com 1040 URI: http://www.tschofenig.com 1042 Charles E. Perkins 1043 Nokia Research Center 1044 313 Fairchild Drive 1045 Mountain View CA 94043 1046 US 1048 Phone: +1 650 625-2986 1049 Email: charliep@iprg.nokia.com 1050 Kuntal Chowdhury 1051 Starent Networks 1052 30 International Place 1053 Tewksbury MA 01876 1054 US 1056 Phone: +1 214 550 1416 1057 Email: kchowdhury@starentnetworks.com 1059 Full Copyright Statement 1061 Copyright (C) The IETF Trust (2007). 1063 This document is subject to the rights, licenses and restrictions 1064 contained in BCP 78, and except as set forth therein, the authors 1065 retain all their rights. 1067 This document and the information contained herein are provided on an 1068 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1069 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1070 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1071 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1072 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1073 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1075 Intellectual Property 1077 The IETF takes no position regarding the validity or scope of any 1078 Intellectual Property Rights or other rights that might be claimed to 1079 pertain to the implementation or use of the technology described in 1080 this document or the extent to which any license under such rights 1081 might or might not be available; nor does it represent that it has 1082 made any independent effort to identify any such rights. Information 1083 on the procedures with respect to rights in RFC documents can be 1084 found in BCP 78 and BCP 79. 1086 Copies of IPR disclosures made to the IETF Secretariat and any 1087 assurances of licenses to be made available, or the result of an 1088 attempt made to obtain a general license or permission for the use of 1089 such proprietary rights by implementers or users of this 1090 specification can be obtained from the IETF on-line IPR repository at 1091 http://www.ietf.org/ipr. 1093 The IETF invites any interested party to bring to its attention any 1094 copyrights, patents or patent applications, or other proprietary 1095 rights that may cover technology that may be required to implement 1096 this standard. Please address the information to the IETF at 1097 ietf-ipr@ietf.org. 1099 Acknowledgment 1101 Funding for the RFC Editor function is provided by the IETF 1102 Administrative Support Activity (IASA).