idnits 2.17.1 draft-ietf-ngtrans-6bone-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 125 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 27 has weird spacing: '...i.oz.au to le...' == Line 79 has weird spacing: '...special addre...' == Line 138 has weird spacing: '...used to route...' == Line 262 has weird spacing: '...egistry objec...' == Line 282 has weird spacing: '... 3. The site ...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1998) is 9477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 1897' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RIPE-181' is defined on line 367, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1897 (Obsoleted by RFC 2471) ** Obsolete normative reference: RFC 2283 (Obsoleted by RFC 2858) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Alain Durand 3 NGTRANS WG IMAG 4 Expires 20 November, 1998 Bertrand Buclin 5 Category: Informational AT&T Labs Europe 6 May 1998 8 6Bone Routing Practice 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its Areas, and its Working 16 Groups. Note that other groups may also distribute working documents as 17 Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six months. 20 Internet Drafts may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as reference 22 material or to cite them other than as a ``working draft'' or ``work in 23 progress.'' 25 Please check the 1id-abstracts.txt listing contained in the internet-drafts 26 Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 27 ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any 28 Internet Draft. 30 This memo provides information for the Internet community. This memo does 31 not specify an Internet standard of any kind. Distribution of this memo is 32 unlimited. 34 This draft expires October 30, 1998. 36 Copyright Notice 38 Copyright (C) The Internet Society (date). All Rights Reserved. 40 1 Introduction 42 The 6Bone is an environment supporting experimentation with the IPv6 43 protocols and products implementing it. As the network grows, the need for 44 common operation rules emerged. In particular, operation of the 6Bone 45 backbone is a challenge due to the frequent insertion of bogus routes by 46 leaf or even backbone sites. 48 This memo identifies guidelines on how 6Bone sites might operate, so that 49 the 6Bone can remain a quality experimentation environment and to avoid 50 pathological situations that have been encountered in the past. It defines 51 the 'best current practice' acceptable in the 6Bone for the configuration 52 of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior 53 Gateway Protocols (like BGP4+ [RFC 2283]). 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC 2119]. 59 2 Basic principles 61 The 6Bone is structured as a hierarchical network with pseudo Top Level 62 Aggregator (pTLA) sites, pseudo Next Level Aggregator (pNLA) sites and 63 leaf sites. This topology supports the IPv6 address aggregation 64 architecture as described in [1]. The 6Bone backbone is made of a mesh 65 interconnecting pTLAs only. pNLAs connect to one or more pTLAs and provide 67 transit service for leaf sites. 69 pTLA sites MUST use BGP4+ [RFC 2283] as the mandatory routing protocol for 70 exchanging routing information among them. 72 Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a 73 simple default route to their ISP. 75 3 Common Rules 77 This section details common rules governing the routing on the 6Bone. They 78 are derived from issues encountered on the 6Bone, with respect to the 79 routes advertised, handling of special addresses, and aggregation: 81 1) link local prefixes 83 2) site local prefixes 85 3) loopback prefix & unspecified prefix 87 4) multicast prefixes 89 5) IPv4-compatible prefixes 91 6) IPv4-mapped prefixes 93 7) default routes 95 8) Yet undefined unicast prefixes (from a different /3 prefix) 97 9) Inter site links issues 99 10) aggregation & advertisement issues 101 3.1 Link-local prefix 103 The link-local prefix (FE80::/10) MUST NOT be advertised through either an 104 IGP or an EGP. 106 By definition, the link-local prefix has a scope limited to a specific 107 link. Since the prefix is the same on all IPv6 links, advertising it in any 108 routing protocol does not make sense and, worse, may introduce nasty error 109 conditions. 111 Well known cases where link local prefixes could be advertised by mistake 112 include: 114 - a router advertising all directly connected network prefixes including 115 the link-local one. 117 - Subnetting of the link-local prefix. 119 In such cases, vendors should be urged to correct their code. 121 3.2 Site-local prefixes 123 Site local prefixes (in the FEC0::/10 range) MAY be advertized by IGPs or 124 EGPs within a site. The precise definition of a site is ongoing work 125 discussed in the IPng working group. 127 Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs. 129 3.3 Loopback and unspecified prefixes 131 The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT 132 be advertised by any routing protocol. 134 3.4 Multicast prefixes 136 Multicast prefixes MUST NOT be advertised by any unicast routing protocol. 137 Multicast routing protocols are designed to respect the semantics of 138 multicast and MUST therefore be used to route packets with multicast 139 destination addresses (in the range FF00::/8). 141 Multicast address scopes MUST be respected on the 6Bone. Only global scope 142 multicast addresses MAY be routed across transit pNLAs and pTLAs. There is 143 no requirement on a pTLA to route multicast packets. 145 Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be 146 routed across a pNLA to its leaf sites. 148 Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. 150 Obviously, link-local multicasts and node-local multicasts MUST NOT be 151 routed at all. 153 3.5 IPv4-compatible prefixes 155 Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. 156 As there is no real rationale today for doing that, these addresses SHOULD 158 NOT be used in the 6Bone. 160 The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. 162 IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or 163 pTLAs. 165 3.6 IPv4-mapped prefixes 167 IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4 address) MAY 168 be advertised by IGPs within a site. It may be useful for some IPv6 only 169 nodes within a site to have such a route pointing to a translation device. 171 IPv4-mapped prefixes MUST NOT be advertised by EGPs. 173 3.7 Default routes 175 6Bone core pTLA routers MUST be default-free. 177 pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do 178 the same for their leaf sites. 180 3.8 Yet undefined unicast prefixes 182 Yet undefined unicast prefixes from a format prefix other than 2000::/3 183 MUST NOT be advertised by any routing protocol in the 6Bone. In particular, 184 RFC1897 test addresses MUST NOT be advertised on the 6Bone. 186 Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) 187 is discussed in section 4, Routing policies, below. 189 3.9 Inter-site links 191 Global IPv6 addresses MUST be used for the end points of the inter-site 192 links. In particular, IPv4 compatible addresses MUST NOT be used for 193 tunnels. 195 Prefixes for those links MUST NOT be injected in the global routing tables. 197 3.10 Aggregation & advertisement issues 199 Route aggregation MUST be performed by any border router. 201 Sites or pNLAs MUST only advertise to their upstream provider the prefixes 202 assigned by that ISP unless otherwise agreed. 204 Site border router MUST NOT advertise prefixes more specific than the /48 205 ones allocated by their ISP. 207 pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless 208 special peering agreements are implemented. When such special peering 209 agreements are in place between any two or more pTLAs, care MUST be taken 210 not to leak the more specific prefixes to other pTLAs not participating 211 in the peering agreement. 213 4 Routing policies 215 6Bone backbone sites maintain the mesh into the backbone and provide an as 216 reliable as possible service, granted the 6Bone is an experimentation tool. 217 To achieve their mission, 6Bone backbone sites MUST maintain peerings with 218 at least 3 (three) other back bone sites. 220 The peering agreements across the 6Bone are by nature non-commercial, and 221 therefore SHOULD allow transit traffic through. 223 Eventually, the Internet registries will assign other TLAs than the 6Bone 224 one (currently 3FFE::/16). The organizations bearing those TLAs will 225 establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT 226 interconnect with this new IPv6 Internet, b ut transit across the 6Bone 227 will not be guaranteed. It will be left to each 6Bone backbone site to 228 decide whether it will carry traffic to or from the IPv6 Internet. 230 5 The 6Bone registry 232 The 6Bone registry is a RIPE-181 database with IPv6 extensions used to 233 store information about the 6Bone. Each 6Bone site MUST maintain the 234 relevant entries in the 6Bone registry (whois.6bone.net). In particular, 235 the following objects MUST be present: 237 - IPv6-site: site description 239 - Inet6num: prefix delegation 241 - Mntner: coordinate of site maintenance staff 243 Other objects MAY be maintained at the discretion of the sites, such as 244 routing policy descriptors, person or role objects. The Mntner object MUST 245 make reference to a role or person object, but those must not necessarily 246 reside in the 6Bone registry, they can be stored within any of the 247 Internet registry databases (RIPE, InterNIC, APNIC, ...). 249 6 Guidelines for new sites joining the 6Bone 251 New sites joining the 6Bone should seek to connect to a transit pNLA or a 252 pTLA within their region, and preferably as close as possible to their 253 existing IPv4 physical and routing path for Internet service. The 6Bone 254 registry is available to find out candidate ISPs. 256 Any site connected to the 6Bone MUST maintain a DNS server for forward name 257 looking and reverse address translation. The joining site MUST maintain the 258 6Bone registry objects relative to its site, and in particular the IPv6- 259 site and the MNTNER objects. 261 The upstream ISP MUST delegate the reverse address translation zone in DNS 262 to the joining site. The ISP MUST also create 6Bone registry objects 263 reflecting the delegated address space (inet6num:). 265 Up to date information about how to join the 6Bone is available on the 266 6Bone Web site at http://www.6bone.net. 268 7 Guidelines for 6Bone pTLA sites 270 6Bone pTLA sites are altogether forming the backbone of the 6Bone. In order 271 to ensure the highest level possible of availability and stability for the 272 6Bone environment, a few constraints are placed onto sites wishing to 273 become or stay a 6Bone pTLA: 275 1. The site MUST have experience with IPv6 on the 6Bone, at least as 276 a leaf site and preferably as a transit pNLA under an existing pTLA. 278 2. The site MUST have the ability and intent to provide "production- 279 like" 6Bone backbone service to provide a robust and operationally 280 reliable 6Bone backbone. 282 3. The site MUST have a potential "user community" that would be 283 served by becoming a pTLA, e.g., the requester is a major player in a 284 region, country or focus of interest. 286 4. Must commit to abide by the 6Bone backbone operational rules and 287 policies as defined in the present document. 289 When a candidate site seeks to become a pTLA site, it will apply for it to 290 the 6Bone Operations group (see below) by bringing evidences it meets the 291 above criteria. 293 8 6Bone Operations group 295 The 6Bone Operations group is the body in charge of monitoring the 296 adherence to the present rules, and will take the appropriate actions to 297 correct deviations. Membership in the 6Bone Operations group is mandatory 299 for, and restricted to, any site connecte d to the 6Bone. 301 The 6Bone Operations group is currently defined by those members of the 302 existing 6Bone mailing list, i.e., 6bone@isi.edu, who represent sites 303 participating on the 6Bone. Therefore it is incumbent on relevant site 304 contacts to join the mailing list. Instructions on how to join the list are 305 maintained on the 6Bone web site at http://www.6bone.net. 307 9 Common rules enforcement 309 Participation in the 6Bone is a voluntary and benevolent undertaking. 310 However, participating sites are expected to adhere to the rules described 311 in this document, in order to maintain the 6Bone as quality tool for 312 experimenting with the IPv6 protocols and products implementing them. 314 The following processes are proposed to help enforcing the 6Bone rules: 316 - Each pTLA site has committed when requesting their pTLA to implement the 317 rules, and to ensure they are respected by sites within their 318 administrative control (i.e. those to who prefixes have been delegated). 320 - When a site detects an issue, it will first use the 6Bone registry to 321 contact the site maintainer and work the issue. 323 - If nothing happens, or there is disagreement on what the right solution 324 is, the issue can be brought to the 6Bone Operations group. 326 - When the problem is related to a product issue, the site(s) involved is 327 responsible for contact the product vendor and work toward its resolution. 329 - When an issue causes major operational problems, backbone sites may 330 decide to temporarily set filters in order to restore service. 332 10 Security considerations 334 The result of bogus entries in routing tables is usually unreachable sites. 335 Having guidelines to aggregate or reject routes will clean up the routing 336 tables. It is expected that using these guidelines, routing on the 6Bone 337 will be less sensitive to denial of service attacks due to misleading 338 routes. 340 The 6Bone is a test network. Therefore, denial of service, packet 341 disclosure,... are to be expected. 343 11 Acknowledgements 345 This document is the result of shared experience on the 6Bone. Special 346 thanks go to Bob Fink for the hard work make to date to direct the 6Bone 347 effort, to David Kessens for the 6Bone registry, and to Guy Davies for his 348 insightful contributions. 350 12 References 352 [1] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 353 January 1998, internet draft, work in progress, 354 356 [RFC 1897] R. Hinden & J. Postel., IPv6 Testing Address Allocation. 357 January 1996. (Status: OBSOLETE) 359 [RFC 2080] Malkin, G., Minnear, R., "RIPng for IPv6", January 1997. 361 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 362 Levels", BCP 14, RFC 2119, March 1997. 364 [RFC 2283] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 365 Extensions for BGP-4", March 98 367 [RIPE-181] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. 368 Karrenberg, M. Terpstra, and J. Yu. Representation of IP 369 Routing Policies in a Routing Registry. Technical Report ripe- 370 181, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994. 372 13 Author address 374 Alain Durand 375 Institut d'Informatique et de Mathematiques Appliquees de Grenoble 376 IMAG BP 53 377 38041 Grenoble CEDEX 9 France 378 Phone : +33 4 76 63 57 03 379 Fax : +33 4 76 51 49 64 380 E-Mail: Alain.Durand@imag.fr 382 Bertrand Buclin 383 AT&T International S.A. 384 Route de l'aeroport 31, CP 72 385 CH-1215 Geneve 15 (Switzerland) 386 Phone : +41 22 929 37 40 387 Fax : +41 22 929 39 84 388 E-Mail: Bertrand.Buclin@ch.att.com 390 14 Full Copyright Statement 392 "Copyright (C) The Internet Society (date). All Rights Reserved. 394 This document and translations of it may be copied and furnished 395 to others, and derivative works that comment on or otherwise 396 explain it or assist in its implmentation may be prepared, copied, 397 published and distributed, in whole or in part, without 398 restriction of any kind, provided that the above copyright notice 399 and this paragraph are included on all such copies and derivative 400 works. However, this document itself may not be modified in any 401 way, such as by removing the copyright notice or references to the 402 Internet Society or other Internet organizations, except as needed 403 for the purpose of developing Internet standards in which case the 404 procedures for copyrights defined in the Internet Standards 405 process must be followed, or as required to translate it into 406 languages other than English. 408 The limited permissions granted above are perpetual and will not 409 be revoked by the Internet Society or its successors or assigns. 411 This document and the information contained herein is provided on 412 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 413 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 414 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 415 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.