< draft-ietf-lisp-rfc6830bis-20.txt | draft-ietf-lisp-rfc6830bis-21.txt > | |||
---|---|---|---|---|
Network Working Group D. Farinacci | Network Working Group D. Farinacci | |||
Internet-Draft V. Fuller | Internet-Draft V. Fuller | |||
Obsoletes: 6830 (if approved) D. Meyer | Obsoletes: 6830 (if approved) D. Meyer | |||
Intended status: Standards Track D. Lewis | Intended status: Standards Track D. Lewis | |||
Expires: March 30, 2019 Cisco Systems | Expires: March 31, 2019 Cisco Systems | |||
A. Cabellos (Ed.) | A. Cabellos (Ed.) | |||
UPC/BarcelonaTech | UPC/BarcelonaTech | |||
September 26, 2018 | September 27, 2018 | |||
The Locator/ID Separation Protocol (LISP) | The Locator/ID Separation Protocol (LISP) | |||
draft-ietf-lisp-rfc6830bis-20 | draft-ietf-lisp-rfc6830bis-21 | |||
Abstract | Abstract | |||
This document describes the Data-Plane protocol for the Locator/ID | This document describes the Data-Plane protocol for the Locator/ID | |||
Separation Protocol (LISP). LISP defines two namespaces, End-point | Separation Protocol (LISP). LISP defines two namespaces, End-point | |||
Identifiers (EIDs) that identify end-hosts and Routing Locators | Identifiers (EIDs) that identify end-hosts and Routing Locators | |||
(RLOCs) that identify network attachment points. With this, LISP | (RLOCs) that identify network attachment points. With this, LISP | |||
effectively separates control from data, and allows routers to create | effectively separates control from data, and allows routers to create | |||
overlay networks. LISP-capable routers exchange encapsulated packets | overlay networks. LISP-capable routers exchange encapsulated packets | |||
according to EID-to-RLOC mappings stored in a local Map-Cache. | according to EID-to-RLOC mappings stored in a local Map-Cache. | |||
skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 30, 2019. | This Internet-Draft will expire on March 31, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 7 ¶ | skipping to change at page 3, line 7 ¶ | |||
17. Network Management Considerations . . . . . . . . . . . . . . 33 | 17. Network Management Considerations . . . . . . . . . . . . . . 33 | |||
18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | |||
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 | 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 | |||
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | |||
20.2. Informative References . . . . . . . . . . . . . . . . . 35 | 20.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 | |||
B.1. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 40 | B.1. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 40 | |||
B.2. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 40 | B.2. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 40 | |||
B.3. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 40 | B.3. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 40 | |||
B.4. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 40 | B.4. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 40 | |||
B.5. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 40 | B.5. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 40 | |||
B.6. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 40 | B.6. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 40 | |||
B.7. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 41 | B.7. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 40 | |||
B.8. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 41 | B.8. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 41 | |||
B.9. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41 | B.9. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 41 | |||
B.10. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 41 | B.10. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41 | |||
B.11. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 41 | B.11. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 41 | |||
B.12. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 42 | B.12. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 41 | |||
B.13. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 42 | B.13. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 42 | |||
B.14. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 42 | B.14. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 42 | |||
B.15. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 42 | B.15. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 42 | |||
B.16. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 43 | B.16. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 42 | |||
B.17. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 43 | B.17. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 43 | |||
B.18. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 43 | B.18. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 43 | |||
B.19. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 43 | B.19. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 43 | |||
B.20. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 43 | B.20. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 43 | |||
B.21. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44 | B.21. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 43 | |||
B.22. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 44 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
1. Introduction | 1. Introduction | |||
This document describes the Locator/Identifier Separation Protocol | This document describes the Locator/Identifier Separation Protocol | |||
(LISP). LISP is an encapsulation protocol built around the | (LISP). LISP is an encapsulation protocol built around the | |||
fundamental idea of separating the topological location of a network | fundamental idea of separating the topological location of a network | |||
attachment point from the node's identity [CHIAPPA]. As a result | attachment point from the node's identity [CHIAPPA]. As a result | |||
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | |||
used to identify end-hosts (e.g., nodes or Virtual Machines) and | used to identify end-hosts (e.g., nodes or Virtual Machines) and | |||
skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 36 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119] and | document are to be interpreted as described in [RFC2119] and | |||
[RFC8174]. | [RFC8174]. | |||
3. Definition of Terms | 3. Definition of Terms | |||
Address Family Identifier (AFI): AFI is a term used to describe an | Address Family Identifier (AFI): AFI is a term used to describe an | |||
address encoding in a packet. An address family that pertains to | address encoding in a packet. An address family that pertains to | |||
the Data-Plane. See [AFN] and [RFC3232] for details. An AFI | addresses found in Data-Plane headers. See [AFN] and [RFC3232] | |||
value of 0 used in this specification indicates an unspecified | for details. An AFI value of 0 used in this specification | |||
encoded address where the length of the address is 0 octets | indicates an unspecified encoded address where the length of the | |||
following the 16-bit AFI value of 0. | address is 0 octets following the 16-bit AFI value of 0. | |||
Anycast Address: Anycast Address is a term used in this document to | Anycast Address: Anycast Address is a term used in this document to | |||
refer to the same IPv4 or IPv6 address configured and used on | refer to the same IPv4 or IPv6 address configured and used on | |||
multiple systems at the same time. An EID or RLOC can be an | multiple systems at the same time. An EID or RLOC can be an | |||
anycast address in each of their own address spaces. | anycast address in each of their own address spaces. | |||
Client-side: Client-side is a term used in this document to indicate | Client-side: Client-side is a term used in this document to indicate | |||
a connection initiation attempt by an end-system represented by an | a connection initiation attempt by an end-system represented by an | |||
EID. | EID. | |||
skipping to change at page 6, line 37 ¶ | skipping to change at page 6, line 40 ¶ | |||
to an LEID. | to an LEID. | |||
Ingress Tunnel Router (ITR): An ITR is a router that resides in a | Ingress Tunnel Router (ITR): An ITR is a router that resides in a | |||
LISP site. Packets sent by sources inside of the LISP site to | LISP site. Packets sent by sources inside of the LISP site to | |||
destinations outside of the site are candidates for encapsulation | destinations outside of the site are candidates for encapsulation | |||
by the ITR. The ITR treats the IP destination address as an EID | by the ITR. The ITR treats the IP destination address as an EID | |||
and performs an EID-to-RLOC mapping lookup. The router then | and performs an EID-to-RLOC mapping lookup. The router then | |||
prepends an "outer" IP header with one of its routable RLOCs (in | prepends an "outer" IP header with one of its routable RLOCs (in | |||
the RLOC space) in the source address field and the result of the | the RLOC space) in the source address field and the result of the | |||
mapping lookup in the destination address field. Note that this | mapping lookup in the destination address field. Note that this | |||
destination RLOC MAY be an intermediate, proxy device that has | destination RLOC may be an intermediate, proxy device that has | |||
better knowledge of the EID-to-RLOC mapping closer to the | better knowledge of the EID-to-RLOC mapping closer to the | |||
destination EID. In general, an ITR receives IP packets from site | destination EID. In general, an ITR receives IP packets from site | |||
end-systems on one side and sends LISP-encapsulated IP packets | end-systems on one side and sends LISP-encapsulated IP packets | |||
toward the Internet on the other side. | toward the Internet on the other side. | |||
Specifically, when a service provider prepends a LISP header for | Specifically, when a service provider prepends a LISP header for | |||
Traffic Engineering purposes, the router that does this is also | Traffic Engineering purposes, the router that does this is also | |||
regarded as an ITR. The outer RLOC the ISP ITR uses can be based | regarded as an ITR. The outer RLOC the ISP ITR uses can be based | |||
on the outer destination address (the originating ITR's supplied | on the outer destination address (the originating ITR's supplied | |||
RLOC) or the inner destination address (the originating host's | RLOC) or the inner destination address (the originating host's | |||
skipping to change at page 7, line 26 ¶ | skipping to change at page 7, line 29 ¶ | |||
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the | Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the | |||
LISP header. They are used by ITRs to inform ETRs about the up/ | 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 | 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 | 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 | status. The LSBs can be verified by use of one of the Locator | |||
reachability algorithms described in Section 10. | reachability algorithms described in Section 10. | |||
Negative Mapping Entry: A negative mapping entry, also known as a | Negative Mapping Entry: A negative mapping entry, also known as a | |||
negative cache entry, is an EID-to-RLOC entry where an EID-Prefix | 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 | 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 | for the EID-to-RLOC entry is empty, one with an encoded Locator | |||
of 0. This type of entry could be used to describe a prefix from | count of 0. This type of entry could be used to describe a prefix | |||
a non-LISP site, which is explicitly not in the mapping database. | from a non-LISP site, which is explicitly not in the mapping | |||
There are a set of well-defined actions that are encoded in a | database. There are a set of well-defined actions that are | |||
Negative Map-Reply. | encoded in a Negative Map-Reply. | |||
Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A | 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 | PETR acts like an ETR but does so on behalf of LISP sites that | |||
send packets to destinations at non-LISP sites. | send packets to destinations at non-LISP sites. | |||
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A | 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 | PITR acts like an ITR but does so on behalf of non-LISP sites that | |||
send packets to destinations at LISP sites. | send packets to destinations at LISP sites. | |||
Recursive Tunneling: Recursive Tunneling occurs when a packet has | Recursive Tunneling: Recursive Tunneling occurs when a packet has | |||
skipping to change at page 10, line 18 ¶ | skipping to change at page 10, line 21 ¶ | |||
encapsulated for inter-site communication. | encapsulated for inter-site communication. | |||
o EIDs MAY also be structured (subnetted) in a manner suitable for | o EIDs MAY also be structured (subnetted) in a manner suitable for | |||
local routing within an Autonomous System (AS). | local routing within an Autonomous System (AS). | |||
An additional LISP header MAY be prepended to packets by a TE-ITR | 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 | 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 | use-case for this would be an ISP router that needs to perform | |||
Traffic Engineering for packets flowing through its network. In such | Traffic Engineering for packets flowing through its network. In such | |||
a situation, termed "Recursive Tunneling", an ISP transit acts as an | a situation, termed "Recursive Tunneling", an ISP transit acts as an | |||
additional ITR, and the RLOC it uses for the new prepended header | additional ITR, and the destination RLOC it uses for the new | |||
would be either a TE-ETR within the ISP (along an intra-ISP traffic | prepended header would be either a TE-ETR within the ISP (along an | |||
engineered path) or a TE-ETR within another ISP (an inter-ISP traffic | intra-ISP traffic engineered path) or a TE-ETR within another ISP (an | |||
engineered path, where an agreement to build such a path exists). | 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 | In order to avoid excessive packet overhead as well as possible | |||
encapsulation loops, this document recommends that a maximum of two | encapsulation loops, this document recommends that a maximum of two | |||
LISP headers can be prepended to a packet. For initial LISP | LISP headers can be prepended to a packet. For initial LISP | |||
deployments, it is assumed that two headers is sufficient, where the | deployments, it is assumed that two headers is sufficient, where the | |||
first prepended header is used at a site for Location/Identity | first prepended header is used at a site for Location/Identity | |||
separation and the second prepended header is used inside a service | separation and the second prepended header is used inside a service | |||
provider for Traffic Engineering purposes. | provider for Traffic Engineering purposes. | |||
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. | Tunnel Routers can be placed fairly flexibly in a multi-AS topology. | |||
skipping to change at page 19, line 10 ¶ | skipping to change at page 19, line 10 ¶ | |||
of the IPv6 'Traffic Class' field) requires special treatment in | of the IPv6 'Traffic Class' field) requires special treatment in | |||
order to avoid discarding indications of congestion [RFC6040]. | order to avoid discarding indications of congestion [RFC6040]. | |||
ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | |||
header to the outer header. Re-encapsulation MUST copy the 2-bit | header to the outer header. Re-encapsulation MUST copy the 2-bit | |||
'ECN' field from the stripped outer header to the new outer | 'ECN' field from the stripped outer header to the new outer | |||
header. | header. | |||
When doing ETR/PETR decapsulation: | When doing ETR/PETR decapsulation: | |||
o The inner-header 'Time to Live' field (or 'Hop Limit' field, in | 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 | the case of IPv6) MUST be copied from the outer-header 'Time to | |||
Live' field, when the Time to Live value of the outer header is | Live' 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 | 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 | perform this check can cause the Time to Live of the inner header | |||
to increment across encapsulation/decapsulation cycles. This | to increment across encapsulation/decapsulation cycles. This | |||
check is also performed when doing initial encapsulation, when a | check is also performed when doing initial encapsulation, when a | |||
packet comes to an ITR or PITR destined for a LISP site. | packet comes to an ITR or PITR destined for a LISP site. | |||
o The inner-header 'Differentiated Services Code Point' (DSCP) field | o The outer-header 'Differentiated Services Code Point' (DSCP) field | |||
(or the 'Traffic Class' field, in the case of IPv6) SHOULD be | (or the 'Traffic Class' field, in the case of IPv6) SHOULD be | |||
copied from the outer-header DSCP field ('Traffic Class' field, in | copied from the outer-header DSCP field ('Traffic Class' field, in | |||
the case of IPv6) to the inner-header. | the case of IPv6) to the inner-header. | |||
o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | |||
of the IPv6 'Traffic Class' field) requires special treatment in | of the IPv6 'Traffic Class' field) requires special treatment in | |||
order to avoid discarding indications of congestion [RFC6040]. If | order to avoid discarding indications of congestion [RFC6040]. If | |||
the 'ECN' field contains a congestion indication codepoint (the | the 'ECN' field contains a congestion indication codepoint (the | |||
value is '11', the Congestion Experienced (CE) codepoint), then | value is '11', the Congestion Experienced (CE) codepoint), then | |||
ETR decapsulation MUST copy the 2-bit 'ECN' field from the | ETR decapsulation MUST copy the 2-bit 'ECN' field from the | |||
skipping to change at page 21, line 45 ¶ | skipping to change at page 21, line 45 ¶ | |||
MTU between the ITR and its correspondent ETR. | MTU between the ITR and its correspondent ETR. | |||
When an ETR receives encapsulated fragments, it treats them as two | When an ETR receives encapsulated fragments, it treats them as two | |||
individually encapsulated packets. It strips the LISP headers and | individually encapsulated packets. It strips the LISP headers and | |||
then forwards each fragment to the destination host of the | then forwards each fragment to the destination host of the | |||
destination site. The two fragments are reassembled at the | destination site. The two fragments are reassembled at the | |||
destination host into the single IP datagram that was originated by | destination host into the single IP datagram that was originated by | |||
the source host. Note that reassembly can happen at the ETR if the | the source host. Note that reassembly can happen at the ETR if the | |||
encapsulated packet was fragmented at or after the ITR. | encapsulated packet was fragmented at or after the ITR. | |||
This behavior MAY be performed by the ITR only when the source host | This behavior MUST be performed by the ITR only when the source host | |||
originates a packet with the 'DF' field of the IP header set to 0. | 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 | 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 | 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/ | packet when the size is greater than L and send an ICMPv4 ICMP | |||
Fragmentation-Needed message to the source with a value of S, where S | Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" message | |||
is (L - H). | to the source with a value of S, where S is (L - H). | |||
When the outer-header encapsulation uses an IPv4 header, an | When the outer-header encapsulation uses an IPv4 header, an | |||
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly | 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 | 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 | to 0 if it has good reason to believe there are unresolvable path MTU | |||
issues between the sending ITR and the receiving ETR. | issues between the sending ITR and the receiving ETR. | |||
This specification RECOMMENDS that L be defined as 1500. | This specification RECOMMENDS that L be defined as 1500. | |||
7.2. A Stateful Solution to MTU Handling | 7.2. A Stateful Solution to MTU Handling | |||
skipping to change at page 24, line 51 ¶ | skipping to change at page 24, line 51 ¶ | |||
encapsulated packet. A reply to this "verifying Map-Request" is used | encapsulated packet. A reply to this "verifying Map-Request" is used | |||
to fully populate the Map-Cache entry for the "gleaned" EID and is | 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 | 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 | received Map-Reply. When a verified Map-Cache entry is stored, data | |||
gleaning no longer occurs for subsequent packets that have a source | gleaning no longer occurs for subsequent packets that have a source | |||
EID that matches the EID-Prefix of the verified entry. This | EID that matches the EID-Prefix of the verified entry. This | |||
"gleaning" mechanism is OPTIONAL, refer to Section 16 for security | "gleaning" mechanism is OPTIONAL, refer to Section 16 for security | |||
issues regarding this mechanism. | issues regarding this mechanism. | |||
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be | 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 | reachable when the R-bit [I-D.ietf-lisp-rfc6833bis] for the Locator | |||
the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the | record is set to 1. When the R-bit is set to 0, an ITR or PITR MUST | |||
RLOC. Neither the information contained in a Map-Reply nor that | NOT encapsulate to the RLOC. Neither the information contained in a | |||
stored in the mapping database system provides reachability | Map-Reply nor that stored in the mapping database system provides | |||
information for RLOCs. Note that reachability is not part of the | reachability information for RLOCs. Note that reachability is not | |||
mapping system and is determined using one or more of the Routing | part of the mapping system and is determined using one or more of the | |||
Locator reachability algorithms described in the next section. | Routing Locator reachability algorithms described in the next | |||
section. | ||||
10. Routing Locator Reachability | 10. Routing Locator Reachability | |||
Several Data-Plane mechanisms for determining RLOC reachability are | Several Data-Plane mechanisms for determining RLOC reachability are | |||
currently defined. Please note that additional Control-Plane based | currently defined. Please note that additional Control-Plane based | |||
reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. | reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. | |||
1. An ETR MAY examine the Locator-Status-Bits in the LISP header of | 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 | 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 | 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 | ITR site, it can use this status information to help select an | |||
RLOC. | RLOC. | |||
2. When an ETR receives an encapsulated packet from an ITR, the | 2. When an ETR receives an encapsulated packet from an ITR, the | |||
source RLOC from the outer header of the packet is likely up. | source RLOC from the outer header of the packet is likely to be | |||
reachable. | ||||
3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability | 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability | |||
algorithms described in this section. | algorithms described in this section. | |||
When determining Locator up/down reachability by examining the | When determining Locator up/down reachability by examining the | |||
Locator-Status-Bits from the LISP-encapsulated data packet, an ETR | Locator-Status-Bits from the LISP-encapsulated data packet, an ETR | |||
will receive up-to-date status from an encapsulating ITR about | will receive up-to-date status from an encapsulating ITR about | |||
reachability for all ETRs at the site. CE-based ITRs at the source | reachability for all ETRs at the site. CE-based ITRs at the source | |||
site can determine reachability relative to each other using the site | site can determine reachability relative to each other using the site | |||
IGP as follows: | IGP as follows: | |||
skipping to change at page 33, line 36 ¶ | skipping to change at page 33, line 36 ¶ | |||
than 2 LISP headers, an implementation can support more. However, | than 2 LISP headers, an implementation can support more. However, | |||
it is RECOMMENDED that a maximum of two LISP headers can be | it is RECOMMENDED that a maximum of two LISP headers can be | |||
prepended to a packet. | prepended to a packet. | |||
o The 3 reserved flag bits in the LISP header have been allocated | 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 | 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 | the KK bits) are used as a key identifier. The 1 remaining bit is | |||
still documented as reserved. | still documented as reserved. | |||
o Data-Plane gleaning for creating map-cache entries has been made | o Data-Plane gleaning for creating map-cache entries has been made | |||
optional. If any ITR implementations depend or assume the remote | optional. Any ITR implementations that depend on or assume the | |||
ETR is gleaning should not do so. This does not create any | remote ETR is gleaning should not do so. This does not create any | |||
interoperability problems since the control-plane map-cache | interoperability problems since the control-plane map-cache | |||
population procedures are unilateral and are the typical method | population procedures are unilateral and are the typical method | |||
for map-cache population. | for map-cache population. | |||
o The bulk of the changes to this document which reduces its length | o The bulk of the changes to this document which reduces its length | |||
are due to moving the LISP control-plane messaging and procedures | are due to moving the LISP control-plane messaging and procedures | |||
to [I-D.ietf-lisp-rfc6833bis]. | to [I-D.ietf-lisp-rfc6833bis]. | |||
19. IANA Considerations | 19. IANA Considerations | |||
skipping to change at page 34, line 25 ¶ | skipping to change at page 34, line 25 ¶ | |||
20.1. Normative References | 20.1. Normative References | |||
[I-D.ietf-lisp-6834bis] | [I-D.ietf-lisp-6834bis] | |||
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | |||
Separation Protocol (LISP) Map-Versioning", draft-ietf- | Separation Protocol (LISP) Map-Versioning", draft-ietf- | |||
lisp-6834bis-02 (work in progress), September 2018. | lisp-6834bis-02 (work in progress), September 2018. | |||
[I-D.ietf-lisp-rfc6833bis] | [I-D.ietf-lisp-rfc6833bis] | |||
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | |||
"Locator/ID Separation Protocol (LISP) Control-Plane", | "Locator/ID Separation Protocol (LISP) Control-Plane", | |||
draft-ietf-lisp-rfc6833bis-15 (work in progress), | draft-ietf-lisp-rfc6833bis-16 (work in progress), | |||
September 2018. | September 2018. | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
DOI 10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
<https://www.rfc-editor.org/info/rfc768>. | <https://www.rfc-editor.org/info/rfc768>. | |||
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
<https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
skipping to change at page 40, line 5 ¶ | skipping to change at page 40, line 5 ¶ | |||
The LISP working group would like to give a special thanks to Jari | 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 | Arkko, the Internet Area AD at the time that the set of LISP | |||
documents were being prepared for IESG last call, and for his | documents were being prepared for IESG last call, and for his | |||
meticulous reviews and detailed commentaries on the 7 working group | meticulous reviews and detailed commentaries on the 7 working group | |||
last call documents progressing toward standards-track RFCs. | last call documents progressing toward standards-track RFCs. | |||
Appendix B. Document Change Log | Appendix B. Document Change Log | |||
[RFC Editor: Please delete this section on publication as RFC.] | [RFC Editor: Please delete this section on publication as RFC.] | |||
B.1. Changes to draft-ietf-lisp-rfc6830bis-20 | B.1. Changes to draft-ietf-lisp-rfc6830bis-21 | |||
o Late-September 2018. | ||||
o Changes to reflect comments from Sep 27th Telechat. | ||||
B.2. Changes to draft-ietf-lisp-rfc6830bis-20 | ||||
o Posted late-September 2018. | o Posted late-September 2018. | |||
o Fix old reference to RFC3168, changed to RFC6040. | o Fix old reference to RFC3168, changed to RFC6040. | |||
B.2. Changes to draft-ietf-lisp-rfc6830bis-19 | B.3. Changes to draft-ietf-lisp-rfc6830bis-19 | |||
o Posted late-September 2018. | o Posted late-September 2018. | |||
o More editorial changes. | o More editorial changes. | |||
B.3. Changes to draft-ietf-lisp-rfc6830bis-18 | B.4. Changes to draft-ietf-lisp-rfc6830bis-18 | |||
o Posted mid-September 2018. | o Posted mid-September 2018. | |||
o Changes to reflect comments from Secdir review (Mirja). | o Changes to reflect comments from Secdir review (Mirja). | |||
B.4. Changes to draft-ietf-lisp-rfc6830bis-17 | B.5. Changes to draft-ietf-lisp-rfc6830bis-17 | |||
o Posted September 2018. | o Posted September 2018. | |||
o Indicate in the "Changes since RFC 6830" section why the document | o Indicate in the "Changes since RFC 6830" section why the document | |||
has been shortened in length. | has been shortened in length. | |||
o Make reference to RFC 8085 about UDP congestion control. | o Make reference to RFC 8085 about UDP congestion control. | |||
o More editorial changes from multiple IESG reviews. | o More editorial changes from multiple IESG reviews. | |||
B.5. Changes to draft-ietf-lisp-rfc6830bis-16 | B.6. Changes to draft-ietf-lisp-rfc6830bis-16 | |||
o Posted late August 2018. | o Posted late August 2018. | |||
o Distinguish the message type names between ICMP for IPv4 and ICMP | o Distinguish the message type names between ICMP for IPv4 and ICMP | |||
for IPv6 for handling MTU issues. | for IPv6 for handling MTU issues. | |||
B.6. Changes to draft-ietf-lisp-rfc6830bis-15 | B.7. Changes to draft-ietf-lisp-rfc6830bis-15 | |||
o Posted August 2018. | o Posted August 2018. | |||
o Final editorial changes before RFC submission for Proposed | o Final editorial changes before RFC submission for Proposed | |||
Standard. | Standard. | |||
o Added section "Changes since RFC 6830" so implementers are | o Added section "Changes since RFC 6830" so implementers are | |||
informed of any changes since the last RFC publication. | informed of any changes since the last RFC publication. | |||
B.7. Changes to draft-ietf-lisp-rfc6830bis-14 | B.8. Changes to draft-ietf-lisp-rfc6830bis-14 | |||
o Posted July 2018 IETF week. | o Posted July 2018 IETF week. | |||
o Put obsolete of RFC 6830 in Intro section in addition to abstract. | o Put obsolete of RFC 6830 in Intro section in addition to abstract. | |||
B.8. Changes to draft-ietf-lisp-rfc6830bis-13 | B.9. Changes to draft-ietf-lisp-rfc6830bis-13 | |||
o Posted March IETF Week 2018. | o Posted March IETF Week 2018. | |||
o Clarified that a new nonce is required per RLOC. | o Clarified that a new nonce is required per RLOC. | |||
o Removed 'Clock Sweep' section. This text must be placed in a new | o Removed 'Clock Sweep' section. This text must be placed in a new | |||
OAM document. | OAM document. | |||
o Some references changed from normative to informative | o Some references changed from normative to informative | |||
B.9. Changes to draft-ietf-lisp-rfc6830bis-12 | B.10. Changes to draft-ietf-lisp-rfc6830bis-12 | |||
o Posted July 2018. | o Posted July 2018. | |||
o Fixed Luigi editorial comments to ready draft for RFC status. | o Fixed Luigi editorial comments to ready draft for RFC status. | |||
B.10. Changes to draft-ietf-lisp-rfc6830bis-11 | B.11. Changes to draft-ietf-lisp-rfc6830bis-11 | |||
o Posted March 2018. | o Posted March 2018. | |||
o Removed sections 16, 17 and 18 (Mobility, Deployment and | o Removed sections 16, 17 and 18 (Mobility, Deployment and | |||
Traceroute considerations). This text must be placed in a new OAM | Traceroute considerations). This text must be placed in a new OAM | |||
document. | document. | |||
B.11. Changes to draft-ietf-lisp-rfc6830bis-10 | B.12. Changes to draft-ietf-lisp-rfc6830bis-10 | |||
o Posted March 2018. | o Posted March 2018. | |||
o Updated section 'Router Locator Selection' stating that the Data- | o Updated section 'Router Locator Selection' stating that the Data- | |||
Plane MUST follow what's stored in the Map-Cache (priorities and | Plane MUST follow what's stored in the Map-Cache (priorities and | |||
weights). | weights). | |||
o Section 'Routing Locator Reachability': Removed bullet point 2 | o Section 'Routing Locator Reachability': Removed bullet point 2 | |||
(ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | |||
Unreachable),5 (receive a Map-Reply as a response) and RLOC | Unreachable),5 (receive a Map-Reply as a response) and RLOC | |||
probing | probing | |||
o Removed 'Solicit-Map Request'. | o Removed 'Solicit-Map Request'. | |||
B.12. Changes to draft-ietf-lisp-rfc6830bis-09 | B.13. Changes to draft-ietf-lisp-rfc6830bis-09 | |||
o Posted January 2018. | o Posted January 2018. | |||
o Add more details in section 5.3 about DSCP processing during | o Add more details in section 5.3 about DSCP processing during | |||
encapsulation and decapsulation. | encapsulation and decapsulation. | |||
o Added clarity to definitions in the Definition of Terms section | o Added clarity to definitions in the Definition of Terms section | |||
from various commenters. | from various commenters. | |||
o Removed PA and PI definitions from Definition of Terms section. | o Removed PA and PI definitions from Definition of Terms section. | |||
o More editorial changes. | o More editorial changes. | |||
o Removed 4342 from IANA section and move to RFC6833 IANA section. | o Removed 4342 from IANA section and move to RFC6833 IANA section. | |||
B.13. Changes to draft-ietf-lisp-rfc6830bis-08 | B.14. Changes to draft-ietf-lisp-rfc6830bis-08 | |||
o Posted January 2018. | o Posted January 2018. | |||
o Remove references to research work for any protocol mechanisms. | o Remove references to research work for any protocol mechanisms. | |||
o Document scanned to make sure it is RFC 2119 compliant. | o Document scanned to make sure it is RFC 2119 compliant. | |||
o Made changes to reflect comments from document WG shepherd Luigi | o Made changes to reflect comments from document WG shepherd Luigi | |||
Iannone. | Iannone. | |||
o Ran IDNITs on the document. | o Ran IDNITs on the document. | |||
B.14. Changes to draft-ietf-lisp-rfc6830bis-07 | B.15. Changes to draft-ietf-lisp-rfc6830bis-07 | |||
o Posted November 2017. | o Posted November 2017. | |||
o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | |||
addresses. | addresses. | |||
B.15. Changes to draft-ietf-lisp-rfc6830bis-06 | B.16. Changes to draft-ietf-lisp-rfc6830bis-06 | |||
o Posted October 2017. | o Posted October 2017. | |||
o Put RTR definition before it is used. | o Put RTR definition before it is used. | |||
o Rename references that are now working group drafts. | 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 | o Remove "EIDs MUST NOT be used as used by a host to refer to other | |||
hosts. Note that EID blocks MAY LISP RLOCs". | hosts. Note that EID blocks MAY LISP RLOCs". | |||
skipping to change at page 43, line 15 ¶ | skipping to change at page 43, line 15 ¶ | |||
o ETRs may, rather than will, be the ones to send Map-Replies. | o ETRs may, rather than will, be the ones to send Map-Replies. | |||
o Recommend, rather than mandate, max encapsulation headers to 2. | o Recommend, rather than mandate, max encapsulation headers to 2. | |||
o Reference VPN draft when introducing Instance-ID. | o Reference VPN draft when introducing Instance-ID. | |||
o Indicate that SMRs can be sent when ITR/ETR are in the same node. | o Indicate that SMRs can be sent when ITR/ETR are in the same node. | |||
o Clarify when private addresses can be used. | o Clarify when private addresses can be used. | |||
B.16. Changes to draft-ietf-lisp-rfc6830bis-05 | B.17. Changes to draft-ietf-lisp-rfc6830bis-05 | |||
o Posted August 2017. | o Posted August 2017. | |||
o Make it clear that a Re-encapsulating Tunnel Router is an RTR. | o Make it clear that a Re-encapsulating Tunnel Router is an RTR. | |||
B.17. Changes to draft-ietf-lisp-rfc6830bis-04 | B.18. Changes to draft-ietf-lisp-rfc6830bis-04 | |||
o Posted July 2017. | o Posted July 2017. | |||
o Changed reference of IPv6 RFC2460 to RFC8200. | o Changed reference of IPv6 RFC2460 to RFC8200. | |||
o Indicate that the applicability statement for UDP zero checksums | o Indicate that the applicability statement for UDP zero checksums | |||
over IPv6 adheres to RFC6936. | over IPv6 adheres to RFC6936. | |||
B.18. Changes to draft-ietf-lisp-rfc6830bis-03 | B.19. Changes to draft-ietf-lisp-rfc6830bis-03 | |||
o Posted May 2017. | o Posted May 2017. | |||
o Move the control-plane related codepoints in the IANA | o Move the control-plane related codepoints in the IANA | |||
Considerations section to RFC6833bis. | Considerations section to RFC6833bis. | |||
B.19. Changes to draft-ietf-lisp-rfc6830bis-02 | B.20. Changes to draft-ietf-lisp-rfc6830bis-02 | |||
o Posted April 2017. | o Posted April 2017. | |||
o Reflect some editorial comments from Damien Sausez. | o Reflect some editorial comments from Damien Sausez. | |||
B.20. Changes to draft-ietf-lisp-rfc6830bis-01 | B.21. Changes to draft-ietf-lisp-rfc6830bis-01 | |||
o Posted March 2017. | o Posted March 2017. | |||
o Include references to new RFCs published. | o Include references to new RFCs published. | |||
o Change references from RFC6833 to RFC6833bis. | o Change references from RFC6833 to RFC6833bis. | |||
o Clarified LCAF text in the IANA section. | o Clarified LCAF text in the IANA section. | |||
o Remove references to "experimental". | o Remove references to "experimental". | |||
B.21. Changes to draft-ietf-lisp-rfc6830bis-00 | B.22. Changes to draft-ietf-lisp-rfc6830bis-00 | |||
o Posted December 2016. | o Posted December 2016. | |||
o Created working group document from draft-farinacci-lisp | o Created working group document from draft-farinacci-lisp | |||
-rfc6830-00 individual submission. No other changes made. | -rfc6830-00 individual submission. No other changes made. | |||
Authors' Addresses | Authors' Addresses | |||
Dino Farinacci | Dino Farinacci | |||
Cisco Systems | Cisco Systems | |||
End of changes. 38 change blocks. | ||||
77 lines changed or deleted | 87 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |