idnits 2.17.1 draft-ietf-ngtrans-harden-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 561 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The draft header indicates that this document obsoletes RFC2546, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 304 has weird spacing: '...parties are a...' == Line 499 has weird spacing: '...tacting the p...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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.) -- 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 (21 December 1999) is 8886 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 2373' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC 2471' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC 2546' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC 2080' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RIPE-181' is defined on line 543, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2471 (Obsoleted by RFC 3701) ** Obsolete normative reference: RFC 2546 (Obsoleted by RFC 2772) ** Obsolete normative reference: RFC 2283 (Obsoleted by RFC 2858) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Rockell (Sprint) 2 Obsoletes: 2546 R. Fink (ESnet) 3 Category: Informational 21 December 1999 5 6Bone Backbone Routing Guidelines 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 29 This draft expires on 21 June 2000. 31 Abstract 33 The 6Bone is an Ipv6 testbed to assist in the evolution and deployment 34 of IPv6. Because of this, it is important that the core backbone of the 35 IPv6 network maintain stability, and that all operators have a common 36 set of rules and guildelines by which to deploy IPv6 routing equipment. 38 This document provides a set of guildelines for all 6bone routing 39 equipment operators to use as a reference for efficient and stable 40 deployment of 6bone routing systems. As the complexity of the 6Bone 41 grows,the adherence to a common set of rules becomes increasingly 42 important in order for an efficient, scalable backbone to exist. 44 Table of Contents 46 1. Introduction....................................................... 47 2. Scope of this document............................................. 48 3. Common Rules for the 6bone......................................... 49 3.1 Link-local prefixes 50 3.2 Site-local prefixes 51 3.3 Loopback and unspecified prefixes 52 3.4 Multicast prefixes 53 3.5 IPv4 compatible prefixes 54 3.6 IPv4-mapped prefixes 55 3.7 Default routes 56 3.8 Yet undefined unicast prefixes 57 3.9 Inter-site links 58 3.10 6to4 Prefixes 59 3.11 Aggregation & advertisement issues 60 4. Routing Policies for the 6bone..................................... 61 5. The 6Bone Registry................................................. 62 6. Guidelines for new sites joining the 6Bone......................... 63 7. Guidelines for 6Bone pTLA sites.................................... 64 8. 6Bone Operations group............................................. 65 9. Common rules enforcement for the 6bone............................. 66 10. Security Considerations........................................... 67 11. References........................................................ 68 12. Authors' Addresses................................................ 70 1. Introduction 72 The 6Bone is an IPv6 testbed to assist in the evolution and deployment 73 of IPv6. Because of this, it is important that the core backbone of the 74 IPv6 network maintain stability, and that all operators have a common 75 set of rules and guidelines by which to deploy IPv6 routing equipment. 77 This document provides a set of guidelines for all 6bone routing 78 equipment operators to use as a reference for efficient and stable 79 deployment of 6bone routing systems. As the complexity of the 6Bone 80 grows,the adherence to a common set of rules becomes increasingly 81 important in order for an efficient, scalable backbone to exist. 83 This document uses BGP-4 with Multiprotocol Extensions for BGP-4 as 84 defined [RFC 2283], commonly referred to as BGP4+, as the currently 85 accepted EGP. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC 2119]. 91 2. Scope of this document 93 This document is a best-practices Informational document aimed at IPv6 94 entities which operate under the 6Bone IPv6 testbed TLA allocation. 96 3. Common Rules for the 6bone 98 This section details common rules governing the routing of the 6Bone. 99 They are derived from the issues encountered on the 6Bone, with respect 100 to the routes advertised, handling of special addresses, and 101 aggregation: 103 1) link local prefixes 105 2) site local prefixes 107 3) loopback and unspecified prefixes 109 4) multicast prefixes 111 5) IPv4-compatible prefixes 113 6) IPv4-mapped prefixes 115 7) default routes 117 8) yet undefined unicast prefixes (from a different /3 prefix) 119 9) inter-site links issues 121 10) 6to4 prefixes 123 11) aggregation & advertisement issues 125 3.1 Link-local prefixes 127 This link-local prefix (FE80::/10) MUST NOT be advertised through either 128 an IGP or an EGP. Under no circumstance should this prefix be seen in 129 the 6Bone backbone routing table. 131 By definition, the link-local prefix has a scope limited to a specific 132 link. Since the prefix is the same on all IPv6 links, advertising it in 133 any routing protocol does not make sense and, worse, may introduce nasty 134 error conditions. 136 Well known cases where link-local prefixes could be advertised by 137 mistake include, but are not limited to: 139 - a router advertising all directly connected network prefixes 140 including the link-local one 142 - subnetting of the link-local prefix 144 In such cases, vendors should be urged to correct their code. While 145 vendors should be encouraged to fix the problem, the ultimate 146 responsibility lies on the operator of that IPv6 site to correct the 147 problem through whatever means necessary. 149 Should a pTLA discover link-local prefixes coming from another pTLA, 150 it is the responsibility of the pTLA leaking the routes to filter these, 151 and correct the problem in a timely fashion. Should a pTLA discover that 152 a downstream of that pTLA is leaking link-local prefixes, it is the 153 pTLA's responsibility to ensure that these prefixes are not leaked to 154 other pTLA's, or to other downstreams of that pTLA. 156 Failure to filter such routes in a timely fashion may result in the 157 manual shutting down of BGP4+ sessions to that pTLA, from other pTLA's. 159 (Also, it is each pTLA, pNLA, and end-site's responsibility to not 160 only filter their own BGP4+ sessions appropriately to peers, but to 161 filter routes coming from peers as well, and to only allow those 162 routes that fit the aggregation model, and do not cause operational 163 problems). 165 3.2 Site-local prefixes 167 Site local prefixes (in the FEC0::/10 range) MAY be advertised by IGP's 168 or EGP's within a site. The precise definition of a site is ongoing work 169 of the IPng working group, but should generally include a group of nodes 170 that are operating under one administrator or group of administrators, 171 or a group of nodes which are used for a common purpose. 173 Site-local prefixes MUST NOT be advertised across transit pNLAs, pTLAs, 174 or leaf-sites. 176 Again, should site-local prefixes be leaked outside of a given site, 177 it is the responsibility of the site to fix the problem in a timely 178 manner, either through filters, or via other means which remove the 179 operational impact that those prefixes had on the peering sites 180 involved. However, every site SHOULD filter not only outbound on their 181 EGP, but also inbound, in order to ensure proper routing announcements 182 are not only sent, but also received. 184 3.3 Loopback and unspecified prefixes 186 The loopback prefix (::1/128) and the unspecified prefix (::0/128) 187 MUST NOT be advertised by any routing protocol. 189 The same responsibility lies with the party guilty of advertising the 190 loopback or unspecified prefix as in Section 3.1 and 3.2. 192 3.4 Multicast prefixes 194 Multicast prefixes MUST NOT be advertised by any unicast routing 195 protocol. Multicast routing protocols are designed to respect the 196 semantics of multicast and MUST therefore be used to route packets with 197 multicast destination addresses (in the range of FF00::/8). 199 Multicast address scopes MUST be respected on the 6Bone. Only global 200 scope multicast addresses MAY be routed across transit pNLAs and pTLAs. 201 There is no requirement on a pTLA to route multicast packets at the 202 time of the writing of this draft. 204 Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) 205 MAY be routed across a pNLA to its leaf sites. 207 Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. 209 Link-local multicasts and node-local multicasts MUST NOT be routed at 210 all. 212 3.5 IPv4 compatible prefixes 214 Sites may choose to use IPv4 compatible addresses (::a.b.c.d where 215 a.b.c.d represents the octets of an IPv4 address) internally. As there 216 is no real rationale today for doing so, these address SHOULD NOT be 217 used or routed in the 6Bone. 219 The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. 221 IPv4 compatible prefixes MUST NOT be advertised by EGPs to transit 222 pNLAs or pTLAs. 224 Should ::/96 IPv4-compatible prefixes be leaked into an EGP, it is the 225 responsibility of the party who is advertising the route to fix the 226 problem, either through proper filters, or through other means, while 227 it remains in the best interest of all particiapants of the 6Bone to 228 filter both outbound and inbound at their IGP borders. 230 3.6 IPv4-mapped prefixes 232 IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d represents the 233 octets of an IPv4 address) MAY be advertised by IGPs within a site. It 234 may be useful for some IPv6 only nodes within a site to have such a 235 route pointing to a translation device, to aid in deployment of IPv6. 237 IPv4-mapped prefixes MUST NOT be advertised by EGPs. 239 3.7 Default routes 241 6Bone core pTLA routers MUST be default-free. 243 pTLAs MAY advertise a default route to any downstream peer (non-pTLA 244 site). Transit pNLAs MAY advertise a default route to any of their 245 downstreams (other transit pNLA or leaf site). 247 Should a default route be redistributed into an EGP and found on any 248 pTLA EGP sessions, it is the responsibility of the pTLA to fix this 249 problem immediately upon realization of the route's existence, and the 250 responsibility of the guilty pTLA to push the entity from which the 251 default route was originated, should the default route have originated 252 from downstream of a pTLA. 254 3.8 Yet undefined unicast prefixes 256 Yet undefined unicast prefixes from a format prefix other than 2000::/3 257 MUST NOT be advertised by any routing protocol in the 6Bone. In 258 particular, RFC 2471 test addresses MUST NOT be advertised on the 6Bone. 260 Routing of global unicast prefixes outside the 6Bone range (3ffe::/16), 261 and routing of global unicast prefixes yet undelegated in the range 262 (3ffe::/16) are discussed in section 4, Routing policies, below. 264 3.9 Inter-site links 266 Global IPv6 addresses must be used for the end points of inter-site 267 links. In particular, IPv4 compatible addresses MUST NOT be used for 268 tunnels. 270 Sites MAY use Other addressing schemes for Inter-site links, but these 271 addresses MUST NOT be advertised into the IPv6 global routing table. 273 Prefixes for inter-site links MUST NOT be injected in the global routing 274 tables. 276 3.10 6to4 Prefixes 278 The 6to4 prefix, or some portion thereof, MAY be announced 279 by any pTLA which has a current implementation of 6to4 in their IPv6 280 network. However, as 6to4 implementors gain more operational 281 experience, it MAY be necessary to change this in some way. 282 At the time of the writing of this docuement, any pTLA MAY announce 283 the 6to4 prefix into global EBGP. However, in order to announce this 284 block, the pTLA MUST have a 6to4 router active, sourcing this prefix 285 announcement. 287 This section subject to change, and MAY vary, depending on 6to4 progress 288 within the NGTRANS working group. 290 3.11 Aggregation & advertisement issues 292 Route aggregation MUST be performed by any border router talking EGP 293 with any other IPv6 sites. More-specifics MUST NOT be leaked into or 294 across the IPv6 6Bone backbone. 296 4. Routing Policies for the 6bone 298 Leaf sites or pNLAs MUST only advertise to an upstream provider the 299 prefixes assigned by that provider. Advertising a prefix assigned by 300 another provider to a provider is not acceptable, and breaks the 301 aggregation model. A site MUST NOT advertise a prefix from another 302 provider to a provider as a way around the multi-homing problem. 303 However, in the interest of testing new solutions, one may break this 304 policy, so long as ALL affected parties are aware of this test, and all 305 agree to support this testing. These policy breaks MUST NOT affect the 306 6bone routing table globally. 308 To clarify, if one has two upstream pNLA or pTLA providers, (A and B for 309 this example), one MUST only announce the prefix delegated to one by 310 provider A to provider A, and one MUST only announce the prefeix 311 delegated by one from provider B upstream to provider B. There exists 312 no circumstance where this should be violated, as it breaks the 313 aggregation model, and could globally affect routing decisions if 314 downstreams are able to leak other providers' more specific delegations 315 up to a pTLA. As the IPNG working group works through the multi-homing 316 problem, there may be a need to alter this rule slightly, to test new 317 strategies for deployment. However, in the case of current 318 specifications at the time of this writing, there is no reason to 319 advertise more specifics, and pTLA's MUST adhere to the current 320 aggregation model. 322 Site border routers for pNLA or leaf sites MUST NOT advertise prefixes 323 more specific (longer) than the prefix that was allocated by their 324 upstream provider. 326 All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA 327 delegation (currently /24 or /28) to other 6bone pTLAs unless special 328 peering arrangements are implemented. When such special peering 329 aggreements are in place between any two or more 6bone pTLAs, care MUST 330 be taken not to leak the more specifics to other 6bone pTLAs not 331 participating in the peering aggreement. 6bone pTLAs which have such 332 agreements in place MUST NOT advertise other 6bone pTLA more specifics 333 to downstream 6bone pNLAs or leaf sites, as this will break the best-path 334 routing decision. 336 The peering agreements across the 6Bone may be by nature non-commercial, 337 and therefore MAY allow transit traffic, if peering agreements of this 338 nature are made. However, no pTLA is REQUIRED to give or receive transit 339 service from another pTLA. 341 Eventually, the Internet registries will assign prefixes under other 342 than the 6Bone TLA (3FFE::/16). As of the time this document was 343 written in 1999, the Internet registries were starting to assign /35 344 sub-TLA (sTLA) blocks from the 2001::/16 TLA. Others will certainly be 345 used in the future. 347 The organizations receiving prefixes under these newer TLAs would be 348 expected to want to establish peering and connectivity relationships 349 with other IPv6 networks, both in the newer TLA space and in the 6bone 350 pTLA space. Peering between new TLA's and the current 6Bone pTLA's MAY 351 occur, and details such as transit, and what routes are received by 352 each, are outside of general peering rules as stated in this draft, and 353 are left up to the members of those TLA's and pTLA's that are 354 establishing said peerings. However, it is expected that most of the 355 rules discussed here are equally applicable to new TLAs. 357 5. The 6Bone Registry 359 The 6Bone registry is a RIPE-181 database with IPv6 extensions used to 360 store information about the 6Bone, and its sites. The 6bone is 361 accessible at: 363 ) 365 Each 6Bone site MUST maintain the relevant entries in the 6Bone 366 registry. In particular, the following object MUST be present for all 367 6Bone leaf sites, pNLAs and pTLAs: 369 -IPv6-site: site description 371 -Inet6num: prefix delegation (one record MUST exist for each delegation) 373 -Mntner: contact info for site maintance/administration staff. 375 Other object MAY be maintained at the discretion of the sites such as 376 routing policy descriptors, person, or role objects. The Mntner object 377 MUST make reference to a role or person object, but those MAY NOT 378 necessarily reside in the 6Bone registry. They can be stored within any 379 of the Internet registry databases (ARIN, APNIC, RIPE-NCC, etc.) 381 6. Guidelines for new sites joining the 6Bone 383 New sites joining the 6Bone should seek to connect to a transit pNLA or 384 a pTLA within their region, and preferably as close as possible to their 385 existing IPv4 physical and routing path for Internet service. The 6Bone 386 web site at has various information and tools to 387 help find candidate 6bone networks. 389 Any site connected to the 6Bone MUST maintain a DNS server for forward 390 name lookups and reverse address lookups. The joining site MUST 391 maintain the 6Bone objects relative to its site, as describe in 392 section 5. 394 The upstream provider MUST delegate the reverse address translation 395 zone in DNS to the joining site, or have an agreement in place to 396 perform primary DNS for that downstream. The provider MUST also create 397 the 6Bone registry inet6num object reflecting the delegated address 398 space. 400 Up to date informatino about how to join the 6Bone is available on the 401 6Bone Web site at . 403 7. Guidelines for 6Bone pTLA sites 405 The following rules apply to qualify for a 6Bone pTLA allocation. It 406 should be recognized that holders of 6Bone pTLA allocations are expected 407 to provide production quality backbone network services for the 6Bone. 409 1. The pTLA Applicant must have a minimum of three (3) months 410 qualifying experience as a 6Bone end-site or pNLA transit. 411 During the entire qualifying period the Applicant must be 412 operationally providing the following: 414 a. Fully maintained, up to date, 6Bone Registry entries for their 415 ipv6-site inet6num, mntner, and person objects, including each 416 tunnel that the Applicant has. 418 b. Fully maintained, and reliable, BGP4+ peering and connectivity 419 between the Applicant's boundary router and the appropriate 420 connection point into the 6Bone. This router must be IPv6 421 pingable. This criteria is judged by members of the 6Bone 422 Operations Group at the time of the Applicant's pTLA request. 424 c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) 425 entries for the Applicant's router(s) and at least one host 426 system. 428 d. A fully maintained, and reliable, IPv6-accessible system 429 providing, at a mimimum, one or more web pages, describing the 430 Applicant's IPv6 services. This server must be IPv6 pingable. 432 2. The pTLA Applicant MUST have the ability and intent to provide 433 "production-quality" 6Bone backbone service. Applicants must 434 provide a statement and information in support of this claim. 435 This MUST include the following: 437 a. A support staff of two persons minimum, three preferable, with 438 person attributes registered for each in the ipv6-site object 439 for the pTLA applicant. 441 b. A common mailbox for support contact purposes that all support 442 staff have acess to, pointed to with a notify attribute in the 443 ipv6-site object for the pTLA Applicant. 445 3. The pTLA Applicant MUST have a potential "user community" that 446 would be served by its becoming a pTLA, e.g., the Applicant is a 447 major provider of Internet service in a region, country, or 448 focus of interest. Applicant must provide a statement and 449 information in support this claim. 451 4. The pTLA Applicant MUST commit to abide by the current 6Bone 452 operational rules and policies as they exist at time of its 453 application, and agree to abide by future 6Bone backbone 454 operational rules and policies as they evolve by consensus of the 455 6Bone backbone and user community. 457 When an Applicant seeks to receive a pTLA allocation, it will apply to 458 the 6Bone Operations Group (see section 8 below) by providing to the 459 Group information in support of its claims that it meets the criteria 460 above. 462 8. 6Bone Operations Group 464 The 6Bone Operations Group is the group in charge of monitoring and 465 policing adherence to the current rules. Membership in the 6Bone 466 Operations Group is mandatory for, and restricted to, sites connected 467 to the 6Bone. 469 The 6Bone Operations Group is currently defined by those members of 470 the existing 6Bone mailing list who represent sites participating in 471 the 6Bone. Therefore it is incumbent on relevant site contacts to join 472 the 6Bone mailing list. Instructions on how to join the list are 473 maintained on the 6Bone web site at < http://www.6bone.net>. 475 9. Common rules enforcement for the 6bone 477 Participation in the 6Bone is a voluntary and benevolent undertaking. 478 However, participating sites are expected to adhere to the rules and 479 policies described in this document in order to maintain the 6Bone as 480 a quality tool for the deployment of, and transition to, IPv6 protocols 481 and the products implementing them. 483 The following is in support of policing adherence to 6Bone rules and 484 policies: 486 1. Each pTLA site has committed to implement the 6Bone's rules and 487 policies, and SHOULD try to ensure they are adhered to by sites 488 within their administrative control, i.e. those to who prefixes 489 under their respective pTLA prefix have been delegated. 491 2. When a site detects an issue, it SHOULD first use the 6Bone 492 registry to contact the site maintainer and work the issue. 494 3. If nothing happens, or there is disagreement on what the right 495 solution is, the issue SHOULD be brought to the 6Bone Operations 496 Group. 498 4. When the problem is related to a product issue, the site(s) 499 involved SHOULD be responsible for contacting the product vendor 500 and work toward its resolution. 502 5. When an issue causes major operational problems, backbone sites 503 SHOULD decide to temporarily set filters in order to restore 504 service. 506 10. Security Considerations 508 The result of incorrect entries in routing tables is usually unreachable 509 sites. Having guidelines to aggregate or reject routes will clean up 510 the routing tables. It is expected that using these rules and policies, 511 routing on the 6Bone will be less sensitive to denial of service attacks 512 due to misleading routes. 514 The 6Bone is an IPv6 testbed to assist in the evolution and deployment 515 of IPv6. Therefore, denial of service or packet disclosure are to be 516 expected. However, it is the pTLA from where the attack originated who 517 has ultimate responsibility for isolating and fixing problems of this 518 nature. It is also every 6Bone site's responsibility to safely introduce 519 new test systems into the 6Bone, by placing them at a strategically safe 520 places which will have minimal impact on other 6Bone sites, should bugs 521 or misconfigurations occur. 523 11. References 525 [RFC 2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 526 Architecture", RFC 2373, July 1998. 528 [RFC 2471] Hinden, R., Fink, R. and J. Postel (deceased), "IPv6 529 Testing Address Allocation", RFC 2471, December 1998. 531 [RFC 2546] Durand, A., Buclin, B, "6Bone Routing Practice", 532 RFC 2546, March 1999 534 [RFC 2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 535 January 1997. 537 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, 541 "Multiprotocol Extensions for BGP-4", RFC 2283, March 1998. 543 [RIPE-181] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., 544 Karrenberg, D., Terpstra, M. and J. Yu, Representation 545 of IP Routing Policies in a Routing Registry. Technical 546 Report ripe-181, RIPE, RIPE NCC, Amsterdam, Netherlands, 547 October 1994. 549 12. Authors' Addresses 551 Rob Rockell 552 rrockell@sprint.net 554 Bob Fink 555 fink@es.net