nautiyal-l2tpext-tunnel-ka-control-channel-00.txt

Internet DRAFT - draft-nautiyal-l2tpext-tunnel-ka-control-channel

draft-nautiyal-l2tpext-tunnel-ka-control-channel

Last Version:	draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt	Tracker Entry
Date:	`25-Jun-2021`
Disposition:	expired

Network Working Group Y. Nautiyal
Internet-Draft Juniper Networks
Intended status: Standard Track June 23 2021
Expires: November 2021

L2TP Tunnel keepalive control channel
draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt

Abstract

This memo defines a dedicated control channel for L2TP tunnel keepalives
for use in deployment which has control plane and user plane seperation.

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 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.

1. Introduction

L2TP tunnel uses keepalive mechanism where it sends Hello control
message and waits for its acknowledgement. Each control message in
L2TP carries sequence numbers. More formally there are Ns and Nr sequence
numbers in L2TP header for control messages. Ns" stands for next-send
sequence number of the local tunnel endpoint, and "Nr" stands for
next-receive sequence number from the peer tunnel endpoint. Since Hello
messages also carries sequence numbers so they needs to be handled by
the same control plane. For the deployment which seperate control plane
and user plane, a node managing multiple user planes may become a
choking point for handling keepalives of different user planes. A
dedicated control channel for keepalives may help to off-load their
handling to each individual user plane.

2. Dedicated Hello control channel negotiation

The two L2TP endpoints of the tunnel negotiate for the usage of dedicated Hello
control channel if supported. If a implementation support dedicated Hello control
channel it should be able to support it in both modes i.e, with sequencing and
sequencing disabled.

2.1 Dedicated Hello control channel AVP

This is the new L2TP control message AVP assigned by IANA used for this negotiation.
The Hello control channel AVP has Mandatory bit 'M' and Hidden bit 'H'set to 0 in L2TP header.
The AVP value is one byte long and has value that can be 0, 1, or 2. AVP value of 0 means
Hello control channel is not supported. AVP value of 1 means Hello control channel is
supported without sequencing enabled. AVP value of 2 means Hello control control channel
is supported with sequence numbers.

The tunnel initiator include Hello control channel AVP in SCCRQ message if it
is supported. The other side on receipt of SCCRQ message responds with SCCRP
message and include Hello control channel AVP if it is supported. The tunnel initiator
will then know if the remote side also supports the dedicated hello control channel or not.

3 Dedicated Hello control channel message
3.1 Dedicated Hello control channel sequencing enabled

Hello control channel uses its own sequencing number management. A new L2TP message
type is used to identify this Hello message from the existing Hello message.
The receiving node on seeing this Hello message will be knowing if it needs to
handle it in separate control channel or not.

The Ns/Nr if to be used on dedicated hello control channel should be generated and
handled as per existing mechanism for L2TP per RFC 2580. But these sequence numbers will
be solely used for the keepalives management only. A node will not use the sequence numbers
from the hello control channel to acknowledge non-hello control messages. Neither
should a node use the sequence numbers from the hello control channel to transmit
a non-hello message.

3.2 Dedicated Hello control channel sequencing disabled

An implementation can also configure the Hello control channel to not use the
sequencing for the Hello messages at all. This means that the dedicated control channel
Hello message will not contain any Ns/Nr values in the L2TP header. For this a L2TP
node will informs its peer by setting the appropriate value of the AVP for dedicated
hello control channel in SCCRQ/SCCRP message.
For the incoming Hello message a L2TP node will simply acknowledge it by sending ZLB but
devoid of any Ns/Nr values in it.

4. Backward Compatibility

Since the mechanism in this document uses new control message type, it is made to be
compatible to existing implementation also. At the time of L2TP negotiation both sides
negotiates for use of dedicated hello control channel. If the negotiations is successful
then dedicated hello control channel is used, otherwise the existing mechanism stays.

3. Conventions

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 BCP 14, RFC 2119
[RFC2119].

8. Security Considerations.

Hello control channel may be operating on a different machine possibly but under
superior control of the machine handling control plane. A spoofing attempt by a machine
to hijack a hello control channel should be prevented.

9. IANA Considerations

L2TP Hello message on dedicated control channel:

This document introduces new message type for Hello on dedicated channel.
The new message type is IANA-assigned for L2TP message type AVP.

Descriptor Value
---------- -----------------------
Hello on dedicated control channel 30

L2TP control message type AVP for the hello on dedicated control channel:
Descriptor Value
---------- ------------------------
Hello dedicated control channel 30
control message type

11. References

11.1. Normative References

[RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G.Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)",
August 1999.atements for SMIv2", STD 58, RFC 2580, April 1999.

11.2. Informative References

[RFC2223] Postel, J. and J.K. Reynolds, "Instructions to RFC
Authors", RFC 2223, October 1997.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.

[RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.

[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.

11.3. URL References

[idguidelines]
IETF Internet Drafts editor,
"http://www.ietf.org/ietf/1id-guidelines.txt", .

[idnits] IETF Internet Drafts editor,
"http://www.ietf.org/ID-Checklist.html", .

[xml2rfc] XML2RFC tools and documentation,
"http://xml.resource.org", .

[ops] the IETF OPS Area, "http://www.ops.ietf.org", .

[ietf] IETF Tools Team, "http://tools.ietf.org", .

Author's Address

Yogesh Nautiyal
Juniper Networks
10 Technology Park Drive
Westford, MA 01886

Phone:
EMail: yogeshn@juniper.net