GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7961

Internet Engineering Task Force (IETF) D. Eastlake 3rd Request for Comments: 7961 Y. Li Category: Standards Track Huawei ISSN: 2070-1721 August 2016

       Transparent Interconnection of Lots of Links (TRILL):
                   Interface Addresses APPsub-TLV

Abstract

 This document specifies a TRILL (Transparent Interconnection of Lots
 of Links) IS-IS application sub-TLV that enables the reporting by a
 TRILL switch of sets of addresses.  Each set of addresses reports all
 of the addresses that designate the same interface (port) and also
 reports the TRILL switch by which that interface is reachable.  For
 example, a 48-bit MAC (Media Access Control) address, IPv4 address,
 and IPv6 address can be reported as all corresponding to the same
 interface reachable by a particular TRILL switch.  Such information
 could be used in some cases to synthesize responses to, or bypass the
 need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor
 Discovery (ND) protocol, or the flooding of unknown MAC addresses.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7961.

Eastlake & Li Standards Track [Page 1] RFC 7961 TRILL: IA APPsub-TLV August 2016

Copyright Notice

 Copyright (c) 2016 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.

Table of Contents

 1. Introduction ....................................................3
    1.1. Conventions Used in This Document ..........................3
 2. Format of the Interface Addresses APPsub-TLV ....................4
 3. IA APPsub-TLV Sub-sub-TLVs ......................................9
    3.1. AFN Size Sub-sub-TLV ......................................10
    3.2. Fixed Address Sub-sub-TLV .................................11
    3.3. Data Label Sub-sub-TLV ....................................12
    3.4. Topology Sub-sub-TLV ......................................12
 4. Security Considerations ........................................13
 5. IANA Considerations ............................................14
    5.1. Allocation of AFN Values ..................................14
    5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry ...................15
    5.3. IA APPsub-TLV Number ......................................16
 6. Additional AFN Information .....................................16
 7. Processing Address Sets ........................................16
 8. References .....................................................18
    8.1. Normative References ......................................18
    8.2. Informative References ....................................20
 Appendix A. Examples ..............................................21
    A.1. Simple Example ............................................21
    A.2. Complex Example ...........................................22
 Acknowledgments ...................................................24
 Authors' Addresses ................................................24

Eastlake & Li Standards Track [Page 2] RFC 7961 TRILL: IA APPsub-TLV August 2016

1. Introduction

 This document specifies a TRILL (Transparent Interconnection of Lots
 of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV) [RFC6823]
 that enables the convenient representation of sets of addresses where
 all of the addresses in each set designate the same interface (port).
 For example, a 48-bit MAC (Media Access Control) [RFC7042] address,
 IPv4 address, and IPv6 address can be reported as all three
 designating the same interface.  In addition, a Data Label (VLAN or
 Fine-Grained Label (FGL) [RFC7172]) is specified for the interface,
 along with the TRILL switch and, optionally, the TRILL switch port
 from which the interface is reachable.  Such information could be
 used in some cases to synthesize responses to, or bypass the need
 for, the Address Resolution Protocol (ARP) [RFC826], the IPv6
 Neighbor Discovery (ND) [RFC4861] protocol, the Reverse Address
 Resolution Protocol (RARP) [RFC903], or the flooding of unknown
 destination MAC addresses [ARPND].  If the information reported is
 complete, it can also be used to detect and discard packets with
 forged source addresses.
 This APPsub-TLV appears inside the TRILL GENINFO TLV specified in the
 End Station Address Distribution Information (ESADI) RFC [RFC7357]
 but may also occur in other application contexts.  The
 "directory assistance" TRILL Edge services [DirectoryScheme] are
 expected to make use of this APPsub-TLV.
 Although in some IETF protocols address field types are represented
 by an Ethertype [RFC7042] or a hardware address type [RFC5494], only
 the Address Family Number (AFN) is used in this APPsub-TLV to
 represent the address field type.

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].
 Capitalized IANA-related terms such as "Expert Review" are to be
 interpreted as described in [RFC5226].
 The terminology and acronyms of [RFC6325] are used herein, along with
 the following additional acronyms and terms:
 AFN: Address Family Number
    (http://www.iana.org/assignments/address-family-numbers/)
 APPsub-TLV: Application sub-TLV [RFC6823]
 Data Label: VLAN or FGL

Eastlake & Li Standards Track [Page 3] RFC 7961 TRILL: IA APPsub-TLV August 2016

 FGL: Fine-Grained Label [RFC7172]
 IA: Interface Address(es)
 MAC: Media Access Control
 Nickname: A 16-bit TRILL switch identifier, as specified in
    Section 3.7 of [RFC6325] and as updated by Section 4 of [RFC7780]
 RBridge: An alternative name for a TRILL switch
 TRILL switch: A device that implements the TRILL protocol

2. Format of the Interface Addresses APPsub-TLV

 The Interface Addresses (IA) APPsub-TLV is used to advertise a set of
 addresses indicating the same interface (port) within a Data Label
 (VLAN or FGL).  It also associates that interface with the TRILL
 switch and, optionally, the TRILL switch port by which the interface
 is reachable.  These addresses can be in different address families.
 For example, the IA APPsub-TLV can be used to declare that a
 particular interface with specified IPv4, IPv6, and 48-bit MAC
 addresses in some particular Data Label is reachable from a
 particular TRILL switch.  While those three types of addresses are
 likely to be the only types of interest, any address type for which
 an AFN has been assigned by IANA can be represented.
 The Template field in a particular IA APPsub-TLV indicates the format
 of each Address Set it carries.  Certain well-known sets of addresses
 are represented by special values.  Other sets of addresses are
 specified by a list of AFNs.  The Template format that uses a list of
 AFNs provides an explicit pattern for the type and order of addresses
 in each Address Set in the IA APPsub-TLV that includes that Template.
 A device or application making use of IA APPsub-TLV data is not
 required to make use of all IA data.  For example, a device or
 application that was only interested in MAC and IPv6 addresses could
 ignore any IPv4 or other types of address information that was
 present.

Eastlake & Li Standards Track [Page 4] RFC 7961 TRILL: IA APPsub-TLV August 2016

 Figure 1 shows an IA APPsub-TLV as it would appear inside an IS-IS
 Flooding Scope Link State PDU (FS-LSP) using an extended flooding
 scope [RFC7356] TLV -- for example, in ESADI [RFC7357].  Within an
 IS-IS FS-LSP using traditional [ISO-10589] TLVs, the Type and Length
 would be 1-byte unsigned integers equal to or less than 255, but with
 an extended TLV, the Type and Length are 2-byte unsigned integers.
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type = (10)                   |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Length                        |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Addr Sets End                 |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Nickname                      |  (2 bytes)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Flags         |                  (1 byte)
        +-+-+-+-+-+-+-+-+
        | Confidence    |                  (1 byte)
        +-+-+-+-+-+-+-+-+-+-
        | Template ...                     (variable)
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
        | Address Set 1    (size determined by Template)    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
        | Address Set 2    (size determined by Template)    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
        |   ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
        | Address Set N    (size determined by Template)    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
        | optional sub-sub-TLVs ...
        +-+-+-+-+-+-+-+-+-+-+-+-...
               Figure 1: Interface Addresses APPsub-TLV
 o  Type: Interface Addresses TRILL APPsub-TLV type; set to 10
    (IA-SUBTLV).
 o  Length: Variable; minimum 7.  If Length is 6 or less or if the
    APPsub-TLV extends beyond the size of an encompassing TRILL
    GENINFO TLV or other context, the APPsub-TLV MUST be ignored.  For
    manageability, a counter reflecting the receipt of such malformed
    IA APPsub-TLVs should be maintained.

Eastlake & Li Standards Track [Page 5] RFC 7961 TRILL: IA APPsub-TLV August 2016

 o  Addr Sets End: The unsigned integer byte number, within the IA
    APPsub-TLV value part, of the last byte of the last Address Set,
    where the first byte is numbered 1.  This will be the number of
    the byte just before the first sub-sub-TLV if any sub-sub-TLVs are
    present (see Section 3).  The processing is as follows:
  1. If this field is greater than Length or points to before the

end of the Template, the IA APPsub-TLV is corrupt and MUST be

       discarded.
  1. If this field is equal to Length, there are no sub-sub-TLVs.
  1. If this field is less than Length, sub-sub-TLVs are parsed as

specified in Section 3.

    Note: This field is always 2 bytes in size.
 o  Nickname: The nickname (see Section 1.1) of the TRILL switch by
    which the Address Sets are reachable.  If 0, the Address Sets are
    reachable from the TRILL switch originating the message containing
    the APPsub-TLV (for example, an ESADI [RFC7357] message).
 o  Flags: A byte of flags, as follows:
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |D|L|   RESV    |
       +-+-+-+-+-+-+-+-+
       D: Directory flag: If D is 1, the APPsub-TLV contains directory
          information [RFC7067].
       L: Local flag: If L is 1, the APPsub-TLV contains information
          learned locally by observing ingressed frames [RFC6325].
          (Both D and L can be set to 1 in the same IA APPsub-TLV if a
          TRILL switch had learned an address locally and also
          advertised it as a directory.)
       RESV: Additional reserved flag bits that MUST be sent as zero
          and ignored on receipt.
 o  Confidence: This 8-bit unsigned quantity in the range 0 to 254
    indicates the confidence level in the addresses being transported
    (see Section 4.8.2 of [RFC6325]).  A value of 255 is treated as if
    it was 254.

Eastlake & Li Standards Track [Page 6] RFC 7961 TRILL: IA APPsub-TLV August 2016

 o  Template: The initial byte of this field is the unsigned integer
    K.  If K has a value from 1 to 31, it indicates that this initial
    byte is followed by a list of K AFNs that specify the exact
    structure and order of each Address Set occurring later in the
    APPsub-TLV.  K can be 1, which is the minimum valid value.  If K
    is 0, the IA APPsub-TLV is ignored.  If K is 32 to 254, the length
    of the Template field is 1 byte, and its value is intended to
    correspond to a particular ordered set of AFNs, some of which are
    specified below.  The value of 255 for K is reserved for future
    definition and causes the IA APPsub-TLV to be ignored.
    If the Template uses explicit AFNs, it looks like the following,
    with the number of AFNs, up to 31, equal to K.
          +-+-+-+-+-+-+-+-+
          |  K            |                  (1 byte)
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  AFN 1                        |  (2 bytes)
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  AFN 2                        |  (2 bytes)
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |   ...
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |  AFN K                        |  (2 bytes)
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    For K in the range 32 to 39, values indicate a specific sequence,
    as specified below.  The values of K from 40 to 254 are reserved
    for future specification.  If the value of K is not understood by
    a receiver of the IA-APPsub-TLV, any Address Sets present are
    ignored.
           K   Addresses in order of occurrence
          ---  --------------------------------
           32  48-bit MAC
           33  48-bit MAC, IPv4
           34  48-bit MAC, IPv6
           35  48-bit MAC, IPv4, IPv6
           36  48-bit MAC, RBridge port
           37  48-bit MAC, IPv4, RBridge port
           38  48-bit MAC, IPv6, RBridge port
           39  48-bit MAC, IPv4, IPv6, RBridge port
    For ease of decoding, note that for values of K between 32 and 39
    inclusive, the 0x01 bit indicates that an IPv4 address is present,
    the 0x02 bit indicates that an IPv6 address is present, and the
    0x04 bit indicates that an RBridge Port ID is present.

Eastlake & Li Standards Track [Page 7] RFC 7961 TRILL: IA APPsub-TLV August 2016

 o  AFN: A 2-byte Address Family Number.  The number of AFNs present
    is given by K, except that there are no AFNs if K is greater than
    31.  The AFN sequence specifies the structure of the Address Sets
    occurring later in the TLV.  For example, if the Template size is
    2 and the two AFNs present are the AFNs for a 48-bit MAC and an
    IPv4 address, in that order, then each Address Set present will
    consist of a 6-byte MAC address followed by a 4-byte IPv4 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-sub-TLV as specified below, the receiving IS will be unable to
    parse the Address Sets and MUST ignore the IA APPsub-TLV.
 o  Address Set: Each Address Set in the APPsub-TLV consists of
    exactly the same sequence of addresses and types as specified by
    the Template earlier in the APPsub-TLV.  No alignment, other than
    to a byte boundary, is provided.  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
    successive Address Sets.  The Address Sets must fit within the
    TLV.  See Section 7 on interpreting certain Address Sets.
 o  sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do
    not completely fill the length of the APPsub-TLV (as indicated by
    the Length field), then per Section 4 of [RFC5305] the remaining
    bytes are parsed as sub-sub-TLVs.  Any such sub-sub-TLVs that are
    not known to the receiving TRILL switch are ignored.  Should this
    parsing not be possible -- for example, there is only one
    remaining byte or an apparent sub-sub-TLV extends beyond the end
    of the TLV -- the containing IA APPsub-TLV is considered corrupt
    and is ignored.  (Several sub-sub-TLV types are specified in
    Section 3.)
 Different IA APPsub-TLVs within the same or different LSPs or other
 data structures may have different Templates.  The same AFN may occur
 more than once in a Template, and the same address may occur in
 different Address Sets.  For example, a 48-bit MAC address interface
 might have three different IPv6 addresses.  This could be represented
 by an IA APPsub-TLV whose Template specifically provided for one
 EUI-48 address and three IPv6 addresses; this might be an efficient
 format if there were multiple interfaces with that pattern.
 Alternatively, a Template with one 48-bit MAC and one IPv6 address
 could be used in an IA APPsub-TLV with three Address Sets each having
 the same MAC address but different IPv6 addresses; this might be the
 most efficient format if only one interface had multiple IPv6
 addresses and other interfaces had only one IPv6 address.

Eastlake & Li Standards Track [Page 8] RFC 7961 TRILL: IA APPsub-TLV August 2016

 In order to be able to parse the Address Sets, a receiving TRILL
 switch must know at least the size of the address for each AFN or
 address type the Template specifies; however, the presence of the
 Addr Sets End field means that the sub-sub-TLVs, if any, can always
 be located by a receiver.  A TRILL switch can be assumed to know the
 size of the AFNs mentioned in Section 5.  Should a TRILL switch wish
 to include an AFN that some receiving TRILL switch in the campus may
 not know, it SHOULD include an AFN Size sub-sub-TLV as described in
 Section 3.1.  If an IA APPsub-TLV is received with one or more AFNs
 in its Template for which the receiving TRILL switch does not know
 the length and for which an AFN Size sub-sub-TLV is not present, that
 IA APPsub-TLV MUST be ignored.
 For manageability, a counter of ill-formed IA APPsub-TLVs received
 and ignored due to unknown K, unknown AFN, and the like (as described
 above) should be maintained.

3. IA APPsub-TLV Sub-sub-TLVs

 IA APPsub-TLVs can have sub-sub-TLVs (sub-TLVs of sub-TLVs [RFC5305])
 at the end, as specified below.  These sub-sub-TLVs occur after the
 Address Sets.  The amount of space available for sub-sub-TLVs is
 determined from the overall IA APPsub-TLV length and the value of the
 Addr Sets End byte.
 There is no ordering restriction on sub-sub-TLVs.  Unless otherwise
 specified, each sub-sub-TLV type can occur zero, one, or many times
 in an IA APPsub-TLV.  Any sub-sub-TLVs for which the Type is unknown
 are ignored.  For manageability, a counter of sub-sub-TLVs received
 and ignored due to an unknown Type or other reasons, as described
 below, should be maintained.
 The data structures of the sub-sub-TLVs shown below, with 2-byte
 Types and Lengths, assume that the enclosing IA APPsub-TLV is in an
 extended LSP TLV [RFC7356] or some non-LSP context.  If they were
 used in an IA APPsub-TLV in a non-extended LSP [ISO-10589], then only
 1-byte Types and Lengths could be used.  As a result, any sub-sub-TLV
 types greater than 255 could not be used, and Length would be limited
 to 255.

Eastlake & Li Standards Track [Page 9] RFC 7961 TRILL: IA APPsub-TLV August 2016

3.1. AFN Size Sub-sub-TLV

 Using this sub-sub-TLV, the originating TRILL switch can specify the
 size of an address type.  This is useful under the following two
 circumstances:
 1. One or more AFNs that are unknown to the receiving TRILL switch
    appear in the Template.  If an AFN Size sub-sub-TLV is present for
    each such AFN, then at least the IA APPsub-TLV can be parsed, and
    possibly other addresses in each Address Set can still be used.
 2. If an AFN occurs in the Template that represents a variable-length
    address, this sub-sub-TLV gives its size for all occurrences in
    that IA APPsub-TLV.
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type = AFNsz                  |  (2 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Length                        |  (2 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AFN Size Record 1                             |  (3 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AFN Size Record 2                             |  (3 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | AFN Size Record N                             |  (3 bytes)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 2: AFN Size Sub-sub-TLV
 Where each AFN Size Record is structured as follows:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  AFN                          |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  AdrSize      |                  (1 byte)
       +-+-+-+-+-+-+-+-+
 o  Type: AFN Size sub-sub-TLV type; set to 1 (AFNsz).
 o  Length: 3*N, where N is the number of AFN Size Records present.
    If Length is not a multiple of 3, the sub-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.

Eastlake & Li Standards Track [Page 10] RFC 7961 TRILL: IA APPsub-TLV August 2016

 o  AFN: The AFN whose length is being specified by the AFN Size
    Record.
 o  AdrSize: The length, in bytes, of addresses specified by the AFN
    field as an unsigned integer.
 An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL
 switch is compared with the size known to the TRILL switch.  If they
 differ, the IA APPsub-TLV is assumed to be corrupt and MUST be
 ignored.

3.2. Fixed Address Sub-sub-TLV

 There may be cases where, in a particular IA APPsub-TLV, the same
 address would appear in every Address Set across the IA APPsub-TLV.
 To avoid wasted space, this sub-sub-TLV can be used to indicate such
 a fixed address.  The address or addresses incorporated into the sets
 by this sub-sub-TLV are NOT mentioned in the IA APPsub-TLV Template.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Type = FIXEDADR               | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Length                        | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AFN                           | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Fixed Address                   (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-...
                  Figure 3: Fixed Address Sub-sub-TLV
 o  Type: Data Label sub-sub-TLV type; set to 2 (FIXEDADR).
 o  Length: Variable; minimum 2.  If Length is 0 or 1, the sub-sub-TLV
    MUST be ignored.
 o  AFN: Address Family Number of the Fixed Address.
 o  Fixed Address: The address of the Type indicated by the preceding
    AFN field that is considered to be part of every Address Set in
    the IA APPsub-TLV.
 The Length field implies a size for the Fixed Address.  If that size
 differs from the size of the address type for the given AFN as known
 by the receiving TRILL switch, the Fixed Address sub-sub-TLV is
 considered corrupt and MUST be ignored.

Eastlake & Li Standards Track [Page 11] RFC 7961 TRILL: IA APPsub-TLV August 2016

3.3. Data Label Sub-sub-TLV

 This sub-sub-TLV indicates the Data Label within which the interfaces
 listed in the IA APPsub-TLV are reachable.  It is useful if the IA
 APPsub-TLV occurs outside of the context of a message specifying the
 Data Label or if it is desired and permitted to override that
 specification.  Multiple occurrences of this sub-sub-TLV indicate
 that the interfaces are reachable in all of the Data Labels given.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type = DATALEN                 | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Length                        | (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Data Label                      (variable)
       +-+-+-+-+-+-+-+-+-+-+-+-+-...
                   Figure 4: Data Label Sub-sub-TLV
 o  Type: Data Label sub-TLV type; set to 3 (DATALEN).
 o  Length: 2 or 3.  If Length is some other value, the sub-sub-TLV
    MUST be ignored.
 o  Data Label: If Length is 2, the bottom 12 bits of the Data Label
    are a VLAN ID and the top 4 bits are reserved (MUST be sent as
    zero and ignored on receipt).  If Length is 3, the three Data
    Label bytes contain an FGL [RFC7172].

3.4. Topology Sub-sub-TLV

 The presence of this sub-sub-TLV indicates that the interfaces given
 in the IA APPsub-TLV are reachable in the topology given.  It is
 useful if the IA APPsub-TLV occurs outside of the context of a
 message indicating the topology or if it is desired and permitted to
 override that specification.  If it occurs multiple times, then the
 Address Sets are in all of the topologies given.
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type = TOPOLOGY                |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Length                        |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RESV  |        Topology       |  (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 5: Topology Sub-sub-TLV

Eastlake & Li Standards Track [Page 12] RFC 7961 TRILL: IA APPsub-TLV August 2016

 o  Type: Topology sub-TLV type; set to 4 (TOPOLOGY).
 o  Length: 2.  If Length is some other value, the sub-sub-TLV MUST be
    ignored.
 o  RESV: 4 reserved bits.  MUST be sent as zero and ignored on
    receipt.
 o  Topology: The 12-bit topology number [RFC5120].

4. Security Considerations

 The integrity of address mapping and reachability information as well
 as the correctness of Data Labels (VLANs or FGLs [RFC7172]) are very
 important.  Forged, altered, or incorrect address mapping or data
 labeling can lead to delivery of packets to the incorrect party,
 violating security policy.  However, this document merely describes a
 data format and does not provide any explicit mechanisms for securing
 that information, other than a few simple consistency checks that
 might detect some corrupted data.  Security on the wire, or in
 storage, for this data is to be provided by the transport or storage
 used.  For example, when transported with ESADI [RFC7357] or RBridge
 Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel]
 security mechanisms can be used, respectively.
 The address mapping and reachability information, if known to be
 complete and correct, can be used to detect some cases of forged
 packet source addresses [RFC7067].  In particular, if native traffic
 from an end station is received by a TRILL switch that would
 otherwise accept it but authoritative data indicates that the source
 address should not be reachable from the receiving TRILL switch, that
 traffic should be discarded.  The data format specified in this
 document may optionally include a TRILL switch Port ID number so that
 this forged address filtering can be optionally applied with port
 granularity.  For manageability, a counter of frames so discarded
 should be maintained.
 See [RFC6325] for general TRILL security considerations.

Eastlake & Li Standards Track [Page 13] RFC 7961 TRILL: IA APPsub-TLV August 2016

5. IANA Considerations

 The following subsections specify IANA allocations.

5.1. Allocation of AFN Values

 IANA has allocated values in the "Address Family Numbers" registry
 that may be useful for IA APPsub-TLVs.  The values are as follows:
      Hex    Decimal   Description      References
     -----   -------   -----------      ----------
      0001        1    IPv4
      0002        2    IPv6
      4005    16389    48-bit MAC       Section 2.1 of [RFC7042]
      4006    16390    64-bit MAC       Section 2.2 of [RFC7042]
      4007    16391    OUI              Section 6 of RFC 7961
      4008    16392    MAC/24           Section 6 of RFC 7961
      4009    16393    MAC/40           Section 6 of RFC 7961
      400A    16394    IPv6/64          Section 6 of RFC 7961
      400B    16395    RBridge Port ID  Section 6 of RFC 7961
 Other AFNs can be found at <http://www.iana.org/assignments/
 address-family-numbers>.
 See Section 7 on interpreting Address Sets.

Eastlake & Li Standards Track [Page 14] RFC 7961 TRILL: IA APPsub-TLV August 2016

5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry

 IANA has established a new sub-registry of the "Transparent
 Interconnection of Lots of Links (TRILL) Parameters" registry for
 sub-sub-TLVs of the Interface Addresses APPsub-TLV, with the
 following initial contents:
    Name:  Interface Addresses APPsub-TLV Sub-sub-TLVs
    Procedure:  Expert Review
    Note:  Types greater than 255 are not usable in some contexts.
    Reference:  RFC 7961
        Type      Description       Reference
       ------     -----------       ---------
           0      Reserved          RFC 7961
           1      AFN Size          RFC 7961
           2      Fixed Address     RFC 7961
           3      Data Label        RFC 7961
           4      Topology          RFC 7961
       5-254      Unassigned
         255      Reserved          RFC 7961
   256-65534      Unassigned
       65535      Reserved          RFC 7961
 Expert Guidance: A designated expert for this registry should decide
    whether to permit the assignment of a type based on clear
    documentation of the proposed type as provided by the requester,
    such as a complete Internet-Draft.  New types should not duplicate
    existing types.  Requests should indicate whether a type less than
    255 is desired; such types can be used in contexts where only
    1 byte of a type (and usually only 1 byte of the length) is
    permitted.  Types greater than 255 can only be used where 2-byte
    types are allowed, such as in Extended Level 1 Flooding Scope
    (E-L1FS) or Extended Level 1 Circuit Scope (E-L1CS) extended
    FS-LSPs [RFC7356]; in those contexts, lengths up to 65535 bytes
    can also be expressed, although they may not be usable if the
    resulting TLV would not fit into a larger context restricted by an
    MTU setting or the like.  Values within the region below 255 and
    the region above 255 should be allocated sequentially, unless
    there is an extraordinary reason for a special value.

Eastlake & Li Standards Track [Page 15] RFC 7961 TRILL: IA APPsub-TLV August 2016

5.3. IA APPsub-TLV Number

 IANA has allocated type 10 as the IA APPsub-TLV in the "TRILL
 APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
 registry from the range under 256.  In the registry, the name is "IA"
 and the reference is this document.

6. Additional AFN Information

 This section provides additional information concerning AFNs that
 were allocated in connection with this document.  These AFNs are not
 restricted to use in the IA APPsub-TLV and may be used in other
 protocols where they would be appropriate.
 OUI: A 3-byte (24-bit) Organizationally Unique Identifier used as the
    initial 3 bytes of a MAC address.  See Sections 2.1 and 2.2 of
    [RFC7042], and Section 7 below.
 MAC/24: A 3-byte (24-bit) quantity used as the final 3 bytes of a
    48-bit MAC address.  See Section 2.1 of [RFC7042] and Section 7
    below.
 MAC/40: A 5-byte (40-bit) quantity used as the final 5 bytes of a
    64-bit MAC address.  See Section 2.2 of [RFC7042] and Section 7
    below.
 IPv6/64: An 8-byte (64-bit) quantity used as the initial 8 bytes of
    an IPv6 address.  See Section 7 below.
 RBridge Port ID: A 16-bit quantity that uniquely identifies a port on
    a TRILL switch (RBridge).  See Section 4.4.2 of [RFC6325].

7. Processing Address Sets

 The following processes should be followed in interpreting sets of
 AFN values in an IA APPsub-TLV to synthesize addresses.  These apply
 whether the AFN values came from sub-sub-TLVs, appeared within an
 Address Set, or came from both sources.  In general, the processing
 is applied separately to each Address Set as supplemented by any
 Fixed Address sub-sub-TLVs that are present.
 The OUI AFN value is provided so that MAC addresses can be
 abbreviated if they have the same upper 24 bits.  A MAC/24 is a
 24-bit suffix intended to be prefixed by an OUI to create a 48-bit
 MAC address [RFC7042]; in the absence of an OUI, a MAC/24 entry
 cannot be used.  A MAC/40 is a 40-bit suffix intended to be prefixed
 by an OUI to create a 64-bit MAC address [RFC7042]; in the absence of
 an OUI, a MAC/40 entry cannot be used.

Eastlake & Li Standards Track [Page 16] RFC 7961 TRILL: IA APPsub-TLV August 2016

 Typically, an OUI would be provided as a Fixed Address sub-sub-TLV
 (see Section 3.2) using the OUI AFN, but there is no prohibition
 against one or more OUIs appearing in an Address Set.
 Each Address Set, after being supplemented by any Fixed Address
 sub-sub-TLVs, is processed by combining each OUI in the Address Set
 with each MAC/24 and each MAC/40 address in the Address Set.
 Depending on how many of each of these address types are present,
 zero or more 48-bit and/or 64-bit MAC addresses may be synthesized
 that are subsequently processed as if they had been part of the
 Address Set.  If there are no MAC/24 or MAC/40 addresses present, any
 OUIs are ignored.  If there are no OUIs, any MAC/24s and/or MAC/40s
 are ignored.  If there are K1 OUIs, K2 MAC/24s, and K3 MAC/40s, K1*K2
 48-bit MACs are synthesized and K1*K3 64-bit MACs are synthesized.
 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6
 address.  IPv6/64s are ignored unless, after the processing described
 above in this subsection, there are one or more 48-bit and/or 64-bit
 MAC addresses in the Address Set to provide the lower 64 bits of the
 IPv6 address.  For this purpose, a 48-bit MAC address is expanded to
 64 bits as described in Section 2.2.1 of [RFC7042].  If there are K4
 IPv6/64s present and K5 48-bit and 64-bit MAC addresses present,
 K4*K5 128-bit IPv6 addresses are synthesized.
 Synthesized addresses are treated as if they had been members of the
 Address Set.

Eastlake & Li Standards Track [Page 17] RFC 7961 TRILL: IA APPsub-TLV August 2016

8. References

8.1. Normative References

 [ISO-10589]
            International Organization for Standardization,
            "Intermediate System to Intermediate System intra-domain
            routeing information exchange protocol for use in
            conjunction with the protocol for providing the
            connectionless-mode network service (ISO 8473)",
            ISO Standard 10589, 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, DOI 10.17487/RFC0826, November 1982,
            <http://www.rfc-editor.org/info/rfc826>.
 [RFC903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
            Reverse Address Resolution Protocol", STD 38, RFC 903,
            DOI 10.17487/RFC0903, June 1984,
            <http://www.rfc-editor.org/info/rfc903>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
            "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
            DOI 10.17487/RFC4861, September 2007,
            <http://www.rfc-editor.org/info/rfc4861>.
 [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS:
            Multi Topology (MT) Routing in Intermediate System to
            Intermediate Systems (IS-ISs)", RFC 5120,
            DOI 10.17487/RFC5120, February 2008,
            <http://www.rfc-editor.org/info/rfc5120>.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <http://www.rfc-editor.org/info/rfc5226>.
 [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
            Engineering", RFC 5305, DOI 10.17487/RFC5305,
            October 2008, <http://www.rfc-editor.org/info/rfc5305>.

Eastlake & Li Standards Track [Page 18] RFC 7961 TRILL: IA APPsub-TLV August 2016

 [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
            Ghanwani, "Routing Bridges (RBridges): Base Protocol
            Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
            <http://www.rfc-editor.org/info/rfc6325>.
 [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
            Generic Information in IS-IS", RFC 6823,
            DOI 10.17487/RFC6823, December 2012,
            <http://www.rfc-editor.org/info/rfc6823>.
 [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
            IETF Protocol and Documentation Usage for IEEE 802
            Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
            October 2013, <http://www.rfc-editor.org/info/rfc7042>.
 [RFC7172]  Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
            D. Dutt, "Transparent Interconnection of Lots of Links
            (TRILL): Fine-Grained Labeling", RFC 7172,
            DOI 10.17487/RFC7172, May 2014,
            <http://www.rfc-editor.org/info/rfc7172>.
 [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
            Scope Link State PDUs (LSPs)", RFC 7356,
            DOI 10.17487/RFC7356, September 2014,
            <http://www.rfc-editor.org/info/rfc7356>.
 [RFC7357]  Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
            Stokes, "Transparent Interconnection of Lots of Links
            (TRILL): End Station Address Distribution Information
            (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357,
            September 2014, <http://www.rfc-editor.org/info/rfc7357>.
 [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
            Ghanwani, A., and S. Gupta, "Transparent Interconnection
            of Lots of Links (TRILL): Clarifications, Corrections, and
            Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
            <http://www.rfc-editor.org/info/rfc7780>.

Eastlake & Li Standards Track [Page 19] RFC 7961 TRILL: IA APPsub-TLV August 2016

8.2. Informative References

 [ARPND]    Li, Y., Eastlake 3rd, D., Dunbar, L., and R. Perlman,
            "TRILL: ARP/ND Optimization", Work in Progress,
            draft-ietf-trill-arp-optimization-06, April 2016.
 [ChannelTunnel]
            Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge
            Channel Header Extension", Work in Progress,
            draft-ietf-trill-channel-tunnel-11, August 2016.
 [DirectoryScheme]
            Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li,
            "TRILL: Edge Directory Assist Mechanisms", Work in
            Progress, draft-ietf-trill-directory-assist-mechanisms-07,
            February 2016.
 [RFC5494]  Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
            for the Address Resolution Protocol (ARP)", RFC 5494,
            DOI 10.17487/RFC5494, April 2009,
            <http://www.rfc-editor.org/info/rfc5494>.
 [RFC7067]  Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
            Gashinsky, "Directory Assistance Problem and High-Level
            Design Proposal", RFC 7067, DOI 10.17487/RFC7067,
            November 2013, <http://www.rfc-editor.org/info/rfc7067>.
 [RFC7178]  Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
            Ward, "Transparent Interconnection of Lots of Links
            (TRILL): RBridge Channel Support", RFC 7178,
            DOI 10.17487/RFC7178, May 2014,
            <http://www.rfc-editor.org/info/rfc7178>.

Eastlake & Li Standards Track [Page 20] RFC 7961 TRILL: IA APPsub-TLV August 2016

Appendix A. Examples

 Below are example IA APPsub-TLVs.  "0x" indicates that the quantity
 is in hexadecimal.  "0b" indicates that the quantity is in binary.
 Leading zeros are retained.

A.1. Simple Example

 Below is an annotated IA APPsub-TLV carrying two simple pairs of
 EUI-48 MAC addresses and IPv4 addresses from a Push Directory
 (a directory conforming to the Push Model [RFC7067]).  No
 sub-sub-TLVs are included.
       0x0002(10)   Type: Interface Addresses
       0x001B        Length: 27 (= 0x1B)
       0x001B        Address Sets End: 27 (= 0x1B)
       0x1234        RBridge Nickname from which reachable
       0b10000000    Flags: Push Directory data
       0xE3          Confidence = 227
       33            Template: 33 (0x21) = 32 + 1(IPv4)
             Address Set One
       0x00005E0053A9   48-bit MAC address
       198.51.100.23    IPv4 address
             Address Set Two
       0x00005E00536B   48-bit MAC address
       203.0.113.201    IPv4 address
 The size includes 7 for the fixed fields through and including the
 1-byte Template, plus 2 times the Address Set size.  Each Address Set
 is 10 bytes: 6 for the 48-bit MAC address plus 4 for the IPv4
 address.  Therefore, the total size is 7 + 2*10 = 27.
 See Section 2 for more information on the Template.

Eastlake & Li Standards Track [Page 21] RFC 7961 TRILL: IA APPsub-TLV August 2016

A.2. Complex Example

 Below is an annotated IA APPsub-TLV carrying three sets of addresses,
 each consisting of an EUI-48 MAC address, an IPv4 address, an IPv6
 address, and an RBridge Port ID, all from a Push Directory
 (a directory conforming to the Push Model [RFC7067]).  The IPv6
 address for each Address Set is synthesized from the MAC address
 given in that set and the IPv6/64 64-bit prefix provided through a
 Fixed Address sub-sub-TLV.  In addition, a sub-sub-TLV is included
 that provides an FGL that overrides whatever Data Label may be
 provided by the envelope (for example, an ESADI-LSP [RFC7357]) within
 which this IA APPsub-TLV occurs.
     0x0002(10)    Type: Interface Addresses
     0x0036        Length: 64 (= 0x40)
     0x0021        Address Sets End: 43 (= 0x2B)
     0x4321        RBridge Nickname from which reachable
     0b10000000    Flags: Push Directory data
     0xD3          Confidence = 211
     37            Template: 37(0x25) = 32 + 1(IPv4) + 4(Port)
           Address Set One
     0x00005E0053DE   48-bit MAC address
     198.51.100.105   IPv4 address
     0x1DE3           RBridge Port ID
           Address Set Two
     0x00005E0053E3   48-bit MAC address
     203.0.113.89     IPv4 address
     0x1DEE           RBridge Port ID
           Address Set Three
     0x00005E0053D3   48-bit MAC address
     192.0.2.139      IPv4 address
     0x01DE           RBridge Port ID
           sub-sub-TLV One
     0x0003           Type: Data Label
     0x0003           Length: Implies FGL
     0xD3E3E3         Fine-Grained Label
           sub-sub-TLV Two
     0x0002           Type: Fixed Address
     0x000A           Size: 0x0A = 10
     0x400A           AFN: IPv6/64
     0x20010db800000000   IPv6 Prefix: 2001:db8::
 See Section 2 for more information on the Template.

Eastlake & Li Standards Track [Page 22] RFC 7961 TRILL: IA APPsub-TLV August 2016

 The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be
 treated as if it occurred as a fourth entry inside each of the three
 Address Sets.  When there is an IPv6/64 entry and a 48-bit MAC entry,
 the MAC value is expanded by inserting 0xfffe immediately after the
 OUI, and the local/global bit is inverted.  The resulting
 Modified EUI-64-bit value is used as the lower 64 bits of the
 resulting IPv6 address (Section 2.2.1 of [RFC7042]).  As a result, a
 receiving TRILL switch would treat the three Address Sets shown as if
 they had an IPv6 address in them, as follows:
             Address Set One
       0x20010db80000000002005efffe0053de  IPv6 Address
             Address Set Two
       0x20010db80000000002005efffe0053e3  IPv6 Address
             Address Set Three
       0x20010db80000000002005efffe0053d3  IPv6 Address
 As an alternative to the compact "well-known value" Template encoding
 used in the example above, the less compact explicit AFN encoding
 could have been used.  In that case, the IA APPsub-TLV would have
 started as follows:
       0x0002(10)    Type: Interface Addresses
       0x003C        Length: 60 (= 0x3C)
       0x0027        Address Sets End: 39 (= 0x27)
       0x4321        RBridge Nickname from which reachable
       0b10000000    Flags: Push Directory data
       0xD3          Confidence = 211
       0x3           Template: 3 AFNs
       0x4005        AFN: 48-bit MAC
       0x0001        AFN: IPv4
       0x400B        AFN: RBridge Port ID
 As a final point, since the 48-bit MAC addresses in these three
 Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would
 have been possible to just have a MAC/24 value giving the lower
 24 bits of the MAC in each Address Set.  The OUI would then be
 supplied by a second Fixed Address sub-sub-TLV providing the OUI.
 With N Address Sets, this would have saved 3*N or 9 bytes, at a cost
 of 9 bytes (2 each for the Type and Length of the sub-sub-TLV, 2 for
 the OUI AFN, and 3 for the OUI).  So, with just three Address Sets,
 there would be no net savings; however, with a larger number of
 Address Sets, there would be a net savings.

Eastlake & Li Standards Track [Page 23] RFC 7961 TRILL: IA APPsub-TLV August 2016

Acknowledgments

 The authors gratefully acknowledge the contributions and review by
 the following:
    Linda Dunbar, Sue Hares, Paul Kyzivat, Danny McPherson, and
    Gayle Noble

Authors' Addresses

 Donald Eastlake 3rd
 Huawei Technologies
 155 Beaver Street
 Milford, MA  01757
 United States of America
 Phone: +1-508-333-2270
 Email: d3e3e3@gmail.com
 Yizhou Li
 Huawei Technologies
 101 Software Avenue
 Nanjing  210012
 China
 Phone: +86-25-56622310
 Email: liyizhou@huawei.com

Eastlake & Li Standards Track [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7961.txt · Last modified: 2016/08/24 20:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki