INTERNET-DRAFT Alain Durand, IMAG November 20, 1997 Expires May 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 May 20, 1998. Introduction ------------ 6bone routes have sometimes provide examples of bogus routes who introduced serious operational issues. This memo identifies some pathological cases and try to give some guidelines how 6bone nodes should handle them. This is ongoing work and lots of changes should be made to this text. It is only published as a starting point for a discussion. It will cover: 1) link local addresses 2) site local addresses 3) special case addresses: loopback addresses & unspecified addresses 4) multicast addresses 5) IPv4-mapped addresses 6) IPv4-compatible addresses 7) Yet undefined unicast addresses (from a different /3 prefix) 8) default routes 9) aggregation issues 10) tunnel issues 1) link local prefixes ----------------------- Link local prefixes MUST NOT be advertized. 2) site local addresses ----------------------- Site local prefixes SHOULD only be advertized within the site. Now the question is: what is a site? What about multi-sited nodes? There is a need for a precise definition of a site. 3) special case addresses ------------------------- a) loopback address ::1/128 Routers MAY have a route to the loopback interface. This route MUST NOT be advertised. b) unspecified address ::0/128 Router MUST NOT advertise it 4) multicast addresses ---------------------- Do programs using multicast addresses use the routing table? Some more work to be done here. Should multicast routes be advertised in regular unicast routing protocols ? 5) IPv4-mapped addresses ------------------------ For a dual-stack host, an IPv4-mapped address means: "use the IPv4 stack". What about IPv6 only hosts? Such routes may be useful if they point to a 'translation' machine. See header translation work. 6) IPv4-compatible addresses ---------------------------- The use of IPv4 compatible SHOULD be limited to end points of configured tunnels. 6bone routers SHOULD NOT route IPv4 compatible prefixes. 7) Yet undefined unicast addresses ---------------------------------- a) from a format prefix different from 2000::/3 6bone core routers SHOULD NOT advertise them and SHOULD NOT route them. b) from a prefix different from 3ffe::/16 (6bone prefix) open question. 8) Default routes ----------------- Sites MAY have default routes to their local provider, a local provider MAY have default routes to a more global provider. 6bone core routers SHOULD be default free. 9) Aggregation issues --------------------- Aggregation SHOULD be mandatory whenever possible. For example, a site border router SHOULD aggregate all prefixes to a /48 one. Some more work is obviously needed here. 10) Tunnel issues ----------------- Tunnels IPv6 endpoint addresses SHOULD be within the 6bone address space, i.e. link local addresses may be not enough. Open questions: a) what prefix length should be used for those tunnels? Options are: /128 /126 /124 /64. Note: see addr-arch draft. b) who 'owns' the tunnel prefix? (do we need DMZ?) 6bone routers SHOULD NOT advertise specific routes for tunnel prefixes. Tunneling hosts SHOULD NOT use the endpoint address of the tunnel as source address if they do not 'own' it. Similarly, tunneling host SHOULD NOT use IPv4 compatible addresses as source addres. 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