< draft-ietf-ospf-ospfv3-autoconfig-02.txt   draft-ietf-ospf-ospfv3-autoconfig-03.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft J. Arkko Internet-Draft J. Arkko
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: October 17, 2013 April 15, 2013 Expires: February 20, 2014 August 19, 2013
OSPFv3 Auto-Configuration OSPFv3 Auto-Configuration
draft-ietf-ospf-ospfv3-autoconfig-02.txt draft-ietf-ospf-ospfv3-autoconfig-03.txt
Abstract Abstract
OSPFv3 is a candidate for deployments in environments where auto- OSPFv3 is a candidate for deployments in environments where auto-
configuration is a requirement. One such environment is the IPv6 configuration is a requirement. One such environment is the IPv6
home network where users expect to simply plug in a router and have home network where users expect to simply plug in a router and have
it automatically use OSPFv3 for intra-domain routing. This document it automatically use OSPFv3 for intra-domain routing. This document
describes the necessary mechanisms for OSPFv3 to be self-configuring. describes the necessary mechanisms for OSPFv3 to be self-configuring.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 17, 2013. This Internet-Draft will expire on February 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 6 3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . . 6
4. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 7 4. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . . 7
5. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 8 5. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . . 8
6. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 9 6. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 9
6.1. Duplicate Router ID Detection for Neighbors . . . . . . . 9 6.1. Duplicate Router ID Detection for Neighbors . . . . . . . 9
6.2. Duplicate Router ID Detection for OSPFv3 Routers that 6.2. Duplicate Router ID Detection for OSPFv3 Routers that
are not Neighbors . . . . . . . . . . . . . . . . . . . . 9 are not Neighbors . . . . . . . . . . . . . . . . . . . . 9
6.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 9 6.2.1. OSPFv3 Router Auto-Configuration LSA . . . . . . . . . 9
6.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 11 6.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 11
6.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 11 6.3. Duplicate Router ID Resolution . . . . . . . . . . . . . . 11
6.4. Change to Received Self-Originated LSA Processing . . . . 12 6.4. Change to RFC 2328 Section 13.4, 'Receiving
Self-Originated LSA' Processing . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Management Considerations . . . . . . . . . . . . . . . . . . 14 8. Management Considerations . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Border Gateway Protocol (BGP) [BGP] peering, there is typically Border Gateway Protocol (BGP) [BGP] peering, there is typically
no need to employ OSPFv3. However, note that in many no need to employ OSPFv3. However, note that in many
environments it can be useful to test whether an OSPFv3 adjacency environments it can be useful to test whether an OSPFv3 adjacency
can be established. In home networking environments, an can be established. In home networking environments, an
interface where no OSPFv3 neighbors are found but a DHCP IPv6 interface where no OSPFv3 neighbors are found but a DHCP IPv6
prefix can be acquired may be considered an ISP-facing interface prefix can be acquired may be considered an ISP-facing interface
and running OSPFv3 is unnecessary. and running OSPFv3 is unnecessary.
3. OSPFv3 interfaces will be auto-configured to an interface type 3. OSPFv3 interfaces will be auto-configured to an interface type
corresponding to their layer-2 capability. For example, Ethernet corresponding to their layer-2 capability. For example, Ethernet
interfaces will be auto-configured as broadcast networks and interfaces and vanilla Wi-Fi interfaces will be auto-configured
Point-to-Point Protocol (PPP) interfaces will be auto-configured as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP)
as Point-to-Point interfaces. Most extant OSPFv3 implementations interfaces will be auto-configured as OSPFv3 Point-to-Point
do this already. Auto-configured operation over wireless interfaces. Most extant OSPFv3 implementations do this already.
networks requiring a point-to-multipoint (P2MP) topology and Auto-configured operation over wireless networks requiring a
dynamic metrics based on wireless feedback is not within the point-to-multipoint (P2MP) topology and dynamic metrics based on
scope of this document. However, auto-configuration is not wireless feedback is not within the scope of this document.
precluded in these environments. However, auto-configuration is not precluded in these
environments.
4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and 4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and
RouterDeadInterval as specified in Section 3. Of course, an RouterDeadInterval as specified in Section 3. Of course, an
identical HelloInterval and RouterDeadInterval will still be identical HelloInterval and RouterDeadInterval will still be
required to form an adjacency with an OSPFv3 router not required to form an adjacency with an OSPFv3 router not
supporting auto-configuration [OSPFV3]. supporting auto-configuration [OSPFV3].
5. All OSPFv3 interfaces SHOULD be auto-configured to use an 5. All OSPFv3 interfaces SHOULD be auto-configured to use an
Interface Instance ID of 0 that corresponds to the base IPv6 Interface Instance ID of 0 that corresponds to the base IPv6
unicast address family instance ID as defined in [OSPFV3-AF]. unicast address family instance ID as defined in [OSPFV3-AF].
Similarly, if IPv4 unicast addresses are advertised in a separate Similarly, if IPv4 unicast addresses are advertised in a separate
auto-configured OSPFv3 instance, the base IPv4 unicast address auto-configured OSPFv3 instance, the base IPv4 unicast address
family instance ID value, i.e., 64, SHOULD be auto-configured as family instance ID value, i.e., 64, SHOULD be auto-configured as
the Interface Instance ID for all interfaces corresponding to the the Interface Instance ID for all interfaces corresponding to the
OSPFv3 instance [OSPFV3-AF]. IPv4 unicast OSPFv3 instance [OSPFV3-AF].
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility 3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility
Auto-configured OSPFv3 routers will not require an identical Auto-configured OSPFv3 routers will not require an identical
HelloInterval and RouterDeadInterval to form adjacencies. Rather, HelloInterval and RouterDeadInterval to form adjacencies. Rather,
the received HelloInterval will be ignored and the received the received HelloInterval will be ignored and the received
RouterDeadInterval will be used to determine OSPFv3 liveliness with RouterDeadInterval will be used to determine OSPFv3 liveliness with
the sending router. In other words, the Inactivity Timer for each the sending router. In other words, the Neighbor Inactivity Timer
neighbor will reflect that neighbor's advertised RouterDeadInterval (Section 10 of [OSPFV2]) for each neighbor will reflect that
and MAY be different from other OSPFv3 routers on the link without neighbor's advertised RouterDeadInterval and MAY be different from
impacting adjacency formation. A similar mechanism requiring other OSPFv3 routers on the link without impacting adjacency
additional signaling is proposed for all OSPFv2 and OSPFv3 routers formation. A similar mechanism requiring additional signaling is
[ASYNC-HELLO]. proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO].
3.1. Wait Timer Reduction 3.1. Wait Timer Reduction
In many situations, auto-configured OSPFv3 routers will be deployed In many situations, auto-configured OSPFv3 routers will be deployed
in environments where back-to-back ethernet connections are utilized. in environments where back-to-back ethernet connections are utilized.
When this is the case, an OSPFv3 broadcast interface will not come up 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 until the other OSPFv3 router is connected and the routers will wait
RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In
order to reduce this delay, an auto-configured OSPFv3 router MAY order to reduce this delay, an auto-configured OSPFv3 router MAY
reduce the wait interval to a value no less than (HelloInterval + 1), reduce the wait interval to a value no less than (HelloInterval + 1).
i.e., 11 seconds. Reducing the setting will slightly increase the Reducing the setting will slightly increase the likelihood of the
likelihood of the Designated Router (DR) flapping but is preferable Designated Router (DR) flapping but is preferable to the long
to the long adjacency formation delay. Note that this value is not adjacency formation delay. Note that this value is not included in
included in OSPFv3 Hello packets and does not impact OSPFv3 Hello packets and does not impact interoperability.
interoperability.
4. OSPFv3 Router ID Selection 4. OSPFv3 Router ID Selection
As OSPFv3 Router implementing this specification must select a unique As OSPFv3 Router implementing this specification must select a unique
Router ID. A pseudo-random number SHOULD be used for the OSPFv3 Router ID. A pseudo-random number SHOULD be used for the OSPFv3
Router ID. The generation should be seeded with a variable that is Router ID. The generation should be seeded with a variable that is
likely to be unique in that environment. A good choice of seed would likely to be unique in the applicable OSPFv3 router deployment. A
be some portion or hash of the Route-Hardware-Fingerprint as good choice of seed would be some portion or hash of the Route-
described in Section 6.2.2. Hardware-Fingerprint as described in Section 6.2.2.
Since there is a possibility of a Router ID collision, duplicate Since there is a possibility of a Router ID collision, duplicate
Router ID detection and resolution are required as described in Router ID detection and resolution are required as described in
Section 6 and Section 6.3. Section 6 and Section 6.3.
5. OSPFv3 Adjacency Formation 5. OSPFv3 Adjacency Formation
Since OSPFv3 uses IPv6 link-local addresses for all protocol messages Since OSPFv3 uses IPv6 link-local addresses for all protocol messages
other than messages sent on virtual links (which are not applicable other than messages sent on virtual links (which are not applicable
to auto-configuration), OSPFv3 adjacency formation can proceed as to auto-configuration), OSPFv3 adjacency formation can proceed as
skipping to change at page 9, line 9 skipping to change at page 9, line 9
Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only
changes to the OSPFv3 base specification are supporting changes to the OSPFv3 base specification are supporting
HelloInterval/RouterDeadInterval flexibility as described in HelloInterval/RouterDeadInterval flexibility as described in
Section 3 and duplicate Router ID detection and resolution as Section 3 and duplicate Router ID detection and resolution as
described in Section 6 and Section 6.3. described in Section 6 and Section 6.3.
6. OSPFv3 Duplicate Router ID Detection and Resolution 6. OSPFv3 Duplicate Router ID Detection and Resolution
There are two cases of duplicate OSPFv3 Router ID detection. One There are two cases of duplicate OSPFv3 Router ID detection. One
where the OSPFv3 router with the duplicate Router ID is directly where the OSPFv3 router with the duplicate Router ID is directly
connected and one where it is not. In both cases, the resolution is connected and one where it is not. In both cases, the duplicate
for one of the routers with the duplicate OSPFv3 Router ID to select resolution is for one of the routers to select a new OSPFv3 Router
a new one. ID.
6.1. Duplicate Router ID Detection for Neighbors 6.1. Duplicate Router ID Detection for Neighbors
In this case, a duplicate Router ID is detected if any valid OSPFv3 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 packet is received with the same OSPFv3 Router ID but a different
IPv6 link-local source address. Once that occurs, the OSPFv3 router IPv6 link-local source address. Once this occurs, the OSPFv3 router
with the numerically smaller IPv6 link-local address will need to 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 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 fact that the OSPFv3 router is a neighbor on a non-virtual interface
implies that the router is directly connected. An OSPFv3 router implies that the router is directly connected. An OSPFv3 router
implementing this specification should assure that the inadvertent implementing this specification should assure that the inadvertent
connection of multiple router interfaces to the same physical link is connection of multiple router interfaces to the same physical link is
not misconstrued as detection of a different OSPFv3 router with a not misconstrued as detection of an OSPFv3 neighbor with a duplicate
duplicate Router ID. Router ID.
6.2. Duplicate Router ID Detection for OSPFv3 Routers that are not 6.2. Duplicate Router ID Detection for OSPFv3 Routers that are not
Neighbors Neighbors
OSPFv3 Routers implementing auto-configuration, as specified herein, OSPFv3 Routers implementing auto-configuration, as specified herein,
MUST originate an Auto-Config (AC) Link State Advertisement (LSA) MUST originate an Auto-Configuration (AC) Link State Advertisement
including the Router-Hardware-Fingerprint Type-Length-Value (TLV). (LSA) including the Router-Hardware-Fingerprint Type-Length-Value
The Router-Hardware-Fingerprint TLV contains a variable length value (TLV). The Router-Hardware-Fingerprint TLV contains a variable
that has a very high probability of uniquely identifying the length value that has a very high probability of uniquely identifying
advertising OSPFv3 router. An OSPFv3 router implementing this the advertising OSPFv3 router. An OSPFv3 router implementing this
specification MUST compare a received self-originated Auto-Config specification MUST compare a received self-originated Auto-
LSA's Router-Hardware-Fingerprint TLV against its own router hardware Configuration LSA's Router-Hardware-Fingerprint TLV against its own
fingerprint. If the fingerprints are not equal, there is a Router ID router hardware fingerprint. If the fingerprints are not equal,
conflict and the OSPFv3 Router with the numerically smaller router there is a duplicate Router ID conflict and the OSPFv3 Router with
hardware fingerprint MUST select a new Router ID as described in the numerically smaller router hardware fingerprint MUST select a new
Section 6.3. Router ID as described in Section 6.3.
This new LSA is designated for information related to OSPFv3 Auto- This new LSA is designated for information related to OSPFv3 Auto-
configuration and, in the future, could be used other auto- configuration and, in the future, could be used other auto-
configuration information, e.g., global IPv6 prefixes. However, this configuration information, e.g., global IPv6 prefixes. However, this
is beyond the scope of this document. is beyond the scope of this document.
6.2.1. OSPFv3 Router Auto-Configuration LSA 6.2.1. OSPFv3 Router Auto-Configuration LSA
The OSPFv3 Auto-Configuration (AC) LSA has a function code of TBD and 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 the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit
skipping to change at page 11, line 12 skipping to change at page 11, line 12
(thus a TLV with no value portion would have a length of 0). The TLV (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 is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total 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 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 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 to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. Unrecognized types are ignored. portion of the TLV. Unrecognized types are ignored.
The new LSA is designated for information related to OSPFv3 Auto- The new LSA is designated for information related to OSPFv3 Auto-
configuration and, in the future, can be used other auto- configuration and, in the future, can be used other auto-
configuration information, e.g., global IPv6 prefixes. configuration information.
6.2.2. Router-Hardware-Fingerprint TLV 6.2.2. Router-Hardware-Fingerprint TLV
The Router-Hardware-Fingerprint TLV is the first TLV defined for the 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 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 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 occur, at most, once and the first instance of the TLV will take
precedence over subsequent TLV instances. The length of the Router- precedence over subsequent TLV instances. The length of the Router-
Hardware-Fingerprint is variable but must be 32 bytes or greater. Hardware-Fingerprint is variable but must be 32 octets or greater.
The contents of the hardware fingerprint should be some combination The contents of the hardware fingerprint SHOULD be some combination
of MAC addresses, CPU ID, or serial number(s) that provides an of MAC addresses, CPU ID, or serial number(s) that provides an
extremely high probability of uniqueness. It MUST be based on extremely high probability of uniqueness. It MUST be based on
hardware attributes that will not change across hard and soft hardware attributes that will not change across hard and soft
restarts. restarts.
0 1 2 3 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 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 | | 1 | >32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 47 skipping to change at page 11, line 47
o o
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Hardware-Fingerprint TLV Format Router-Hardware-Fingerprint TLV Format
6.3. Duplicate Router ID Resolution 6.3. Duplicate Router ID Resolution
The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID The OSPFv3 Router selected to resolve the duplicate OSPFv3 Router ID
condition must select a new OSPFv3 Router ID. After selecting a new condition must select a new OSPFv3 Router ID. After selecting a new
Router ID, the Router-LSA with the prior duplicate Router ID MUST be Router ID, all self-originated LSAs MUST be reoriginated, and any
purged. All self-originated LSAs MUST be reoriginated, and any OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router
OSPFv3 neighbor adjacencies MUST be reestablished. retaining the Router ID causing the conflict will reoriginate of
purge stale any LSAs as described in Section 13.4 [OSPFV2].
6.4. Change to Received Self-Originated LSA Processing 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 RFC 2328 [OSPFV2], Section 13.4, describes the processing of received
self-originated LSAs. If the received LSA doesn't exist, the self-originated LSAs. If the received LSA doesn't exist, the
receiving router will purge it from the OSPF routing domain. If 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 LSA is newer than the version in the Link State Database (LSDB), the
receiving router will originate a newer version by advancing the LSA receiving router will originate a newer version by advancing the LSA
sequence number and reflooding. Since it is possible for an auto- sequence number and reflooding. Since it is possible for an auto-
configured OSPFv3 router to choose a duplicate OSPFv3 Router ID, configured OSPFv3 router to choose a duplicate OSPFv3 Router ID,
OSPFv3 routers implementing this specification should detect when OSPFv3 routers implementing this specification should detect when
multiple instances of the same self-originated LSA are purged or multiple instances of the same self-originated LSA are purged or
reoriginated since this is indicative of an OSPFv3 router with a reoriginated since this is indicative of an OSPFv3 router with a
duplicate Router ID in the OSPFv3 routing domain. When this duplicate Router ID in the OSPFv3 routing domain. When this
condition is detected, the OSPFv3 Router SHOULD delay self-originated condition is detected, the OSPFv3 Router SHOULD delay self-originated
LSA processing for LSAs that have recently been purged or reflooded. LSA processing for LSAs that have recently been purged or reflooded.
This specification recommends 10 seconds as the interval defining This specification recommends 10 seconds as the interval defining
recent self-originated LSA processing and an exponential back off of recent self-originated LSA processing and an exponential back off of
1 to 8 seconds for the processing delay. 1 to 8 seconds for the processing delay. This additional delay
should allow for the mechanisms described in Section 6 to resolve the
duplication OSPFv3 Router ID conflict.
7. Security Considerations 7. Security Considerations
A unique OSPFv3 Interface Instance ID is used for auto-configuration A unique OSPFv3 Interface Instance ID is used for auto-configuration
to prevent inadvertent OSPFv3 adjacency formation, see Section 2 to prevent inadvertent OSPFv3 adjacency formation, see Section 2
The goals of security and complete OSPFv3 auto-configuration are The goals of security and complete OSPFv3 auto-configuration are
somewhat contradictory. When no explicit security configuration somewhat contradictory. When no explicit security configuration
takes place, auto-configuration implies that additional devices takes place, auto-configuration implies that additional devices
placed in the network are automatically adopted as a part of the placed in the network are automatically adopted as a part of the
skipping to change at page 15, line 7 skipping to change at page 15, line 7
It is RECOMMENDED that OSPFv3 routers supporting this specification It is RECOMMENDED that OSPFv3 routers supporting this specification
also allow explicit configuration of OSPFv3 parameters as specified also allow explicit configuration of OSPFv3 parameters as specified
in Appendix C of [OSPFV3]. This is in addition to the authentication in Appendix C of [OSPFV3]. This is in addition to the authentication
key configuration recommended in Section 7. However, it is key configuration recommended in Section 7. However, it is
acknowledged that there may be some deployment scenarios where manual acknowledged that there may be some deployment scenarios where manual
authentication key configuration is not required. authentication key configuration is not required.
9. IANA Considerations 9. IANA Considerations
This specification allocates a new OSPFv3 LSA, OSPFv3 Auto- This specification defines an OSPFv3 LSA Type for the OSPFv3 Auto-
Configuration (AC) LSA, TBD, as described in Section 6.2.1. 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- This specification also creates a registry for OSPFv3 Auto-
Configuration (AC) LSA TLVs. This registry should be placed in the Configuration (AC) LSA TLVs. This registry should be placed in the
existing OSPFv3 IANA registry, and new values can be allocated via existing OSPFv3 IANA registry, and new values can be allocated via
IETF Consensus or IESG Approval. IETF Consensus or IESG Approval.
Three initial values are allocated: Three initial values are allocated:
o 0 is marked as reserved. o 0 is marked as reserved.
skipping to change at page 17, line 9 skipping to change at page 17, line 9
Timer", draft-madhukar-ospf-agr-asymmetric-00.txt (work in Timer", draft-madhukar-ospf-agr-asymmetric-00.txt (work in
progress). progress).
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
Authors' Addresses Authors' Addresses
Acee Lindem Acee Lindem
Ericsson Ericsson
102 Carric Bend Court 301 Midenhall Way
Cary, NC 27519 Cary, NC 27513
USA USA
Email: acee.lindem@ericsson.com Email: acee.lindem@ericsson.com
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas, 02420 Jorvas, 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
 End of changes. 21 change blocks. 
57 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/