draft-ietf-lisp-rfc6833bis-03.txt   draft-ietf-lisp-rfc6833bis-04.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: October 16, 2017 A. Cabellos (Ed.) Expires: November 5, 2017 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
April 14, 2017 May 4, 2017
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-03 draft-ietf-lisp-rfc6833bis-04
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 October 16, 2017. This Internet-Draft will expire on November 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 41 skipping to change at page 2, line 41
4.6. Map-Register Message Format . . . . . . . . . . . . . . . 21 4.6. Map-Register Message Format . . . . . . . . . . . . . . . 21
4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 24 4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 24
4.8. Encapsulated Control Message Format . . . . . . . . . . . 25 4.8. Encapsulated Control Message Format . . . . . . . . . . . 25
5. Interactions with Other LISP Components . . . . . . . . . . . 27 5. Interactions with Other LISP Components . . . . . . . . . . . 27
5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 27
5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28 5.2. EID-Prefix Configuration and ETR Registration . . . . . . 28
5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 30
5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 30
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7.1. Normative References . . . . . . . . . . . . . . . . . . 32 7.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 32
7.2. Informative References . . . . . . . . . . . . . . . . . 33 7.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 32
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36 7.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 33
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 36 7.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 33
B.1. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.2. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . 33
B.3. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 36 8.2. Informative References . . . . . . . . . . . . . . . . . 35
B.4. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 37 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37
B.5. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 37 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 B.1. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 37
B.2. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 37
B.3. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 37
B.4. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 38
B.5. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 38
B.6. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 replacing the addresses currently used by IP with two separate
name spaces: Endpoint IDs (EIDs), used within sites; and Routing name spaces: Endpoint IDs (EIDs), used within sites; and Routing
Locators (RLOCs), used on the transit networks that make up the Locators (RLOCs), used on the transit networks that make up the
Internet infrastructure. To achieve this separation, LISP defines Internet infrastructure. To achieve this separation, LISP defines
protocol mechanisms for mapping from EIDs to RLOCs. In addition, protocol mechanisms for mapping from EIDs to RLOCs. In addition,
skipping to change at page 9, line 7 skipping to change at page 9, line 7
Map-Reply, Map-Register, and Encapsulated Control Message (ECM) Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
control messages. It MUST be checked on receipt, and if the checksum control messages. It MUST be checked on receipt, and if the checksum
fails, the packet MUST be dropped. fails, the packet MUST be dropped.
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.
4.1. LISP Control Packet Type Allocations 4.1. LISP Control Packet Type Allocations
This section will be the authoritative source for allocating LISP This section defines the LISP control message formats and summarizes
Type values and for defining LISP control message formats. For for IANA the LISP Type codes assigned by this document. For
Shared Extension types, see [RFC8113]. Current allocations are: completeness, this document references the LISP Shared Extension
Message assigned by [RFC8113]. Message type definitions are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110' LISP Map-Referral: 6 b'0110'
LISP Info-Request/Reply: 7 b'0111'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
Not Assigned 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- b'1110'
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
procedures in [RFC5226]. Documents that request for a new LISP
packet type may indicate a preferred value in Section 7.3.
Protocol designers experimenting with new message formats should use
the LISP Shared Extension Message Type and request a [RFC8113] sub-
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 of the LISP
data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane
specification itself does not offer such functionality and other specification itself does not offer such functionality and other
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details. Request (SMRs) [I-D.ietf-lisp-rfc6830bis] 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.meyer-lisp-mn]. operate as a mobile node as defined in [I-D.ietf-lisp-mn].
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.
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 local to the site.
That is, that it is part of the RLOC-set for the LISP site. That is, that it is part of the RLOC-set for the LISP site.
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 [I-D.ietf-lisp-rfc6830bis]. When an xTR sends an SMR
skipping to change at page 21, line 22 skipping to change at page 21, line 22
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|I| Reserved |E|T|a|m|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI | c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix | r | EID-Prefix |
skipping to change at page 22, line 31 skipping to change at page 22, line 31
T: This is the use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use-TTL for timeout bit. When set to 1, the xTR wants
the Map-Server to time out registrations based on the value in the the Map-Server to time out registrations based on the value in the
"Record TTL" field of this message. "Record TTL" field of this message.
a: This is the merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the xTR requests to
merge RLOC-records from different xTRs registering the same EID- merge RLOC-records from different xTRs registering the same EID-
record. See signal-free multicast record. See signal-free multicast
[I-D.ietf-lisp-signal-free-multicast] for one use case example. [I-D.ietf-lisp-signal-free-multicast] for one use case example.
m: This is the mobile-node bit. When set to 1, the registering xTR m: This is the mobile-node bit. When set to 1, the registering xTR
supports the procuedures in [I-D.meyer-lisp-mn]. supports the procedures in [I-D.ietf-lisp-mn].
M: This is the want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, an ETR is
requesting a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in response to
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a Map-Register
message. message.
Record Count: This is the number of records in this Map-Register Record Count: This is the number of records in this Map-Register
message. A record is comprised of that portion of the packet message. A record is comprised of that portion of the packet
labeled 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of times equal to
Record Count. Record Count.
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register
messages. Since the Map-Register message is authenticated, the messages. Since the Map-Register message is authenticated, the
'Nonce' field is not currently used for any security function but 'Nonce' field is not currently used for any security function but
may be in the future as part of an anti-replay solution. may be in the future as part of an anti-replay solution.
Key ID: This is a configured ID to find the configured Message Key ID: This is a configured key-id value that corresponds to a
Authentication Code (MAC) algorithm and key value used for the shared-secret password that is used to authenticate the sender.
authentication function. See Key ID Numbers in Multiple shared-secrets can be used to roll over keys in a non-
[I-D.ietf-lisp-rfc6830bis] for codepoint assignments. disruptive way.
Algorithm ID: This is the configured Message Authentication Code
(MAC) algorithm value used for the authentication function. See
Algorithm ID Numbers in the Section 7.3 for codepoint 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
skipping to change at page 24, line 22 skipping to change at page 24, line 22
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=4/5| Reserved | Record Count | |Type=4/5| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-Prefix-AFI | c | Rsvd | Map-Version Number | EID-Prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-Prefix | r | EID-Prefix |
skipping to change at page 29, line 19 skipping to change at page 29, line 19
specified in the original Map-Register message. specified in the original Map-Register message.
Note that a one-minute minimum registration interval during Note that a one-minute minimum registration interval during
maintenance of an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a lower bound on
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.meyer-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
[I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
certain flags (such as those indicating whether the message is certain flags (such as those indicating whether the message is
authoritative and how returned Locators should be treated) when authoritative and how returned Locators should be treated) when
sending a Map-Reply on behalf of an ETR. When an ETR requests proxy sending a Map-Reply on behalf of an ETR. When an ETR requests proxy
reply service, it should include all RLOCs for all ETRs for the EID- reply service, it should include all RLOCs for all ETRs for the EID-
Prefix being registered, along with the routable flag ("R-bit") Prefix being registered, along with the routable flag ("R-bit")
skipping to change at page 32, line 19 skipping to change at page 32, line 19
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.
7. References 7. IANA Considerations
7.1. Normative References This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this
LISP control-plane specification, in accordance with BCP 26
[RFC5226].
There are three namespaces (listed in the sub-sections below) in LISP
that have been registered.
o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served".
7.1. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet
Type definitions and that it refers to this document as well as
[RFC8113] as references.
Based on deployment experience of [RFC6830], the Map-Notify-Ack
message, message type 5, was added to this document. This document
requests IANA to add it to the LISP Packet Type Registry.
7.2. LISP ACT and Flag Fields
New ACT values an be allocated through IETF review or IESG approval.
Four values have already been allocated by this specification.
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
bits for flags in these fields can be implemented after IETF review
or IESG approval, but these need not be managed by IANA.
7.3. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings
are used for specific use-cases where different address types for
EID-records and RLOC-records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is
used for LCAF types, the registry for LCAF types use the
Specification Required policy [RFC5226]. Initial values for the
registry as well as further information can be found in [RFC8060].
7.4. LISP Algorithm ID Numbers
The following Algorithm ID values are defined by this specification
as used in any packet type that references a 'Algorithm ID' field:
Name Number Defined in
-----------------------------------------------
None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis.
8. References
8.1. Normative References
[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, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://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,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 33, line 5 skipping to change at page 34, line 19
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>. <http://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://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, <http://www.rfc-editor.org/info/rfc6831>. 2013, <http://www.rfc-editor.org/info/rfc6831>.
[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, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://www.rfc-editor.org/info/rfc6836>.
skipping to change at page 33, line 47 skipping to change at page 35, line 27
[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, <http://www.rfc-editor.org/info/rfc8060>. February 2017, <http://www.rfc-editor.org/info/rfc8060>.
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", RFC 8113, for Packet Type Allocations", RFC 8113,
DOI 10.17487/RFC8113, March 2017, DOI 10.17487/RFC8113, March 2017,
<http://www.rfc-editor.org/info/rfc8113>. <http://www.rfc-editor.org/info/rfc8113>.
7.2. Informative References 8.2. Informative References
[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-12 (work in progress), March 2017. lisp-nat-traversal-12 (work in progress), March 2017.
skipping to change at page 34, line 21 skipping to change at page 35, line 49
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-09 (work in progress), January 2017. ddt-09 (work in progress), January 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]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-00 (work in progress),
April 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-02 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-02 (work in progress),
April 2017. April 2017.
[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-12 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016. (work in progress), November 2016.
skipping to change at page 34, line 43 skipping to change at page 36, line 27
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-03 (work in draft-ietf-lisp-signal-free-multicast-03 (work in
progress), April 2017. progress), April 2017.
[I-D.lewis-lisp-gpe] [I-D.lewis-lisp-gpe]
Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P.,
Smith, M., and N. Yadav, "LISP Generic Protocol Smith, M., and N. Yadav, "LISP Generic Protocol
Extension", draft-lewis-lisp-gpe-02 (work in progress), Extension", draft-lewis-lisp-gpe-02 (work in progress),
July 2014. July 2014.
[I-D.meyer-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-meyer-lisp-mn-16 (work in progress),
December 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-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-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-02 (work in progress), April 2017. mobility-02 (work in progress), April 2017.
[I-D.quinn-vxlan-gpe] [I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
skipping to change at page 36, line 19 skipping to change at page 37, 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 on Special thanks are due to Noel Chiappa for his extensive work on
caching with LISP-CONS, some of which may be used by Map-Resolvers. caching with LISP-CONS, some of which may be used by 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-03 B.1. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017.
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
and a 8-bit Algorithm-ID field.
o Move the control-plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this
document.
o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested.
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-02 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-01 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-00 B.5. 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.5. Changes to draft-farinacci-lisp-rfc6833bis-00 B.6. 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. 26 change blocks. 
41 lines changed or deleted 148 lines changed or added

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