INTERNET-DRAFT Alain Durand, IMAG March 29, 1999 Bertrand Buclin, AT&T Expires September 30, 1998 IPv6 routing issues Status of this Memo ------------------- This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as 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 draft expires September 30, 1998. Introduction ------------ Operation of the 6bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies some pathological cases and gives some guidelines on how 6bone sites should handle them. It defines the 'best current practice' acceptable in the 6bone for the config- uration of both Interior Gateway Protocols (like RIPng) and Exterior Gateway Protocols (like BGP4+). Basic principles ---------------- The 6bone is structured as a hierarchical network with pseudo TLA (pTLA), pseudo NLA (pNLA) and leaf sites. 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. BGP4+ is the mandatory routing protocol used for exchanging routing information among pTLAs. Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP. This memo will cover: 1) link local prefixes 2) site local prefixes 3) special case prefixes: loopback prefix & unspecified prefix 4) multicast prefixes 5) IPv4-mapped prefixes 6) IPv4-compatible prefixes 7) Yet undefined unicast prefixes (from a different /3 prefix) 8) default routes 9) agregation & advertisement issues 10) Inter site tunnel issues 1) link local prefixes ---------------------- Link local prefixes MUST NOT be advertized through neither 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, may introduce nasty error conditions. Well known dangerous cases where link local prefixes could be advertised by mistake are: - a router advertising all directly connected networks including link local ones. - subnets of the link local prefix In such cases, vendors should be urged to correct their code. 2) site local prefixes ---------------------- Site local prefixes MAY be advertized 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) special case prefixes ------------------------ a) loopback prefix ::1/128 b) unspecified prefix ::/128 Loopback prefix and unspecified prefix MUST NOT be advertised by any routing protocol. 4) multicast prefixes --------------------- Multicast prefixes MUST NOT be advertised by any unicast routing protocol. 5) IPv4-mapped prefixes ----------------------- IPv4-mapped prefixes MAY be advertised by IGPs withing 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. 6) IPv4-compatible prefixes --------------------------- Sites may choose to use IPv4 compatible addresses internally. As they is no real rationale today for doing that, this practice SHOULD be discouraged 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. 7) yet undefined unicast prefixes ---------------------------------- a) from a format prefix different from 2000::/3 b) from a prefix different from 3ffe::/16 (6bone prefix) Such prefixes MUST NOT be advertised by any routing protocol in the 6bone. In particular, RFC1897 test addresses MUST NOT be advertised on the 6bone. 8) default routes ----------------- 6bone core pTLA routers MUST be default free. pTLAs MAY advertise a default route to its pNLAs. Transit pNLAs MAY do the same for their leaf sites. 9) agregation & 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 agreement are implemented. 10) inter site links -------------------- 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. Security considerations ----------------------- The result of bogus routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using this guidelines, routing will be less sensitive to denial of service attacks due to misleading routes. The 6bone is a test network. Therefore, denial of service, packet disclosure,... are to be expected. Author address -------------- 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 E-Mail: 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 E-Mail: Bertrand.Buclin@ch.att.com