Internet DRAFT - draft-eastlake-isis-ia-tlv
draft-eastlake-isis-ia-tlv
Network Working Group Donald Eastlake
INTERNET-DRAFT Yizhou Li
Intended status: Proposed Standard Huawei
Expires: April 21, 2013 October 22, 2012
Interface Addresses TLV
<draft-eastlake-isis-ia-tlv-01.txt>
Abstract
This document specifies an IS-IS (Intermediate System to Intermediate
System) TLV that enables the reporting by an Intermediate System of
sets of addresses of different types such that all of the addresses
in each set designate the same interface (port). For example, an
EUI-48 MAC (Extended Unique Identifier 48-bit, Media Access Control)
address, IPv4 address, and IPv6 address can be reported as all
corresponding to the same interface. Such information could be used,
for example, to synthesize responses to or by-pass the need for the
Address Resolution Protocol (ARP) or the IPv6 Neighbor Discovery (ND)
protocol in some cases.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
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/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
D. Eastlake, et al. [Page 1]
INTERNET-DRAFT IA TLV
Table of Contents
1. Introduction............................................3
1.1 Conventions Used in This Document......................3
2. The Interface Addresses TLV.............................4
3 IA-TLV sub-TLVs..........................................7
3.1 AFN Size sub-TLV.......................................7
3.2 Data Label sub-TLV.....................................8
3.3 Nickname sub-TLV.......................................9
3.4 Fixed Address sub-TLV..................................9
4. Example................................................11
5. IANA Considerations....................................12
6. Security Considerations................................13
7. Normative References...................................14
8. Informative References.................................14
Change History............................................16
00 to 01..................................................16
Acknowledgements..........................................17
D. Eastlake, et al. [Page 2]
INTERNET-DRAFT IA TLV
1. Introduction
This document specifies an IS-IS (Intermediate System to Intermediate
System [ISO-10589] [RFC1195]) TLV that enables the reporting by an
Intermediate System in its LSP (Link State PDU) of sets of addresses
of different types such that all of the addresses in each set
designate the same interface (port). For example, an EUI-48 MAC
(Extended Unique Identifier 48-bit, Media Access Control [RFC5342])
address, IPv4 address, and IPv6 address can be reported as all three
corresponding to the same interface. Such information could be used,
for example, to synthesize responses to or by-pass the need for the
Address Resolution Protocol (ARP, [RFC826]), Reverse Address
Resolution Protocol (RARP, [RFC903]) or the IPv6 Neighbor Discovery
(ND [RFC4861]) protocols in some cases.
Although, in some IETF protocols, address field types are represented
by EtherType [802] or Hardware Type [RFC5494] only Address Family
Number is used in this TLV.
1.1 Conventions Used in This Document
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 [RFC2119].
D. Eastlake, et al. [Page 3]
INTERNET-DRAFT IA TLV
2. The Interface Addresses TLV
The Interface Addresses TLV is used to indicate that a set of
addresses indicate the same interface. These addresses can be in
different address families. For example, it can be used to declare
that an interface has a particular IPv4 address, IPv6 address, and
EUI-48 MAC address.
The Template Size gives the number of AFNs present below. The set of
AFNs preent give a template for the type and order of addresses in
each Address Set.
+-+-+-+-+-+-+-+-+
| Type = TBD | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Set End | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+
| Template Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 1 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 2 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set N (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| optional sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 1. The Interface Addresses TLV
o Type: Interface Addresses TLV type, set to TBD[#247 suggested]
(IA-TLV).
o Length: Variable, minimum 7. If length is 6 or less, the TLV MUST
D. Eastlake, et al. [Page 4]
INTERNET-DRAFT IA TLV
be ignored.
o E: The E (rEachability) flag is set to one to indicate that the
interfaces whose addresses are being given in the TLV are
reachable through the Intermediate System that is advertising the
TLV.
o RESV: Reserved. MUST be sent as zero and ignored on receipt.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
o Addr Set End: The unsigned offset of the byte, within the TLV
value part, of the last byte of the last Address Set. This will be
the byte just before the first sub-TLV if any sub-TLVs are
present. [RFC5305]
o Confidence: This 8-bit quantity indicates the confidence level in
the addresses being transported. The semantics of the Confidence
are further defined by the technology using the IA-TLV.
o Template Size: A byte containing the unsigned integer number K of
AFNs (Address Family Numbers) in the template specifying the
structure of each Address Set occurring later in the TLV. The
minimum valid value is 1 and there must be room in the TLV for the
AFNs. If Template Size is zero or too big, the TLV MUST be
ignored.
o AFN: A two-byte Address Family Number. The number of AFNs present
is given in the Template Size field. This sequence specifies the
structure of the Address Sets occurring later in the TLV. For
example, if Template Size is 2 and the two AFNs present are the
AFNs for IPv4 and EUI-48, in that order, then each Address set
present will consist of a 4-byte IPv4 address followed by a 6-byte
MAC address. If any AFNs are present that are unknown to the
receiving IS and the length of the corresponding address is not
provided by a sub-TLV as specified below, the receiving IS will be
unable to parse the Address Sets and MUST ignore the enclosing
TLV.
o Address Set: Each address set consists of a sequence of Template
Size number of addresses of the types given by the AFN sequence
template earlier in the TLV in the same order as those AFNs. No
alignment, other than to a byte boundary, is guaranteed. The
addresses in each Address Set are contiguous with no unused bytes
between them and the Address Sets are contiguous with no unused
bytes between Address Sets. The Address Sets must fit within the
TLV. If the product of the size of an Address Set and the number
of Address Sets is so large that this is not true, the TLV is
ignored.
D. Eastlake, et al. [Page 5]
INTERNET-DRAFT IA TLV
o sub-TLVs: If the Address Sets indicated by Addr Sets End do not
completely fill the Length of the TLV, the remaining bytes are
parsed as sub-TLVs [RFC5305]. These sub-TLVs are from a new
sequence of sub-TLVs. Any such sub-TLVs that are not known to the
receiving IS are ignored. Should this not be possible, for example
there is only one remaining byte or an apparent sub-TLV extends
beyond the end of the TLV, the containing IA-TLV is considered
corrupt and is ignored. Several sub-TLV types are specified in
Section 3.
This Reachable Interface Addresses TLV occurs only within LSP PDUs
and may occur multiple times in the same or different LSP PDUs with
the same or different templates.
Different IA-TLVs within the same or different LSP PDUs from the same
IS may have different templates. The same AFN may occur more than
once in a template and the same address may occur in more than one
address set. For example, an EUI-48 MAC address interface might have
three IPv6 addresses. This could be represented by an IA-TLV whose
template specifically provided for one EUI-48 address and three IPv6
addresses, which might be an efficient format if there were multiple
interfaces with that pattern. Alternatively, a template with one
EUI-48 and one IPv6 address could be used in an IA-TLV with three
address sets each having the same EUI-48 address but different IPv6
addresses, which might be the most efficient format if only one
interface had multiple IPv6 addresses and other interfaces had only
one IPv6 address.
In order to be able to parse the Address Sets, a receiving IS must
know at least the size of the address each AFN in the Temple
specifies; however, the presence of the Addr Set End field means that
the sub-TLVs, if any, can always be located by a receiving IS. An IS
can be assumed to know the size of IPv4 and IPv6 addresses (AFNs 1
and 2) and the size of the additional AFNs allocated by the IANA
Considerations below. Should an IS wish to include an AFN that some
receiving IS in the campus may not know, it SHOULD include an AFN-
Size sub-TLV as described below. If an IA-RLV is received with one or
more AFNs in its template for which the receiving IS does not know
the length and for which an AFN-Size sub-TLV is not present, that IA-
TLV will be ignored.
D. Eastlake, et al. [Page 6]
INTERNET-DRAFT IA TLV
3 IA-TLV sub-TLVs
IA-TLVs may have trailing sub-TLVs [RFC5305] as specified below.
These sub-TLVs occur after the Address Sets and the amount of space
available for sub-TLVs is determined from the overall IA-TLV length
and the value of the Addr Set End byte.
There is no ordering restriction on IA-TLV sub-TLVs. Unless otherwise
specified each sub-TLV type can occur zero, one, or many times in an
IA-TLV.
3.1 AFN Size sub-TLV
Using this sub-TLV, the originating IS can specify the size of an
address type. This is useful under two circumstances:
1. One or more AFNs that are unknown to the receiving IS appears in
the template. If an AFN Size sub-TLV is present for each such AFN,
the at least the IA-TLV can be parses the Address Sets and make
use of any address types present that it does understand.
2. If an AFN occurs in the template that represents a variable length
address, this sub-TLV gives its size for all occurrences in that
IA-TLV.
+-+-+-+-+-+-+-+-+
|subType = AFNsz| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record(s) | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each AFN Size Record is structured as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AdrSize | (1 byte)
+-+-+-+-+-+-+-+-+
o Type: AFN-Size sub-TLV type, set to 1 (AFNsz).
o Length: 3*n where n is the number of AFN Size Records present. If
n is not a multiple of 3, the sub-TLV MUST be ignored.
o AFN Size Record(s): Zero or more 3-byte records, each giving the
size of an address type identified by an AFN,
D. Eastlake, et al. [Page 7]
INTERNET-DRAFT IA TLV
o AFN: The AFN whose length is being specified by the AFN Size
Record.
o AdrSize: The length of the address specified by the AFN field.
This sub-TLV may occur multiple times in an enclosing IA-TLV.
The declaration of a size for an AFN address type controls for the
occurrences of the AFN in the enclosing IA-TLV and for and subsequent
IA-TLVs in the enclosing LSP PDU until the next occurrence in the LSP
PDU of an AFN Size sub-TLV for that AFN. Thus, an AFN Size sub-TLV
for a fixed size AFN need only be included in the first IA-TLV in a
PDU. But one must be included in or before first IA-TLV using an AFN
in each PDU where that AFN appears in the template if needed.
Otherwise Address Sets will not be parseable by a receiving IS. If
multiple AFN Size Records occur for the same AFN in the same AFN Size
sub-TLV the last size given controls.
An AFN Size sub-TLV for any AFN known to the receiving IS (which
always includes AFN 1 and 2 and the AFNs specified in Section 5) is
compared with the size known to the IS and if they differ, the
enclosing IA-TLV is ignored.
3.2 Data Label sub-TLV
+-+-+-+-+-+-+-+-+
|Type==DATA-LABEL| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Data Label (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: Data Label sub-TLV type, set to 2 (DATA-LABEL).
o Length: variable, minimum 1. If Length is zero, the sub-TLV MUST
be ignored.
o Data Label: A data label under which all the interfaces listed in
the TLV can be reached. Exact meaning for different lengths
depends on the technology in use. If absent, no label is
specified. If more than one different Data Label sub-TLV occurs in
an Interface Addresses TLV, it indicates that the interfaces
listed can be reach via all the labels given.
For TRILL use, if Length=2, the Data Label is a VLAN-ID which
appears right justified in two bytes with four leading bits that
MUST be sent as zero and ignored on receipt.
D. Eastlake, et al. [Page 8]
INTERNET-DRAFT IA TLV
3.3 Nickname sub-TLV
+-+-+-+-+-+-+-+-+
|Type=NICKNAME | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Nickname (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: Data Label sub-TLV type, set to 3 (NICKNAME).
o Length: variable, minimum 1. If Length is zero, the sub-TLV MUST
be ignored.
o Nickname: The nickname of an Intermediate System through which all
the interfaces listed in the TLV can be reached. Exact meaning for
different lengths depends on the technology in use. If absent, no
nickname is specified. If more than one different Nickname sub-TLV
occurs in an Interface Addresses TLV, it indicates that the
interfaces listed can be reach via all the nicknames given.
Occurrence of one or more Nickname sub-TLVs in an Interface
Addresses TLV does not change the effect of the E flag bit in the
TLV initial fixed fields; the E flag having the value one still
indicates that the interfaces are reachable through the
Intermediate System advertising the TLV.
3.4 Fixed Address sub-TLV
There may be cases where, in an Interface Addresses TLV, the same
address would appear across every address set in the TLV. To avoid
having a larger template and wasted space in all Address Sets, this
sub-TLV can be used to indicate such a fixed address
+-+-+-+-+-+-+-+-+
|Type=FIXEDADR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Fixed Address (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: Data Label sub-TLV type, set to 4 (FIXEDADR).
o Length: variable, minimum 3. If Length is 2 or less, the sub-TLV
MUST be ignored.
D. Eastlake, et al. [Page 9]
INTERNET-DRAFT IA TLV
o AFN: Address Family Number of the Fixed Address.
o Fixed Address: The address of the type indicated by the preceeding
AFN field that is considered to be part of every Address Set in
the TLV.
D. Eastlake, et al. [Page 10]
INTERNET-DRAFT IA TLV
4. Example
TBD
D. Eastlake, et al. [Page 11]
INTERNET-DRAFT IA TLV
5. IANA Considerations
IANA is requested to allocate a new TLV number for IA-TLV [#247
suggested because #147 is the MAC Reachability (MAC-RI) TLV].
IANA is requested to allocate three new AFN numbers as follows:
Number Description References
TBD(26) EUI-48 RFC 5342, this document
TBD(27) EUI-64 RFC 5342, this document
TBD(28) IPv6/64 This document.
[[[Curiously enough, the AFN RFC references seem to always use
"Address Family Identifier" although IANA uses "Address Family
Number". Furthermore, neither of the two RFCs pointed to by the IANA
Address Family Number Registry actually has IANA Considerations for
Address Family Numbers although the IANA Registry has shows policies
for different ranges of AFNs. Conceivably, such IANA Considerations
should appear in this document.]]]
IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6
address. If present, there will normally be an EUI-64 or EUI-48
address in the address set to provide the lower 64 bits of the IPv6
address. For this purpose, an EUI-48 is expanded to 64 bits as
described in [RFC5342].
IANA is requested to establish a new subregistry for sub-TLVs of the
IA-TLV with initial contents as shown below.
Name: Sub-TLVs for TLV TBD[#247]
Procedure: Expert Review
Reference: This document
Type Description Reference
---- ----------- ---------
0 Reserved
1 AFN Size This document
2 Nickname This document
3 Data Label This document
4 Fixed Address This docment
5-254 Available This document
255 Reserved
[[[Should administrative tag sub-TLVs (see RFC 5130) be allowed?]]]
D. Eastlake, et al. [Page 12]
INTERNET-DRAFT IA TLV
6. Security Considerations
This document raises no new security issues for IS-IS. IS-IS security
may be used to secure IS-IS PDUs containing the IA-TLV. See
[RFC5304] and [RFC5310].
D. Eastlake, et al. [Page 13]
INTERNET-DRAFT IA TLV
7. Normative References
[ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate
System to Intermediate System Intra-Domain Routing Exchange
Protocol for use in Conjunction with the Protocol for Providing
the Connectionless-mode Network Service (ISO 8473)", 2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Intermediate
Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", 2008.
[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
5310, February 2009.
8. Informative References
[802] - IEEE, "Standard for Local and Metropolitan Area Networks:
Overview and Architecture", IEEE Std. 802-2001, 8 March 2002.
[RFC826] - Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48-bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, RFC
826, November 1982.
[RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Reverse Address Resolution Protocol", STD 38, RFC 903, June
1984.
[RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
D. Eastlake, et al. [Page 14]
INTERNET-DRAFT IA TLV
2008.
[RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
for the Address Resolution Protocol (ARP)", RFC 5494, April
2009.
D. Eastlake, et al. [Page 15]
INTERNET-DRAFT IA TLV
Change History
RFC Editor Note: Please delete this section before publication.
00 to 01
Add the Fixed Address sub-TLV.
Minor editorial changes.
D. Eastlake, et al. [Page 16]
INTERNET-DRAFT IA TLV
Acknowledgements
The authors gratefully acknowledge the contributions and review by
the following:
Linda Dunbar
This document was produced with raw nroff. All macros used were
defined in the source files.
Authors' Addresses
Donald Eastlake
Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56624558
Email: liyizhou@huawei.com
D. Eastlake, et al. [Page 17]
INTERNET-DRAFT IA TLV
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2012 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. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake, et al. [Page 18]
