draft-ietf-lisp-rfc6833bis-20.txt   draft-ietf-lisp-rfc6833bis-21.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: May 8, 2019 UPC/BarcelonaTech Expires: May 7, 2019 UPC/BarcelonaTech
November 4, 2018 November 4, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-20 draft-ietf-lisp-rfc6833bis-21
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 47 skipping to change at page 1, line 47
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 May 8, 2019. This Internet-Draft will expire on May 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 27 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28
5.8. Encapsulated Control Message Format . . . . . . . . . . . 29 5.8. Encapsulated Control Message Format . . . . . . . . . . . 30
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 31 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 32 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 34 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35
8. Interactions with Other LISP Components . . . . . . . . . . . 35 8. Interactions with Other LISP Components . . . . . . . . . . . 36
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 35 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 36 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 37
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 38 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 39
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 39 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 39 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 42 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 43 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44
12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 43 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44
12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 43 12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44
12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 44 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45
12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 44 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45
12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 45 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 48 13.1. Normative References . . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 49 13.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 53 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 54
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 53 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 54
B.1. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 53 B.1. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 54
B.2. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 53 B.2. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 54
B.3. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 53 B.3. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 54
B.4. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 54 B.4. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 55
B.5. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 54 B.5. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 55
B.6. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 54 B.6. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 55
B.7. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 54 B.7. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 55
B.8. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 54 B.8. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 55
B.9. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 55 B.9. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 56
B.10. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 55 B.10. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 56
B.11. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 55 B.11. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 56
B.12. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 55 B.12. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 56
B.13. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 55 B.13. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 56
B.14. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 55 B.14. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 56
B.15. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 56 B.15. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 57
B.16. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 56 B.16. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 57
B.17. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 56 B.17. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 58
B.18. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 57 B.18. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 58
B.19. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 57 B.19. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 58
B.20. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 57 B.20. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 58
B.21. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 57 B.21. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 58
B.22. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 58 B.22. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 B.23. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see
also [I-D.ietf-lisp-introduction]) specifies an architecture and also [I-D.ietf-lisp-introduction]) specifies an architecture and
mechanism for dynamic tunneling by logically separating the addresses mechanism for dynamic tunneling 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
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
skipping to change at page 24, line 11 skipping to change at page 24, line 11
The destination port of a Map-Reply message is copied from the source The destination port of a Map-Reply message is copied from the source
port of the Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source port of the
Map-Reply message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port 4342.
5.6. Map-Register Message Format 5.6. Map-Register Message Format
This section specifies the encoding format for the Map-Register This section specifies the encoding format for the Map-Register
message. The message is sent in UDP with a destination UDP port of message. The message is sent in UDP with a destination UDP port of
4342 and a randomly selected UDP source port number. 4342 and a randomly selected UDP source port number.
The fields below are used in multiple control messages. They are
defined for Map-Register, Map-Notify and Map-Notify-Ack message
types.
The Map-Register message format is: The Map-Register message format is:
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=3 |P|S|R| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
skipping to change at page 25, line 5 skipping to change at page 25, line 8
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a
Map-Register message requesting the Map-Server to proxy a Map- Map-Register message requesting the Map-Server to proxy a Map-
Reply. The Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative Map-Replies on
behalf of the ETR. behalf of the ETR.
S: This is the security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the procedures from
[I-D.ietf-lisp-sec] are supported. [I-D.ietf-lisp-sec] are supported.
I: This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64
bit Site-ID fields are present at the end of the Map-Register
message. If an xTR is configured with an xTR-ID and Site-ID, it
MUST set the I bit to 1 and include its xTR-ID and Site-ID in the
Map-Register messages it generates. The combination of Site-ID
plus xTR-ID uniquely identifies an xTR in a LISP domain and serves
to track its last seen nonce.
Reserved: This unassigned field MUST be set to 0 on transmit and Reserved: This unassigned field MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
E: This is the Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is used by a First-
Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify
based Map-Register is sent by the FHR to the same site xTR that based Map-Register is sent by the FHR to the same site xTR that
propogates the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. The site xTR
keeps state to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the EID has moves
away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case.
skipping to change at page 25, line 50 skipping to change at page 26, line 12
Register message is sent. When a Map-Register acknowledgement is Register message is sent. When a Map-Register acknowledgement is
requested, the nonce is returned by Map-Servers in Map-Notify requested, the nonce is returned by Map-Servers in Map-Notify
messages. Since the entire Map-Register message is authenticated, messages. Since the entire Map-Register message is authenticated,
the 'Nonce' field serves to protect against Map-Register replay the 'Nonce' field serves to protect against Map-Register replay
attacks. An ETR that registers to the mapping system SHOULD store attacks. An ETR that registers to the mapping system SHOULD store
the last nonce sent in persistent storage so when it restarts it the last nonce sent in persistent storage so when it restarts it
can continue using an incrementing nonce. If the the ETR cannot can continue using an incrementing nonce. If the the ETR cannot
support saving the nonce, then when it restarts it MUST use a new support saving the nonce, then when it restarts it MUST use a new
authentication key to register to the mapping system. A Map- authentication key to register to the mapping system. A Map-
Server MUST track and save in persistent storage the last nonce Server MUST track and save in persistent storage the last nonce
received for each ETR that registers to it. If a Map-Register is received for each ETR xTR-ID that registers to it. If a Map-
received with a nonce value that is not greater than the saved Register is received with a nonce value that is not greater than
nonce, it drops the Map-Register message and logs the fact a the saved nonce, it drops the Map-Register message and logs the
replay attack could have occurred. fact a replay attack could have occurred.
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 12.5 for codepoint Algorithm ID Numbers in the Section 12.5 for codepoint
assignments. assignments.
skipping to change at page 26, line 33 skipping to change at page 26, line 43
Authentication Data: This is the output of the MAC algorithm. The Authentication Data: This is the output of the MAC algorithm. The
entire Map-Register payload (from and including the LISP message entire Map-Register payload (from and including the LISP message
type field through the end of the last RLOC record) is type field through the end of the last RLOC record) 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 either HMAC-SHA-1-96 specification MUST include support for either HMAC-SHA-1-96
[RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is
RECOMMENDED. RECOMMENDED.
The definition of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be found in EID-
record description in Section 5.4. record description in Section 5.4. When the I-bit is set, the
following fields are added to the end of thd Map-Register message:
xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register
message, starting after the final Record in the message. The xTR-
ID is used to uniquely identify a xTR. The same xTR-ID value MUST
NOT be used in two different xTRs.
Site-ID: Site-ID is a 64 bit field at the end of the Map- Register
message, following the xTR-ID. Site-ID is used to uniquely
identify to which site the xTR that sent the message belongs.
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 49 skipping to change at page 28, line 49
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 4/5 (Map-Notify/Map-Notify-Ack) Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See the Map-Register section for field descriptions. message. See the Map-Register section for field descriptions.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a Map-Notify
for the sender to stop retransmitting a Map-Notify with the same (solicited or unsolicited) and for the sender to stop retransmitting
nonce. a Map-Notify with the same nonce.
A Map-Server sends an unsolicited Map-Notify message (one that is not A Map-Server sends an unsolicited Map-Notify message (one that is not
used as an acknowledgment to a Map-Register message) that follows the used as an acknowledgment to a Map-Register message) that follows the
Congestion Control And Relability Guideline sections of [RFC8085]. A Congestion Control And Relability Guideline sections of [RFC8085]. A
Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Notify is retransmitted until a Map-Notify-Ack is received by the
Map-Server with the same nonce used in the Map-Notify message. If a Map-Server with the same nonce used in the Map-Notify message. If a
Map-Notify-Ack is never received by the Map-Server, it issues a log Map-Notify-Ack is never received by the Map-Server, it issues a log
message. An implementation SHOULD retransmit up to 3 times at 3 message. An implementation SHOULD retransmit up to 3 times at 3
second retransmission intervals, after which time the retransmission second retransmission intervals, after which time the retransmission
interval is exponentially backed-off for another 3 retransmission interval is exponentially backed-off for another 3 retransmission
skipping to change at page 46, line 26 skipping to change at page 47, line 26
| S | map-reply-S | 6 | Security Bit | | S | map-reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+ +-----------+-------------+--------------+------------------------+
LISP Map-Reply Header Bits LISP Map-Reply Header Bits
Sub-Registry: Map-Register Header Bits [Section 5.6]: Sub-Registry: Map-Register Header Bits [Section 5.6]:
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=3 |P|S|R| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+----------------+--------------+----------------------+ +-----------+----------------+--------------+----------------------+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+-----------+----------------+--------------+----------------------+ +-----------+----------------+--------------+----------------------+
| P | map-register-P | 4 | Proxy Map-Reply Bit | | P | map-register-P | 4 | Proxy Map-Reply Bit |
| S | map-register-S | 5 | LISP-SEC Capable Bit | | S | map-register-S | 5 | LISP-SEC Capable Bit |
| I | map-register-I | 6 | xTR-ID present flag |
+-----------+----------------+--------------+----------------------+ +-----------+----------------+--------------+----------------------+
LISP Map-Register Header Bits LISP Map-Register Header Bits
Sub-Registry: Encapsulated Control Message (ECM) Header Bits Sub-Registry: Encapsulated Control Message (ECM) Header Bits
[Section 5.8]: [Section 5.8]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 53, line 30 skipping to change at page 54, line 30
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The
contributions they offered greatly added to the security, scale, and contributions they offered greatly added to the security, scale, and
robustness of the LISP architecture and protocols. robustness of the LISP architecture and protocols.
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-20 B.1. Changes to draft-ietf-lisp-rfc6833bis-21
o Posted early November 2018.
o Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR-
ID to detect duplicate or replayed Map-Register messages.
B.2. Changes to draft-ietf-lisp-rfc6833bis-20
o Posted late October 2018. o Posted late October 2018.
o Changed description about "reserved" bits to state "reserved and o Changed description about "reserved" bits to state "reserved and
unassigned". unassigned".
o Make it more clear how Map-Register nonce processing is performed o Make it more clear how Map-Register nonce processing is performed
in an ETR and Map-Server. in an ETR and Map-Server.
B.2. Changes to draft-ietf-lisp-rfc6833bis-19 B.3. Changes to draft-ietf-lisp-rfc6833bis-19
o Posted mid October 2018. o Posted mid October 2018.
o Added Fabio text to the Security Considerations section. o Added Fabio text to the Security Considerations section.
B.3. Changes to draft-ietf-lisp-rfc6833bis-18 B.4. Changes to draft-ietf-lisp-rfc6833bis-18
o Posted mid October 2018. o Posted mid October 2018.
o Fixed comments from Eric after more email clarity. o Fixed comments from Eric after more email clarity.
B.4. Changes to draft-ietf-lisp-rfc6833bis-17 B.5. Changes to draft-ietf-lisp-rfc6833bis-17
o Posted early October 2018. o Posted early October 2018.
o Changes to reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th Telechat.
o Added all flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for allocation in IANA
Considersations section. Considersations section.
o Added an applicability statement in section 1 to address security o Added an applicability statement in section 1 to address security
concerns from Telechat. concerns from Telechat.
o Moved m-bit description and IANA request to draft-ietf-lisp-mn. o Moved m-bit description and IANA request to draft-ietf-lisp-mn.
o Moved I-bit description and IANA request to draft-ietf-lisp- o Moved I-bit description and IANA request to draft-ietf-lisp-
pubsub. pubsub.
B.5. Changes to draft-ietf-lisp-rfc6833bis-16 B.6. Changes to draft-ietf-lisp-rfc6833bis-16
o Posted Late-September 2018. o Posted Late-September 2018.
o Re-wrote Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks Albert.
o Added Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA actions.
B.6. Changes to draft-ietf-lisp-rfc6833bis-15 B.7. Changes to draft-ietf-lisp-rfc6833bis-15
o Posted mid-September 2018. o Posted mid-September 2018.
o Changes to reflect comments from Colin and Mirja. o Changes to reflect comments from Colin and Mirja.
B.7. Changes to draft-ietf-lisp-rfc6833bis-14 B.8. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018. o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews. reviews.
B.8. Changes to draft-ietf-lisp-rfc6833bis-13 B.9. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018. o Posted August 2018.
o Final editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for Proposed
Standard. Standard.
o Added section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication. informed of any changes since the last RFC publication.
B.9. Changes to draft-ietf-lisp-rfc6833bis-12 B.10. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018. o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative References.
B.10. Changes to draft-ietf-lisp-rfc6833bis-11 B.11. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018. o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again. ran through IDNITs again.
B.11. Changes to draft-ietf-lisp-rfc6833bis-10 B.12. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March. o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM packet format
description section. description section.
o Say more about when the new Drop actions should be sent. o Say more about when the new Drop actions should be sent.
B.12. Changes to draft-ietf-lisp-rfc6833bis-09 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-08 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-07 B.15. 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 56, line 25 skipping to change at page 57, line 37
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.15. Changes to draft-ietf-lisp-rfc6833bis-06 B.16. 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.16. Changes to draft-ietf-lisp-rfc6833bis-05 B.17. 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.17. Changes to draft-ietf-lisp-rfc6833bis-04 B.18. 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.18. Changes to draft-ietf-lisp-rfc6833bis-03 B.19. 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.19. Changes to draft-ietf-lisp-rfc6833bis-02 B.20. 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.20. Changes to draft-ietf-lisp-rfc6833bis-01 B.21. 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.21. Changes to draft-ietf-lisp-rfc6833bis-00 B.22. 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.22. Changes to draft-farinacci-lisp-rfc6833bis-00 B.23. 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. 34 change blocks. 
85 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/