idnits 2.17.1 draft-droms-dhc-v6-relayopt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 515 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 3 instances of too long lines in the document, the longest one being 1 character 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 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 2004) is 7126 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 58 looks like a reference -- Missing reference section? '6' on line 449 looks like a reference -- Missing reference section? '11' on line 64 looks like a reference -- Missing reference section? '9' on line 97 looks like a reference -- Missing reference section? '10' on line 97 looks like a reference -- Missing reference section? '3' on line 432 looks like a reference -- Missing reference section? '12' on line 486 looks like a reference -- Missing reference section? '13' on line 486 looks like a reference -- Missing reference section? '4' on line 216 looks like a reference -- Missing reference section? '8' on line 352 looks like a reference -- Missing reference section? '7' on line 410 looks like a reference -- Missing reference section? '5' on line 432 looks like a reference -- Missing reference section? '14' on line 486 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Ralph Droms 3 Cisco Systems 4 Internet Draft Wing Cheong Lau 5 Document: draft-droms-dhc-v6-relayopt-00.txt Qualcomm 6 Expires: March 2005 October 2004 8 DHCPv6 Relay Agent Information Option 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document introduces the capabilities of the DHCPv4 Relay Agent 36 Information Option in RFC 3046 and the corresponding RADIUS- 37 Attributes Sub-option to DHCPv6. In particular, the document 38 describes a new DHCPv6 option called the Relay Agent Information 39 option which extends the set of DHCPv6 options as defined in RFC 3315 40 and 3376. Following its DHCPv4 counterpart as defined in RFC 3046, 41 the new option is inserted by the DHCPv6 relay agent when forwarding 42 client-originated DHCPv6 packets to a DHCPv6 server. Servers 43 recognizing the Relay Agent Information option may use the 44 information to implement IP address or other parameter assignment 45 policies. The DHCP Server echoes the option back verbatim to the 46 relay agent in server-to-client replies, and the relay agent strips 47 the option before forwarding the reply to the client. The Relay Agent 48 Information option is organized as a single DHCPv6 option that 49 contains one or more "sub-options" that convey information known by 50 the relay agent. A RADIUS Attributes Sub-option, following its 51 DHCPv4 counterpart, is also defined. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [2]. 59 The use of the standard keywords MUST, SHOULD, MUST NOT and SHOULD 60 NOT within this specification are with respect to RADIUS clients and 61 servers that implement the optional features of this specification, 62 do not create any normative requirements outside of that scope and do 63 not modify the base RADIUS specifications, such as RFC2865 [6] or 64 RFC2866 [11]. 66 Throughout this document, "DHCP" refers to DHCP for IPv6 unless 67 explicitly stated otherwise. 69 Table of Contents 71 1. Motivation and Introduction....................................2 72 2. Terminology....................................................4 73 2.1 DHCP Terminology...........................................4 74 2.2 RADIUS Terminology.........................................5 75 3. Relay Agent Information Option for DHCPv6......................5 76 3.1 Relay Agent Operation......................................7 77 3.2 Server Operation...........................................8 78 3.3 DHCP Client Behavior.......................................8 79 4. Relay Agent Information Sub-options............................8 80 4.1 RADIUS Attributes sub-option...............................8 81 5. Security Considerations.......................................10 82 6. IANA Considerations...........................................11 83 7. Acknowledgments...............................................11 84 8. Intellectual Property Statement...............................11 85 9. Full copyright statement......................................12 86 Authors' Addresses...............................................12 87 References.......................................................12 89 1. Motivation and Introduction 91 In 3GPP2 networks, the Packet Data Service Node (PDSN) provides the 92 function of a Network Access Server (NAS) to enable authenticated 93 network access of its clients, i.e. the mobile stations (MS). The 94 PDSN also acts as a DHCPv6 relay agent to forward requests and 95 responses between an MS and a DHCPv6 server within the network. The 96 DHCPv6 server may be used for assigning DNS server, Mobile IPv6 Home 97 agent (HA), Mobile IPv6 Home address (HoA) [9,10] and other 98 configuration parameters for the MS. The PDSN, using RADIUS as an 99 authentication authority, will receive attributes from a RADIUS 100 server that may be used by the DHCP server in the selection of 101 configuration parameters to be delivered to the MS through its DHCP 102 client. The Relay Agent Information option, together with the RADIUS 103 Attributes sub-option enable a network element like the PDSN in 3GPP2, 104 to pass along attributes for the user of a device received during 105 RADIUS authentication to a DHCP server. 107 The RADIUS Attributes sub-option for the DHCP Relay Agent Information 108 option provides a way in which a NAS, such as the 3GPP2 PDSN, can 109 pass attributes obtained from a RADIUS server to a DHCP server [3]. 110 The 3GPP2 access authentication mechanism is an example through which 111 a PDSN (which doubles as the NAS) can authenticate the identity of 112 the user of a device before providing network access using RADIUS as 113 the Authentication Service specified in [6]. In 3GPP2 authenticated 114 access, an MS must first exchange some authentication credentials 115 with the PDSN. The PDSN then supplies these credentials to a RADIUS 116 server, which eventually sends either an Access-Accept or an Access- 117 Reject in response to an Access-Request. The PDSN, based on the reply 118 of the RADIUS server, then allows or denies network access to the 119 requesting device. 121 Figure 1 summarizes the message exchange among the participants in 122 3GPP2 network access authentication. 124 +------------------+ 125 |Mobile Station(MS)| 126 | requesting | 127 | network access | 128 +------------------+ 129 | ^ 130 | | 131 (1) Request for access 132 | | 133 | (4) Success/Failure 134 v | 135 +-------------------+ 136 | 3GPP2 PDSN | 137 | (Acts as NAS | 138 | and | 139 |DHCPv6 relay agent)| 140 +-------------------+ 141 | ^ 142 | | 143 (2) Request for authentication 144 | | 145 | (3) Access-Accept/Reject 146 v | 147 +-----------------+ 148 | RADIUS | 149 | Server | 150 +-----------------+ 152 Figure 1 154 In the application described in this document, the PDSN acts as a NAS 155 as well as a DHCPv6 relay agent. It adds a DHCP Relay Agent 156 Information option which includes a RADIUS Attributes sub-option to 157 DHCP messages. At the successful conclusion of network access 158 authentication, a RADIUS Access-Accept provides attributes for 159 service authorizations to the NAS. The NAS stores these attributes 160 locally. When the NAS subsequently forwards DHCP messages from the 161 device requesting network access, the NAS adds these attributes in a 162 RADIUS Attributes Sub-option for the Relay Agent Information option. 164 This document uses 3GPP2 access authentication as an example to 165 motivate the use of the Relay Agent Information option and the RADIUS 166 Attributes sub-option by a NAS. The Relay Agent Information option is 167 not limited to use in conjunction with RADIUS sub-option when other 168 sub-options are defined in the future. The RADIUS Attributes sub- 169 option for the Relay Agent Information option described in this 170 document is not limited to use in conjunction with 3GPP2 and can be 171 used to carry RADIUS attributes obtained by the relay agent for any 172 reason. That is, the sub-option is not limited to use with 3GPP2, 173 but is constrained by RADIUS semantics. 175 The scope of applicability of this specification is such that the NAS 176 (which acts as a DHCP relay agent), any other participating DHCP 177 relay agent, the DHCP server and DHCP client should be within the 178 same administrative domain while the RADIUS service involved may span 179 multiple administrative domains. See the Section 5 for details of 180 security considerations when this specification is deployed with 181 RADIUS service operating across multiple administrative domains. 182 Global interoperability of this specification, across arbitrary 183 administrative domains, is not supported. 185 2. Terminology 187 2.1 DHCP Terminology 188 The following terms are used as defined in RFC3315 and RFC3736: DHCP 189 relay agent, DHCP server, DHCP client, Stateless DHCP. 191 2.2 RADIUS Terminology 193 The following terms are used in conjunction with RADIUS: 195 RADIUS server: A RADIUS server is responsible for receiving user 196 connection requests, authenticating the user, and then returning 197 all configuration information necessary for the client to deliver 198 service to the user. 200 Attribute: A Type-Length-Value tuple encapsulating data elements as 201 defined in RFC 2865 [6]. 203 NAS: A Network Access Server (NAS) provides access to the network and 204 operates as a client of RADIUS. The client is responsible for passing 205 user information to designated RADIUS servers, and then acting on the 206 response which is returned. 208 3. Relay Agent Information Option for DHCPv6 210 To support the capability of a PDSN as described in Section 1, we 211 introduce the DHCPv6 counterpart of the DHCPv4 Relay Agent 212 Information Option and the related RADIUS Attributes Sub-option as 213 defined in RFC3046 [12] and [13] respectively. In particular, this 214 document describes a new DHCPv6 option called the Relay Agent 215 Information option which extends the set of DHCPv6 options as defined 216 in RFC 3315 [3] and 3736 [4]. Following its DHCPv4 counterpart as 217 defined in RFC 3046, the new option is inserted by the DHCPv6 relay 218 agent when forwarding client-originated DHCPv6 packets to a DHCPv6 219 server. Servers recognizing the Relay Agent Information option may 220 use the information to implement IP address or other parameter 221 assignment policies. The DHCP Server echoes the option back verbatim 222 to the relay agent in server-to-client replies, and the relay agent 223 strips the option before forwarding the reply to the client. 225 The new DHCPv6 Option is called the Relay Agent Information Option. 226 It is a "container" option for specific agent supplied sub-options. 227 The format of the Relay Agent Information option follows that of the 228 DHCP Options as defined in Section 22.1 of RFC 3315 [3] as follows: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | OPTION_RELAY_INFO | option-len | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Agent Information Field | 236 | (variable no. of octets) | 237 . . 238 . . 239 . . 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 option-code OPTION_RELAY_INFO (TBD). This is the DHCP option 243 code for the Relay Agent Information Option 245 option-len An unsigned integer giving the length of the 246 Agent Information Field in octets. 248 Agent Information Field 249 This consists of a sequence of 250 SubOpt/Length/Value tuples for each sub-option, 251 encoded in the following manner: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |sub-option-code|sub-option-len | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 258 . sub-option-value field . 259 . (variable no. of octets) . 260 . . 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 sub-option-code An unsigned integer identifying the specific 264 sub-option type carried in this sub-option. 266 sub-option-len An unsigned integer giving the length the 267 sub-option value in octets. 269 sub-option-value field 270 This consists of a sequence of octets carrying 271 the sub-option value. 273 Since at least one sub-option must be defined, the minimum option-len 274 for the Relay Agent Information option length is two (2). The length 275 an sub-option shall be the number of octets in that sub-option's 276 value field. A sub-option length may be zero. The sub-options need 277 not appear in sub-option code order. 279 The initial assignment of DHCP Relay Agent Sub-options is as follows: 281 DHCP Agent Sub-Option Description 282 Sub-option Code 283 --------------- ---------------------- 284 SUBOPT_RADIUS (TBD) RADIUS-Attributes Sub-option 286 3.1 Relay Agent Operation 288 Overall adding of the DHCP relay agent option SHOULD be configurable, 289 and SHOULD be disabled by default. Relay agents SHOULD have separate 290 configurables for each sub-option to control whether it is added to 291 client-to-server packets. 293 The operation of relay agents for specific sub-options is specified 294 with that sub-option. 296 Relay agents are NOT required to monitor or modify client-originated 297 DHCP packets addressed to a server unicast address. 299 3.1.1 Relaying a Message from a Client 301 When a relay agent receives a valid DHCP message to be relayed from a 302 client, it constructs a new Relay-forward message per Section 20.1.1 303 of RFC 3315 [3] and then adds to the Relay-forward message the Relay 304 Agent Information Option if it is configured to do so. The relay 305 agent must be aware of the recommendations on packet sizes and the 306 use of fragmentation in Section 5 of RFC 2460 [8]. 308 3.1.2 Relaying a Message from a Relay Agent 310 When a relay agent receives a valid Relay-forward message from 311 another relay agent closer to the client, regardless of whether the 312 message already includes a Relay Agent Information option or not, the 313 relay agent shall construct a new Relay-forward message per Section 314 20.1.2 of RFC 3315 [3] and then add to this newly created Relay- 315 forward message the Relay Agent Information Option if it is 316 configured to do so. The relay agent must be aware of the 317 recommendations on packet sizes and the use of fragmentation in 318 Section 5 of RFC 2460 [8]. 320 3.1.3 Relaying a Replay-reply Message 322 The Relay Agent Information option echoed by a server MUST be removed 323 by the relay agent which added it when forwarding a server-to-client 324 response back to the client. 326 3.2 Server Operation 328 DHCP servers unaware of the Relay Agent Information option will 329 ignore the option upon receive and will not echo it back on 330 responses. This is the specified server behavior for unknown 331 options. 333 DHCP servers claiming to support the Relay Agent Information option 334 MUST discard the message and increment an error count if a Relay 335 Agent Information option was added by a DHCP client but not by a 336 relay agent. (This situation can be identified by the nesting of a 337 Relay Agent Information option inside the content of the Relay 338 Message option created by the first-hop relay agent.) We put the 339 responsibility of such checking to the DHCP server instead of the 340 relay agents in order to simplify the operations of the latter. 341 Furthermore, it is unreasonable to require a relay agent not 342 supporting/ understanding the Relay Agent Information option to 343 perform such checking. 345 DHCP servers claiming to support the Relay Agent Information option 346 MUST echo the entire contents of the Relay Agent Information option 347 in all of its relay-replies. The nesting of the echoed Relay-Agent 348 Information option(s) within the possibly nested relay-reply message 349 MUST be according to the nesting order of those options within the 350 original the Relay-forward message. DHCP servers must be aware of the 351 recommendations on packet sizes and the use of fragmentation in 352 Section 5 of RFC 2460 [8]. 354 The operation of DHCP servers for specific sub-options is specified 355 with that sub-option. 357 3.3 DHCP Client Behavior 359 Relay agent options are exchanged only between relay agents and DHCP 360 server, so DHCP clients are never aware of their use. 362 4. Relay Agent Information Sub-options 364 4.1 RADIUS Attributes sub-option 366 The RADIUS Attributes Sub-option is a sub-option for the DHCP 367 Relay Agent option. 369 The format of the RADIUS Attributes sub-option is: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | SUBOPT_RADIUS |sub-option-len | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 376 . RADIUS attributes . 377 . (variable no. of octets) . 378 . . 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 The RADIUS attributes are encoded as a sequence of octets according 382 to the encoding rules in RFC 2865 [6]. 384 4.1.1 DHCP Relay Agent Behavior for the RADIUS Attributes Sub-option 386 When the DHCP relay agent receives a DHCP message from the client, it 387 MAY append a DHCP Relay Agent Information option containing the 388 RADIUS Attributes sub-option, along with any other sub-options it is 389 configured to supply. The RADIUS Attributes sub-option MUST only 390 contain the attributes provided in the RADIUS Access/Accept message. 391 The DHCP relay agent MUST NOT add more than one RADIUS Attributes 392 sub-option in a message. 394 The relay agent MUST include the User-Name and IPv6 Framed-Pool 395 attributes in the RADIUS Attributes sub-option if available, and MAY 396 include other attributes. 398 In order to avoid dependencies between the address allocation and 399 other state information between the RADIUS server and the DHCP server, 400 the DHCP relay agent SHOULD include only the attributes in the table 401 below an instance of the RADIUS Attributes sub-option. The table 402 lists attributes that MAY be included: 404 # Attribute 405 --- --------- 406 1 User-Name (RFC 2865 [6]) 407 6 Service-Type (RFC 2865) 408 26 Vendor-Specific (RFC 2865) 409 27 Session-Timeout (RFC 2865) 410 100 Framed-IPv6-Pool (RFC 3162 [7]) 412 4.1.2 DHCP Server Behavior 414 When the DHCP server receives a message from a relay agent containing 415 a RADIUS Attributes sub-option, it extracts the contents of the sub- 416 option and uses that information in selecting configuration 417 parameters for the client. If the relay agent forwards RADIUS 418 attributes not included in the table in Section 4.1.1, the DHCP 419 server SHOULD ignore them. If the DHCP server uses attributes not 420 specified here, it might result in side effects not anticipated in 421 the existing RADIUS specifications. 423 5. Security Considerations 425 The DHCP Relay Agent Information option depends on a trusted 426 relationship between the DHCP relay agent and the server. If a client 427 message is relayed through multiple relay agents, each of the relay 428 agents must have established independent, pairwise trust 429 relationships. While the introduction of fraudulent relay-agent 430 options can be prevented by a perimeter defense that blocks these 431 options unless the relay agent is trusted, a deeper defense using, 432 e.g. IPsec [5] as described in Section 21.1 of RFC 3315 [3] SHOULD be 433 deployed as well. 435 There are several data in a DHCP message that convey information that 436 may identify an individual host on the network. Depending on the type 437 of data included, the Relay Agent Information option and its sub- 438 options may also convey information that identifies a specific host 439 or a specific user on the network. In practice, this information 440 isn't exposed outside the internal service-provider network, where 441 DHCP messages are usually confined. Administrators who configure data 442 that's going to be used the Relay Agent Information option and its 443 sub-options should be careful to use data that are appropriate for 444 the types of networks they administer. If DHCP messages travel 445 outside the service-provider's own network, or if the sub-option 446 values may become visible to other users, that may raise privacy 447 concerns for the access provider or service provider. 449 The RADIUS protocol [6] was designed for intra-domain use, where the 450 NAS, proxy, and home server exist within a single administrative 451 domain, and proxies may be considered a trusted component. However, 452 under roaming situation, the NAS, proxies, and home server will 453 typically be managed by different administrative entities. As a 454 result, inter-domain RADIUS operations are inherently required for 455 roaming applications, and proxies cannot necessarily be trusted. 456 Refer to Section 7 of RFC 2609 for a detailed security threat 457 analysis, limitations and precautions of operating RADIUS in a inter- 458 domain environment. In general, robust and secure operations of 459 RADIUS across multiple administrative domains require pre-established 460 agreement, mutual trust, and secure communications channel amongst 461 all the participating domains. 463 6. IANA Considerations 465 IANA is requested to assign a new option code, in the registry of DHCP 466 option codes, for the DHCP Relay Agent Information Option. 468 IANA is also requested to maintain a new number space of "DHCPv6 469 Relay Agent Information Option Sub-options". The initial sub-options 470 are described in Section 4 of this document. In particular, IANA is 471 requested to assign Sub-option number for RADIUS-Attributes Sub- 472 option. 474 IANA assigns future DHCP Relay Agent Information Option Sub-options 475 with a "IETF Consensus" policy as described in RFC 2434. Future 476 proposed sub-options are to be referenced symbolically in the 477 Internet-Drafts that describe them, and shall be assigned numeric 478 codes by IANA when approved for publication as an RFC. 480 7. Acknowledgments 482 Many thanks to M. Patrick, R. Droms, J. Schnizlein, M. Stapp, R. 483 Johnson and T. Palaniappan as this document is based on their work on 484 the DHCPv4 relay agent information option RFC3046 [12] and the 485 related sub-options [13,14]. The document follows closely the 486 original structure and borrows text from [12,13,14]. The 2nd author 487 would also like to thank P. Barany, T. Hardie, R. Hsu, M. Lioy, A.C. 488 Mahendran, R. Rezaiifar, S. Veerepalli and J. Wang for their helpful 489 discussions. 491 8. Intellectual Property Statement 493 The IETF takes no position regarding the validity or scope of any 494 intellectual property or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; neither does it represent that it 498 has made any effort to identify any such rights. Information on the 499 IETF's procedures with respect to rights in standards-track and 500 standards-related documentation can be found in BCP-11. Copies of 501 claims of rights made available for publication and any assurances of 502 licenses to be made available, or the result of an attempt made to 503 obtain a general license or permission for the use of such 504 proprietary rights by implementors or users of this specification can 505 be obtained from the IETF Secretariat. 507 The IETF invites any interested party to bring to its attention any 508 copyrights, patents or patent applications, or other proprietary 509 rights which may cover technology that may be required to practice 510 this document. Please address the information to the IETF Executive 511 Director. 513 9. Full copyright statement 515 Copyright (C) The Internet Society (2004). This document is subject 516 to the rights, licenses and restrictions contained in BCP 78 and 517 except as set forth therein, the authors retain all their rights. 518 This document and the information contained herein are provided on an 519 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 520 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 521 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 522 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 523 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 524 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 526 Authors' Addresses 528 Ralph Droms 529 Cisco Systems 530 1414 Massachusetts Avenue 531 Boxborough, MA 01719 532 U.S.A. 533 Email: rdroms@cisco.com 535 Wing Cheong Lau 536 Qualcomm 537 5775 Morehouse Drive 538 San Diego, CA 92121 539 U.S.A. 540 Phone: 858-651-5032 541 Email: lau@qualcomm.com 543 References 545 Normative References 547 [1]Bradner, S., "Intellectual Property Rights in IETF Technology", 548 BCP 79, RFC 3668, Feb. 2004. 550 [2]Bradner, S., "Key words for use in RFCs to Indicate Requirement 551 Levels", BCP 14, RFC 2119, March 1997. 553 [3]Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 554 (DHCPv6)", RFC 3315, July 2003. 556 [4]Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 557 Service for IPv6", RFC 3736, April 2004. 559 [5]Kent, S. and Atkinson R., "Security Architecture for the Internet 560 Protocol", RFC 2401, Nov. 1998. 562 [6]Rigney, C., Willens, S., Rubens, A. and Simpson, W., "Remote 563 Authentication Dial In User Service (RADIUS)", RFC 2865, June 564 2000. 566 [7]Aboba, B., Zorn, G. and Mitton, D., "RADIUS and IPv6", RFC 3162, 567 Aug. 2001. 569 [8]Deering, S and Hinden, R., "Internet Protocol Version 6 (IPv6) 570 Specification", RFC 2460, Dec. 1998. 572 Informative References 574 [9]3GPP2 X.S0011-002-D v.0.4, "cdma2000 Wireless IP Network 575 Standard:Simple IP and Mobile IP services," Work in progress. 577 [10]Johnson, D, Perkins, C. and Arkko, J., "Mobility Support in 578 IPv6", RFC 3775, June 2004. 580 [11]Rigney, C. "RADIUS Accounting", RFC 2866, June 2000. 582 [12]M.Patrick, "DHCP Relay Agent Information Option", RFC3046, Jan 583 2001. 585 [13]Droms, R., Schnizlein J., "RADIUS Attributes Sub-option for the 586 DHCP Relay Agent Information Option", draft-ietf-dhc-agentopt- 587 radius-08.txt, August 18, 2004. 589 [14]Stapp, M., Johnson, R., and Palaniappan, T., "Vendor-Specific 590 Information Sub-option for the DHCP Relay Agent Option", draft- 591 ietf-dhc-vendor-suboption-00.txt, Work-in-progress, Aug. 2004. 593 [15]Aboba B. and Vollbrecht J., "Proxy Chaining and Policy 594 Implementation in Roaming", RFC 2607, June 1999.