< draft-ietf-pppext-trill-protocol-07.txt   draft-ietf-pppext-trill-protocol-08.txt >
Network Working Group James Carlson Network Working Group James Carlson
INTERNET-DRAFT WorkingCode INTERNET-DRAFT WorkingCode
Intended status: Proposed Standard June 3, 2011 Intended status: Proposed Standard Donald Eastlake
Expires: December 3, 2011 Huawei
Expires: December 12, 2011 June 13, 2011
PPP TRILL Protocol Control Protocol PPP TRILL Protocol Control Protocol
<draft-ietf-pppext-trill-protocol-07.txt> <draft-ietf-pppext-trill-protocol-08.txt>
Copyright Notice Abstract
Copyright (c) 2011 IETF Trust and the persons identified as the The Point-to-Point Protocol (PPP) defines a Link Control Protocol
document authors. All rights reserved. (LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links. This document describes PPP support for
the Transparent Interconnection of Lots of Links (TRILL) Protocol,
allowing direct communication between Routing Bridges (RBridges) via
PPP links.
This document is subject to BCP 78 and the IETF Trust's Legal Status of This Memo
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.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working provisions of BCP 78 and BCP 79.
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute Distribution of this document is unlimited. Comments should be sent
working documents as Internet-Drafts. to the DNSEXT working group mailing list: <rbridge@postel.org>.
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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments are solicited and should be sent to the PPP Extensions INTERNET-DRAFT TRILL over PPP
<pppext@ietf.org> or TRILL working group <rbridge@postel.org> mailing
list and/or the author.
This Internet-Draft will expire on December 3, 2011. Table of Contents
Abstract 1. Introduction............................................3
The Point-to-Point Protocol (PPP) defines a Link Control Protocol 2. PPP TRILL Negotiation...................................4
(LCP) and a method for negotiating the use of multi-protocol traffic 2.1 TNCP Packet Format.....................................4
over point-to-point links. This document describes PPP support for 2.2 TNP Packet Format......................................5
Transparent Interconnection of Lots of Links (TRILL) Protocol, 2.3 TLSP Packet Format.....................................6
allowing direct communication between Routing Bridges (RBridges) via
PPP links.
1. Introduction 3. TRILL PPP Behavior......................................7
4. Security Considerations.................................8
5. IANA Considerations.....................................8
The TRILL Protocol [1] defines a set of mechanisms used to 6. References..............................................9
6.1 Normative..............................................9
6.2 Informative............................................9
7. Acknowledgments........................................10
8. Authors' Addresses.....................................10
INTERNET-DRAFT TRILL over PPP
1. Introduction
The TRILL Protocol [RFCtrill] defines a set of mechanisms used to
communicate between RBridges. These devices can bridge together communicate between RBridges. These devices can bridge together
large 802 networks using link-state protocols in place of the large 802 networks using link-state protocols in place of the
traditional spanning tree mechanisms. traditional spanning tree mechanisms.
Over Ethernet, TRILL uses two separate Ethertypes to distinguish Over Ethernet, TRILL uses two separate Ethertypes to distinguish
between encapsulation headers, which carry user data, and link-state between encapsulation headers, which carry user data, and link-state
messages, which compute network topology using a protocol based on messages, which compute network topology using a protocol based on
ISO IS-IS. These two protocols must be distinguished from one [IS-IS]. These two protocols must be distinguished from one another,
another, and segregated from all other traffic. and segregated from all other traffic.
In a network where PPP [2] is used to interconnect routers (often In a network where PPP [RFC1661] is used to interconnect routers
over telecommunications links), it may be advantageous to be able to (often over telecommunications links), it may be advantageous to be
bridge between Ethernet segments over those PPP links, and thus able to bridge between Ethernet segments over those PPP links, and
integrate remote networks with an existing TRILL cloud. The existing thus integrate remote networks with an existing TRILL cloud. The
Bridging Control Protocol (BCP) [5] allows direct bridging of existing Bridging Control Protocol (BCP) [RFC3518] allows direct
Ethernet frames over PPP. However, this mechanism is inefficient and bridging of Ethernet frames over PPP. However, this mechanism is
inadequate for TRILL, which can be optimized for use over PPP links. inefficient and inadequate for TRILL, which can be optimized for use
over PPP links.
To interconnect these devices over PPP links, three protocol numbers To interconnect these devices over PPP links, three protocol numbers
are needed, and are reserved as follows: are needed, and are reserved as follows:
Value (in hex) Protocol Name Value (in hex) Protocol Name
TBD-00XX TRILL Network Protocol (TNP) -------------- -------------------------------------
TBD-40XX TRILL Link State Protocol (TLSP) TBD-00XX TRILL Network Protocol (TNP)
TBD-80XX TRILL Network Control Protocol (TNCP) TBD-40YY TRILL Link State Protocol (TLSP)
TBD-80ZZ TRILL Network Control Protocol (TNCP)
The usage of these three protocols is described in detail in the The usage of these three protocols is described in detail in the
following section. following section.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in [RFC2119].
2. PPP TRILL Negotiation INTERNET-DRAFT TRILL over PPP
2. PPP TRILL Negotiation
The TRILL Network Control Protocol (TNCP) is responsible for The TRILL Network Control Protocol (TNCP) is responsible for
negotiating the use of the TRILL Network Protocol (TNP) and TRILL negotiating the use of the TRILL Network Protocol (TNP) and TRILL
Link State Protocol (TLSP) on a PPP link. TNCP uses the same option Link State Protocol (TLSP) on a PPP link. TNCP uses the same option
negotiation mechanism and state machine as described for LCP (section negotiation mechanism and state machine as described for LCP (section
4 of [2]). 4 of [RFC1661]).
TNCP packets MUST NOT be exchanged until PPP has reached the TNCP packets MUST NOT be exchanged until PPP has reached the Network-
Network-Layer Protocol phase. Any TNCP packets received when not in Layer Protocol phase. Any TNCP packets received when not in that
that phase MUST be silently ignored. phase MUST be silently ignored.
The encapsulated network layer data, carried in TNP packets, and The encapsulated network layer data, carried in TNP packets, and
topology information, carried in TLSP packets, MUST NOT be sent topology information, carried in TLSP packets, MUST NOT be sent
unless TNCP is in Opened state. If a TNP or TLSP packet is received unless TNCP is in Opened state. If a TNP or TLSP packet is received
when TNCP is not in Opened state and LCP is Opened, an implementation when TNCP is not in Opened state and LCP is Opened, an implementation
MUST silently discard the unexpected TNP or TLSP packet. MUST silently discard the unexpected TNP or TLSP packet.
2.1. TNCP Packet Format 2.1 TNCP Packet Format
Exactly one TNCP packet is carried in the PPP Information field, with Exactly one TNCP packet is carried in the PPP Information field, with
the PPP Protocol field set to hex TBD-80XX (TNCP). A summary of the the PPP Protocol field set to hex TBD-80ZZ (TNCP). A summary of the
TNCP packet format is shown below. The fields are transmitted from TNCP packet format is shown below. The fields are transmitted from
left to right. left to right.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Data ...
+-+-+-+-+ +-+-+-+-+
skipping to change at page 4, line 5 skipping to change at page 5, line 5
result in a TNCP Code-Reject reply. result in a TNCP Code-Reject reply.
Identifier and Length Identifier and Length
These are as documented for LCP. These are as documented for LCP.
Data Data
This field contains data formatted as described in section 5 of This field contains data formatted as described in section 5 of
[2]. Codes 1-4 use Type-Length-Data sequences, Codes 5 and 6 use INTERNET-DRAFT TRILL over PPP
uninterpreted data, and Code 7 uses a Rejected-Packet, all as
described in [2]. [RFC1661]. Codes 1-4 use Type-Length-Data sequences, Codes 5 and
6 use uninterpreted data, and Code 7 uses a Rejected-Packet, all
as described in [RFC1661].
Because no Configuration Options have been defined for TNCP, Because no Configuration Options have been defined for TNCP,
negotiating the use of TRILL Protocol with IS-IS for the link state negotiating the use of TRILL Protocol with IS-IS for the link state
protocol is the default when no options are specified. A future protocol is the default when no options are specified. A future
document may specify the use of Configuration Options to enable document may specify the use of Configuration Options to enable
different TRILL operating modes, such as the use of a different link different TRILL operating modes, such as the use of a different link
state protocol. state protocol.
2.2. TNP Packet Format 2.2 TNP Packet Format
When TNCP is in Opened state, TNP packets are sent by setting the PPP When TNCP is in Opened state, TNP packets are sent by setting the PPP
Protocol field to hex TBD-00XX (TNP) and placing TRILL-encapsulated Protocol field to hex TBD-00XX (TNP) and placing TRILL-encapsulated
data representing exactly one encapsulated packet in the PPP data representing exactly one encapsulated packet in the PPP
Information field. Information field.
A summary of this format is provided below: A summary of this format is provided below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname | | V | R |M|Op-Length| Hop Count | Egress (RB2) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress (RB1) Nickname | Inner Destination MAC ... | Ingress (RB1) Nickname | Inner Destination MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
This is identical to the TRILL Ethernet format (section 4.1 of [1], This is identical to the TRILL Ethernet format (section 4.1 of
"Ethernet Data Encapsulation,") except that the Outer MAC header and [RFCtrill], "Ethernet Data Encapsulation,") except that the Outer MAC
Ethertype are replaced by the PPP headers and Protocol Field, and the header and Ethertype are replaced by the PPP headers and Protocol
Ethernet FCS is not present. Both user data and ESADI packets are Field, and the Ethernet FCS is not present. Both user data and ESADI
encoded in this format. packets are encoded in this format.
The PPP FCS follows the encapsulated data on links where the PPP FCS The PPP FCS follows the encapsulated data on links where the PPP FCS
is in use. is in use.
Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC Unlike the TRILL Ethernet encapsulation, PPP nodes do not have MAC
addresses, so no outer MAC is present. (HDLC addresses MAY be addresses, so no outer MAC is present. (HDLC addresses MAY be
present in some situations; such usage is outside the scope of this present in some situations; such usage is outside the scope of this
document.) document.)
2.3. TLSP Packet Format INTERNET-DRAFT TRILL over PPP
2.3 TLSP Packet Format
When TNCP is in Opened state, TLSP packets are sent by setting the When TNCP is in Opened state, TLSP packets are sent by setting the
PPP Protocol field to hex TBD-40XX (TLSP) and placing exactly one PPP Protocol field to hex TBD-40YY (TLSP) and placing exactly one IS-
IS-IS Payload (section 4.2.3 of [1], "TRILL IS-IS Frames") in the PPP IS Payload (section 4.2.3 of [RFCtrill], "TRILL IS-IS Frames") in the
Information field. PPP Information field.
Note that point-to-point IS-IS links have only an arbitrary Circuit Note that point-to-point IS-IS links have only an arbitrary Circuit
ID, and do not use MAC addresses for identification. ID, and do not use MAC addresses for identification.
3. TRILL PPP Behavior INTERNET-DRAFT TRILL over PPP
1. On a PPP link, TRILL always uses P2P Hellos. There is no need 3. TRILL PPP Behavior
for TRILL-Hello frames, nor is per-port configuration necessary.
P2P Hello messages, per "Point-to-Point IS to IS Hello PDU" 1. On a PPP link, TRILL always uses P2P Hellos. There is no need for
(section 9.7 of [6]), do not use Neighbor IDs in the same manner TRILL-Hello frames, nor is per-port configuration necessary. P2P
as on Ethernet. However, per section 4.2.4.1 of [1], three-way Hello messages, per "Point-to-Point IS to IS Hello PDU" (section
IS-IS handshake using extended circuit IDs is required on 9.7 of [IS-IS]), do not use Neighbor IDs in the same manner as on
point-to-point links, such as PPP. Ethernet. However, per section 4.2.4.1 of [RFCtrill], three-way
IS-IS handshake using extended circuit IDs is required on point-
to-point links, such as PPP.
2. RBridges are never appointed forwarders on PPP links. If an 2. RBridges are never appointed forwarders on PPP links. If an
implementation includes BCP [5], then it MUST ensure that only one implementation includes BCP [RFC3518], then it MUST ensure that
of BCP or TNCP is negotiated on a link, and not both. If the peer only one of BCP or TNCP is negotiated on a link, and not both. If
is an RBridge, then there is no need to pass unencapsulated the peer is an RBridge, then there is no need to pass
frames, as the link can have no TRILL-ignorant peer to be unencapsulated frames, as the link can have no TRILL-ignorant peer
concerned about. If the peer is not an RBridge, then TNCP to be concerned about. If the peer is not an RBridge, then TNCP
negotiation fails and TRILL is not used on the link. negotiation fails and TRILL is not used on the link.
3. An implementation that has only PPP links might have no 3. An implementation that has only PPP links might have no
Organizationally Unique Identifier (OUI) that can form an IS-IS Organizationally Unique Identifier (OUI) that can form an IS-IS
System ID. Resolving that issue is outside the scope of this System ID. Resolving that issue is outside the scope of this
document, however it is strongly RECOMMENDED that all TRILL document, however it is strongly RECOMMENDED that all TRILL
implementations have at least one zero-configuration mechanism to implementations have at least one zero-configuration mechanism to
obtain a valid System ID. Refer to ISO/IEC 10589 regarding System obtain a valid System ID. Refer to ISO/IEC 10589 regarding System
ID uniqueness requirements. ID uniqueness requirements.
4. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of [1]) 4. TRILL MTU-probe and TRILL MTU-ack messages (section 4.3.2 of
are not needed on a PPP link. Implementations MUST NOT send [RFCtrill]) are not needed on a PPP link. Implementations MUST
MTU-probe and SHOULD NOT reply to these messages. The MTU NOT send MTU-probe and SHOULD NOT reply to these messages. The
computed by LCP SHOULD be used instead. Negotiating an LCP MTU MTU computed by LCP SHOULD be used instead. Negotiating an LCP
of at least 1524, to allow for an inner Ethernet payload of 1500 MTU of at least 1524, to allow for an inner Ethernet payload of
octets, is RECOMMENDED. 1500 octets, is RECOMMENDED.
4. Security Considerations INTERNET-DRAFT TRILL over PPP
4. Security Considerations
Existing PPP and IS-IS security mechanisms may play important roles Existing PPP and IS-IS security mechanisms may play important roles
in a network of RBridges interconnected by PPP links. A PPP in a network of RBridges interconnected by PPP links. The IS-IS
authentication mechanism (such as CHAP [8] or EAP [9]) protects the authentication mechanism [RFC5304] [RFC5310], at the TRILL IS-IS
establishment of a link, and identifies a link with a known peer. layer, prevents fabrication of link-state control messages.
The IS-IS authentication mechanisms [10] prevent fabrication of
link-state control messages. PPP link encryption mechanisms [11] can
protect the confidentiality and integrity of all packets on the link.
And when PPP is run over tunneling mechanisms, such as L2TP [12],
other security protocols are available.
A complete enumeration of possible deployment scenarios and Not all implementations need to include specific security mechanisms
associated threats and options is not possible and is outside the at the PPP layer, for example if they are designed to be deployed
scope of this document. Implementors are encouraged to evaluate only in cases where the networking environment is trusted or where
their own overall network and system security issues, and to use the other layers provide adequate security. A complete enumeration of
existing security mechanisms where appropriate. possible deployment scenarios and associated threats and options is
not possible and is outside the scope of this document. For
applications involving sensitive data, end-to-end security should
always be considered in addition to link security to provide security
in depth.
5. IANA Considerations However, in case a PPP layer authentication mechanism to protect the
establishment of a link and identify a link with a known peer is
needed, implementation of PPP CHAP [RFC1994] is RECOMENDED. Should
greater flexibility be required than that provided by CHAP, EAP
[RFC3748] is a good alternative.
IANA has assigned three PPP Protocol field values, TBD-00XX, TBD- If TRILL over PPP packets also require confidentiality, the PPP ECP
40XX, and TBD-80XX, as described in Section 1 of this document. link encryption mechanisms [RFC1968] can protect the confidentiality
and integrity of all packets on the PPP link.
And when PPP is run over tunneling mechanisms, such as L2TP
[RFC3931], tunnel security protocols may be available.
For general TRILL protocol security considerations, see [RFCtrill].
5. IANA Considerations
IANA is requested to assigned three PPP Protocol field values,
TBD-00XX, TBD-40YY, and TBD-80ZZ, as described in Section 1 of this
document.
IANA is requested to create a new "PPP TNCP Configuration Option
Types" in the PPP-Numbers registry using the same format as the
existing "PPP LCP Configuration Option Types" table.
All TNCP Configuration Option Types except 00 are "Unassigned" and All TNCP Configuration Option Types except 00 are "Unassigned" and
available for future use, based on "IETF Review," as described in BCP available for future use, based on "IETF Review," as described in BCP
26 [4]. Option 00 is allocated for use with Vendor Specific Options, 26 [RFC5226]. Option 00 is allocated for use with Vendor Specific
as described in [7]. Options, as described in [RFC2153].
[IANA Note: new registry "PPP TNCP Configuration Option Types" needed INTERNET-DRAFT TRILL over PPP
under ppp-numbers using the same format as the existing "PPP LCP
Configuration Option Types" table; details in paragraph above.]
6. References 6. References
6.1. Normative Normative and Informational references are listed below.
[1] R. Perlman, et al., "RBridges: Base Protocol Specification," 6.1 Normative
draft-ietf-trill-rbridge-protocol-16.txt, in RFC Editor queue
[2] W. Simpson, Editor, "The Point-to-Point Protocol (PPP)," RFC [RFC1661] - W. Simpson, Editor, "The Point-to-Point Protocol (PPP),"
1661, July 1994 RFC 1661, July 1994
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
Levels," BCP 14 and RFC 2119, March 1997 Requirement Levels," BCP 14 and RFC 2119, March 1997
[4] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [RFC5226] - T. Narten and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs," BCP 26 and RFC 5226, May 2008 IANA Considerations Section in RFCs," BCP 26 and RFC 5226, May
2008
6.2. Informative [RFCtrill] - R. Perlman, et al., "RBridges: Base Protocol
Specification," draft-ietf-trill-rbridge-protocol-16.txt, in
RFC Editor queue
[5] M. Higashiyama, et al., "Point-to-Point Protocol (PPP) Bridging 6.2 Informative
Control Protocol (BCP)," RFC 3518, April 2003
[6] International Organization for Standardization, "Intermediate [IS-IS] - International Organization for Standardization,
system to Intermediate system intra-domain routeing information "Intermediate system to Intermediate system intra-domain
exchange protocol for use in conjunction with the protocol for routeing information exchange protocol for use in conjunction
providing the connectionless-mode Network Service (ISO 8473)", with the protocol for providing the connectionless-mode Network
ISO/IEC 10589:2002, Second Edition, Nov 2002 Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov
2002
[7] W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997 [RFC1968] - G. Meyer, "The PPP Encryption Control Protocol (ECP),"
RFC 1968, June 1996
[8] W. Simpson, "PPP Challenge Handshake Authentication Protocol [RFC1994] - W. Simpson, "PPP Challenge Handshake Authentication
(CHAP)," RFC 1994, August 1996 Protocol (CHAP)," RFC 1994, August 1996
[9] B. Aboba, et al., "Extensible Authentication Protocol (EAP)," [RFC2153] - W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997
RFC 3748, June 2004
[10] T. Li and R. Atkinson, "IS-IS Cryptographic Authentication," [RFC3518] - M. Higashiyama, et al., "Point-to-Point Protocol (PPP)
RFC 5304, October 2008 Bridging Control Protocol (BCP)," RFC 3518, April 2003
[11] G. Meyer, "The PPP Encryption Control Protocol (ECP)," RFC [RFC3748] - B. Aboba, et al., "Extensible Authentication Protocol
1968, June 1996 (EAP)," RFC 3748, June 2004
[12] J. Lau, Ed., et al., "Layer Two Tunneling Protocol - Version INTERNET-DRAFT TRILL over PPP
3 (L2TPv3)," RFC 3931, March 2005
7. Acknowledgments [RFC3931] - J. Lau, Ed., et al., "Layer Two Tunneling Protocol -
Version 3 (L2TPv3)," RFC 3931, March 2005
The author thanks Jari Arkko, Stewart Bryant, Linda Dunbar, Donald [RFC5304] - T. Li and R. Atkinson, "IS-IS Cryptographic
Eastlake, Radia Perlman, Mike Shand, and William A. Simpson for their Authentication," RFC 5304, October 2008
comments and help.
8. Authors' Addresses [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
5310, February 2009.
7. Acknowledgments
The authors thanks Jari Arkko, Stewart Bryant, Ralph Droms, Linda
Dunbar, Adrian Farrel, Stephen Farrell, Radia Perlman, Mike Shand,
and William A. Simpson for their comments and help.
8. Authors' Addresses
James Carlson James Carlson
WorkingCode WorkingCode
25 Essex Street 25 Essex Street
North Andover, MA 01845 USA North Andover, MA 01845 USA
Phone: +1-781-301-2471 Phone: +1-781-301-2471
Email: carlsonj@workingcode.com Email: carlsonj@workingcode.com
Donald Eastlake, 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
INTERNET-DRAFT TRILL over PPP
Copyright and IPR Provisions
Copyright (c) 2011 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.
 End of changes. 56 change blocks. 
142 lines changed or deleted 192 lines changed or added

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