idnits 2.17.1 draft-ietf-radext-ipv6-access-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 (July 6, 2010) is 5035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4861' is defined on line 500, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Lourdelet 3 Internet-Draft W. Dec, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 7, 2011 B. Sarikaya 6 Huawei USA 7 G. Zorn 8 Network Zen 9 D. Miles 10 Alcatel-Lucent 11 July 6, 2010 13 RADIUS attributes for IPv6 Access Networks 14 draft-ietf-radext-ipv6-access-02.txt 16 Abstract 18 This document specifies IPv6 RADIUS attributes, which complement 19 those of RFC3162, and are intended to be used in residential 20 broadband networks, where specific user configuration information is 21 expected to be passed as part of the AAA process between a NAS and an 22 AAA server. The attributes cover the assignment or reporting of the 23 following; a specific host IPv6 address; a recursive DNS IPv6 server 24 address; a specific IPv6 route announced to a host; a named IPv6 25 delegated prefix pool to be used for assignments to an accessing 26 host. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 7, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 81 2.1. IPv6 Address Assignment . . . . . . . . . . . . . . . . . 5 82 2.2. Recursive DNS Servers . . . . . . . . . . . . . . . . . . 6 83 2.3. IPv6 Route Information . . . . . . . . . . . . . . . . . . 6 84 2.4. Delegated IPv6 Prefix Pool . . . . . . . . . . . . . . . . 6 85 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.1. Framed-IPv6-Address . . . . . . . . . . . . . . . . . . . 7 87 3.2. DNS-Server-IPv6-Address . . . . . . . . . . . . . . . . . 8 88 3.3. Route-IPv6-Information . . . . . . . . . . . . . . . . . . 9 89 3.4. Delegated-IPv6-Prefix-Pool . . . . . . . . . . . . . . . . 10 90 3.5. Table of attributes . . . . . . . . . . . . . . . . . . . 10 91 3.6. RFC3162 Attribute coexistance . . . . . . . . . . . . . . 11 92 4. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 98 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Introduction 103 In IPv6 deployments DHCPv6 and/or ICMPv6 Router Advertisements can be 104 used to convey configuration information by a NAS towards accessing 105 hosts. Such information typically needs to be provisioned on the NAS 106 and may be done so on a per host or user basis using the AAA process. 107 This document specifies IPv6 RADIUS attributes used to support 108 configuration information allowed for by DHCPv6 and/or ICMPv6, which 109 complement the existing set defined in [RFC3162] and [RFC4818]. 110 Specifically, attributes supporting the following information in 111 Radius are covered by this draft: 113 o The assignment or reporting of specific IPv6 addresses assigned to 114 hosts (where host address assignmenet takes place via DHCPv6) 116 o The passing by the NAS of IPv6 recursive DNS server addresses to a 117 host (where the NAS and accessing host use DHCPv6 or [RFC5006]) 119 o The passing of IPv6 Route information by the NAS intended to be 120 advertised to the host (where the NAS and accessing host use 121 [RFC4191] or equivalent mechanisms). 123 o The assignment of a named prefix pool intended for Prefix 124 Delegation to a host (where the NAS and accessing host use 125 [RFC3633]). 127 2. Deployment Scenarios 129 A common broadband network scenario is illustrated in Figure 1. It 130 is composed of a IP Routing Residential Gateway (RG) or host, a Layer 131 2 Access-Node (e.g. a DSLAM), one or more IP Network Access Servers 132 (NASes), and an AAA server. The RG or host are expected to be multi 133 homed at Layer 2 to both NASes. Layer 2 Connectivity between the 134 host and NAS can be either via PPPoE or IP over Ethernet, and 135 established dynamically. 137 +-----+ 138 (Radius) | AAA | 139 ...........>| | 140 . +--+--+ 141 v ^ 142 +---+---+ . 143 | NAS | .(Radius) 144 | | . 145 +---+---+ v 146 +------+ | +---+---+ 147 +------+ | AN | | | NAS | 148 | RG/ +-------| +-----------+----------+ | 149 | host | | | | | 150 +------+ (DSL) +------+ (Ethernet) +-------+ 152 Figure 1 154 In the illustrated deployment scenario the NASes are assumed to embed 155 a DHCPv6 server function that allows them to locally handle any 156 DHCPv6 requests issued by RGs/hosts. This scenario is particularly 157 useful in illustrating the possible interaction between RADIUS and 158 DHCPv6, however the options defined in this document are not 159 restricted to be used only in the presence of such embedded 160 functionality. 162 The NAS interfaces to the AAA server by means of the RADIUS protocol. 163 The AAA server is expected to authenticate each accessing RG/host and 164 to return to the NAS per host authorization and network configuration 165 information that can comprise of: One or more IP addresses Recursive 166 DNS servers intended to be announced to the host; specific IP routes 167 to be announced to the host by a NAS; an explicit 128 bit IPv6 168 address that is to be statefuly assigned to a given RG/host. The NAS 169 can also report some of this information back to the AAA server in 170 accounting messages. 172 The known methods by which the NAS can communicate the above 173 information to RG/hosts are explained in each of the following sub- 174 sections. 176 2.1. IPv6 Address Assignment 178 DHCPv6 [RFC3315] provides a mechanism to assign one or more or non- 179 temporary IPv6 addresses to nodes complementing the ICMPv6 stateless 180 (SLAAC) method [RFC4862]. Simplistically, using SLAAC the NAS 181 announces to a host a /64 IPv6 prefix from which the host construct 182 its full 128 bit IPv6 address by appending an 64-bit interface- 183 identifier. By providing one or more hosts with only a /64 prefix, 184 network operators are have to rely on extra processes or procedures 185 to determine the exact IPv6 address that is being used by a host. 186 Such procedures typically involve processing of two existing 187 [RFC3162] attributes. In contrast to SLAAC, DHCPv6 allows for an 188 operator to uniquely assign a non-temporary address to a give host. 189 This document specifies a single RADIUS attribute intended to be used 190 for the assignment or accounting of a full 128-bit IPv6 addresses to 191 a host (typically via DHCPv6), without overloading or modifying the 192 implementations associated to the existing attributes. 194 2.2. Recursive DNS Servers 196 DHCPv6 provides an option for recursive DNS servers to hosts, as does 197 ICMPv6 with Router Advertisements supporting the experimental 198 [RFC5006] option. Existing IETF Radius attributes convey DNS as 32- 199 bit IPv4 addresses and cannot support a 128-bit IPv6 address. This 200 document specifies the RADIUS attribute to convey a list of IPv6 DNS 201 Recursive name server addresses, from an AAA server, which can that 202 can be conveyed by a NAS to a host. 204 2.3. IPv6 Route Information 206 In scenarios where Stateless Address Autoconfiguration (SLAAC) 207 [RFC4862] is used for address assignment, an ICMPv6 Router 208 Advertisement is multicast by the NAS with one or more Prefix 209 Information Options with the autonomous-bit set to true. In such 210 cases, the Prefix Information Option, is a /64 prefix to which a host 211 appends its locally-generated Interface Id to create a unique 128-bit 212 IPv6 address. [RFC3162] currently defines a Radius Framed-IPv6- 213 Prefix attribute that can be used by a NAS to advertise such on-link 214 prefixes in Router Advertisement messages. An IPv6 Route Information 215 option, defined in [RFC4191] is almost the inverse. It is intended 216 to be used to inform a host connected to the NAS that a specific 217 route is reachable via the NAS. This is particularly desirable in 218 cases where the RG or host are multi-homed to different NASes as 219 shown in Figure 1. 221 This document specifies the RADIUS attribute that allows the AAA 222 system to provision the announcement by the NAS of a specific Route 223 Information Option to an accessing host. The NAS may advertise this 224 route using the method defined in [RFC4191] or using other equivalent 225 methods. 227 2.4. Delegated IPv6 Prefix Pool 229 The use of DHCPv6 Prefix Delegation [RFC3633] involves a delegating 230 router selecting a prefix and delegating it on a temporary basis to a 231 requesting router. The delegating router may implement a number of 232 strategies as to how it chooses what prefix is to be delegated to a 233 requesting router, one of them being the use of a local named prefix 234 pool. The Delegated IPv6 Prefix Pool attribute is intended to allow 235 the AAA system to convey the selected prefix pool name to a NAS 236 hosting a DHCPv6-PD server and acting as a delegating router. While 237 similar in principle, this attribute is not to be confused with the 238 [RFC3162]Framed-IPv6-Pool attribute, which is intended for selecting 239 an address from a pool for assignment to a user interface nor with 240 [RFC4818] that conveys a specific prefix. 242 3. Attributes 244 The fields shown in the diagrams below are transmitted from left to 245 right. 247 3.1. Framed-IPv6-Address 249 This Attribute indicates an IPv6 Address that is assigned to the NAS- 250 facing interface of the RG/host. It MAY be used in Access-Accept 251 packets, and MAY appear multiple times. It MAY be used in an Access- 252 Request packet as a hint by the NAS to the server that it would 253 prefer these IPv6 address(es), but the server is not required to 254 honor the hint. Since it is assumed that the NAS will add a route 255 corresponding to the address, it is not necessary for the server to 256 also send a host Framed-IPv6-Route attribute for the same address. 258 This Attribute can be used by a DHCPv6 process on the NAS to assign a 259 unique IPv6 address to the RG/host, or it can be used for 260 a-posteriori validation or announcement of an auto configured address 261 to the AAA server. 263 A summary of the Framed-IPv6-Address Attribute format is shown below. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | Address 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Address (cont) 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Address (cont) 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Address (cont) 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Address (cont.) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type 281 TBA1 for Framed-IPv6-Address 283 Length 285 18 287 Address 289 The Address field contains a 128-bit IPv6 address. 291 3.2. DNS-Server-IPv6-Address 293 The DNS-Server-IPv6-Address Attribute contains the IPv6 address of a 294 recursive DNS server. This attribute MAY be included multiple times 295 in Access-Accept packets, when the intention is for a NAS to announce 296 more than one recursive DNS address to an RG/host. 298 The content of this attribute can be inserted in a Router 299 Advertisement as specified in [RFC5006] or mapped to the matching 300 DHCPv6 option. 302 A summary of the DNS-Server-IPv6-Address Attribute format is given 303 below. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | Address 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Address (cont) 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Address (cont) 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Address (cont) 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Address (cont.) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Type 321 TBA2 for DNS-Server-IPv6-Address 323 Length 325 18 327 Address 329 The 128-bit IPv6 address of a DNS server. 331 3.3. Route-IPv6-Information 333 This Attribute specifies a prefix (and corresponding route) to be 334 authorized for announcement towards the user by the NAS, with the 335 reachable by means of routing towards the NAS. It is used in the 336 Access-Accept packet and can appear multiple times. It may also be 337 used in the Access-Request packet as hint to the server. 339 A summary of the Route-IPv6-Information attribute format is shown 340 below. The route information option defined in [RFC4191] is captured 341 in this and following two attributes. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length | Reserved | Prefix-Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | | 349 . Prefix (variable) . 350 . . 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Type 356 TBA3 for Route-IPv6-Information 358 Length 360 Length in bytes. At least 4 and no larger than 20; typically 12 361 or less. 363 Prefix Length 365 The length of the prefix, in bits; at least 0 and no more than 366 128; typically 64 or less. 368 Prefix 370 Variable-length field containing an IP prefix. The Prefix Length 371 field contains the number of valid leading bits in the prefix. 372 The bits in the prefix after the prefix length (if any) up to the 373 byte boundary are reserved and MUST be initialized to zero by the 374 sender and ignored by the receiver. 376 3.4. Delegated-IPv6-Prefix-Pool 378 This Attribute contains the name of an assigned pool that SHOULD be 379 used to select an IPv6 delegated prefix for the user. If a NAS does 380 not support multiple prefix pools, the NAS MUST ignore this 381 Attribute. 383 A summary of the Delegated-IPv6-Prefix-Pool Attribute format is shown 384 below. The fields are transmitted from left to right. 385 0 1 2 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | String... 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Type 393 TBA4 for Delegated-IPv6-Prefix-Pool 395 Length 397 Length in bytes. At least 4. 399 String 401 The string field contains the name of an assigned IPv6 prefix pool 402 configured on the NAS. The field is not NULL (hex 00) terminated. 404 3.5. Table of attributes 406 The following table provides a guide to which attributes may be found 407 in which kinds of packets, and in what quantity. 409 Request Accept Reject Challenge Accounting # Attribute 410 Request 411 0+ 0+ 0 0 0+ TBA1 Framed-IPv6-Address 412 0+ 0+ 0 0 0+ TBA2 DNS-Server-IPv6-Address 413 0 0+ 0 0 0+ TBA3 Route-IPv6-Information 414 0 0-1 0 0 0-1 TBA4 Delegated-IPv6-Prefix-Pool 415 3.6. RFC3162 Attribute coexistance 417 Syntactically, the Framed-IPv6-Address and the [RFC3162] Framed-IPv6- 418 Prefix attributes are identical. In terms of their applied 419 semantics, however the former represents a full 128-bit IPv6 address 420 while the latter a /64 prefix intended to be applied with SLAAC on a 421 NAS access interface. These attributes are envisaged to co-exist in 422 Radius messages and given existing NAS applications for the Framed- 423 IPv6-Prefix it is recommended that each attribute be used for its 424 intended purposes. A functional substitution of one attribute for 425 the other may however be an optional configuration feature of a 426 Radius client and server. 428 4. Diameter Considerations 430 Given that the Attributes defined in this document are allocated from 431 the standard RADIUS type space (see Section 6), no special handling 432 is required by Diameter entities. 434 5. Security Considerations 436 This document describes the use of RADIUS for the purposes of 437 authentication, authorization and accounting in IPv6-enabled 438 networks. In such networks, the RADIUS protocol may run either over 439 IPv4 or over IPv6. Known security vulnerabilities of the RADIUS 440 protocol apply to the attributes defined in this document. Since 441 IPSEC is natively defined for IPv6, it is expected that running 442 RADIUS implementations supporting IPv6 may want to run over IPSEC. 443 Where RADIUS is run over IPSEC and where certificates are used for 444 authentication, it may be desirable to avoid management of RADIUS 445 shared secrets, so as to leverage the improved scalability of public 446 key infrastructure. 448 6. IANA Considerations 450 This document requires the assignment of three new RADIUS Attribute 451 Types in the "Radius Types" registry (currently located at 452 http://www.iana.org/assignments/radius-types for the following 453 attributes: 455 o Framed-IPv6-Address 457 o DNS-Server-IPv6-Address 458 o Route-IPv6-Information 460 o Delegated-IPv6-Prefix-Pool 462 IANA should allocate these numbers from the standard RADIUS 463 Attributes space using the "IETF Review" policy [RFC5226]. 465 7. Acknowledgements 467 The authors would like to thank Alfred Hines, Alan DeKok, Peter 468 Deacon and Mark Smith for their help and comments in reviewing this 469 document. 471 8. References 473 8.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 479 Address Autoconfiguration", RFC 4862, September 2007. 481 8.2. Informative References 483 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 484 RFC 3162, August 2001. 486 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 487 and M. Carney, "Dynamic Host Configuration Protocol for 488 IPv6 (DHCPv6)", RFC 3315, July 2003. 490 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 491 Host Configuration Protocol (DHCP) version 6", RFC 3633, 492 December 2003. 494 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 495 More-Specific Routes", RFC 4191, November 2005. 497 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 498 Attribute", RFC 4818, April 2007. 500 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 501 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 502 September 2007. 504 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 505 "IPv6 Router Advertisement Option for DNS Configuration", 506 RFC 5006, September 2007. 508 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 509 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 510 May 2008. 512 Authors' Addresses 514 Benoit Lourdelet 515 Cisco Systems, Inc. 516 Village ent. GreenSide, Bat T3, 517 400, Av de Roumanille, 518 06410 BIOT - Sophia-Antipolis Cedex 519 France 521 Phone: +33 4 97 23 26 23 522 Email: blourdel@cisco.com 524 Wojciech Dec (editor) 525 Cisco Systems, Inc. 526 Haarlerbergweg 13-19 527 Amsterdam , NOORD-HOLLAND 1101 CH 528 Netherlands 530 Email: wdec@cisco.com 532 Behcet Sarikaya 533 Huawei USA 534 1700 Alma Dr. Suite 500 535 Plano, TX 536 US 538 Phone: +1 972-509-5599 539 Email: sarikaya@ieee.org 540 Glen Zorn 541 Network Zen 542 1310 East Thomas Street 543 Seattle, WA 544 US 546 Email: gwz@net-zen.net 548 David Miles 549 Alcatel-Lucent 550 L3 / 215 Spring St 551 Melbourne, Victoria 3000, 552 Australia 554 Phone: 555 Fax: 556 Email: David.Miles@alcatel-lucent.com 557 URI: