new routing issue draft

[Alain Durand]

INTERNET-DRAFT                                   Alain Durand, IMAG
March 29, 1999                                Bertrand Buclin, AT&T
Expires September 30, 1998






                    IPv6 routing issues


       <draft-ietf-ngtrans-6bone-routing-issues-02.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 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