new routing issue draft

Alain Durand Alain.Durand@imag.fr
Tue, 20 Jan 1998 18:57:31 +0100


--
--PART-BOUNDARY=.1980120185731.ZM3035.imag.fr
Content-Type: text/plain; charset=us-ascii

Hi

I've submited a new version of the routing-issue draft
draft-ietf-ngtrans-6bone-routing-issues-01.txt

I've tried to include all feedbacks from last IETF meetings.

Here is a copy of it for the impatients.

	- Alain.


--PART-BOUNDARY=.1980120185731.ZM3035.imag.fr
Content-Type: text/plain ; name="draft-ietf-ngtrans-6bone-routing-issues-01.txt" ; charset=us-ascii
Content-Disposition: attachment ; filename="draft-ietf-ngtrans-6bone-routing-issues-01.txt"
X-Zm-Content-Name: draft-ietf-ngtrans-6bone-routing-issues-01.txt


INTERNET-DRAFT                                   Alain Durand, IMAG
January 19, 1997
Expires July 20, 1998






                    IPv6 routing issues


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


--PART-BOUNDARY=.1980120185731.ZM3035.imag.fr--