One document matched: draft-ietf-ngtrans-6bone-routing-issues-00.txt

INTERNET-DRAFT                                   Alain Durand, IMAG

November 20, 1997

Expires May 20, 1998






                    IPv6 routing issues


       <<draft-ietf-ngtrans-6bone-routing-issues-00.txt>




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