INTERNET-DRAFT Alain Durand, IMAG January 19, 1997 Expires July 20, 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 July 20, 1998. Introduction ------------ The 6bone provides examples of bogus routes which introduced serious operational issues. This memo identifies some pathological cases and gives some guidelines on how 6bone sites should handle them. It defines the 'best current practise' acceptable in the 6bone for the config- uration of both Interior Gateway Protocols (like RIPng) and Exterior Gateway Protocols (like BGP4+). NB: Core routers used in pTLA sites MUST use BGP4+. 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) aggregation issues 10) Inter site tunnel issues 1) link local prefixes ---------------------- Link local prefixes MUST NOT be advertized. 2) site local prefixes ---------------------- Site local prefixes MAY be advertized by IGPs within a site. The precise definition of a site is ongoing work discussed in IPng working group. Site local prefixes MUST NOT be advertised by EGPs. 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 usefull for some 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 practise should be discouraged in the 6bone. It is believed that the use of IPv4 compatible SHOULD be limited to end points of configured tunnels. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. Other IPv4-compatible prefixes MUST NOT be advertised by IGPs. IPv4-compatible prefixes MUST NOT be advertised by EGPs. 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. 8) Default routes ----------------- 6bone core pTLA routers MUST be default free. 9) Aggregation issues --------------------- Aggregation SHOULD be mandatory whenever possible. Site border router MUST aggregate all interior prefixes to a /48 one. pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs. Sites MUST NOT do proxy aggregation, i.e. sites MUST NOT aggregate on behalf of other sites. 10) Inter site tunnel issues ---------------------------- Sites MAY use a /128 prefix taken from their own address space to give an IPv6 address to their endpoint of the tunnels. 11) 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. 12) 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