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]