Internet DRAFT - draft-mrw-trill-over-ip
draft-mrw-trill-over-ip
Network Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Standards Track D. Eastlake
Expires: August 2, 2014 D. Zhang
Huawei Technologies
January 31, 2014
Transparent Interconnection of Lots of Links (TRILL) over IP
draft-mrw-trill-over-ip-04.txt
Abstract
The Transparent Interconnection of Lots of Links (TRILL) protocol is
implemented by devices called TRILL Switches or RBridges (Routing
Bridges). TRILL supports both point-to-point and multi-access links
and is designed so that a variety of link protocols can be used
between TRILL switch ports. This document standardizes methods for
encapsulating TRILL in IP(v4 or v6) to provide a unified TRILL
campus.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2014.
Copyright Notice
Copyright (c) 2014 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
Wasserman, et al. Expires August 2, 2014 [Page 1]
Internet-Draft TRILL over IP January 2014
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. Requirements Terminology . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases for TRILL over IP . . . . . . . . . . . . . . . . . 3
3.1. Remote Office Scenario . . . . . . . . . . . . . . . . . 3
3.2. IP Backbone Scenario . . . . . . . . . . . . . . . . . . 4
3.3. Important Properties of the Scenarios . . . . . . . . . . 4
3.3.1. Security Requirements . . . . . . . . . . . . . . . . 4
3.3.2. Multicast Handling . . . . . . . . . . . . . . . . . 5
3.3.3. RBridge Neighbor Discovery . . . . . . . . . . . . . 5
4. TRILL Packet Formats . . . . . . . . . . . . . . . . . . . . 5
4.1. TRILL Data Packet . . . . . . . . . . . . . . . . . . . . 5
4.2. TRILL IS-IS Packet . . . . . . . . . . . . . . . . . . . 6
5. Link Protocol Specifics . . . . . . . . . . . . . . . . . . . 6
6. Port Configuration . . . . . . . . . . . . . . . . . . . . . 7
7. TRILL over UDP/IP Format . . . . . . . . . . . . . . . . . . 7
8. Handling Multicast . . . . . . . . . . . . . . . . . . . . . 8
9. Use of DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Transport Considerations . . . . . . . . . . . . . . . . . . 9
10.1. Recursive Ingress . . . . . . . . . . . . . . . . . . . 9
10.2. Fat Flows . . . . . . . . . . . . . . . . . . . . . . . 10
10.3. Congestion Considerations . . . . . . . . . . . . . . . 10
11. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Middlebox Considerations . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . . 11
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
16.1. Normative References . . . . . . . . . . . . . . . . . . 13
16.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Wasserman, et al. Expires August 2, 2014 [Page 2]
Internet-Draft TRILL over IP January 2014
2. Introduction
TRILL switches (RBridges) are devices that implement the IETF TRILL
protocol [RFC6325] [I-D.eastlake-isis-rfc6326bis]
[I-D.ietf-trill-rfc6327bis].
RBridges provide transparent forwarding of frames within an arbitrary
network topology, using least cost paths for unicast traffic. They
support not only VLANs and Fine Grained Labels
[I-D.ietf-trill-fine-labeling] but also multipathing of unicast and
multi-destination traffic. They use IS-IS link state routing and
encapsulation with a hop count. They are compatible with IEEE 802.1
customer bridges, and can incrementally replace them.
Ports on different RBridges can communicate with each other over
various link types, such as Ethernet [RFC6325] or PPP [RFC6361].
This document defines a method for RBridges to communicate over UDP/
IP(v4 or v6). TRILL over IP will allow remote, Internet-connected
RBridges to form a single RBridge campus, or multiple TRILL over IP
networks within a campus to be connected as a single TRILL campus via
a TRILL over IP backbone.
TRILL over IP connects RBridge ports using IPv4 or IPv6 as a
transport in such a way that the ports appear to TRILL to be
connected by a single multi-access link. Therefore, if more than two
RBridge ports are connected via a single TRILL over IP link, any pair
of them can communicate.
To support the scenarios where RBridges are connected via links (such
as the public Internet) that are not under the same administrative
control as the TRILL campus, this document specifies the use of
Datagram Transport Layer Security (DTLS) [RFC6347] to secure the
communications between RBridges running TRILL over IP.
3. Use Cases for TRILL over IP
This section introduces two application scenarios (a remote office
scenario and an IP backbone scenario) which cover the most typical of
situations where network administrators may choose to use TRILL over
an IP network.
3.1. Remote Office Scenario
In the Remote Office Scenario, a remote TRILL network is connected to
a TRILL campus across a multihop IP network, such as the public
Internet. The TRILL network in the remote office becomes a logical
part of TRILL campus, and nodes in the remote office can be attached
Wasserman, et al. Expires August 2, 2014 [Page 3]
Internet-Draft TRILL over IP January 2014
to the same VLANs or Fine Grained
Labels[I-D.ietf-trill-fine-labeling] as local campus nodes. In many
cases, a remote office may be attached to the TRILL campus by a
single pair of RBridges, one on the campus end, and the other in the
remote office. In this use case, the TRILL over IP link will often
cross logical and physical IP networks that do not support TRILL, and
are not under the same administrative control as the TRILL campus.
3.2. IP Backbone Scenario
In the IP Backbone Scenario, TRILL over IP is used to connect a
number of TRILL networks to form a single TRILL campus. For example,
a TRILL over IP backbone could be used to connect multiple TRILL
networks on different floors of a large building, or to connect TRILL
networks in separate buildings of a multi-building site. In this use
case, there may often be several TRILL switches on a single TRILL
over IP link, and the IP link(s) used by TRILL over IP are typically
under the same administrative control as the rest of the TRILL
campus.
3.3. Important Properties of the Scenarios
There are a number of differences between the above two application
scenarios, some of which drive features of this specification. These
differences are especially pertinent to the security requirements of
the solution, how multicast data frames are handled, and how the
TRILL switch ports discover each other.
3.3.1. Security Requirements
In the IP Backbone Scenario, TRILL over IP is used between a number
of RBridge ports, on a network link that is in the same
administrative control as the remainder of the TRILL campus. While
it is desirable in this scenario to prevent the association of rogue
RBridges, this can be accomplished using existing IS-IS security
mechanisms. There may be no need to protect the data traffic, beyond
any protections that are already in place on the local network.
In the Remote Office Scenario, TRILL over IP may run over a network
that is not under the same administrative control as the TRILL
network. Nodes on the network may think that they are sending
traffic locally, while that traffic is actually being sent, in a UDP/
IP tunnel, over the public Internet. It is necessary in this
scenario to protect the integrity and confidentiality of user
traffic, as well as ensuring that no unauthorized RBridges can gain
access to the RBridge campus. The issues of protecting integrity and
confidentiality of user traffic are addressed by using DTLS for both
IS-IS frames and data frames between RBridges in this scenario.
Wasserman, et al. Expires August 2, 2014 [Page 4]
Internet-Draft TRILL over IP January 2014
3.3.2. Multicast Handling
In the IP Backbone scenario, native multicast may be supported on the
TRILL over IP link. If so, it can be used to send TRILL IS-IS and
multicast data packets, as discussed later in this document.
Alternatively, multi-destination packets can be transmitted serially.
In the Remote Office Scenario there will often be only one pair of
RBridges connecting a given site and, even when multiple RBridges are
used to connect a Remote Office to the TRILL campus, the intervening
network may not provide reliable (or any) multicast connectivity.
The issues such as complex key management also makes it difficult to
provide strong data integrity and confidentiality protections for
multicast traffic. For all of these reasons, the connections between
local and remote RBridges will be treated like point-to-point links,
and all TRILL IS-IS control messages and multicast data packets that
are transmitted between the Remote Office and the TRILL campus will
be serially transmitted, as discussed later in this document.
3.3.3. RBridge Neighbor Discovery
In the IP Backbone Scenario, RBridges that use TRILL over IP will use
the normal TRILL IS-IS Hello mechanisms to discover the existence of
other RBridges on the link [I-D.ietf-trill-rfc6327bis], and to
establish authenticated communication with those RBridges.
In the Remote Office Scenario, a DTLS session will need to be
established between RBridges before TRILL IS-IS traffic can be
exchanged, as discussed below. In this case, one of the RBridges
will need to be configured to establish a DTLS session with the other
RBridge. This will typically be accomplished by configuring the
RBridge at a Remote Office to initiate a DTLS session, and subsequent
TRILL exchanges, with a TRILL over IP-enabled RBridge attached to the
TRILL campus.
4. TRILL Packet Formats
To support the TRILL base protocol standard [RFC6325]. , two types of
packets will be transmitted between RBridges: TRILL Data frames and
TRILL IS-IS packets.
4.1. TRILL Data Packet
The on-the-wire form of a TRILL Data packet in transit between two
neighboring RBridges is as shown below:
Wasserman, et al. Expires August 2, 2014 [Page 5]
Internet-Draft TRILL over IP January 2014
+--------------+----------+----------------+-----------+
| TRILL Data | TRILL | Native Frame | Link |
| Link Header | Header | Payload | Trailer |
+--------------+----------+----------------+-----------+
Where the Encapsulated Native Frame is similar to Ethernet frame
format with a VLAN tag or Fine Grained Label
[I-D.ietf-trill-fine-labeling] but with no trailing Frame Check
Sequence (FCS).
4.2. TRILL IS-IS Packet
TRILL IS-IS packets are formatted on-the-wire as follows:
+--------------+---------------+-----------+
| TRILL IS-IS | TRILL IS-IS | Link |
| Link Header | Payload | Trailer |
+--------------+---------------+-----------+
The Link Header and Link Trailer in these formats depend on the
specific link technology. The Link Header usually contains one or
more fields that distinguish TRILL Data from TRILL IS-IS. For
example, over Ethernet, the TRILL Data Link Header ends with the
TRILL Ethertype while the TRILL IS-IS Link Header ends with the L2
-IS-IS Ethertype; on the other hand, over PPP, there are no
Ethertypes but PPP protocol code points are included that distinguish
TRILL Data from TRILL IS-IS.
In TRILL over IP, we will use UDP/IP (v4 or v6) as the link header,
and the TRILL packet type will be determined based on the UDP
destination port number. In TRILL over IP, no Link Trailer is
specified, although one may be added when the resulting IP packets
are encapsulated for transmission on a network (e.g. Ethernet).
5. Link Protocol Specifics
TRILL Data packets can be unicast to a specific RBridge or multicast
to all RBridges on the link. TRILL IS-IS packets are always
multicast to all other RBridge on the link (except for MTU PDUs,
which may be unicast). On Ethernet links, the Ethernet multicast
address All-RBridges is used for TRILL Data and All-IS-IS-RBridges
for TRILL IS-IS.
Wasserman, et al. Expires August 2, 2014 [Page 6]
Internet-Draft TRILL over IP January 2014
To properly handle TRILL base protocol packets on a TRILL over IP
link, either native multicast mode must be enabled on that link, or
multicast must be simulated using serial unicast, as discussed below.
In TRILL Hello PDUs used on TRILL IP links, the IP addresses of the
connected IP ports are their real SNPA (SubNetwork Point of
Attachment) addresses and, for IPv6, the 16-byte IPv6 address is
used; however, for easy of code re-use designed for common 48-bit
SNPAs, for TRILL over IPv4, a 48-bit synthetic SNPA that looks like a
unicast MAC address is constructed for use in the SNPA field of TRILL
Neighbor TLVs
[I-D.eastlake-isis-rfc6326bis][I-D.ietf-trill-rfc6327bis] on the
link. This synthetic SNPA is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFE | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This synthetic SNPA/MAC address has the local (0x02) bit on in the
first byte and so cannot conflict with any globally unique 48-bit
Ethernet MAC. However, at the IP level, where TRILL operates on an
IP link, there are only IP stations, not MAC stations, so conflict on
the link with a real MAC address would be impossible in any case.
6. Port Configuration
Each RBridge physical port used for a TRILL over IP link MUST have at
least one IP (v4 or v6) address. Implementations MAY allow a single
physical port to operate as multiple IPv4 and/or IPv6 logical ports.
Each IP address constitutes a different logical port and the RBridge
with those ports MUST associate a different Port ID with each logical
port.
TBD: MUST be able to configure a list of IP addresses for serial
unicast. MUST be able to configure a non-standard IP multi-cast
address if native multicast is being used.
7. TRILL over UDP/IP Format
The general format of a TRILL over UDP/IP packet is shown below.
Wasserman, et al. Expires August 2, 2014 [Page 7]
Internet-Draft TRILL over IP January 2014
+----------+--------+-----------------------+
| IP | UDP | TRILL |
| Header | Header | Payload |
+----------+--------+-----------------------+
Where the UDP Header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Payload ...
Source Port - see Section 10.2
Destination Port - indicates TRILL Data or IS-IS, see Section 14
UDP Length - as specified in [RFC768]
UDP Checksum - as specified in [RFC768]
The TRILL Payload starts with the TRILL Header (not including the
TRILL Ethertype) for TRILL Data packets and starts with the 0x83
Intradomain Routeing Protocol Discriminator byte (thus not including
the L2-IS-IS Ethertype) for TRILL IS-IS packets.
8. Handling Multicast
By default, both TRILL IS-IS packets and multi-destination TRILL Data
packets are sent to an All-RBridges IPv4 or IPv6 multicast Address as
appropriate (see Section 14); however, a TRILL over IP port may be
configured to use serial unicast with a list of unicast addresses of
other stations to which multi-destination packets are sent.
TBD
9. Use of DTLS
All RBridges that support TRILL over IP MUST implement DTLS and
support the use of DTLS to secure both TRILL IS-IS and TRILL data
packets. When DTLS is used to secure a TRILL over IP link, the DTLS
session MUST be fully established before any TRILL IS-IS or data
frames are exchanged.
Wasserman, et al. Expires August 2, 2014 [Page 8]
Internet-Draft TRILL over IP January 2014
RBridges that implement TRILL over IP SHOULD support the use of
certificates for DTLS and, if they support certificates, MUST support
the following algorithm:
o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
RBridges that support TRILL over IP MUST support the use of pre-
shared keys for DTLS. If the communicating RBridges have IS-IS Hello
authentication enabled with a pre-shared key, then, by default a key
derived from that TRILL Hello pre-shared key is used for DTLS unless
some other pre-shared key is configured. The following cryptographic
algorithms MUST be supported for use with pre-shared keys:
o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246]
If the derived default preshared key is used, it is derived as
follows:
HMAC-SHA256 ("TRILL IP", IS-IS-shared key )
In the above "|" indicates concatenation, HMAC-SHA256 is as described
in [FIPS180] [RFC6234] and "TRILL IP" is the eight byte US ASCII
[ASCII] string indicated.
10. Transport Considerations
10.1. Recursive Ingress
TRILL is designed to transport end station traffic to and from IEEE
802.1Q conformant end stations and IP is frequently transported over
IEEE 802.3 or similar protocols supporting 802.1Q conformant end
stations. Thus, an end station data frame EF might get TRILL
ingressed to TRILL(EF) which was then sent on a TRILL over IP over an
802.3 link resulting in an 802.3 frame of the form
802.3(IP(TRILL(EF))). There is a risk of such a packet being re-
ingressed by the same TRILL campus, due to physical or logical
misconfiguration, looping round, being further re-ingressed, etc.
The packet might get discarded if it got too large but if
fragmentation is enabled, it would just keep getting split into
fragments that would continue to loop and grow and re-fragment until
the path was saturated with junk and packets were being discarded due
to queue overflow. The TRILL Header TTL would provide no protection
because each TRILL ingress adds a new Header and TTL.
To protect against this scenario, TRILL over IP output ports MUST be
able to test whether a TRILL packet they are above to send is, in
fact a TRILL ingress of a TRILL over IP over 802.3 or the like
packets. That is, is it of the form TRILL(802.3(IP(TRILL(...)))? If
Wasserman, et al. Expires August 2, 2014 [Page 9]
Internet-Draft TRILL over IP January 2014
so, the default action of the TRILL over IP output port is to discard
the packet. However, there are cases where some level of nested
ingress is desired so it MUST be possible to configure the port to
allow such packets.
10.2. Fat Flows
For the purpose of load balancing, it could be worthwhile to consider
how to transport the TRILL packets over the Equal Cost Multiple Paths
(ECMPs) existing in the IP path.
The ECMP election for the IP traffics could be based, at least for
IPv4, on the quintuple of the outer IP header { Source IP,
Destination IP, Source Port, Destination Port, and IP protocol }.
Such tuples, however, can be exactly the same for all TRILL Data
packets between two RBridge ports, even if there is a huge amount of
data being sent. Therefore, in order to support ECMP, a RBridge
SHOULD set the Source Port as an entropy field for ECMP decisions.
This idea is also introduced in [I-D.yong-tsvwg-gre-in-udp-encap].
10.3. Congestion Considerations
TRILL can carry many different protocols as a payload. When a TRILL
over IP flow carries primarily IP-based traffic, the aggregate
traffic is assumed to be TCP friendly due to the congestion control
mechanisms used by the payload traffic. Packet loss will trigger the
necessary reduction in offered load, and no additional congestion
avoidance action is necessary. When a TRILL over IP flow carries
payload traffic that is not known to be TCP friendly and the flow
runs across a path that could potentially become congested,
additional mechanisms MUST be employed to ensure that the offered
load on the TRILL link over IP is reduced appropriately during
periods of congestion. This is not necessary in the case of a TRILL
link over IP through an over- provisioned network, where the
potential for congestion is avoided through the over-provisioning of
the network.
11. MTU Considerations
In TRILL each RBridge advertises the largest LSP frame it can accept
(but not less than 1,470 bytes) on any of its interfaces (at least
those interfaces with adjacencies to other RBridges in the campus) in
its LSP number zero through the originatingLSPBufferSize TLV
[RFC6325] [I-D.eastlake-isis-rfc6326bis]. The campus minimum MTU,
denoted Sz, is then established by taking the minimum of this
advertised MTU for all RBridges in the campus. Links that do not
meet the Sz MTU are not included in the routing topology. This
Wasserman, et al. Expires August 2, 2014 [Page 10]
Internet-Draft TRILL over IP January 2014
protects the operation of IS-IS from links that would be unable to
accommodate some LSPs.
A method of determining originatingLSPBufferSize for an RBridge with
one or more TRILL over IP portsis described in
[I-D.ietf-trill-clear-correct]. However, if an IP link either can
accommodate jumbo frames or is a link on which IP fragmentation is
enabled and acceptable, then it is unlikely that the IP link will be
a constraint on the RBridge's originatingLSPBufferSize. On the other
hand, if the IP link can only handle smaller frames and fragmentation
is to be avoided when possible, a TRILL over IP port might constrain
the RBridge's originatingLSPBufferSize. Because TRILL sets the
minimum values of Sz at 1,470 bytes, there may be links that meet the
minimum MTU for the IP protocol (1,280 bytes for IPv6, theoretically
68 bytes for IPv4) on which it would be necessary to enable
fragmentation for TRILL use.
The optional use of TRILL IS-IS MTU PDUs, as specified in [RFC6325]
and [I-D.ietf-trill-rfc6327bis] can provide added assurance of the
actual MTU of a link.
12. Middlebox Considerations
TBD
13. Security Considerations
TRILL over IP is subject to all of the security considerations for
the base TRILL protocol [RFC6325]. In addition, there are specific
security requirements for different TRILL deployment scenarios, as
discussed in the "Use Cases for TRILL over IP" section above.
This document specifies that all RBridges that support TRILL over IP
MUST implement DTLS, and makes it clear that it is both wise and good
to use DTLS in all cases where a TRILL over IP link will traverse a
network that is not under the same administrative control as the rest
of the TRILL campus. DTLS is necessary, in these cases to protect
the privacy and integrity of data traffic.
TRILL over IP is completely compatible with the use of IS-IS
security, which can be used to authenticate RBridges before allowing
them to join a TRILL campus. This is sufficient to protect against
rogue RBridges, but is not sufficient to protect data packets that
may be sent, in UDP/IP tunnels, outside of the local network, or even
across the public Internet. To protect the privacy and integrity of
that traffic, use DTLS.
Wasserman, et al. Expires August 2, 2014 [Page 11]
Internet-Draft TRILL over IP January 2014
In cases were DTLS is used, the use of IS-IS security may not be
necessary, but there is nothing about this specification that would
prevent using both DTLS and IS-IS security together. In cases where
both types of security are enabled, by default, a key derived from
the IS-IS key will be used for DTLS.
14. IANA Considerations
IANA has allocated the following destination UDP Ports for the TRILL
IS-IS and Data channels:
UDP Port Protocol
(TBD) TRILL IS-IS Channel
(TBD) TRILL Data Channel
IANA has allocated one IPv4 and one IPv6 multicast address, as shown
below, which correspond to the All-RBridges and All-IS-IS-RBridges
multicast MAC addresses that the IEEE Registration Authority has
assigned for TRILL. Because the low level hardware MAC address
dispatch considerations for TRILL over Ethernet do not apply to TRILL
over IP, one IP multicast address for each version of IP is
sufficient.
[Values recommended to IANA:]
Name IPv4 IPv6
All-RBridges 233.252.14.0 FF0X:0:0:0:0:0:0:205
Note: when these IPv4 and IPv6 multicast addresses are used and the
resulting IP frame is sent over Ethernet, the usual IP derived MAC
address is used.
[Need to discuss scopes for IPv6 multicast (the "X" in the addresses)
somewhere. Default to "site" scope but MUST be configurable?]
15. Acknowledgements
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
The following people have provided useful feedback on the contents of
this document: Sam Hartman, Adrian Farrel.
Wasserman, et al. Expires August 2, 2014 [Page 12]
Internet-Draft TRILL over IP January 2014
Some material has been derived from draft-ietf-mpls-in-udp by Xiaohu
Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and Yongbing Fan.
16. References
16.1. Normative References
[ASCII] "American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, ANSI X3.4-1968
has been replaced by newer versions with slight
modifications, but the 1968 version remains definitive for
the Internet.", 1968.
[FIPS180] ""Secure Hash Standard (SHS)", United States of American,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 180-4", March 2012.
[I-D.eastlake-isis-rfc6326bis]
Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", draft-eastlake-isis-
rfc6326bis-09 (work in progress), August 2012.
[I-D.ietf-trill-clear-correct]
Eastlake, D., Zhang, M., Ghanwani, A., Manral, V., and A.
Banerjee, "TRILL: Clarifications, Corrections, and
Updates", draft-ietf-trill-clear-correct-06 (work in
progress), July 2012.
[I-D.ietf-trill-rfc6327bis]
Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V.
Manral, "TRILL: Adjacency", draft-ietf-trill-rfc6327bis-03
(work in progress), January 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
Wasserman, et al. Expires August 2, 2014 [Page 13]
Internet-Draft TRILL over IP January 2014
16.2. Informative References
[I-D.ietf-trill-fine-labeling]
Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D.
Dutt, "TRILL (Transparent Interconnection of Lots of
Links): Fine-Grained Labeling", draft-ietf-trill-fine-
labeling-07 (work in progress), May 2013.
[I-D.yong-tsvwg-gre-in-udp-encap]
Crabbe, E., Yong, L., and K. Building, "Generic UDP
Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in-
udp-encap-02 (work in progress), October 2013.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6361] Carlson, J. and D. Eastlake, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, August 2011.
Authors' Addresses
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405-7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
Phone: +1 508 333-2270
Email: d3e3e3@gmail.com
Wasserman, et al. Expires August 2, 2014 [Page 14]
Internet-Draft TRILL over IP January 2014
Dacheng Zhang
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Rd.
Beijing, Hai-Dian District 100095
P.R. China
Email: zhangdacheng@huawei.com
Wasserman, et al. Expires August 2, 2014 [Page 15]
