[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-rosen-l3vpn-mvpn-infra-addrs) 00 01 02 03 04 05 RFC 6515

Network Working Group                                     Rahul Aggarwal
Internet Draft                                    Juniper Networks, Inc.
Intended Status: Proposed Standard
Expires: February 17, 2011                                 Eric C. Rosen
                                                     Cisco Systems, Inc.

                                                         August 17, 2010


       IPv4 and IPv6 Infrastructure Addresses in MCAST-VPN Routes


                draft-ietf-l3vpn-mvpn-infra-addrs-00.txt

Abstract

   To provide Multicast VPN service, a provider edge router originates
   "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.  The existing
   specifications do not explicitly say how to determine whether a given
   provider address is IPv4 or IPv6, and there are differing precedents
   about the method used to encode IPv4 addresses in messages that also
   contain IPv6 addresses.  This document removes any ambiguity by
   specifying 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



Raggarwa & Rosen                                                [Page 1]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 2010


   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.


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          Introduction  ..........................................   3
 3          PE Addresses in MCAST-VPN Routes  ......................   4
 4          PMSI Tunnel Attributes in I-PMSI A-D Routes  ...........   5
 4.1        Relationship to AFI Value  .............................   5
 4.2        Relationship to Next Hop Address Family  ...............   5
 5          IANA Considerations  ...................................   6
 6          Security Considerations  ...............................   6
 7          Acknowledgments  .......................................   6
 8          Authors' Addresses  ....................................   6
 9          Normative References  ..................................   7
10          Informational References  ..............................   7







Raggarwa & Rosen                                                [Page 2]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 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. Introduction

   [MVPN-BGP] defines a new set of BGP route types that are used by
   Service Providers (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
   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
   Provider Edge (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.  This document does not
   use that approach.  Rather, this specification uses the approach



Raggarwa & Rosen                                                [Page 3]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 2010


   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.


3. 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].

      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



Raggarwa & Rosen                                                [Page 4]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 2010


         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.


4. 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.


4.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.


4.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



Raggarwa & Rosen                                                [Page 5]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 2010


   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].



5. IANA Considerations

   This document has no actions for IANA.



6. Security Considerations

   This document does not raise any security considerations beyond those
   raised by [MVPN-BGP].


7. Acknowledgments

   The authors wish to thank Dongling Duan, Yakov Rekhter, and Karthik
   Subramanian.


8. 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










Raggarwa & Rosen                                                [Page 6]

Internet Draft  draft-ietf-l3vpn-mvpn-infra-addrs-00.txt     August 2010


9. Normative References

   [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra,
   D. Katz, Y. Rekhter, RFC 4760, January 2007

   [MVPN-BGP], "BGP Encodings and Procedures for Multicast in MPLS/BGP
   IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter,
   30-Sep-09, draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997


10. Informational References

   [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 7]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/