idnits 2.17.1 draft-ietf-l2vpn-radius-pe-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2005) is 7005 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: 'TBD' is mentioned on line 587, but not defined == Unused Reference: 'RFC2868' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pwe3-control-protocol' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC2279' is defined on line 625, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2868 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-02 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-14 -- Obsolete informational reference (is this intentional?): RFC 2279 (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Heinanen 2 Internet-Draft TutPro Inc. 3 Expires: August 23, 2005 G. Weber, Ed. 4 W. Townsley 5 S. Booth 6 W. Luo 7 Cisco Systems 8 February 19, 2005 10 Using RADIUS for PE-Based VPN Discovery 11 draft-ietf-l2vpn-radius-pe-discovery-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 23, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document describes a strategy by which Provider Equipment (PE) 47 can be dynamically provisioned for inclusion in PE-based Layer 2 48 Virtual Private Networks (L2VPNs). This layered strategy utilizes 49 the Remote Authentication Dial In User Service (RADIUS) protocol as a 50 centralized control mechanism and can be used in conjunction with 51 other proposed mechanisms. The mechanisms described in this document 52 enhance those established by RFC 2868 and conform to those described 53 by the L2VPN Framework. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Information Model . . . . . . . . . . . . . . . . . . . . . 3 61 5. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . 6 62 5.1 Router-Distinguisher . . . . . . . . . . . . . . . . . . . 6 63 5.2 VPN-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3 Attachment-Individual-ID . . . . . . . . . . . . . . . . . 7 65 5.4 Per-Hop-Behavior . . . . . . . . . . . . . . . . . . . . . 8 66 5.5 PE-Router-ID . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.6 PE-Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.7 PE-Record . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. New Values for Existing RADIUS Attributes . . . . . . . . . 11 70 6.1 Service-Type . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.2 User-Name . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . 12 73 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. Security Considerations . . . . . . . . . . . . . . . . . . 14 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 11.1 Normative References . . . . . . . . . . . . . . . . . . 14 78 11.2 Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 80 Intellectual Property and Copyright Statements . . . . . . . 17 82 1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 This document uses terminology from [I-D.ietf-l2vpn-l2-framework] and 89 [I-D.ietf-l2vpn-signaling]. 91 2. Acronyms 93 AII: Attachment Individual Identifier 94 AC: Attachment Circuit 95 AGI: Attachment Group Identifier 96 AS: Automonous System 97 CE: Customer Equipment 98 L2VPN: Layer 2 Provider Provisioned Virtual Private Network 99 NAI Network Access Identifier 100 NAS: Network Access Server 101 PE: Provider Equipment 102 SAI: Source Attachment Identifier 103 SAII: Source Attachment Individual Identifier 104 RADIUS: Remote Authentication Dial In User Service 105 TAI: Target Attachment Identifier 106 TAII: Target Attachment Individual Identifier 107 VPLS: Virtual Private LAN Service 108 VPN: Virtual Private Network 109 VPWS: Virtual Private Wire Service 111 3. Introduction 113 This document describes how in PE-based VPNs a PE of a VPN can use 114 RADIUS [RFC2865] to authenticate its CEs and discover the other PEs 115 of the VPN. In RADIUS terms, the CEs are users and the PEs are 116 Network Access Servers (NAS) implementing RADIUS client 117 functionality. 119 A VPN can span multiple Autonomous Systems (AS) and multiple 120 providers. Each PE, however, only needs to be a RADIUS client to 121 RADIUS server of the "local" provider. In the case in which a CE 122 belongs to a "foreign" VPN, the RADIUS server of the local provider 123 acts as a proxy client to RADIUS of the foreign provider. 125 4. Information Model 127 This document presents a model wherein authorization for 128 participation in a PE-based VPN can be divided into three different 129 layers of access. 131 o CE or AC Authorization 132 o VPN Authorization 133 o Pseudowire Authorization 135 The first layer is AC authorization, in which a first sign of life on 136 a particular AC triggers an authorization resulting in provisioning 137 information particular to the circuit in question. Once the AC is 138 authorized, its VPN membership is authorized separately. This 139 authorization step may result in a number of pseudowire specific 140 connections; each of which may be authorized separately. The 141 relationships between these three data representations are shown in 142 the diagram below. 144 Using a layered approach allows the different stages of authorization 145 to be satisfied by separate means based on deployment scenario. It 146 also allows one model to apply to various deployment architectures 147 including VPLS and VPWS. If all three authorization stages are 148 accommodated by a RADIUS server, the stages may be combined into a 149 single transaction instead of having three separate transactions. 151 +--------+ 152 | | 153 | CE | 154 | | 155 +--------+ 156 | 157 +-------------------------+---------------------------+ 158 | | | 159 | VPN +--------+ | 160 | | | | 161 | | PE | | 162 | | | | 163 | +--------+ | 164 | | | 165 | | | 166 | +------------------------------------------+ | 167 | | +-------------------------+ | | 168 | | PE | +-------------------+ | | | 169 | | Next Hop | | Pseudowire | | | | 170 | | +--------+ +-| Per hop behavior| | | | 171 | | | | | ... | | | | 172 | | | AII-----+ +-------------------+ | | | 173 | | | AII-----+ +-------------------+ | | | 174 | | | ... | | Pseudowire | | | | 175 | | | +-| Per hop behavior| | | | 176 | | | | ... | | | | 177 | | | +-------------------+ | | | 178 | | | ... | | | 179 | | +----------------------------------+ | | 180 | +------------------------------------------+ | 181 | +------------------------------------------+ | 182 | | +-------------------------+ | | 183 | | PE | +-------------------+ | | | 184 | | Next Hop | | Pseudowire | | | | 185 | | +--------+ +-| Per hop behavior| | | | 186 | | | | | ... | | | | 187 | | | AII-----+ +-------------------+ | | | 188 | | | AII-----+ +-------------------+ | | | 189 | | | ... | | Pseudowire | | | | 190 | | | +-| Per hop behavior| | | | 191 | | | | ... | | | | 192 | | | +-------------------+ | | | 193 | | | ... | | | 194 | | +----------------------------------+ | | 195 | +------------------------------------------+ | 196 | ... | 197 +-----------------------------------------------------+ 199 o Each pseudowire may have its own per-hop behavior and arbitrary 200 configuration information 201 o Each pseudowire is associated with an AII 202 o Each PE includes an arbitrary number of AIIs 203 o Each PE has one associated next hop address 204 o The VPN includes an arbitrary number of PEs 206 The following two sections define how the components of this data 207 model may be represented as RADIUS attributes so the components of 208 this information model may be communicated from a centralized 209 location out into the network elements. 211 5. New RADIUS Attributes 213 This document defines several new RADIUS Attributes which are 214 described in detail in this section. 216 5.1 Router-Distinguisher 218 This attribute represents a Router Distinguisher as described in 219 [I-D.ietf-l3vpn-rfc2547bis]. It MAY be included in an Access-Request 220 message. This attribute MUST NOT be included in Access-Request 221 messages that also include a "VPN-ID" attribute. 223 A summary of the Router-Distinguisher attribute format is shown 224 below. The fields are transmitted from left to right. 226 0 1 2 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 229 | Type | Length | Text ... 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 232 Type 234 (TBA) for Router-Distinguisher. 236 Length 238 >= 7 240 Text 242 The Text field is composed of three colon separated parts: a type, an 243 administrator, and an assigned number. 245 Where the type is "0", the administrator contains a 16-bit Autonomous 246 System Number (ASN), and the assigned number is a 32-bit value 247 assigned by enterprise responsible for the ASN, e.g. "0:114:23". 249 Where the type is "1", the administrator contains an IP address, and 250 the assigned number is a 16-bit value assigned by the enterprise 251 controlling the IP address space, e.g. "1:1.2.3.4:10001". 253 Where the type is "2", the administrator contains a 32-bit ASN, and 254 the assigned number is a 16-bit value assigned by the enterprise 255 responsible for the ASN, e.g. "2:70000:216". 257 5.2 VPN-ID 259 This attribute represents a VPN-ID as described in [RFC2685]. It MAY 260 be included in an Access-Request message. This attribute MUST NOT be 261 included in Access-Request messages that also include a 262 Router-Distinguisher attribute. 264 A summary of the VPN-ID attribute format is shown below. The fields 265 are transmitted from left to right. 267 0 1 2 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 270 | Type | Length | Text ... 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 273 Type 275 (TBA) for VPN-ID. 277 Length 279 >= 5 281 Text 283 The Text field is composed of two colon separated parts: a VPN 284 authority Organizationally Unique Identifier, and a VPN index, e.g. 285 "101:14". 287 5.3 Attachment-Individual-ID 289 This attribute indicates a Attachment-Individual-ID as described in 290 [I-D.ietf-l2vpn-signaling]. 292 A summary of the Attachment-Individual-ID attribute format is shown 293 below. The fields are transmitted from left to right. 295 0 1 2 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 298 | Type | Length | Text ... 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 301 Type 303 (TBA) for Attachment-Individual-ID. 305 Length 307 >= 3 309 Text 311 The Text field is an encoding of the Source Attachment Individual 312 Identifier, e.g. "2". 314 5.4 Per-Hop-Behavior 316 This attribute indicates a Per-Hop-Behavior as described in 317 [RFC3140]. 319 A summary of the Per-Hop-Behavior attribute format is shown below. 320 The fields are transmitted from left to right. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | Value 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Value (cont) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type 332 (TBA) for Per-Hop-Behavior. 334 Length 336 6 338 Integer 340 The lower 16-bits of the value contains the Per-Hop-Behavior value as 341 described in [RFC3140]. 343 5.5 PE-Router-ID 345 This attribute typically indicates an IPv4 address for a particular 346 PE member of a VPN, though it may be some arbitrary value assigned by 347 the owner of the ID space. 349 A summary of the PE-Router-ID attribute format is shown below. The 350 fields are transmitted from left to right. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type | Length | Value 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 Value (cont) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Type 362 (TBA) for PE-Router-ID. 364 Length 366 6 368 Address 370 Typically, the value indicates the IPv4 address of a particular PE 371 member of a VPN. 373 5.6 PE-Address 375 This attribute indicates an IPv4 address for a particular PE member 376 of a VPN. In relation to the PE for which a CE is joining the VPN, 377 this would be the initial's PE's next hop address. 379 A summary of the PE-Address attribute format is shown below. The 380 fields are transmitted from left to right. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length | Value 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Value (cont) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Type 392 (TBA) for PE-Address. 394 Length 396 6 398 Address 400 The value indicates the IPv4 address of a particular PE member of a 401 VPN. 403 5.7 PE-Record 405 This attribute represents a single element within a particular PE's 406 description. A group of PE-Records combine to form a complete PE 407 description when returned during VPN authorization. 409 A summary of the PE-Record attribute format is shown below. The 410 fields are transmitted from left to right. 412 0 1 2 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 415 | Type | Length | Text ... 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 418 Type 420 (TBA) for PE-Record. 422 Length 424 >= 8 426 Text 428 The Text field contains an AII prefixed by a PE-Router-ID and 429 separated by a colon, e.g. "1.1.1.1:14" where the PE-Router-ID is 430 1.1.1.1 and the AII is 14. This represents a particular pseudowire. 431 The value is optionally suffixed by a colon separated list of 432 attribute value pairs containing pseudowire-specific configuration, 433 e.g. "1.1.1.1:14:PHB=256". 435 6. New Values for Existing RADIUS Attributes 437 6.1 Service-Type 439 This document defines one new value for an existing RADIUS attribute. 440 The Service-Type attribute is defined in Section 5.6 of RFC 2865 441 [RFC2865], as follows: 443 This Attribute indicates the type of service the user has requested, 444 or the type of service to be provided. It MAY be used in both 445 Access-Request and Access-Accept packets. 447 A NAS is not required to implement all of these service types, and 448 MUST treat unknown or unsupported Service-Types as though an Access- 449 Reject had been received instead. 451 A summary of the Service-Type Attribute format is shown below. 453 The fields are transmitted from left to right. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | Value 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Value (cont) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Type 465 6 for Service-Type. 467 Length 469 6 471 Value 473 The Value field is four octets. 475 This document defines one new value for the Service-Type 476 attribute. 478 (TBA) L2VPN 480 The semantics of the L2VPN service are as follows: 482 L2VPN A CE is requesting to join a VPN. 484 6.2 User-Name 486 This attribute defined by [RFC2865] takes a value depending on which 487 layer of VPN authorization is occurring. 489 o For CE/AC authorization, the User-Name value contains either a 490 Network Access Identifier (NAI) associated with the CE [RFC2486], 491 or an implementation dependent AC name. 492 o For VPN authorization, the User-Name value contains the VPN-ID or 493 a Router-Distinguisher. 494 o For pseudowire authorization, the User-Name value contains a 495 PE-Router-ID. 497 7. Table of Attributes 499 The following tables provide a guide to which attributes may be found 500 in which kinds of packets, and in what quantity. 502 CE/AC Authorization 503 Request Accept Reject Challenge # Attribute 504 --------------------------------------------------------------------- 505 0 0-1 0 0 TBA Router-Distinguisher 506 0 0-1 0 0 TBA VPN-ID 508 VPN Authorization 509 Request Accept Reject Challenge # Attribute 510 --------------------------------------------------------------------- 511 0-1 0 0 0 TBA Router-Distinguisher 512 0-1 0 0 0 TBA VPN-ID 513 0 0+ 0 0 TBA Attachment-Individual-ID 514 0 0-1 0 0 TBA Per-Hop-Behavior 515 0 0-1 0 0 TBA PE-Router-ID 516 0 0-1 0 0 TBA PE-Address 517 0 0+ 0 0 TBA PE-Record 519 Pseudowire Authorization 520 VPN Authorization 521 Request Accept Reject Challenge # Attribute 522 --------------------------------------------------------------------- 523 0-1 0 0 0 TBA Router-Distinguisher 524 0-1 0 0 0 TBA VPN-ID 525 1 0 0 0 TBA Attachment-Individual-ID 526 0 0-1 0 0 TBA Per-Hop-Behavior 528 The following table defines the meaning of the above table entries. 530 0 This attribute MUST NOT be present in a packet. 531 0+ Zero or more instances of this attribute MAY be present in 532 a packet. 533 0-1 Zero or one instance of this attribute MAY be present in 534 a packet. 535 1 Exactly one instance of this attribute MUST be present in 536 a packet. 538 8. Examples 540 CE/AC Authorization 542 Request 543 User-Name = "providerX/atlanta@vpnY.domainZ.net" (CE NAI) 544 NAS-IP-Address = "1.1.1.1" 545 Response 546 VPN-ID = "100:14" 548 Request 549 User-Name = "ATM14.0.1" (AC Name) 550 NAS-IP-Address = "1.1.1.1" 551 Response 552 Router-Distinguisher = "1:1.2.3.4:10001" 554 VPN Authorization 556 Request 557 User-Name = "100:14" (VPN-ID) 558 NAS-IP-Address = "1.1.1.1" 559 Response 560 PE-Record = "2.2.2.2:14" (PE-Router-ID:AII) 561 PE-Record = "2.2.2.2:15" 562 PE-Record = "3.3.3.3:24" 563 PE-Record = "3.3.3.3:25" 565 Request 566 User-Name = "100:14" (VPN-ID) 567 NAS-IP-Address = "1.1.1.1" 568 Response 569 PE-Record = "2.2.2.2:14:PHB=256" 571 Pseudowire Authorization 573 Request 574 User-Name = "2.2.2.2" (PE-Router-ID) 575 NAS-IP-Address = "1.1.1.1" 576 Attachment-Individual-ID = "14" 577 VPN-ID = "100:14" 578 Response 579 Per-Hop-Behavior = "256" 581 9. Security Considerations 583 [TBD] 585 10. IANA Considerations 587 [TBD] 589 11. References 591 11.1 Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 597 "Remote Authentication Dial In User Service (RADIUS)", 598 RFC 2865, June 2000. 600 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 601 M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol 602 Support", RFC 2868, June 2000. 604 [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks 605 Identifier", RFC 2685, September 1999. 607 11.2 Informative References 609 [I-D.ietf-l2vpn-signaling] 610 Rosen, E. and V. Radoaca, "Provisioning Models and 611 Endpoint Identifiers in L2VPN Signaling", 612 Internet-Draft draft-ietf-l2vpn-signaling-02, September 613 2004. 615 [I-D.ietf-pwe3-control-protocol] 616 Martini, L., "Pseudowire Setup and Maintenance using LDP", 617 Internet-Draft draft-ietf-pwe3-control-protocol-14, 618 November 2004. 620 [I-D.ietf-l3vpn-rfc2547bis] 621 Rosen, E., "BGP/MPLS IP VPNs", 622 Internet-Draft draft-ietf-l3vpn-rfc2547bis-03, October 623 2004. 625 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 626 10646", RFC 2279, January 1998. 628 [I-D.ietf-l2vpn-l2-framework] 629 Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 630 Private Networks (L2VPNs)", 631 Internet-Draft draft-ietf-l2vpn-l2-framework-05, June 632 2004. 634 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 635 RFC 2486, January 1999. 637 [RFC3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, 638 "Per Hop Behavior Identification Codes", RFC 3140, June 639 2001. 641 Authors' Addresses 643 Juha Heinanen 644 TutPro Inc. 645 Utsjoki 646 Finland 648 Email: jh@tutpro.com 650 Greg Weber (editor) 651 Cisco Systems 652 10850 Murdock Road 653 Knoxville, TN 37932 654 US 656 Email: gdweber@cisco.com 658 W. Mark Townsley 659 Cisco Systems 660 7025 Kit Creek Road 661 Research Triangle Park, NC 27709 662 US 664 Email: mark@townsley.net 666 Skip Booth 667 Cisco Systems 668 7025 Kit Creek Road 669 Research Triangle Park, NC 27709 670 US 672 Email: ebooth@cisco.com 674 Wei Luo 675 Cisco Systems 676 170 West Tasman Drive 677 San Jose, CA 95134 678 US 680 Email: luo@cisco.com 682 Intellectual Property Statement 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use of 696 such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at 704 ietf-ipr@ietf.org. 706 Disclaimer of Validity 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Copyright Statement 718 Copyright (C) The Internet Society (2005). This document is subject 719 to the rights, licenses and restrictions contained in BCP 78, and 720 except as set forth therein, the authors retain all their rights. 722 Acknowledgment 724 Funding for the RFC Editor function is currently provided by the 725 Internet Society.