RFC 2546

6Bone Routing Practice

📅 published March 1999, from ietf

RFC 2546: 6Bone Routing Practice 🦋

okay bestie, RFC 2546 is called 6Bone Routing Practice and it dropped in March 1999 📅 It came out of the Network Working Group and was written by A. Durand (IMAG) and B. Buclin (AT&T Labs Europe) 💖 The category is Informational, so it's giving "here's some good info" and not a standard 🧚 The title block doesn't list anything it obsoletes or updates, so no drama there 🙈

Status of This Memo ✨

This memo is here to give info to the Internet community 🌸 It does not specify an Internet standard of any kind, and it can be shared as much as you want, no limits 💅

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

1. Introduction ✨

The 6Bone is basically a playground for trying out the IPv6 protocols and the products that run them 🌈 As it grew, people realized it needed some common operation rules, because keeping the 6Bone backbone healthy is hard when leaf or even backbone sites keep slipping in bogus routes 😭

This memo lays out guidelines for how 6Bone sites might operate, so the 6Bone stays a quality experimentation environment and dodges the pathological situations that happened before 💅 It defines the "best current practice" that's acceptable in the 6Bone for configuring both Interior Gateway Protocols (like RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]) 🎀

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 [RFC 2119]. 🫶

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 that interconnects 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 exchanging routing information among them 👑

Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP ✨

3. Common Rules 💅

This section spills the tea on the common rules that govern routing on the 6Bone 🫖 They come from real issues people hit on the 6Bone, around the routes advertised, how special addresses get handled, and aggregation:

  1. link local prefixes
  2. site local prefixes
  3. loopback prefix & unspecified prefix
  4. multicast prefixes
  5. IPv4-compatible prefixes
  6. IPv4-mapped prefixes
  7. default routes
  8. Yet undefined unicast prefixes (from a different /3 prefix)
  9. Inter site links issues
  10. aggregation & advertisement issues

The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP.

By definition, the link-local prefix has a scope limited to a specific link. Since the prefix is the same on all IPv6 links, advertising it in any routing protocol does not make sense and, worse, it may introduce nasty error conditions 💀

Well known cases where link local prefixes could be advertised by mistake include:

  • a router advertising all directly connected network prefixes, including the link-local one.
  • Subnetting of the link-local prefix.

In such cases, vendors should be urged to correct their code 🙈

3.2. Site-local prefixes 🌷

Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGPs or EGPs within a site. The precise definition of a site is ongoing work discussed in the IPng working group 🧩

Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs.

3.3. Loopback and unspecified prefixes 🪞

The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol.

3.4. Multicast prefixes 📣

Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast routing protocols are designed to respect the semantics of multicast and MUST therefore be used to route packets with multicast destination addresses (in the range FF00::/8) 🦋

Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and 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 routed across a pNLA to its leaf sites.

Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs.

Obviously, link-local multicasts and node-local multicasts MUST NOT be routed at all 🙅‍♀️

3.5. IPv4-compatible prefixes 🎀

Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. As there is no real rationale today for doing that, these addresses SHOULD NOT be used in the 6Bone 🙃

The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs.

IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs.

3.6. IPv4-mapped prefixes 🧁

IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4 address) MAY be advertised by IGPs within a site. It may be useful 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.

3.7. Default routes 🛣️

6Bone core pTLA routers MUST be default-free.

pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do the same for their leaf sites.

3.8. Yet undefined unicast prefixes 🌈

Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in 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) is discussed in section 4, Routing policies, below.

Global IPv6 addresses MUST be used for the end points of the inter-site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels.

Prefixes for those links MUST NOT be injected in the global routing tables.

3.10. Aggregation & advertisement issues 📦

Route aggregation MUST be performed by any border router.

Sites or pNLAs MUST only advertise to their upstream provider the prefixes assigned by that ISP, unless otherwise agreed.

Site border router MUST NOT advertise prefixes more specific than the /48 ones allocated by their ISP.

pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless special peering agreements are implemented. When such special peering agreements are in place between any two or more pTLAs, care MUST be taken not to leak the more specific prefixes to other pTLAs not participating in the peering agreement 🤫

4. Routing policies 🌸

6Bone backbone sites maintain the mesh into the backbone and provide an as reliable as possible service, granted the 6Bone is an experimentation tool 🧪 To achieve their mission, 6Bone backbone 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 therefore SHOULD allow transit traffic through 🤝

Eventually, the Internet registries will assign other TLAs than the 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs will establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT interconnect with this new IPv6 Internet, but transit across the 6Bone will not be guaranteed. It will be left to each 6Bone backbone site to decide whether it will carry traffic to or from the IPv6 Internet 🌍

5. The 6Bone registry 📚

The 6Bone registry is a RIPE-181 database with IPv6 extensions, used to store information about the 6Bone. Each 6Bone site MUST maintain the relevant entries in the 6Bone registry (whois.6bone.net). In particular, the following objects MUST be present:

  • IPv6-site: site description
  • Inet6num: prefix delegation
  • Mntner: coordinate of site maintenance staff

Other objects MAY be maintained at the discretion of the sites, such as routing policy descriptors, person or role objects. The Mntner object MUST make reference to a role or person object, but those must not necessarily reside in the 6Bone registry; they can be stored within any of the Internet registry databases (RIPE, InterNIC, APNIC,

9. Common rules enforcement ✨

okay so being on the 6Bone is totally voluntary and super benevolent 🫶 nobody's forcing you. BUT participating sites are expected to follow the rules in this document, bc the whole point is keeping the 6Bone a quality playground for experimenting with IPv6 and the products that run it 🧪💜

here's how we help enforce the rules (no drama, just teamwork 🌸):

  • when a pTLA site requests its pTLA, it commits to implementing the rules and making sure every site under its administrative control (aka the sites it has delegated prefixes to) follows them too 💅
  • if a site spots an issue, step one is to use the 6Bone registry to contact the site's maintainer and work it out together 📇
  • if nothing happens, or people disagree about the right fix, the issue can be escalated to the 6Bone Operations group 👑
  • if the problem is actually a product issue, the site(s) involved are responsible for contacting the product vendor and working toward a fix 🔧
  • if an issue causes major operational problems, backbone sites may temporarily set filters to restore service 🚨

10. Security Considerations 💀

okay this part is lowkey serious so pay attention 🙈

bogus entries in routing tables usually end up as unreachable sites, and that's a whole mess 😭 having guidelines to aggregate or reject routes will clean up the routing tables. if everyone follows these guidelines, routing on the 6Bone should be way less sensitive to denial of service attacks caused by misleading routes 🛡️

the 6Bone is a TEST network, bestie. denial of service and packet disclosure are to be expected 💀 don't build anything sensitive on top of it and assume it's locked down 🙅‍♀️

11. Acknowledgements 🫶

this document is the result of shared experience on the 6Bone, so a huge shoutout to everyone who put in the hours 🌈 special thanks to Bob Fink for all the hard work he's done to date directing the 6Bone effort, to David Kessens for the 6Bone registry, and to Guy Davies for his insightful contributions 👑✨

12. References 📚

  • [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
  • [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 Testing Address Allocation", RFC 2471, December 1998.
  • [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 Levels", BCP 14, RFC 2119, March 1997.
  • [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998.
  • [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, Representation of IP Routing Policies in a Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.

13. Authors' Addresses 🎀

Alain Durand
Institut d'Informatique et de Mathematiques Appliquees de Grenoble
IMAG BP 53
38041 Grenoble CEDEX 9 France

Phone : +33 4 76 63 57 03
Fax   : +33 4 76 51 49 64
EMail: Alain.Durand@imag.fr


Bertrand Buclin
AT&T International S.A.
Route de l'aeroport 31, CP 72
CH-1215 Geneve 15 (Switzerland)

Phone : +41 22 929 37 40
Fax   : +41 22 929 39 84
EMail: Bertrand.Buclin@ch.att.com

Copyright (C) The Internet Society (1999). 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. 💖

📦 where this page comes from