idnits 2.17.1 draft-ietf-softwire-map-radius-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 19, 2014) is 3410 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3580 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-12 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-11 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire S. Jiang 3 Internet-Draft Y. Fu 4 Intended status: Standards Track B. Liu 5 Expires: June 22, 2015 Huawei Technologies Co., Ltd 6 P. Deacon 7 IEA Software, Inc. 8 December 19, 2014 10 RADIUS Attribute for MAP 11 draft-ietf-softwire-map-radius-03 13 Abstract 15 Mapping of Address and Port (MAP) is a stateless mechanism for 16 running IPv4 over IPv6-only infrastructure. It provides both IPv4 17 and IPv6 connectivity services simultaneously during the IPv4/IPv6 18 co-existing period. The Dynamic Host Configuration Protocol for IPv6 19 (DHCPv6) MAP options has been defined to configure MAP Customer Edge 20 (CE). However, in many networks, the configuration information may 21 be stored in Authentication Authorization and Accounting (AAA) 22 servers while user configuration is mainly from Broadband Network 23 Gateway (BNG) through DHCPv6 protocol. This document defines a 24 Remote Authentication Dial In User Service (RADIUS) attribute that 25 carries MAP configuration information from AAA server to BNG. The 26 MAP RADIUS attribute are designed following the simplify principle. 27 It provides just enough information to form the correspondent DHCPv6 28 MAP option. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 22, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. MAP Configuration process with RADIUS . . . . . . . . . . . . 3 79 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.1. MAP-Configuration Attribute . . . . . . . . . . . . . . . 6 81 4.2. MAP Rule Options . . . . . . . . . . . . . . . . . . . . 6 82 4.3. Sub Options for MAP Rule Option . . . . . . . . . . . . . 7 83 4.3.1. Rule-IPv6-Prefix Sub Option . . . . . . . . . . . . . 7 84 4.3.2. Rule-IPv4-Prefix Sub Option . . . . . . . . . . . . . 8 85 4.3.3. EA Length Sub Option . . . . . . . . . . . . . . . . 9 86 4.3.4. BR-IPv6-Address Sub Option . . . . . . . . . . . . . 9 87 4.3.5. PSID Sub Option . . . . . . . . . . . . . . . . . . . 9 88 4.3.6. PSID Length Sub Option . . . . . . . . . . . . . . . 10 89 4.3.7. PSID Offset Sub Option . . . . . . . . . . . . . . . 10 90 4.4. Table of attributes . . . . . . . . . . . . . . . . . . . 11 91 5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 97 9.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 Recently providers start to deploy IPv6 and consider how to transit 103 to IPv6. Mapping of Address and Port (MAP)[I-D.ietf-softwire-map] is 104 a stateless mechanism for running IPv4 over IPv6-only infrastructure. 105 It provides both IPv4 and IPv6 connectivity services simultaneously 106 during the IPv4/IPv6 co-existing period. MAP has adopted Dynamic 107 Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] as auto- 108 configuring protocol. The MAP Customer Edge (CE) uses the DHCPv6 109 extension options [I-D.ietf-softwire-map-dhcp] to discover MAP Border 110 Relay (in tunnel model only) and to configure relevant MAP rules. 112 In many networks, user configuration information may be managed by 113 AAA (Authentication, Authorization, and Accounting) servers. Current 114 AAA servers communicate using the Remote Authentication Dial In User 115 Service (RADIUS) [RFC2865] protocol. In a fixed line broadband 116 network, the Broadband Network Gateways (BNGs) act as the access 117 gateway of users. The BNGs are assumed to embed a DHCPv6 server 118 function that allows them to locally handle any DHCPv6 requests 119 initiated by hosts. 121 Since the MAP configuration information is stored in AAA servers and 122 user configuration is mainly through DHCPv6 protocol between BNGs and 123 hosts/CEs, new RADIUS attributes are needed to propagate the 124 information from AAA servers to BNGs. The MAP RADIUS attributes 125 designed in this document are especially for the MAP encapsulation 126 mode, while providing enough information to form the correspondent 127 DHCPv6 MAP option [I-D.ietf-softwire-map-dhcp]. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 The terms MAP CE and MAP Border Relay are defined in 136 [I-D.ietf-softwire-map]. 138 3. MAP Configuration process with RADIUS 140 The below Figure 1 illustrates how the RADIUS protocol and DHCPv6 141 cooperate to provide MAP CE with MAP configuration information. 143 MAP CE BNG AAA Server 144 | | | 145 |------DHCPv6 Solicit----->| | 146 |(Option Request w/ MAP option) | 147 | |--Access-Request(MAP Attr)-->| 148 | | | 149 | |<--Access-Accept(MAP Attr)---| 150 |<---DHCPv6 Advertisement--| | 151 | | | 152 |------DHCPv6 Request---->| | 153 | (MAP Option) | | 154 |<---- -DHCPv6 Reply-------| | 155 | (MAP option) | | 156 | | | 157 DHCPv6 RADIUS 159 Figure 1: the cooperation between DHCPv6 and RADIUS combining with 160 RADIUS authentication 162 BNGs act as a RADIUS client and as a DHCPv6 server. First, the MAP 163 CE MAY initiate a DHCPv6 Solicit message that includes an Option 164 Request option (6) [RFC3315] with the MAP option 165 [I-D.ietf-softwire-map-dhcp] from the MAP CE. But note that the ORO 166 (Option Request option) with the MAP option could be optional if the 167 network was planned as MAP-enabled as default. When BNG receives the 168 SOLICIT, it SHOULD initiates radius Access-Request message, in which 169 the User-Name attribute (1) SHOULD be filled by the MAP CE MAC 170 address, to the RADIUS server and the User-password attribute (2) 171 SHOULD be filled by the shared MAP password that has been 172 preconfigured on the DHCPv6 server, requesting authentication as 173 defined in [RFC2865] with MAP-Configuration attribute, defined in the 174 next Section. If the authentication request is approved by the AAA 175 server, an Access-Accept message MUST be acknowledged with the IPv6- 176 MAP-Configuration Attribute. After receiving the Access-Accept 177 message with MAP-Configuration Attribute, the BNG SHOULD respond the 178 user an Advertisement message. Then the user can requests for a MAP 179 Option, the BNG SHOULD reply the user with the message containing the 180 MAP option. The recommended format of the MAC address is as defined 181 in Calling-Station-Id (Section 3.20 in [RFC3580] without the SSID 182 (Service Set Identifier) portion. 184 Figure 2 describes another scenario, in which the authorization 185 operation is not coupled with authentication. Authorization relevant 186 to MAP is done independently after the authentication process. As 187 similar to above scenario, the ORO with the MAP option in the initial 188 DHCPv6 request could be optional if the network was planned as MAP- 189 enabled as default. 191 MAP CE BNG AAA Server 192 | | | 193 |------DHCPv6 Request---->| | 194 |(Option Request w/ MAP option) | 195 | |--Access-Request(MAP Attr)-->| 196 | | | 197 | |<--Access-Accept(MAP Attr)---| 198 | | | 199 |<-----DHCPv6 Reply--------| | 200 | (MAP option) | | 201 | | | 202 DHCPv6 RADIUS 204 Figure 2: the cooperation between DHCPv6 and RADIUS decoupled with 205 RADIUS authentication 207 In the abovementioned scenario, the Access-Request packet SHOULD 208 contain a Service-Type attribute (6) with the value Authorize Only 209 (17); thus, according to [RFC5080], the Access-Request packet MUST 210 contain a State attribute that obtained from the previous 211 authentication process. 213 In both above-mentioned scenarios, Message-authenticator (type 80) 214 [RFC2869] SHOULD be used to protect both Access-Request and Access- 215 Accept messages. 217 After receiving the MAP-Configuration Attribute in the initial 218 Access-Accept, the BNG SHOULD store the received MAP configuration 219 parameters locally. When the MAP CE sends a DHCPv6 Request message 220 to request an extension of the lifetimes for the assigned address, 221 the BNG does not have to initiate a new Access-Request towards the 222 AAA server to request the MAP configuration parameters. The BNG 223 could retrieve the previously stored MAP configuration parameters and 224 use them in its reply. 226 If the BNG does not receive the MAP-Configuration Attribute in the 227 Access-Accept it MAY fallback to a pre-configured default MAP 228 configuration, if any. If the BNG does not have any pre-configured 229 default MAP configuration or if the BNG receives an Access-Reject, 230 the tunnel cannot be established. 232 As specified in [RFC3315], section 18.1.4, "Creation and Transmission 233 of Rebind Messages ", if the DHCPv6 server to which the DHCPv6 Renew 234 message was sent at time T1 has not responded by time T2, the MAP CE 235 (DHCPv6 client) SHOULD enters the Rebind state and attempt to contact 236 any available server. In this situation, the secondary BNG receiving 237 the DHCPv6 message MUST initiate a new Access-Request towards the AAA 238 server. The secondary BNG MAY include the MAP-Configuration 239 Attribute in its Access-Request. 241 4. Attributes 243 This section defines MAP-Rule Attribute which is used in the MAP 244 scenario. The attribute design follows [RFC6158] and referring 245 to[RFC6929]. 247 The MAP RADIUS attribute are designed following the simplify 248 principle. The sub options are organized into two categories: the 249 necessary and the optional. 251 4.1. MAP-Configuration Attribute 253 The MAP-Configuration Attribute is structured as follows: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 260 | | 261 + MAP Rule Option(s) + 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Type 265 TBD 266 Length 267 2 + the length of the Rule option(s) 268 MAP Rule Option (s) 269 A variable field that may contains one or more Rule option(s), 270 defined in Section 4.2. 272 4.2. MAP Rule Options 274 Depending on deployment scenario, one Default Mapping rule and zero 275 or more other type Mapping Rules MUST be included in one MAP- 276 Configuration Attribute. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 283 | | 284 + Sub Options + 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type 288 1 Basic Mapping Rule (Not Forwarding Mapping Rule) 289 2 Forwarding Mapping Rule (Not Basic Mapping Rule) 290 3 Default Mapping Rule 291 4 Basic & Forwarding Mapping Rule 292 Length 293 2 + the length of the sub options 294 Sub Option 295 A variable field that contains necessary sub options defined in 296 Section 4.3 and zero or several optional sub options, defined 297 in Section 4.4. 299 4.3. Sub Options for MAP Rule Option 301 4.3.1. Rule-IPv6-Prefix Sub Option 303 The Rule-IPv6-Prefix Sub Option is necessary for every MAP Rule 304 option. It should appear for once and only once. 306 The IPv6 Prefix sub option is followed the framed IPv6 prefix 307 designed in [RFC3162]. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | SubType | SubLen | Reserved | prefix6-len | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 | rule-ipv6-prefix | 316 | | 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 SubType 320 1 (SubType number, for the Rule-IPv6-Prefix6 sub option) 321 SubLen 322 20 (the length of the Rule-IPv6-Prefix6 sub option) 323 Reserved 324 Reserved for future usage. It should be set to all zero. 325 prefix6-len 326 length of the IPv6 prefix, specified in the rule-ipv6-prefix 327 field, expressed in bits 328 rule-ipv6-prefix 329 a 128-bits field that specifies an IPv6 prefix that appears in 330 a MAP rule 332 4.3.2. Rule-IPv4-Prefix Sub Option 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 | prefix4-len | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | rule-ipv4-prefix | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 SubType 343 2 (SubType number, for the Rule-IPv4-Prefix6 sub option) 344 SubLen 345 8 (the length of the Rule-IPv4-Prefix6 sub option) 346 Reserved 347 Reserved for future usage. It should be set to all zero. 348 Prefix4-len 349 length of the IPv6 prefix, specified in the rule-ipv6-prefix 350 field, expressed in bits 351 rule-ipv4-prefix 352 a 32-bits field that specifies an IPv4 prefix that appears in 353 a MAP rule 355 4.3.3. EA Length Sub Option 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | SubType | SubLen | EA-len | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 SubType 364 3 (SubType number, for the EA Length sub option) 365 SubLen 366 4 (the length of the EA Length sub option) 367 EA-len 368 16 bits long field that specifies the Embedded-Address (EA) 369 bit length. Allowed values range from 0 to 48. 371 4.3.4. BR-IPv6-Address Sub Option 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | SubType | SubLen | BR-ipv6-address 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 BR-ipv6-address 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 BR-ipv6-address 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 BR-ipv6-address 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 BR-ipv6-address | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 SubType 387 4 (SubType number, for the BR-ipv6-address sub option) 388 SubLen 389 20 (the length of the BR-ipv6-address sub option) 390 BR-ipv6-address 391 a 128-bits field that specifies the IPv6 address for the BR. 393 4.3.5. PSID Sub Option 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | SubType | SubLen | PSID | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 SubType 401 5 (SubType number, for the PSID Sub Option sub option) 402 SubLen 403 4 (the length of the PSID Sub Option sub option) 404 PSID (Port-set ID) 405 Explicit 16-bit (unsigned word) PSID value. The PSID value 406 algorithmically identifies a set of ports assigned to a CE. The 407 first k-bits on the left of this 2-octets field is the PSID 408 value. The remaining (16-k) bits on the right are padding zeros. 410 4.3.6. PSID Length Sub Option 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | SubType | SubLen | PSID-len | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 SubType 419 6 (SubType number, for the PSID Length sub option) 420 SubLen 421 4 (the length of the PSID Length sub option) 422 PSID-len 423 Bit length value of the number of significant bits in the PSID 424 field. (also known as 'k'). When set to 0, the PSID field is to 425 be ignored. After the first 'a' bits, there are k bits in the 426 port number representing valid of PSID. Subsequently, the 427 address sharing ratio would be 2 ^k. 429 4.3.7. PSID Offset Sub Option 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | SubType | SubLen | PSID Offset | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 SubType 437 7 (SubType number, for the PSID Offset sub option) 438 SubLen 439 4 (the length of the PSID Offset sub option) 440 PSID Offset 441 4 bits long field that specifies the numeric value for the MAP 442 algorithm's excluded port range/offset bits (A-bits), as per 443 section 5.1.1 in [I-D.ietf-softwire-map]. Default must be set 444 to 4. 446 4.4. Table of attributes 448 The following table provides a guide to which attributes may be found 449 in which kinds of packets, and in what quantity. 451 Request Accept Reject Challenge Accounting # Attribute 452 Request 453 0-1 0-1 0 0 0-1 TBD1 MAP- 454 Configuration 455 0-1 0-1 0 0 0-1 1 User-Name 456 0-1 0 0 0 0 2 User-Password 457 0-1 0-1 0 0 0-1 6 Service-Type 458 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator 460 The following table defines the meaning of the above table entries. 462 0 This attribute MUST NOT be present in packet. 463 0+ Zero or more instances of this attribute MAY be present in 464 packet. 465 0-1 Zero or one instance of this attribute MAY be present in 466 packet. 467 1 Exactly one instance of this attribute MUST be present in 468 packet. 470 5. Diameter Considerations 472 This attribute is usable within either RADIUS or Diameter [RFC6733]. 473 Since the Attributes defined in this document will be allocated from 474 the standard RADIUS type space, no special handling is required by 475 Diameter entities. 477 6. IANA Considerations 479 This document requires the assignment of two new RADIUS Attributes 480 Types in the "Radius Types" registry (currently located at 481 http://www.iana.org/assignments/radius-types for the following 482 attributes: 484 o MAP-Configuration TBD1 486 IANA should allocate the numbers from the standard RADIUS Attributes 487 space using the "IETF Review" policy [RFC5226]. 489 7. Security Considerations 491 In MAP scenarios, both CE and BNG are within a provider network, 492 which can be considered as a closed network and a lower security 493 threat environment. A similar consideration can be applied to the 494 RADIUS message exchange between BNG and the AAA server. 496 Known security vulnerabilities of the RADIUS protocol are discussed 497 in [RFC2607], [RFC2865], and[RFC2869]. Use of IPsec [RFC4301] for 498 providing security when RADIUS is carried in IPv6 is discussed in 499 [RFC3162]. 501 A malicious user may use MAC address proofing and/or dictionary 502 attack on the shared MAP password that has been preconfigured on the 503 DHCPv6 server to get unauthorized MAP configuration information. 505 Security considerations for MAP specific between MAP CE and BNG are 506 discussed in [I-D.ietf-softwire-map]. Furthermore, generic DHCPv6 507 security mechanisms can be applied DHCPv6 intercommunication between 508 MAP CE and BNG. 510 Security considerations for the Diameter protocol are discussed in 511 [RFC6733]. 513 8. Acknowledgements 515 The authors would like to thank the valuable comments made by Peter 516 Lothberg, Wojciech Dec, and Suresh Krishnan for this document. 518 This document was produced using the xml2rfc tool [RFC2629]. 520 9. References 521 9.1. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 527 "Remote Authentication Dial In User Service (RADIUS)", RFC 528 2865, June 2000. 530 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 531 3162, August 2001. 533 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 534 and M. Carney, "Dynamic Host Configuration Protocol for 535 IPv6 (DHCPv6)", RFC 3315, July 2003. 537 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 538 "IEEE 802.1X Remote Authentication Dial In User Service 539 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 541 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 542 Dial In User Service (RADIUS) Implementation Issues and 543 Suggested Fixes", RFC 5080, December 2007. 545 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 546 158, RFC 6158, March 2011. 548 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 549 Service (RADIUS) Protocol Extensions", RFC 6929, April 550 2013. 552 9.2. Informative References 554 [I-D.ietf-softwire-map] 555 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 556 Murakami, T., and T. Taylor, "Mapping of Address and Port 557 with Encapsulation (MAP)", draft-ietf-softwire-map-12 558 (work in progress), November 2014. 560 [I-D.ietf-softwire-map-dhcp] 561 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 562 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 563 configuration of Softwire Address and Port Mapped 564 Clients", draft-ietf-softwire-map-dhcp-11 (work in 565 progress), November 2014. 567 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 568 Implementation in Roaming", RFC 2607, June 1999. 570 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 571 June 1999. 573 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 574 Extensions", RFC 2869, June 2000. 576 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 577 Internet Protocol", RFC 4301, December 2005. 579 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 580 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 581 May 2008. 583 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 584 "Diameter Base Protocol", RFC 6733, October 2012. 586 Authors' Addresses 588 Sheng Jiang 589 Huawei Technologies Co., Ltd 590 Q14, Huawei Campus, No.156 Beiqing Road 591 Hai-Dian District, Beijing, 100095 592 P.R. China 594 Email: jiangsheng@huawei.com 596 Yu Fu 597 Huawei Technologies Co., Ltd 598 Q14, Huawei Campus, No.156 Beiqing Road 599 Hai-Dian District, Beijing, 100095 600 P.R. China 602 Email: eleven.fuyu@huawei.com 604 Bing Liu 605 Huawei Technologies Co., Ltd 606 Q14, Huawei Campus, No.156 Beiqing Road 607 Hai-Dian District, Beijing, 100095 608 P.R. China 610 Email: leo.liubing@huawei.com 611 Peter Deacon 612 IEA Software, Inc. 613 P.O. Box 1170 614 Veradale, WA 99037 615 USA 617 Email: peterd@iea-software.com