LISP Generic Protocol ExtensionCisco Systemsdarlewis@cisco.comBroadcom3151 Zanker RoadSan JoseCA95134USAjohn.lemon@broadcom.comInnoviumUSApuneet@acm.orgUSAlkreeger@gmail.comCisco Systemspquinn@cisco.comCisco Systemsmichsmit@cisco.comCisco Systemsnyadav@cisco.comCisco SystemsSan JoseCA95134USAfmaino@cisco.com
General
Internet Engineering Task ForcesecuritypolicyThis draft describes extending the Locator/ID Separation Protocol
(LISP), via changes to the LISP header, to support multi-protocol
encapsulation.LISP, as defined in and extended in , defines an encapsulation format
that carries IPv4 or IPv6 (henceforth referred to as IP) packets in a
LISP header and outer UDP/IP transport.The LISP header does not specify the protocol being encapsulated and
therefore is currently limited to encapsulating only IP packet payloads.
Other protocols, most notably VXLAN (which
defines a similar header format to LISP), are used to encapsulate L2
protocols such as Ethernet.This document defines an extension for the LISP header, as defined in
, to indicate the inner
protocol, enabling the encapsulation of Ethernet, IP or any other
desired protocol all the while ensuring compatibility with existing LISP
deployments.A flag in the LISP header, called the P-bit, is used to signal the
presence of the 8-bit Next Protocol field. The Next Protocol field, when
present, uses 8 bits of the field allocated to the echo-noncing and
map-versioning features. The two features are still available, albeit
with a reduced length of Nonce and Map-Version.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.This document uses terms already defined in .As described in the introduction, the LISP header has no protocol
identifier that indicates the type of payload being carried. Because of
this, LISP is limited to carry IP payloads.The LISP header contains a
series of flags (some defined, some reserved), a Nonce/Map-version field
and an instance ID/Locator-status-bit field. The flags provide
flexibility to define how the various fields are encoded. Notably, Flag
bit 5 is the last reserved bit in the LISP header.This document defines the following changes to the LISP header in
order to support multi-protocol encapsulation:Flag bit 5 is defined as the Next Protocol bit.
The P bit MUST be set to 1 to indicate the presence of the 8 bit
next protocol field.P = 0 indicates that the payload MUST conform to LISP
as defined in . Flag bit 5
was chosen as the P bit because this flag bit is currently
unallocated.The lower 8 bits of the first 32-bit
word are used to carry a Next Protocol. This Next Protocol field
contains the protocol of the encapsulated payload packet.LISP uses the lower 24 bits of the first word for either a nonce,
an echo-nonce, or to support map-versioning . These are all optional capabilities that are
indicated in the LISP header by setting the N, E, and the V bit
respectively.When the P-bit and the N-bit are set to 1, the Nonce field is the
middle 16 bits.When the P-bit and the V-bit are set to 1, the Version field is
the middle 16 bits.When the P-bit is set to 1 and the N-bit and the V-bit are both
0, the middle 16-bits are set to 0.This draft defines the following Next Protocol values:IPv4IPv6EthernetNetwork Service Header Group-Based Policy (GBP) .LISP-GPE uses the same UDP destination port (4341) allocated to
LISP.A LISP-GPE router MUST not encapsulate non-IP packets to a LISP
router. A method for determining the capabilities of a LISP router (GPE
or "legacy") is out of the scope of this draft.When encapsulating IP packets to a LISP "legacy" router the P bit
MUST be set to 0.When a LISP-GPE router performs Ethernet encapsulation, the inner
802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from
the encapsulated frame to the Type of Service field in the outer IPv4
header, or in the case of IPv6 the 'Traffic Class' field.When a LISP-GPE router performs Ethernet encapsulation, the inner
header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or
used to determine the LISP Instance ID field.IANA is requested to set up a registry of LISP-GPE "Next Protocol".
These are 8-bit values. Next Protocol values in the table below are
defined in this draft. New values are assigned via Standards Action
.Next ProtocolDescriptionReference0ReservedThis Document1IPv4This Document2IPv6This Document3EthernetThis Document4NSHThis Document5Reserved6GBPThis Document7Reserved8..255UnassignedLISP-GPE security considerations are similar to the LISP security
considerations documented at length in . With LISP-GPE, issues such as
dataplane spoofing, flooding, and traffic redirection may depend on the
particular protocol payload encapsulated.A special thank you goes to Dino Farinacci for his guidance and
detailed review.