Re: initial draft to bootstrap some discussions
- Date: Fri, 19 Oct 2001 14:17:43 -0400
- modifs included (tagged with MB:). mainly minor edits.
- preparing another email that would propose something more substantial
Marc.
Hello all,
I've managed to spend some time on writing up some of the ideas I've
talked about during the RIPE meeting. Remember that my initial intent was
focused on IPv6 unicast. I've attached the document, and it is available
in the internet-draft repository.
This is a startup document and it needs more work. That said,
contributors most welcomed!
>From the feedback I got was that the RPSLng work should be broadened to
include IPv4 multicast and IPv6 multicast.
I know that many of you are interested to work in IPv4 multicast. It would
be great to have an initial document on the IPv4 multicast in RPSL. Any
takers ? (I'll be glad to help)
I'm hoping that all this will give us a better idea on the overall
RPSLng framework and how to proceed with this work.
Is this approach sensible? I would appreciate any feedback/comments.
Thanks all.
Florent.
--
Florent Parent
Viagénie inc. http://www.viagenie.qc.ca
+1.418.656.9254 x 227
Network Working Group F. Parent
Internet-Draft Viagenie
Expires: April 17, 2002 October 17, 2001
IPv6 Routing Policies using RPSL
draft-parent-rpsl-ipv6-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 April 17, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the definitions and extensions required in
RPSL [1] in order to be able to define IPv6 routing policies.
Defining RPSL for IPv6 is an important step to build an IPv6 Internet
Routing Registry.
Parent Expires April 17, 2002 [Page 1]
Internet-Draft RPSL-IPv6 October 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Address and Prefix Representation in RPSL . . . . . . . . 4
3. Using IPv6 in RPSL classes . . . . . . . . . . . . . . . . . . 6
3.1 aut-num . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 route . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 route-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 as-set . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 inet-rtr . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 filter-set . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7 peering-set . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Using route vs using ipv6-site Objects . . . . . . . . . . . . 9
5. Tunnels and Native IPv6 Links . . . . . . . . . . . . . . . . 10
6. Security considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
Parent Expires April 17, 2002 [Page 2]
Internet-Draft RPSL-IPv6 October 2001
1. Introduction
This draft documents the required information and extensions in RPSL
to be able to specify an IPv6 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 routing policies, and maintain backward
compatibility.
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. The current version of this document
focuses on IPv6 unicast, but this document will be evolving within
the work currently underway in this area.
MB: at the time the draft contains something more than IPv6, then we will
MB: need to change the title and the abstract and the introduction.
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.
Section 2 in RFC 2622 defines the usage of IPv4 addresses and
prefixes in RPSL. Since defining RPSL for IPv6 routing policies
requires defining the usage of IPv6 addresses inside object
attributes, Section 2 in RFC2622 needs to be extended to describe
IPv6 usage. Section 2 describes the usage of IPv6 addresses inside
RPSL.
Introducing IPv6 has an impact on certain classes, most notably in
the aut-num class. Section 3 enumerates the current RPSL classes and
defines the new attributes, when necessary, to support IPv6.
Parent Expires April 17, 2002 [Page 3]
Internet-Draft RPSL-IPv6 October 2001
2. IPv6 Address and Prefix Representation in RPSL
This section is based on Section 2 in RFC 2622 [1] and takes much of
the wording from that section. This section extends the IP address,
prefix and range definitions in order to include IPv6.
It should be noted that IPv6 prefixes has been in usage in RPSL for
quite some time. For example, the 6bone registry [3] uses the ipv6-
site and inet6num objects that contains IPv6 prefixes in their
attributes.
The following IP address representations are added or extended:
<ipv6-address>, <address-prefix> and <address-prefix-range>
<ipv6-address> An IPv6 address is represented as a sequence of
hexadecimal groups delimited with ":" representing a 128 bit address.
The textual representation can be compressed using the "::" syntax.
A full description of the address syntax can be found in Section 2.2
of RFC2373 [2]
MB: :: is not the only compression method (cutting leading 0 is another one).
MB: while IPv4 compatible addresses do not make sense in an RPSL, we may end up
MB: in ipv6 having IPv4 embedded addresses with the current IPv4 decimal writing
MB: in IPv6 addresses.
MB: for all those reasons, I would suggest to reference RFC2373 for all the
MB: possible writing of an IPv6 addresses. This makes more generic and no repetition.
MB: I would suggest the following wording:
MB:The textual representation of an IPv6 address should follow the syntax described in
MB: section 2.2 of RFC2373 [2].
<address-prefix> An address prefix is represented as an IP address
followed by the character slash "/" followed by an integer in the
range appropriate for the IP version (from 0 to 32 for IPv4 and from
0 to 128 for IPv6). The following are valid IPv6 prefixes:
3ffe:ffff:c18::/48, 2002::/16;
MB: the ";" looks like part of the address.
and the following IPv6 prefixes are
invalid: 3ffe:ffff:c18/48 (incomplete IPv6 address), fec0::1/130
(prefix length out of bound).
MB: Really necessary to include examples?.
<address-prefix-range> An address prefix range is an address prefix
followed by an optional range operator. The range operators are:
^- is the exclusive more specifics operator; it stands for the more
specifics of the address prefix excluding the address prefix itself.
For example, 2001::/16^- contains all the more specifics of 2001::/16
excluding 2001::/16.
^+ is the inclusive more specifics operator; it stands for the more
specifics of the address prefix including the address prefix itself.
For example, 2001::/16^+ contains all the more specifics of 2001::/16
including 2001::/16.
^n where n is an integer, stands for all the length n specifics of
the address prefix. For example, 3ffe:ffff::/24^48 contains all the
more specifics of 3ffe:ffff::/24 which are of length 48 such as
3ffe:ffff:c18::/48.
^n-m where n and m are integers, stands for all the length n to
length m specifics of the address prefix. For example,
Parent Expires April 17, 2002 [Page 4]
Internet-Draft RPSL-IPv6 October 2001
3ffe:ffff::/24^24-48 contains all the more specifics of
3ffe:ffff::/24 which are of length 24 to 48 such as
3ffe:ffff:c18::/48 and 3ffe:ffff:c00::/40.
Parent Expires April 17, 2002 [Page 5]
Internet-Draft RPSL-IPv6 October 2001
3. Using IPv6 in RPSL classes
3.1 aut-num
The aut-num class is used to define the automonous system routing
policies.
(Show aut-num class template here)
In order to be able to specify IPv6 routing policies, IPv6 needs to
be supported in aut-num attributes (import, export, default). As an
example, the aut-num import attribute can use an explicit IPv6 prefix
as follows:
import: from AS2 accept { 2001:410::/35 }
Such an statement defines clearly the goal of that attribute: accept
IPv6 prefix advertisement 2001:410::/35 from AS2. Using the
definitions in Section 2, this type of IPv6 policy can be
unambiguously defined.
But routing policies inside aut-num are often defined in term of a
relationship to other autonomous systems, as the following example
shows.
import: from AS3701 accept ANY
export: to AS3701 announce AS3582
Since there is no reference to the IP protocol used, an ambiguity
arises when introducing IPv6: Does the above mean import and export
both IPv4 and IPv6 ? If the IPv4 and IPv6 routing policies are to be
kept distinct, we need some identifier to distinguish between address
families.
It is proposed to define new attributes inside aut-num: import6,
export6, default6. These would allow to unambiguously specify which
address family is being specified inside the policy.
import: from AS3701 accept ANY
import6: from AS3702 accept ANY
export: to AS3701 announce AS3582
export6: to AS3702 announce AS3582
The advantage of using new attributes inside aut-num for IPv6
policies is that the backward compatibility with IPv4 IRR is assured.
If the new attribute is not understood by an IPv4 only software, it
is simply ignored.
Parent Expires April 17, 2002 [Page 6]
Internet-Draft RPSL-IPv6 October 2001
Another approach would be to introduce a new keyword inside the
current import, export and default attributes in order to specify the
address family that the statement applies to. Such an approach would
closely match the current multiprotocol BGP implementation and would
scale better to support address families other that IPv6 unicast.
The import, export attributes use objects such as peering and filter.
These classes must be defined to support IPv6.
3.2 route
This class specifies a route originated by an autonomous system.
(Show route class template here)
Using the definitions in Section 2, the route attribute can specify
IPv6 prefixes. The following route object is an example:
route: 3ffe:b00::/24
origin: AS10566
The route class contains other attributes that use an IP address or
prefix: Section 8 in RFC2622 describes the aggregation attributes
used in the route class. It remains to be further explored how/if
these attributes will be used in IPv6.
3.3 route-set
A route-set allows the definition of a group of prefixes under a
common name. Using the definitions in Section 2, the members
attribute can new specify IPv6 prefixes.
(Show route-set class template here)
route-set: rs-viagenie
members: 3ffe:b00::/24, 2001:410:800::/48
3.4 as-set
3.5 inet-rtr
TO BE DONE
3.6 filter-set
TO BE DONE
Parent Expires April 17, 2002 [Page 7]
Internet-Draft RPSL-IPv6 October 2001
3.7 peering-set
TO BE DONE
Parent Expires April 17, 2002 [Page 8]
Internet-Draft RPSL-IPv6 October 2001
4. Using route vs using ipv6-site Objects
The ipv6-site class (draft-ietf-ngtrans-6bone-registry-xx.txt [3])
contains information similar to the route class:
o AS of the site
o Route prefixes which are exported by the site to the outside world
o Information related to the type of IPv6 connectivity (tunnel or
native links)
The ipv6-site class offers the similar information to what is
available in a route class, but with some important differences:
o the prefix attribute is optional in ipv6-site (whereas it is
mandatory inside the route class).
o the prefix attribute can appear multiple times in ipv6-site
(similar to a route-set).
o ipv6-site does not offer indirect membership as offered by the
route and route-set classes.
o route class offers aggregation attributes.
TO BE COMPLETED
Parent Expires April 17, 2002 [Page 9]
Internet-Draft RPSL-IPv6 October 2001
5. Tunnels and Native IPv6 Links
TO BE DONE
Parent Expires April 17, 2002 [Page 10]
Internet-Draft RPSL-IPv6 October 2001
6. Security considerations
TBD
Parent Expires April 17, 2002 [Page 11]
Internet-Draft RPSL-IPv6 October 2001
7. Acknowledgments
TBD
Parent Expires April 17, 2002 [Page 12]
Internet-Draft RPSL-IPv6 October 2001
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",
draft-ietf-ngtrans-6bone-registry-xx.txt, internet-draft, 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@localhost
Parent Expires April 17, 2002 [Page 13]
Internet-Draft RPSL-IPv6 October 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 April 17, 2002 [Page 14]
-------------
Marc Blanchet
Viagenie
http://www.viagenie.qc.ca
tel: +1-418-656-9254 x225
-------------
IPv6 easy connectivity: http://www.freenet6.net
RFC/W3C/IANA searchable repository: http://www.normos.org
-------------
|
you are here: RIPE -> RIPE Maillists > Archives
