L3VPN Working Group Rahul Aggarwal
Internet Draft Juniper Networks, Inc.
Intended Status: Proposed Standard
Expires: May 8, 2011 Eric C. Rosen
Cisco Systems, Inc.
November 8, 2010
IPv4 and IPv6 Infrastructure Addresses in MCAST-VPN Routes
draft-ietf-l3vpn-mvpn-infra-addrs-01.txt
Abstract
To provide Multicast VPN service, a provider edge router originates
Multicast-VPN ("MCAST-VPN") BGP routes. These routes encode
addresses from the customer's address space as well as addresses from
the provider's address space. The customer's address space may be
either IPv4 or IPv6. Independently, the provider's address space may
be either IPv4 or IPv6. The MCAST-VPN BGP routes always contain an
"address family" field that specifies whether the customer addresses
are IPv4 addresses or whether they are IPv6 addresses. However,
there is no field that explicitly specifies whether the provider
addresses are IPv4 addresses or whether they are IPv6 addresses. To
ensure interoperability, this document specifies that MCAST-VPN
routes always encode provider IPv4 addresses as four-octet addresses,
and that the distinction between an IPv4 address and an IPv6 address
is signaled solely by the length of the address field.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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."
Raggarwa & Rosen [Page 1]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
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.
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Specification of requirements ......................... 3
2 Acronyms Used in this Document ........................ 3
3 Introduction .......................................... 3
4 PE Addresses in MCAST-VPN Routes ...................... 4
5 PMSI Tunnel Attributes in I-PMSI A-D Routes ........... 6
5.1 Relationship to AFI Value ............................. 6
5.2 Relationship to Next Hop Address Family ............... 6
6 IANA Considerations ................................... 7
7 Security Considerations ............................... 7
8 Acknowledgments ....................................... 7
9 Authors' Addresses .................................... 7
10 Normative References .................................. 7
11 Informational References .............................. 8
Raggarwa & Rosen [Page 2]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Acronyms Used in this Document
This document uses a number of acronyms, mostly taken directly from
the BGP and VPN specifications.
- A-D Route: Auto-Discovery Route [MVPN]
- AFI: Address Family Identifier [BGP-MP]
- I-PMSI: Inclusive PMSI [RFC4364]
- MCAST-VPN: Multicast Virtual Private Network [MVPN-BGP]
- MP_REACH_NLRI: Multiprotocol Reachable NLRI [BGP-MP]
- MP_UNREACH_NLRI; Multiprotocol Unreachable NLRI [BGP-MP]
- PMSI: Provider Multicast Service Interface [MVPN]
- NLRI: Network Layer Reachability Information [BGP]
- PE: Provider Edge [RFC4364]
- S-PMSI: Selective PMSI [RFC4364]
- SAFI: Subsequent Address Field Identifier [BGP-MP]
- SP: Service Provider
3. Introduction
[MVPN-BGP] defines a new set of BGP route types that are used by SPs
to provide Multicast Virtual Private Network service to their
customers. These routes have a newly defined BGP NLRI, the "MCAST-
VPN" NLRI. MCAST-VPN NLRI is carried in the NLRI field of the
MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP]. The
SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
identify the NLRI as being an MCAST-VPN NLRI.
When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
Raggarwa & Rosen [Page 3]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
AFI 1 indicates that any customer multicast addresses occurring in
the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
indicates that any such addresses are IPv6 addresses.
However, some of the MCAST-VPN routes also contain addresses of PE
routers in the SP network. An SP with an IPv4 network may provide
MVPN service for customers that use IPv6, and an SP with an IPv6
network may provide MVPN service for customers that use IPv4.
Therefore the address family of the PE addresses MUST NOT be inferred
from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
attribute.
The purpose of this document is to make it clear that whenever a PE
address occurs in an MCAST-VPN route (whether in the NLRI or in an
attribute), the IP address family of that address is determined by
the length of the address (a length of 4 octets for IPv4 addresses, a
length of 16 octets for IPv6 addresses), NOT by the AFI field of the
route.
In particular, if a SP with an IPv4 core network is providing
MVPN/IPv6 service to a customer, the PE addresses in the MCAST-VPN
routes will be four-octet IPv4 routes, even though the AFI of those
routes will have the value 2.
Some previous specifications (e.g., [RFC4659] and [RFC4798]) have
taken a different approach, requiring that in any routes containing
IPv6 or VPN-IPv6 customer addresses, the IPv4 PE addresses be
represented as IPv6-mapped IPv4 addresses [RFC4291]. This document
does not use that approach. Rather, this specification uses the
approach adopted in [RFC4684] and [RFC5549]. The MCAST-VPN routes
contain enough information to enable the IP address family of the PE
addresses to be inferred from the address lengths.
4. PE Addresses in MCAST-VPN Routes
PE addresses occur in MCAST-VPN routes in the following places:
1. "Network Address of Next Hop" field in the MP_REACH_NLRI
attribute, as defined in section 3 of [BGP-MP]. This field is
preceded by a "length of next hop address" field. Hence it is
always clear whether the address is an IPv4 address (length is
4) or an IPv6 address (length is 16). If the length of next
hop address is neither 4 nor 16, the MP_REACH_NLRI attribute
MUST be considered to be "incorrect", and MUST be handled as
specified in section 7 of [BGP-MP].
Raggarwa & Rosen [Page 4]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
2. "Intra-AS I-PMSI A-D route". All MCAST-VPN routes begin with a
one-octet route type field, followed by a one-octet "NLRI
length" field. In the Intra-AS I-PMSI A-D route, the length is
followed by an 8-octet RD, which is then followed by the
"Originating Router's IP Address" field. The length of this
field (4 octets for IPv4 or 16 octets for IPv6 can thus be
inferred from the NLRI length field (which will be either 12 or
24, respectively). If the inferred length of the "Originating
Router's IP Address" field is neither 4 nor 16, the
MP_REACH_NLRI attribute MUST be considered to be "incorrect",
and MUST be handled as specified in section 7 of [BGP-MP].
3. "S-PMSI A-D Route". In this route, the "NLRI length" field is
followed by an 8-octet RD, a variable length "multicast source"
field, a variable length "multicast group" field, and an
"Originating Router's IP Address" field. The two variable
length fields have their own length fields. From these two
length fields and the NLRI length field, one can compute the
length of the "Originating Router's IP Address" field, which
again is either 4 for IPv4 or 16 for IPv6. If the computed
length of the "Originating Router's IP Address" field is
neither 4 nor 16, the MP_REACH_NLRI attribute MUST be
considered to be "incorrect", and MUST be handled as specified
in section 7 of [BGP-MP].
4. "Leaf A-D Route". In this route, the "NLRI length" field is
following by a variable length "route key", which is followed
by the "Originating Router's IP Address" field. The Route Key
has its own length field. From the NLRI length and the route
key length, one can compute the length of the "Originating
Router's IP Address" field. If the computed length of the
"Originating Router's IP Address" field is neither 4 nor 16,
the MP_REACH_NLRI attribute MUST be considered to be
"incorrect", and MUST be handled as specified in section 7 of
[BGP-MP].
5. "VRF Route Import Extended Community". The "VRF Route Import
Extended Community", as specified in [MVPN-BGP], can only carry
an IPv4 address. To carry an IPv6 address, the "IPv6 Address
Specific Route Target" as specified in [RFC5701] MUST be used.
Raggarwa & Rosen [Page 5]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
5. PMSI Tunnel Attributes in I-PMSI A-D Routes
When a PMSI Tunnel Attribute occurs in an I-PMSI A-D route originated
by a particular PE or ASBR, it identifies a tunnel that the PE/ASBR
uses by default for carrying the multicast traffic of a particular
customer MVPN. The proper encoding and interpretation of the PMSI
Tunnel attribute is affected by both the AFI and "Network Address of
Next Hop" fields.
5.1. Relationship to AFI Value
When the PMSI Tunnel Attribute occurs in a BGP Update message with a
MP_REACH_NLRI attribute whose AFI is 1, the meaning is that the
identified tunnel is used by default to carry IPv4 MVPN traffic for a
particular customer MVPN. When the PMSI Tunnel Attribute occurs in a
BGP Update message with a MP_REACH_NLRI attribute whose AFI is 2, the
meaning is that the identified tunnel is used by default to carry
IPv6 MVPN traffic for a particular customer MVPN. To assign both
IPv4 and IPv6 MVPN traffic to an I-PMSI tunnel, two I-PMSI A-D routes
MUST be used, one whose MP_REACH_NLRI has an AFI of 1, and one whose
MP_REACH_NLRI has an AFI of 2. To use the same tunnel for both IPv4
and IPv6 traffic, the same value of the PMSI Tunnel attribute can be
used in each route.
5.2. Relationship to Next Hop Address Family
If the "Network Address of Next Hop" field in the MP_REACH_NLRI
attribute contains an IPv4 address, then any IP addresses appearing
in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be
IPv4 addresses.
If the "Network Address of Next Hop" field in the MP_REACH_NLRI
attribute contains an IPv6 address, then any IP addresses appearing
in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be
IPv6 addresses.
If these conditions are not met, the PMSI Tunnel Attribute MUST be
handled as a "malformed" PMSI Tunnel Attribute, as specified in
section 5 [MVPN-BGP].
Raggarwa & Rosen [Page 6]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
This document does not raise any security considerations beyond those
raised by [MVPN-BGP].
8. Acknowledgments
The authors wish to thank Dongling Duan, Yakov Rekhter, and Karthik
Subramanian.
9. Authors' Addresses
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
10. Normative References
[BGP] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4
(BGP-4)", Y. Rekhter, T. Li, S. Hares, RFC 4271, January 2006
[BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra,
D. Katz, Y. Rekhter, RFC 4760, January 2007
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010
[MVPN-BGP], "BGP Encodings and Procedures for Multicast in MPLS/BGP
Raggarwa & Rosen [Page 7]
Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-01.txt November 2010
IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter,
draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, October 2009
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997
11. Informational References
[RFC4291] "IP Version 6 Addressing Architecture", R. Hinden, S.
Deering, RFC 4291, February 2006.
[RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", E. Rosen, Y.
Rekhter, RFC4364, February 2006
[RFC4659] "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. RFC
4659, September 2006
[RFC4798] "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
Edge Routers (6PE)", J. De Clercq, D. Ooms, S. Prevost, F. Le
Faucheur. RFC 4798, February 2007
[RFC4684] "Constrained Route Distribution for Border Gateway
Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
(IP) Virtual Private Networks (VPNs)", P. Marques, R. Bonica, L.
Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. RFC 4684 November
2006
[RFC5549] "Advertising IPv4 Network Layer Reachability Information
with an IPv6 Next Hop" F. Le Faucheur, E. Rosen. RFC 5549, May 2009
[RFC5701] "IPv6 Address Specific BGP Extended Community Attribute" Y.
Rekhter. RFC 5701, November 2009
Raggarwa & Rosen [Page 8]
