draft-ietf-lisp-rfc6833bis-09.txt   draft-ietf-lisp-rfc6833bis-10.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 19, 2018 A. Cabellos (Ed.) Expires: September 21, 2018 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
March 18, 2018 March 20, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-09 draft-ietf-lisp-rfc6833bis-10
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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2018. This Internet-Draft will expire on September 21, 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 43 skipping to change at page 2, line 43
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . 38
10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . 39
10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 44 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 44
B.1. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 44 B.1. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 44
B.2. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 44 B.2. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 44
B.3. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 44 B.3. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 44
B.4. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 45 B.4. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 44
B.5. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 45 B.5. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 45
B.6. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 45 B.6. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 45
B.7. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 46 B.7. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 46
B.8. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 46 B.8. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 46
B.9. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 46 B.9. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 46
B.10. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 46 B.10. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 46
B.11. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 47 B.11. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 47
B.12. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 dynamic tunnelling by logically separating the addresses for dynamic tunnelling by logically separating the addresses
currently used by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: Endpoint IDs
(EIDs), used within sites; and Routing Locators (RLOCs), used on the (EIDs), used within sites; and Routing Locators (RLOCs), used on the
transit networks that make up the Internet infrastructure. To transit networks that make up the Internet infrastructure. To
skipping to change at page 5, line 16 skipping to change at page 5, line 16
Map-Resolver: A network infrastructure component that accepts LISP Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated (ECM) Map-Requests, typically from an ITR, and Encapsulated (ECM) Map-Requests, typically from an ITR, and
determines whether or not the destination IP address is part of determines whether or not the destination IP address is part of
the EID namespace; if it is not, a Negative Map-Reply is returned. the EID namespace; if it is not, a Negative Map-Reply is returned.
Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
mapping by consulting a mapping database system. mapping by consulting a mapping database system.
Negative Map-Reply: A LISP Map-Reply that contains an empty Negative Map-Reply: A LISP Map-Reply that contains an empty
Locator-Set. Returned in response to a Map-Request if the Locator-Set. Returned in response to a Map-Request if the
destination EID does not exist in the mapping database. destination EID is not registered in the mapping system, is policy
Typically, this means that the "EID" being requested is an IP denied or fails authentication.
address connected to a non-LISP site.
Map-Register message: A LISP message sent by an ETR to a Map-Server Map-Register message: A LISP message sent by an ETR to a Map-Server
to register its associated EID-Prefixes. In addition to the set to register its associated EID-Prefixes. In addition to the set
of EID-Prefixes to register, the message includes one or more of EID-Prefixes to register, the message includes one or more
RLOCs to reach ETR(s). The Map-Server uses these RLOCs when RLOCs to reach ETR(s). The Map-Server uses these RLOCs when
forwarding Map-Requests (re-formatted as Encapsulated Map- forwarding Map-Requests (re-formatted as Encapsulated Map-
Requests). An ETR MAY request that the Map-Server answer Map- Requests). An ETR MAY request that the Map-Server answer Map-
Requests on its behalf by setting the "proxy Map-Reply" flag Requests on its behalf by setting the "proxy Map-Reply" flag
(P-bit) in the message. (P-bit) in the message.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
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. They are used to tell an ITR or PITR why a empty
destination EID matches a negative Map-Cache entry. Unassigned locator-set was returned from the mapping system and how it stores
values SHOULD cause a Map-Cache entry to be created, and when the map-cache entry.
packets match this negative cache entry, they will be dropped.
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 Map-Cache entry is created and flagged
that any packet matching this entry 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.
skipping to change at page 26, line 21 skipping to change at page 26, line 21
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 | / | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 |S|D|E|M| Reserved | LISP |Type=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) | IH | (uses RLOC or EID addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
skipping to change at page 26, line 43 skipping to change at page 26, line 43
Packet header descriptions: Packet header descriptions:
OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the
source and destination header address fields. source and destination header address fields.
UDP: The outer UDP header with destination port 4342. The source UDP: The outer UDP header with destination port 4342. The source
port is randomly allocated. The checksum field MUST be non- port is randomly allocated. The checksum field MUST be non-
zero. zero.
LH: Type 8 is defined to be a "LISP Encapsulated Control Message", LISP: Type 8 is defined to be a "LISP Encapsulated Control Message",
and what follows is either an IPv4 or IPv6 header as encoded by and what follows is either an IPv4 or IPv6 header as encoded by
the first 4 bits after the 'Reserved' field. the first 4 bits after the 'Reserved' field.
Type: 8 (Encapsulated Control Message (ECM)) Type: 8 (Encapsulated Control Message (ECM))
S: This is the Security bit. When set to 1, the procedures from S: This is the Security bit. When set to 1, the field following
[I-D.ietf-lisp-sec] are followed. the 'Reserved' field will have the following Authentication
Data format and follow the procedures from [I-D.ietf-lisp-sec].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the DDT-bit. When set to 1, the sender is requesting a D: This is the DDT-bit. When set to 1, the sender is requesting a
Map-Referral message to be returned. The details of this Map-Referral message to be returned. The details of this
procedure are described in [RFC8111]. procedure are described in [RFC8111].
E: This is the to-ETR bit. When set to 1, the Map-Server's E: This is the to-ETR bit. When set to 1, the Map-Server's
intention is to forward the ECM to an authoritative ETR. intention is to forward the ECM to an authoritative ETR.
M: This is the to-MS bit. When set to 1, a Map-Request is being M: This is the to-MS bit. When set to 1, a Map-Request is being
sent to a co-located Map-Resolver and Map-Server where the sent to a co-located Map-Resolver and Map-Server where the
message can be processed directly by the Map-Server versus the message can be processed directly by the Map-Server versus the
Map-Resolver using the LISP-DDT procedures in [RFC8111]. Map-Resolver using the LISP-DDT procedures in [RFC8111].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is addresses in the header address fields. When a Map-Request is
encapsulated in this packet format, the destination address in encapsulated in this packet format, the destination address in
this header is an EID. this header is an EID.
UDP: The inner UDP header, where the port assignments depend on the UDP: The inner UDP header, where the port assignments depend on the
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
skipping to change at page 35, line 27 skipping to change at page 35, line 27
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
a Negative Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code "Natively-Forward" and a
1-minute TTL. 1-minute TTL.
If the EID-prefix is either registered or not registered to the
mapping system and there is a policy in the Map-Server to have the
requestor drop packets for the matching EID-prefix, then a Drop/
Policy-Denied action is returned. If the EID-prefix is registered or
not registered and there is a authentication failure, then a Drop/
Authentication- failure action is returned. If either of these
actions result as a temporary state in policy or authentication then
a Send-Map-Request action with 1-minute TTL MAY be returned to allow
the reqeustor to retry the Map-Request.
If any of the registered ETRs for the EID-Prefix have requested proxy If any of the registered ETRs for the EID-Prefix have requested proxy
reply service, then the Map-Server answers the request instead of reply service, then the Map-Server answers the request instead of
forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs,
and other information learned through the registration process. and other information learned through the registration process.
If none of the ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply service, then the Map-
Server re-encapsulates and forwards the resulting Encapsulated Map- Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not otherwise alter
the Map-Request, so any Map-Reply sent by the ETR is returned to the the Map-Request, so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map-Server. Unless also acting RLOC in the Map-Request, not to the Map-Server. Unless also acting
skipping to change at page 41, line 41 skipping to change at page 42, line 8
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-11 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress),
March 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-09 (work in draft-ietf-lisp-signal-free-multicast-09 (work in
skipping to change at page 44, line 19 skipping to change at page 44, line 19
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 and Special thanks are due to Noel Chiappa for his extensive work and
thought about caching in 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-09 B.1. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format
description section.
o Say more about when the new Drop actions should be sent.
B.2. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018. o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi o Fixed editorial comments submitted by document shepherd Luigi
Iannone. Iannone.
B.2. Changes to draft-ietf-lisp-rfc6833bis-08 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-07 B.4. 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 45, line 19 skipping to change at page 45, line 28
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.4. Changes to draft-ietf-lisp-rfc6833bis-06 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-05 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-04 B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-03 B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-02 B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-01 B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-00 B.11. 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.11. Changes to draft-farinacci-lisp-rfc6833bis-00 B.12. 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
 End of changes. 28 change blocks. 
49 lines changed or deleted 69 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/