Internet DRAFT - draft-bhati-l2tpext-l2tpv4
draft-bhati-l2tpext-l2tpv4
Internet Engineering Task Force A. Bhati
Internet Draft Samsung Electronics
Intended status: Standards Track October 25, 2016
Expires: April 2017
Layer Two Tunneling Protocol - Version 4 (L2TPv4)
draft-bhati-l2tpext-l2tpv4-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 25, 2009.
Bhati Expires April 25, 2017 [Page 1]
Internet-Draft L2TPv4 October 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.
Bhati Expires April 25, 2017 [Page 2]
Internet-Draft L2TPv4 October 2016
Abstract
This document describes the Layer Two Tunneling protocol (L2TPv4).
L2TPv4 defines implementation friendly and more secured encapsulation
headers for carrying multiple Layer 2 connections between two IP
nodes.
Table of Contents
1. Introduction...................................................4
1.1. Changes from RFC 3931.....................................4
2. Conventions used in this document..............................4
3. L2TPv4 data packet header format...............................5
3.1. Discussion................................................8
4. L2TPv4 control packet header format............................9
4.1. Discussion...............................................11
5. Security Considerations.......................................12
6. IANA Considerations...........................................12
7. Conclusions...................................................12
8. References....................................................13
8.1. Normative References.....................................13
8.2. Informative References...................................13
9. Acknowledgments...............................................13
Appendix A. Received Packet Processing...........................14
Appendix B. Packet Header Encapsulation Processing...............17
Bhati Expires April 25, 2017 [Page 3]
Internet-Draft L2TPv4 October 2016
1. Introduction
L2TP as originally defined in RFC 2661, is a standard method for
tunneling Point-To-Point (PPP) [RFC 1661] sessions. L2TP is then
modified in L2TPv3 for adoption of tunneling a number of other L2
protocols. This document describes L2TPv4 encapsulation headers (for
data packets and control packets) that is implementation friendly and
provides more security features. Irrespective of whether we carry
L2TPv4 payload as IP layer payload [IP + L2TP + layer-2 header +
payload] or transport layer payload [IP + UDP + L2TP + layer-2 header
+ payload], L2TPv4 encapsulation header format will be same.
The following header formats are described in following sections.
o L2TPv4 data packet header over IP or UDP
o L2TPv4 control packet header over IP or UDP
1.1. Changes from RFC 3931
Everything that is described in RFC 3931 will remain intact except
the L2TP header formats for data packets and control packets. This
draft document proposes to use common L2TPv4 data packet header
format irrespective of the PSNs over which L2TPv4 is operating. This
draft document also proposes to use common L2TPv4 control packet
header format irrespective of the PSNs over which L2TPv4 is
operating. L2TPv3 data and control header formats are different in
cases when L2TPv3 is operating over IP or over UDP. This draft
document proposes to replace those differences with similarities
across PSNs.
L2Tpv4 implementations MUST support L2TP over IP and should support
L2TP over UDP for better NAT and firewall traversal, and for easier
migration from previous L2TP implementations.
2. 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 RFC 2119 [RFC2119].
Bhati Expires April 25, 2017 [Page 4]
Internet-Draft L2TPv4 October 2016
3. L2TPv4 data packet header format
L2TPv4 data packet header format is described in the following
figure. This header format is same irrespective of PSNs [over IP,
over UDP] over which L2TP is operating.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|V|V|V|T|C|S|X|X|X|X|X|X|X|X|X| L2TP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto |Proto Hdr Len | L2TP Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Cookie (Optional, maximum 64 bits)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 L2TPv4 data packet header
VVVV:
A 4 bit field which indicates version of L2TP header. Its value is
equal to 0100 for L2TPv4 data packet.
T:
A 1 bit field which indicates whether it is a data packet or control
packet. Its value is equal to 0 for data packets.
Bhati Expires April 25, 2017 [Page 5]
Internet-Draft L2TPv4 October 2016
C:
A 1 bit field which indicates header checksum is present inside L2TP
header and needs to be validated. Checksum calculation is similar to
IPv4 header checksum calculation as described in [RFC 1071]. For L2TP
data packets directly operating over IP, it is recommended to set
this bit and update the 16-bit checksum value inside L2TP header.
This bit can be set to 0 in case L2TP is operating over UDP because
UDP checksum can be used to provide integrity to L2TP header and its
payload. If C bit is zero, checksum field MUST contain 0x0000 as 16
bit value. Checksum covers all bytes starting from first bit of L2TP
header till last byte of session cookie value (if present).
S:
A 1 bit field which indicates session cookie value is present inside
L2TP header and a comparison is required between this value and
cookie present inside L2TP session context.
L2TP Header Checksum:
A 16 bit field which contains checksum value and covers entire L2TP
header. This value should be written to all zeros before actually
doing the checksum calculation on header bytes.
Proto:
An 8 bit field which contains the protocol value which L2TP is
carrying inside as a payload. As described in [RFC 3931], this is
equal to the pseudo-wire type. For example: If L2TP is used to carry
PPP frames, the Pseudo-wire type PS-WIRE-PPP should be set as proto
value inside L2TP header. This value of protocol is covered inside
L2TP header integrity checksum.
Bhati Expires April 25, 2017 [Page 6]
Internet-Draft L2TPv4 October 2016
Proto Header Length:
An 8 bit field which carries length of protocol header which is
encapsulated inside L2TP protocol. As described in [RFC 3931], this
is equal to the length of pseudo-wire header. For example: If L2TP is
used to carry HDLC frames, the Pseudo-wire type PS-WIRE-HDLC should
be set as proto value inside L2TP header and proto header length
should be set to 4. For any encapsulation sequence, we always know
how many bytes of pseudo-wire header are added before encapsulation
of L2TP headers. This value of protocol header length is covered
inside L2TP header integrity checksum.
L2TP Payload Length:
A 16 bit field which carries total length of L2TP payload. This value
does not include L2TP header length. If L2TP is used to carry PPP
frames, then L2TP payload length value is equal to sum of PPP header
and PPP payload bytes.
L2TP Session ID:
A 32 bit field containing a non-zero identifier for a session as
described in [RFC 3931].
L2TP Session Cookie:
The optional cookie field contains a variable length value (maximum
64 bits) used to check the association of a received data message
with the session identified by the Session ID. It is as described in
[RFC 3931].
Bhati Expires April 25, 2017 [Page 7]
Internet-Draft L2TPv4 October 2016
3.1. Discussion
The above mentioned format of L2TP data message header shall be used
irrespective of whether L2TP is operating over IP or over UDP. The
main reason for not having L2TP header length inside L2TP header is
to avoid guessing the actual session cookie length by intermediate
entities. The prediction of session cookie by intermediate entities
can compromise the L2TP security features.
If IPv4 protocol value is 115, and first 5 bits after end of IPv4
header are equal to 01000, then we MUST interpret the packet as
L2TPv4 data packet.
If IPv4 protocol value is 17, then 8 bytes of UDP header will be
present after IPv4 header. If operating over UDP, L2TP peers usually
agree on a UDP port range. If UDP destination port falls in between
that range and first 5 bits after UDP header are equal to 01000, then
we MUST interpret the packet as L2TPv4 data packet.
Addition of version bits inside L2TP header flags makes it easier to
define future versions of L2TP protocol. It is also easier for the
implementations to switch between different versions dynamically when
L2TP entity receives L2TP packets of different versions. This
scenario can happen when multiple LAC with different L2TP versions
establish tunnel with LNS which supports all versions of L2TP
protocol.
Bhati Expires April 25, 2017 [Page 8]
Internet-Draft L2TPv4 October 2016
4. L2TPv4 control packet header format
L2TPv4 data packet header format is described in the following
figure. This header format is same irrespective of PSNs [over IP,
over UDP] over which L2TP is operating.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V|V|V|V|T|C|S|X|X|X|X|X|X|X|X|X| L2TP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 L2TPv4 control packet header
VVVV:
A 4 bit field indicates the version of L2TP header. Its value is
equal to 0100 for L2TPv4 control packet.
T:
A 1 bit field indicates whether it is a data packet or control
packet. Its value is equal to 1 for control packets.
Bhati Expires April 25, 2017 [Page 9]
Internet-Draft L2TPv4 October 2016
C:
A 1 bit field which indicates header checksum is present inside L2TP
header and needs to be validated. Checksum calculation is similar to
IPv4 header checksum calculation as described in [RFC 1071]. For L2TP
data packets directly operating over IP, it is recommended to set
this bit and update the 16-bit checksum value inside L2TP header.
This bit can be set to 0 in case L2TP is operating over UDP because
UDP checksum can be used to provide security to L2TP header and its
payload. Checksum covers all bytes starting from first bit of L2TP
header till last bit of Nr field.
S:
A 1 bit field indicates sequence numbers (Ns and Nr) are present
inside L2TP control packet header.
L2TP Header Checksum:
A 16 bit field contains checksum value for L2TPv4 control packet
header. This value should be written to all zeros before actually
doing the checksum calculation on header bytes.
Length:
A 16 bit field carries length of control packet bytes. This is equal
to the sum of L2TPv4 control header bytes and L2TPv4 control payload.
This length is covered inside the checksum calculation of L2TPv4
control packet, if C bit is 1.
Control Connection ID:
A 32 bit field which carries control connection identifier. This
value is detailed in RFC 3931.
Bhati Expires April 25, 2017 [Page 10]
Internet-Draft L2TPv4 October 2016
Ns:
A 16 bit field carries control message sequence number for the sender
of control message. Interpretation of this field is governed by [RFC
3931]. This field is present only is S bit is set in L2TPv4 flags.
Nr:
A 16 bit field carries last received message number which is used to
acknowledge messages received by a L2TP peer. Interpretation of this
field is governed by [RFC 3931]. This field is present only if S bit
is set in L2TPv4 flags.
4.1. Discussion
This format of L2TP control message header shall be used irrespective
of whether L2TP is operating over IP or over UDP. If IP protocol
value is 115, and first 5 bits of L2TP header are equal to 01001,
then we shall interpret the packet as L2TP control packet.
When operating directly over IP, L2TP packets lose the ability to
take advantage of UDP checksum as a simple measure for packet
integrity check, which is of a particular concern to L2TP control
messages. That is the main reason to include L2TP header checksum as
an optional field inside L2TPv4 headers. The presence or absence of
actual checksum is controlled by C bit in L2TPv4 header flags.
If IP protocol value is 17, then 8 bytes of UDP header will be
present after IP header. If operating over UDP, L2TP peers usually
agree on a UDP port range. If UDP destination port falls in between
that range and first 5 bits after UDP header are equal to 01001, then
we shall interpret the packet as L2TPv4 control packet.
Bhati Expires April 25, 2017 [Page 11]
Internet-Draft L2TPv4 October 2016
5. Security Considerations
This section addresses data header integrity concern. Optional header
checksum field is added inside data packet header which is calculated
over L2TP data header including variable length of session cookie
field. If session cookie flag is set in data packet header, it is
recommended that header checksum flag MUST be set to 1 for additional
level of integrity check.
6. IANA Considerations
This draft document does not request any IANA action.
7. Conclusions
This draft document proposes header formats for L2TPv4 data and
control packets which are implementation friendly and provides
additional level of integrity check via new fields inside headers.
The header formats of data packet and control packet are common
whether we carry L2TP over IP or L2TP over UDP.
Bhati Expires April 25, 2017 [Page 12]
Internet-Draft L2TPv4 October 2016
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
8.2. Informative References
[RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G.Zorn,
B.Palter, "Layer Two Tunneling Protocol "L2TP", RFC 2661,
August 1999
[RFC 3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3), RFC 3931, March 2005
9. Acknowledgments
Many of the protocol constructs were originally defined in RFC 2661,
"L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens,
G. Pall, G. Zorn, B. Palter. Thanks so much for defining a wonderful
protocol.
Thanks to the authors of RFC 3931 "L2TPv3". RFC 3931 authors are J.
Lau, M. Townsley, I. Goyret. Addition of multiple pseudo wire types
is indeed an important update to L2TP protocol.
Big Thanks to J. Touch who has prepared the word template document to
edit/write new RFC documents. It is really difficult to write a new
RFC without this template. This document was prepared using 2-Word-
v2.0.template.dot.
Bhati Expires April 25, 2017 [Page 13]
Internet-Draft L2TPv4 October 2016
Appendix A. Received Packet Processing
void rcvd_packet_process(uint8_t *pkt_ptr)
{
ip_hdr_ptr = (ip_hdr_t *)(pkt_ptr);
if(115 == ip_hdr_ptr->protocol)
{
l2tp_hdr_ptr = (uint8_t *)(ip_hdr_ptr + ip_hdr_length);
first_two_bytes = *((uint16_t *)(l2tp_hdr_ptr));
if(0x4000 == first_two_bytes & 0x4800)
{
// this is L2TPv4 data packet
}
else if(0x4800 == first_two_bytes & 0x4800)
{
// this is L2TPv4 control packet
}
else
{
// MUST discard this packet
}
}
Bhati Expires April 25, 2017 [Page 14]
Internet-Draft L2TPv4 October 2016
else if(17 == ip_hdr_ptr->protocol)
{
udp_hdr_ptr = (udp_hdr_t *)(ip_hdr_ptr + 1);
if(l2tp_session_ptr->udp_min < udp_hdr_ptr->dest_port &&
l2tp_session_ptr->udp_max > udp_hdr_ptr->dest_port &&
l2tp_session_ptr->l2tp_over_udp == 1)
{
l2tp_hdr_ptr = (l2tp_hdr_t *)(udp_hdr_ptr + 1);
first_two_bytes = *((uint16_t *)(l2tp_hdr_ptr));
if(0x4000 == first_two_bytes & 0x4800)
{
// this is L2TPv4 data packet
}
else if(0x4800 == first_two_bytes & 0x4800)
{
// this is L2TPv4 control packet
}
else
{
// MUST discard this packet
}
}
}
}
Bhati Expires April 25, 2017 [Page 15]
Internet-Draft L2TPv4 October 2016
Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Bhati Expires April 25, 2017 [Page 16]
Internet-Draft L2TPv4 October 2016
Appendix B. Packet Header Encapsulation Processing
void l2tp_data_packet_sender(uint8_t *pkt_ptr,
uint16_t pkt_len,
void *l2tp_session_context)
{
switch(l2tp_session_context->pw_type)
{
case 'PPP':
l2_hdr_size = 4;
l2_hdr_ptr = pkt_ptr - l2_hdr_size;
*((uint32_t *)(l2tp_hdr_ptr)) = layer_2_hdr_value;
break;
case 'HDLC':
l2_hdr_size = 4;
l2_hdr_ptr = pkt_ptr - l2_hdr_size;
*((uint32_t *)(l2tp_hdr_ptr)) = layer_2_hdr_value;
break;
case 'consider other cases also'
break;
default:
break;
}
Bhati Expires April 25, 2017 [Page 17]
Internet-Draft L2TPv4 October 2016
/////// Time to Add L2TPv4 data header ////////////////////
// 2 byte flags + 2 byte header checksum + 1 byte proto +
// 1 byte proto_len + 2 byte payload_len + 4 byte session id
// Total fixed size = 12 bytes
///////////////////////////////////////////////////////////
uint8_t l2tp_hdr_size = 12;
if(1 == l2tp_session_context->cookie_set)
{
l2tp_hdr_size += l2tp_session_context->cookie_len;
}
l2tp_hdr_ptr = l2_hdr_ptr - l2tp_hdr_size;
l2tp_hdr_ptr->flags.version = 0x4; // L2TPv4
l2tp_hdr_ptr->flags.T_bit = 0; // data packet
if(l2tp_session_context->l2tp_over_ip)
{
l2tp_hdr_ptr->flags.C_bit = 1;
}
else
{
l2tp_hdr_ptr->flags.C_bit = 0; // UDP checksum is enough
}
Bhati Expires April 25, 2017 [Page 18]
Internet-Draft L2TPv4 October 2016
if(l2tp_session_context->cookie_set)
{
l2tp_hdr_ptr->flags.S_bit = 1;
}
l2tp_hdr_ptr->checksum = 0x0000;
l2tp_hdr_ptr->proto = l2tp_session_context->pw_type;
l2tp_hdr_ptr->proto_hdr_len = l2_hdr_size;
l2tp_hdr_ptr->payload_len = pkt_len + l2_hdr_len;
l2tp_hdr_ptr->session_id = l2tp_session_context->session_id;
if(l2tp_hdr_ptr->flags.S_bit)
{
memcpy(l2tp_hdr_ptr + 12, // destination
l2tp_session_ptr->cookie, // source
l2tp_session_ptr->cookie_len); // length
}
if(l2tp_hdr_ptr->flags.C_bit)
{
l2tp_hdr_ptr->checksum =
checksum(l2tp_hdr_ptr, 12 + l2tp_session_ptr->cookie_len);
}
} // end of pseudo function
Bhati Expires April 25, 2017 [Page 19]
Internet-Draft L2TPv4 October 2016
Copyright (c) 2016 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Bhati Expires April 25, 2017 [Page 20]
Internet-Draft L2TPv4 October 2016
Authors' Addresses
ABHISHEK BHATI
SAMSUNG ELECTRONICS
SAMSUNG R&D INSTITUTE, BENGALURU, INDIA
Phone: +91-9686500752
Email: ABH.BHATI@SAMSUNG.COM / AB.BHATI@GMAIL.COM
Bhati Expires April 25, 2017 [Page 21]
