idnits 2.17.1 draft-ooms-v6ops-bgp-tunnel-04.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 3979, Section 5, paragraph 1 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 533), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 527. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: 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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 10) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([KEYWRD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'IPv6' is mentioned on line 80, but not defined == Unused Reference: 'MP-BGP' is defined on line 415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (ref. 'LABEL') (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 3513 (ref. 'V6ADDR') (Obsoleted by RFC 4291) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. De Clercq 2 Alcatel 3 D. Ooms 4 OneSparrow 5 S. Prevost 6 BTexact 7 F. Le Faucheur 8 Cisco 9 October, 2004 10 Expires April, 2005 12 Connecting IPv6 Islands over IPv4 MPLS 13 using IPv6 Provider Edge Routers (6PE) 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he is aware have been 19 or will be disclosed, and any of which he becomes aware will be 20 disclosed, in accordance with 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 Internet- 25 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 Abstract 40 This document explains how to interconnect IPv6 islands over a 41 Multi-Protocol Label Switching (MPLS)-enabled IPv4 cloud. This 42 approach relies on IPv6 Provider Edge routers (6PE) which are Dual 43 Stack in order to connect to IPv6 islands and to the MPLS core which 44 is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 45 reachability information transparently over the core using the 46 Multi-Protocol Border Gateway Protocol (MP-BGP) over IPv4. In doing 47 so, the BGP Next Hop field is used to convey the IPv4 address of the 48 6PE router so that dynamically established IPv4-signaled MPLS Label 49 Switched Paths (LSPs) can be used without explicit tunnel 50 configuration. 52 Requirements 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [KEYWRD]. 58 1. Introduction 60 There are several approaches for providing IPv6 connectivity over an 61 MPLS core network [ISPSCEN] including (i) requiring that MPLS 62 networks support setting up IPv6-signaled LSPs and set up IPv6 63 connectivity by using those, (ii) use only configured tunneling over 64 IPv4-signaled LSPs, or (iii) use the IPv6 Provider Edge (6PE) 65 approach. 67 This document specifies operations of the 6PE approach for 68 interconnection of IPv6 islands over an IPv4 MPLS cloud. The approach 69 requires the edge routers that are connected to IPv6 islands to be 70 Dual Stack MP-BGP-speaking routers while the core routers are only 71 required to run IPv4 MPLS. The approach uses MP-BGP over IPv4, relies 72 on identification of the 6PE routers by their IPv4 address and uses 73 IPv4-signaled MPLS LSPs that don't require any explicit tunnel 74 configuration. 76 Throughout this document, the terminology of [IPV6] and [VPN] is 77 used. 79 In this document an 'IPv6 island' is a network running native IPv6 as 80 per [IPv6]. A typical example of an IPv6 island would be a customer's 81 IPv6 site connected via its IPv6 Customer Edge (CE) router to one (or 82 more) Dual Stack Provider Edge router(s) of a Service Provider. These 83 IPv6 Provider Edge routers (6PE) are connected to an IPv4 MPLS core 84 network. 86 +--------+ 87 |site A CE---+ +-----------------+ 88 +--------+ | | | +--------+ 89 6PE-+ IPv4 MPLS core +-6PE--CE site C | 90 +--------+ | | | +--------+ 91 |site B CE---+ +-----------------+ 92 +--------+ 94 IPv6 islands IPv4 cloud IPv6 island 95 <-------------><---------------------><--------------> 97 The interconnection method described in this document typically 98 applies to an ISP that has an IPv4 MPLS network and is familiar with 99 BGP (possibly already offering BGP/MPLS VPN services) and that wants 100 to offer IPv6 services to some of its customers. However, the ISP 101 may not (yet) want to upgrade its network core to IPv6 nor use only 102 IPv6-over-IPv4 tunnelling. With the 6PE approach described here, the 103 provider only has to upgrade some Provider Edge (PE) routers to Dual 104 Stack operations so they behave as 6PE routers (and route reflectors 105 if those are used for exchange of IPv6 reachability among 6PE 106 routers) while leaving the IPv4 MPLS core routers untouched. These 107 6PE routers provide connectivity to IPv6 islands. They may also 108 provide other services simultaneously (IPv4 connectivity, IPv4 L3VPN 109 services, L2VPN services, etc.). Also with the 6PE approach, no 110 tunnels need to be explicitly configured, and no IPv4 headers need to 111 be inserted in front of the IPv6 packets. 113 The ISP obtains IPv6 connectivity to its peers and upstreams using 114 means outside of the scope of this memo, and its 6PE routers 115 readvertise it over the IPv4 MPLS core with MP-BGP. 117 The interface between the edge router of the IPv6 island (Customer 118 Edge (CE) router) and the 6PE router is a native IPv6 interface which 119 can be physical or logical. A routing protocol (IGP or EGP) may run 120 between the CE router and the 6PE router for the distribution of IPv6 121 reachability information. Alternatively, static routes and/or a 122 default route may be used on the 6PE router and the CE router to 123 control reachability. An IPv6 island may connect to the provider 124 network over more than one interface. 126 The 6PE approach described in this document can be used for customers 127 that already have an IPv4 service from the network provider and 128 additionally require an IPv6 service, as well as for customers that 129 require only IPv6 connectivity. 131 The scenario is also described in [ISPSCEN]. 133 Note that the 6PE approach specified in this document provides global 134 IPv6 reachability. Support of IPv6 VPNs is not within the scope of 135 this document and is addressed in [V6VPN]. 137 2. Protocol Overview 139 Each IPv6 site is connected to at least one Provider Edge router that 140 is located on the border of the IPv4 MPLS cloud. We call such a 141 router a 6PE router. The 6PE router MUST be dual stack IPv4 and IPv6. 142 The 6PE router MUST be configurable with at least one IPv4 address on 143 the IPv4 side and at least one IPv6 address on the IPv6 side. The 144 configured IPv4 address needs to be routable in the IPv4 cloud, and 145 there needs to be a label bound via an IPv4 label distribution 146 protocol to this IPv4 route. 148 As a result of this, every considered 6PE router knows which MPLS 149 label to use to send packets to any other 6PE router. Note that an 150 MPLS network offering BGP/MPLS IP VPN services already fulfills these 151 requirements. 153 No extra routes need to be injected in the IPv4 cloud. 155 We call the 6PE router receiving IPv6 packets from an IPv6 site an 156 Ingress 6PE router (relative to these IPv6 packets). We call a 6PE 157 router forwarding IPv6 packets to an IPv6 site an Egress 6PE router 158 (relative to these IPv6 packets). 160 Interconnecting IPv6 islands over an IPv4 MPLS cloud takes place 161 through the following steps: 163 (1) Exchange IPv6 reachability information among 6PE routers with 164 MP-BGP [MP-BGP-v6]: 166 The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP 167 sessions as per [MP-BGP-v6] running over IPv4. The MP-BGP AFI used 168 MUST be IPv6 (value 2). In doing so, the 6PE routers convey their 169 IPv4 address as the BGP Next Hop for the advertised IPv6 prefixes. 170 Since MP-BGP assumes that the BGP Next Hop is of the same address 171 family as the NLRI, the IPv4 address needs to be embedded in an 172 IPv6 format. The IPv4-mapped IPv6 address is defined in [V6ADDR] 173 as an "address type used to represent the addresses of IPv4 nodes 174 as IPv6 addresses" which precisely fits the above purpose. 175 Therefore, the IPv4 address of the egress 6PE router MUST be 176 encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. 177 In addition, the 6PE MUST bind a label to the IPv6 prefix as per 178 [LABEL]. The SAFI used in MP-BGP MUST be the "label" SAFI (value 179 4) as defined in [LABEL]. Rationale for this and label allocation 180 policies are discussed in section 3. 182 (2) Transport IPv6 packets from Ingress 6PE router to Egress 6PE 183 router over IPv4-signaled LSPs: 185 The Ingress 6PE router MUST forward IPv6 data over the IPv4- 186 signaled LSP towards the Egress 6PE router identified by the IPv4 187 address advertised in the IPv4-mapped IPv6 address of the BGP Next 188 Hop for the corresponding IPv6 prefix. 190 As required by BGP specification, PE routers form a full peering mesh 191 unless Route Reflectors are used. 193 3. Transport over IPv4-signaled LSPs and IPv6 label binding 195 In this approach, the IPv4-mapped IPv6 addresses allow a 6PE router 196 that has to forward an IPv6 packet to automatically determine the 197 IPv4-signaled LSP to use for a particular IPv6 destination by looking 198 at the MP-BGP routing information. 200 The IPv4-signaled LSPs can be established using any existing 201 technique (LDP, RSVP-TE, ...). 203 When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than 204 successively prepend an IPv4 header and then perform label imposition 205 based on the IPv4 header, the ingress 6PE Router MUST directly 206 perform label imposition of the IPv6 header without prepending any 207 IPv4 header. The (outer) label imposed MUST correspond to the IPv4- 208 signaled LSP starting on the ingress 6PE Router and ending on the 209 egress 6PE Router. 211 While this approach could conceptually operate in some situations 212 using a single level of labels, there are significant advantages in 213 using a second level of labels which are bound to IPv6 prefixes via 214 MP-BGP advertisements in accordance with [LABEL]. 216 For instance, use of a second level label allows Penultimate Hop 217 Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the 218 egress 6PE router without any IPv6 capabilities/upgrade on the 219 penultimate router; this is because it still transmits MPLS packets 220 even after the PHP (instead of having to transmit IPv6 packets and 221 encapsulate them appropriately). 223 Also, an existing IPv4-signaled LSP which is using "IPv4 Explicit 224 NULL label" over the last hop (say because that LSP is already used 225 to transport IPv4 traffic with the Pipe Diff-Serv Tunneling Model as 226 defined in [MPLS-DS]) could not be used to carry IPv6 with a single 227 label since the "IPv4 Explicit NULL label" can not be used to carry 228 native IPv6 traffic (see [MPLS-STACK]), while it could be used to 229 carry labeled IPv6 traffic (see [EXP-NULL]). 231 This is why a second label is always used with the 6PE approach. 233 The label bound by MP-BGP to the IPv6 prefix indicates to the Egress 234 6PE Router that the packet is an IPv6 packet. This label advertised 235 by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value 236 which identifies an IPv6 routing context or outgoing interface to 237 send the packet to, or MAY be the IPv6 Explicit Null Label. An 238 Ingress 6PE Router MUST be able to accept any such advertised label. 240 4. Crossing Multiple IPv4 Autonomous Systems 242 This section discusses the case where two IPv6 islands are connected 243 to different Autonomous Systems. 245 Like in the case of multi-AS backbone operations for IPv4 VPNs 246 described in section 10 of [VPN], three main approaches can be 247 distinguished: 249 (a) EBGP redistribution of IPv6 routes from AS to neighboring AS 251 This approach is the equivalent for exchange of IPv6 routes to 252 procedure (a) described in section 10 of [VPN] for the exchange of 253 VPN-IPv4 routes. 255 In this approach, the 6PE routers use IBGP (according to [MP-BGP-v6] 256 and [LABEL] and as described in this document for the single-AS 257 situation) to redistribute labeled IPv6 routes either to an 258 Autonomous System Border Router (ASBR) 6PE router, or to a route 259 reflector of which an ASBR 6PE router is a client. The ASBR then uses 260 EBGP to redistribute the (non-labeled) IPv6 routes to an ASBR in 261 another AS, which in turn distributes them to the 6PE routers in that 262 AS as described earlier in this specification, or perhaps to another 263 ASBR which in turn distributes them etc. 265 There may be one, or multiple, ASBR interconnection(s) across any two 266 ASes. IPv6 needs to be activated on the inter-ASBR links and each 267 ASBR 6PE router has at least one IPv6 address on the interface to 268 that link. 270 No inter-AS LSPs are used. There is effectively a separate mesh of 271 LSPs across the 6PE routers within each AS. 273 In this approach, the ASBR exchanging IPv6 routes may peer over IPv6 274 or over IPv4. The exchange of IPv6 routes MUST be carried out as per 275 [MP-BGP-v6]. 277 Note that the peering ASBR in the neighboring AS to which the IPv6 278 routes were distributed with EBGP, should in its turn redistribute 279 these routes to the 6PEs in its AS using IBGP and encoding its own 280 IPv4 address as the IPv4-mapped IPv6 BGP Next Hop. 282 (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring 283 AS 285 This approach is the equivalent for exchange of IPv6 routes to 286 procedure (b) described in section 10 of [VPN] for the exchange of 287 VPN-IPv4 routes. 289 In this approach, the 6PE routers use IBGP (as described earlier in 290 this document for the single-AS situation) to redistribute labeled 291 IPv6 routes either to an Autonomous System Border Router (ASBR) 6PE 292 router, or to a route reflector of which an ASBR 6PE router is a 293 client. The ASBR then uses EBGP to redistribute the labeled IPv6 294 routes to an ASBR in another AS, which in turn distributes them to 295 the 6PE routers in that AS as described earlier in this 296 specification, or perhaps to another ASBR which in turn distributes 297 them etc. 299 There may be one, or multiple, ASBR interconnection(s) across any two 300 ASes. IPv6 may or may not be activated on the inter-ASBR links. 302 This approach requires that there be label switched paths established 303 across ASes. Hence the corresponding considerations described for 304 procedure (b) in section 10 of [VPN] apply equally to this approach 305 for IPv6. 307 In this approach, the ASBR exchanging IPv6 routes may peer over IPv4 308 or IPv6 (in which case, IPv6 obviously needs to be activated on the 309 inter-ASBR link). When peering over IPv6, the exchange of labeled 310 IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. When 311 peering over IPv4, the exchange of labeled IPv6 routes MUST be 312 carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 313 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next 314 Hop field. 316 (c) Multihop EBGP redistribution of labeled IPv6 routes between 317 source and destination ASes, with EBGP redistribution of labeled IPv4 318 routes from AS to neighboring AS. 320 This approach is the equivalent for exchange of IPv6 routes to 321 procedure (c) described in section 10 of [VPN] for exchange of VPN- 322 IPv4 routes. 324 In this approach, IPv6 routes are neither maintained nor distributed 325 by the ASBR routers. The ASBR routers need not be dual stack and may 326 be IPv4/MPLS-only routers. An ASBR needs to maintain labeled IPv4 /32 327 routes to the 6PE routers within its AS. It uses EBGP to distribute 328 these routes to other ASes. ASBRs in any transit ASes will also have 329 to use EBGP to pass along the labled IPv4 /32 routes. This results in 330 the creation of an IPv4 label switched path from the ingress 6PE 331 router to the egress 6PE router. Now 6PE routers in different ASes 332 can establish multi-hop EBGP connections to each other over IPv4, and 333 can exchange labeled IPv6 routes (with an IPv4-mapped IPv6 BGP Next 334 Hop) over those connections. 336 IPv6 need not be activated on the inter-ASBR links. 338 The considerations described for procedure (c) in section 10 of [VPN] 339 with respect to possible use of multi-hop EBGP connections via 340 route-reflectors in different ASes, as well as with respect to the 341 use of a third label in case the IPv4 /32 routes for the (6)PE 342 routers are NOT made known to the P routers, apply equally to this 343 approach for IPv6. 345 This approach requires that there be IPv4 label switched paths 346 established across the ASes leading form a packet's ingress 6PE 347 router to its egress 6PE router. Hence, the considerations described 348 for procedure (c) in section 10 of [VPN] with respect to LSPs 349 spanning multiple ASes apply equally to this approach for IPv6. 351 Note also that the exchange of IPv6 routes can only start after BGP 352 has created IPv4 connectivity between the ASes. 354 5. Security Considerations 356 The extensions defined in this document allow BGP to propagate 357 reachability information about IPv6 routes over an MPLS IPv4 core 358 network. As such, no new security issues are raised beyond those that 359 already exist in BGP-4 and use of MP-BGP for IPv6. 361 The security features of BGP and corresponding security policy 362 defined in the ISP domain are applicable. 364 For the inter-AS distribution of IPv6 routes according to case (a) of 365 section 4 of this document, no new security issues are raised beyond 366 those that already exist in the use of EBGP for IPv6 [MP-BGP-v6]. 368 For the inter-AS distribution of IPv6 routes according to case (b) 369 and (c) of section 4 of this document, the procedures require that 370 there be label switched paths established across the AS boundaries. 371 Hence the appropriate trust relationships must exist between and 372 among the set of ASes along the path. Care must be taken to avoid 373 "label spoofing". To this end an ASBR 6PE SHOULD only accept labeled 374 packets from its peer ASBR 6PE if the topmost label is a label that 375 it has explicitly signaled to that peer ASBR 6PE. 377 Note that for the inter-AS distribution of IPv6 routes according to 378 case (c) of section 4 of this document, label spoofing may be more 379 difficult to prevent. Indeed, the MPLS label distributed with the 380 IPv6 routes via multi-hop EBGP is directly sent from the egress 6PE 381 to ingress 6PEs in an other AS (or through route reflectors). This 382 label is advertised transparently through the AS boundaries. When the 383 egress 6PE that sent the labeled IPv6 routes receives a data packet 384 that has this particular label on top of its stack, it may not be 385 able to verify whether the label was pushed on the stack by an 386 ingress 6PE that is allowed to do so. As such one AS may be 387 vulnerable to label spoofing in a different AS. The same issue 388 equally applies to the option (c) of section 10 of [VPN]. Just like 389 it is the case for [VPN], addressing this particular security issue 390 is for further study. 392 IANA Considerations 394 This document has no actions for IANA. 396 Acknowledgements 398 We wish to thank Gerard Gastaud and Eric Levy-Abegnoli who 399 contributed to this document, and we wish to thank Tri T. Nguyen who 400 initiated this document, but who unfortunately passed away much too 401 soon. We also thank Pekka Savola for his valuable comments and 402 suggestions. 404 Normative References 406 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 407 (IPv6) Specification", RFC2460. 409 [KEYWRD] S. Bradner, Key words for use in RFCs to Indicate 410 Requirement Levels, RFC2119, March 1997. 412 [LABEL] Rekhter Y., E. Rosen, "Carrying Label Information in 413 BGP-4", RFC 3107, May 2001. 415 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiproto- 416 col Extensions for BGP-4", RFC 2858. 418 [MP-BGP-v6] Marques P., et al., "Use of BGP-4 Multiprotocol Exten- 419 sions for IPv6 Inter-Domain Routing", RFC 2545. 421 [V6ADDR] Deering, S., and R. Hinden, "IP Version 6 Addressing 422 Architecture", RFC 3513 424 [MPLS-STACK] Rosen E., et al., "MPLS Label Stack Encoding", RFC 3032. 426 Informative References 428 [ISPSCEN] Lind M., et al., "Scenarios and Analysis for Introducing 429 IPv6 into ISP Networks", draft-ietf-v6ops-isp- 430 scenarios-analysis, (work in progress) 432 [EXP-NULL] Rosen, E., et al., "Removing a Restriction on the use of 433 MPLS Explicit NULL", draft-rosen-mpls-explicit-null- 434 01.txt, work in progress 436 [MPLS-DS] Le Faucheur et al., "MPLS Support for DiffServ", RFC 437 3270 439 [V6VPN] De Clercq J., Ooms D., Carugi M., Le Faucheur F., "BGP- 440 MPLS VPN extension for IPv6 VPN over an IPv4 infrastruc- 441 ture", draft-ietf-l3vpn-bgp-ipv6 (work in progress). 443 [VPN] Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq 444 J., Hitchin P., Marshall , Srinivasan V., "BGP/MPLS 445 VPNs", draft-ietf-l3vpn-rfc2547bis (work in progress). 447 Authors' Addresses 449 Jeremy De Clercq 450 Alcatel 451 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 452 E-mail: jeremy.de_clercq@alcatel.be 454 Dirk Ooms 455 OneSparrow 456 Belegstraat 13, 2018 Antwerpen, Belgium 457 E-mail: dirk@onesparrow.com 459 Stuart Prevost 460 BTexact Technologies 461 Room 136 Polaris House, Adastral Park, 462 Martlesham Heath, Ipswich, Suffolk IP5 3RE, England 463 E-mail: stuart.prevost@bt.com 465 Francois Le Faucheur 466 Cisco Systems 467 Domaine Green Side, 400, Avenue de Roumanille, Batiment T3 468 06 410 BIOT, SOPHIA ANTIPOLIS, FRANCE 469 E-mail: flefauch@cisco.com 471 APPENDIX A 473 [RFC-editor note: remove before publication] 475 Changes 476 ngtrans history (draft-ietf-ngtrans-bgp-tunnel-0x.txt) 477 00->01: editorial changes 478 extended section 4 479 01->02: editorial changes 480 added tunnel-specific considerations 481 added case of multiple IPv4 domains between IPv6 islands 482 added discussion on v6[v4]addresses in appendix A 483 02->03: complete rewrite: it turned out that two interpretations 484 of the previous drafts existed, the two different 485 interpretations are described explicitly in this version 486 03->04: renaming of the two approaches 487 editorial changes 488 clearly indicate which part requires standards track 489 04->05: added 5.1.3 to clarify how DS-BGP routers agree on tunnel 490 type 492 v6ops history (draft-ooms-v6ops-bgp-tunnel-0x.txt) 493 05->00 individual submission: no changes. The document passed 494 ngtrans last call early 2002, but the transfer to the IESG 495 was postponed because of the reorg and closing down of 496 ngtrans. 497 00->01 no changes 498 01->02 according to v6ops mailing list discussion, the scope of 499 the document was restricted to the "MP-BGP over IPv4 using 500 LSPs" approach. 501 02->03 adopted various comments 502 03->04 clean-up of the requirements terminology 503 clarification of section 4 505 Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 Intellectual Property Rights or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; nor does it represent that it has 512 made any independent effort to identify any such rights. Information 513 on the procedures with respect to rights in RFC documents can be 514 found in BCP 78 and BCP 79. 516 Copies of IPR disclosures made to the IETF Secretariat and any 517 assurances of licenses to be made available, or the result of an 518 attempt made to obtain a general license or permission for the use of 519 such proprietary rights by implementors or users of this 520 specification can be obtained from the IETF on-line IPR repository at 521 http://www.ietf.org/ipr. 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights which may cover technology that may be required to practice 526 this standard. Please address the information to the IETF Executive 527 Director. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Full Copyright Statement 537 Copyright (C) The Internet Society (2004). This document is subject 538 to the rights, licences and restrictions contained in BCP 78 and 539 except as set forth therein, the authors retain all their rights. 541 This document and the information contained herein are provided on 542 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANISATION HE/SHE 543 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 544 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 545 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 546 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Acknowledgment 551 Funding for the RFC Editor function is currently provided by the 552 Internet Society.