One document matched: draft-chelius-router-autoconf-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-23 10:30:53 |