idnits 2.17.1 draft-ietf-softwire-map-radius-02.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 (June 19, 2014) is 3599 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-10 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-07 -- 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: December 21, 2014 Huawei Technologies Co., Ltd 6 P. Deacon 7 IEA Software, Inc. 8 June 19, 2014 10 RADIUS Attribute for MAP 11 draft-ietf-softwire-map-radius-02 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 December 21, 2014. 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 | Reserved | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | | 379 | BR-ipv6-address | 380 | | 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 SubType 384 4 (SubType number, for the BR-ipv6-address sub option) 385 SubLen 386 20 (the length of the BR-ipv6-address sub option) 387 Reserved 388 Reserved for future usage. It should be set to all zero. 389 BR-ipv6-address 390 a 128-bits field that specifies the IPv6 address for the BR. 392 4.3.5. PSID Sub Option 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | SubType | SubLen | PSID | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 SubType 400 5 (SubType number, for the PSID Sub Option sub option) 401 SubLen 402 4 (the length of the PSID Sub Option sub option) 403 PSID (Port-set ID) 404 Explicit 16-bit (unsigned word) PSID value. The PSID value 405 algorithmically identifies a set of ports assigned to a CE. The 406 first k-bits on the left of this 2-octets field is the PSID 407 value. The remaining (16-k) bits on the right are padding zeros. 409 4.3.6. PSID Length Sub Option 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | SubType | SubLen | PSID-len | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 SubType 418 6 (SubType number, for the PSID Length sub option) 419 SubLen 420 4 (the length of the PSID Length sub option) 421 PSID-len 422 Bit length value of the number of significant bits in the PSID 423 field. (also known as 'k'). When set to 0, the PSID field is to 424 be ignored. After the first 'a' bits, there are k bits in the 425 port number representing valid of PSID. Subsequently, the 426 address sharing ratio would be 2 ^k. 428 4.3.7. PSID Offset Sub Option 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | SubType | SubLen | PSID Offset | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 SubType 436 7 (SubType number, for the PSID Offset sub option) 437 SubLen 438 4 (the length of the PSID Offset sub option) 439 PSID Offset 440 4 bits long field that specifies the numeric value for the MAP 441 algorithm's excluded port range/offset bits (A-bits), as per 442 section 5.1.1 in [I-D.ietf-softwire-map]. Default must be set 443 to 4. 445 4.4. Table of attributes 447 The following table provides a guide to which attributes may be found 448 in which kinds of packets, and in what quantity. 450 Request Accept Reject Challenge Accounting # Attribute 451 Request 452 0-1 0-1 0 0 0-1 TBD1 MAP- 453 Configuration 454 0-1 0-1 0 0 0-1 1 User-Name 455 0-1 0 0 0 0 2 User-Password 456 0-1 0-1 0 0 0-1 6 Service-Type 457 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator 459 The following table defines the meaning of the above table entries. 461 0 This attribute MUST NOT be present in packet. 462 0+ Zero or more instances of this attribute MAY be present in 463 packet. 464 0-1 Zero or one instance of this attribute MAY be present in 465 packet. 466 1 Exactly one instance of this attribute MUST be present in 467 packet. 469 5. Diameter Considerations 471 This attribute is usable within either RADIUS or Diameter [RFC6733]. 472 Since the Attributes defined in this document will be allocated from 473 the standard RADIUS type space, no special handling is required by 474 Diameter entities. 476 6. IANA Considerations 478 This document requires the assignment of two new RADIUS Attributes 479 Types in the "Radius Types" registry (currently located at 480 http://www.iana.org/assignments/radius-types for the following 481 attributes: 483 o MAP-Configuration TBD1 485 IANA should allocate the numbers from the standard RADIUS Attributes 486 space using the "IETF Review" policy [RFC5226]. 488 7. Security Considerations 490 In MAP scenarios, both CE and BNG are within a provider network, 491 which can be considered as a closed network and a lower security 492 threat environment. A similar consideration can be applied to the 493 RADIUS message exchange between BNG and the AAA server. 495 Known security vulnerabilities of the RADIUS protocol are discussed 496 in [RFC2607], [RFC2865], and[RFC2869]. Use of IPsec [RFC4301] for 497 providing security when RADIUS is carried in IPv6 is discussed in 498 [RFC3162]. 500 A malicious user may use MAC address proofing and/or dictionary 501 attack on the shared MAP password that has been preconfigured on the 502 DHCPv6 server to get unauthorized MAP configuration information. 504 Security considerations for MAP specific between MAP CE and BNG are 505 discussed in [I-D.ietf-softwire-map]. Furthermore, generic DHCPv6 506 security mechanisms can be applied DHCPv6 intercommunication between 507 MAP CE and BNG. 509 Security considerations for the Diameter protocol are discussed in 510 [RFC6733]. 512 8. Acknowledgements 514 The authors would like to thank the valuable comments made by Peter 515 Lothberg, Wojciech Dec, and Suresh Krishnan for this document. 517 This document was produced using the xml2rfc tool [RFC2629]. 519 9. References 520 9.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 526 "Remote Authentication Dial In User Service (RADIUS)", RFC 527 2865, June 2000. 529 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 530 3162, August 2001. 532 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 533 and M. Carney, "Dynamic Host Configuration Protocol for 534 IPv6 (DHCPv6)", RFC 3315, July 2003. 536 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 537 "IEEE 802.1X Remote Authentication Dial In User Service 538 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 540 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 541 Dial In User Service (RADIUS) Implementation Issues and 542 Suggested Fixes", RFC 5080, December 2007. 544 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 545 158, RFC 6158, March 2011. 547 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 548 Service (RADIUS) Protocol Extensions", RFC 6929, April 549 2013. 551 9.2. Informative References 553 [I-D.ietf-softwire-map] 554 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 555 Murakami, T., and T. Taylor, "Mapping of Address and Port 556 with Encapsulation (MAP)", draft-ietf-softwire-map-10 557 (work in progress), January 2014. 559 [I-D.ietf-softwire-map-dhcp] 560 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 561 W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, 562 "DHCPv6 Options for configuration of Softwire Address and 563 Port Mapped Clients", draft-ietf-softwire-map-dhcp-07 564 (work in progress), March 2014. 566 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 567 Implementation in Roaming", RFC 2607, June 1999. 569 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 570 June 1999. 572 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 573 Extensions", RFC 2869, June 2000. 575 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 576 Internet Protocol", RFC 4301, December 2005. 578 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 579 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 580 May 2008. 582 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 583 "Diameter Base Protocol", RFC 6733, October 2012. 585 Authors' Addresses 587 Sheng Jiang 588 Huawei Technologies Co., Ltd 589 Q14, Huawei Campus, No.156 Beiqing Road 590 Hai-Dian District, Beijing, 100095 591 P.R. China 593 Email: jiangsheng@huawei.com 595 Yu Fu 596 Huawei Technologies Co., Ltd 597 Q14, Huawei Campus, No.156 Beiqing Road 598 Hai-Dian District, Beijing, 100095 599 P.R. China 601 Email: eleven.fuyu@huawei.com 603 Bing Liu 604 Huawei Technologies Co., Ltd 605 Q14, Huawei Campus, No.156 Beiqing Road 606 Hai-Dian District, Beijing, 100095 607 P.R. China 609 Email: leo.liubing@huawei.com 610 Peter Deacon 611 IEA Software, Inc. 612 P.O. Box 1170 613 Veradale, WA 99037 614 USA 616 Email: peterd@iea-software.com