RFC 2772

6Bone Backbone Routing Guidelines

📅 published February 2000, from ietf

RFC 2772: 6Bone Backbone Routing Guidelines 🌈

Okay bestie, RFC 2772 is called 6Bone Backbone Routing Guidelines 🦋 It came out of the Network Working Group in February 2000. The authors are R. Rockell from Sprint and R. Fink from ESnet. It's Category Informational, so it's a best-practices guide, not a standard 💅 It obsoletes RFC 2546, which means that one is retired now, and it doesn't list any RFCs it updates.

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸

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

Abstract 🎀

The 6Bone is basically a playground for testing IPv6, and it exists to help IPv6 evolve and get deployed 🧚 Because of that, the core backbone of the IPv6 network has to stay stable. Every operator also needs the same set of rules and guidelines for deploying IPv6 routing equipment, or things get messy fast 😭

This document is a set of guidelines for every 6bone routing equipment operator to use as a reference for efficient, stable deployment of 6bone routing systems. The more complex the 6Bone gets, the more important it is that everyone follows one common set of rules, so the backbone can be efficient and scalable 💜

Table of Contents 🍓

   1. Introduction..................................................  2
   2. Scope of this document........................................  3
   3. Common Rules for the 6bone....................................  3
       3.1 Link-local prefixes......................................  3
       3.2 Site-local prefixes......................................  4
       3.3 Loopback and unspecified prefixes........................  5
       3.4 Multicast prefixes.......................................  5
       3.5 IPv4 compatible prefixes.................................  5
       3.6 IPv4-mapped prefixes.....................................  6
       3.7 Default routes...........................................  6
       3.8 Yet undefined unicast prefixes...........................  6
       3.9 Inter-site links.........................................  6
       3.10 6to4 Prefixes...........................................  7
       3.11 Aggregation & advertisement issues......................  7
   4. Routing Policies for the 6bone................................  7
   5. The 6Bone Registry............................................  8
   6. Guidelines for new sites joining the 6Bone....................  9
   7. Guidelines for 6Bone pTLA sites...............................  9
   8. 6Bone Operations group........................................ 11
   9. Common rules enforcement for the 6bone........................ 11
   10. Security Considerations...................................... 12
   11. References................................................... 12
   12. Authors' Addresses........................................... 13
   13. Full Copyright Statement..................................... 14

1. Introduction 🧚

The 6Bone is an IPv6 testbed that helps IPv6 evolve and get deployed. Because of that, the core backbone of the IPv6 network has to stay stable, and all operators need a common set of rules and guidelines for deploying IPv6 routing equipment 🫶

This document gives every 6bone routing equipment operator a reference for efficient, stable deployment of 6bone routing systems. As the 6Bone grows more complex, sticking to a common set of rules gets more and more important, because that's what keeps an efficient, scalable backbone possible 🔥

This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as defined [RFC 2283], commonly called BGP4+, as the currently accepted EGP 💅

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. Scope of this document 🦋

This is a best-practices Informational document, and it's aimed at IPv6 entities that operate under the 6Bone IPv6 testbed TLA allocation 🌸

3. Common Rules for the 6bone 🎀

This section spells out the common rules that govern routing on the 6Bone. They come from real problems people ran into on the 6Bone with the routes being advertised, the handling of special addresses, and aggregation 😭 The topics are:

  1. link local prefixes
  2. site local prefixes
  3. loopback and unspecified prefixes
  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. 6to4 prefixes
  11. aggregation & advertisement issues

The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP. Under no circumstance should this prefix show up in the 6Bone backbone routing table 🙈

The link-local prefix only has scope on one specific link. Since it's the same on every IPv6 link, advertising it in any routing protocol makes zero sense, and worse, it can cause nasty error conditions 💀

Some well-known ways link-local prefixes get advertised by accident include, but aren't limited to:

  • a router advertising all directly connected network prefixes, link-local one included
  • subnetting of the link-local prefix

When this happens, vendors should be urged to fix their code. Vendors should be encouraged to fix the problem, but the ultimate responsibility is on the operator of that IPv6 site, who has to fix it by whatever means necessary 💅

If a pTLA finds link-local prefixes coming from another pTLA, the pTLA that's leaking the routes is responsible for filtering them and fixing the problem in a timely fashion. If a pTLA finds that one of its downstreams is leaking link-local prefixes, that pTLA has to make sure those prefixes don't leak to other pTLAs or to its other downstreams 🫶

If the route filtering isn't done in a timely fashion, other pTLAs may end up manually shutting down their BGP4+ sessions to that pTLA 😭

Also, every pTLA, pNLA, and end-site is responsible for filtering its own BGP4+ sessions appropriately toward peers, and for filtering routes coming in from peers too. They should only allow the routes that fit the aggregation model and don't cause operational problems ✨

3.2 Site-local prefixes 🌈

Site-local prefixes (in the FEC0::/10 range) MAY be advertised by IGPs or EGPs within a site. The IPng working group is still working on the precise definition of a site. Generally, though, a site includes a group of nodes run by one administrator or a group of administrators, or a group of nodes used for a common purpose 🧚

Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, or leaf-sites 🙅‍♀️

Again, if site-local prefixes leak outside of a given site, the site is responsible for fixing it in a timely manner. It can use filters or other means that remove the operational impact those prefixes had on the peering sites involved 💅 Still, every site SHOULD filter not only outbound on their EGP, but also inbound, so that proper routing announcements are not only sent but also received 🔥

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 🚫

The same responsibility applies to whoever advertises the loopback or unspecified prefix as in Section 3.1 and 3.2 🫶

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, so they MUST be used to route packets with multicast destination addresses (in the range of FF00::/8) 💜

Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and pTLAs. At the time this memo was written, there's 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 🙈

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 internally, written as ::a.b.c.d where a.b.c.d stands for the octets of an IPv4 address. There's no real reason to do this right now, so these addresses SHOULD NOT be used or routed on 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 💅

If ::/96 IPv4-compatible prefixes do leak into an EGP, the party advertising the route has to fix it, either with proper filters or other means. It's in everyone's best interest to filter both outbound and inbound at their IGP borders 😭

3.6 IPv4-mapped prefixes 🌈

IPv4-mapped prefixes, written as ::FFFF:a.b.c.d where a.b.c.d stands for the octets of an IPv4 address, MAY be advertised by IGPs within a site. Some IPv6-only nodes inside a site might find it useful to have a route like this pointing to a translation device, which helps with IPv6 deployment ✨

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 any downstream peer (non-pTLA site). Transit pNLAs MAY advertise a default route to any of their downstreams (other transit pNLA or leaf site) 🫶

If a default route gets redistributed into an EGP and shows up on any pTLA EGP session, the pTLA has to fix it immediately once it realizes the route exists. If the default route came from downstream of a pTLA, the guilty pTLA is responsible for pushing the entity that originated it to fix things 😭

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 on the 6Bone. In particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone 🙈

Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), and routing of global unicast prefixes that aren't delegated yet inside that range (3ffe::/16), are discussed in section 4, Routing policies, below 🌸

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

Sites MAY use other addressing schemes for inter-site links, but those addresses MUST NOT be advertised into the IPv6 global routing table 🙅‍♀️

Prefixes for inter-site links MUST NOT be injected into the global routing tables 💀

Okay, that's the first chunk of the rules! 🫶

3.10. 6to4 Prefixes 🌸

okay so the 6to4 prefix, or some portion of it, MAY be announced by any pTLA that has a current implementation of 6to4 running in their IPv6 network 💅. but as 6to4 folks get more real-world experience, it MAY be necessary to change this in some way 🙈. when this doc was being written, any pTLA MAY announce the 6to4 prefix into global EBGP ✨. BUT to announce this block, the pTLA MUST have a 6to4 router active that is sourcing this prefix announcement 🔥.

this section is subject to change and MAY vary depending on how 6to4 progresses inside the NGTRANS working group 🦋

3.11. Aggregation & advertisement issues 🎀

route aggregation MUST be performed by any border router talking EGP with any other IPv6 sites 💖. More-specifics MUST NOT be leaked into or across the IPv6 6Bone backbone 🙅‍♀️

4. Routing Policies for the 6bone 🦋

bestie, leaf sites or pNLAs MUST only advertise to an upstream provider the prefixes assigned by that provider 👑. advertising a prefix assigned by another provider to a provider is not acceptable, and it breaks the aggregation model 💀. A site MUST NOT advertise a prefix from another provider to a provider as a way around the multi-homing problem 🙅‍♀️. however, in the interest of testing new solutions, one may break this policy, so long as ALL affected parties are aware of this test, and all agree to support this testing 🧪. These policy breaks MUST NOT affect the 6bone routing table globally 🌍

to clarify, if one has two upstream pNLA or pTLA providers (A and B for this example), one MUST only announce the prefix delegated to one by provider A to provider A, and one MUST only announce the prefix delegated by one from provider B upstream to provider B 🫶. there exists no circumstance where this should be violated, bc it breaks the aggregation model and could globally affect routing decisions if downstreams are able to leak other providers' more specific delegations up to a pTLA 😭. as the IPNG working group works through the multi-homing problem, there may be a need to alter this rule slightly, to test new strategies for deployment ✨. however, in the case of current specifications at the time of this writing, there is no reason to advertise more specifics, and pTLA's MUST adhere to the current aggregation model 💅

site border routers for pNLA or leaf sites MUST NOT advertise prefixes more specific (longer) than the prefix that was allocated by their upstream provider 🚫

All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented 🌸. When such special peering agreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering agreement 🔒. 6bone pTLAs which have such agreements in place MUST NOT advertise other 6bone pTLA more specifics to downstream 6bone pNLAs or leaf sites, as this will break the best-path routing decision 🛣️

the peering agreements across the 6Bone may be by nature non-commercial, and therefore MAY allow transit traffic, if peering agreements of this nature are made. however, no pTLA is REQUIRED to give or receive transit service from another pTLA 💜

eventually, the Internet registries will assign prefixes under other than the 6Bone TLA (3FFE::/16) 🔮. as of the time this document was written in 1999, the Internet registries were starting to assign /35 sub-TLA (sTLA) blocks from the 2001::/16 TLA 🕰️. others will certainly be used in the future 🌈

the organizations receiving prefixes under these newer TLAs would be expected to want to establish peering and connectivity relationships with other IPv6 networks, both in the newer TLA space and in the 6bone pTLA space 🤝. Peering between new TLA's and the current 6Bone pTLA's MAY occur, and details such as transit, and what routes are received by each, are outside of general peering rules as stated in this memo, and are left up to the members of those TLA's and pTLA's that are establishing said peerings 🧚. however, it is expected that most of the rules discussed here are equally applicable to new TLAs 🎀

5. The 6Bone Registry 🌈

the 6Bone registry is a RIPE-181 database with IPv6 extensions used to store information about the 6Bone, and its sites 📚. the 6bone is accessible at:

<http://www.6bone.net/whois.html>)

Each 6Bone site MUST maintain the relevant entries in the 6Bone registry 📝. in particular, the following object MUST be present for all 6Bone leaf sites, pNLAs and pTLAs 💖:

  • IPv6-site: site description
  • Inet6num: prefix delegation (one record MUST exist for each delegation)
  • Mntner: contact info for site maintenance/administration staff.

Other object 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 MAY NOT necessarily reside in the 6Bone registry 🤔. they can be stored within any of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.) 🌸

6. Guidelines for new sites joining the 6Bone 🍓

new sites joining the 6Bone should seek to connect to a transit pNLA or a pTLA within their region, and preferably as close as possible to their existing IPv4 physical and routing path for Internet service 🛤️. The 6Bone web site at http://www.6bone.net has various information and tools to help find candidate 6bone networks 🔍

Any site connected to the 6Bone MUST maintain a DNS server for forward name lookups and reverse address lookups 🧭. The joining site MUST maintain the 6Bone objects relative to its site, as described in section 5 📋

The upstream provider MUST delegate the reverse address translation zone in DNS to the joining site, or have an agreement in place to perform primary DNS for that downstream 🤝. The provider MUST also create the 6Bone registry inet6num object reflecting the delegated address space 🗂️

up to date information about how to join the 6Bone is available on the 6Bone Web site at http://www.6bone.net 🌐

7. Guidelines for 6Bone pTLA sites 💅

the following rules apply to qualify for a 6Bone pTLA allocation 👑. it should be recognized that holders of 6Bone pTLA allocations are expected to provide production quality backbone network services for the 6Bone 🔥

  1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period, the Applicant must be operationally providing the following:
    • a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site, inet6num, mntner, and person objects, including each tunnel that the Applicant has 📝
    • b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request 🛰️
    • c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system 🧭
    • d. A fully maintained, and reliable, IPv6-accessible system providing, at a minimum, one or more web pages describing the Applicant's IPv6 services. This server must be IPv6 pingable 🌸
  2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following:
    • a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA Applicant 🫶
    • b. A common mailbox for support contact purposes that all support staff have access to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant 📬
  3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest 🌍. Applicant must provide a statement and information in support of this claim 📄
  4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community 🤝

When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing the Group with information in support of its claims that it meets the criteria above 💌

8. 6Bone Operations Group 🦋

The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules 👀. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone 🔒

The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone 💌. Therefore, it is incumbent on relevant site contacts to join the 6Bone mailing list 🫶. Instructions on how to join the list are maintained on the 6Bone web site at http://www.6bone.net ✨

9. Common rules enforcement for the 6bone ✨

participation in the 6Bone is a voluntary and benevolent undertaking 🌈. however, participating sites are expected to adhere to the rules and policies described in this document, in order to maintain the 6Bone as a quality tool for the deployment of, and transition to, IPv6 protocols and the products implementing them 🛠️

the following is in support of policing adherence to 6Bone rules and policies 👮‍♀️:

  1. Each pTLA site has committed to implement the 6Bone's rules and policies, and SHOULD try to ensure they are adhered to by sites within their administrative control, i.e., those to whom prefixes under their respective pTLA prefix have been delegated 🫶
  2. When a site detects an issue, it SHOULD first use the 6Bone registry to contact the site maintainer and work the issue 📞
  3. If nothing happens, or there is disagreement on what the right solution is, the issue SHOULD be brought to the 6Bone Operations Group 🙋‍♀️
  4. When the problem is related to a product issue, the site(s) involved SHOULD be responsible for contacting the product vendor and work toward its resolution 🧑‍💻
  5. When an issue causes major operational problems, backbone sites SHOULD decide to temporarily set filters in order to restore service 🚨

10. Security Considerations ✨

okay so bestie, this part is lowkey the most important bit 🫶 Wrong entries in routing tables usually mean unreachable sites 😭 So having guidelines to aggregate or reject routes is literally how you clean up the tables 🧹✨ The expectation is that if everyone follows these rules and policies, routing on the 6Bone gets way less sensitive to denial of service attacks caused by misleading routes 🛡️💅

The 6Bone is an IPv6 testbed meant to help IPv6 evolve and get deployed 🦋 So denial of service or packet disclosure are things you should expect 💀 But here's the tea: the pTLA where the attack came from has the ultimate responsibility for isolating and fixing problems like this 👑 And every 6Bone site is responsible for safely introducing new test systems into the 6Bone 🧪 by placing them at strategically safe places that have minimal impact on other 6Bone sites, in case bugs or misconfigurations happen 🙈

11. References 📚

okay here's the reading list, bestie 🌈

11.1. Normative and Informative References

  • [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 💜
  • [RFC 2471] Hinden, R., Fink, R. and J. Postel, "IPv6 Testing Address Allocation", RFC 2471, December 1998. 🎀
  • [RFC 2546] Durand, A. and B. Buclin, "6Bone Routing Practice", RFC 2546, March 1999. 🌸
  • [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. 🍓

12. Authors' Addresses 💌

Rob Rockell EMail: rrockell@sprint.net

Bob Fink EMail: fink@es.net

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

📦 where this page comes from