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]