[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                               G. Chelius
Document: draft-chelius-router-autoconf-00.txt                E. Fleury
13 June 2002                                              Inria, France
                                                             L. Toutain
                                                  ENST Bretagne, France



            Using OSPFv3 for IPv6 router autoconfiguration
                <draft-chelius-router-autoconf-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.


   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 and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document proposes the definition of three new OSPFv3 LSA types
   for auto-configuration of IPv6 networks with routers by allowing a
   consensus on the SLA part of the IPv6 address for each link of the
   network.


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   1. Overview........................................................2
   2. Conventions used in this document...............................2
   3. Algorithm description...........................................3
   3.1. Merging of a new router.......................................3
   3.2. Merging of several networks...................................4
   3.3. Use with OSPF Areas...........................................4
   4. Routers internal data structures................................4


Chelius, Fleury, Toutain       Expires 13 December 2002               1
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   5. Definition of LSAs..............................................5
   5.1. SLA-Link LSA..................................................5
   5.2. SLA-Area LSA..................................................5
   5.3. TLA-Site LSA..................................................6
   6. Security Considerations.........................................6
   7. IANA consideration..............................................7
   8. References......................................................8
   A. LSA Format......................................................8
   A.1. SLA-Link LSA Format...........................................8
   A.2. SLA-Area LSA Format...........................................8
   A.3. TLA-Site LSA Format...........................................9
   Author's Addresses.................................................9


1. Overview

   Auto-configuration in IPv6 has been defined for hosts, but knowledge
   of the network topology is still required for routers configuration
   since the SLA part of the IPv6 address reflects the topology. This
   is not a problem in the context of large companies but it may limit
   the spread of IPv6 for small companies or for home networking. In
   this latter case, even if the network size is limited, the topology
   can be complex due to the use of different technologies (HomePNA,
   IEEE 802.11, Bluetoothà). It is difficult to delegate the network
   configuration to the ISP since several routers may be necessary. In
   a simple model, the edge router connected to the ISP forwards
   packets to the different supports used to compose the home network.
   This model is very restrictive since, for instance, some wireless
   networks may be directly unreachable from the edge router but
   accessible from some intermediary routers. The home network may be
   multi-homed, since several accesses (GPRS, ADSL,à) may be available
   at the same time. The home network may also evolve dynamically as,
   for example, Bluetooth links may leave or enter the network.

   Our proposal is to define three new OSPFv3 LSAs to allow automatic
   configuration of the SLA part of an IPv6 address. Our algorithm
   guaranties consensus and a strong stability for the SLA chosen by a
   given link and uniqueness of the TLA-SLA association in a site. One
   or more edge routers can connect the home network to ISPs. These
   edge routers can be configured by standard means to learn the TLA
   from the ISP. Site-local TLA (FEC0::/48) can be used in any case,
   but must be used explicitly when no other global TLA is advertised.

   The protocol can also work if the network is splited into OSPF
   areas. This is not pure zero-configuration since areas cannot be
   discovered automatically. With areas, some protocol enhancements can
   be defined to improve scalability by prefix aggregation.


2. Conventions used in this document



Chelius, Fleury, Toutain       Expires 13 December 2002               2
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   This document uses terms from the OSPFv3 protocol as described in
   RFC-2740 [RFC2740].

   In addition, this draft uses the following terms:

   o TLA: the first 48 bits of an IPv6 address.

   o SLA: the 16 following bits of an IPv6 address.

   o TLA-SLA association: concatenation of a TLA and a SLA that forms
   the 64-bits prefix of an IPv6 address.

   o Site: an OSPF site corresponds to an OSPF AS (autonomous system)

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119
   [RFC2119].


3. Algorithm description

   Three OSPFv3 LSAs are defined in this protocol:

   o SLA-Link LSA: it carries the SLA chosen by the Designated Router
   on the link. The scope of this LSA is the link. This LSA is used to
   generate a consensus about the link SLA.

   o SLA-Area: it carries the SLA obtained by consensus on the link.
   The scope of this LSA is the area. This LSA is used to detect and
   avoid SLA collisions between different links of the network.

   o TLA-Site: it carries the TLA(s) chosen by the ISP(s). The scope of
   this LSA is the OSPF network. This LSA is used to generate prefixes
   by concatenation with the SLAs obtained by consensus.

   SLAs are chosen randomly, but the risk of collisions is very low,
   since routers know, from the OSPF database, the already chosen SLAs.
   This risk is higher when two partitioned networks merge.


3.1. Merging of a new router

   A new zero conf router entering on a link:

   o synchronizes its OSPF database with the designated router.

   o accepts the SLA value of the designated router. If collision
   occurs for some of its other links, interfaces with the smallest
   link IDs will renumber their SLA.

   o Configures its internal variables to inform hosts of the chosen
   prefix through the neighbor discovery protocol [RFC2461].


Chelius, Fleury, Toutain       Expires 13 December 2002               3
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   o Injects the negotiated prefixes in the routing OSPF database to
   allow prefix advertisement.

   Note that, as IPv6 prefixes cannot be guessed a priori, since the
   SLA is randomly chosen, the DNS registration cannot be done
   manually. Hosts must use DNS dynamic updates, if they want to
   register their addresses. This is not incompatible with the goal of
   a zero conf network.


3.2. Merging of several networks

   When several networks merge, OSPF synchronizes the databases of all
   routers. All routers receive the list of all SLAs allocated in the
   network. In case of conflict, two or more links have the same SLA,
   all conflicting links with the smallest IDs will have to renumber
   their SLA.

   The renumbering process is the following. All routers of a
   conflicting link generate a new potential SLA for the link but only
   the Designated Router fixes the new SLA. New potential SLAs are
   chosen randomly but avoid the already chosen SLAs in the network.

3.3. Use with OSPF Areas

   This protocol allows the negociation of only a portion of a link
   SLA. The remaining part of the SLA can be manually configured.

   This feature allows address aggregation in the case of OSPF areas.
   All links of an area may share a portion of their SLA.


4. Routers internal data structures

   Routers will keep the following pieces of information for each
   interface running the protocol.

   o Link-ID: 128 bit that identifies the link the interface is
   attached to. This value is chosen randomly at the interface startup
   and may change upon reception of a SLA-Link LSA.

   o SLA-value: SLA value of the link the interface is attached to.
   This value is chosen randomly at the interface startup and may
   change upon reception of a SLA-Link LSA. Its length is equal to SLA-
   length bits.

   o SLA-length: the length of the SLA portion that is negotiated by
   the protocol for the link. The default value is 16 bits and can be
   changed by system management and upon reception of a SLA-Link LSA.

   o SLA-prefix: the portion of the SLA that is not negotiated by the
   protocol. Its length is equal to (16 - SLA-length)bits. The default
   value is 0 and can be changed by system management and upon
   reception of a SLA-Link LSA.

Chelius, Fleury, Toutain       Expires 13 December 2002               4
Internet Draft     IPv6 router autoconfiguration           13 June 2002


   o TLA-list: list of TLA values available in the network. By default,
   this list only contains the TLA value of the site-local prefix (i.e.
   fec0::/48). This list changes depending on the reception of TLA-site
   LSAs.

   The prefixes negotiated for a link by the protocol are built by
   concatening a TLA with the SLA-prefix and the SLA-value of an
   interface for all TLAs of the TLA list.

   We can notice that modification of the SLA-length induces
   modifications of the SLA-prefix and SLA-value.

   Edge routers also have the following piece of information:

   o TLA-to-export: list of TLAs to declare in the site. This list is
   modified by system management. For instance, TLAs can be provided by
   an ISP.


5. Definition of LSAs

   This protocol defines three new LSA types: SLA-Link, SLA-Area and
   TLA-Site.


5.1. SLA-Link LSA

   The LS type of a SLA-Link LSA is set to the value <TBD by IANA>.
   SLA-Link LSAs have link flooding scope. A SLA-Link LSA is originated
   for every broadcast or NBMA link having two or more attached
   routers, by the link's Designated Router. The SLA-Link LSA gives the
   SLA-value, the SLA-length, the SLA-prefix and the Link-ID for the
   link.

   The events causing SLA-Link LSAs to be reoriginated, are the
   following:

   o The SLA-value of a link interface is modified.

   o The SLA-prefix of a link interface is modified.

   Upon reception of a SLA-Link LSA, a router updates the SLA-value,
   SLA-length, SLA-prefix and Link-ID of its receiving interface with
   the received ones.


5.2. SLA-Area LSA

   The LS type of a SLA-Area LSA is set to the value <TBD by IANA>.
   SLA-Area LSAs have area flooding scope. A SLA-Area LSA is originated
   for every broadcast or NBMA link having two or more attached
   routers, by the link's Designated Router. The SLA-Area LSA gives the
   SLA of the link.

Chelius, Fleury, Toutain       Expires 13 December 2002               5
Internet Draft     IPv6 router autoconfiguration           13 June 2002


   The events causing SLA-Area LSAs to be reoriginated, are the
   following:

   o The SLA-value of a link interface is modified.

   o The SLA-prefix of a link interface is modified

   Upon reception of a SLA-Area LSA, a router first removes from its
   OSPF database all older SLA-Area LSAs with the same Link-ID.
   Secondly, for each of its interfaces, it compares the received SLA
   and Link-ID with its interface ones. There is collision if the Link-
   IDs differ and the SLAs are equal.

   In the case of a collision, the router renumbers the SLA if its
   interface Link-ID is smaller than the received one. Renumbering is
   done randomly. The new SLA must not already be present in any SLA-
   Area LSA of its database.


5.3. TLA-Site LSA

   The LS type of a TLA-Site LSA is set to the value <TBD by IANA>.
   TLA-Site LSAs have site flooding scope. A TLA-Site LSA is originated
   for all edge routers by the corresponding edge router. The TLA-Site
   LSA lists all TLA provided by the edge router.

   The events causing SLA-Area LSAs to be reoriginated, are the
   following:

   o The TLA-to-export list of the edge router is modified.

   Upon reception of a TLA-to-export LSA, a router adds all received
   TLAs to the TLA lists of all its interfaces.


6. Security Considerations

   In rare case, this protocol may lead to aberrations in network
   addressing and routing. The sanity of the protocol relies on the
   fact that two links will not have the same link ID. As this 128bits
   value is chosen randomly, the risk of collision is small.

   As OSPF, when running over IPv6, this protocol relies on the IP
   Authentication Header (see [Ref19]) and the IP Encapsulating
   Security Payload (see [Ref20]) to ensure integrity and
   authentication/confidentiality of routing exchanges.

   Most implementations will be running on systems that support
   multiple protocols, many of them having independent security
   assumptions and domains. When IPSEC is used to protect OSPF packets,
   it is important for the implementation to check the IPSEC SA, and



Chelius, Fleury, Toutain       Expires 13 December 2002               6
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   local SA database to make sure that the packet originates from a
   source THAT IS TRUSTED FOR OSPF PURPOSES.


7. IANA consideration

   Three OSPFv3 LSA type have to be defined: one with a link scope, the
   other with a area scope and the last with a site scope.















































Chelius, Fleury, Toutain       Expires 13 December 2002               7
Internet Draft     IPv6 router autoconfiguration           13 June 2002


8. References

   [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
   2402, November 1998.

   [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
   Payload(ESP)", RFC 2406, November 1998.

   [RFC2740] Coltun, R. and Ferguson, D. and J. Moy, "OSPF for IPv6",
   RFC 2470, December 1999.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirements Levels", RFC 2119, March 1997.


   [RFC2461] Narten, T. and Nordmark, E. and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2641, December 1998.


A. LSA Format

   This appendice describes the format of the SLA-Link, SLA-Area and
   TLA-Site LSAs.


A.1. SLA-Link LSA Format

   SLA-Link LSAs have LS type equal to <TBD by IANA>.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                            Link-ID                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             SLA              |            SLA-length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Link-ID
        The Link-ID value of the sending interface.

   SLA
        Concatenation of the SLA-prefix and SLA-value of the sending
        interface.

   SLA-length
        The SLA-length of the sending interface.


A.2. SLA-Area LSA Format


Chelius, Fleury, Toutain       Expires 13 December 2002               8
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   SLA-Area LSAs have LS type equal to <TBD by IANA>

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                            Link-ID                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Reserved          |                SLA            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Link-ID
        The Link-ID value for the sending interface.

   Reserved
        0

   SLA
        Concatenation of the SLA-prefix and SLA-value of the sending
        interface.


A.3. TLA-Site LSA Format

   TLA-Site LSAs have LS type equal to <TBD by IANA>

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Reserved          |                               |
    +-+-+-+-+-+-+-+-++-+-+-+-+-++-+-+                               +
    |                             TLA                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              ...                              |

   Reserved
        0

   TLA
        All TLAs of the TLA-to-export list of the sending router.


Author's Addresses

   Guillaume Chelius
   Ares, Inria, France
   Email: gchelius@telecom.insa-lyon.fr

   Eric Fleury
   Ares, Inria, France
   Email: Eric.Fleury@inria.fr


Chelius, Fleury, Toutain       Expires 13 December 2002               9
Internet Draft     IPv6 router autoconfiguration           13 June 2002

   Laurent Toutain
   ENST Bretagne, France
   Email: Laurent.Toutain@enst-bretagne.fr




















































Chelius, Fleury, Toutain       Expires 13 December 2002              10


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/