< draft-ietf-lisp-rfc6833bis-08.txt | draft-ietf-lisp-rfc6833bis-09.txt > | |||
---|---|---|---|---|
Network Working Group V. Fuller | Network Working Group V. Fuller | |||
Internet-Draft D. Farinacci | Internet-Draft D. Farinacci | |||
Intended status: Standards Track Cisco Systems | Intended status: Standards Track Cisco Systems | |||
Expires: September 5, 2018 A. Cabellos (Ed.) | Expires: September 19, 2018 A. Cabellos (Ed.) | |||
UPC/BarcelonaTech | UPC/BarcelonaTech | |||
March 4, 2018 | March 18, 2018 | |||
Locator/ID Separation Protocol (LISP) Control-Plane | Locator/ID Separation Protocol (LISP) Control-Plane | |||
draft-ietf-lisp-rfc6833bis-08 | draft-ietf-lisp-rfc6833bis-09 | |||
Abstract | Abstract | |||
This document describes the Control-Plane and Mapping Service for the | This document describes the Control-Plane and Mapping Service for the | |||
Locator/ID Separation Protocol (LISP), implemented by two new types | Locator/ID Separation Protocol (LISP), implemented by two new types | |||
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server | of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server | |||
-- that provides a simplified "front end" for one or more Endpoint ID | -- that provides a simplified "front end" for one or more Endpoint ID | |||
to Routing Locator mapping databases. | to Routing Locator mapping databases. | |||
By using this control-plane service interface and communicating with | By using this Control-Plane service interface and communicating with | |||
Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and | Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and | |||
Egress Tunnel Routers (ETRs) are not dependent on the details of | Egress Tunnel Routers (ETRs) are not dependent on the details of | |||
mapping database systems, which facilitates modularity with different | mapping database systems, which facilitates modularity with different | |||
database designs. Since these devices implement the "edge" of the | database designs. Since these devices implement the "edge" of the | |||
LISP infrastructure, connect directly to LISP-capable Internet end | LISP Control-Plane infrastructure, connect directly to LISP-capable | |||
sites, and comprise the bulk of LISP-speaking devices, reducing their | Internet end sites, and comprising the bulk of LISP-speaking devices, | |||
implementation and operational complexity should also reduce the | reducing their implementation and operational complexity should also | |||
overall cost and effort of deploying LISP. | reduce the overall cost and effort of deploying LISP. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 September 5, 2018. | This Internet-Draft will expire on September 19, 2018. | |||
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 2, line 48 ¶ | skipping to change at page 2, line 48 ¶ | |||
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 | 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 | |||
8. Interactions with Other LISP Components . . . . . . . . . . . 32 | 8. Interactions with Other LISP Components . . . . . . . . . . . 32 | |||
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 | 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 | |||
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 | 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 | |||
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 | 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 | |||
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 35 | 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 35 | |||
8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 | 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | |||
10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 37 | 10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 37 | |||
10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 37 | 10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | |||
10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 | 10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 | |||
10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 38 | 10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 38 | |||
10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 38 | 10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 39 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 40 | 11.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 43 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 43 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 44 | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 43 | B.1. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 44 | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 43 | B.2. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 44 | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 44 | B.3. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 44 | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 44 | B.4. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 45 | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 44 | B.5. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 45 | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 44 | B.6. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 45 | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 45 | B.7. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 46 | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 45 | B.8. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 46 | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 45 | B.9. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 46 | |||
B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 45 | B.10. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 46 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 | B.11. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 47 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 | ||||
1. Introduction | 1. Introduction | |||
The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and | The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and | |||
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism | [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism | |||
for replacing the addresses currently used by IP with two separate | for dynamic tunnelling by logically separating the addresses | |||
name spaces: Endpoint IDs (EIDs), used within sites; and Routing | currently used by IP in two separate name spaces: Endpoint IDs | |||
Locators (RLOCs), used on the transit networks that make up the | (EIDs), used within sites; and Routing Locators (RLOCs), used on the | |||
Internet infrastructure. To achieve this separation, LISP defines | transit networks that make up the Internet infrastructure. To | |||
protocol mechanisms for mapping from EIDs to RLOCs. In addition, | achieve this separation, LISP defines protocol mechanisms for mapping | |||
LISP assumes the existence of a database to store and propagate those | from EIDs to RLOCs. In addition, LISP assumes the existence of a | |||
mappings globally. Several such databases have been proposed; among | database to store and propagate those mappings globally. Several | |||
them are the Content distribution Overlay Network Service for LISP | such databases have been proposed; among them are the Content | |||
(LISP-CONS) [LISP-CONS], LISP-NERD (a Not-so-novel EID-to-RLOC | distribution Overlay Network Service for LISP-NERD (a Not-so-novel | |||
Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT) | EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology | |||
[RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111]. | (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) | |||
[RFC8111]. | ||||
The LISP Mapping Service defines two new types of LISP-speaking | The LISP Mapping Service defines two new types of LISP-speaking | |||
devices: the Map-Resolver, which accepts Map-Requests from an Ingress | devices: the Map-Resolver, which accepts Map-Requests from an Ingress | |||
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a | Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a | |||
mapping database; and the Map-Server, which learns authoritative EID- | mapping database; and the Map-Server, which learns authoritative EID- | |||
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes | to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes | |||
them in a database. | them in a database. | |||
This LISP Control-Plane Mapping Service can be used by many different | This LISP Control-Plane Mapping Service can be used by many different | |||
encapsulation-based or translation-based data-planes which include | encapsulation-based or translation-based Data-Planes which include | |||
but are not limited to the ones defined in LISP RFC 6830bis | but are not limited to the ones defined in LISP RFC 6830bis | |||
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN | [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN | |||
[RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe]. | [RFC7348], VXLAN-GPE [I-D.quinn-vxlan-gpe], and ILA | |||
[I-D.herbert-intarea-ila]. | ||||
Conceptually, LISP Map-Servers share some of the same basic | Conceptually, LISP Map-Servers share some of the same basic | |||
configuration and maintenance properties as Domain Name System (DNS) | configuration and maintenance properties as Domain Name System (DNS) | |||
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar | [RFC1035] servers; likewise, Map-Resolvers are conceptually similar | |||
to DNS caching resolvers. With this in mind, this specification | to DNS caching resolvers. With this in mind, this specification | |||
borrows familiar terminology (resolver and server) from the DNS | borrows familiar terminology (resolver and server) from the DNS | |||
specifications. | specifications. | |||
Note that while this document assumes a LISP+ALT database mapping | Note that while this document assumes a LISP-ALT database mapping | |||
infrastructure to illustrate certain aspects of Map-Server and Map- | infrastructure to illustrate certain aspects of Map-Server and Map- | |||
Resolver operation, the Mapping Service interface can (and likely | Resolver operation, the Mapping Service interface can (and likely | |||
will) be used by ITRs and ETRs to access other mapping database | will) be used by ITRs and ETRs to access other mapping database | |||
systems as the LISP infrastructure evolves. | systems as the LISP infrastructure evolves. | |||
The LISP Mapping Service is an important component of the LISP | The LISP Mapping Service is an important component of the LISP | |||
toolset. Issues and concerns about the deployment of LISP for | toolset. Issues and concerns about the deployment of LISP for | |||
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. | Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], | |||
[RFC7215], and [LISP-OAM]. | ||||
2. Requirements Notation | 2. Requirements Notation | |||
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]. | document are to be interpreted as described in [RFC2119]. | |||
3. Definition of Terms | 3. Definition of Terms | |||
Map-Server: A network infrastructure component that learns of EID- | Map-Server: A network infrastructure component that learns of EID- | |||
Prefix mapping entries from an ETR, via the registration mechanism | Prefix mapping entries from an ETR, via the registration mechanism | |||
described below, or some other authoritative source if one exists. | described below, or some other authoritative source if one exists. | |||
A Map-Server publishes these EID-Prefixes in a mapping database. | A Map-Server publishes these EID-Prefixes in a mapping database. | |||
Map-Request: A LISP Map-Request is a control-plane message to query | Map-Request: A LISP Map-Request is a Control-Plane message to query | |||
the mapping system to resolve an EID. A LISP Map-Request can also | the mapping system to resolve an EID. A LISP Map-Request can also | |||
be sent to an RLOC to test for reachability and to exchange | be sent to an RLOC to test for reachability and to exchange | |||
security keys between an encapsulator and a decapsulator. This | security keys between an encapsulator and a decapsulator. This | |||
type of Map-Request is also known as an RLOC-Probe Request. | type of Map-Request is also known as an RLOC-Probe Request. | |||
Map-Reply: A LISP Map-Reply is a control-plane message returned in | Map-Reply: A LISP Map-Reply is a Control-Plane message returned in | |||
response to a Map-Request sent to the mapping system when | response to a Map-Request sent to the mapping system when | |||
resolving an EID. A LISP Map-Reply can also be returned by a | resolving an EID. A LISP Map-Reply can also be returned by a | |||
decapsulator in response to a Map-Request sent by an encapsulator | decapsulator in response to a Map-Request sent by an encapsulator | |||
to test for reachability. This type of Map-Reply is known as a | to test for reachability. This type of Map-Reply is known as a | |||
RLOC-Probe Reply. | RLOC-Probe Reply. | |||
Encapsulated Map-Request: A LISP Map-Request carried within an | Encapsulated Map-Request: A LISP Map-Request carried within an | |||
Encapsulated Control Message (ECM), which has an additional LISP | Encapsulated Control Message (ECM), which has an additional LISP | |||
header prepended. Sent to UDP destination port 4342. The "outer" | header prepended. Sent to UDP destination port 4342. The "outer" | |||
addresses are routable IP addresses, also known as RLOCs. Used by | addresses are routable IP addresses, also known as RLOCs. Used by | |||
skipping to change at page 5, line 51 ¶ | skipping to change at page 6, line 5 ¶ | |||
A Map-Server is a device that publishes EID-Prefixes in a LISP | A Map-Server is a device that publishes EID-Prefixes in a LISP | |||
mapping database on behalf of a set of ETRs. When it receives a Map | mapping database on behalf of a set of ETRs. When it receives a Map | |||
Request (typically from an ITR), it consults the mapping database to | Request (typically from an ITR), it consults the mapping database to | |||
find an ETR that can answer with the set of RLOCs for an EID-Prefix. | find an ETR that can answer with the set of RLOCs for an EID-Prefix. | |||
To publish its EID-Prefixes, an ETR periodically sends Map-Register | To publish its EID-Prefixes, an ETR periodically sends Map-Register | |||
messages to the Map-Server. A Map-Register message contains a list | messages to the Map-Server. A Map-Register message contains a list | |||
of EID-Prefixes plus a set of RLOCs that can be used to reach the | of EID-Prefixes plus a set of RLOCs that can be used to reach the | |||
ETRs. | ETRs. | |||
When LISP+ALT is used as the mapping database, a Map-Server connects | When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server | |||
to the ALT network and acts as a "last-hop" ALT-Router. Intermediate | connects to the ALT network and acts as a "last-hop" ALT-Router. | |||
ALT-Routers forward Map-Requests to the Map-Server that advertises a | Intermediate ALT-Routers forward Map-Requests to the Map-Server that | |||
particular EID-Prefix, and the Map-Server forwards them to the owning | advertises a particular EID-Prefix, and the Map-Server forwards them | |||
ETR, which responds with Map-Reply messages. | to the owning ETR, which responds with Map-Reply messages. | |||
When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server | When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server | |||
sends the final Map-Referral messages from the Delegated Database | sends the final Map-Referral messages from the Delegated Database | |||
Tree. | Tree. | |||
A Map-Resolver receives Encapsulated Map-Requests from its client | A Map-Resolver receives Encapsulated Map-Requests from its client | |||
ITRs and uses a mapping database system to find the appropriate ETR | ITRs and uses a mapping database system to find the appropriate ETR | |||
to answer those requests. On a LISP+ALT network, a Map-Resolver acts | to answer those requests. On a LISP-ALT network, a Map-Resolver acts | |||
as a "first-hop" ALT-Router. It has Generic Routing Encapsulation | as a "first-hop" ALT-Router. It has Generic Routing Encapsulation | |||
(GRE) tunnels configured to other ALT-Routers and uses BGP to learn | (GRE) tunnels configured to other ALT-Routers and uses BGP to learn | |||
paths to ETRs for different prefixes in the LISP+ALT database. The | paths to ETRs for different prefixes in the LISP-ALT database. The | |||
Map-Resolver uses this path information to forward Map-Requests over | Map-Resolver uses this path information to forward Map-Requests over | |||
the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- | the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- | |||
Resolver maintains a referral-cache and acts as a "first-hop" DDT- | Resolver maintains a referral-cache and acts as a "first-hop" DDT- | |||
node. The Map-Resolver uses the referral information to forward Map- | node. The Map-Resolver uses the referral information to forward Map- | |||
Requests. | Requests. | |||
Note that while it is conceivable that a Map-Resolver could cache | Note that while it is conceivable that a Map-Resolver could cache | |||
responses to improve performance, issues surrounding cache management | responses to improve performance, issues surrounding cache management | |||
will need to be resolved so that doing so will be reliable and | will need to be resolved so that doing so will be reliable and | |||
practical. As initially deployed, Map-Resolvers will operate only in | practical. As initially deployed, Map-Resolvers will operate only in | |||
a non-caching mode, decapsulating and forwarding Encapsulated Map | a non-caching mode, decapsulating and forwarding Encapsulated Map | |||
Requests received from ITRs. Any specification of caching | Requests received from ITRs. Any specification of caching | |||
functionality is left for future work. | functionality is out of scope for this document. | |||
Note that a single device can implement the functions of both a Map- | Note that a single device can implement the functions of both a Map- | |||
Server and a Map-Resolver, and in many cases the functions will be | Server and a Map-Resolver, and in many cases the functions will be | |||
co-located in that way. Also, there can be ALT-only nodes and DDT- | co-located in that way. Also, there can be ALT-only nodes and DDT- | |||
only nodes, when LISP+ALT and LISP-DDT are used, respectively, to | only nodes, when LISP-ALT and LISP-DDT are used, respectively, to | |||
connect Map-Resolvers and Map-Servers together to make up the Mapping | connecting Map-Resolvers and Map-Servers together to make up the | |||
System. | Mapping System. | |||
Detailed descriptions of the LISP packet types referenced by this | ||||
document may be found in [I-D.ietf-lisp-rfc6830bis]. | ||||
5. LISP IPv4 and IPv6 Control-Plane Packet Formats | 5. LISP IPv4 and IPv6 Control-Plane Packet Formats | |||
The following UDP packet formats are used by the LISP control plane. | The following UDP packet formats are used by the LISP control plane. | |||
0 1 2 3 | 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 | 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 |Type of Service| Total Length | | |Version| IHL |Type of Service| Total Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 31 ¶ | |||
source port of either the Map-Request or the invoking data packet. | source port of either the Map-Request or the invoking data packet. | |||
Implementations MUST be prepared to accept packets when either the | Implementations MUST be prepared to accept packets when either the | |||
source port or destination UDP port is set to 4342 due to NATs | source port or destination UDP port is set to 4342 due to NATs | |||
changing port number values. | changing port number values. | |||
The 'UDP Length' field will reflect the length of the UDP header and | The 'UDP Length' field will reflect the length of the UDP header and | |||
the LISP Message payload. | the LISP Message payload. | |||
The UDP checksum is computed and set to non-zero for all messages | The UDP checksum is computed and set to non-zero for all messages | |||
sent to or from port 4342. It MUST be checked on receipt, and if the | sent to or from port 4342. It MUST be checked on receipt, and if the | |||
checksum fails, the control message MUST be dropped. | checksum fails, the control message MUST be dropped [RFC1071]. | |||
The format of control messages includes the UDP header so the | The format of control messages includes the UDP header so the | |||
checksum and length fields can be used to protect and delimit message | checksum and length fields can be used to protect and delimit message | |||
boundaries. | boundaries. | |||
5.1. LISP Control Packet Type Allocations | 5.1. LISP Control Packet Type Allocations | |||
This section defines the LISP control message formats and summarizes | This section defines the LISP control message formats and summarizes | |||
for IANA the LISP Type codes assigned by this document. For | for IANA the LISP Type codes assigned by this document. For | |||
completeness, this document references the LISP Shared Extension | completeness, this document references the LISP Shared Extension | |||
skipping to change at page 9, line 31 ¶ | skipping to change at page 9, line 31 ¶ | |||
LISP Shared Extension Message: 15 b'1111' [RFC8113] | LISP Shared Extension Message: 15 b'1111' [RFC8113] | |||
Values in the "Not Assigned" range can be assigned according to | Values in the "Not Assigned" range can be assigned according to | |||
procedures in [RFC8126]. Documents that request for a new LISP | procedures in [RFC8126]. Documents that request for a new LISP | |||
packet type MAY indicate a preferred value in Section 10.4. | packet type MAY indicate a preferred value in Section 10.4. | |||
Protocol designers experimenting with new message formats SHOULD use | Protocol designers experimenting with new message formats SHOULD use | |||
the LISP Shared Extension Message Type and request a [RFC8113] sub- | the LISP Shared Extension Message Type and request a [RFC8113] sub- | |||
type assignment. | type assignment. | |||
All LISP control-plane messages use Address Family Identifiers (AFI) | All LISP Control-Plane messages use Address Family Identifiers (AFI) | |||
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to | [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to | |||
encode either fixed or variable length addresses. This includes | encode either fixed or variable length addresses. This includes | |||
explicit fields in each control message or part of EID-records or | explicit fields in each control message or part of EID-records or | |||
RLOC-records in commonly formatted messages. | RLOC-records in commonly formatted messages. | |||
The LISP control-plane describes how other data-planes can encode | The LISP control-plane describes how other data-planes can encode | |||
messages to support the SMR and RLOC-probing procedures of the LISP | messages to support the SMR and RLOC-probing procedures. | |||
data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane | ||||
specification itself does not offer such functionality and other | ||||
data-planes can use their own mechanisms that do not rely on the LISP | ||||
control-plane. | ||||
5.2. Map-Request Message Format | 5.2. Map-Request Message Format | |||
0 1 2 3 | 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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | | |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Nonce . . . | | | Nonce . . . | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 10, line 47 ¶ | skipping to change at page 10, line 47 ¶ | |||
destination site to return the Map-Reply rather than the mapping | destination site to return the Map-Reply rather than the mapping | |||
database system. | database system. | |||
M: This is the map-data-present bit. When set, it indicates that a | M: This is the map-data-present bit. When set, it indicates that a | |||
Map-Reply Record segment is included in the Map-Request. | Map-Reply Record segment is included in the Map-Request. | |||
P: This is the probe-bit, which indicates that a Map-Request SHOULD | P: This is the probe-bit, which indicates that a Map-Request SHOULD | |||
be treated as a Locator reachability probe. The receiver SHOULD | be treated as a Locator reachability probe. The receiver SHOULD | |||
respond with a Map-Reply with the probe-bit set, indicating that | respond with a Map-Reply with the probe-bit set, indicating that | |||
the Map-Reply is a Locator reachability probe reply, with the | the Map-Reply is a Locator reachability probe reply, with the | |||
nonce copied from the Map-Request. See RLOC-Probing | nonce copied from the Map-Request. See RLOC-Probing Section 7.1 | |||
[I-D.ietf-lisp-rfc6830bis] for more details. | for more details. | |||
S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- | S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- | |||
Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. | Request (SMRs) Section 6.1 for details. | |||
p: This is the PITR bit. This bit is set to 1 when a PITR sends a | p: This is the PITR bit. This bit is set to 1 when a PITR sends a | |||
Map-Request. | Map-Request. | |||
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | |||
sending a Map-Request in response to a received SMR-based Map- | sending a Map-Request in response to a received SMR-based Map- | |||
Request. | Request. | |||
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that | m: This is the LISP mobile-node m-bit. This bit is set by xTRs that | |||
operate as a mobile node as defined in [I-D.ietf-lisp-mn]. | operate as a mobile node as defined in [I-D.ietf-lisp-mn]. | |||
I: This is the xTR-ID bit. When this bit is set, what is appended to | I: This is the xTR-ID bit. When this bit is set, what is appended to | |||
the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage | the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage | |||
procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. | procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. | |||
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | |||
receipt. | receipt. | |||
L: This is the local-xtr bit. It is used by an xTR in a LISP site to | L: This is the local-xtr bit. It is used by an xTR in a LISP site to | |||
tell other xTRs in the same site that it is local to the site. | tell other xTRs in the same site that it is part of the RLOC-set | |||
That is, that it is part of the RLOC-set for the LISP site. | for the LISP site. The L-bit is set to 1 when the RLOC is the | |||
sender's IP address. | ||||
D: This is the dont-map-reply bit. It is used in the SMR procedure | D: This is the dont-map-reply bit. It is used in the SMR procedure | |||
described in [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR | described in Section 6.1. When an xTR sends an SMR Map-Request | |||
Map-Request message, it doesn't need a Map-Reply returned. When | message, it doesn't need a Map-Reply returned. When this bit is | |||
this bit is set, the receiver of the Map-Request does not return a | set, the receiver of the Map-Request does not return a Map-Reply. | |||
Map-Reply. | ||||
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the | IRC: This 5-bit field is the ITR-RLOC Count, which encodes the | |||
additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields | additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields | |||
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- | present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- | |||
Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields | Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields | |||
are used, so a Map-Replier can select which destination address to | are used, so a Map-Replier can select which destination address to | |||
use for a Map-Reply. The IRC value ranges from 0 to 31. For a | use for a Map-Reply. The IRC value ranges from 0 to 31. For a | |||
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, | value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, | |||
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which | there are 2 ITR-RLOC addresses encoded, and so on up to 31, which | |||
encodes a total of 32 ITR-RLOC addresses. | encodes a total of 32 ITR-RLOC addresses. | |||
skipping to change at page 13, line 46 ¶ | skipping to change at page 13, line 46 ¶ | |||
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be | ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be | |||
found in Section 5.8. | found in Section 5.8. | |||
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- | Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- | |||
Request for the same EID-Prefix be sent no more than once per second. | Request for the same EID-Prefix be sent no more than once per second. | |||
An ITR that is configured with mapping database information (i.e., it | An ITR that is configured with mapping database information (i.e., it | |||
is also an ETR) MAY optionally include those mappings in a Map- | is also an ETR) MAY optionally include those mappings in a Map- | |||
Request. When an ETR configured to accept and verify such | Request. When an ETR configured to accept and verify such | |||
"piggybacked" mapping data receives such a Map-Request and it does | "piggybacked" mapping data receives such a Map-Request and it does | |||
not have this mapping in the map-cache, it MAY originate a "verifying | not have this mapping in the Map-Cache, it MAY originate a "verifying | |||
Map-Request", addressed to the map-requesting ITR and the ETR MAY add | Map-Request", addressed to the map-requesting ITR and the ETR MAY add | |||
a Map-Cache entry. If the ETR has a Map-Cache entry that matches the | a Map-Cache entry. If the ETR has a Map-Cache entry that matches the | |||
"piggybacked" EID and the RLOC is in the Locator-Set for the entry, | "piggybacked" EID and the RLOC is in the Locator-Set for the entry, | |||
then it MAY send the "verifying Map-Request" directly to the | then it MAY send the "verifying Map-Request" directly to the | |||
originating Map-Request source. If the RLOC is not in the Locator- | originating Map-Request source. If the RLOC is not in the Locator- | |||
Set, then the ETR MUST send the "verifying Map-Request" to the | Set, then the ETR MUST send the "verifying Map-Request" to the | |||
"piggybacked" EID. Doing this forces the "verifying Map-Request" to | "piggybacked" EID. Doing this forces the "verifying Map-Request" to | |||
go through the mapping database system to reach the authoritative | go through the mapping database system to reach the authoritative | |||
source of information about that EID, guarding against RLOC-spoofing | source of information about that EID, guarding against RLOC-spoofing | |||
in the "piggybacked" mapping data. | in the "piggybacked" mapping data. | |||
skipping to change at page 15, line 38 ¶ | skipping to change at page 15, line 38 ¶ | |||
| \| Locator | | | \| Locator | | |||
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Packet field descriptions: | Packet field descriptions: | |||
Type: 2 (Map-Reply) | Type: 2 (Map-Reply) | |||
P: This is the probe-bit, which indicates that the Map-Reply is in | P: This is the probe-bit, which indicates that the Map-Reply is in | |||
response to a Locator reachability probe Map-Request. The 'Nonce' | response to a Locator reachability probe Map-Request. The 'Nonce' | |||
field MUST contain a copy of the nonce value from the original | field MUST contain a copy of the nonce value from the original | |||
Map-Request. See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more | Map-Request. See RLOC-probing Section 7.1 for more details. When | |||
details. | the probe-bit is set to 1 in a Map-Reply message, the A-bit in | |||
each EID-record included in the message MUST be set to 1. | ||||
E: This bit indicates that the ETR that sends this Map-Reply message | E: This bit indicates that the ETR that sends this Map-Reply message | |||
is advertising that the site is enabled for the Echo-Nonce Locator | is advertising that the site is enabled for the Echo-Nonce Locator | |||
reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] | reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] | |||
for more details. | for more details. | |||
S: This is the Security bit. When set to 1, the following | S: This is the Security bit. When set to 1, the following | |||
authentication information will be appended to the end of the Map- | authentication information will be appended to the end of the Map- | |||
Reply. The details of signing a Map-Reply message can be found in | Reply. The details of signing a Map-Reply message can be found in | |||
[I-D.ietf-lisp-sec]. | [I-D.ietf-lisp-sec]. | |||
skipping to change at page 16, line 19 ¶ | skipping to change at page 16, line 19 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Reserved: This field MUST be set to 0 on transmit and MUST be | Reserved: This field MUST be set to 0 on transmit and MUST be | |||
ignored on receipt. | ignored on receipt. | |||
Record Count: This is the number of records in this reply message. | Record Count: This is the number of records in this reply message. | |||
A record is comprised of that portion of the packet labeled | A record is comprised of that portion of the packet labeled | |||
'Record' above and occurs the number of times equal to Record | 'Record' above and occurs the number of times equal to Record | |||
Count. | Count. | |||
Nonce: This is a 24-bit value set in a Data-Probe packet, or a | Nonce: This is a 24-bit value set in a Data-Probe | |||
64-bit value from the Map-Request is echoed in this 'Nonce' field | [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request | |||
of the Map-Reply. When a 24-bit value is supplied, it resides in | is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit | |||
the low-order 64 bits of the 'Nonce' field. | value is supplied, it resides in the low-order 64 bits of the | |||
'Nonce' field. | ||||
Record TTL: This is the time in minutes the recipient of the Map- | Record TTL: This is the time in minutes the recipient of the Map- | |||
Reply will store the mapping. If the TTL is 0, the entry SHOULD | Reply will store the mapping. If the TTL is 0, the entry MUST be | |||
be removed from the cache immediately. If the value is | removed from the cache immediately. If the value is 0xffffffff, | |||
0xffffffff, the recipient can decide locally how long to store the | the recipient can decide locally how long to store the mapping. | |||
mapping. | ||||
Locator Count: This is the number of Locator entries. A Locator | Locator Count: This is the number of Locator entries. A Locator | |||
entry comprises what is labeled above as 'Loc'. The Locator count | entry comprises what is labeled above as 'Loc'. The Locator count | |||
can be 0, indicating that there are no Locators for the EID- | can be 0, indicating that there are no Locators for the EID- | |||
Prefix. | Prefix. | |||
EID mask-len: This is the mask length for the EID-Prefix. | EID mask-len: This is the mask length for the EID-Prefix. | |||
ACT: This 3-bit field describes Negative Map-Reply actions. In any | ACT: This 3-bit field describes Negative Map-Reply actions. In any | |||
other message type, these bits are set to 0 and ignored on | other message type, these bits are set to 0 and ignored on | |||
receipt. These bits are used only when the 'Locator Count' field | receipt. These bits are used only when the 'Locator Count' field | |||
is set to 0. The action bits are encoded only in Map-Reply | is set to 0. The action bits are encoded only in Map-Reply | |||
messages. The actions defined are used by an ITR or PITR when a | messages. The actions defined are used by an ITR or PITR when a | |||
destination EID matches a negative Map-Cache entry. Unassigned | destination EID matches a negative Map-Cache entry. Unassigned | |||
values SHOULD cause a Map-Cache entry to be created, and when | values SHOULD cause a Map-Cache entry to be created, and when | |||
packets match this negative cache entry, they will be dropped. | packets match this negative cache entry, they will be dropped. | |||
The current assigned values are: | The current assigned values are: | |||
(0) No-Action: The map-cache is kept alive, and no packet | (0) No-Action: The Map-Cache is kept alive, and no packet | |||
encapsulation occurs. | encapsulation occurs. | |||
(1) Natively-Forward: The packet is not encapsulated or dropped | (1) Natively-Forward: The packet is not encapsulated or dropped | |||
but natively forwarded. | but natively forwarded. | |||
(2) Send-Map-Request: The packet invokes sending a Map-Request. | (2) Send-Map-Request: The packet invokes sending a Map-Request. | |||
(3) Drop/No-Reason: A packet that matches this map-cache entry is | (3) Drop/No-Reason: A packet that matches this Map-Cache entry is | |||
dropped. An ICMP Destination Unreachable message SHOULD be | dropped. An ICMP Destination Unreachable message SHOULD be | |||
sent. | sent. | |||
(4) Drop/Policy-Denied: A packet that matches this map-cache | (4) Drop/Policy-Denied: A packet that matches this Map-Cache | |||
entry is dropped. The reason for the Drop action is that a | entry is dropped. The reason for the Drop action is that a | |||
Map-Request for the target-EID is being policy denied by | Map-Request for the target-EID is being policy denied by | |||
either an xTR or the mapping system. | either an xTR or the mapping system. | |||
(5) Drop/Authentication-Failure: A packet that matches this map- | (5) Drop/Authentication-Failure: A packet that matches this Map- | |||
cache entry is dropped. The reason for the Drop action is | Cache entry is dropped. The reason for the Drop action is | |||
that a Map-Request for the target-EID fails an authentication | that a Map-Request for the target-EID fails an authentication | |||
verification-check by either an xTR or the mapping system. | verification-check by either an xTR or the mapping system. | |||
A: The Authoritative bit, when sent, is always set to 1 by an ETR. | A: The Authoritative bit, when sent, is always set to 1 by an ETR. | |||
When a Map-Server is proxy Map-Replying for a LISP site, the | When a Map-Server is proxy Map-Replying for a LISP site, the | |||
Authoritative bit is set to 0. This indicates to requesting ITRs | Authoritative bit is set to 0. This indicates to requesting ITRs | |||
that the Map-Reply was not originated by a LISP node managed at | that the Map-Reply was not originated by a LISP node managed at | |||
the site that owns the EID-Prefix. | the site that owns the EID-Prefix. | |||
Map-Version Number: When this 12-bit value is non-zero, the Map- | Map-Version Number: When this 12-bit value is non-zero, the Map- | |||
Reply sender is informing the ITR what the version number is for | Reply sender is informing the ITR what the version number is for | |||
the EID record contained in the Map-Reply. The ETR can allocate | the EID record contained in the Map-Reply. The ETR can allocate | |||
this number internally but MUST coordinate this value with other | this number internally but MUST coordinate this value with other | |||
ETRs for the site. When this value is 0, there is no versioning | ETRs for the site. When this value is 0, there is no versioning | |||
information conveyed. The Map-Version Number can be included in | information conveyed. The Map-Version Number can be included in | |||
Map-Request and Map-Register messages. See Map-Versioning | Map-Request and Map-Register messages. See Map-Versioning | |||
[I-D.ietf-lisp-rfc6830bis] for more details. | [RFC6834] for more details. | |||
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] | EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] | |||
and [RFC8060]. | and [RFC8060]. | |||
EID-Prefix: This prefix is 4 octets for an IPv4 address family and | EID-Prefix: This prefix is 4 octets for an IPv4 address family and | |||
16 octets for an IPv6 address family. | 16 octets for an IPv6 address family. | |||
Priority: Each RLOC is assigned a unicast Priority. Lower values | Priority: Each RLOC is assigned a unicast Priority. Lower values | |||
are more preferable. When multiple RLOCs have the same Priority, | are more preferable. When multiple RLOCs have the same Priority, | |||
they MAY be used in a load-split fashion. A value of 255 means | they MAY be used in a load-split fashion. A value of 255 means | |||
skipping to change at page 19, line 5 ¶ | skipping to change at page 19, line 5 ¶ | |||
that the Locator is reachable. The p-bit is set for a single | that the Locator is reachable. The p-bit is set for a single | |||
Locator in the same Locator-Set. If an implementation sets more | Locator in the same Locator-Set. If an implementation sets more | |||
than one p-bit erroneously, the receiver of the Map-Reply MUST | than one p-bit erroneously, the receiver of the Map-Reply MUST | |||
select the first Locator. The p-bit MUST NOT be set for Locator- | select the first Locator. The p-bit MUST NOT be set for Locator- | |||
Set records sent in Map-Request and Map-Register messages. | Set records sent in Map-Request and Map-Register messages. | |||
R: This is set when the sender of a Map-Reply has a route to the | R: This is set when the sender of a Map-Reply has a route to the | |||
Locator in the Locator data record. This receiver MAY find this | Locator in the Locator data record. This receiver MAY find this | |||
useful to know if the Locator is up but not necessarily reachable | useful to know if the Locator is up but not necessarily reachable | |||
from the receiver's point of view. See also EID-Reachability | from the receiver's point of view. See also EID-Reachability | |||
[I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used. | Section 7.1 for another way the R-bit MAY be used. | |||
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- | Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- | |||
AFI' field) assigned to an ETR. Note that the destination RLOC | AFI' field) assigned to an ETR. Note that the destination RLOC | |||
address MAY be an anycast address. A source RLOC can be an | address MAY be an anycast address. A source RLOC can be an | |||
anycast address as well. The source or destination RLOC MUST NOT | anycast address as well. The source or destination RLOC MUST NOT | |||
be the broadcast address (255.255.255.255 or any subnet broadcast | be the broadcast address (255.255.255.255 or any subnet broadcast | |||
address known to the router) and MUST NOT be a link-local | address known to the router) and MUST NOT be a link-local | |||
multicast address. The source RLOC MUST NOT be a multicast | multicast address. The source RLOC MUST NOT be a multicast | |||
address. The destination RLOC SHOULD be a multicast address if it | address. The destination RLOC SHOULD be a multicast address if it | |||
is being mapped from a multicast destination EID. | is being mapped from a multicast destination EID. | |||
5.5. EID-to-RLOC UDP Map-Reply Message | 5.5. EID-to-RLOC UDP Map-Reply Message | |||
A Map-Reply returns an EID-Prefix with a prefix length that is less | A Map-Reply returns an EID-Prefix with a prefix length that is less | |||
than or equal to the EID being requested. The EID being requested is | than or equal to the EID being requested. The EID being requested is | |||
either from the destination field of an IP header of a Data-Probe or | either from the destination field of an IP header of a Data-Probe or | |||
the EID record of a Map-Request. The RLOCs in the Map-Reply are | the EID record of a Map-Request. The RLOCs in the Map-Reply are | |||
routable IP addresses of all ETRs for the LISP site. Each RLOC | routable IP addresses of all ETRs for the LISP site. Each RLOC | |||
conveys status reachability but does not convey path reachability | conveys status reachability but does not convey path reachability | |||
from a requester's perspective. Separate testing of path | from a requester's perspective. Separate testing of path | |||
reachability is required. See RLOC-reachability | reachability is required. See RLOC-reachability Section 7.1 for | |||
[I-D.ietf-lisp-rfc6830bis] for details. | details. | |||
Note that a Map-Reply MAY contain different EID-Prefix granularity | Note that a Map-Reply MAY contain different EID-Prefix granularity | |||
(prefix + length) than the Map-Request that triggers it. This might | (prefix + length) than the Map-Request that triggers it. This might | |||
occur if a Map-Request were for a prefix that had been returned by an | occur if a Map-Request were for a prefix that had been returned by an | |||
earlier Map-Reply. In such a case, the requester updates its cache | earlier Map-Reply. In such a case, the requester updates its cache | |||
with the new prefix information and granularity. For example, a | with the new prefix information and granularity. For example, a | |||
requester with two cached EID-Prefixes that are covered by a Map- | requester with two cached EID-Prefixes that are covered by a Map- | |||
Reply containing one less-specific prefix replaces the entry with the | Reply containing one less-specific prefix replaces the entry with the | |||
less-specific EID-Prefix. Note that the reverse, replacement of one | less-specific EID-Prefix. Note that the reverse, replacement of one | |||
less-specific prefix with multiple more-specific prefixes, can also | less-specific prefix with multiple more-specific prefixes, can also | |||
skipping to change at page 20, line 26 ¶ | skipping to change at page 20, line 26 ¶ | |||
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. | 10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. | |||
Note that not all overlapping EID-Prefixes need to be returned but | Note that not all overlapping EID-Prefixes need to be returned but | |||
only the more-specific entries (note that in the second example above | only the more-specific entries (note that in the second example above | |||
10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the | 10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the | |||
matching EID-Prefix of the requesting EID. When more than one EID- | matching EID-Prefix of the requesting EID. When more than one EID- | |||
Prefix is returned, all SHOULD use the same Time to Live value so | Prefix is returned, all SHOULD use the same Time to Live value so | |||
they can all time out at the same time. When a more-specific EID- | they can all time out at the same time. When a more-specific EID- | |||
Prefix is received later, its Time to Live value in the Map-Reply | Prefix is received later, its Time to Live value in the Map-Reply | |||
record can be stored even when other less-specific entries exist. | record can be stored even when other less-specific entries exist. | |||
When a less-specific EID-Prefix is received later, its map-cache | When a less-specific EID-Prefix is received later, its Map-Cache | |||
expiration time SHOULD be set to the minimum expiration time of any | expiration time SHOULD be set to the minimum expiration time of any | |||
more-specific EID-Prefix in the map-cache. This is done so the | more-specific EID-Prefix in the Map-Cache. This is done so the | |||
integrity of the EID-Prefix set is wholly maintained and so no more- | integrity of the EID-Prefix set is wholly maintained and so no more- | |||
specific entries are removed from the map-cache while keeping less- | specific entries are removed from the Map-Cache while keeping less- | |||
specific entries. | specific entries. | |||
Map-Replies SHOULD be sent for an EID-Prefix no more often than once | Map-Replies SHOULD be sent for an EID-Prefix no more often than once | |||
per second to the same requesting router. For scalability, it is | per second to the same requesting router. For scalability, it is | |||
expected that aggregation of EID addresses into EID-Prefixes will | expected that aggregation of EID addresses into EID-Prefixes will | |||
allow one Map-Reply to satisfy a mapping for the EID addresses in the | allow one Map-Reply to satisfy a mapping for the EID addresses in the | |||
prefix range, thereby reducing the number of Map-Request messages. | prefix range, thereby reducing the number of Map-Request messages. | |||
Map-Reply records can have an empty Locator-Set. A Negative Map- | Map-Reply records can have an empty Locator-Set. A Negative Map- | |||
Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies | Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies | |||
skipping to change at page 24, line 7 ¶ | skipping to change at page 24, line 7 ¶ | |||
is not currently used for any security function but MAY be in the | is not currently used for any security function but MAY be in the | |||
future as part of an anti-replay solution. | future as part of an anti-replay solution. | |||
Key ID: This is a configured key-id value that corresponds to a | Key ID: This is a configured key-id value that corresponds to a | |||
shared-secret password that is used to authenticate the sender. | shared-secret password that is used to authenticate the sender. | |||
Multiple shared-secrets can be used to roll over keys in a non- | Multiple shared-secrets can be used to roll over keys in a non- | |||
disruptive way. | disruptive way. | |||
Algorithm ID: This is the configured Message Authentication Code | Algorithm ID: This is the configured Message Authentication Code | |||
(MAC) algorithm value used for the authentication function. See | (MAC) algorithm value used for the authentication function. See | |||
Algorithm ID Numbers in the Section 10.4 for codepoint | Algorithm ID Numbers in the Section 10.5 for codepoint | |||
assignments. | assignments. | |||
Authentication Data Length: This is the length in octets of the | Authentication Data Length: This is the length in octets of the | |||
'Authentication Data' field that follows this field. The length | 'Authentication Data' field that follows this field. The length | |||
of the 'Authentication Data' field is dependent on the MAC | of the 'Authentication Data' field is dependent on the MAC | |||
algorithm used. The length field allows a device that doesn't | algorithm used. The length field allows a device that doesn't | |||
know the MAC algorithm to correctly parse the packet. | know the MAC algorithm to correctly parse the packet. | |||
Authentication Data: This is the message digest used from the output | Authentication Data: This is the message digest used from the output | |||
of the MAC algorithm. The entire Map-Register payload is | of the MAC algorithm. The entire Map-Register payload is | |||
authenticated with this field preset to 0. After the MAC is | authenticated with this field preset to 0. After the MAC is | |||
computed, it is placed in this field. Implementations of this | computed, it is placed in this field. Implementations of this | |||
specification MUST include support for HMAC-SHA-1-96 [RFC2404], | specification MUST include support for HMAC-SHA-1-96 [RFC2404], | |||
and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. | and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. | |||
The definition of the rest of the Map-Register can be found in | The definition of the rest of the Map-Register can be found in EID- | |||
Section 5.4. | record description in Section 5.4. | |||
5.7. Map-Notify/Map-Notify-Ack Message Format | 5.7. Map-Notify/Map-Notify-Ack Message Format | |||
This section specifies the encoding format for the Map-Notify and | This section specifies the encoding format for the Map-Notify and | |||
Map-Notify-Ack messages. The messages are sent inside a UDP packet | Map-Notify-Ack messages. The messages are sent inside a UDP packet | |||
with source and destination UDP ports equal to 4342. | with source and destination UDP ports equal to 4342. | |||
The Map-Notify and Map-Notify-Ack message formats are: | The Map-Notify and Map-Notify-Ack message formats are: | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at page 27, line 39 ¶ | skipping to change at page 27, line 39 ¶ | |||
control packet being encapsulated. When the control packet is | control packet being encapsulated. When the control packet is | |||
a Map-Request or Map-Register, the source port is selected by | a Map-Request or Map-Register, the source port is selected by | |||
the ITR/PITR and the destination port is 4342. When the | the ITR/PITR and the destination port is 4342. When the | |||
control packet is a Map-Reply, the source port is 4342 and the | control packet is a Map-Reply, the source port is 4342 and the | |||
destination port is assigned from the source port of the | destination port is assigned from the source port of the | |||
invoking Map-Request. Port number 4341 MUST NOT be assigned to | invoking Map-Request. Port number 4341 MUST NOT be assigned to | |||
either port. The checksum field MUST be non-zero. | either port. The checksum field MUST be non-zero. | |||
LCM: The format is one of the control message formats described in | LCM: The format is one of the control message formats described in | |||
this section. At this time, only Map-Request messages are | this section. At this time, only Map-Request messages are | |||
allowed to be control-plane (ECM) encapsulated. In the future, | allowed to be Control-Plane (ECM) encapsulated. In the future, | |||
PIM Join/Prune messages [RFC6831] might be allowed. | PIM Join/Prune messages [RFC6831] might be allowed. | |||
Encapsulating other types of LISP control messages is for | Encapsulating other types of LISP control messages is for | |||
further study. When Map-Requests are sent for RLOC-Probing | further study. When Map-Requests are sent for RLOC-Probing | |||
purposes (i.e., the probe-bit is set), they MUST NOT be sent | purposes (i.e., the probe-bit is set), they MUST NOT be sent | |||
inside Encapsulated Control Messages. | inside Encapsulated Control Messages. | |||
6. Changing the Contents of EID-to-RLOC Mappings | 6. Changing the Contents of EID-to-RLOC Mappings | |||
In the LISP architecture ITRs/PITRs use a local map-cache to store | In the LISP architecture ITRs/PITRs use a local Map-Cache to store | |||
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a | EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a | |||
mechanism is required to inform ITRs/PITRs that are using such | mechanism is required to inform ITRs/PITRs that are using such | |||
mappings. | mappings. | |||
The LISP data-plane defines several mechanism to update mappings | The LISP Data-Plane defines several mechanism to update mappings | |||
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map | [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map | |||
Request (SMR), a control-plane push-based mechanism. An additional | Request (SMR), a Control-Plane push-based mechanism. An additional | |||
control-plane mechanism based on the Publish/subscribe paradigm is | Control-Plane mechanism based on the Publish/subscribe paradigm is | |||
specified in [I-D.rodrigueznatal-lisp-pubsub]. | specified in [I-D.rodrigueznatal-lisp-pubsub]. | |||
6.1. Solicit-Map-Request (SMR) | 6.1. Solicit-Map-Request (SMR) | |||
Soliciting a Map-Request is a selective way for ETRs, at the site | Soliciting a Map-Request is a selective way for ETRs, at the site | |||
where mappings change, to control the rate they receive requests for | where mappings change, to control the rate they receive requests for | |||
Map-Reply messages. SMRs are also used to tell remote ITRs to update | Map-Reply messages. SMRs are also used to tell remote ITRs to update | |||
the mappings they have cached. | the mappings they have cached. | |||
Since the ETRs don't keep track of remote ITRs that have cached their | Since the ETRs don't keep track of remote ITRs that have cached their | |||
skipping to change at page 29, line 10 ¶ | skipping to change at page 29, line 10 ¶ | |||
message or to the mapping database system. A newly allocated | message or to the mapping database system. A newly allocated | |||
random nonce is selected, and the EID-Prefix used is the one | random nonce is selected, and the EID-Prefix used is the one | |||
copied from the SMR message. If the source Locator is the only | copied from the SMR message. If the source Locator is the only | |||
Locator in the cached Locator-Set, the remote ITR SHOULD send a | Locator in the cached Locator-Set, the remote ITR SHOULD send a | |||
Map-Request to the database mapping system just in case the | Map-Request to the database mapping system just in case the | |||
single Locator has changed and may no longer be reachable to | single Locator has changed and may no longer be reachable to | |||
accept the Map-Request. | accept the Map-Request. | |||
3. The remote ITR MUST rate-limit the Map-Request until it gets a | 3. The remote ITR MUST rate-limit the Map-Request until it gets a | |||
Map-Reply while continuing to use the cached mapping. When | Map-Reply while continuing to use the cached mapping. When | |||
Map-Versioning as described in [I-D.ietf-lisp-rfc6830bis] is | Map-Versioning as described in [RFC6834] is used, an SMR sender | |||
used, an SMR sender can detect if an ITR is using the most up-to- | can detect if an ITR is using the most up-to-date database | |||
date database mapping. | mapping. | |||
4. The ETRs at the site with the changed mapping will reply to the | 4. The ETRs at the site with the changed mapping will reply to the | |||
Map-Request with a Map-Reply message that has a nonce from the | Map-Request with a Map-Reply message that has a nonce from the | |||
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- | SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- | |||
limited. This is important to avoid Map-Reply implosion. | limited. This is important to avoid Map-Reply implosion. | |||
5. The ETRs at the site with the changed mapping record the fact | 5. The ETRs at the site with the changed mapping record the fact | |||
that the site that sent the Map-Request has received the new | that the site that sent the Map-Request has received the new | |||
mapping data in the Map-Cache entry for the remote site so the | mapping data in the Map-Cache entry for the remote site so the | |||
Locator-Status-Bits are reflective of the new mapping for packets | Locator-Status-Bits are reflective of the new mapping for packets | |||
skipping to change at page 29, line 40 ¶ | skipping to change at page 29, line 40 ¶ | |||
Locator-Set for the stored Map-Cache entry, then the responding Map- | Locator-Set for the stored Map-Cache entry, then the responding Map- | |||
Request MUST be sent with an EID destination to the mapping database | Request MUST be sent with an EID destination to the mapping database | |||
system. Since the mapping database system is a more secure way to | system. Since the mapping database system is a more secure way to | |||
reach an authoritative ETR, it will deliver the Map-Request to the | reach an authoritative ETR, it will deliver the Map-Request to the | |||
authoritative source of the mapping data. | authoritative source of the mapping data. | |||
When an ITR receives an SMR-based Map-Request for which it does not | When an ITR receives an SMR-based Map-Request for which it does not | |||
have a cached mapping for the EID in the SMR message, it may not send | have a cached mapping for the EID in the SMR message, it may not send | |||
an SMR-invoked Map-Request. This scenario can occur when an ETR | an SMR-invoked Map-Request. This scenario can occur when an ETR | |||
sends SMR messages to all Locators in the Locator-Set it has stored | sends SMR messages to all Locators in the Locator-Set it has stored | |||
in its map-cache but the remote ITRs that receive the SMR may not be | in its Map-Cache but the remote ITRs that receive the SMR may not be | |||
sending packets to the site. There is no point in updating the ITRs | sending packets to the site. There is no point in updating the ITRs | |||
until they need to send, in which case they will send Map-Requests to | until they need to send, in which case they will send Map-Requests to | |||
obtain a Map-Cache entry. | obtain a Map-Cache entry. | |||
7. Routing Locator Reachability | 7. Routing Locator Reachability | |||
This document defines several control-plane mechanisms for | This document defines several Control-Plane mechanisms for | |||
determining RLOC reachability. Please note that additional data- | determining RLOC reachability. Please note that additional Data- | |||
plane reachability mechanisms are defined in | Plane reachability mechanisms are defined in | |||
[I-D.ietf-lisp-rfc6830bis]. | [I-D.ietf-lisp-rfc6830bis]. | |||
1. An ITR MAY receive an ICMP Network Unreachable or Host | 1. An ITR MAY receive an ICMP Network Unreachable or Host | |||
Unreachable message for an RLOC it is using. This indicates that | Unreachable message for an RLOC it is using. This indicates that | |||
the RLOC is likely down. Note that trusting ICMP messages may | the RLOC is likely down. Note that trusting ICMP messages may | |||
not be desirable, but neither is ignoring them completely. | not be desirable, but neither is ignoring them completely. | |||
Implementations are encouraged to follow current best practices | Implementations are encouraged to follow current best practices | |||
in treating these conditions [I-D.ietf-opsec-icmp-filtering]. | in treating these conditions [I-D.ietf-opsec-icmp-filtering]. | |||
2. When an ITR participates in the routing protocol that operates in | 2. When an ITR participates in the routing protocol that operates in | |||
skipping to change at page 32, line 21 ¶ | skipping to change at page 32, line 21 ¶ | |||
8. Interactions with Other LISP Components | 8. Interactions with Other LISP Components | |||
8.1. ITR EID-to-RLOC Mapping Resolution | 8.1. ITR EID-to-RLOC Mapping Resolution | |||
An ITR is configured with one or more Map-Resolver addresses. These | An ITR is configured with one or more Map-Resolver addresses. These | |||
addresses are "Locators" (or RLOCs) and MUST be routable on the | addresses are "Locators" (or RLOCs) and MUST be routable on the | |||
underlying core network; they MUST NOT need to be resolved through | underlying core network; they MUST NOT need to be resolved through | |||
LISP EID-to-RLOC mapping, as that would introduce a circular | LISP EID-to-RLOC mapping, as that would introduce a circular | |||
dependency. When using a Map-Resolver, an ITR does not need to | dependency. When using a Map-Resolver, an ITR does not need to | |||
connect to any other database mapping system. In particular, the ITR | connect to any other database mapping system. In particular, the ITR | |||
need not connect to the LISP+ALT infrastructure or implement the BGP | need not connect to the LISP-ALT infrastructure or implement the BGP | |||
and GRE protocols that it uses. | and GRE protocols that it uses. | |||
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver | An ITR sends an Encapsulated Map-Request to a configured Map-Resolver | |||
when it needs an EID-to-RLOC mapping that is not found in its local | when it needs an EID-to-RLOC mapping that is not found in its local | |||
map-cache. Using the Map-Resolver greatly reduces both the | Map-Cache. Using the Map-Resolver greatly reduces both the | |||
complexity of the ITR implementation and the costs associated with | complexity of the ITR implementation and the costs associated with | |||
its operation. | its operation. | |||
In response to an Encapsulated Map-Request, the ITR can expect one of | In response to an Encapsulated Map-Request, the ITR can expect one of | |||
the following: | the following: | |||
o An immediate Negative Map-Reply (with action code of "Natively- | o An immediate Negative Map-Reply (with action code of "Natively- | |||
Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if | Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if | |||
the Map-Resolver can determine that the requested EID does not | the Map-Resolver can determine that the requested EID does not | |||
exist. The ITR saves the EID-Prefix returned in the Map-Reply in | exist. The ITR saves the EID-Prefix returned in the Map-Reply in | |||
skipping to change at page 33, line 10 ¶ | skipping to change at page 33, line 10 ¶ | |||
matches a non-delegated part of the authoritative EID-Prefix, then | matches a non-delegated part of the authoritative EID-Prefix, then | |||
it is not a LISP EID and a 15-minute TTL is returned. See | it is not a LISP EID and a 15-minute TTL is returned. See | |||
Section 8.2 for discussion of aggregate EID-Prefixes and details | Section 8.2 for discussion of aggregate EID-Prefixes and details | |||
of Map-Server EID-Prefix matching. | of Map-Server EID-Prefix matching. | |||
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or | o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or | |||
possibly from a Map-Server answering on behalf of the ETR. See | possibly from a Map-Server answering on behalf of the ETR. See | |||
Section 8.4 for more details on Map-Resolver message processing. | Section 8.4 for more details on Map-Resolver message processing. | |||
Note that an ITR MAY be configured to both use a Map-Resolver and to | Note that an ITR MAY be configured to both use a Map-Resolver and to | |||
participate in a LISP+ALT logical network. In such a situation, the | participate in a LISP-ALT logical network. In such a situation, the | |||
ITR SHOULD send Map-Requests through the ALT network for any EID- | ITR SHOULD send Map-Requests through the ALT network for any EID- | |||
Prefix learned via ALT BGP. Such a configuration is expected to be | Prefix learned via ALT BGP. Such a configuration is expected to be | |||
very rare, since there is little benefit to using a Map-Resolver if | very rare, since there is little benefit to using a Map-Resolver if | |||
an ITR is already using LISP+ALT. There would be, for example, no | an ITR is already using LISP-ALT. There would be, for example, no | |||
need for such an ITR to send a Map-Request to a possibly non-existent | need for such an ITR to send a Map-Request to a possibly non-existent | |||
EID (and rely on Negative Map-Replies) if it can consult the ALT | EID (and rely on Negative Map-Replies) if it can consult the ALT | |||
database to verify that an EID-Prefix is present before sending that | database to verify that an EID-Prefix is present before sending that | |||
Map-Request. | Map-Request. | |||
8.2. EID-Prefix Configuration and ETR Registration | 8.2. EID-Prefix Configuration and ETR Registration | |||
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP | An ETR publishes its EID-Prefixes on a Map-Server by sending LISP | |||
Map-Register messages. A Map-Register message includes | Map-Register messages. A Map-Register message includes | |||
authentication data, so prior to sending a Map-Register message, the | authentication data, so prior to sending a Map-Register message, the | |||
skipping to change at page 33, line 38 ¶ | skipping to change at page 33, line 38 ¶ | |||
authoritative. Upon receipt of a Map-Register from an ETR, a Map- | authoritative. Upon receipt of a Map-Register from an ETR, a Map- | |||
Server accepts only EID-Prefixes that are configured for that ETR. | Server accepts only EID-Prefixes that are configured for that ETR. | |||
Failure to implement such a check would leave the mapping system | Failure to implement such a check would leave the mapping system | |||
vulnerable to trivial EID-Prefix hijacking attacks. As developers | vulnerable to trivial EID-Prefix hijacking attacks. As developers | |||
and operators gain experience with the mapping system, additional, | and operators gain experience with the mapping system, additional, | |||
stronger security measures MAY be added to the registration process. | stronger security measures MAY be added to the registration process. | |||
In addition to the set of EID-Prefixes defined for each ETR that MAY | In addition to the set of EID-Prefixes defined for each ETR that MAY | |||
register, a Map-Server is typically also configured with one or more | register, a Map-Server is typically also configured with one or more | |||
aggregate prefixes that define the part of the EID numbering space | aggregate prefixes that define the part of the EID numbering space | |||
assigned to it. When LISP+ALT is the database in use, aggregate EID- | assigned to it. When LISP-ALT is the database in use, aggregate EID- | |||
Prefixes are implemented as discard routes and advertised into ALT | Prefixes are implemented as discard routes and advertised into ALT | |||
BGP. The existence of aggregate EID-Prefixes in a Map-Server's | BGP. The existence of aggregate EID-Prefixes in a Map-Server's | |||
database means that it MAY receive Map Requests for EID-Prefixes that | database means that it MAY receive Map Requests for EID-Prefixes that | |||
match an aggregate but do not match a registered prefix; Section 8.3 | match an aggregate but do not match a registered prefix; Section 8.3 | |||
describes how this is handled. | describes how this is handled. | |||
Map-Register messages are sent periodically from an ETR to a Map- | Map-Register messages are sent periodically from an ETR to a Map- | |||
Server with a suggested interval between messages of one minute. A | Server with a suggested interval between messages of one minute. A | |||
Map-Server SHOULD time out and remove an ETR's registration if it has | Map-Server SHOULD time out and remove an ETR's registration if it has | |||
not received a valid Map-Register message within the past | not received a valid Map-Register message within the past | |||
skipping to change at page 34, line 30 ¶ | skipping to change at page 34, line 30 ¶ | |||
how quickly and how frequently a mapping database entry can be | how quickly and how frequently a mapping database entry can be | |||
updated. This MAY have implications for what sorts of mobility can | updated. This MAY have implications for what sorts of mobility can | |||
be supported directly by the mapping system; shorter registration | be supported directly by the mapping system; shorter registration | |||
intervals or other mechanisms might be needed to support faster | intervals or other mechanisms might be needed to support faster | |||
mobility in some cases. For a discussion on one way that faster | mobility in some cases. For a discussion on one way that faster | |||
mobility MAY be implemented for individual devices, please see | mobility MAY be implemented for individual devices, please see | |||
[I-D.ietf-lisp-mn]. | [I-D.ietf-lisp-mn]. | |||
An ETR MAY also request, by setting the "proxy Map-Reply" flag | An ETR MAY also request, by setting the "proxy Map-Reply" flag | |||
(P-bit) in the Map-Register message, that a Map-Server answer Map- | (P-bit) in the Map-Register message, that a Map-Server answer Map- | |||
Requests instead of forwarding them to the ETR. See | Requests instead of forwarding them to the ETR. See Section 7.1 for | |||
[I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets | details on how the Map-Server sets certain flags (such as those | |||
certain flags (such as those indicating whether the message is | indicating whether the message is authoritative and how returned | |||
authoritative and how returned Locators SHOULD be treated) when | Locators SHOULD be treated) when sending a Map-Reply on behalf of an | |||
sending a Map-Reply on behalf of an ETR. When an ETR requests proxy | ETR. When an ETR requests proxy reply service, it SHOULD include all | |||
reply service, it SHOULD include all RLOCs for all ETRs for the EID- | RLOCs for all ETRs for the EID-Prefix being registered, along with | |||
Prefix being registered, along with the routable flag ("R-bit") | the routable flag ("R-bit") setting for each RLOC. The Map-Server | |||
setting for each RLOC. The Map-Server includes all of this | includes all of this information in Map-Reply messages that it sends | |||
information in Map-Reply messages that it sends on behalf of the ETR. | on behalf of the ETR. This differs from a non-proxy registration, | |||
This differs from a non-proxy registration, since the latter need | since the latter need only provide one or more RLOCs for a Map-Server | |||
only provide one or more RLOCs for a Map-Server to use for forwarding | to use for forwarding Map-Requests; the registration information is | |||
Map-Requests; the registration information is not used in Map- | not used in Map-Replies, so it being incomplete is not incorrect. | |||
Replies, so it being incomplete is not incorrect. | ||||
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings | An ETR that uses a Map-Server to publish its EID-to-RLOC mappings | |||
does not need to participate further in the mapping database | does not need to participate further in the mapping database | |||
protocol(s). When using a LISP+ALT mapping database, for example, | protocol(s). When using a LISP-ALT mapping database, for example, | |||
this means that the ETR does not need to implement GRE or BGP, which | this means that the ETR does not need to implement GRE or BGP, which | |||
greatly simplifies its configuration and reduces its cost of | greatly simplifies its configuration and reduces its cost of | |||
operation. | operation. | |||
Note that use of a Map-Server does not preclude an ETR from also | Note that use of a Map-Server does not preclude an ETR from also | |||
connecting to the mapping database (i.e., it could also connect to | connecting to the mapping database (i.e., it could also connect to | |||
the LISP+ALT network), but doing so doesn't seem particularly useful, | the LISP-ALT network), but doing so doesn't seem particularly useful, | |||
as the whole purpose of using a Map-Server is to avoid the complexity | as the whole purpose of using a Map-Server is to avoid the complexity | |||
of the mapping database protocols. | of the mapping database protocols. | |||
8.3. Map-Server Processing | 8.3. Map-Server Processing | |||
Once a Map-Server has EID-Prefixes registered by its client ETRs, it | Once a Map-Server has EID-Prefixes registered by its client ETRs, it | |||
can accept and process Map-Requests for them. | can accept and process Map-Requests for them. | |||
In response to a Map-Request (received over the ALT if LISP+ALT is in | In response to a Map-Request (received over the ALT if LISP-ALT is in | |||
use), the Map-Server first checks to see if the destination EID | use), the Map-Server first checks to see if the destination EID | |||
matches a configured EID-Prefix. If there is no match, the Map- | matches a configured EID-Prefix. If there is no match, the Map- | |||
Server returns a Negative Map-Reply with action code "Natively- | Server returns a Negative Map-Reply with action code "Natively- | |||
Forward" and a 15-minute TTL. This MAY occur if a Map Request is | Forward" and a 15-minute TTL. This MAY occur if a Map Request is | |||
received for a configured aggregate EID-Prefix for which no more- | received for a configured aggregate EID-Prefix for which no more- | |||
specific EID-Prefix exists; it indicates the presence of a non-LISP | specific EID-Prefix exists; it indicates the presence of a non-LISP | |||
"hole" in the aggregate EID-Prefix. | "hole" in the aggregate EID-Prefix. | |||
Next, the Map-Server checks to see if any ETRs have registered the | Next, the Map-Server checks to see if any ETRs have registered the | |||
matching EID-Prefix. If none are found, then the Map-Server returns | matching EID-Prefix. If none are found, then the Map-Server returns | |||
skipping to change at page 36, line 7 ¶ | skipping to change at page 36, line 7 ¶ | |||
Upon receipt of an Encapsulated Map-Request, a Map-Resolver | Upon receipt of an Encapsulated Map-Request, a Map-Resolver | |||
decapsulates the enclosed message and then searches for the requested | decapsulates the enclosed message and then searches for the requested | |||
EID in its local database of mapping entries (statically configured | EID in its local database of mapping entries (statically configured | |||
or learned from associated ETRs if the Map-Resolver is also a Map- | or learned from associated ETRs if the Map-Resolver is also a Map- | |||
Server offering proxy reply service). If it finds a matching entry, | Server offering proxy reply service). If it finds a matching entry, | |||
it returns a LISP Map-Reply with the known mapping. | it returns a LISP Map-Reply with the known mapping. | |||
If the Map-Resolver does not have the mapping entry and if it can | If the Map-Resolver does not have the mapping entry and if it can | |||
determine that the EID is not in the mapping database (for example, | determine that the EID is not in the mapping database (for example, | |||
if LISP+ALT is used, the Map-Resolver will have an ALT forwarding | if LISP-ALT is used, the Map-Resolver will have an ALT forwarding | |||
table that covers the full EID space), it immediately returns a | table that covers the full EID space), it immediately returns a | |||
negative LISP Map-Reply, with action code "Natively-Forward" and a | negative LISP Map-Reply, with action code "Natively-Forward" and a | |||
15-minute TTL. To minimize the number of negative cache entries | 15-minute TTL. To minimize the number of negative cache entries | |||
needed by an ITR, the Map-Resolver SHOULD return the least-specific | needed by an ITR, the Map-Resolver SHOULD return the least-specific | |||
prefix that both matches the original query and does not match any | prefix that both matches the original query and does not match any | |||
EID-Prefix known to exist in the LISP-capable infrastructure. | EID-Prefix known to exist in the LISP-capable infrastructure. | |||
If the Map-Resolver does not have sufficient information to know | If the Map-Resolver does not have sufficient information to know | |||
whether the EID exists, it needs to forward the Map-Request to | whether the EID exists, it needs to forward the Map-Request to | |||
another device that has more information about the EID being | another device that has more information about the EID being | |||
requested. To do this, it forwards the unencapsulated Map-Request, | requested. To do this, it forwards the unencapsulated Map-Request, | |||
with the original ITR RLOC as the source, to the mapping database | with the original ITR RLOC as the source, to the mapping database | |||
system. Using LISP+ALT, the Map-Resolver is connected to the ALT | system. Using LISP-ALT, the Map-Resolver is connected to the ALT | |||
network and sends the Map-Request to the next ALT hop learned from | network and sends the Map-Request to the next ALT hop learned from | |||
its ALT BGP neighbors. The Map-Resolver does not send any response | its ALT BGP neighbors. The Map-Resolver does not send any response | |||
to the ITR; since the source RLOC is that of the ITR, the ETR or Map- | to the ITR; since the source RLOC is that of the ITR, the ETR or Map- | |||
Server that receives the Map-Request over the ALT and responds will | Server that receives the Map-Request over the ALT and responds will | |||
do so directly to the ITR. | do so directly to the ITR. | |||
8.4.1. Anycast Map-Resolver Operation | 8.4.1. Anycast Map-Resolver Operation | |||
A Map-Resolver can be set up to use "anycast", where the same address | A Map-Resolver can be set up to use "anycast", where the same address | |||
is assigned to multiple Map-Resolvers and is propagated through IGP | is assigned to multiple Map-Resolvers and is propagated through IGP | |||
skipping to change at page 37, line 16 ¶ | skipping to change at page 37, line 16 ¶ | |||
messages does not provide protection against "replay" attacks by a | messages does not provide protection against "replay" attacks by a | |||
"man-in-the-middle". Additional work is needed in this area. | "man-in-the-middle". Additional work is needed in this area. | |||
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin | [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin | |||
authentication, integrity, anti-replay protection, and prevention of | authentication, integrity, anti-replay protection, and prevention of | |||
man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- | man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- | |||
Reply exchange. Work is ongoing on this and other proposals for | Reply exchange. Work is ongoing on this and other proposals for | |||
resolving these open security issues. | resolving these open security issues. | |||
While beyond the scope of securing an individual Map-Server or Map- | While beyond the scope of securing an individual Map-Server or Map- | |||
Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if | Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if | |||
ALT is used as the mapping database infrastructure) can take | ALT is used as the mapping database infrastructure) can take | |||
advantage of standards work on adding security to BGP. | advantage of standards work on adding security to BGP. | |||
A complete LISP threat analysis has been published in [RFC7835]. | A complete LISP threat analysis has been published in [RFC7835]. | |||
Please refer to it for more security related details. | Please refer to it for more security related details. | |||
10. IANA Considerations | 10. IANA Considerations | |||
This section provides guidance to the Internet Assigned Numbers | This section provides guidance to the Internet Assigned Numbers | |||
Authority (IANA) regarding registration of values related to this | Authority (IANA) regarding registration of values related to this | |||
LISP control-plane specification, in accordance with BCP 26 | LISP Control-Plane specification, in accordance with BCP 26 | |||
[RFC8126]. | [RFC8126]. | |||
There are three namespaces (listed in the sub-sections below) in LISP | There are three namespaces (listed in the sub-sections below) in LISP | |||
that have been registered. | that have been registered. | |||
o LISP IANA registry allocations SHOULD NOT be made for purposes | o LISP IANA registry allocations SHOULD NOT be made for purposes | |||
unrelated to LISP routing or transport protocols. | unrelated to LISP routing or transport protocols. | |||
o The following policies are used here with the meanings defined in | o The following policies are used here with the meanings defined in | |||
BCP 26: "Specification Required", "IETF Review", "Experimental | BCP 26: "Specification Required", "IETF Review", "Experimental | |||
Use", and "First Come First Served". | Use", and "First Come First Served". | |||
10.1. LISP UDP Port Numbers | 10.1. LISP UDP Port Numbers | |||
The IANA registry has allocated UDP port number 4342 for the LISP | The IANA registry has allocated UDP port number 4342 for the LISP | |||
control-plane. IANA has updated the description for UDP port 4342 as | Control-Plane. IANA has updated the description for UDP port 4342 as | |||
follows: | follows: | |||
lisp-control 4342 udp LISP Control Packets | Keyword Port Transport Layer Description | |||
------- ---- --------------- ----------- | ||||
lisp-control 4342 udp LISP Control Packets | ||||
10.2. LISP Packet Type Codes | 10.2. LISP Packet Type Codes | |||
It is being requested that the IANA be authoritative for LISP Packet | It is being requested that the IANA be authoritative for LISP Packet | |||
Type definitions and that it refers to this document as well as | Type definitions and that it refers to this document as well as | |||
[RFC8113] as references. | [RFC8113] as references. | |||
Based on deployment experience of [RFC6830], the Map-Notify-Ack | Based on deployment experience of [RFC6830], the Map-Notify-Ack | |||
message, message type 5, was added to this document. This document | message, message type 5, was added to this document. This document | |||
requests IANA to add it to the LISP Packet Type Registry. | requests IANA to add it to the LISP Packet Type Registry. | |||
Name Number Defined in | ||||
---- ------ ----------- | ||||
LISP Map-Notify-Ack 5 RFC6833bis | ||||
10.3. LISP ACT and Flag Fields | 10.3. LISP ACT and Flag Fields | |||
New ACT values can be allocated through IETF review or IESG approval. | New ACT values can be allocated through IETF review or IESG approval. | |||
Four values have already been allocated by [RFC6830]. This | Four values have already been allocated by [RFC6830]. This | |||
specification changes the name of ACT type 3 value from "Drop" to | specification changes the name of ACT type 3 value from "Drop" to | |||
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ | "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ | |||
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). | Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). | |||
Value Action Description Reference | ||||
----- ------ ----------- --------- | ||||
4 Drop/ A Packet matching this Map-Cache RFC6833bis | ||||
Policy-Denied entry is dropped because the target | ||||
EID is policy-denied by the xTR or | ||||
the mapping system. | ||||
5 Drop/ A Packet matching this Map-Cache RFC6833bis | ||||
Auth-Failure entry is dropped because the | ||||
Map-Request for target EID fails an | ||||
authentication check by the xTR or | ||||
the mapping system. | ||||
In addition, LISP has a number of flag fields and reserved fields, | In addition, LISP has a number of flag fields and reserved fields, | |||
such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New | such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New | |||
bits for flags in these fields can be implemented after IETF review | bits for flags in these fields can be implemented after IETF review | |||
or IESG approval, but these need not be managed by IANA. | or IESG approval, but these need not be managed by IANA. | |||
10.4. LISP Address Type Codes | 10.4. LISP Address Type Codes | |||
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | |||
defines LISP-specific encodings for AFI value 16387. LCAF encodings | defines LISP-specific encodings for AFI value 16387. LCAF encodings | |||
are used for specific use-cases where different address types for | are used for specific use-cases where different address types for | |||
skipping to change at page 38, line 47 ¶ | skipping to change at page 39, line 20 ¶ | |||
10.5. LISP Algorithm ID Numbers | 10.5. LISP Algorithm ID Numbers | |||
In [RFC6830], a request for a "LISP Key ID Numbers" registry was | In [RFC6830], a request for a "LISP Key ID Numbers" registry was | |||
submitted. This document renames the registry to "LISP Algorithm ID | submitted. This document renames the registry to "LISP Algorithm ID | |||
Numbers" and requests the IANA to make the name change. | Numbers" and requests the IANA to make the name change. | |||
The following Algorithm ID values are defined by this specification | The following Algorithm ID values are defined by this specification | |||
as used in any packet type that references a 'Algorithm ID' field: | as used in any packet type that references a 'Algorithm ID' field: | |||
Name Number Defined in | Name Number Defined in | |||
----------------------------------------------- | ----------------------------------------------- | |||
None 0 n/a | None 0 RFC6833bis | |||
HMAC-SHA-1-96 1 [RFC2404] | HMAC-SHA-1-96 1 [RFC2404] | |||
HMAC-SHA-256-128 2 [RFC4868] | HMAC-SHA-256-128 2 [RFC4868] | |||
Number values are in the range of 0 to 255. The allocation of values | Number values are in the range of 0 to 255. The allocation of values | |||
is on a first come first served basis. | is on a first come first served basis. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | ||||
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, | ||||
September 1988, <https://www.rfc-editor.org/info/rfc1071>. | ||||
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within | [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within | |||
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November | ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November | |||
1998, <https://www.rfc-editor.org/info/rfc2404>. | 1998, <https://www.rfc-editor.org/info/rfc2404>. | |||
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | |||
"Randomness Requirements for Security", BCP 106, RFC 4086, | "Randomness Requirements for Security", BCP 106, RFC 4086, | |||
DOI 10.17487/RFC4086, June 2005, | DOI 10.17487/RFC4086, June 2005, | |||
<https://www.rfc-editor.org/info/rfc4086>. | <https://www.rfc-editor.org/info/rfc4086>. | |||
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- | |||
skipping to change at page 39, line 36 ¶ | skipping to change at page 40, line 15 ¶ | |||
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | |||
Locator/ID Separation Protocol (LISP)", RFC 6830, | Locator/ID Separation Protocol (LISP)", RFC 6830, | |||
DOI 10.17487/RFC6830, January 2013, | DOI 10.17487/RFC6830, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6830>. | <https://www.rfc-editor.org/info/rfc6830>. | |||
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The | [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The | |||
Locator/ID Separation Protocol (LISP) for Multicast | Locator/ID Separation Protocol (LISP) for Multicast | |||
Environments", RFC 6831, DOI 10.17487/RFC6831, January | Environments", RFC 6831, DOI 10.17487/RFC6831, January | |||
2013, <https://www.rfc-editor.org/info/rfc6831>. | 2013, <https://www.rfc-editor.org/info/rfc6831>. | |||
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | ||||
Separation Protocol (LISP) Map-Versioning", RFC 6834, | ||||
DOI 10.17487/RFC6834, January 2013, | ||||
<https://www.rfc-editor.org/info/rfc6834>. | ||||
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, | [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, | |||
"Locator/ID Separation Protocol Alternative Logical | "Locator/ID Separation Protocol Alternative Logical | |||
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, | Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, | |||
January 2013, <https://www.rfc-editor.org/info/rfc6836>. | January 2013, <https://www.rfc-editor.org/info/rfc6836>. | |||
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to | [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to | |||
Routing Locator (RLOC) Database", RFC 6837, | Routing Locator (RLOC) Database", RFC 6837, | |||
DOI 10.17487/RFC6837, January 2013, | DOI 10.17487/RFC6837, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6837>. | <https://www.rfc-editor.org/info/rfc6837>. | |||
[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>. | ||||
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | |||
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | |||
February 2017, <https://www.rfc-editor.org/info/rfc8060>. | February 2017, <https://www.rfc-editor.org/info/rfc8060>. | |||
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. | [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. | |||
Smirnov, "Locator/ID Separation Protocol Delegated | Smirnov, "Locator/ID Separation Protocol Delegated | |||
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, | Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8111>. | May 2017, <https://www.rfc-editor.org/info/rfc8111>. | |||
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation | [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation | |||
skipping to change at page 40, line 27 ¶ | skipping to change at page 41, line 16 ¶ | |||
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | |||
NUMBERS http://www.iana.org/assignments/address-family- | NUMBERS http://www.iana.org/assignments/address-family- | |||
numbers/address-family-numbers.xhtml?, Febuary 2007. | numbers/address-family-numbers.xhtml?, Febuary 2007. | |||
[I-D.ermagan-lisp-nat-traversal] | [I-D.ermagan-lisp-nat-traversal] | |||
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, | Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, | |||
F., and C. White, "NAT traversal for LISP", draft-ermagan- | F., and C. White, "NAT traversal for LISP", draft-ermagan- | |||
lisp-nat-traversal-13 (work in progress), September 2017. | lisp-nat-traversal-13 (work in progress), September 2017. | |||
[I-D.herbert-intarea-ila] | ||||
Herbert, T. and P. Lapukhov, "Identifier-locator | ||||
addressing for IPv6", draft-herbert-intarea-ila-01 (work | ||||
in progress), March 2018. | ||||
[I-D.ietf-lisp-eid-mobility] | [I-D.ietf-lisp-eid-mobility] | |||
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | |||
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | |||
Unified Control Plane", draft-ietf-lisp-eid-mobility-01 | Unified Control Plane", draft-ietf-lisp-eid-mobility-01 | |||
(work in progress), November 2017. | (work in progress), November 2017. | |||
[I-D.ietf-lisp-introduction] | [I-D.ietf-lisp-introduction] | |||
Cabellos-Aparicio, A. and D. Saucez, "An Architectural | Cabellos-Aparicio, A. and D. Saucez, "An Architectural | |||
Introduction to the Locator/ID Separation Protocol | Introduction to the Locator/ID Separation Protocol | |||
(LISP)", draft-ietf-lisp-introduction-13 (work in | (LISP)", draft-ietf-lisp-introduction-13 (work in | |||
progress), April 2015. | progress), April 2015. | |||
[I-D.ietf-lisp-mn] | [I-D.ietf-lisp-mn] | |||
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP | Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP | |||
Mobile Node", draft-ietf-lisp-mn-01 (work in progress), | Mobile Node", draft-ietf-lisp-mn-01 (work in progress), | |||
October 2017. | October 2017. | |||
[I-D.ietf-lisp-rfc6830bis] | [I-D.ietf-lisp-rfc6830bis] | |||
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. | |||
Cabellos-Aparicio, "The Locator/ID Separation Protocol | Cabellos-Aparicio, "The Locator/ID Separation Protocol | |||
(LISP)", draft-ietf-lisp-rfc6830bis-09 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-11 (work in progress), | |||
February 2018. | March 2018. | |||
[I-D.ietf-lisp-sec] | [I-D.ietf-lisp-sec] | |||
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | |||
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 | Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 | |||
(work in progress), October 2017. | (work in progress), October 2017. | |||
[I-D.ietf-lisp-signal-free-multicast] | [I-D.ietf-lisp-signal-free-multicast] | |||
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", | Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", | |||
draft-ietf-lisp-signal-free-multicast-08 (work in | draft-ietf-lisp-signal-free-multicast-09 (work in | |||
progress), February 2018. | progress), March 2018. | |||
[I-D.ietf-opsec-icmp-filtering] | [I-D.ietf-opsec-icmp-filtering] | |||
Gont, F., Gont, G., and C. Pignataro, "Recommendations for | Gont, F., Gont, G., and C. Pignataro, "Recommendations for | |||
filtering ICMP messages", draft-ietf-opsec-icmp- | filtering ICMP messages", draft-ietf-opsec-icmp- | |||
filtering-04 (work in progress), July 2013. | filtering-04 (work in progress), July 2013. | |||
[I-D.lewis-lisp-gpe] | [I-D.lewis-lisp-gpe] | |||
Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., | Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., | |||
Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol | Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol | |||
Extension", draft-lewis-lisp-gpe-04 (work in progress), | Extension", draft-lewis-lisp-gpe-04 (work in progress), | |||
skipping to change at page 41, line 46 ¶ | skipping to change at page 42, line 36 ¶ | |||
2015. | 2015. | |||
[I-D.rodrigueznatal-lisp-pubsub] | [I-D.rodrigueznatal-lisp-pubsub] | |||
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | |||
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | |||
Boucadair, M., Jacquenet, C., and s. | Boucadair, M., Jacquenet, C., and s. | |||
stefano.secci@lip6.fr, "Publish/Subscribe Functionality | stefano.secci@lip6.fr, "Publish/Subscribe Functionality | |||
for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in | for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in | |||
progress), March 2018. | progress), March 2018. | |||
[LISP-CONS] | ||||
Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, | ||||
D., and D. Meyer, "LISP-CONS: A Content distribution | ||||
Overlay Network Service for LISP", Work in Progress, April | ||||
2008. | ||||
[RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
DOI 10.17487/RFC2104, February 1997, | DOI 10.17487/RFC2104, February 1997, | |||
<https://www.rfc-editor.org/info/rfc2104>. | <https://www.rfc-editor.org/info/rfc2104>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
skipping to change at page 43, line 12 ¶ | skipping to change at page 44, line 12 ¶ | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The authors would like to thank Greg Schudel, Darrel Lewis, John | The authors would like to thank Greg Schudel, Darrel Lewis, John | |||
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, | Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, | |||
Fabio Maino, and members of the lisp@ietf.org mailing list for their | Fabio Maino, and members of the lisp@ietf.org mailing list for their | |||
feedback and helpful suggestions. | feedback and helpful suggestions. | |||
Special thanks are due to Noel Chiappa for his extensive work on | Special thanks are due to Noel Chiappa for his extensive work and | |||
caching with LISP-CONS, some of which may be used by Map-Resolvers. | thought about caching in Map-Resolvers. | |||
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-rfc6833bis-08 | B.1. Changes to draft-ietf-lisp-rfc6833bis-09 | |||
o Posted March IETF week 2018. | ||||
o Fixed editorial comments submitted by document shepherd Luigi | ||||
Iannone. | ||||
B.2. Changes to draft-ietf-lisp-rfc6833bis-08 | ||||
o Posted March 2018. | o Posted March 2018. | |||
o Added RLOC-probing algorithm. | o Added RLOC-probing algorithm. | |||
o Added Solicit-Map Request algorithm. | o Added Solicit-Map Request algorithm. | |||
o Added several mechanisms (from 6830bis) regarding Routing Locator | o Added several mechanisms (from 6830bis) regarding Routing Locator | |||
Reachability. | Reachability. | |||
o Added port 4342 to IANA Considerations section. | o Added port 4342 to IANA Considerations section. | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-07 | B.3. Changes to draft-ietf-lisp-rfc6833bis-07 | |||
o Posted December 2017. | o Posted December 2017. | |||
o Make it more clear in a couple of places that RLOCs are used to | o Make it more clear in a couple of places that RLOCs are used to | |||
locate ETRs more so than for Map-Server Map-Request forwarding. | locate ETRs more so than for Map-Server Map-Request forwarding. | |||
o Make it clear that "encapsualted" for a control message is an ECM | o Make it clear that "encapsualted" for a control message is an ECM | |||
based message. | based message. | |||
o Make it more clear what messages use source-port 4342 and which | o Make it more clear what messages use source-port 4342 and which | |||
skipping to change at page 44, line 11 ¶ | skipping to change at page 45, line 19 ¶ | |||
Can use othe AFIs then IPv4 and IPv6. | Can use othe AFIs then IPv4 and IPv6. | |||
o Many editorial changes to clarify text. | o Many editorial changes to clarify text. | |||
o Changed some "must", "should", and "may" to capitalized. | o Changed some "must", "should", and "may" to capitalized. | |||
o Added definitions for Map-Request and Map-Reply messages. | o Added definitions for Map-Request and Map-Reply messages. | |||
o Ran document through IDNITs. | o Ran document through IDNITs. | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-06 | B.4. Changes to draft-ietf-lisp-rfc6833bis-06 | |||
o Posted October 2017. | o Posted October 2017. | |||
o Spec the I-bit to include the xTR-ID in a Map-Request message to | o Spec the I-bit to include the xTR-ID in a Map-Request message to | |||
be consistent with the Map-Register message and to anticipate the | be consistent with the Map-Register message and to anticipate the | |||
introduction of pubsub functionality to allow Map-Requests to | introduction of pubsub functionality to allow Map-Requests to | |||
subscribe to RLOC-set changes. | subscribe to RLOC-set changes. | |||
o Updated references for individual submissions that became working | o Updated references for individual submissions that became working | |||
group documents. | group documents. | |||
o Updated references for working group documents that became RFCs. | o Updated references for working group documents that became RFCs. | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-05 | B.5. Changes to draft-ietf-lisp-rfc6833bis-05 | |||
o Posted May 2017. | o Posted May 2017. | |||
o Update IANA Considerations section based on new requests from this | o Update IANA Considerations section based on new requests from this | |||
document and changes from what was requested in [RFC6830]. | document and changes from what was requested in [RFC6830]. | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-04 | B.6. Changes to draft-ietf-lisp-rfc6833bis-04 | |||
o Posted May 2017. | o Posted May 2017. | |||
o Clarify how the Key-ID field is used in Map-Register and Map- | o Clarify how the Key-ID field is used in Map-Register and Map- | |||
Notify messages. Break the 16-bit field into a 8-bit Key-ID field | Notify messages. Break the 16-bit field into a 8-bit Key-ID field | |||
and a 8-bit Algorithm-ID field. | and a 8-bit Algorithm-ID field. | |||
o Move the control-plane codepoints from the IANA Considerations | o Move the Control-Plane codepoints from the IANA Considerations | |||
section of RFC6830bis to the IANA Considerations section of this | section of RFC6830bis to the IANA Considerations section of this | |||
document. | document. | |||
o In the "LISP Control Packet Type Allocations" section, indicate | o In the "LISP Control Packet Type Allocations" section, indicate | |||
how message Types are IANA allocated and how experimental RFC8113 | how message Types are IANA allocated and how experimental RFC8113 | |||
sub-types should be requested. | sub-types should be requested. | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-03 | B.7. Changes to draft-ietf-lisp-rfc6833bis-03 | |||
o Posted April 2017. | o Posted April 2017. | |||
o Add types 9-14 and specify they are not assigned. | o Add types 9-14 and specify they are not assigned. | |||
o Add the "LISP Shared Extension Message" type and point to RFC8113. | o Add the "LISP Shared Extension Message" type and point to RFC8113. | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-02 | B.8. Changes to draft-ietf-lisp-rfc6833bis-02 | |||
o Posted April 2017. | o Posted April 2017. | |||
o Clarify that the LISP control-plane document defines how the LISP | o Clarify that the LISP Control-Plane document defines how the LISP | |||
data-plane uses Map-Requests with either the SMR-bit set or the | Data-Plane uses Map-Requests with either the SMR-bit set or the | |||
P-bit set supporting mapping updates and RLOC-probing. Indicating | P-bit set supporting mapping updates and RLOC-probing. Indicating | |||
that other data-planes can use the same mechanisms or their own | that other Data-Planes can use the same mechanisms or their own | |||
defined mechanisms to achieve the same functionality. | defined mechanisms to achieve the same functionality. | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-01 | B.9. Changes to draft-ietf-lisp-rfc6833bis-01 | |||
o Posted March 2017. | o Posted March 2017. | |||
o Include references to new RFCs published. | o Include references to new RFCs published. | |||
o Remove references to self. | o Remove references to self. | |||
o Change references from RFC6830 to RFC6830bis. | o Change references from RFC6830 to RFC6830bis. | |||
o Add two new action/reasons to a Map-Reply has posted to the LISP | o Add two new action/reasons to a Map-Reply has posted to the LISP | |||
WG mailing list. | WG mailing list. | |||
o In intro section, add refernece to I-D.ietf-lisp-introduction. | o In intro section, add refernece to I-D.ietf-lisp-introduction. | |||
o Removed Open Issues section and references to "experimental". | o Removed Open Issues section and references to "experimental". | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-00 | B.10. Changes to draft-ietf-lisp-rfc6833bis-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 | |||
-rfc6833-00 individual submission. No other changes made. | -rfc6833-00 individual submission. No other changes made. | |||
B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 | B.11. Changes to draft-farinacci-lisp-rfc6833bis-00 | |||
o Posted November 2016. | o Posted November 2016. | |||
o This is the initial draft to turn RFC 6833 into RFC 6833bis. | o This is the initial draft to turn RFC 6833 into RFC 6833bis. | |||
o The document name has changed from the "Locator/ID Separation | o The document name has changed from the "Locator/ID Separation | |||
Protocol (LISP) Map-Server Interface" to the "Locator/ID | Protocol (LISP) Map-Server Interface" to the "Locator/ID | |||
Separation Protocol (LISP) Control-Plane". | Separation Protocol (LISP) Control-Plane". | |||
o The fundamental change was to move the control-plane messages from | o The fundamental change was to move the Control-Plane messages from | |||
RFC 6830 to this document in an effort so any IETF developed or | RFC 6830 to this document in an effort so any IETF developed or | |||
industry created data-plane could use the LISP mapping system and | industry created Data-Plane could use the LISP mapping system and | |||
control-plane. | Control-Plane. | |||
o Update control-plane messages to incorporate what has been | o Update Control-Plane messages to incorporate what has been | |||
implemented in products during the early phase of LISP development | implemented in products during the early phase of LISP development | |||
but wasn't able to make it into RFC6830 and RFC6833 to make the | but wasn't able to make it into RFC6830 and RFC6833 to make the | |||
Experimental RFC deadline. | Experimental RFC deadline. | |||
o Indicate there may be nodes in the mapping system that are not MRs | o Indicate there may be nodes in the mapping system that are not MRs | |||
or MSs, that is a ALT-node or a DDT-node. | or MSs, that is a ALT-node or a DDT-node. | |||
o Include LISP-DDT in Map-Resolver section and explain how they | o Include LISP-DDT in Map-Resolver section and explain how they | |||
maintain a referral-cache. | maintain a referral-cache. | |||
End of changes. 93 change blocks. | ||||
172 lines changed or deleted | 208 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |