Internet DRAFT - draft-pc-tcpm-tcp-seamless-mobility-option
draft-pc-tcpm-tcp-seamless-mobility-option
TCPM Working Group B. Pithawala
Internet-Draft U. Chunduri, Ed.
Intended status: Informational Huawei Technologies
Expires: January 17, 2018 July 16, 2017
TCP Mobility Option with Identifiers
draft-pc-tcpm-tcp-seamless-mobility-option-00
Abstract
This document specifies the TCP Seamless Mobility Option (TCP-SMO)
with variable length identifiers. TCP-SMO allows mobility with
session continuity, when either of the TCP endpoint change its IP
address. This is being done securely and without any additional
round trips during mobility event.
Requirements Language
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 [RFC2119].
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 17, 2018.
Copyright Notice
Copyright (c) 2017 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
Pithawala & Chunduri Expires January 17, 2018 [Page 1]
Internet-Draft TCP Mobility Option with Identifiers July 2017
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TCP Seamless Mobility Option with Identifiers . . . . . . . . 3
4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5
4.1. Flow of TCP Connection with SMO And IP Address Change . . 5
4.2. Security mechanisms during IP address change . . . . . . 7
4.2.1. Security Option-1 . . . . . . . . . . . . . . . . . . 7
4.2.2. Security Option-2 . . . . . . . . . . . . . . . . . . 7
4.3. Notifying IP Address Change Event . . . . . . . . . . . . 9
4.4. Buffering the In-flight data . . . . . . . . . . . . . . 9
4.5. TCP-SMO with Unsupported Destination . . . . . . . . . . 10
5. Unsupported Middleboxes . . . . . . . . . . . . . . . . . . . 10
6. Impact of NAT between Source and Destination . . . . . . . . 10
7. Changes to host TCP Stack and Backward Compatibility . . . . 10
8. Relationship with other Identifier Protocols . . . . . . . . 11
9. Previous and Related Efforts . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
When a TCP [RFC0793] connection is opened with a peer, it (TCP
Session or Socket) is identified by Source port, Destination port,
Source IP address and Destination IP address by both initiator and
responder of the connection. This connection is identified by the
socket parameters and stored in Transmission Control Block (TCB) at
TCP stack. Any of these connection identifier changes at one end
cause either TCP RST by peer or the session times out eventually.
The above is per [RFC0793], Section 2.7- "To identify the separate
data streams that a TCP may handle, the TCP provides a port
identifier. Since port identifiers are selected independently by
each TCP they might not be unique. To provide for unique addresses
within each TCP, we concatenate an internet address identifying the
Pithawala & Chunduri Expires January 17, 2018 [Page 2]
Internet-Draft TCP Mobility Option with Identifiers July 2017
TCP with a port identifier to create a socket which will be unique
throughout all networks connected together."
There are more mobile devices today than a decade earlier. Hence it
is imperative that we have a mechanism to provide Session or
Transport layer connectivity that is impervious to network layer
changes. Some of the Identifier/Location protocols which has
inherent support for seamless mobility and relationship to this work
is discussed in Section 8.
This document provides an option towards providing resilience in the
TCP transport layer as either end of the connection moves and changes
its location (and thereby its IP address). Some of the previous
efforts with TCP mobility have been discussed in Section 9
2. Acronyms
DH - Diffie-Hellman Key Agreement
HIP - Host Identity Protocol
LISP - The Locator/ID Separation Protocol
TCP - Transmission Control Protocol
3. TCP Seamless Mobility Option with Identifiers
For seamless mobility with an uninterrupted TCP connection, this
document proposes a TCP Seamless Mobility Option (TCP-SMO) as
described in Figure 1 . This new TCP option introduces connection
identifiers and proposes changes to TCP to use these identifiers for
TCB or connection identification.
Pithawala & Chunduri Expires January 17, 2018 [Page 3]
Internet-Draft TCP Mobility Option with Identifiers July 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |DH |M|Flags | SL |DL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection Identifier (variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TCP Seamless Mobility Option (TCP-SMO)
Kind - TBD (TCP IANA).
Length - Variable. Includes Kind and Length field in bytes. Minimum
value is 12 and a maximum value is 40 bytes. When the Length is less
than 12 TCP MUST discard the segment.
Flags
'D H' - (2 bits) When its non-zero Diffie-Helman value is being
exchanged
D H Bits in Flags
0 0 NO Diffie-Hellman values exchanged
0 1 1024-bit ModP Group (mandatory)
1 0 2048-bit ModP Group/elliptic curve groups which has 200bits
ModP
1 1 Reserved
Two tiers of identification are needed, with identifiers anchored
at the identity.
'M' - mobility event, optional data (4 bytes) contains the keyed
hash of the Source Connection Identifier concatenated with a fixed
12 byte String 0xFEFEFEFEABABABABDEDEDEDE. The fixed string will
help normalized the total data for the hash function as connection
identifiers length can be as low as 4 bytes.
Pithawala & Chunduri Expires January 17, 2018 [Page 4]
Internet-Draft TCP Mobility Option with Identifiers July 2017
In Case of Security Option-1 - the hash function is a simple
SHA1-96 hash of the above concatenated data. Optional 4 byte data
is the checksum of this hash data.
In Case of Security Option-2 Hash function MUST use AES-128-CMAC-6
[NIST-SP800-38B][FIPS197] and Optional 4 byte data is the checksum
of this "keyed" hash data.
Other flags are reserved and undefined.
SL - Source CID Length (4 bits) - Length of the source identifier in
bytes. Minimum is 4 bytes and a maximum of 16 bytes.
DL - Source CID Length (4 bits) - Length of the destination
identifier in bytes. Minimum is 4 bytes and a maximum of 16 bytes.
SCID: Source Connection identifier - Length minimum of 4 bytes as
indicated by CID length. It can be generated by TCP module or can be
supplied by application.
DCID: Destination Connection identifier - Length minimum of 4 bytes
as indicated by CID length. It can be generated by TCP module or can
be supplied by application.
Optional data (4 Bytes) - MUST be present only when M bit is set and
MUST contain the 4 bytes of Checksum of Generated hash of the Source
Connection Identifier + Fixed Data.
The Checksum and Hash is generated on the side of communication which
detected an IP address change and needs to provide seamless mobility.
Source CID (SCID) and Destination CID (DCID) can be provided to TCP
by an application or other protocol (LISP, HIP or any other ID
related protocol with in the constrains of this option) while opening
the TCP socket or TCP stack can generate unique pair of CIDs to be
used in this option.
4. Elements of Procedure
4.1. Flow of TCP Connection with SMO And IP Address Change
Consider IP address of Source is IP1 and Destination is IP2. TCP-SMO
can be explained with a sequence of TCP segments as specified below:
1. Source sends TCP-SYN message with TCP-SMO. In the Seamless
Mobility Option: If CID's (source and destination) are chosen by
application and given to TCP then both can be present in the TCP-SYN
segment. If TCP has to choose the CID's, source chooses the unique
Pithawala & Chunduri Expires January 17, 2018 [Page 5]
Internet-Draft TCP Mobility Option with Identifiers July 2017
(local to the TCP stack) connection Identifier and keeps the
destination connection identifier as 0x0 with minimum length 4 bytes
in the TCP-SYN segment. When destination receives this segment, it
allocates another unique identifier and this value would be kept in
the SYN-ACK segment sent to the source.
2. Destination receives the SYN segment and it supports this option.
It responds back with SYN-ACK with the mobility options. If
destination CID is 0x0, as specified above it Chooses a unique CID.
From this point TCB is looked-up by Source CID, Destination CID
instead of [RFC0793] Section 2.7.
3. Source sends Sync-Ack-Ack segment and at source side TCB is
established with look up parameters by Source CID, Destination CID,
Source Port and Destination port instead of [RFC0793] Section 2.7.
4. TCP data segments exchanged from both Source and destination and
these segments will have the TCP-SMO.
5. In the middle of the connection, a mobility event happened at the
source and IP address is changed from IP1 to IP11. When there is
data to be sent immediately by source, data segment will be sent with
the new Source IP address IP11 and TCB at both ends update the change
in the Source IP address. If there is no data segment to be sent by
source during mobility event either a TCP keep alive segment or empty
data packet needs to be sent with this new IP to allow TCB's at both
end to know the new Source IP address.
The security implications of continuing to use the same session after
an IP address change are discussed in Section 4.2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |DH |1|Flags | SL |DL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Connection Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Connection Identifier (variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum of the Generated Hash of SCID + fixed data(4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TCP Seamless Mobility Option Sent at IP Change Event
6. Destination receives TCP-SMO segment. Verifies that IP1 sent the
data for change to IP11 thru the Generated Hash, updates its TCB for
Pithawala & Chunduri Expires January 17, 2018 [Page 6]
Internet-Draft TCP Mobility Option with Identifiers July 2017
IP1 connections with Mobility flag set and starts to receive packets
on source IP11 TCP segment sent by destination with new Source IP
address. If Destination cannot verify then it terminates the
session, which is the same as existing behavior.
7. Data sent by source but a mobility event happens at destination
before this event can be updated to source. In this case the data is
lost and would be retransmitted by source when changed IP address is
notified by destination.
8. Either end can terminate the session by sending the TCP-FIN
sequence which also uses TCP-SMO regardless who initiates the socket
close.
4.2. Security mechanisms during IP address change
4.2.1. Security Option-1
The TCP-SMO discussed does introduce a security issue as anybody can
hijack the existing TCP connection by changing the source IP address
(Connection Hijacking). It is recommended to use security at IP
(IPsec) or transport layer-Authentication Option (TCP-AO) [RFC5925]
for securing the TCP connection including the TCP header. When
[RFC5925] is used TCP-SMO size MUST not be exceeded more than 12
bytes to accommodate TCP-AO [RFC5925].
Implication on Connection Identifiers:
With the TCP AO option for authentication of an IP Address change,
the Source and Destination connection Identifiers have to be fixed at
4 bytes each for a valid TCP-SMO.
4.2.2. Security Option-2
In this option, security for TCP-SMO is done in-line with in the
newly defined option by exchanging a DH public value and computing a
shared secret at both ends, which can be used as a key to generate a
hash value (pre-defined has algorithm) during mobility. DH groups
and the hash algorithms are pre-defined and MUST be implemented to
use this mechanism to avail the needed security.
This option relies on the "data" to be sent during 3 way handshake.
This data is not application data but the ModP (DH public value) for
selected DH group. As the size of this is anywhere from 1024 bits
(DH Group-1) to 2048 bits (DH Group-2)/200 bits (Elliptic curve DH
groups) sending this as part of option data is not possible (limited
option space in the TCP header).
Pithawala & Chunduri Expires January 17, 2018 [Page 7]
Internet-Draft TCP Mobility Option with Identifiers July 2017
Section 3.4 of [RFC0793] specifies and allows a mechanism to send
application data during TCP 3 way hand shake but this "data" should
not be sent to application until completion of handshake. The data
we send is not application data and will be consumed by TCP end host
stack until handshake completion.
The Sequence of data packet exchange:
1. The TCP-SMO DH flags will have non-zero value and particular DH
group used by source to generate the ModP value. This is sent as
part of the data in the TCP SYN-Segment.
2. When destination receives this data and generates the ModP value
of the destination and sends back in SYN-ACK segment data portion.
At this point destination can compute the DH shared secret (would be
used during mobility as a symmetric key for authentication
information).
3. SYN-ACK-ACK segment is sent and also source computes the DH
shared secret.
4. TCP data segments exchanged from both side with TCP-SMO.
5. Before this message mobility event happens at source and IP1
changes to IP11.
In this case source sends the data segment with TCP-SMO 'M' bit set
with the 4 byte optional data, which is the checksum of the hash
computed using the DH shared secret with data being the new IP
address.
Optional-data = Checksum (Hash((Source Connection Identifier + Fixed
data normalizer), DH-Shared-Secret)).
Fixed data Normalizer: 0xFEFEFEFEABABABABDEDEDEDE
Length of optional data: first 4 bytes of the checksum.
Hash algorithm to be used is AES-128-CMAC-96.
6. When the above segment arrives with M bit set, destination
computes the checksum of the hash for the new IP address received and
compares the same with the received value of "optional data" in the
TCP-mobility-option. If this matches, it ensures the mobility event
is received indeed from Source and IP11 indicated is correct.
It sends the TCP data segment to the newly received IP address from
Source. This time M bit will be cleared (only used for mobility).
Pithawala & Chunduri Expires January 17, 2018 [Page 8]
Internet-Draft TCP Mobility Option with Identifiers July 2017
4.3. Notifying IP Address Change Event
An IP address change in the local stack MUST be notified to the local
TCP layer. This is to ensure that the local TCP layer can adjust to
IP change and to indicate this change to the destination. There are
2 possibilities of change:
Delete: If any IP address (connected route) is deleted, TCP should
be notified of this change and TCP should find another source IP
address for this existing connection only if sockets that are
bound to the deleted IP address had their Mobility Flag ON.
Modify: If IP address is changes, then both the old and new
address should be updated to local TCP to identify the old
connection and also to enable TCP to find new source IP for that
connection (not necessarily the changed IP, but based on the route
lookup on the destination IP).
Once the above is done to intimate the destination about this change
there are 3 possible option and one of the option has to be fulfilled
by local TCP.
Pending data from application: in this case TCB should use the new
source IP address and send the segment with application data.
Sending a keep-alive: If keep-alive are enabled on the TCP
connection and asynchronous keep-alive can be sent to the
destination with the new IP address.
Sending zero-data segment: if the above 2 are not available, local
TCP stack can send a zero-data segment to the destination with the
new source IP address.
In all 3 cases, the packet is sent with the TCP-SMO as in
Section 4 step 6.
4.4. Buffering the In-flight data
During IP address change local host where the change happened can
have a handshake mechanism with TCP stack and during that time
received data can be buffered. Though this is an implementation
detail and it can be done many ways and this is out of scope for this
document.
Pithawala & Chunduri Expires January 17, 2018 [Page 9]
Internet-Draft TCP Mobility Option with Identifiers July 2017
4.5. TCP-SMO with Unsupported Destination
If a destination does not support the TCP-SMO then it MUST send a
regular SYN-ACK as per [RFC0793]. If SYN-ACK is received without any
TCP-SMO, source falls back to sending SYN segment without any option.
At this point this will be a regular TCP connection and seamless
mobility is not possible for this connection.
5. Unsupported Middleboxes
Any new TCP options are prone to be dropped by middle boxes and this
is generally applies to 5% of TCP connections per [RFC7413] section
7.1. To cater this case, after the initial time out of the SYN with
TCP-SMO, source MUST send SYN segment without this option, thus
resorting to native TCBs and hence not having seamless mobility.
6. Impact of NAT between Source and Destination
This solution does not have any impact of NAT/NAPT devices between
source and destination because:
o TCB uses only Source and destination connection identifiers
o During mobility the authentication data uses stable Source
identifier to verify the hash on both sides (does not include new
IP address or port).
So even in the face NAT/NAPT device with M bit set peer can securely
authenticate the change of IP address.
7. Changes to host TCP Stack and Backward Compatibility
This draft suggests changes to TCP host stack on both ends of the
connection. Main aspect of the change includes how TCB (Transmission
Control Block) as defined in TCP [RFC0793] Section 2.7 can be looked
up and subsequently used. TCB is created when OPEN call is done at
the host stack and it is a data structure which holds the state of
the connection. During connection OPEN time a flag can be indicated
which suggests to use TCP-SMO with additional parameters as required.
It is important to note, if the TCP option proposed in this document
is not present, TCP connection should continue to identify TCB with
connection identifiers as specified in TCP [RFC0793]. So,
implementations supporting this option will have both old way of
identifying the connection/TCB per [RFC0793] and with connection
identifiers in the TCP-SMO. How implementation can be done to have
both these methods is beyond the scope of the document, while one
Pithawala & Chunduri Expires January 17, 2018 [Page 10]
Internet-Draft TCP Mobility Option with Identifiers July 2017
could easily perceive my maintaining two separate TCBs or harmonizing
the keys to access the existing TCB with the proposal here.
When a device or User Equipment (UE) connects to a TCP server, in
majority of the cases TCP server will not change its location but to
support device or UE mobility server TCP stack also MUST be updated
to support this option. One way to mitigate this update at server
side is by using a TCP server proxy where this option is implemented.
8. Relationship with other Identifier Protocols
Proposal made in this document can be seen as a potential Data Plane
alternative to existing Location/Identifier based protocols LISP
[RFC6830] or HIP [RFC7401] with respective protocols control plane.
This option doesn't specify any changes to control plane for existing
identifier based protocols. However, existing Location/Identifier
based protocols will have some restrictions to use the data plane
proposed in this document for example, limitation on the length of
Identifier in TCP-SMO, which is variable and a maximum of 16 bytes.
The mechanism proposed in this document also can be used with new
Identity based common control plane protocol as specified in
[I-D.padma-ideas-problem-statement] and this provides a data plane
solution for applications using TCP transport. UDP based
applications can use mobility solution with QUIC protocol
[I-D.tsvwg-quic-protocol], which allows similar functionality with
respect to mobility.
9. Previous and Related Efforts
There were earlier efforts for TCP Mobility and one of those is
described in [I-D.eddy-tcp-mobility]. Two of the main differences in
this proposal is, how mobility event is notified to the peer (here
no-3-way-handshake) and the security mechanisms during that event
part from others.
Multipath TCP (MPTCP) [RFC6182] [RFC6824] was originally invented to
distribute TCP load across multiple TCP connections but later
mobility has been introduced by deleting the old connection. The
proposal in this draft can be seen as more simpler than the solution
proposed with MPTCP. Some of the other aspects, this proposal can be
seen as different from MPTCP are in the area of performance
[I-D.khalili-mptcp-performance-issues] and the host's ability to have
insight into network topology in order to create multiple paths in
some cases.
Pithawala & Chunduri Expires January 17, 2018 [Page 11]
Internet-Draft TCP Mobility Option with Identifiers July 2017
10. Acknowledgements
TBD.
11. IANA Considerations
As specified in Section 3, this document requests new value for
'kind' assignment from TCP IANA registry.
12. Security Considerations
Mechanisms to protect IP address change event is covered in
Section 4.2. Further security concerns TBD.
13. References
13.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>.
13.2. Informative References
[I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", draft-eddy-tcp-
mobility-00 (work in progress), April 2004.
[I-D.khalili-mptcp-performance-issues]
Khalili, R., Gast, N., Popovic, M., and J. Boudec,
"Performance Issues with MPTCP", draft-khalili-mptcp-
performance-issues-06 (work in progress), July 2014.
[I-D.padma-ideas-problem-statement]
Pillay-Esnault, P., Boucadair, M., Fioccola, G.,
Jacquenet, C., and A. Nennker, "Problem Statement for
Identity Enabled Networks", draft-padma-ideas-problem-
statement-03 (work in progress), July 2017.
Pithawala & Chunduri Expires January 17, 2018 [Page 12]
Internet-Draft TCP Mobility Option with Identifiers July 2017
[I-D.tsvwg-quic-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Secure and Reliable Transport for HTTP/2",
draft-tsvwg-quic-protocol-02 (work in progress), January
2016.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>.
Authors' Addresses
Burjiz Pithawala
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: burjiz.pithawala1@huawei.com
Pithawala & Chunduri Expires January 17, 2018 [Page 13]
Internet-Draft TCP Mobility Option with Identifiers July 2017
Uma Chunduri (editor)
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: uma.chunduri@huawei.com
Pithawala & Chunduri Expires January 17, 2018 [Page 14]
