The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-20
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9300.
|
|
---|---|---|---|
Authors | Dino Farinacci , Vince Fuller , David Meyer , Darrel Lewis , Albert Cabellos-Aparicio | ||
Last updated | 2018-09-27 (Latest revision 2018-09-26) | ||
Replaces | draft-farinacci-lisp-rfc6830bis | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
TSVART Telechat review
(of
-19)
by Brian Trammell
Ready w/nits
SECDIR Telechat review
(of
-18)
by Kyle Rose
Has issues
GENART Telechat review
(of
-16)
by Francis Dupont
Ready w/nits
TSVART Last Call review
(of
-15)
by Brian Trammell
Ready w/issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Luigi Iannone | ||
Shepherd write-up | Show Last changed 2018-07-25 | ||
IESG | IESG state | Became RFC 9300 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs a YES. Needs 5 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Deborah Brungard | ||
Send notices to | Luigi Iannone <ggx@gigix.net> | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-lisp-rfc6830bis-20
Network Working Group R. Fajman Request for Comments: 2298 National Institutes of Health Category: Standards Track March 1998 An Extensible Message Format for Message Disposition Notifications Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. Farinacci, et al. Expires March 30, 2019 [Page 6] Internet-Draft LISP September 2018 specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). LISP Site: LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. Negative Mapping Entry: A negative mapping entry, also known as a negative cache entry, is an EID-to-RLOC entry where an EID-Prefix is advertised or stored with no RLOCs. That is, the Locator-Set for the EID-to-RLOC entry is empty or has an encoded Locator count of 0. This type of entry could be used to describe a prefix from a non-LISP site, which is explicitly not in the mapping database. There are a set of well-defined actions that are encoded in a Negative Map-Reply. Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A PETR acts like an ETR but does so on behalf of LISP sites that send packets to destinations at non-LISP sites. Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to remove a LISP header, then acts as an ITR to prepend a new LISP header. This is known as Re-encapsulating Tunneling. Doing this allows a packet to be re-routed by the RTR without adding the overhead of additional tunnel headers. When using multiple Farinacci, et al. Expires March 30, 2019 [Page 7] Internet-Draft LISP September 2018 mapping database systems, care must be taken to not create re- encapsulation loops through misconfiguration. Route-Returnability: Route-returnability is an assumption that the underlying routing system will deliver packets to the destination. When combined with a nonce that is provided by a sender and returned by a receiver, this limits off-path data insertion. A route-returnability check is verified when a message is sent with a nonce, another message is returned with the same nonce, and the destination of the original message appears as the source of the returned message. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to zero or more RLOCs. Typically, RLOCs are numbered from blocks that are assigned to a site at each point to which it attaches to the underlay network; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. TE-ETR: A TE-ETR is an ETR that is deployed in a service provider network that strips an outer LISP header for Traffic Engineering purposes. TE-ITR: A TE-ITR is an ITR that is deployed in a service provider network that prepends an additional LISP header for Traffic Engineering purposes. xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they do today. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change. In LISP terminology, these IP addresses are called Endpoint Identifiers (EIDs). Farinacci, et al. Expires March 30, 2019 [Page 8] Internet-Draft LISP September 2018 Routers continue to forward packets based on IP destination addresses. When a packet is LISP encapsulated, these addresses are referred to as Routing Locators (RLOCs). Most routers along a path between two hosts will not change; they continue to perform routing/ forwarding lookups on the destination addresses. For routers between the source host and the ITR as well as routers from the ETR to the destination host, the destination address is an EID. For the routers between the ITR and the ETR, the destination address is an RLOC. Another key LISP concept is the "Tunnel Router". A Tunnel Router prepends LISP headers on host-originated packets and strips them prior to final delivery to their destination. The IP addresses in this "outer header" are RLOCs. During end-to-end packet exchange between two Internet hosts, an ITR prepends a new LISP header to each packet, and an ETR strips the new header. The ITR performs EID-to- RLOC lookups to determine the routing path to the ETR, which has the RLOC as one of its IP addresses. Some basic rules governing LISP are: o End-systems only send to addresses that are EIDs. EIDs are typically IP addresses assigned to hosts (other types of EID are supported by LISP, see [RFC8060] for further information). End- systems don't know that addresses are EIDs versus RLOCs but assume that packets get to their intended destinations. In a system where LISP is deployed, LISP routers intercept EID-addressed packets and assist in delivering them across the network core where EIDs cannot be routed. The procedure a host uses to send IP packets does not change. o LISP routers mostly deal with Routing Locator addresses. See details in Section 4.1 to clarify what is meant by "mostly". o RLOCs are always IP addresses assigned to routers, preferably topologically oriented addresses from provider CIDR (Classless Inter-Domain Routing) blocks. o When a router originates packets, it MAY use as a source address either an EID or RLOC. When acting as a host (e.g., when terminating a transport session such as Secure SHell (SSH), TELNET, or the Simple Network Management Protocol (SNMP)), it MAY use an EID that is explicitly assigned for that purpose. An EID that identifies the router as a host MUST NOT be used as an RLOC; an EID is only routable within the scope of a site. A typical BGP configuration might demonstrate this "hybrid" EID/RLOC usage where a router could use its "host-like" EID to terminate iBGP sessions to other routers in a site while at the same time using RLOCs to terminate eBGP sessions to routers outside the site. Farinacci, et al. Expires March 30, 2019 [Page 9] Internet-Draft LISP September 2018 o Packets with EIDs in them are not expected to be delivered end-to- end in the absence of an EID-to-RLOC mapping operation. They are expected to be used locally for intra-site communication or to be encapsulated for inter-site communication. o EIDs MAY also be structured (subnetted) in a manner suitable for local routing within an Autonomous System (AS). An additional LISP header MAY be prepended to packets by a TE-ITR when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly connected to the destination host. Another example, perhaps for a VPN service outsourced to an ISP by a site, the ITR could be the site's border router at the service provider attachment point. Mixing and matching of site-operated, ISP-operated, and other Tunnel Routers is allowed for maximum flexibility. 4.1. Packet Flow Sequence This section provides an example of the unicast packet flow, including also Control-Plane information as specified in [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following conditions: o Source host "host1.abc.example.com" is sending a packet to "host2.xyz.example.com", exactly what host1 would do if the site was not using LISP. Farinacci, et al. Expires March 30, 2019 [Page 10] Internet-Draft LISP September 2018Fajman Standards Track [Page 1] RFC 2298 Message Disposition Notifications March 1998 Table of Contents 1. Introduction ............................................ 2 2. Requesting Message Disposition Notifications ............ 3 3. Format of a Message Disposition Notification ............ 7 4. Timeline of events ...................................... 17 5. Conformance and Usage Requirements ...................... 18 6. Security Considerations ................................. 19 7. Collected Grammar ....................................... 20 8. Guidelines for Gatewaying MDNs .......................... 22 9. Example ................................................. 24 10. IANA Registration Forms ................................. 25 11. Acknowledgments ......................................... 26 12. References .............................................. 26 13. Author's Address ........................................ 27 14. Copyright ............................................... 28 1. Introduction This memo defines a MIME content-type [5] for message disposition notifications (MDNs). An MDN can be used to notify the sender of a message of any of several conditions that may occur after successful delivery, such as display of the message contents, printing of the message, deletion (without display) of the message, or the recipient's refusal to provide MDNs. The "message/disposition- notification" content-type defined herein is intended for use within the framework of the "multipart/report" content type defined in RFC 1892 [7]. This memo defines the format of the notifications and the RFC 822 headers used to request them. 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. 1.1 Purposes The MDNs defined in this memo are expected to serve several purposes: (a) Inform human beings of the disposition of messages after succcessful delivery, in a manner which is largely independent of human language; (b) Allow mail user agents to keep track of the disposition of messages sent, by associating returned MDNs with earlier message transmissions; Fajman Standards Track [Page 2] RFC 2298 Message Disposition Notifications March 1998 (c) Convey disposition notification requests and disposition notifications between Internet Mail and "foreign" mail systems via a gateway; (d) Allow "foreign" notifications to be tunneled through a MIME- capable message system and back into the original messaging system that issued the original notification, or even to a third messaging system; (e) Allow language-independent, yet reasonably precise, indications of the disposition of a message to be delivered. 1.2 Requirements These purposes place the following constraints on the notification protocol: (a) It must be readable by humans, as well as being machine- parsable. (b) It must provide enough information to allow message senders (or their user agents) to unambiguously associate an MDN with the message that was sent and the original recipient address for which the MDN is issued (if such information is available), even if the message was forwarded to another recipient address. (c) It must also be able to describe the disposition of a message independent of any particular human language or of the terminology of any particular mail system. (d) The specification must be extensible in order to accomodate future requirements. 2. Requesting Message Disposition Notifications Message disposition notifications are requested by including a Disposition-Notification-To header in the message. Further information to be used by the recipient's UA in generating the MDN may be provided by including Original-Recipient and/or Disposition- Notification-Options headers in the message. 2.1 The Disposition-Notification-To Header A request that the receiving user agent issue message disposition notifications is made by placing a Disposition-Notification-To header into the message. The syntax of the header, using the ABNF of RFC 822 [2], is Fajman Standards Track [Page 3] RFC 2298 Message Disposition Notifications March 1998 mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox The mailbox token is as specified in RFC 822 [2]. The presence of a Disposition-Notification-To header in a message is merely a request for an MDN. The recipients' user agents are always free to silently ignore such a request. Alternatively, an explicit denial of the request for information about the disposition of the message may be sent using the "denied" disposition in an MDN. An MDN MUST NOT itself have a Disposition-Notification-To header. An MDN MUST NOT be generated in response to an MDN. At most one MDN may be issued on behalf of each particular recipient by their user agent. That is, once an MDN has been issued on behalf of a recipient, no further MDNs may be issued on behalf of that recipient, even if another disposition is performed on the message. However, if a message is forwarded, an MDN may been issued for the recipient doing the forwarding and the recipient of the forwarded message may also cause an MDN to be generated. While Internet standards normally do not specify the behavior of user interfaces, it is strongly recommended that the user agent obtain the user's consent before sending an MDN. This consent could be obtained for each message through some sort of prompt or dialog box, or globally through the user's setting of a preference. The user might also indicate globally that MDNs are never to be sent or that a "denied" MDN is always sent in response to a request for an MDN. MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header differs from the address in the Return-Path header (see RFC 822 [2]). In this case, confirmation from the user SHOULD be obtained, if possible. If obtaining consent is not possible (e.g., because the user is not online at the time), then an MDN SHOULD NOT be sent. Confirmation from the user SHOULD be obtained (or no MDN sent) if there is no Return-Path header in the message, or if there is more than one distinct address in the Disposition-Notification-To header. The comparison of the addresses should be done using only the addr- spec (local-part "@" domain) portion, excluding any phrase and route. The comparison MUST be case-sensitive for the local-part and case- insensitive for the domain part. If the message contains more than one Return-Path header, the implementation may pick one to use for the comparison, or treat the situation as a failure of the comparison. Fajman Standards Track [Page 4] RFC 2298 Message Disposition Notifications March 1998 The reason for not automatically sending an MDN if the comparison fails or more than one address is specified is to reduce the possibilities for mail loops and use of MDNs for mail bombing. A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header as specified in RFC 822 [2]. This will permit automatic correlation of MDNs with original messages by user agents. If it is desired to request message disposition notifications for some recipients and not others, two copies of the message should be sent, one with an Disposition-Notification-To header and one without. Many of the other headers of the message (e.g., To, cc) will be the same in both copies. The recipients in the respective message envelopes determine for whom message disposition notifications are requested and for whom they are not. If desired, the Message-ID header may be the same in both copies of the message. Note that there are other situations (e.g., bcc) in which it is necessary to send multiple copies of a message with slightly different headers. The combination of such situations and the need to request MDNs for a subset of all recipients may result in more than two copies of a message being sent, some with a Disposition- Notification-To header and some without. Messages posted to newsgroups SHOULD NOT have a Disposition- Notification-To header. 2.2 The Disposition-Notification-Options Header Future extensions to this specification may require that information be supplied to the recipient's UA for additional control over how and what MDNs are generated. The Disposition-Notification-Options header provides an extensible mechanism for such information. The syntax of this header, using the ABNF of RFC 822 [2], is Disposition-Notification-Options = "Disposition-Notification-Options" ":" disposition-notification-parameters disposition-notification-parameters = parameter *(";" parameter) parameter = attribute "=" importance "," 1#value importance = "required" / "optional" The definitions of attribute and value are as in the definition of the Content-Type header in RFC 2045 [4]. Fajman Standards Track [Page 5] RFC 2298 Message Disposition Notifications March 1998 An importance of "required" indicates that interpretation of the parameter is necessary for proper generation of an MDN in response to this request. If a UA does not understand the meaning of the parameter, it MUST NOT generate an MDN with any disposition type other than "failed" in response to the request. An importance of "optional" indicates that a UA that does not understand the meaning of this parameter MAY generate an MDN in response anyway, ignoring the value of the parameter. No parameters are defined in this specification. Parameters may be defined in the future by later revisions or extensions to this specification. Parameter attribute names beginning with "X-" will never be defined as standard names; such names are reserved for experimental use. MDN parameter names not beginning with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. See Section 10 for a registration form. If a required parameter is not understood or contains some sort of error, the receiving UA SHOULD issue an MDN with a disposition type of "failed" (see Section 3.2.6) and include a Failure field (see Section 3.2.7) that further describes the problem. MDNs with the a disposition type of "failed" and a "Failure" field MAY also be generated when other types of errors are detected in the parameters of the Disposition-Notification-Options header. However, an MDN with a disposition type of "failed" MUST NOT be generated if the user has indicated a preferance that MDNs are not to be sent. If user consent would be required for an MDN of some other disposition type to be sent, user consent SHOULD also be obtained before sending an MDN with a disposition type of "failed". 2.3 The Original-Recipient Header Since electronic mail addresses may be rewritten while the message is in transit, it is useful for the original recipient address to be made available by the delivering MTA. The delivering MTA may be able to obtain this information from the ORCPT parameter of the SMTP RCPT TO command, as defined in RFC 1891 [8]. If this information is available, the delivering MTA SHOULD insert an Original-Recipient header at the beginning of the message (along with the Return-Path header). The delivering MTA MAY delete any other Original-Recipient headers that occur in the message. The syntax of this header, using the ABNF of RFC 822 [2], is as follows original-recipient-header = "Original-Recipient" ":" address-type ";" generic-address Fajman Standards Track [Page 6] RFC 2298 Message Disposition Notifications March 1998 The address-type and generic-address token are as as specified in the description of the Original-Recipient field in section 3.2.3. The purpose of carrying the original recipient information and returning it in the MDN is to permit automatic correlation of MDNs with the original message on a per-recipient basis. 2.4 Use with the Message/Partial Content Type The use of the headers Disposition-Notification-To, Disposition- Notification-Options, and Original-Recipient with the MIME Message/partial content type (RFC 2046 [5]) requires further definition. When a message is segmented into two or more message/partial fragments, the three headers mentioned in the above paragraph SHOULD be placed in the "inner" or "enclosed" message (using the terms of RFC 2046 [5]). These headers SHOULD NOT be used in the headers of any of the fragments themselves. When the multiple message/partial fragments are reassembled, the following applies. If these headers occur along with the other headers of a message/partial fragment message, they pertain to an MDN to be generated for the fragment. If these headers occur in the headers of the "inner" or "enclosed" message (using the terms of RFC 2046 [5]), they pertain to an MDN to be generated for the reassembled message. Section 5.2.2.1 of RFC 2046 [5]) is amended to specify that, in addition to the headers specified there, the three headers described in this specification are to be appended, in order, to the headers of the reassembled message. Any occurances of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message. 3. Format of a Message Disposition Notification A message disposition notification is a MIME message with a top- level content-type of multipart/report (defined in RFC 1892 [7]). When a multipart/report content is used to transmit an MDN: (a) The report-type parameter of the multipart/report content is "disposition-notification". (b) The first component of the multipart/report contains a human- readable explanation of the MDN, as described in RFC 1892 [7]. (c) The second component of the multipart/report is of content-type message/disposition-notification, described in section 3.1 of this document. Fajman Standards Track [Page 7] RFC 2298 Message Disposition Notifications March 1998 (d) If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. The decision of whether or not to return the message or part of the message is up to the UA generating the MDN. However, in the case of encrypted messages requesting MDNs, encrypted message text MUST be returned, if it is returned at all, only in its original encrypted form. NOTE: For message dispostion notifications gatewayed from foreign systems, the headers of the original message may not be available. In this case the third component of the MDN may be omitted, or it may contain "simulated" RFC 822 headers which contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message. The MDN MUST be addressed (in both the message header and the transport envelope) to the address(es) from the Disposition- Notification-To header from the original message for which the MDN is being generated. The From field of the message header of the MDN MUST contain the address of the person for whom the message disposition notification is being issued. The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<& o Each site is multihomed, so each Tunnel Router has an address (RLOC) assigned from the service provider address block for each provider to which that particular Tunnel Router is attached. o The ITR(s) and ETR(s) are directly connected to the source and destination, respectively, but the source and destination can be located anywhere in the LISP site. o A Map-Request is sent for an external destination when the destination is not found in the forwarding table or matches a default route. Map-Requests are sent to the mapping database system by using the LISP Control-Plane protocol documented in [I-D.ietf-lisp-rfc6833bis]. o Map-Replies are sent on the underlying routing system topology using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. Client host1.abc.example.com wants to communicate with server host2.xyz.example.com: 1. host1.abc.example.com wants to open a TCP connection to host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of host1.abc.example.com is used as the source EID. An IPv4 or IPv6 packet is built and forwarded through the LISP site as a normal IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC of one of the ETRs at the destination site. The specific method used to do this is not described in this example. See [I-D.ietf-lisp-rfc6833bis] for further information. 3. The ITR sends a LISP Map-Request as specified in [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 4. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. 5. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- RLOC mapping database. This is the list of EID-Prefixes the ETR is supporting for the site it resides in. If there is no match, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. Farinacci, et al. Expires March 30, 2019 [Page 11] Internet-Draft LISP September 2018 6. The ITR receives the Map-Reply message, parses the message (to check for format validity), and stores the mapping information from the packet. This information is stored in the ITR's EID-to- RLOC Map-Cache. Note that the Map-Cache is an on-demand cache. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints. 7. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination address learned from the ETR. Note that the packet MAY be sent to a different ETR than the one that returned the Map-Reply due to the source site's hashing policy or the destination site's Locator-Set policy. 8. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. 9. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map- Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet is dropped and an ICMP Unreachable/Fragmentation-Needed message is returned to the source. In the case when fragmentation is needed, this specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header Farinacci, et al. Expires March 30, 2019 [Page 12] Internet-Draft LISP September 2018 is in IPv6 packet format and the outer header is in IPv4 packet format). The next sub-sections illustrate packet formats for the homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 combinations MUST be supported. Additional types of EIDs are defined in [RFC8060]. As LISP uses UDP encapsulation to carry traffic between xTRs across the Internet, implementors should be aware of the provisions of [RFC8085], especially those given in section 3.1.11 on congestion control for UDP tunneling. Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. 5.1. LISP IPv4-in-IPv4 Header Format Farinacci, et al. Expires March 30, 2019 [Page 13] Internet-Draft LISP September 2018 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OH | Time to Live | Protocol = 17 | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source Routing Locator | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination Routing Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4341 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| IHL | DSCP |ECN| Total Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Identification |Flags| Fragment Offset | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IH | Time to Live | Protocol | Header Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source EID | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IHL = IP-Header-Length 5.2. LISP IPv6-in-IPv6 Header Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | Next Header=17| Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | O + + u | | t + Source Routing Locator + e | | Farinacci, et al. Expires March 30, 2019 [Page 14] Internet-Draft LISP September 2018 r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination Routing Locator + | | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4341 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L |N|L|E|V|I|R|K|K| Nonce/Map-Version | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | Instance ID/Locator-Status-Bits | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / |Version| DSCP |ECN| Flow Label | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Payload Length | Next Header | Hop Limit | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | I + + n | | n + Source EID + e | | r + + | | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | r + + | | ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host [RFC0791] [RFC8200] [RFC2474]. The source and destination IP addresses are EIDs. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress Farinacci, et al. Expires March 30, 2019 [Page 15] Internet-Draft LISP September 2018 router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash algorithm used to select a source port based on the 5-tuple of the inner header. The destination port MUST be set to the well-known IANA-assigned port value 4341. UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP zero checksums over IPv6 for all tunneling protocols, including LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header contain a Nonce. See Section 10.1 for details. Both N- and V-bits MUST NOT be set in the same packet. If they are, a decapsulating ETR MUST treat the 'Nonce/Map-Version' field as having a Nonce value present. L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When this bit is set to 1, the Locator-Status-Bits in the second 32 bits of the LISP header are in use. Farinacci, et al. Expires March 30, 2019 [Page 16] Internet-Draft LISP September 2018 x 1 x x 0 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to 1, the N-bit MUST be 0. Refer to Section 13.1 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I: The I-bit is the Instance ID bit. See Section 8 for more details. When this bit is set to 1, the 'Locator-Status-Bits' field is reduced to 8 bits and the high-order 24 bits are used as an Instance ID. If the L-bit is set to 0, then the low-order 8 bits are transmitted as zero and ignored on receipt. The format of the LISP header would look like this: x x x x 1 x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | LSBs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R: The R-bit is a Reserved bit for future use. It MUST be set to 0 on transmit and MUST be ignored on receipt. KK: The KK-bits are a 2-bit field used when encapsulated packets are encrypted. The field is set to 00 when the packet is not encrypted. See [RFC8061] for further information. Farinacci, et al. Expires March 30, 2019 [Page 17] Internet-Draft LISP September 2018 LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is randomly generated by an ITR when the N-bit is set to 1. Nonce generation algorithms are an implementation matter but are required to generate different nonces when sending to different RLOCs. However, the same nonce can be used for a period of time when encapsulating to the same ETR. The nonce is also used when the E-bit is set to request the nonce value to be echoed by the other side when packets are returned. When the E-bit is clear but the N-bit is set, a remote ITR is either echoing a previously requested echo-nonce or providing a random nonce. See Section 10.1 for more details. LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 'Locator-Status-Bits' field in the LISP header is set by an ITR to indicate to an ETR the up/down status of the Locators in the source site. Each RLOC in a Map-Reply is assigned an ordinal value from 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator-Status-Bits are numbered from 0 to n-1 from the least significant bit of the field. The field is 32 bits when the I-bit is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix that the inner-header source EID address matches. If the LSB for an anycast Locator is set to 1, then there is at least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: o The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field. o The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) to the outer-header. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit Farinacci, et al. Expires March 30, 2019 [Page 18] Internet-Draft LISP September 2018 'ECN' field from the stripped outer header to the new outer header. When doing ETR/PETR decapsulation: o The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live>), specifying that no Delivery Status Notification messages or other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN. A message disposition notification MUST NOT itself request an MDN. That is, it MUST NOT contain a Disposition-Notification-To header. The Message-ID header (if present) for an MDN MUST be different from the Message-ID of the message for which the MDN is being issued. A particular MDN describes the disposition of exactly one message for exactly one recipient. Multiple MDNs may be generated as a result of one message submission, one per recipient. However, due to the circumstances described in Section 2.1, MDNs may not be generated for some recipients for which MDNs were requested. 3.1 The message/disposition-notification content-type The message/disposition-notification content-type is defined as follows: MIME type name: message Fajman Standards Track [Page 8] RFC 2298 Message Disposition Notifications March 1998 MIME subtype name: disposition-notification Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. Security considerations: discussed in section 6 of this memo. The message/disposition-notification report type for use in the multipart/report is "disposition-notification". The body of a message/disposition-notification consists of one or more "fields" formatted according to the ABNF of RFC 822 header "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the message/disposition-notification content is as follows: disposition-notification-content = [ reporting-ua-field CRLF ] [ mdn-gateway-field CRLF ] [ original-recipient-field CRLF ] final-recipient-field CRLF [ original-message-id-field CRLF ] disposition-field CRLF *( failure-field CRLF ) *( error-field CRLF ) *( warning-field CRLF ) *( extension-field CRLF ) 3.1.1 General conventions for fields Since these fields are defined according to the rules of RFC 822 [2], the same conventions for continuation lines and comments apply. Notification fields may be continued onto multiple lines by beginning each additional line with a SPACE or HTAB. Text which appears in parentheses is considered a comment and not part of the contents of that notification field. Field names are case-insensitive, so the names of notification fields may be spelled in any combination of upper and lower case letters. Comments in notification fields may use the "encoded-word" construct defined in RFC 2047 [6]. 3.1.2 "*-type" subfields Several fields consist of a "-type" subfield, followed by a semi- colon, followed by "*text". For these fields, the keyword used in the address-type or MTA-type subfield indicates the expected format of the address or MTA-name that follows. The "-type" subfields are defined as follows: Fajman Standards Track [Page 9] RFC 2298 Message Disposition Notifications March 1998 (a) An "address-type" specifies the format of a mailbox address. For example, Internet Mail addresses use the "rfc822" address- type. address-type = atom (b) An "MTA-name-type" specifies the format of a mail transfer agent name. For example, for an SMTP server on an Internet host, the MTA name is the domain name of that host, and the "dns" MTA-name-type is used. mta-name-type = atom Values for address-type and mta-name-type are case-insensitive. Thus address-type values of "RFC822" and "rfc822" are equivalent. The Internet Assigned Numbers Authority (IANA) will maintain a registry of address-type and mta-name-type values, along with descriptions of the meanings of each, or a reference to a one or more specifications that provide such descriptions. (The "rfc822" address-type is defined in RFC 1891 [8].) Registration forms for address-type and mta-name-type appear in RFC 1894 [9]. IANA will not accept registrations for any address-type name that begins with "X-". These type names are reserved for experimental use. 3.1.3 Lexical tokens imported from RFC 822 The following lexical tokens, defined in RFC 822 [2], are used in the ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text. 3.2 Message/disposition-notification Fields 3.2.1 The Reporting-UA field reporting-ua-field = "Reporting-UA" ":" ua-name [ ";" ua-product ] ua-name = *text ua-product = *text The Reporting-UA field is defined as follows: A MDN describes the disposition of a message after it has been delivered to a recipient. In all cases, the Reporting-UA is the UA that performed the disposition described in the MDN. This field is Fajman Standards Track [Page 10] RFC 2298 Message Disposition Notifications March 1998 optional, but recommended. For Internet Mail user agents, it is recommended that this field contain both the DNS name of the particular instance of the UA that generated the MDN and the name of the product. For example, Reporting-UA: rogers-mac.dcrt.nih.gov; Foomail 97.1 If the reporting UA consists of more than one component (e.g., a base program and plug-ins), this may be indicated by including a list of product names. 3.2.2 The MDN-Gateway field The MDN-Gateway field indicates the name of the gateway or MTA that translated a foreign (non-Internet) message disposition notification into this MDN. This field MUST appear in any MDN which was translated by a gateway from a foreign system into MDN format, and MUST NOT appear otherwise. mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name mta-name = *text For gateways into Internet Mail, the MTA-name-type will normally be "smtp", and the mta-name will be the Internet domain name of the gateway. 3.2.3 Original-Recipient field The Original-Recipient field indicates the original recipient address as specified by the sender of the message for which the MDN is being issued. For Internet Mail messages the value of the Original-Recipient field is obtained from the Original-Recipient header from the message for which the MDN is being generated. If there is no Original-Recipient header in the message, then the Original-Recipient field MUST be omitted, unless the same information is reliably available some other way. If there is an Original- Recipient header in the original message (or original recipient information is reliably available some other way), then the Original-Recipient field must be supplied. If there is more than one Original-Recipient header in the message, the UA may choose the one to use or act as if no Original-Recipient header is present. original-recipient-field = "Original-Recipient" ":" address-type ";" generic-address generic-address = *text Fajman Standards Track [Page 11] RFC 2298 Message Disposition Notifications March 1998 The address-type field indicates the type of the original recipient address. If the message originated within the Internet, the address-type field field will normally be "rfc822", and the address will be according to the syntax specified in RFC 822 [2]. The value "unknown" should be used if the Reporting UA cannot determine the type of the original recipient address from the message envelope. This address is the same as that provided by the sender and can be used to automatically correlate MDN reports with original messages on a per recipient basis. 3.2.4 Final-Recipient field The Final-Recipient field indicates the recipient for which the MDN is being issued. This field MUST be present. The syntax of the field is as follows: final-recipient-field = "Final-Recipient" ":" address-type ";" generic-address The generic-address subfield of the Final-Recipient field MUST contain the mailbox address of the recipient (from the From header of the MDN) as it was when the MDN was generated by the UA. The Final-Recipient address may differ from the address originally provided by the sender, because it may have been transformed during forwarding and gatewaying into an totally unrecognizable mess. However, in the absence of the optional Original-Recipient field, the Final-Recipient field and any returned content may be the only information available with which to correlate the MDN with a particular message recipient. The address-type subfield indicates the type of address expected by the reporting MTA in that context. Recipient addresses obtained via SMTP will normally be of address-type ' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header. Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles. This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site. o The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) to the inner-header. o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC6040]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. Implementations exist that copy the 'ECN' field from the outer header to the inner header even though [RFC6040] does not recommend this behavior. It is RECOMMENDED that implementations change to support the behavior in [RFC6040]. Note that if an ETR/PETR is also an ITR/PITR and chooses to re- encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration. The Explicit Congestion Notification ('ECN') field occupies bits 6 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic Class' field [RFC6040]. The 'ECN' field requires special treatment Farinacci, et al. Expires March 30, 2019 [Page 19] Internet-Draft LISP September 2018 in order to avoid discarding indications of congestion [RFC6040]. An ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR/ PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR. These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. When an ITR/PITR receives a packet from inside of the LISP site to destinations outside of the site a longest-prefix match lookup of the EID is done to the Map-Cache. When the lookup succeeds, the Locator-Set retrieved from the Map- Cache is used to send the packet to the EID's topological location. If the lookup fails, the ITR/PITR needs to retrieve the mapping using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. The mapping is then stored in the local Map-Cache to forward subsequent packets addressed to the same EID-prefix. The Map-Cache is a local cache of mappings, entries are expired based on the associated Time to live. In addition, entries can be updated with more current information, see Section 13 for further information on this. Finally, the Map-Cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets This section proposes two mechanisms to deal with packets that exceed the path MTU between the ITR and ETR. It is left to the implementor to decide if the stateless or stateful mechanism SHOULD be implemented. Both or neither can be used, since Farinacci, et al. Expires March 30, 2019 [Page 20] Internet-Draft LISP September 2018 it is a local decision in the ITR regarding how to deal with MTU issues, and sites can interoperate with differing mechanisms. Both stateless and stateful mechanisms also apply to Re-encapsulating and Recursive Tunneling, so any actions below referring to an ITR also apply to a TE-ITR. 7.1. A Stateless Solution to MTU Handling An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any intermediate routers to fragment the packet. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L = S + H. When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then prepended to each fragment. The size of the encapsulated fragments is then (S/2 + H), which is less than the ITR's estimate of the path MTU between the ITR and its correspondent ETR. When an ETR receives encapsulated fragments, it treats them as two individually encapsulated packets. It strips the LISP headers and then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior MAY be performed by the ITR only when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet when the size is greater than L and send an ICMP Unreachable/ Fragmentation-Needed message to the source with a value of S, where S is (L - H). Farinacci, et al. Expires March 30, 2019 [Page 21] Internet-Draft LISP September 2018 When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ Fragmentation-Needed to the ITR, respectively. The ITR will parse the ICMP message to determine which Locator is affected by the effective MTU change and then record the new effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination EID the packet is for, the ITR will send an ICMPv4 ICMP Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" message back to the source. The packet size advertised by the ITR in the ICMP message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP There are several cases where segregation is needed at the EID level. For instance, this is the case for deployments containing overlapping addresses, traffic isolation policies or multi-tenant virtualization. For these and other scenarios where segregation is needed, Instance IDs are used. Farinacci, et al. Expires March 30, 2019 [Page 22] Internet-Draft LISP September 2018 An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. The Instance ID that is stored in the mapping database when LISP-DDT [RFC8111] is used is 32 bits in length. That means the Control-Plane can store more instances than a given Data-Plane can use. Multiple Data-Planes can use the same 32-bit space as long as the low-order 24 bits don't overlap among xTRs. 9. Routing Locator Selection The Map-Cache contains the state used by ITRs and PITRs to encapsulate packets. When an ITR/PITR receives a packet from inside the LISP site to a destination outside of the site a longest-prefix match lookup of the EID is done to the Map-Cache (see Section 6). The lookup returns a single Locator-Set containing a list of RLOCs corresponding to the EID's topological location. Each RLOC in the Locator-Set is associated with a 'Priority' and 'Weight', this information is used to select the RLOC to encapsulate. The RLOC with the lowest 'Priority' is selected. An RLOC with 'Priority' 255 means that MUST NOT be used for forwarding. When multiple RLOC have the same 'Priority' then the 'Weight' states how to load balance traffic among them. The value of the 'Weight' represents the relative weight of the total packets that match the maping entry. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In this case, the server-side controls both the subset list and load- Farinacci, et al. Expires March 30, 2019 [Page 23] Internet-Draft LISP September 2018 splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the list are unreachable. o The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. Control is shared by the server- side determining the list and the client-side determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. o Either side (more likely the server-side ETR) decides not to send a Map-Request. For example, if the server-side ETR does not send Map-Requests, it gleans RLOCs from the client-side ITR, giving the client-side ITR responsibility for bidirectional RLOC reachability and preferability. Server-side ETR gleaning of the client-side ITR RLOC is done by caching the inner-header source EID and the outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. Alternatively, RLOC information MAY be gleaned from received tunneled packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache entry, one learned from the source RLOC of a received encapsulated packet, is only stored and used for a few seconds, pending verification. Verification is performed by sending a Map-Request to the source EID (the inner-header IP source address) of the received encapsulated packet. A reply to this "verifying Map-Request" is used to fully populate the Map-Cache entry for the "gleaned" EID and is stored and used for the time indicated from the 'TTL' field of a received Map-Reply. When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches the EID-Prefix of the verified entry. This "gleaning" mechanism is OPTIONAL, refer to Section 16 for security issues regarding this mechanism. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit for the Locator record is set to 1. When Farinacci, et al. Expires March 30, 2019 [Page 24] Internet-Draft LISP September 2018 the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. 10. Routing Locator Reachability Several Data-Plane mechanisms for determining RLOC reachability are currently defined. Please note that additional Control-Plane based reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. 2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability algorithms described in this section. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. When ITRs at the site are not deployed in CE routers, the IGP can still be used to determine the reachability of Locators, provided they are injected into the IGP. This is typically done when a /32 address is configured on a loopback interface. Farinacci, et al. Expires March 30, 2019 [Page 25] Internet-Draft LISP September 2018 RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. Refer to Section 16 for security related issues regarding Locator-Status-Bits. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. In most cases, the ETR can also reach the ITR but cannot assume this to be true, due to the possibility of path asymmetry. In the presence of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT use the lack of return traffic as an indication that the ETR is unreachable. Instead, it MUST use an alternate mechanism to determine reachability. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a Data-Plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. Farinacci, et al. Expires March 30, 2019 [Page 26] Internet-Draft LISP September 2018 If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision MAY be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data header. It is recognized that there are no simple solutions to the site partitioning problem because it is hard to know which part of the EID-Prefix range is partitioned and which Locators can reach any sub- ranges of the EID-Prefixes. Note that this is not a new problem Farinacci, et al. Expires March 30, 2019 [Page 27] Internet-Draft LISP September 2018 introduced by the LISP architecture. The problem exists today when a multihomed site uses BGP to advertise its reachability upstream. 12. Routing Locator Hashing When an ETR provides an EID-to-RLOC mapping in a Map-Reply message that is stored in the Map-Cache of a requesting ITR, the Locator-Set for the EID-Prefix MAY contain different Priority and Weight values for each locator address. When more than one best Priority Locator exists, the ITR can decide how to load-share traffic against the corresponding Locators. The following hash algorithm MAY be used by an ITR to select a Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1. Either a source and destination address hash or the traditional 5-tuple hash can be used. The traditional 5-tuple hash includes the source and destination addresses; source and destination TCP, UDP, or Stream Control Transmission Protocol (SCTP) port numbers; and the IP protocol number field or IPv6 next-protocol fields of a packet that a host originates from within a LISP site. When a packet is not a TCP, UDP, or SCTP packet, the source and destination addresses only from the header are used to compute the hash. 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. Note that when a packet is LISP encapsulated, the source port number in the outer UDP header needs to be set. Selecting a hashed value allows core routers that are attached to Link Aggregation Groups (LAGs) to load-split the encapsulated packets across member links of such LAGs. Otherwise, core routers would see a single flow, since packets have a source address of the ITR, for packets that are originated by different EIDs at the source site. A suggested setting for the source port number computed by an ITR is a 5-tuple hash function on the inner header, as described above. The source port SHOULD be the same for all packets belonging to the same flow. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet Farinacci, et al. Expires March 30, 2019 [Page 28] Internet-Draft LISP September 2018 is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. This section defines a Data-Plane mechanism for updating EID-to-RLOC mappings. Additionally, the Solicit-Map Request (SMR) Control-Plane updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to maintain lexicographic order, SMR procedure [I-D.ietf-lisp-rfc6833bis] is used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be Farinacci, et al. Expires March 30, 2019 [Page 29] Internet-Draft LISP September 2018 useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. We propose here a Data-Plane mechanism (Map-Versioning specified in [I-D.ietf-lisp-6834bis]) to update the contents of EID-to-RLOC mappings. Please note that in addition the Solicit-Map Request (specified in [I-D.ietf-lisp-rfc6833bis]) is a Control-Plane mechanisms that can be used to update EID-to-RLOC mappings. 13.1. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in [I-D.ietf-lisp-rfc6833bis] occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. See [I-D.ietf-lisp-6834bis] for a more detailed analysis and description of Database Map-Versioning. Farinacci, et al. Expires March 30, 2019 [Page 30] Internet-Draft LISP September 2018 14. Multicast Considerations A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends its own IP address as the source address of the outer IP header. Just like it would if the destination EID was a unicast address. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [RFC8378], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. 15. Router Performance Considerations LISP is designed to be very "hardware-based forwarding friendly". A few implementation techniques can be used to incrementally implement LISP: o When a tunnel-encapsulated packet is received by an ETR, the outer destination address may not be the address of the router. This makes it challenging for the control plane to get packets from the hardware. This may be mitigated by creating special Forwarding Information Base (FIB) entries for the EID-Prefixes of EIDs served by the ETR (those for which the router provides an RLOC translation). These FIB entries are marked with a flag indicating that Control-Plane processing SHOULD be performed. The forwarding Farinacci, et al. Expires March 30, 2019 [Page 31] Internet-Draft LISP September 2018 logic of testing for particular IP protocol number values is not necessary. There are a few proven cases where no changes to existing deployed hardware were needed to support the LISP Data- Plane. o On an ITR, prepending a new IP header consists of adding more octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. o A packet's source address or interface the packet was received on can be used to select VRF (Virtual Routing/Forwarding). The VRF's routing table can be used to find EID-to-RLOC mappings. For performance issues related to Map-Cache management, see Section 16. 16. Security Considerations A complete LISP threat analysis can be found in [RFC7835] in what follows we provide a summary when LISP is deployed in non-trustable environments. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping into its Map-Cache. An off-path attacker can spoof the source EID address to divert the traffic sent to the victim's spoofed EID. If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim's RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC Data- Plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC of a victim's xTR can manipulate such mechanisms to declare a set of RLOCs unreachable. This can be used also, for instance, to declare only one RLOC reachable with the aim of overload it. Map-Versioning is a Data-Plane mechanism used to signal a peering xTR that a local EID-to-RLOC mapping has been updated, so that the peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- Farinacci, et al. Expires March 30, 2019 [Page 32] Internet-Draft LISP September 2018 versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Most of the attack vectors can be mitigated with careful deployment and configuration, information learned opportunistically (such as LSB or gleaning) SHOULD be verified with other reachability mechanisms. In addition, systematic rate-limitation and filtering is an effective technique to mitigate attacks that aim to overload the Control-Plane. 17. Network Management Considerations Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. 18. Changes since RFC 6830 For implementation considerations, the following changes have been made to this document since RFC 6830 was published: o It is no longer mandated that a maximum number of 2 LISP headers be prepended to a packet. If there is a application need for more than 2 LISP headers, an implementation can support more. However, it is RECOMMENDED that a maximum of two LISP headers can be prepended to a packet. o The 3 reserved flag bits in the LISP header have been allocated for [RFC8061]. The low-order 2 bits of the 3-bit field (now named the KK bits) are used as a key identifier. The 1 remaining bit is still documented as reserved. o Data-Plane gleaning for creating map-cache entries has been made optional. If any ITR implementations depend or assume the remote ETR is gleaning should not do so. This does not create any interoperability problems since the control-plane map-cache population procedures are unilateral and are the typical method for map-cache population. o The bulk of the changes to this document which reduces its length are due to moving the LISP control-plane messaging and procedures to [I-D.ietf-lisp-rfc6833bis]. 19. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this Data-Plane LISP specification, in accordance with BCP 26 [RFC8126]. Farinacci, et al. Expires March 30, 2019 [Page 33] Internet-Draft LISP September 2018 19.1. LISP UDP Port Numbers The IANA registry has allocated UDP port number 4341 for the LISP Data-Plane. IANA has updated the description for UDP port 4341 as follows: lisp-data 4341 udp LISP Data Packets 20. References 20.1. Normative References [I-D.ietf-lisp-6834bis] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", draft-ietf- lisp-6834bis-02 (work in progress), September 2018. [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-15 (work in progress), September 2018. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>. Farinacci, et al. Expires March 30, 2019 [Page 34] Internet-Draft LISP September 2018 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. 20.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, <http://www.iana.org/assignments/address-family-numbers>. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in progress), May 2018. [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", Work in Progress, July 2008. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>. Farinacci, et al. Expires March 30, 2019 [Page 35] Internet-Draft LISP September 2018 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>. [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, <https://www.rfc-editor.org/info/rfc3232>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>. [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>. Farinacci, et al. Expires March 30, 2019 [Page 36] Internet-Draft LISP September 2018 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>. [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>. [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>. [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, <https://www.rfc-editor.org/info/rfc7833>. [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>. [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>. [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>. [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>. Farinacci, et al. Expires March 30, 2019 [Page 37] Internet-Draft LISP September 2018 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>. [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>. Farinacci, et al. Expires March 30, 2019 [Page 38] Internet-Draft LISP September 2018 Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras and Alberto Rodriguez. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] Farinacci, et al. Expires March 30, 2019 [Page 39] Internet-Draft LISP September 2018 B.1. Changes to draft-ietf-lisp-rfc6830bis-20 o Posted late-September 2018. o Fix old reference to RFC3168, changed to RFC6040. B.2. Changes to draft-ietf-lisp-rfc6830bis-19 o Posted late-September 2018. o More editorial changes. B.3. Changes to draft-ietf-lisp-rfc6830bis-18 o Posted mid-September 2018. o Changes to reflect comments from Secdir review (Mirja). B.4. Changes to draft-ietf-lisp-rfc6830bis-17 o Posted September 2018. o Indicate in the "Changes since RFC 6830" section why the document has been shortened in length. o Make reference to RFC 8085 about UDP congestion control. o More editorial changes from multiple IESG reviews. B.5. Changes to draft-ietf-lisp-rfc6830bis-16 o Posted late August 2018. o Distinguish the message type names between ICMP for IPv4 and ICMP for IPv6 for handling MTU issues. B.6. Changes to draft-ietf-lisp-rfc6830bis-15 o Posted August 2018. o Final editorial changes before RFC submission for Proposed Standard. o Added section "Changes since RFC 6830" so implementers are informed of any changes since the last RFC publication. Farinacci, et al. Expires March 30, 2019 [Page 40] Internet-Draft LISP September 2018 B.7. Changes to draft-ietf-lisp-rfc6830bis-14 o Posted July 2018 IETF week. o Put obsolete of RFC 6830 in Intro section in addition to abstract. B.8. Changes to draft-ietf-lisp-rfc6830bis-13 o Posted March IETF Week 2018. o Clarified that a new nonce is required per RLOC. o Removed 'Clock Sweep' section. This text must be placed in a new OAM document. o Some references changed from normative to informative B.9. Changes to draft-ietf-lisp-rfc6830bis-12 o Posted July 2018. o Fixed Luigi editorial comments to ready draft for RFC status. B.10. Changes to draft-ietf-lisp-rfc6830bis-11 o Posted March 2018. o Removed sections 16, 17 and 18 (Mobility, Deployment and Traceroute considerations). This text must be placed in a new OAM document. B.11. Changes to draft-ietf-lisp-rfc6830bis-10 o Posted March 2018. o Updated section 'Router Locator Selection' stating that the Data- Plane MUST follow what's stored in the Map-Cache (priorities and weights). o Section 'Routing Locator Reachability': Removed bullet point 2 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and RLOC probing o Removed 'Solicit-Map Request'. Farinacci, et al. Expires March 30, 2019 [Page 41] Internet-Draft LISP September 2018 B.12. Changes to draft-ietf-lisp-rfc6830bis-09 o Posted January 2018. o Add more details in section 5.3 about DSCP processing during encapsulation and decapsulation. o Added clarity to definitions in the Definition of Terms section from various commenters. o Removed PA and PI definitions from Definition of Terms section. o More editorial changes. o Removed 4342 from IANA section and move to RFC6833 IANA section. B.13. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted January 2018. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. o Made changes to reflect comments from document WG shepherd Luigi Iannone. o Ran IDNITs on the document. B.14. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. B.15. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. Farinacci, et al. Expires March 30, 2019 [Page 42] Internet-Draft LISP September 2018 quot;rfc822". Since mailbox addresses (including those used in the Internet) may be case sensitive, the case of alphabetic characters in the address MUST be preserved. 3.2.5 Original-Message-ID field The Original-Message-ID field indicates the message-ID of the message for which the MDN is being issued. It is obtained from the Message- ID header of the message for which the MDN is issued. This field MUST be present if the original message contained a Message-ID header. The syntax of the field is Fajman Standards Track [Page 12] RFC 2298 Message Disposition Notifications March 1998 original-message-id-field = "Original-Message-ID" ":" msg-id The msg-id token is as specified in RFC 822 [2]. 3.2.6 Disposition field The Disposition field indicates the action performed by the Reporting-UA on behalf of the user. This field MUST be present. The syntax for the Disposition field is: disposition-field = "Disposition" ":" disposition-mode ";" disposition-type [ '/' disposition-modifier *( "," dispostion-modifier ) ] disposition-mode = action-mode "/" sending-mode action-mode = "manual-action" / "automatic-action" sending-mode = "MDN-sent-manually" / "MDN-sent-automatically" disposition-type = "displayed" / "dispatched" / "processed" / "deleted" / "denied" / "failed" disposition-modifier = ( "error" / "warning" ) / ( "superseded" / "expired" / "mailbox-terminated" ) / disposition-modifier-extension disposition-modifier-extension = atom The disposition-mode, disposition-type and disposition-modifier may be spelled in any combination of upper and lower case characters. 3.2.6.1 Disposition modes The following disposition modes are defined: "manual-action" The disposition described by the disposition type was a result of an explicit instruction by the user rather than some sort of automatically performed action. Fajman Standards Track [Page 13] RFC 2298 Message Disposition Notifications March 1998 "automatic-action" The disposition described by the disposition type was a result of an automatic action, rather than an explicit instruction by the user for this message. "Manual-action" and "automatic-action" are mutually exclusive. One or the other must be specified. "MDN-sent-manually" The user explicity gave permission for this particular MDN to be sent. "MDN-sent-automatically" The MDN was sent because the UA had previously been configured to do so automatically. "MDN-sent-manually" and "MDN-sent- automatically" are mutually exclusive. One or the other must be specified. 3.2.6.2 Disposition types The following disposition-types are defined: "displayed" The message has been displayed by the UA to someone reading the recipient's mailbox. There is no guarantee that the content has been read or understood. "dispatched" The message has been sent somewhere in some manner (e.g., printed, faxed, forwarded) without necessarily having been previously displayed to the user. The user may or may not see the message later. "processed" The message has been processed in some manner (i.e., by some sort of rules or server) without being displayed to the user. The user may or may not see the message later, or there may not even be a human user associated with the mailbox. "deleted" The message has been deleted. The recipient may or may not have seen the message. The recipient might "undelete" the message at a later time and read the message. Fajman Standards Track [Page 14] RFC 2298 Message Disposition Notifications March 1998 "denied" The recipient does not wish the sender to be informed of the message's disposition. A UA may also siliently ignore message disposition requests in this situation. "failed" A failure occurred that prevented the proper generation of an MDN. More information about the cause of the failure may be contained in a Failure field. The "failed" disposition type is not to be used for the situation in which there is is some problem in processing the message other than interpreting the request for an MDN. The "processed" or other disposition type with appropriate disposition modifiers is to be used in such situations. 3.2.6.3 Disposition modifiers The following disposition modifiers are defined: "error" An error of some sort occurred that prevented successful processing of the message. Further information is contained in an Error field. "warning" The message was successfully processed but some sort of exceptional condition occurred. Further information is contained in a Warning field. "superseded&o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addresses can be used. B.16. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Re-encapsulating Tunnel Router is an RTR. B.17. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. B.18. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. B.19. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. B.20. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. Farinacci, et al. Expires March 30, 2019 [Page 43] Internet-Draft LISP September 2018 o Remove references to "experimental". B.21. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com Farinacci, et al. Expires March 30, 2019 [Page 44] Internet-Draft LISP September 2018 Albert Cabellos UPC/BarcelonaTech Campus Nord, C. Jordi Girona 1-3 Barcelona, Catalunya Spain EMail: acabello@ac.upc.edu Farinacci, et al. Expires March 30, 2019 [Page 45]