idnits 2.17.00 (12 Aug 2021) /tmp/idnits13251/draft-jiang-softwire-4rd-radius-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3580' is mentioned on line 161, but not defined == Missing Reference: 'RFC4301' is mentioned on line 489, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-softwire-4rd has been published as RFC 7600 ** Downref: Normative reference to an Experimental draft: draft-ietf-softwire-4rd (ref. 'I-D.ietf-softwire-4rd') Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sheng Jiang (Editor) 2 Internet Draft Yu Fu 3 Intended status: Standards Track Bing Liu 4 Expires: August 18, 2014 Huawei Technologies Co., Ltd 5 February 14, 2014 7 RADIUS Attribute for 4rd 9 draft-jiang-softwire-4rd-radius-04.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 18, 2014. 28 Copyright Notice 30 Copyright (c) 2014 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 IPv4 Residual Deployment via IPv6 (4rd) is a stateless mechanism for 46 running IPv4 over IPv6-only infrastructure. It provides both IPv4 and 47 IPv6 connectivity services simultaneously during the IPv4/IPv6 co- 48 existing period. The Dynamic Host Configuration Protocol for IPv6 49 (DHCPv6) 4rd options has been defined to configure 4rd Customer Edge 50 (CE). However, in many networks, the configuration information may be 51 stored in Authentication Authorization and Accounting (AAA) servers 52 while user configuration is mainly from Broadband Network Gateway 53 (BNG) through DHCPv6 protocol. This document defines a Remote 54 Authentication Dial In User Service (RADIUS) attribute that carries 55 4rd configuration information from AAA server to BNG. The 4rd RADIUS 56 attribute are designed following the simplify principle. It provides 57 just enough information to form the correspondent DHCPv6 4rd option. 59 Table of Contents 61 1. Introduction ................................................. 3 62 2. Terminology .................................................. 3 63 3. 4rd Configuration process with RADIUS ........................ 3 64 4. Attributes ................................................... 6 65 4.1. 4rd-Configuration Attribute ............................. 6 66 4.2. 4rd Non-mapping-rule Parameter option ................... 7 67 4.3. 4rd Rule Options ........................................ 7 68 4.4. 4rd Rule Sub Options .................................... 8 69 4.4.1. Rule-IPv6-Prefix Sub Option ........................ 8 70 4.4.2. Rule-IPv6-Suffix Sub Option ........................ 9 71 4.4.3. Rule-IPv4-Prefix Sub Option ....................... 10 72 4.4.4. Misc Sub Option ................................... 11 73 4.5. Table of attributes .................................... 11 74 5. Diameter Considerations ..................................... 12 75 6. Security Considerations ..................................... 12 76 7. IANA Considerations ......................................... 12 77 8. Acknowledgments ............................................. 13 78 9. References .................................................. 13 79 9.1. Normative References ................................... 13 80 9.2. Informative References ................................. 13 82 1. Introduction 84 Recently providers start to deploy IPv6 and consider how to transit 85 to IPv6. IPv4 Residual Deployment via IPv6 (4rd) 86 [I-D.ietf-softwire-4rd] is a stateless mechanism for running IPv4 87 over IPv6-only infrastructure. It provides both IPv4 and IPv6 88 connectivity services simultaneously during the IPv4/IPv6 co-existing 89 period. 4rd has adopted Dynamic Host Configuration Protocol for IPv6 90 (DHCPv6) [RFC3315] as auto-configuring protocol. The 4rd Customer 91 Edge (CE) uses the DHCPv6 extension options 92 [I-D.ietf-softwire-4rd] to discover 4rd Border Relay and to configure 93 relevant 4rd rules. 95 In many networks, user configuration information may be managed by 96 AAA (Authentication, Authorization, and Accounting) servers. Current 97 AAA servers communicate using the Remote Authentication Dial In User 98 Service (RADIUS) [RFC2865] protocol. In a fixed line broadband 99 network, the Broadband Network Gateways (BNGs) act as the access 100 gateway of users. The BNGs are assumed to embed a DHCPv6 server 101 function that allows them to locally handle any DHCPv6 requests 102 issued by hosts. 104 Since the 4rd configuration information is stored in AAA servers and 105 user configuration is mainly through DHCPv6 protocol between BNGs and 106 hosts/CEs, new RADIUS attributes are needed to propagate the 107 information from AAA servers to BNGs. The 4rd RADIUS attribute are 108 designed following the simplify principle, while providing enough 109 information to form the correspondent DHCPv6 4rd option. 110 [I-D.ietf-softwire-4rd]. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC2119 [RFC2119]. 118 The terms 4rd CE and 4rd Border Relay are defined in 119 [I-D.ietf-softwire-4rd]. 121 3. 4rd Configuration process with RADIUS 123 The below Figure 1 illustrates how the RADIUS protocol and DHCPv6 124 cooperate to provide 4rd CE with 4rd configuration information. 126 4rd CE BNG AAA Server 127 | | | 128 |------DHCPv6 Solicit----->| | 129 |(Option Request w/ 4rd option) | 130 | |--Access-Request(4rd Attr)-->| 131 | | | 132 | |<--Access-Accept(4rd Attr)---| 133 |<---DHCPv6 Advertisement--| | 134 | | | 135 |------DHCPv6 Request---->| | 136 | (4rd Option) | | 137 |<---- -DHCPv6 Reply-------| | 138 | (4rd option) | | 139 | | | 140 DHCPv6 RADIUS 141 Figure 1: the cooperation between DHCPv6 and RADIUS 142 combining with RADIUS authentication 144 BNGs act as a client of RADIUS and as a DHCPv6 server. First, the 145 4rd CE MAY initiate a DHCPv6 Solicit message that includes an Option 146 Request option (6) [RFC3315] with the 4rd option 147 [draft-ietf-softwire-4rd] from the 4rd CE. When BNG receives the 148 SOLICIT, it SHOULD initiate an RADIUS Access-Request message, in 149 which the User-Name attribute (1) SHOULD be filled by the 4rd CE MAC 150 address, to the RADIUS server and the User-password attribute (2) 151 SHOULD be filled by the shared 4rd password that has been 152 preconfigured on the DHCPv6 server, requesting authentication as 153 defined in [RFC2865] with 4rd-Configuration attribute, defined in the 154 next Section. If the authentication request is approved by the AAA 155 server, an Access-Accept message MUST contain the 4rd-Configuration 156 Attribute. After receiving the Access-Accept message with 4rd- 157 Configuration Attribute, the BNG SHOULD respond to the user with an 158 Advertisement message. Then the user can request a 4rd Option, the 159 BNG SHOULD reply the user with a message containing the 4rd option. 160 The recommended format of the MAC address is as defined in Calling- 161 Station-Id (Section 3.20 in [RFC3580]) without the SSID (Service Set 162 Identifier) portion. 164 Figure 2 describes another scenario, in which the authorization 165 operation is not coupled with authentication. Authorization relevant 166 to 4RD is done independently after the authentication process. 168 4rd CE BNG AAA Server 169 | | | 170 |------DHCPv6 Request---->| | 171 |(Option Request w/ 4rd option) | 172 | |--Access-Request(4rd Attr)-->| 173 | | | 174 | |<--Access-Accept(4rd Attr)---| 175 | | | 176 |<------DHCPv6 Reply-------| | 177 | (4rd option) | | 178 | | | 179 DHCPv6 RADIUS 180 Figure 2: the cooperation between DHCPv6 and RADIUS 181 decoupled with RADIUS authentication 183 In the abovementioned scenario, the Access-Request packet SHOULD 184 contain a Service-Type attribute (6) with the value Authorize Only 185 (17); thus, according to [RFC5080], the Access-Request packet MUST 186 contain a State attribute that obtained from the previous 187 authentication process. 189 In both above-mentioned scenarios, Message-authenticator (type 80) 190 [RFC2869] SHOULD be used to protect both Access-Request and Access- 191 Accept messages. 193 After receiving the 4rd-Configuration Attribute in the initial 194 Access-Accept, the BNG SHOULD store the received 4rd configuration 195 parameters locally. When the 4rd CE sends a DHCPv6 Request message to 196 request an extension of the lifetimes for the assigned address, the 197 BNG does not have to initiate a new Access-Request towards the AAA 198 server to request the 4rd configuration parameters. The BNG could 199 retrieves the previously stored 4rd configuration parameters and use 200 them in its reply. 202 If the BNG does not receive the 4rd-Configuration Attribute in the 203 Access-Accept it MAY fallback to a pre-configured default 4rd 204 configuration, if any. If the BNG does not have any pre-configured 205 default 4rd configuration or if the BNG receives an Access-Reject, 206 the tunnel cannot be established. 208 As specified in [RFC3315], section 18.1.4, "Creation and Transmission 209 of Rebind Messages ", if the DHCPv6 server to which the DHCPv6 Renew 210 message was sent at time T1 has not responded by time T2, the 4rd CE 211 (DHCPv6 client) enters the Rebind state and attempts to contact any 212 available server. In this situation the secondary BNG receiving the 213 DHCPv6 message MUST initiate a new Access-Request towards the AAA 214 server. The secondary BNG MAY include the 4rd-Configuration Attribute 215 in its Access-Request. 217 4. Attributes 219 This section defines 4rd-Configuration Attribute which is used in the 220 4rd scenario. The attribute design follows [RFC6158]. 222 The 4rd RADIUS attribute are designed following the simplify 223 principle. The sub options are organized into two categories: the 224 necessary and the optional. 226 4.1. 4rd-Configuration Attribute 228 The 4rd-Configuration Attribute is structured 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 | Type | Length | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 235 | | 236 + 4rd Option(s) + 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type 242 TBD 244 Length 246 6 + the length of the Rule option(s) 248 Sub Option 250 a variable field that may contains a 4rd non-mapping-rule 251 parameter option andone or more Rule option(s), defined in 252 Section 4.2 and 4.3. 254 4.2. 4rd Non-mapping-rule Parameter option 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | option-code = OPTION_4RD | option-length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |H| 0 |T| traffic-class | domain-pmtu | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type 266 1 268 Length 270 4 272 H bit 274 Hub&spoke topology (= 1 if Yes) 276 T bit 278 Traffic-class flag (= 1 if a Tunnel traffic class is provided) 280 traffic-class 282 Tunnel-traffic class 284 domain-pmtu 286 Domain PMTU (at least 1280) 288 4.3. 4rd Rule Options 290 Depending on deployment scenario, at least one BR Mapping Rule one 291 and one or more CE Mapping Rules MUST be included in one 4rd- 292 Configuration Attribute. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 299 | | 300 + Sub Options + 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Type 306 2 BR Mapping Rule 308 3 CE Mapping Rule 310 Length 312 2 + the length of the sub options 314 Sub Option 316 a variable field that contains necessary sub options defined in 317 Section 4.3 and zero or several optional sub options, defined 318 in Section 4.4. 320 4.4. 4rd Rule Sub Options 322 Rule-IPv6-Prefix Sub Option and Rule-IPv4-Prefix Sub Option are 323 necessary for every 4rd Rule option. They should appear for once and 324 only once. Different from [I-D.ietf-softwire-4rd], EA-Len, Embedded- 325 Address (EA) length, is not present at all, because it can be 326 calculated by the combine of prefix4len, prefix6-len, excluded ports 327 and off bits. 329 4.4.1. Rule-IPv6-Prefix Sub Option 331 The IPv6 Prefix sub option is follow the framed IPv6 prefix designed 332 in [RFC3162]. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | SubType | SubLen | Reserved | prefix6-len | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 | rule-ipv6-prefix | 341 | | 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 SubType 347 0 (SubType number, for the Rule-IPv6-Prefix6 sub option) 349 SubLen 351 20 (the length of the Rule-IPv6-Prefix6 sub option) 353 Reserved 355 Reserved for future usage. It should be set to all zero. 357 prefix6-len 359 length of the IPv6 prefix, specified in the rule-ipv6-prefix 360 field, expressed in bits 362 rule-ipv6-prefix 364 a 128-bits field that specifies an IPv6 prefix that appears in 365 a 4rd rule 367 4.4.2. Rule-IPv6-Suffix Sub Option 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | SubType | SubLen | suffix6-len | ipv6-suffix | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 SubType 377 1 (SubType number, for the Rule-IPv6-Suffix6 sub option) 379 SubLen 380 4 (the length of the Rule-IPv6-Suffix6 sub option) 382 prefix6-len 384 length of the IPv6 suffix, specified in the rule-ipv6-suffix 385 field, expressed in bits. In attendance, the value should be 386 1~4 only. 388 rule-ipv6-suffix 390 a 8-bits field that specifies an IPv6 suffix that appears in 391 a 4rd rule 393 4.4.3. Rule-IPv4-Prefix Sub Option 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | SubType | SubLen | Reserved | prefix4-len | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | rule-ipv4-prefix | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 SubType 405 2 (SubType number, for the Rule-IPv4-Prefix6 sub option) 407 SubLen 409 8 (the length of the Rule-IPv4-Prefix6 sub option) 411 Reserved 413 Reserved for future usage. It should be set to all zero. 415 Prefix4-len 417 length of the IPv6 prefix, specified in the rule-ipv6-prefix 418 field, expressed in bits 420 rule-ipv4-prefix 422 a 32-bits field that specifies an IPv4 prefix that appears in 423 a 4rd rule 425 4.4.4. Misc Sub Option 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | SubType | SubLen | Reserved |W| 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 SubType 434 3 (SubType number, for the Rule-IPv4-Prefix6 sub option) 436 SubLen 438 1 (the length of the Rule-IPv4-Prefix6 sub option) 440 Reserved 442 Reserved for future usage. It should be set to all zero. 444 W bit 446 WKP authorized, = 1 if set 448 4.5. Table of attributes 450 The following table provides a guide to which attributes may be found 451 in which kinds of packets, and in what quantity. 453 Request Accept Reject Challenge Accounting # Attribute 454 Request 455 0-1 0-1 0 0 0-1 TBD1 4rd- 456 Configuration 457 0-1 0-1 0 0 0-1 1 User-Name 458 0-1 0 0 0 0-1 2 User-Password 459 0-1 0-1 0 0 0-1 6 Service-Type 460 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator 462 The following table defines the meaning of the above table entries. 464 0 This attribute MUST NOT be present in packet. 465 0+ Zero or more instances of this attribute MAY be present in 466 packet. 467 0-1 Zero or one instance of this attribute MAY be present in 468 packet. 470 1 Exactly one instance of this attribute MUST be present in 471 packet. 473 5. Diameter Considerations 475 This attribute is usable within either RADIUS or Diameter [RFC6733]. 476 Since the Attributes defined in this document will be allocated from 477 the standard RADIUS type space, no special handling is required by 478 Diameter entities. 480 6. Security Considerations 482 In 6rd scenarios, both CE and BNG are within a provider network, 483 which can be considered as a closed network and a lower security 484 threat environment. A similar consideration can be applied to the 485 RADIUS message exchange between BNG and the AAA server. 487 Known security vulnerabilities of the RADIUS protocol are discussed 488 in RFC 2607 [RFC2607], RFC 2865 [RFC2865], and RFC 2869 [RFC2869]. 489 Use of IPsec [RFC4301] for providing security when RADIUS is carried 490 in IPv6 is discussed in RFC 3162 [RFC3162]. 492 A malicious user may use MAC address spoofing and/or dictionary 493 attack on the shared 4rd password that has been preconfigured on the 494 DHCPv6 server to get unauthorized 4rd configuration information. 496 Security considerations for 4RD specific between 4RD CE and BNG are 497 discussed in [I-D.ietf-softwire-4rd]. Furthermore, generic DHCPv6 498 security mechanisms can be applied DHCPv6 intercommunication between 499 4RD CE and BNG. 501 Security considerations for the Diameter protocol are discussed in 502 [RFC6733]. 504 7. IANA Considerations 506 This document requires the assignment of two new RADIUS Attributes 507 Types in the "Radius Types" registry (currently located at 508 http://www.iana.org/assignments/radius-types for the following 509 attributes: 511 o 4rd-Configuration TBD1 513 IANA should allocate the numbers from the standard RADIUS Attributes 514 space using the "IETF Review" policy [RFC5226]. 516 8. Acknowledgments 518 The authors would like to thank for valuable comments. 520 9. References 522 9.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 528 "Remote Authentication Dial In User Service (RADIUS)", RFC 529 2865, June 2000. 531 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 532 3162, August 2001. 534 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 535 M. Carney, "Dynamic Host Configuration Protocol for IPv6 536 (DHCPv6)", RFC 3315, July 2003. 538 [RFC4301]Kent, S. and K. Seo, "Security Architecture for the 539 Internet Protocol", RFC 4301, December 2005. 541 [RFC5080] Nelson, D. and DeKok A., "Common Remote Authentication Dial 542 In User Service (RADIUS) Implementation Issues and 543 Suggested Fixes", RFC 5080, December 2007. 545 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 546 IANA Considerations Section in RFCs", RFC 5226, May 2008. 548 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", RFC 549 6158, March 2011. 551 [RFC6733] V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed., 552 "Diameter Base Protocol", RFC 6733, October 2012. 554 [I-D.ietf-softwire-4rd] 555 R. Despres, et al., "IPv4 Residual Deployment via IPv6 - a 556 unified Stateless Solution (4rd)", draft-ietf-softwire-4rd, 557 working in progress. 559 9.2. Informative References 561 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 562 Implementation in Roaming", RFC 2607, June 1999. 564 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 565 Extensions", RFC 2869, June 2000. 567 Author's Addresses 569 Sheng Jiang (Editor) 570 Huawei Technologies Co., Ltd 571 Q14 Huawei Campus, 156 BeiQi Road, 572 ZhongGuan Cun, Hai-Dian District, Beijing 100085 573 P.R. China 574 EMail: jiangsheng@huawei.com 576 Yu Fu 577 Huawei Technologies Co., Ltd 578 Q14 Huawei Campus, 156 BeiQi Road, 579 ZhongGuan Cun, Hai-Dian District, Beijing 100085 580 P.R. China 581 EMail: eleven.fuyu@huawei.com 583 Bing Liu 584 Huawei Technologies Co., Ltd 585 Q14 Huawei Campus, 156 BeiQi Road, 586 ZhongGuan Cun, Hai-Dian District, Beijing 100085 587 P.R. China 588 EMail: leo.liubing@huawei.com