< draft-liu-isis-auto-conf-02.txt   draft-liu-isis-auto-conf-03.txt >
Network Working Group B. Liu
Internet Draft Huawei Technologies
Intended status: Standards Track Bruno Decraene
Expires: March 6, 2015 Orange
I. Farrer
Deutsche Telekom AG
M. Abrahamsson
T-System
September 3, 2014
ISIS Auto-Configuration isis B. Liu
draft-liu-isis-auto-conf-02.txt Internet-Draft Huawei Technologies
Intended status: Standards Track B. Decraene
Expires: April 30, 2015 Orange
I. Farrer
Deutsche Telekom AG
M. Abrahamsson
T-Systems
October 27, 2014
Status of this Memo ISIS Auto-Configuration
draft-liu-isis-auto-conf-03
Abstract
This document describes an IS-IS auto-configuration technology. The
key mechanisms of this technology are IS-IS NET (Network Entity
Title) self-generation, duplication detection and duplication
resolution. This technology fits the environment where plug-and-play
is expected, e.g., home networks and small or medium size enterprise
networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 working Task Force (IETF). Note that other groups may also distribute
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
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 March 6, 2015. This Internet-Draft will expire on April 30, 2015.
Copyright Notice0 Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document describes mechanisms for IS-IS to be self-configuring.
Such mechanisms could reduce the management burden to configure a
network. One obvious environment that could benefit from these
mechanisms is IPv6 home network where plug-and-play would be expected.
Besides home network, some simple enterprise/ISP networks might also
benefit from the self-configuring mechanisms.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Scope ................................................. 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification ....................................... 4 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3.1. IS-IS Default Configuration ............................. 4 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3
3.2. IS-IS NET Generation .................................... 4 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3
3.3. IS-IS NET Duplication Detection and Resolution........... 5 3.3. IS-IS NET Duplication Detection and Resolution . . . . . 4
3.3.1. Router-Hardware-Fingerprint TLV .................... 5 3.3.1. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 4
3.3.2. NET Duplication Detection and Resolution Procedures. 5 3.3.2. NET Duplication Detection and Resolution Procedures . 5
3.4. Authentication TLV ...................................... 6 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 6
3.5. Wide Metric ............................................. 7 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 6
3.6. Adjacency Formation Consideration ....................... 7 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 6
4. Co-existence with Other IGP Auto-configuration ............... 7 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 6
5. Security Considerations ...................................... 7 3.4.4. Purge Originator Identification TLV . . . . . . . . . 6
6. IANA Considerations .......................................... 8 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 6
7. Acknowledgments .............................................. 8 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 7
8. References ................................................... 8 3.5.2. Co-existing with Other IGP Auto-configuration . . . . 7
8.1. Normative References .................................... 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References .................................. 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This memo describes mechanisms for IS-IS [RFC1195][RFC5308] to be This memo describes mechanisms for IS-IS [RFC1195] [RFC5308] to be
auto-configuring. Such mechanisms could reduce the management burden auto-configuring. Such mechanisms could reduce the management burden
to configure a network. One example is home network where plug-and- to configure a network. Home networks and small or medium size
play would be expected. Besides home network, some simple enterprise networks where plug-n-play is expected can benefit from
enterprise/ISP networks might also potentially benefit from the auto- these mechanisms.
configuring mechanisms.
In addition, this memo defines how such un-configured routers should In addition, this memo defines how such un-configured routers should
behave, also limits the risk on existing network using IS-IS (Setcion behave, in order to limit the risk on existing network using IS-IS
3.4 & 3.5). (Section 3.4.1 & 3.5).
IS-IS auto-configuration mainly contains the following aspects: IS-IS auto-configuration mainly contains the following aspects:
1. IS-IS Default Configuration 1. IS-IS Default Configurations
2. IS-IS NET Self-Generation
2. IS-IS NET self-generation
3. NET duplication detection and resolution 3. NET Duplication Detection and Resolution
4. Authentication and Wide Metric TLV 4. ISIS TLVs utilization such as Authentication TLV, Wide Metric TLV
etc.
2. Design Scope 2. Scope
The auto-configuring mechanisms are not specifically designed based The auto-configuring mechanisms does not specifically destinguish
on IPv4 or IPv6. IPv4 or IPv6.
The auto-configuring mechanisms enabled interfaces are assumed to The auto-configuring mechanisms enabled interfaces are assumed to
have a 48-bit MAC address. have a 48-bit MAC address.
The main targeted application scenarios are supposed to be home This auto-configuration mechanism aims at simple case. The following
networks or small enterprise networks .etc. where plug-n-play is advanced features are out of scope:
expected and complex topology/hierarchy is not needed. Sophisticate
requirements from service provider networks are out of scope.
So this document does not provide a complete configuration-free
alternative to the IS-IS protocol. The following features of IS-IS
are NOT supported by this document:
o Auto-configuring multiple IS-IS processes. The auto-configuration
mechanisms only support configuring a single process.
o Route between multiple IS-IS areas. The auto-configuration o Multiple IS-IS instances.
mechanisms only support routers that are within a single area.
o Auto-configuring multiple operation levels. The auto-configuration o Multi-area and level-2 routers.
mechanisms only support level-1 operation mode.
o This document does not consider interoperability with other routing o Interworking with other routing protocols.
protocols.
3. Protocol Specification 3. Protocol Specification
3.1. IS-IS Default Configuration 3.1. IS-IS Default Configuration
o IS-IS SHOULD be enabled on all interfaces in a router that requires o IS-IS SHOULD be enabled as default on all interfaces in a router
the IS-IS auto-configuration as default. For some specific situations, that requires the IS-IS auto-configuration. For some specific
interface MAY be excluded if it is a clear that running IS-IS on the situations, interface MAY be excluded if it is a clear that
interface is not required. running IS-IS on the interface is not required.
o IS-IS interfaces MUST be auto-configured to an interface type o IS-IS interfaces MUST 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 Point- interfaces will be auto-configured as broadcast networks and
to-Point Protocol (PPP) interfaces will be auto-configured as Point- Point- to-Point Protocol (PPP) interfaces will be auto-configured
to-Point interfaces. as Point- to-Point interfaces.
o IS-IS auto-configuration interfaces MUST be configured with level-1. o IS-IS auto-configuration interfaces MUST be configured with level-
1.
3.2. IS-IS NET Generation 3.2. IS-IS NET Generation
In IS-IS, a router (known as an IS) is identified by an Network In IS-IS, a router (known as an IS) is identified by an Network
Entity Title (NET) which is the address of a Network Service Access Entity Title (NET) which is the address of a Network Service Access
Point (NSAP) and represented with an IS-IS specific address format. Point (NSAP) and represented with an IS-IS specific address format.
The NSAP is a logical entity which represents an instance of the IS- The NSAP is a logical entity which represents an instance of the IS-
IS protocol running on an IS. IS protocol running on an IS.
The NET consists of three parts. The auto-generation mechanisms of The NET consists of three parts. The auto-generation mechanisms of
each part are described as the following: each part are described as the following:
Area address: This field is 1 to 13 octets in length. In IS-IS auto- o Area address
configuring, this field MUST be 0 in 13 octets length.
System ID: This field follows the area address field, and is 6 octets This field is 1 to 13 octets in length. In IS-IS auto-
in length. As specified in IS-IS protocol, this field must be unique configuring, this field MUST be 0 in 13 octets length.
among all level-1 routers in the same area when the IS operates at
Level 1. In IS-IS auto-configuring, this field SHOULD be the MAC
address of one IS-IS enabled interface.
NSEL: This field is the N-selector, and is 1 octet in length. In IS- o System ID
IS auto-configuring, it must be set to "00".
3.3. IS-IS NET Duplication Detection and Resolution This field follows the area address field, and is 6 octets in
length. As specified in IS-IS protocol, this field must be
unique among all level-1 routers in the same area when the IS
operates at Level 1. In IS-IS auto-configuring, this field
SHOULD be the MAC address of one IS-IS enabled interface.
As described in Section 3, in IS-IS auto-configuring the NETs are o NSEL
distinguished by the System ID field in which it is a MAC address. So
for IS-IS neighbors' NET duplication, it is equal to MAC address
duplication in a LAN, which means a serious problem that devices need
to be changed. So the NET duplication detection and resolution
mechanism is actually used between non-neighbors which are within
the same IS-IS area.
The rational of IS-IS NET duplication detection and resolution is This field is the N-selector, and is 1 octet in length. In IS-
described as the following. IS auto-configuring, it SHOULD be set to "00".
3.3.1. Router-Hardware-Fingerprint TLV 3.3. IS-IS NET Duplication Detection and Resolution
The Router-Hardware-Fingerprint TLV is defined in [OSPFv3AC]. This NET addresses need to be distinct within one IS-IS area. This
document re-uses it to achieve NET duplication detection. document auto-configure the NET address based on the MAC address
which are supposed to be globally unique, but in order to detect and
correct the possible MAC duplication, this section defines how IS-IS
may detect and correct NET duplication.
0 1 2 3 3.3.1. Router-Hardware-Fingerprint TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint (Variable) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Router-Hardware-Fingerprint TLV Format
As defined in [OSPFv3AC], the contents of the hardware fingerprint The Router-Hardware-Fingerprint TLV is defined in
should be some combination of CPU ID, or serial number(s) that [I-D.ietf-ospf-ospfv3-autoconfig]. This document re-uses it to
provides an extremely high probability of uniqueness. It MUST be achieve NET duplication detection.
based on hardware attributes that will not change across hard and
soft restarts. The length of the Router-Hardware-Fingerprint is 0 1 2 3
variable but must be 32 octets or greater. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint (Variable) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Router-Hardware-Fingerprint TLV Format
As defined in [I-D.ietf-ospf-ospfv3-autoconfig], the contents of the
hardware fingerprint should be some combination of 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. The length of the Router-Hardware-
Fingerprint is variable but must be 32 octets or greater.
Note that, since the TLV is to detect MAC address based NET Note that, since the TLV is to detect MAC address based NET
duplication, the TLV content MUST NOT only use MAC address. MAC duplication, the TLV content SHOULD NOT use MAC address.
address plus other information are also not recommended to use.
3.3.2. NET Duplication Detection and Resolution Procedures 3.3.2. NET Duplication Detection and Resolution Procedures
1) Flood the Router-Hardware-Fingerprint TLVs 1) Flood the Router-Hardware-Fingerprint TLVs
When an IS-IS auto-configuration router gets online, it MUST include When an IS-IS auto-configuration router gets online, it MUST
the Router-Hardware-Fingerprint TLV in the first originated level-1 include the Router-Hardware-Fingerprint TLV in the first
LSP. Then all the routers in the area could receive the information originated level-1 LSP. Then all the routers in the area could
in the TLV. receive the information in the TLV.
2) Compare the received Router-Hardware-Fingerprint TLVs 2) Compare the received Router-Hardware-Fingerprint TLVs
An IS-IS auto-configuring router MUST compare a received self- An IS-IS auto-configuring router MUST compare a received self-
originated LSP's Router-Hardware-Fingerprint TLV against its own one. originated LSP's Router-Hardware-Fingerprint TLV against its own
If they are equal, it means the LSP was indeed originated by the one. If they are equal, it means the LSP was indeed originated by
router itself; if they are not equal, it means some other router has the router itself; if they are not equal, it means some other
the same NET originated the LSP, thus there is a NET duplication. router has the same NET originated the LSP, thus there is a NET
duplication.
3) Duplication resolution 3) Duplication resolution
When NET duplication occurs, the router with the numerically smaller When NET duplication occurs, the router with the numerically
router hardware fingerprint MUST generate a new NET. smaller router hardware fingerprint MUST generate a new NET. The
newly generated NET SHOULD take a NET duplication detection as
well.
4) Purge the LSPs containing duplicated NET 4) Purge the LSPs containing duplicated NET
Before flooding the new NET, the LSP with the prior duplicate NET Before flooding the new NET, the LSP with the prior duplicate NET
MUST be purged. And any IS-IS neighbor adjacencies MUST be MUST be purged. And any IS-IS neighbor adjacencies MUST be
reestablished. reestablished.
5) Re-join the network with the new NET 5) Re-join the network with the new NET
After purging the LSPs with the duplicated NET, the router re-join After purging the LSPs with the duplicated NET, the router re-join
the IS-IS auto-configuration network with the newly generated NET. the IS-IS auto-configuration network with the newly generated NET.
3.4. Authentication TLV 3.4. IS-IS TLVs Usage
3.4.1. Authentication TLV
Every IS-IS auto-configuration message MUST include an authentication Every IS-IS auto-configuration message MUST include an authentication
TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode
("Cleartext Password") in order to avoid the auto-conf router to ("Cleartext Password") in order to avoid the auto-conf router to
accidentally join an existing IS-IS network which is not intended to accidentally join an existing IS-IS network which is not intended to
be auto-configured. be auto-configured.
This feature is necessary because a low end CPE joining an existing This feature is necessary since it might seriously break an existing
IS-IS network might seriously break it or cause unnecessary IS-IS network or cause unnecessary management confusion if a low end
management confusion. CPE (which might be the normal form of ISIS-autoconf routers)
occasionally joins the network.
The cleartext password is specified as "isis-autoconf". Routers that The cleartext password is specified as "isis-autoconf". Routers that
implement IS-IS auto-configuration MUST use this password as default, implement IS-IS auto-configuration MUST use this password as default,
so that different routers could authenticate each other with no human so that different routers could authenticate each other with no human
intervene as default. And routers MUST be able to set manual password intervene as default. And routers MUST be able to set manual
by the users. password by the users.
3.5. Wide Metric 3.4.2. Wide Metric TLV
IS-IS auto-configuration routers SHOULD support wide metric (TLV 22, IS-IS auto-configuration routers SHOULD support wide metric (TLV 22,
[RFC5305]). It is recommended that IS-IS auto-configuration routers [RFC5305]). It is recommended that IS-IS auto-configuration routers
use a high metric value (e.g. 1000000) as default in order to use a high metric value (e.g. 1000000) as default in order to
typically prefer the manually configured adjacencies rather than the typically prefer the manually configured adjacencies rather than the
auto-conf ones. auto-conf ones.
3.6. Adjacency Formation Consideration 3.4.3. Dynamic Host Name TLV
ISIS does not require strict hold timers matching to form adjacency. IS-IS auto-configuration routers SHOULD advertise their Dynamic Host
But a reasonable range might be needed. Whether we need to specify a Names TVL (TLV 137, [RFC5301]). The host names could be provisioned
best practice timers in ISIS-AC is an open question.[TBD]. by an IT system, or just use the name of vendor, device type or
serial number etc.
4. Co-existence with Other IGP Auto-configuration 3.4.4. Purge Originator Identification TLV
For troubleshooting purpose, the Purge Originator Identification TLV
(TLV 13, [RFC6232]) MAY be used to determin the origin of the purge.
Please refer to [RFC6232] for details.
3.5. Routing Behavior Considerations
3.5.1. Adjacency Formation
Since ISIS does not require strict hold timers matching to form
adjacency, this document does not specify specific hold timers.
However, the timers should be within a reasonable range based on
current practisce in the industry. (For example, 30 seconds for
holdtime and 20 minutes for LSP lifetime.)
3.5.2. Co-existing with Other IGP Auto-configuration
If a router supports multiple IGP auto-configuration mechanisms (e.g. If a router supports multiple IGP auto-configuration mechanisms (e.g.
both IS-IS auto-configuration and OSPF auto-configuration), then in both IS-IS auto-configuration and OSPF auto-configuration), then in
practice it is a problem that there should be a mechanism to decide practice it is a problem that there should be a mechanism to decide
which IGP to be used, or even both. which IGP to be used, or even both.
However, it is not proper to specify choice/interaction of multiple However, the behavior of multiple IGP protocols interaction should be
IGPs in any standalone IGP auto-configuration protocols. It should be done in the router level rather than in any IGP protocols.
done in the CPE level. Currently, there is some relevant work Currently, there is some relevant work going on, for example, the
emerging, for example, the suggestion from [HOMENET-HNCP] is to have [I-D.ietf-homenet-hncp] is to have the proposed HNCP (Home Network
the proposed HNCP (Home Network Control Protocol) choose what IGP Control Protocol) choose what IGP should be used.
should be used.
5. Security Considerations 4. Security Considerations
In general, auto-configuration is mutually incompatible with
authentication. So we can't have both. This is not really specific
to IS-IS.
Unwanted routers could easily join in an existing IS-IS auto- Unwanted routers could easily join in an existing IS-IS auto-
configuration network by setting the authentication password as configuration network by setting the authentication password as
"isis-autoconf" default value or sniff the cleartext password online. "isis-autoconf" default value or sniff the cleartext password online.
However, this is a common security risk shared by other IS-IS However, this is a common security risk shared by other IS-IS
networks that don't set proper authentication mechanisms. For wired networks that don't set proper authentication mechanisms. For wired
deployment, the wired line itself could be considered as an implicit deployment, the wired line itself could be considered as an implicit
authentication that normally unwanted routers are not able to connect authentication that normally unwanted routers are not able to connect
to the wire line; for wireless deployment, the authentication could to the wire line; for wireless deployment, the authentication could
be achieve at the lower wireless link layer. be achieve at the lower wireless link layer.
Malicious router could modify the SystemID field to cause NET Malicious router could modify the SystemID field to cause NET
duplication detection and resolution vibrate thus cause the routing duplication detection and resolution vibrate thus cause the routing
system vibrate. system vibrate.
6. IANA Considerations 5. IANA Considerations
The Router Hardware Fingerprint TLV type code needs an assignment by The Router Hardware Fingerprint TLV type code needs an assignment by
IANA. IANA.
7. Acknowledgments 6. Acknowledgements
Many useful comments and contributions were made by Sheng Jiang. Many useful comments and contributions were made by Sheng Jiang.
This document was inspired by [OSPFv3AC]. This document was inspired by [OSPFv3AC].
8. References This document was produced using the xml2rfc tool [RFC2629].
(initiallly prepared using 2-Word-v2.0.template.dot. )
8.1. Normative References 7. References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 7.1. Normative References
dual environments", RFC 1195, December 1990.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
Authentication", RFC 5304, October 2008. dual environments", RFC 1195, December 1990.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
Engineering", RFC 5305, October 2008. June 1999.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
2008. Mechanism for IS-IS", RFC 5301, October 2008.
8.2. Informative References [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[OSPFv3AC]Lindem, A., and J. Arkko, "OSPFv3 Auto-Configuration", Work [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
in Progress, October 2013 Engineering", RFC 5305, October 2008.
[HOMENET-HNCP] [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
Stenberg, M., and S. Barth, "Home Networking Control 2008.
Protocol", Work in Progress, February 05
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232, May
2011.
7.2. Informative References
[I-D.ietf-homenet-hncp]
Stenberg, M. and S. Barth, "Home Networking Control
Protocol", draft-ietf-homenet-hncp-01 (work in progress),
June 2014.
[I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-09 (work in progress),
September 2014.
Authors' Addresses Authors' Addresses
Bing Liu Bing Liu
Huawei Technologies Co., Ltd Huawei Technologies
Q14, Huawei Campus Q14, Huawei Campus, No.156 Beiqing Road
No.156 Beiqing Rd. Hai-Dian District, Beijing, 100095
Hai-Dian District, Beijing 100095
P.R. China P.R. China
Email: leo.liubing@huawei.com Email: leo.liubing@huawei.com
Bruno Decraene Bruno Decraene
Orange Orange
Issy-les-Moulineaux Issy-les-Moulineaux FR
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Bonn, Bonn
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Mikael Abrahamsson Mikael Abrahamsson
T-Systems T-Systems
Stockholm, Stockholm
Sweden Sweden
Email: mikael.abrahamsson@t-systems.se Email: mikael.abrahamsson@t-systems.se
 End of changes. 76 change blocks. 
201 lines changed or deleted 238 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/