Internet DRAFT - draft-hawari-tcpm-tfo-ipv6-prefixes
draft-hawari-tcpm-tfo-ipv6-prefixes
tcpm M. HAWARI
Internet-Draft Ecole Polytechnique / Cisco Systems
Intended status: Experimental July 3, 2015
Expires: January 4, 2016
TCP Fast Open Cookie for IPv6 prefixes
draft-hawari-tcpm-tfo-ipv6-prefixes-00
Abstract
In order to support applications that require a large number of
addresses or address space, a host may be assigned an aggregate IPv6
prefix rather than one or more discrete IPv6 addresses. This
document briefly describes cases where this may occur, and specifies
an extension to TCP Fast Open [RFC7413] to allow a client to use a
single TCP Fast Open cookie for an IPv6 prefix.
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 January 4, 2016.
Copyright Notice
Copyright (c) 2015 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
HAWARI Expires January 4, 2016 [Page 1]
Internet-Draft TFO IPv6 Prefixes July 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposed extension to TCP Fast Open . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. The TCP Fast Open Prefix Length option (TFOPL). . . . . . 3
2.3. Behaviour of the client . . . . . . . . . . . . . . . . . 3
2.4. Behaviour of the server . . . . . . . . . . . . . . . . . 3
3. TCP Fast Open Prefix Length Option Format . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
1.1. 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 [RFC2119] .
1.2. Motivation
TCP Fast Open(TFO) [RFC7413] provides applications with a mechanism
allowing them to send data in the TCP SYN packet. It relies on a TFO
cookie which is delivered by the server to the client. This cookie
is then used by the client for all further TFO transactions to the
server's IP address.
Unlike IPv4, IPv6 provides the applications with the ability to
leverage a great number of addresses. A single server may be
associated to a whole IP prefix from which each of the IP addresses
may be mapped to various application layer concepts. For example an
IPv6 address can identify a service, a process, or even a chunk of
data.
Consequently, it is convenient to make a TFO cookie valid for a whole
prefix instead of a single network address as this prefix may be
hosted on a single server. That is the reason why this document
proposes an extension to TFO to achieve this goal.
HAWARI Expires January 4, 2016 [Page 2]
Internet-Draft TFO IPv6 Prefixes July 2015
Another application of this extension appears in the context of a
DNS-load-balanced cluster of servers. In this case, one server of
the cluster will provide the client with a TFO cookie which is valid
for the whole cluster, thus reducing the number of three way
handshakes.
2. Proposed extension to TCP Fast Open
2.1. Overview
When a server receives a TCP SYN packet asking for a TFO cookie, it
generates a TFO cookie and sends a TCP SYN+ACK with the TFO cookie
and the prefix length for which the TFO cookie is valid, thus
allowing the client to reuse the cookie for the whole prefix
containing the server.
2.2. The TCP Fast Open Prefix Length option (TFOPL).
A new TCP Option named TCP Fast Open Prefix Length (TFOPL) is
specified here. The value of this option is the prefix length (in
bits) which a TCP Fast Open (TFO) cookie is valid for.
2.3. Behaviour of the client
When the client requests a TFO cookie, it MUST include in the TCP SYN
packet a TFOPL Option containing the value zero and an empty TFO
cookie.
When the client receives a TCP SYN+ACK packet including a TFO cookie
and a TFOPL Option containing the value N, it MAY use this cookie for
all further transactions with a host whose IP address belongs to the
prefix of length N associated to the server.
When the client receives a TCP SYN+ACK packet including a TFO cookie
without any TFOPL Option, it MUST assume that the received prefix
length is 128 (i.e, a single address).
2.4. Behaviour of the server
When the server receives a TCP SYN packet including a TFO cookie and
a TFOPL Option, it MUST generate a TFO cookie and reply with a
SYN+ACK packet including the TFO cookie and the TFOPL option
containing the prefix length in bits for which the TFO cookie is
valid.
When the server receives a TCP SYN packet including a TFO cookie but
without any TFOPL Option, it MUST have the same behaviour as a
regular TFO-enabled server as described in [RFC7413].
HAWARI Expires January 4, 2016 [Page 3]
Internet-Draft TFO IPv6 Prefixes July 2015
If a TFO cookie is delivered by the server for a prefix of length N,
all the servers belonging to this prefix MUST consider it as a valid
TFO cookie, until its potential invalidation for the whole prefix.
They MUST also deliver TFO cookies with a TFOPL option containing the
value N.
3. TCP Fast Open Prefix Length Option Format
The TFOPL option has a TLV structure:
+------------+------------+-----------+
| TCP Option | Length | Prefix |
| Kind Number| | Length |
| (1 BYTE) | (1 BYTE) | (1 BYTE) |
+------------+------------+-----------+
The length field MUST be equal to 0x3. The Prefix Length field MUST
contain a value between 0 and 128. Any out of bounds Prefix Length
Value MUST be considered as an absence of TFOPL option.
4. IANA Considerations
IANA is kindly asked to allocate a value in the "TCP Option Kind
Numbers" registry for the TCP Fast Open Prefix Length Option. The
length of this new TCP option is 3.
5. Security Considerations
A rogue TFO server can send a TFOPL option containing an arbitrary
small value, thus endangering all the TFO cookies saved by the client
prior to this transaction. The client may implement the following
strategy in order to mitigate this issue:
The client has a parameter N between 0 and 128. This parameter is a
lower bound for the received prefix lengths. When the client
receives a SYN+ACK packet with a TFOPL containing a value N', it acts
as if it has received min(N,N'). This strategy prevents the server
from erasing the cookies of the client outside the own prefix of
length N of the server. A typical value for N may be 64.
6. Acknowledgements
The author would like to thank Pierre Pfister, Mark Townsley and
Andrew Yourtchencko for their contributions to this draft.
HAWARI Expires January 4, 2016 [Page 4]
Internet-Draft TFO IPv6 Prefixes July 2015
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, December 2014.
Author's Address
Mohammed HAWARI
Ecole Polytechnique / Cisco Systems
Email: mohammed@hawari.fr
HAWARI Expires January 4, 2016 [Page 5]
