Internet DRAFT - draft-levy-idr-6pe-survey
draft-levy-idr-6pe-survey
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 <elevyabe@cisco.com>
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 <roque@juniper.net>
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 <mailto:dlee@ixiacom.com>
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 <mlai@agilent.com>
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 <Floyd.Cash@spirentcom.com>
Chris McCoy <Chris.McCoy@spirentcom.com>
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]
