draft-ietf-ngtrans-6bone-routing-01.txt   rfc2546.txt 
INTERNET DRAFT Alain Durand Network Working Group A. Durand
NGTRANS WG IMAG Request for Comments: 2546 IMAG
Expires 20 November, 1998 Bertrand Buclin Category: Informational B. Buclin
Category: Informational AT&T Labs Europe AT&T Labs Europe
May 1998 March 1999
6Bone Routing Practice
<draft-ietf-ngtrans-6bone-routing-01.txt> 6Bone Routing Practice
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working documents This memo provides information for the Internet community. It does
of the Internet Engineering Task Force (IETF), its Areas, and its Working not specify an Internet standard of any kind. Distribution of this
Groups. Note that other groups may also distribute working documents as memo is unlimited.
Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as reference
material or to cite them other than as a ``working draft'' or ``work in
progress.''
Please check the 1id-abstracts.txt listing contained in the internet-drafts
Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
This memo provides information for the Internet community. This memo does
not specify an Internet standard of any kind. Distribution of this memo is
unlimited.
This draft expires October 30, 1998.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
1 Introduction 1. Introduction
The 6Bone is an environment supporting experimentation with the IPv6 The 6Bone is an environment supporting experimentation with the IPv6
protocols and products implementing it. As the network grows, the need for protocols and products implementing it. As the network grows, the
common operation rules emerged. In particular, operation of the 6Bone need for common operation rules emerged. In particular, operation of
backbone is a challenge due to the frequent insertion of bogus routes by the 6Bone backbone is a challenge due to the frequent insertion of
leaf or even backbone sites. bogus routes by leaf or even backbone sites.
This memo identifies guidelines on how 6Bone sites might operate, so that This memo identifies guidelines on how 6Bone sites might operate, so
the 6Bone can remain a quality experimentation environment and to avoid that the 6Bone can remain a quality experimentation environment and
pathological situations that have been encountered in the past. It defines to avoid pathological situations that have been encountered in the
the 'best current practice' acceptable in the 6Bone for the configuration past. It defines the 'best current practice' acceptable in the 6Bone
of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior for the configuration of both Interior Gateway Protocols (such as
Gateway Protocols (like BGP4+ [RFC 2283]). RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC
2283]).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2 Basic principles 2. Basic principles
The 6Bone is structured as a hierarchical network with pseudo Top Level
Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA) sites and
leaf sites. This topology supports the IPv6 address aggregation
architecture as described in [1]. The 6Bone backbone is made of a mesh
interconnecting pTLAs only. pNLAs connect to one or more pTLAs and provide
transit service for leaf sites. The 6Bone is structured as a hierarchical network with pseudo Top
Level Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA)
sites and leaf sites. This topology supports the IPv6 address
aggregation architecture as described in [1]. The 6Bone backbone is
made of a mesh interconnecting pTLAs only. pNLAs connect to one or
more pTLAs and provide transit service for leaf sites.
pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing protocol for pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing
exchanging routing information among them. protocol for exchanging routing information among them.
Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY
simple default route to their ISP. use a simple default route to their ISP.
3 Common Rules 3. Common Rules
This section details common rules governing the routing on the 6Bone. They This section details common rules governing the routing on the 6Bone.
are derived from issues encountered on the 6Bone, with respect to the They are derived from issues encountered on the 6Bone, with respect
routes advertised, handling of special addresses, and aggregation: to the routes advertised, handling of special addresses, and
aggregation:
1) link local prefixes 1) link local prefixes
2) site local prefixes 2) site local prefixes
3) loopback prefix & unspecified prefix 3) loopback prefix & unspecified prefix
4) multicast prefixes 4) multicast prefixes
5) IPv4-compatible prefixes 5) IPv4-compatible prefixes
skipping to change at page 2, line 51 skipping to change at page 2, line 38
6) IPv4-mapped prefixes 6) IPv4-mapped prefixes
7) default routes 7) default routes
8) Yet undefined unicast prefixes (from a different /3 prefix) 8) Yet undefined unicast prefixes (from a different /3 prefix)
9) Inter site links issues 9) Inter site links issues
10) aggregation & advertisement issues 10) aggregation & advertisement issues
3.1 Link-local prefix 3.1 Link-local prefix
The link-local prefix (FE80::/10) MUST NOT be advertised through either an The link-local prefix (FE80::/10) MUST NOT be advertised through
IGP or an EGP. either an IGP or an EGP.
By definition, the link-local prefix has a scope limited to a specific By definition, the link-local prefix has a scope limited to a
link. Since the prefix is the same on all IPv6 links, advertising it in any specific link. Since the prefix is the same on all IPv6 links,
routing protocol does not make sense and, worse, may introduce nasty error advertising it in any routing protocol does not make sense and,
conditions. worse, may introduce nasty error conditions.
Well known cases where link local prefixes could be advertised by mistake Well known cases where link local prefixes could be advertised by
include: mistake include:
- a router advertising all directly connected network prefixes including - a router advertising all directly connected network prefixes
the link-local one. including the link-local one.
- Subnetting of the link-local prefix. - Subnetting of the link-local prefix.
In such cases, vendors should be urged to correct their code. In such cases, vendors should be urged to correct their code.
3.2 Site-local prefixes 3.2 Site-local prefixes
Site local prefixes (in the FEC0::/10 range) MAY be advertized by IGPs or Site local prefixes (in the FEC0::/10 range) MAY be advertized by
EGPs within a site. The precise definition of a site is ongoing work IGPs or EGPs within a site. The precise definition of a site is
discussed in the IPng working group. ongoing work discussed in the IPng working group.
Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs. Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.
3.3 Loopback and unspecified prefixes 3.3 Loopback and unspecified prefixes
The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT The loopback prefix (::1/128) and the unspecified prefix (::0/128)
be advertised by any routing protocol. MUST NOT be advertised by any routing protocol.
3.4 Multicast prefixes 3.4 Multicast prefixes
Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast prefixes MUST NOT be advertised by any unicast routing
Multicast routing protocols are designed to respect the semantics of protocol. Multicast routing protocols are designed to respect the
multicast and MUST therefore be used to route packets with multicast semantics of multicast and MUST therefore be used to route packets
destination addresses (in the range FF00::/8). with multicast destination addresses (in the range FF00::/8).
Multicast address scopes MUST be respected on the 6Bone. Only global scope Multicast address scopes MUST be respected on the 6Bone. Only global
multicast addresses MAY be routed across transit pNLAs and pTLAs. There is scope multicast addresses MAY be routed across transit pNLAs and
no requirement on a pTLA to route multicast packets. pTLAs. There is no requirement on a pTLA to route multicast packets.
Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges)
routed across a pNLA to its leaf sites. MAY be routed across a pNLA to its leaf sites.
Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. Site-local multicasts MUST NOT be routed toward transit pNLAs or
pTLAs.
Obviously, link-local multicasts and node-local multicasts MUST NOT be Obviously, link-local multicasts and node-local multicasts MUST NOT
routed at all. be routed at all.
3.5 IPv4-compatible prefixes 3.5 IPv4-compatible prefixes
Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. Sites may choose to use IPv4 compatible addresses (::a.b.c.d)
As there is no real rationale today for doing that, these addresses SHOULD internally. As there is no real rationale today for doing that,
these addresses SHOULD
NOT be used in the 6Bone. NOT be used in the 6Bone.
The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.
IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit
pTLAs. pNLAs or pTLAs.
3.6 IPv4-mapped prefixes 3.6 IPv4-mapped prefixes
IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4 address) MAY IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4
be advertised by IGPs within a site. It may be useful for some IPv6 only address) MAY be advertised by IGPs within a site. It may be useful
nodes within a site to have such a route pointing to a translation device. for some IPv6 only nodes within a site to have such a route pointing
to a translation device.
IPv4-mapped prefixes MUST NOT be advertised by EGPs. IPv4-mapped prefixes MUST NOT be advertised by EGPs.
3.7 Default routes 3.7 Default routes
6Bone core pTLA routers MUST be default-free. 6Bone core pTLA routers MUST be default-free.
pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY
the same for their leaf sites. do the same for their leaf sites.
3.8 Yet undefined unicast prefixes 3.8 Yet undefined unicast prefixes
Yet undefined unicast prefixes from a format prefix other than 2000::/3 Yet undefined unicast prefixes from a format prefix other than
MUST NOT be advertised by any routing protocol in the 6Bone. In particular, 2000::/3 MUST NOT be advertised by any routing protocol in the 6Bone.
RFC1897 test addresses MUST NOT be advertised on the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the
6Bone.
Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) Routing of global unicast prefixes outside of the 6Bone range
is discussed in section 4, Routing policies, below. (3FFE::/16) is discussed in section 4, Routing policies, below.
3.9 Inter-site links 3.9 Inter-site links
Global IPv6 addresses MUST be used for the end points of the inter-site Global IPv6 addresses MUST be used for the end points of the inter-
links. In particular, IPv4 compatible addresses MUST NOT be used for site links. In particular, IPv4 compatible addresses MUST NOT be used
tunnels. for tunnels.
Prefixes for those links MUST NOT be injected in the global routing tables. Prefixes for those links MUST NOT be injected in the global routing
tables.
3.10 Aggregation & advertisement issues 3.10 Aggregation & advertisement issues
Route aggregation MUST be performed by any border router. Route aggregation MUST be performed by any border router.
Sites or pNLAs MUST only advertise to their upstream provider the prefixes Sites or pNLAs MUST only advertise to their upstream provider the
assigned by that ISP unless otherwise agreed. prefixes assigned by that ISP unless otherwise agreed.
Site border router MUST NOT advertise prefixes more specific than the /48 Site border router MUST NOT advertise prefixes more specific than the
ones allocated by their ISP. /48 ones allocated by their ISP.
pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless
special peering agreements are implemented. When such special peering special peering agreements are implemented. When such special peering
agreements are in place between any two or more pTLAs, care MUST be taken agreements are in place between any two or more pTLAs, care MUST be
not to leak the more specific prefixes to other pTLAs not participating taken not to leak the more specific prefixes to other pTLAs not
in the peering agreement. participating in the peering agreement.
4 Routing policies 4. Routing policies
6Bone backbone sites maintain the mesh into the backbone and provide an as 6Bone backbone sites maintain the mesh into the backbone and provide
reliable as possible service, granted the 6Bone is an experimentation tool. an as reliable as possible service, granted the 6Bone is an
To achieve their mission, 6Bone backbone sites MUST maintain peerings with experimentation tool. To achieve their mission, 6Bone backbone sites
at least 3 (three) other back bone sites. MUST maintain peerings with at least 3 (three) other back bone sites.
The peering agreements across the 6Bone are by nature non-commercial, and The peering agreements across the 6Bone are by nature non-commercial,
therefore SHOULD allow transit traffic through. and therefore SHOULD allow transit traffic through.
Eventually, the Internet registries will assign other TLAs than the 6Bone Eventually, the Internet registries will assign other TLAs than the
one (currently 3FFE::/16). The organizations bearing those TLAs will 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs
establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT will establish a new IPv6 network, parallel to the 6Bone. The 6Bone
interconnect with this new IPv6 Internet, b ut transit across the 6Bone MIGHT interconnect with this new IPv6 Internet, b ut transit across
will not be guaranteed. It will be left to each 6Bone backbone site to the 6Bone will not be guaranteed. It will be left to each 6Bone
decide whether it will carry traffic to or from the IPv6 Internet. backbone site to decide whether it will carry traffic to or from the
IPv6 Internet.
5 The 6Bone registry 5. The 6Bone registry
The 6Bone registry is a RIPE-181 database with IPv6 extensions used to The 6Bone registry is a RIPE-181 database with IPv6 extensions used
store information about the 6Bone. Each 6Bone site MUST maintain the to store information about the 6Bone. Each 6Bone site MUST maintain
relevant entries in the 6Bone registry (whois.6bone.net). In particular, the relevant entries in the 6Bone registry (whois.6bone.net). In
the following objects MUST be present: particular, the following objects MUST be present:
- IPv6-site: site description - IPv6-site: site description
- Inet6num: prefix delegation - Inet6num: prefix delegation
- Mntner: coordinate of site maintenance staff - Mntner: coordinate of site maintenance staff
Other objects MAY be maintained at the discretion of the sites, such as Other objects MAY be maintained at the discretion of the sites, such
routing policy descriptors, person or role objects. The Mntner object MUST as routing policy descriptors, person or role objects. The Mntner
make reference to a role or person object, but those must not necessarily object MUST make reference to a role or person object, but those must
reside in the 6Bone registry, they can be stored within any of the not necessarily reside in the 6Bone registry, they can be stored
Internet registry databases (RIPE, InterNIC, APNIC, ...). within any of the Internet registry databases (RIPE, InterNIC, APNIC,
6 Guidelines for new sites joining the 6Bone 6. Guidelines for new sites joining the 6Bone
New sites joining the 6Bone should seek to connect to a transit pNLA or a New sites joining the 6Bone should seek to connect to a transit pNLA
pTLA within their region, and preferably as close as possible to their or a pTLA within their region, and preferably as close as possible to
existing IPv4 physical and routing path for Internet service. The 6Bone their existing IPv4 physical and routing path for Internet service.
registry is available to find out candidate ISPs. The 6Bone registry is available to find out candidate ISPs.
Any site connected to the 6Bone MUST maintain a DNS server for forward name Any site connected to the 6Bone MUST maintain a DNS server for
looking and reverse address translation. The joining site MUST maintain the forward name looking and reverse address translation. The joining
6Bone registry objects relative to its site, and in particular the IPv6- site MUST maintain the 6Bone registry objects relative to its site,
site and the MNTNER objects. and in particular the IPv6- site and the MNTNER objects.
The upstream ISP MUST delegate the reverse address translation zone in DNS The upstream ISP MUST delegate the reverse address translation zone
to the joining site. The ISP MUST also create 6Bone registry objects in DNS to the joining site. The ISP MUST also create 6Bone registry
reflecting the delegated address space (inet6num:). objects reflecting the delegated address space (inet6num:).
Up to date information about how to join the 6Bone is available on the Up to date information about how to join the 6Bone is available on
6Bone Web site at http://www.6bone.net. the 6Bone Web site at http://www.6bone.net.
7 Guidelines for 6Bone pTLA sites 7. Guidelines for 6Bone pTLA sites
6Bone pTLA sites are altogether forming the backbone of the 6Bone. In order 6Bone pTLA sites are altogether forming the backbone of the 6Bone. In
to ensure the highest level possible of availability and stability for the order to ensure the highest level possible of availability and
6Bone environment, a few constraints are placed onto sites wishing to stability for the 6Bone environment, a few constraints are placed
become or stay a 6Bone pTLA: onto sites wishing to become or stay a 6Bone pTLA:
1. The site MUST have experience with IPv6 on the 6Bone, at least as 1. The site MUST have experience with IPv6 on the 6Bone, at least as
a leaf site and preferably as a transit pNLA under an existing pTLA. a leaf site and preferably as a transit pNLA under an existing
pTLA.
2. The site MUST have the ability and intent to provide "production- 2. The site MUST have the ability and intent to provide "production-
like" 6Bone backbone service to provide a robust and operationally like" 6Bone backbone service to provide a robust and operationally
reliable 6Bone backbone. reliable 6Bone backbone.
3. The site MUST have a potential "user community" that would be 3. The site MUST have a potential "user community" that would be
served by becoming a pTLA, e.g., the requester is a major player in a served by becoming a pTLA, e.g., the requester is a major player
region, country or focus of interest. in a region, country or focus of interest.
4. Must commit to abide by the 6Bone backbone operational rules and 4. Must commit to abide by the 6Bone backbone operational rules and
policies as defined in the present document. policies as defined in the present document.
When a candidate site seeks to become a pTLA site, it will apply for it to When a candidate site seeks to become a pTLA site, it will apply for
the 6Bone Operations group (see below) by bringing evidences it meets the it to the 6Bone Operations group (see below) by bringing evidences it
above criteria. meets the above criteria.
8 6Bone Operations group 8. 6Bone Operations group
The 6Bone Operations group is the body in charge of monitoring the The 6Bone Operations group is the body in charge of monitoring the
adherence to the present rules, and will take the appropriate actions to adherence to the present rules, and will take the appropriate actions
correct deviations. Membership in the 6Bone Operations group is mandatory to correct deviations. Membership in the 6Bone Operations group is
mandatory for, and restricted to, any site connected to the 6Bone.
for, and restricted to, any site connecte d to the 6Bone.
The 6Bone Operations group is currently defined by those members of the The 6Bone Operations group is currently defined by those members of
existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent sites the existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent
participating on the 6Bone. Therefore it is incumbent on relevant site sites participating on the 6Bone. Therefore it is incumbent on
contacts to join the mailing list. Instructions on how to join the list are relevant site contacts to join the mailing list. Instructions on how
maintained on the 6Bone web site at http://www.6bone.net. to join the list are maintained on the 6Bone web site at
http://www.6bone.net.
9 Common rules enforcement 9. Common rules enforcement
Participation in the 6Bone is a voluntary and benevolent undertaking. Participation in the 6Bone is a voluntary and benevolent undertaking.
However, participating sites are expected to adhere to the rules described However, participating sites are expected to adhere to the rules
in this document, in order to maintain the 6Bone as quality tool for described in this document, in order to maintain the 6Bone as quality
experimenting with the IPv6 protocols and products implementing them. tool for experimenting with the IPv6 protocols and products
implementing them.
The following processes are proposed to help enforcing the 6Bone rules: The following processes are proposed to help enforcing the 6Bone
rules:
- Each pTLA site has committed when requesting their pTLA to implement the - Each pTLA site has committed when requesting their pTLA to
rules, and to ensure they are respected by sites within their implement the rules, and to ensure they are respected by sites
administrative control (i.e. those to who prefixes have been delegated). within their administrative control (i.e. those to who prefixes
have been delegated).
- When a site detects an issue, it will first use the 6Bone registry to - When a site detects an issue, it will first use the 6Bone registry
contact the site maintainer and work the issue. to contact the site maintainer and work the issue.
- If nothing happens, or there is disagreement on what the right solution - If nothing happens, or there is disagreement on what the right
is, the issue can be brought to the 6Bone Operations group. solution is, the issue can be brought to the 6Bone Operations
group.
- When the problem is related to a product issue, the site(s) involved is - When the problem is related to a product issue, the site(s)
responsible for contact the product vendor and work toward its resolution. involved is responsible for contact the product vendor and work
toward its resolution.
- When an issue causes major operational problems, backbone sites may - When an issue causes major operational problems, backbone sites may
decide to temporarily set filters in order to restore service. decide to temporarily set filters in order to restore service.
10 Security considerations 10. Security Considerations
The result of bogus entries in routing tables is usually unreachable sites. The result of bogus entries in routing tables is usually
Having guidelines to aggregate or reject routes will clean up the routing unreachable sites. Having guidelines to aggregate or reject routes
tables. It is expected that using these guidelines, routing on the 6Bone will clean up the routing tables. It is expected that using these
will be less sensitive to denial of service attacks due to misleading guidelines, routing on the 6Bone will be less sensitive to denial
routes. of service attacks due to misleading routes.
The 6Bone is a test network. Therefore, denial of service, packet The 6Bone is a test network. Therefore, denial of service, packet
disclosure,... are to be expected. disclosure, are to be expected.
11 Acknowledgements 11. Acknowledgements
This document is the result of shared experience on the 6Bone. Special This document is the result of shared experience on the 6Bone.
thanks go to Bob Fink for the hard work make to date to direct the 6Bone Special thanks go to Bob Fink for the hard work make to date to
effort, to David Kessens for the 6Bone registry, and to Guy Davies for his direct the 6Bone effort, to David Kessens for the 6Bone registry,
insightful contributions. and to Guy Davies for his insightful contributions.
12 References 12. References
[1] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", [1] Hinden, R. and S. Deering, "IP Version 6 Addressing
January 1998, internet draft, work in progress, Architecture", RFC 2373, July 1998.
<draft-ietf-ipngwg-addr-arch-v2-06.txt>
[RFC 1897] R. Hinden & J. Postel., IPv6 Testing Address Allocation. [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6
January 1996. (Status: OBSOLETE) Testing Address Allocation", RFC 2471, December 1998.
[RFC 2080] Malkin, G., Minnear, R., "RIPng for IPv6", January 1997. [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2283] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
Extensions for BGP-4", March 98 "Multiprotocol Extensions for BGP-4", RFC 2283, March
1998.
[RIPE-181] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J.,
Karrenberg, M. Terpstra, and J. Yu. Representation of IP Karrenberg, D., Terpstra, M. and J. Yu, Representation
Routing Policies in a Routing Registry. Technical Report ripe- of IP Routing Policies in a Routing Registry. Technical
181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands,
October 1994.
13 Author address 13. Authors' Addresses
Alain Durand Alain Durand
Institut d'Informatique et de Mathematiques Appliquees de Grenoble Institut d'Informatique et de Mathematiques Appliquees de Grenoble
IMAG BP 53 IMAG BP 53
38041 Grenoble CEDEX 9 France 38041 Grenoble CEDEX 9 France
Phone : +33 4 76 63 57 03
Fax : +33 4 76 51 49 64
E-Mail: Alain.Durand@imag.fr
Bertrand Buclin Phone : +33 4 76 63 57 03
AT&T International S.A. Fax : +33 4 76 51 49 64
Route de l'aeroport 31, CP 72 EMail: Alain.Durand@imag.fr
CH-1215 Geneve 15 (Switzerland)
Phone : +41 22 929 37 40
Fax : +41 22 929 39 84
E-Mail: Bertrand.Buclin@ch.att.com
14 Full Copyright Statement Bertrand Buclin
AT&T International S.A.
Route de l'aeroport 31, CP 72
CH-1215 Geneve 15 (Switzerland)
"Copyright (C) The Internet Society (date). All Rights Reserved. Phone : +41 22 929 37 40
Fax : +41 22 929 39 84
EMail: Bertrand.Buclin@ch.att.com
This document and translations of it may be copied and furnished 14. Full Copyright Statement
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation 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 Copyright (C) The Internet Society (1999). All Rights Reserved.
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and translations of it may be copied and furnished to
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET others, and derivative works that comment on or otherwise explain it
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR or assist in its implementation may be prepared, copied, published
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF and distributed, in whole or in part, without restriction of any
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED kind, provided that the above copyright notice and this paragraph are
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
 End of changes. 93 change blocks. 
253 lines changed or deleted 233 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/