Network Working Group A. Lindem
Internet-Draft J. Arkko
Intended status: Standards Track Ericsson
Expires: April 23, 2014 October 20, 2013
OSPFv3 Auto-Configuration
draft-ietf-ospf-ospfv3-autoconfig-05.txt
Abstract
OSPFv3 is a candidate for deployments in environments where auto-
configuration is a requirement. One such environment is the IPv6
home network where users expect to simply plug in a router and have
it automatically use OSPFv3 for intra-domain routing. This document
describes the necessary mechanisms for OSPFv3 to be self-configuring.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 23, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Lindem & Arkko Expires April 23, 2014 [Page 1]
Internet-Draft OSPFv3 Auto-Configuration October 2013
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3
2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . . 5
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 7
3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 7
4. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 8
5. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 9
6. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 10
6.1. Duplicate Router ID Detection for Neighbors . . . . . . . 10
6.2. Duplicate Router ID Detection for OSPFv3 Routers that
are not Neighbors . . . . . . . . . . . . . . . . . . . . 10
6.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 10
6.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 12
6.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 12
6.4. Change to RFC 2328 Section 13.4, 'Receiving
Self-Originated LSA' Processing . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Management Considerations . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Lindem & Arkko Expires April 23, 2014 [Page 2]
Internet-Draft OSPFv3 Auto-Configuration October 2013
1. Introduction
OSPFv3 [OSPFV3] is a candidate for deployments in environments where
auto-configuration is a requirement. Its operation is largely
unchanged from the base OSPFv3 protocol specification [OSPFV3].
The following aspects of OSPFv3 auto-configuration are described:
1. Default OSPFv3 Configuration
2. HelloInterval/RouterDeadInterval Flexibility
3. Unique OSPFv3 Router-ID generation
4. OSPFv3 Adjacency Formation
5. Duplicate OSPFv3 Router-ID Resolution
1.1. Requirements notation
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-KEYWORDS].
1.2. Acknowledgments
This specification was inspired by the work presented in the Homenet
working group meeting in October 2011 in Philadelphia, Pennsylvania.
In particular, we would like to thank Fred Baker, Lorenzo Colitti,
Ole Troan, Mark Townsley, and Michael Richardson.
Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 auto-
configuration in the expired "Autoconfiguration of routers using a
link state routing protocol" IETF Draft. There are many similarities
between the concepts and techniques in this document.
Thanks for Abhay Roy and Manav Bhatia for comments regarding
duplicate router-id processing.
Thanks for Alvaro Retana and Michael Barnes for comments regarding
OSPFv3 Instance ID auto-configuration.
Thanks to Faraz Shamim for review and comments.
Thanks to Mark Smith for the requirement to reduce the adjacency
formation delay in the back-to-back ethernet topologies that are
prevalent in home networks.
Lindem & Arkko Expires April 23, 2014 [Page 3]
Internet-Draft OSPFv3 Auto-Configuration October 2013
The RFC text was produced using Marshall Rose's xml2rfc tool.
Special thanks go to Markus Stenberg for his implementation of this
specification.
Lindem & Arkko Expires April 23, 2014 [Page 4]
Internet-Draft OSPFv3 Auto-Configuration October 2013
2. OSPFv3 Default Configuration
For complete auto-configuration, OSPFv3 will need to choose suitable
configuration defaults. These include:
1. Area 0 Only - All auto-configured OSPFv3 interfaces MUST be in
area 0.
2. OSPFv3 SHOULD be auto-configured on for IPv6 on all interfaces
intended as general IPv6-capable routers. Optionally, an
interface MAY be excluded if it is clear that running OSPFv3 on
the interface is not required. For example, if manual
configuration or another condition indicates that an interface is
connected to an Internet Service Provider (ISP) and there is no
Border Gateway Protocol (BGP) [BGP] peering, there is typically
no need to employ OSPFv3. In fact, [IPv6-CPE] specifically
requires that IPv6 Customer Premise Equipment (CPE) routers do
not initiate any dynamic routing protocol by default on the
router's WAN, i.e., ISP-facing, interface. In home networking
environments, an interface where no OSPFv3 neighbors are found
but a DHCP IPv6 prefix can be acquired may be considered an ISP-
facing interface and running OSPFv3 is unnecessary.
3. OSPFv3 interfaces will be auto-configured to an interface type
corresponding to their layer-2 capability. For example, Ethernet
interfaces and vanilla Wi-Fi interfaces will be auto-configured
as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP)
interfaces will be auto-configured as OSPFv3 Point-to-Point
interfaces. Most extant OSPFv3 implementations do this already.
Auto-configured operation over wireless networks requiring a
point-to-multipoint (P2MP) topology and dynamic metrics based on
wireless feedback is not within the scope of this document.
However, auto-configuration is not precluded in these
environments.
4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and
RouterDeadInterval as specified in Section 3. Of course, an
identical HelloInterval and RouterDeadInterval will still be
required to form an adjacency with an OSPFv3 router not
supporting auto-configuration [OSPFV3].
5. All OSPFv3 interfaces SHOULD be auto-configured to use an
Interface Instance ID of 0 that corresponds to the base IPv6
unicast address family instance ID as defined in [OSPFV3-AF].
Similarly, if IPv4 unicast addresses are advertised in a separate
auto-configured OSPFv3 instance, the base IPv4 unicast address
family instance ID value, i.e., 64, SHOULD be auto-configured as
the Interface Instance ID for all interfaces corresponding to the
Lindem & Arkko Expires April 23, 2014 [Page 5]
Internet-Draft OSPFv3 Auto-Configuration October 2013
IPv4 unicast OSPFv3 instance [OSPFV3-AF].
Lindem & Arkko Expires April 23, 2014 [Page 6]
Internet-Draft OSPFv3 Auto-Configuration October 2013
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility
Auto-configured OSPFv3 routers will not require an identical
HelloInterval and RouterDeadInterval to form adjacencies. Rather,
the received HelloInterval will be ignored and the received
RouterDeadInterval will be used to determine OSPFv3 liveliness with
the sending router. In other words, the Neighbor Inactivity Timer
(Section 10 of [OSPFV2]) for each neighbor will reflect that
neighbor's advertised RouterDeadInterval and MAY be different from
other OSPFv3 routers on the link without impacting adjacency
formation. A similar mechanism requiring additional signaling is
proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO].
3.1. Wait Timer Reduction
In many situations, auto-configured OSPFv3 routers will be deployed
in environments where back-to-back ethernet connections are utilized.
When this is the case, an OSPFv3 broadcast interface will not come up
until the other OSPFv3 router is connected and the routers will wait
RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In
order to reduce this delay, an auto-configured OSPFv3 router MAY
reduce the wait interval to a value no less than (HelloInterval + 1).
Reducing the setting will slightly increase the likelihood of the
Designated Router (DR) flapping but is preferable to the long
adjacency formation delay. Note that this value is not included in
OSPFv3 Hello packets and does not impact interoperability.
Lindem & Arkko Expires April 23, 2014 [Page 7]
Internet-Draft OSPFv3 Auto-Configuration October 2013
4. OSPFv3 Router ID Selection
As OSPFv3 Router implementing this specification must select a unique
Router ID. A pseudo-random number SHOULD be used for the OSPFv3
Router ID. The generation should be seeded with a variable that is
likely to be unique in the applicable OSPFv3 router deployment. A
good choice of seed would be some portion or hash of the Route-
Hardware-Fingerprint as described in Section 6.2.2.
Since there is a possibility of a Router ID collision, duplicate
Router ID detection and resolution are required as described in
Section 6 and Section 6.3.
Lindem & Arkko Expires April 23, 2014 [Page 8]
Internet-Draft OSPFv3 Auto-Configuration October 2013
5. OSPFv3 Adjacency Formation
Since OSPFv3 uses IPv6 link-local addresses for all protocol messages
other than messages sent on virtual links (which are not applicable
to auto-configuration), OSPFv3 adjacency formation can proceed as
soon as a Router ID has been selected and the IPv6 link-local address
has completed Duplicate Address Detection (DAD) as specified in IPv6
Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only
changes to the OSPFv3 base specification are supporting
HelloInterval/RouterDeadInterval flexibility as described in
Section 3 and duplicate Router ID detection and resolution as
described in Section 6 and Section 6.3.
Lindem & Arkko Expires April 23, 2014 [Page 9]
Internet-Draft OSPFv3 Auto-Configuration October 2013
6. OSPFv3 Duplicate Router ID Detection and Resolution
There are two cases of duplicate OSPFv3 Router ID detection. One
where the OSPFv3 router with the duplicate Router ID is directly
connected and one where it is not. In both cases, the duplicate
resolution is for one of the routers to select a new OSPFv3 Router
ID.
6.1. Duplicate Router ID Detection for Neighbors
In this case, a duplicate Router ID is detected if any valid OSPFv3
packet is received with the same OSPFv3 Router ID but a different
IPv6 link-local source address. Once this occurs, the OSPFv3 router
with the numerically smaller IPv6 link-local address will need to
select a new Router ID as described in Section 6.3. Note that the
fact that the OSPFv3 router is a neighbor on a non-virtual interface
implies that the router is directly connected. An OSPFv3 router
implementing this specification should assure that the inadvertent
connection of multiple router interfaces to the same physical link is
not misconstrued as detection of an OSPFv3 neighbor with a duplicate
Router ID.
6.2. Duplicate Router ID Detection for OSPFv3 Routers that are not
Neighbors
OSPFv3 Routers implementing auto-configuration, as specified herein,
MUST originate an Auto-Configuration (AC) Link State Advertisement
(LSA) including the Router-Hardware-Fingerprint Type-Length-Value
(TLV). The Router-Hardware-Fingerprint TLV contains a variable
length value that has a very high probability of uniquely identifying
the advertising OSPFv3 router. An OSPFv3 router implementing this
specification MUST compare a received self-originated Auto-
Configuration LSA's Router-Hardware-Fingerprint TLV against its own
router hardware fingerprint. If the fingerprints are not equal,
there is a duplicate Router ID conflict and the OSPFv3 Router with
the numerically smaller router hardware fingerprint MUST select a new
Router ID as described in Section 6.3.
This new LSA is designated for information related to OSPFv3 Auto-
configuration and, in the future, could be used other auto-
configuration information, e.g., global IPv6 prefixes. However, this
is beyond the scope of this document.
6.2.1. OSPFv3 Router Auto-Configuration LSA
The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and
the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit
will be set indicating that the OSPFv3 AC LSA should be flooded even
Lindem & Arkko Expires April 23, 2014 [Page 10]
Internet-Draft OSPFv3 Auto-Configuration October 2013
if it is not understood. The Link State ID (LSID) value will be a
integer index used to discriminate between multiple AC LSAs
originated by the same OSPFv3 Router. This specification only
describes the contents of an AC LSA with a Link State ID (LSID) of 0.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|0|1| TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv3 Auto-Configuration (AC) LSA
The format of the TLVs within the body of an AC LSA is the same as
the format used by the Traffic Engineering Extensions to OSPF [TE].
The LSA payload consists of one or more nested Type/Length/Value
(TLV) triplets. The format of each TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV
is padded to 4-octet alignment; padding is not included in the length
Lindem & Arkko Expires April 23, 2014 [Page 11]
Internet-Draft OSPFv3 Auto-Configuration October 2013
field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. Unrecognized types are ignored.
The new LSA is designated for information related to OSPFv3 Auto-
configuration and, in the future, can be used other auto-
configuration information.
6.2.2. Router-Hardware-Fingerprint TLV
The Router-Hardware-Fingerprint TLV is the first TLV defined for the
OSPFv3 Auto-Configuration (AC) LSA. It will have type 1 and MUST be
advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD
occur, at most, once and the first instance of the TLV will take
precedence over subsequent TLV instances. The length of the Router-
Hardware-Fingerprint is variable but must be 32 octets or greater.
The contents of the hardware fingerprint SHOULD be some combination
of MAC addresses, CPU ID, or serial number(s) that provides an
extremely high probability of uniqueness. It MUST be based on
hardware attributes that will not change across hard and soft
restarts.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | >32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Hardware-Fingerprint TLV Format
6.3. Duplicate Router ID Resolution
The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID
condition must select a new OSPFv3 Router ID. After selecting a new
Router ID, all self-originated LSAs MUST be reoriginated, and any
OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router
Lindem & Arkko Expires April 23, 2014 [Page 12]
Internet-Draft OSPFv3 Auto-Configuration October 2013
retaining the Router ID causing the conflict will reoriginate or
purge stale any LSAs as described in Section 13.4 [OSPFV2].
6.4. Change to RFC 2328 Section 13.4, 'Receiving Self-Originated LSA'
Processing
RFC 2328 [OSPFV2], Section 13.4, describes the processing of received
self-originated LSAs. If the received LSA doesn't exist, the
receiving router will purge it from the OSPF routing domain. If the
LSA is newer than the version in the Link State Database (LSDB), the
receiving router will originate a newer version by advancing the LSA
sequence number and reflooding. Since it is possible for an auto-
configured OSPFv3 router to choose a duplicate OSPFv3 Router ID,
OSPFv3 routers implementing this specification should detect when
multiple instances of the same self-originated LSA are purged or
reoriginated since this is indicative of an OSPFv3 router with a
duplicate Router ID in the OSPFv3 routing domain. When this
condition is detected, the OSPFv3 Router SHOULD delay self-originated
LSA processing for LSAs that have recently been purged or reflooded.
This specification recommends 10 seconds as the interval defining
recent self-originated LSA processing and an exponential back off of
1 to 8 seconds for the processing delay. This additional delay
should allow for the mechanisms described in Section 6 to resolve the
duplicate OSPFv3 Router ID conflict.
Lindem & Arkko Expires April 23, 2014 [Page 13]
Internet-Draft OSPFv3 Auto-Configuration October 2013
7. Security Considerations
A unique OSPFv3 Interface Instance ID is used for auto-configuration
to prevent inadvertent OSPFv3 adjacency formation, see Section 2
The goals of security and complete OSPFv3 auto-configuration are
somewhat contradictory. When no explicit security configuration
takes place, auto-configuration implies that additional devices
placed in the network are automatically adopted as a part of the
network. However, auto-configuration can also be combined with
password configuration (see below) or future extensions for automatic
pairing between devices. These mechanisms can help provide an
automatically configured, securely routed network.
It is RECOMMENDED that OSPFv3 routers supporting this specification
also offer an option to explicitly configure a password for HMAC-SHA
authentication as described in [OSPFV3-AUTH-TRAILER]. When
configured, the password will be used on all auto-configured
interfaces with the Security Association Identifier (SA ID) set to 1
and HMAC-SHA-256 used as the authentication algorithm.
Lindem & Arkko Expires April 23, 2014 [Page 14]
Internet-Draft OSPFv3 Auto-Configuration October 2013
8. Management Considerations
It is RECOMMENDED that OSPFv3 routers supporting this specification
also allow explicit configuration of OSPFv3 parameters as specified
in Appendix C of [OSPFV3]. This is in addition to the authentication
key configuration recommended in Section 7. However, it is
acknowledged that there may be some deployment scenarios where manual
authentication key configuration is not required.
Lindem & Arkko Expires April 23, 2014 [Page 15]
Internet-Draft OSPFv3 Auto-Configuration October 2013
9. IANA Considerations
This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto-
Configuration (AC) LSA, as described in Section 6.2.1. The value TBD
will be allocated from the existing "OSPFv3 LSA Function Code"
registry for the OSPFv3 Auto-Configuration LSA.
This specification also creates a registry for OSPFv3 Auto-
Configuration (AC) LSA TLVs. This registry should be placed in the
existing OSPFv3 IANA registry, and new values can be allocated via
IETF Consensus or IESG Approval.
Three initial values are allocated:
o 0 is marked as reserved.
o 1 is Router-Hardware-Fingerprint TLV (Section 6.2.2).
o 65535 is an Auto-configuration-Experiment-TLV, a common value that
can be used for experimental purposes.
Lindem & Arkko Expires April 23, 2014 [Page 16]
Internet-Draft OSPFv3 Auto-Configuration October 2013
10. References
10.1. Normative References
[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[OSPFV3-AF]
Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[OSPFV3-AUTH-TRAILER]
Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.
[RFC-KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[SLAAC] Thomson, S., Narten, T., and J. Tatuya, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003.
10.2. Informative References
[ASYNC-HELLO]
Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold
Timer", draft-madhukar-ospf-agr-asymmetric-01.txt (work in
progress).
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[IPv6-CPE]
Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
Lindem & Arkko Expires April 23, 2014 [Page 17]
Internet-Draft OSPFv3 Auto-Configuration October 2013
Authors' Addresses
Acee Lindem
Ericsson
301 Midenhall Way
Cary, NC 27513
USA
Email: acee.lindem@ericsson.com
Jari Arkko
Ericsson
Jorvas, 02420
Finland
Email: jari.arkko@piuha.net
Lindem & Arkko Expires April 23, 2014 [Page 18]