6PE Implementation Report January 2006 Internet Draft Eric Levy-Abegnoli Francois Le Faucheur Cisco Systems, Inc. Rajiv Papneja Isocore draft-levy-idr-6pe-survey-00.txt Expires: May 2006 January 2006 Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) - Implementation Report - Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract [6PE] specifies a mechanism to interconnect IPv6 islands over an MPLS-enabled IPv4 cloud using the IPv6 Provider Edge routers (6PE) Levy, et al. [Page 1] 6PE Implementation Report January 2006 approach. The present document reports the results of an implementation survey for this mechanism. After a brief summary of the results, each survey response is listed. The document contains responses from the five implementers that completed the survey (Cisco Systems, Juniper Networks, Ixia, Agilent, Spirent). The document also reports some basic interoperability testing of 6PE implementations carried out by ISOCORE. No ambiguities or errors in the [6PE] specification which could compromise interoperability have been reported. Copyright Notice Copyright (C) The Internet Society (2006). 1. Implementation Survey Summary There are multiple implementations of the 6PE approach ([6PE]). An Implementation Survey questionnaire was issued asking for compliance to every "MUST", "SHOULD" and "MAY" statements of [6PE]. Responses to this survey were provided for two router implementations: - Cisco Systems - Juniper Networks as well as for three implementations on network test equipments: - Ixia - Agilent - Spirent. All the implementations comply with all the mandatory aspects of [6PE] ("MUST"). Implementations on test equipment also supports all (or all but one) of the optional aspects of [6PE] ("SHOULD"/"MAY"). The main difference between the two router implementations is on the strategy for allocating/advertising the inner label, where they use different options allowed by [6PE]. The Cisco implementation allocates and advertises an arbitrary label while the Juniper implementation uses IPv6 Explicit NULL label. However, the two implementations can still interoperate since they comply with the mandatory requirement of [6PE] to accept both forms of advertisement from a peer. Levy, et al. [Page 2] 6PE Implementation Report January 2006 The complete implementation survey response can be found in Section 2 for each implementation. Basic interoperability between multiple of these implementations (Cisco Systems, Juniper Networks and Ixia) has been successfully tested as part of an ISOCORE interop event. A summary of this interoperability testing is provided in Section 3. This implementation survey brought to light the fact that while case (b) of inter-AS operations (defined in section 4 of [6PE]) is applicable when arbitrary labels are used by the 6PE implementation, case (b) is not applicable in the case where the 6PE implementation uses Explicit-Null label. This is because in that case, it does not result in the use of inter-AS LSPs from ingress 6PE to egress 6PE allowing label switching at every hop including ASBRs. Rather, it results in IPv6 lookup and IPv6 forwarding at the ASBRs. The authors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. 2. Survey Responses 2.1. Cisco Systems Organization: Cisco Systems Identification of Implementation: IOS software 12.0S(22), 12.2S, 12.2T and higher Person filling out this form: Eric Levy-Abegnoli Survey Response: Protocol Overview: " The 6PE router MUST be dual stack IPv4 and IPv6. " ==> Does your implementation comply?: Y " The 6PE router MUST be configurable with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. " ==> Does your implementation comply?: Y Levy, et al. [Page 3] 6PE Implementation Report January 2006 " The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [MP-BGP-v6] running over IPv4. " ==> Does your implementation comply?: Y " The MP-BGP AFI used MUST be IPv6 (value 2). " ==> Does your implementation comply?: Y " Therefore, the IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y " In addition, the 6PE MUST bind a label to the IPv6 prefix as per [LABEL]. " ==> Does your implementation comply?: Y " The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [LABEL]. " ==> Does your implementation comply?: Y " The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the Egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix. " ==> Does your implementation comply?: Y Transport over IPv4-signaled LSPs and IPv6 label binding: " When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. " ==> Does your implementation comply?: Y " The (outer) label imposed MUST correspond to the IPv4-signaled LSP Levy, et al. [Page 4] 6PE Implementation Report January 2006 starting on the ingress 6PE Router and ending on the egress 6PE Router. " ==> Does your implementation comply?: Y " This label advertised by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. " ==> Does your implementation comply and advertise an "arbitrary label value"?: Y ==> Does your implementation comply and advertise "IPv6 Explicit Null Label"?: N " An Ingress 6PE Router MUST be able to accept any such advertised label. " ==> Does your implementation comply and accept an "arbitrary label value"?: Y ==> Does your implementation comply and accept "IPv6 Explicit Null Label"?: Y Crossing Multiple IPv4 Autonomous Systems: " (a) EBGP redistribution of IPv6 routes from AS to neighboring AS. The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6]. " ==> Does your implementation support (a)?: Y ==> If yes, does it comply?: Y " (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS. When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. " ==> Does your implementation support (b)?: Y ==> If yes, does it comply?: Y " When peering over IPv4, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y Levy, et al. [Page 5] 6PE Implementation Report January 2006 Security Considerations: " To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE. " ==> Does your implementation comply?: N (under development) 2.2. Juniper Networks Organization: Juniper Networks Identification of Implementation: JunOS software release 7.4 Person filling out this form: Pedro Roque Marques Survey Response: Protocol Overview: " The 6PE router MUST be dual stack IPv4 and IPv6. " ==> Does your implementation comply?: Y/N Yes. " The 6PE router MUST be configurable with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. " ==> Does your implementation comply?: Y/N Yes. " The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [MP-BGP-v6] running over IPv4. " ==> Does your implementation comply?: Y/N Yes. " The MP-BGP AFI used MUST be IPv6 (value 2). " ==> Does your implementation comply?: Y/N Yes. Levy, et al. [Page 6] 6PE Implementation Report January 2006 " Therefore, the IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y " In addition, the 6PE MUST bind a label to the IPv6 prefix as per [LABEL]. " ==> Does your implementation comply?: Y " The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [LABEL]. " ==> Does your implementation comply?: Y " The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the Egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix. " ==> Does your implementation comply?: Y Transport over IPv4-signaled LSPs and IPv6 label binding: " When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. " ==> Does your implementation comply?: Y " The (outer) label imposed MUST correspond to the IPv4-signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router. " ==> Does your implementation comply?: Y " This label advertised by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. " Levy, et al. [Page 7] 6PE Implementation Report January 2006 ==> Does your implementation comply and advertise an "arbitrary label value"?: N ==> Does your implementation comply and advertise "IPv6 Explicit Null Label"?: Y " An Ingress 6PE Router MUST be able to accept any such advertised label. " ==> Does your implementation comply and accept an "arbitrary label value"?: Y ==> Does your implementation comply and accept "IPv6 Explicit Null Label"?: Y Crossing Multiple IPv4 Autonomous Systems: " (a) EBGP redistribution of IPv6 routes from AS to neighboring AS The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6]. " ==> Does your implementation support (a)?: Y ==> If yes, does it comply?: Y " (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS. When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. " ==> Does your implementation support (b)?: It supports explicit-null only under afi,safi (2,4) both on iBGP and eBGP sessions. However since it doesn't support advertising an "arbitrary label" it isn't able to perform a mpls forwarding decision on an ASBR, which is what is implied by the reference to 2547 10 b) model. ==> If yes, does it comply?: It is a matter of opinion. " When peering over IPv4, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y Security Considerations: Levy, et al. [Page 8] 6PE Implementation Report January 2006 " To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE. " ==> Does your implementation comply?: Given that only explicit-null is used, Yes. 2.3. Ixia Organization: Ixia Identification of Implementation: IxRouter 4.10. Person filling out this form: Dean Lee Survey Response: Protocol Overview: " The 6PE router MUST be dual stack IPv4 and IPv6. " ==> Does your implementation comply?: Y " The 6PE router MUST be configurable with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. " ==> Does your implementation comply?: Y " The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [MP-BGP-v6] running over IPv4. " ==> Does your implementation comply?: Y " The MP-BGP AFI used MUST be IPv6 (value 2). " ==> Does your implementation comply?: Y " Therefore, the IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. " Levy, et al. [Page 9] 6PE Implementation Report January 2006 ==> Does your implementation comply?: Y " In addition, the 6PE MUST bind a label to the IPv6 prefix as per [LABEL]. " ==> Does your implementation comply?: Y " The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [LABEL]. " ==> Does your implementation comply?: Y " The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the Egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix. " ==> Does your implementation comply?: Y Transport over IPv4-signaled LSPs and IPv6 label binding: " When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. " ==> Does your implementation comply?: Y " The (outer) label imposed MUST correspond to the IPv4-signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router. " ==> Does your implementation comply?: Y " This label advertised by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. " ==> Does your implementation comply and advertise an "arbitrary label value"?: Y ==> Does your implementation comply and advertise "IPv6 Explicit Null Label"?: Y Levy, et al. [Page 10] 6PE Implementation Report January 2006 " An Ingress 6PE Router MUST be able to accept any such advertised label. " ==> Does your implementation comply and accept an "arbitrary label value"?: Y ==> Does your implementation comply and accept "IPv6 Explicit Null Label"?: Y Crossing Multiple IPv4 Autonomous Systems: " (a) EBGP redistribution of IPv6 routes from AS to neighboring AS. The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6]. " ==> Does your implementation support (a)?: Y ==> If yes, does it comply?: Y " (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS. When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. " ==> Does your implementation support (b)?: Y ==> If yes, does it comply?: Y " When peering over IPv4, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y Security Considerations: " To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE. " ==> Does your implementation comply?: Y 2.4. Agilent Organization: Agilent Levy, et al. [Page 11] 6PE Implementation Report January 2006 Identification of Implementation: Agilent N2X v6.6 Person filling out this form: Martin Lai Survey Response: Protocol Overview: " The 6PE router MUST be dual stack IPv4 and IPv6. " ==> Does your implementation comply?: Y " The 6PE router MUST be configurable with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. " ==> Does your implementation comply?: Y " The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [MP-BGP-v6] running over IPv4. " ==> Does your implementation comply?: Y " The MP-BGP AFI used MUST be IPv6 (value 2). " ==> Does your implementation comply?: Y " Therefore, the IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y " In addition, the 6PE MUST bind a label to the IPv6 prefix as per [LABEL]. " ==> Does your implementation comply?: Y " The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [LABEL]. " ==> Does your implementation comply?: Y Levy, et al. [Page 12] 6PE Implementation Report January 2006 " The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the Egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix. " ==> Does your implementation comply?: Y Transport over IPv4-signaled LSPs and IPv6 label binding: " When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. " ==> Does your implementation comply?: Y " The (outer) label imposed MUST correspond to the IPv4-signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router. " ==> Does your implementation comply?: Y " This label advertised by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. " ==> Does your implementation comply and advertise an "arbitrary label value"?: Y ==> Does your implementation comply and advertise "IPv6 Explicit Null Label"?: Y " An Ingress 6PE Router MUST be able to accept any such advertised label. " ==> Does your implementation comply and accept an "arbitrary label value"?: Y ==> Does your implementation comply and accept "IPv6 Explicit Null Label"?: Y Crossing Multiple IPv4 Autonomous Systems: " (a) EBGP redistribution of IPv6 routes from AS to neighboring AS. The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6]. Levy, et al. [Page 13] 6PE Implementation Report January 2006 " ==> Does your implementation support (a)?: Y ==> If yes, does it comply?: Y " (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS. When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. " ==> Does your implementation support (b)?: Y ==> If yes, does it comply?: Y " When peering over IPv4, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Y Security Considerations: " To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE. " ==> Does your implementation comply?: N 2.5. Spirent Organization: Spirent Identification of Implementation: For Ax/4000 : v4.73 Person filling out this form: Floyd Cash Chris McCoy Survey Response: Protocol Overview: " The 6PE router MUST be dual stack IPv4 and IPv6. " ==> Does your implementation comply?: Yes However being test equipment we don't forward Levy, et al. [Page 14] 6PE Implementation Report January 2006 " The 6PE router MUST be configurable with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side. " ==> Does your implementation comply?: Yes " The 6PE routers MUST exchange the IPv6 prefixes over MP-BGP sessions as per [MP-BGP-v6] running over IPv4. " ==> Does your implementation comply?: Yes " The MP-BGP AFI used MUST be IPv6 (value 2). " ==> Does your implementation comply?: Yes " Therefore, the IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Yes " In addition, the 6PE MUST bind a label to the IPv6 prefix as per [LABEL]. " ==> Does your implementation comply?: Yes " The SAFI used in MP-BGP MUST be the "label" SAFI (value 4) as defined in [LABEL]. " ==> Does your implementation comply?: Yes " The Ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the Egress 6PE router identified by the IPv4 address advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for the corresponding IPv6 prefix. " ==> Does your implementation comply?: Yes, you may create tunnels Transport over IPv4-signaled LSPs and IPv6 label binding: " When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than successively prepend an IPv4 header and then perform label imposition Levy, et al. [Page 15] 6PE Implementation Report January 2006 based on the IPv4 header, the ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header. " ==> Does your implementation comply?: Yes, these packets may be created or simulated " The (outer) label imposed MUST correspond to the IPv4-signaled LSP starting on the ingress 6PE Router and ending on the egress 6PE Router. " ==> Does your implementation comply?: Yes, done manually " This label advertised by the Egress 6PE Router with MP-BGP MAY be an arbitrary label value which identifies an IPv6 routing context or outgoing interface to send the packet to, or MAY be the IPv6 Explicit Null Label. " ==> Does your implementation comply and advertise an "arbitrary label value"?: Yes, this is possible it may be different for each prefix ==> Does your implementation comply and advertise "IPv6 Explicit Null Label"?: Yes, the value may be any fixed value. " An Ingress 6PE Router MUST be able to accept any such advertised label. " ==> Does your implementation comply and accept an "arbitrary label value"?: Yes ==> Does your implementation comply and accept "IPv6 Explicit Null Label"?: Yes Crossing Multiple IPv4 Autonomous Systems: " (a) EBGP redistribution of IPv6 routes from AS to neighboring AS The exchange of IPv6 routes MUST be carried out as per [MP-BGP-v6]. " ==> Does your implementation support (a)?: Yes ==> If yes, does it comply?: Yes, Routes are not redistributed but routes may be added and advertised which simulate behavior " (b) EBGP redistribution of labeled IPv6 routes from AS to neighboring AS When peering over IPv6, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL]. " Levy, et al. [Page 16] 6PE Implementation Report January 2006 ==> Does your implementation support (b)?: Yes ==> If yes, does it comply?: Y/N Yes, Routes are not redistributed but routes may be added and advertised which simulate behavior " When peering over IPv4, the exchange of labeled IPv6 routes MUST be carried out as per [MP-BGP-v6] and [LABEL] with encoding of the IPv4 address of the ASBR as an IPv4-mapped IPv6 address in the BGP Next Hop field. " ==> Does your implementation comply?: Yes, Routes are not redistributed but routes may be added and advertised which simulate behavior Security Considerations: " To this end an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is a label that it has explicitly signaled to that peer ASBR 6PE. " ==> Does your implementation comply?: N/A 3. Interoperability Testing This section provides a summary of the basic 6PE interoperability testing carried out as part of ISOCORE testing efforts during the year 2005. The interoperability tests focused on CE-6PE-P-6PE-CE topologies. Basic interoperability was tested across different 6PE implementations in this topology. IPv6 CEs were emulated by network test equipment (e.g. IPv6 forwarding and traffic generation, OSPFv3/RIPng enabled on PE-CE). The areas that have been successfully evaluated include: - Verifying the capability of the dual stack routers (i.e. IPv6 and IPv4 stack) to exchange the IPv6 reachability information with labels in MP-BGP advertising a v4-mapped IPv6 nexthop address, and - Successfully forwarding the native IPv6 packets on the corresponding IPv4 signaled MPLS based Label Switched Paths with imposition of the two-level MPLS label stack, including the inner label advertised in MP-BGP for the IPv6 prefix. Such functionality was successfully validated between the two router Levy, et al. [Page 17] 6PE Implementation Report January 2006 implementations (Cisco Systems and Juniper Networks) as well as between the router implementations and the network test implementations (Ixia, Agilent, Spirent). During these tests, operation was validated both where the IPv4 LSPs were signaled using LDP and where the LSPs were signaled using RSVP- TE. [6PE] allows different options in terms of strategy for allocating/advertising the inner label. For example, the Cisco implementation allocates and advertises an arbitrary label while the Juniper implementation uses Explicit Null. Tests confirmed that this does not compromise interoperability of 6PE implementations as long as those comply with the mandatory requirement of [6PE] to accept both forms of advertisement from a peer. As of writing of this implementation report, inter-provider scenarios had not yet been tested in an interoperable environment at ISOCORE Internetworking lab; additional testing efforts are scheduled to verify this capability. So far, no ambiguities or errors in the [6PE] specification which could compromise interoperability have been identified during the interoperability testing. However, more tests are needed to be performed to confirm this observation for the whole scope of the specification. 4. Security Considerations Security considerations for 6PE are discussed in [6PE]. 5. IANA Considerations This document has no actions for IANA. 6. Normative References [6PE] "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", J Declerq et al, draft-ooms-v6ops-bgp-tunnel-xx.txt (work in progress) 7. Authors Address: Eric Levy-Abegnoly Cisco Systems, Inc. Levy, et al. [Page 18] 6PE Implementation Report January 2006 Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France Email: elevyabe@cisco.com Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot Sophia-Antipolis France Email: flefauch@cisco.com Rajiv Papneja ISOCORE 12359 Sunrise Valley Drive, STE 100 Reston, VA 20190 USA Email: rpapneja@isocore.com 8. IPR Statements The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 9. Disclaimer of Validity Levy, et al. [Page 19] 6PE Implementation Report January 2006 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Levy, et al. [Page 20]