idnits 2.17.1 draft-ietf-dime-mip6-split-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 81 has weird spacing: '...xplicit sessi...' == Line 373 has weird spacing: '...xplicit sessi...' -- 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 (June 19, 2006) is 6520 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: '13' is defined on line 483, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '2') == Outdated reference: A later version (-07) exists of draft-ietf-mip6-bootstrapping-split-02 ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4005 (ref. '6') (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 3588 (ref. '8') (Obsoleted by RFC 6733) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-01 == Outdated reference: A later version (-01) exists of draft-tschofenig-dime-diameter-qos-00 -- Obsolete informational reference (is this intentional?): RFC 4006 (ref. '12') (Obsoleted by RFC 8506) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-01 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Bournelle (Ed.) 3 Extensions (DIME) GET/INT 4 Internet-Draft G. Giaretta 5 Expires: December 21, 2006 Telecom Italia 6 H. Tschofenig 7 Siemens 8 June 19, 2006 10 Mobile IPv6 Bootstrapping using Diameter in the Split Scenario 11 draft-ietf-dime-mip6-split-00 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 December 21, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 In Mobile IPv6 deployment a need for an interaction between the Home 45 Agent, the AAA infrastructure of the Mobile Service Provider (MSP) 46 and the Mobility Service Authorizer (MSA) has been identified. This 47 document describes how Diameter can be used to perform AAA 48 functionalities for the Mobile IPv6 service in the "split" scenario. 50 For this, it describes two possible approaches. It also explains how 51 Diameter meet the goals outlined in the MIPv6 AAA goals document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Bootstrapping Mobile IPv6 in the Split Scenario . . . . . . . 3 58 4. Use of Diameter EAP for the Mobile IPv6 Split Scenario . . . . 5 59 4.1. NAS-Port-Type AVP . . . . . . . . . . . . . . . . . . . . 6 60 4.2. A new Application ID . . . . . . . . . . . . . . . . . . . 6 61 4.3. Accounting for the Mobile IPv6 Service . . . . . . . . . . 6 62 5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 7 65 5.1.2. Dead peer detection - the HA-AAA interface SHOULD 66 support inactive peer detection. . . . . . . . . . . . 7 67 5.2. Service Authorization . . . . . . . . . . . . . . . . . . 8 68 5.2.1. G2.1. The HA-AAA interface SHOULD allow the use of 69 Network Access Identifier (NAI) to identify the 70 mobile node. . . . . . . . . . . . . . . . . . . . . . 8 71 5.2.2. G2.2. The HA SHOULD be able to query the AAAH 72 server to verify Mobile IPv6 service authorization 73 for the mobile node. . . . . . . . . . . . . . . . . . 8 74 5.2.3. G2.3. The AAAH server SHOULD be able to enforce 75 explicit operational limitations and authorization 76 restrictions on the HA.( e.g. packet filters, QoS 77 parameters). . . . . . . . . . . . . . . . . . . . . . 8 78 5.2.4. G2.4 - G2.6. Issues addressing the maintenance of 79 a Mobile IPv6 session by the AAAH server, e.g. 80 authorization lifetime, extension of the 81 authorization lifetime and explicit session 82 termination by the AAAH server side. . . . . . . . . . 8 83 5.3. Accounting - G3.1. The HA-AAA interface MUST support 84 the transfer of accounting records needed for service 85 control and charging . . . . . . . . . . . . . . . . . . . 9 86 5.4. Mobile Node Authentication (G4.1.) . . . . . . . . . . . . 9 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 92 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 Intellectual Property and Copyright Statements . . . . . . . . . . 13 96 1. Introduction 98 In Mobile IPv6 deployment, authentication, authorization and 99 accounting issues in the protocol operations are approached by using 100 the AAA infrastructure. [9] presents a number of bootstrapping 101 scenarios using the HA-AAA interface and defines a list of 102 requirements that have to be fulfilled. This document deals with the 103 functional capabilities of the Diameter protocol as a AAA protocol 104 applicable for the split scenario. 106 This document focuses only on the split scenario. A separate 107 document [10] describes a Diameter application for bootstrapping 108 MIPv6 for the integrated scenario. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [1]. 116 The MIPv6 bootstrapping terminology is taken from [2]. 118 3. Bootstrapping Mobile IPv6 in the Split Scenario 120 In the split scenario for bootstrapping Mobile IPv6 [3], the Mobile 121 Node (MN) discovers a Home Agent (belonging to the Mobility Service 122 Provider (MSP)) through DNS. Then, the Mobile Node uses IKEv2 [4] to 123 setup IPsec SAs. Use of IKEv2 also provides a way to authenticate 124 the MN by the Mobility Service Authorizer (MSA). Note that in the 125 same time, the Mobile Node can authenticate the Home Agent. IKEv2 126 supports the Extensible Authentication Protocol (EAP) to run an EAP 127 method between the MN and the EAP server that is often separated from 128 the IKEv2 responder, i.e., the HA in our scenario. As such, the MN 129 can reuse its credentials (obtained from the MSA) to be authenticated 130 for the IPv6 mobility service. As outlined in [4] a HA-AAA interface 131 is needed. Since, EAP is used to authenticate the MN, the interface 132 between the Home Agent and the AAA server will be based on the 133 Diameter EAP application [5]. Figure 1 represents the architecture 134 of the split scenario. 136 +-------+ IKEv2 +----------------+ Diameter EAP +----+ 137 | Mobile| | Home Agent/ | | | 138 | Node |<----------->| Diameter Client|<-------------------->|AAAH| 139 +-------+ +----------------+ +----+ 141 Figure 1: Diameter EAP for HA-AAA in the Split Scenario 142 The Mobile Node acts as the EAP client and IKEv2 Initiator. The Home 143 agent is the IKEv2 Responder and acts a Diameter client from a AAA 144 perspective. The AAAH is the home AAA server of the MN (i.e. AAA 145 server of the MSA) and relies on a EAP server to authenticate the 146 Mobile Node. If MSP is different from the MSA, the Home Agent may 147 directly contact the AAAH or a local AAA server which will act as a 148 AAA proxy (cf. [5]). 150 Figure 2 shows the message flow. 152 Mobile Node HA/Diameter Client Home AAA/EAP Server 153 ---------- ----------------- ------------------- 154 IKE_SA_INIT (1,2) 155 <------------------------------> 157 HDR, SK{IDi,[CERTREQ,] [IDr,] 158 SAi2, TSi, TSr} (3) 159 -------------------------------> 160 DER (EAP-Response) 161 ------------------------> 162 DEA (EAP-Request) 163 <------------------------ 164 HDR, SK {IDr, [CERT,] AUTH, 165 EAP } 166 <------------------------------- 167 HDR, SK {EAP} 168 --------------------------------> 169 DER (EAP-Response) 170 ------------------------> 171 DEA (EAP-Request) 172 <------------------------ 173 HDR, SK{EAP-Request} 174 <------------------------------- 175 HDR, SK{EAP-Response} 176 --------------------------------> 177 DER (EAP-Response) 178 ------------------------> 179 ... ... 181 DEA (EAP-Success) 182 <------------------------ 183 HDR, SK{EAP-Success} 184 <------------------------------- 185 HDR, SK{AUTH} 186 -------------------------------> 187 HDR, SK {AUTH, SAr2, TSi, TSr } 188 <------------------------------- 189 Figure 2: IKEv2 Diameter EAP Message Flow 191 The interaction between the MN and the HA starts with an IKE_SA_INIT 192 to setup the IKE SA. The MN indicates its desire to use EAP by not 193 including the AUTH payload in the third message. The MN indicates 194 its identity (e.g Network Access Identitifer) using the IDi field. 195 If the Home Agent, acting as an IKEv2 Responder, supports EAP for 196 authentication and relies on a remote AAA server, the Diameter client 197 part of the Home Agent sends a Diameter-EAP-Request (DER) message 198 containing the identity in the EAP-Payload AVP and in the User-Name 199 AVP. The AAAH chooses an authentication method and sends the first 200 EAP-Request in the Diameter-EAP-Answer message. During the EAP 201 authentication phase, the HA relays EAP packets between the MN (EAP 202 client) and the AAAH (Home EAP server). If the authentication 203 succeeds and if the MN is authorized to use Mobile IPv6 service, the 204 AAAH sends a DEA message containing the EAP-success and the AAA-Key 205 derived from the Master Session Key (MSK) exported by the EAP method. 206 Some specific configuration elements may also be sent in AVPs. Note 207 that EAP methods that do not derive keys are not recommended since 208 they cannot bind the EAP method authentication to the IKEv2 209 authentication. In the latter message, the MN and the HA finalize 210 the IPsec SAs setup to protect Mobile IPv6 signalling. 212 4. Use of Diameter EAP for the Mobile IPv6 Split Scenario 214 In the split scenario, the Home Agent uses the AAA infrastructure in 215 order to perform authentication, authorization and accounting for the 216 Mobile IPv6 service. This document proposes to reuse the Diameter 217 EAP application [5] since EAP is used by the HA to authenticate the 218 MN inside IKEv2. 220 However, the Diameter EAP application has been designed to perform 221 AAA for the network access service. As the Mobile IPv6 service is 222 different from the network access service, it appears that a Diameter 223 server needs a way to make this distinction. Indeed, even if the 224 authentication is provided by the EAP method, authorization and 225 accounting for network access and IPv6 mobility might be different. 226 The AAA server needs to explicitly authorize the Mobile IPv6 service. 227 It may also need to configure specific parameters for the Mobile IPv6 228 service such as the type of Home Address to provide to the MN. 229 Accounting may also require other parameters than those defined for 230 network access. 232 [Editor's Note: It is not clear at this point of time which approach 233 is the best to handle this. For this reason, this document explains 234 two possible approaches.] 236 4.1. NAS-Port-Type AVP 238 As explained below, the AAA server needs a way to identify that it is 239 performing AAA operations for the Mobile IPv6 service. One way to do 240 this is to require that the Home Agent puts the NAS-Port-Type AVP 241 indicating that it is a Mobile IPv6 Home Agent in the first DER 242 message. This would be formulated as: "The Home Agent MUST include 243 the NAS-Port-Type AVP". This requires a change in the current ABNF 244 definition of this message. The AAA server would have to check the 245 presence of this AVP in the first received DER message and would have 246 to recognize the new type defined for the Home Agent. 248 [Editor's Note: It is not clear at this point of time if this change 249 in the ABNF definition would require a new Application-Id.] 251 Moreover, the NAS-Port-Type AVP is defined as: "The NAS-Port-Type AVP 252 (AVP Code 61) is of type Enumerated and contains the type of the port 253 on which the NAS is authenticating the user. This AVP SHOULD be 254 present if the NAS uses the same NAS-Port number ranges for different 255 service types concurrently" (see [6]). Hence, if the DIME WG decides 256 to use this approach, it is necessary to define a new type for Home- 257 Agent. 259 If an operator wants to use one AAA server for network access and 260 another one for IPv6 mobility service then the some messages may be 261 routed to the wrong AAA server since routing is also based on the 262 Application-ID. 264 4.2. A new Application ID 266 The second approach is to require a new application ID for the Mobile 267 IPv6 service. In this case, all messages will be correctly routed to 268 the right Diameter Application. This specific application will 269 specifically handle all AAA Operations for the Mobile IPv6 service as 270 it is done for Mobile IPv4 (cf. [7]). However, the protocol 271 description requires that the new application needs to copy the 272 Diameter messages from the Diameter EAP application. 274 The problem with defining a new Application ID is that every proxies 275 on the path would need a new code to understand this application. 277 4.3. Accounting for the Mobile IPv6 Service 279 Concerning Accounting, the Diameter Mobile IPv4 Application [7] 280 defines the following AVPs: Accounting-Input-Octets (Number of octets 281 in IP packets received from the user), Accounting-Output-Octets 282 (Number of octets in IP packets sent by the user, Accounting-Input- 283 Packets (Number of IP packets received from the user), Accounting- 284 Output-Packets (Number of IP packets sent by the user). 286 These AVPs may be re-used for the Mobile IPv6 service. However, due 287 to some optimizations for Mobile IPv6, the HA may not see all the IP 288 traffic resulting from the activation of this service. 290 [Editor's Note: As the document describing goals for this interface 291 is not finalized, other parameters may be needed in the future.] 293 5. Goals 295 In this section, we present how the goals for a HA-AAA interface 296 presented in [9] are met by this proposal. Note that the two 297 approaches presented above does not affect what is described here. 299 [Editor's Note: the goals presented here are those described in [9]. 300 Future revision of the mentionned document will affect this section.] 302 5.1. General goals 304 5.1.1. G1.1 - G1.4 Security 306 As design goals for an AAA interface, G1.1 - G1.4 goals specify 307 standard requirements for a AAA protocol - mutual authentication of 308 the peers, integrity, replay protection and confidentiality. The 309 Diameter Base Protocol requires IPsec or TLS to provide hop-by-hop 310 security. 312 5.1.2. Dead peer detection - the HA-AAA interface SHOULD support 313 inactive peer detection. 315 Two possible approaches might be considered here: 317 o The AAAH server and the Home Agent establish a transport 318 connection between each other. It is the case if the Diameter 319 Client of the HA has a direct route to its AAA server. In this 320 case Diameter heartbeat messages called Device-Watchdog-Request/ 321 Answer [8], which are exchanged over this connection to test for 322 its aliveness, can be used to detect inactivity between the two 323 Diameter peers. 325 o The AAAH server and the Home Agent do not have transport 326 connection. In this case inactive peer detection functionality 327 should be provided into the Diameter session - service stateless 328 Diameter sessions might be established between the AAAH server and 329 the range of MSP's Home Agents for detecting HAs availability. 331 5.2. Service Authorization 333 5.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network 334 Access Identifier (NAI) to identify the mobile node. 336 Identification by the User-Name AVP [8], which has a format 337 consistent with the NAI specifications, is common for Diameter 338 applications. Diameter provides functionality for routing of 339 Diameter requests based on the information included in the User-Name 340 AVP. 342 The Mobile Node provides its NAI using the IDi field during the IKEv2 343 exchange with the HA. 345 5.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify 346 Mobile IPv6 service authorization for the mobile node. 348 The goal of this document is to explain how to use Diameter to 349 perform AAA operations for the Mobile IPv6 service. The 350 Authentication is done through the use of EAP. The Mobile IPv6 351 service Authorization is an explicit goal of this document. 353 [Editor's note: As explained above, how the AAA server know that it 354 is for Mobile IPv6 service has not yet been decided by the DIME WG.] 356 5.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit 357 operational limitations and authorization restrictions on the 358 HA.( e.g. packet filters, QoS parameters). 360 Several present Diameter applications, standardized or under work-in- 361 progress address an operation and authorization control for specific 362 services and have defined appropriate AVPs. The NAS-Filter-Rule AVP, 363 defined by Diameter NASREQ application [6], provides IP packet filter 364 description. QoS-Filter-Rule AVP defined by Diameter NASREQ 365 application and by the Diameter QoS application [11] provide QoS 366 parameter description. The Credit Control application [12] provides 367 support for prepaid services, tariff switching, cost control over 368 requested services. The available funcationalities might be re-used 369 in this document. 371 5.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6 372 session by the AAAH server, e.g. authorization lifetime, 373 extension of the authorization lifetime and explicit session 374 termination by the AAAH server side. 376 Diameter base protocol provides a powerful set of commands and AVPs 377 for management of the authorization and accounting sessions. A 378 number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout- 379 AVP) handle the duration (in time) of an authorization session [8]. 380 Additional AVPs for measuring the authorization duration in units 381 different that time are specified too [12]. Exchanging of 382 application specific authorization request/answer messages provides 383 extension of the authorization session. Initiation of the re- 384 authorization by both sides could be supported. Both sides could 385 initiate session termination, by using Diameter Session Termination 386 and Abort Session messages. 388 All these are applied to the Diameter session used for authorization 389 of a Mobile IPv6 session and need to be applied appropriately to this 390 Mobile IPv6 session too. 392 5.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer 393 of accounting records needed for service control and charging 395 Diameter accounting protocol provides a variety of options - real- 396 time accounting, event/session-type accounting records, fault 397 resilience, correlation of accounting records. Requirements for the 398 accounting services over AAAH-HA interface are standard. Definition 399 or re-used of AVPs for the specific accounting records combined with 400 the functionality of the Diameter accounting protocol should provide 401 desired accounting services. 403 5.4. Mobile Node Authentication (G4.1.) 405 These issues require the functionality of AAAH server working as a 406 back-end authentication server and HA working as NAS and EAP 407 authenticator in pass-through mode for providing a mobile node 408 authentication. This functionality is provided by the Diameter 409 NASREQ [6] and the Diameter EAP applications [5] application, and 410 will be re-used in this document. 412 6. Security Considerations 414 [Editor's Note: Since the document is not complete it is necessary to 415 state that the security consideration section is incomplete as well. 416 Hence, it is only possible to refer to the security issues raised in 417 the Mobile IPv6 and Diameter protocol related documents mentioned 418 here, such as [9] and [8].] 420 7. IANA Considerations 422 [Editor's note: Since the document is not complete, the IANA 423 considerations is incomplete as well.] 425 8. Acknowledgements 427 The authors would like to thanks Jari Arkko, Tolga Asversen, Pasi 428 Eronen, Santiago Zapata Hernandez, Jouni Korhonen, Anders Kristensen, 429 Avi Lior, John Loughney, Lionel Morand and Yoshihiro Ohba for their 430 inputs to the "Application-ID for the Mobile IPv6 split scenario ?" 431 discussion. 433 9. References 435 9.1. Normative References 437 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 438 Levels", BCP 14, RFC 2119, March 1997. 440 [2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 441 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 442 progress), May 2006. 444 [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", 445 draft-ietf-mip6-bootstrapping-split-02 (work in progress), 446 March 2006. 448 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 449 December 2005. 451 [5] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 452 Authentication Protocol (EAP) Application", RFC 4072, 453 August 2005. 455 [6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 456 Network Access Server Application", RFC 4005, August 2005. 458 [7] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. 459 McCann, "Diameter Mobile IPv4 Application", RFC 4004, 460 August 2005. 462 [8] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 463 "Diameter Base Protocol", RFC 3588, September 2003. 465 9.2. Informative References 467 [9] Giaretta, G., "Goals for AAA-HA interface", 468 draft-ietf-mip6-aaa-ha-goals-01 (work in progress), 469 January 2006. 471 [10] Tschofenig, H., "Diameter MIPv6 Application for the Integrated 472 Scenario", draft-tschofenig-dime-mip6-integrated-00 (work in 473 progress), March 2006. 475 [11] Alfano, F., "Diameter Quality of Service Application", 476 draft-tschofenig-dime-diameter-qos-00 (work in progress), 477 March 2006. 479 [12] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 480 Loughney, "Diameter Credit-Control Application", RFC 4006, 481 August 2005. 483 [13] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for 484 the Integrated Scenario", 485 draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in 486 progress), June 2006. 488 Authors' Addresses 490 Julien Bournelle 491 GET/INT 492 9 rue Charles Fourier 493 Evry 91011 494 France 496 Email: julien.bournelle@int-evry.fr 498 Gerardo Giaretta 499 Telecom Italia Lab 500 via G. Reiss Romoli, 274 501 TORINO, 10148 502 Italy 504 Email: gerardo.giaretta@telecomitalia.it 506 Hannes Tschofenig 507 Siemens 508 Otto-Hahn-Ring 6 509 Munich, Bavaria 81739 510 Germany 512 Email: Hannes.Tschofenig@siemens.com 513 URI: http://www.tschofenig.com 515 Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; nor does it represent that it has 522 made any independent effort to identify any such rights. Information 523 on the procedures with respect to rights in RFC documents can be 524 found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use of 529 such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository at 531 http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at 537 ietf-ipr@ietf.org. 539 Disclaimer of Validity 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 545 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 546 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Copyright Statement 551 Copyright (C) The Internet Society (2006). This document is subject 552 to the rights, licenses and restrictions contained in BCP 78, and 553 except as set forth therein, the authors retain all their rights. 555 Acknowledgment 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.