Network Working Group                                          F. Parent
Internet-Draft                                                  Viagenie
Expires: July 10, 2002                                   January 9, 2002


        RPSL extensions for IPv6 and Multicast Routing Policies
                 draft-parent-multiprotocol-rpsl-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on July 10, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the definitions and extensions required in
   RPSL [1] in order to be able to define IPv6 and multicast routing
   policies.  Defining RPSL for IPv6 is an important step to build an
   IPv6 Internet Routing Registry.











Parent                    Expires July 10, 2002                 [Page 1]


Internet-Draft                   RPSLng                     January 2002


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Using new address families in RPSL objects . . . . . . . . . .  3
   2.1 route class  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2 route-set class  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.3 peering-set class  . . . . . . . . . . . . . . . . . . . . . .  5
   2.4 aut-num  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.5 inet-rtr . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.6 filter-set . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Security considerations  . . . . . . . . . . . . . . . . . . .  8
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  9




































Parent                    Expires July 10, 2002                 [Page 2]


Internet-Draft                   RPSLng                     January 2002


1. Introduction

   This draft documents the required information and extensions in RPSL
   to be able to specify an IPv6 and multicast routing policy.

   This document assumes that it is not required to build a seperate
   Internet Routing Registry (IRR) infrastructure from the existing IPv4
   IRR.  Extensions to existing RPSL object are introduced to allow the
   definitions of IPv6 and multicast routing policies.

   It should be noted that work is underway in the RIPE RPSLng task
   force to investigate and define extensions to RPSL to include IPv6
   and IPv4/IPv6 multicast.  This document will be evolving within the
   work currently underway in this area.

   RFC 2622 [1] defines RPSL using IPv4 prefixes and addresses.
   Fortunately, RPSL was defined to be extensible such that new features
   can be added.  Section 10 in RFC 2622 provides guidelines for
   extending RPSL, such as adding a new routing protocol or new features
   to the existing protocols.

   This document describes the usage of IPv6 and multicast addresses in
   RPSL routing policies.  This has an impact on many classes, most
   notably in the aut-num class.  This proposal tries to minimize the
   number of new classes and attributes, and be as generic as possible.
   The changes proposed will not be limited to support IPv6 and
   multicast, but can later be used to support new address families.

2. Using new address families in RPSL objects

   Section 2 in RFC 2622 [1]defines the usage of IPv4 unicast addresses
   and prefixes in RPSL.  This document introduces IPv6 addresses and
   prefixes in RPSL.  The textual representation of an IPv6 address or
   prefix in RPSL attributes should follow the syntax described in
   section 2.2 of RFC2373 [2].

   The new address families introduced in RPSL need to be identified
   such that they can be unambiguously used in the correct context by
   some tools.  Currently, all IP addresses in RPSL objects are assumed
   to be IPv4 unicast addresses.

   A new syntax is introduced to specify an IP address inside an RPSL
   attribute:

           [afi <address-family>] <address-prefix>
           where:
           <address-family> = enum[ipv4, ipv6, ipv4-multicast,
ipv6-multicast]




Parent                    Expires July 10, 2002                 [Page 3]


Internet-Draft                   RPSLng                     January 2002


   (TBD: use RPSL dictionary style)

   The optional "afi" syntax identifies the address family.  If this
   keyword is missing, ipv4 (unicast) is assumed such that the previous
   RPSL syntax is still valid.  For IPv6 addresses, the "afi ipv6"
   keywords can be optional since the new software and tools can be
   expected to be able to differentiate between IPv4 and IPv6 addresses.
   This will make IPv6 less tedious to use.

2.1 route class

   Using the new address syntax, a route object is extended as follows:

   route: [afi <address-family>] <address-prefix>

   The following two route objects represent the same thing:

   route: 10.0.0.0/8
   origin: AS1


   route: afi ipv4 10.0.0.0/6
   origin: AS1

   An IPv6 route object would be represented as follows:

   route: afi ipv6 3ffe:ffff::/28
   origin: AS1


2.2 route-set class

   route-set: RS-peer1
   members: [afi <address-family>] <address-prefix>


   route-set: ipv6-martians
   members: afi ipv6 ff00::/8
   members: afi ipv6 fe80::/10
   members: afi ipv6 fec0::/10
   members: afi ipv6 ::/96

   Making the "afi ipv6" optional for ipv6 unicast addresses, the route-
   set can be simplified as follows:







Parent                    Expires July 10, 2002                 [Page 4]


Internet-Draft                   RPSLng                     January 2002


   route-set: ipv6-martians
   members: ff00::/8
   members: fe80::/10
   members: fec0::/10
   members: ::/96

   The new syntax allows mixed address families within the same route-
   set.  This enables an autonomous system to specify the same routing
   policies for both IPv4 and IPv6 with minimal duplication of
   information.

2.3 peering-set class

   The peering-set object defines a set of peerings that are listed in
   its peering attributes.  As described in Section 5.6 in RFC 2622 [1],
   the peering attribute can be expressed using IP addresses.  The
   address family used in the peering attribute determines whether IPv4
   or IPv6, for example, will be used to establish the peering session
   (Note that this is different from the address prefixes exchanged in
   that peering).

   Using the new address syntax defined earlier, the peering attribute
   is specified as follows:

   peering: <as-expression> [<[afi <address-family>] router-expression-1>]
                         [at <[afi <address-family>] router-expression-2>]

   [afi <address-family>] specifies the IP protocol used for the actual
   peering.  Acceptable values would be ipv4 or ipv6

   Example:

   peering-set: AS1-v6
   peering: AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2


2.4 aut-num

   The aut-num class is used to define the automonous system routing
   policies.

   The import and export attributes inside the aut-num class can specify
   the routing protocol, the peering type and the routing filters to be
   used by an autonomous system.  The peering type defines the IP
   address of the routing peers, and thus the IP address family used to
   establish that peering (Section 2.3).

   RPSL supports multi-protocol routing protocol through the optional



Parent                    Expires July 10, 2002                 [Page 5]


Internet-Draft                   RPSLng                     January 2002


   "protocol" statement.  This protocol syntax is extended to allow
   specification of the address-family and subsequent address family.
   This syntax is closely tied with the multi-protocol BGP definition.

   The RPSL dictionary must be extended to support a new protocol "afi"
   and "safi" attributes.  These attributes define the address family
   (ipv4, ipv6) and subsequent address family (unicast, multicast) of
   the IP prefixes exchanged in the routing protocol.

   The initial RPSL dictionary, as defined in RFC2622 section 7.1 [1],
   is extended as follows:

   typedef:      # Address family values
                 # Currently defined: IPv4 and IPv6
                 afi_elm
                 enum[ipv4, ipv6]

   typedef:      # Subsequent address family values
                 # Currently defined: unicast and multicast
                 safi_elm
                 enum[unicast, multicast]

   rp-attribute: afi
                 operator=(afi_elm)
   rp-attribute: safi
                 operator=(safi_elm)

   protocol: BGP4
             # as number of the peer router
             MANDATORY asno(as_number)
             # enable flap damping
             OPTIONAL flap_damp()
             OPTIONAL flap_damp(integer[0,65535],
                                # penalty per flap
                                integer[0,65535],
                                # penalty value for supression
                                integer[0,65535],
                                # penalty value for reuse
                                integer[0,65535],
                                # halflife in secs when up
                                integer[0,65535],
                                # halflife in secs when down
                                integer[0,65535])
                                # maximum penalty
             # Optional address family attribute. Default is ipv4.
             OPTIONAL afi()
             # Optional subsequent address family attribute. Default is
unicast.
             OPTIONAL safi()



Parent                    Expires July 10, 2002                 [Page 6]


Internet-Draft                   RPSLng                     January 2002


   Using the new protocol definition, the import and export attributes
   in an aut-num object can now be specified as follows:

   import:  [protocol <protocol> [afi(address-family)
                                  safi(subsequent-address-family)]]
            [into protocol <protocol>]
            from <peering> [action <action>]
            accept <filter>

   export:  [protocol <protocol> [afi(address-family)]
                                  safi(subsequent-address-family)]]
            [into protocol <protocol>]
            to <peering> [action <action>]
            announce <filter>

   address-family = ipv4|ipv6
   subsequent-address-family = unicast|multicast


   As an example, the aut-num import attribute can specify IPv6 unicast
   route exchange (afi, safi) over an IPv6 peering session between the
   routing peers (peering):

   import: protocol BGP afi(ipv6), safi(unicast)
         from AS1 afi ipv6 3ffe:ffff::1 at afi ipv6 3ffe:ffff::2
         accept AS1:RS-PROVIDER

   The import statement defines that BGP peering to exchange IPv6 (afi)
   unicast (safi) prefixes.  The BGP peering session will be done over
   IPv6 as specified by the peers

   The same example as above, but using the AS1-v6 peering object
   defined in Section 2.3:

   import: protocol BGP afi(ipv6), safi(unicast)
         from AS1-v6
         accept AS1:RS-PROVIDER


2.5 inet-rtr

   TBD

2.6 filter-set

   TBD





Parent                    Expires July 10, 2002                 [Page 7]


Internet-Draft                   RPSLng                     January 2002


3. Security considerations

   TBD

4. Acknowledgments

   This document has benefited from discussion and contributions from
   the following people: Cengiz Alaettinoglu, Larry J.  Blunk, Marc
   Blanchet, David Kessens, Bart Peirens, Mark Prior.

References

   [1]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
        Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
        Policy Specification Language (RPSL)", RFC 2622, June 1999.

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [3]  Kessens, D., "The 6bone registry", Jan 2001.


Author's Address

   Florent Parent
   Viagenie
   2875 boul. Laurier, bur 300
   Ste-Foy, QC  G1V 2M2
   Canada

   Phone: +1 418 656 9254
   EMail: Florent.Parent@viagenie.qc.ca



















Parent                    Expires July 10, 2002                 [Page 8]


Internet-Draft                   RPSLng                     January 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Parent                    Expires July 10, 2002                 [Page 9]