| < draft-ietf-lisp-rfc6830bis-17.txt | draft-ietf-lisp-rfc6830bis-18.txt > | |||
|---|---|---|---|---|
| Network Working Group D. Farinacci | Network Working Group D. Farinacci | |||
| Internet-Draft V. Fuller | Internet-Draft V. Fuller | |||
| Obsoletes: 6830 (if approved) D. Meyer | Obsoletes: 6830 (if approved) D. Meyer | |||
| Intended status: Standards Track D. Lewis | Intended status: Standards Track D. Lewis | |||
| Expires: March 15, 2019 Cisco Systems | Expires: March 16, 2019 Cisco Systems | |||
| A. Cabellos (Ed.) | A. Cabellos (Ed.) | |||
| UPC/BarcelonaTech | UPC/BarcelonaTech | |||
| September 11, 2018 | September 12, 2018 | |||
| The Locator/ID Separation Protocol (LISP) | The Locator/ID Separation Protocol (LISP) | |||
| draft-ietf-lisp-rfc6830bis-17 | draft-ietf-lisp-rfc6830bis-18 | |||
| Abstract | Abstract | |||
| This document describes the Data-Plane protocol for the Locator/ID | This document describes the Data-Plane protocol for the Locator/ID | |||
| Separation Protocol (LISP). LISP defines two namespaces, End-point | Separation Protocol (LISP). LISP defines two namespaces, End-point | |||
| Identifiers (EIDs) that identify end-hosts and Routing Locators | Identifiers (EIDs) that identify end-hosts and Routing Locators | |||
| (RLOCs) that identify network attachment points. With this, LISP | (RLOCs) that identify network attachment points. With this, LISP | |||
| effectively separates control from data, and allows routers to create | effectively separates control from data, and allows routers to create | |||
| overlay networks. LISP-capable routers exchange encapsulated packets | overlay networks. LISP-capable routers exchange encapsulated packets | |||
| according to EID-to-RLOC mappings stored in a local Map-Cache. | according to EID-to-RLOC mappings stored in a local Map-Cache. | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on March 15, 2019. | This Internet-Draft will expire on March 16, 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 43 ¶ | skipping to change at page 2, line 43 ¶ | |||
| 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 | 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 | |||
| 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 | 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 | |||
| 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 | 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 | |||
| 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 | 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 | |||
| 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 25 | 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 25 | |||
| 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 | 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 | |||
| 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 | 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 | |||
| 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 28 | 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 28 | |||
| 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 | 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 | |||
| 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 30 | 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 30 | |||
| 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 | 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 31 | |||
| 15. Router Performance Considerations . . . . . . . . . . . . . . 31 | 15. Router Performance Considerations . . . . . . . . . . . . . . 31 | |||
| 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | |||
| 17. Network Management Considerations . . . . . . . . . . . . . . 33 | 17. Network Management Considerations . . . . . . . . . . . . . . 33 | |||
| 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 | |||
| 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 33 | 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 | |||
| 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 | |||
| 20.2. Informative References . . . . . . . . . . . . . . . . . 35 | 20.2. Informative References . . . . . . . . . . . . . . . . . 35 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 | |||
| Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 | |||
| B.1. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 40 | B.1. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 40 | |||
| B.2. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 40 | B.2. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 40 | |||
| B.3. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 40 | B.3. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 40 | |||
| B.4. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 40 | B.4. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 40 | |||
| B.5. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 40 | B.5. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 40 | |||
| B.6. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41 | B.6. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 40 | |||
| B.7. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 41 | B.7. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 41 | |||
| B.8. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 41 | B.8. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 41 | |||
| B.9. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 41 | B.9. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 41 | |||
| B.10. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 42 | B.10. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 41 | |||
| B.11. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 42 | B.11. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 42 | |||
| B.12. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 42 | B.12. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 42 | |||
| B.13. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 42 | B.13. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 42 | |||
| B.14. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 43 | B.14. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 42 | |||
| B.15. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 43 | B.15. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 43 | |||
| B.16. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 43 | B.16. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 43 | |||
| B.17. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 43 | B.17. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 43 | |||
| B.18. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 43 | B.18. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 43 | |||
| B.19. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 43 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
| 1. Introduction | 1. Introduction | |||
| This document describes the Locator/Identifier Separation Protocol | This document describes the Locator/Identifier Separation Protocol | |||
| (LISP). LISP is an encapsulation protocol built around the | (LISP). LISP is an encapsulation protocol built around the | |||
| fundamental idea of separating the topological location of a network | fundamental idea of separating the topological location of a network | |||
| attachment point from the node's identity [CHIAPPA]. As a result | attachment point from the node's identity [CHIAPPA]. As a result | |||
| LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | LISP creates two namespaces: Endpoint Identifiers (EIDs), that are | |||
| used to identify end-hosts (e.g., nodes or Virtual Machines) and | used to identify end-hosts (e.g., nodes or Virtual Machines) and | |||
| skipping to change at page 18, line 49 ¶ | skipping to change at page 18, line 49 ¶ | |||
| the case of IPv6) SHOULD be copied from the inner-header 'Time to | the case of IPv6) SHOULD be copied from the inner-header 'Time to | |||
| Live' field. | Live' field. | |||
| o The outer-header 'Differentiated Services Code Point' (DSCP) field | o The outer-header 'Differentiated Services Code Point' (DSCP) field | |||
| (or the 'Traffic Class' field, in the case of IPv6) SHOULD be | (or the 'Traffic Class' field, in the case of IPv6) SHOULD be | |||
| copied from the inner-header DSCP field ('Traffic Class' field, in | copied from the inner-header DSCP field ('Traffic Class' field, in | |||
| the case of IPv6) considering the exception listed below. | the case of IPv6) considering the exception listed below. | |||
| o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | |||
| of the IPv6 'Traffic Class' field) requires special treatment in | of the IPv6 'Traffic Class' field) requires special treatment in | |||
| order to avoid discarding indications of congestion [RFC3168]. | order to avoid discarding indications of congestion [RFC6040]. | |||
| ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | |||
| header to the outer header. Re-encapsulation MUST copy the 2-bit | header to the outer header. Re-encapsulation MUST copy the 2-bit | |||
| 'ECN' field from the stripped outer header to the new outer | 'ECN' field from the stripped outer header to the new outer | |||
| header. | header. | |||
| When doing ETR/PETR decapsulation: | When doing ETR/PETR decapsulation: | |||
| o The inner-header 'Time to Live' field (or 'Hop Limit' field, in | o The inner-header 'Time to Live' field (or 'Hop Limit' field, in | |||
| the case of IPv6) SHOULD be copied from the outer-header 'Time to | the case of IPv6) SHOULD be copied from the outer-header 'Time to | |||
| Live' field, when the Time to Live value of the outer header is | Live' field, when the Time to Live value of the outer header is | |||
| skipping to change at page 19, line 25 ¶ | skipping to change at page 19, line 25 ¶ | |||
| check is also performed when doing initial encapsulation, when a | check is also performed when doing initial encapsulation, when a | |||
| packet comes to an ITR or PITR destined for a LISP site. | packet comes to an ITR or PITR destined for a LISP site. | |||
| o The inner-header 'Differentiated Services Code Point' (DSCP) field | o The inner-header 'Differentiated Services Code Point' (DSCP) field | |||
| (or the 'Traffic Class' field, in the case of IPv6) SHOULD be | (or the 'Traffic Class' field, in the case of IPv6) SHOULD be | |||
| copied from the outer-header DSCP field ('Traffic Class' field, in | copied from the outer-header DSCP field ('Traffic Class' field, in | |||
| the case of IPv6) to the inner-header. | the case of IPv6) to the inner-header. | |||
| o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 | |||
| of the IPv6 'Traffic Class' field) requires special treatment in | of the IPv6 'Traffic Class' field) requires special treatment in | |||
| order to avoid discarding indications of congestion [RFC3168]. If | order to avoid discarding indications of congestion [RFC6040]. If | |||
| the 'ECN' field contains a congestion indication codepoint (the | the 'ECN' field contains a congestion indication codepoint (the | |||
| value is '11', the Congestion Experienced (CE) codepoint), then | value is '11', the Congestion Experienced (CE) codepoint), then | |||
| ETR decapsulation MUST copy the 2-bit 'ECN' field from the | ETR decapsulation MUST copy the 2-bit 'ECN' field from the | |||
| stripped outer header to the surviving inner header that is used | stripped outer header to the surviving inner header that is used | |||
| to forward the packet beyond the ETR. These requirements preserve | to forward the packet beyond the ETR. These requirements preserve | |||
| CE indications when a packet that uses ECN traverses a LISP tunnel | CE indications when a packet that uses ECN traverses a LISP tunnel | |||
| and becomes marked with a CE indication due to congestion between | and becomes marked with a CE indication due to congestion between | |||
| the tunnel endpoints. | the tunnel endpoints. Implementations exist that copy the 'ECN' | |||
| field from the outer header to the inner header even though | ||||
| [RFC6040] does not recommend this behavior. It is RECOMMENDED | ||||
| that implementations change to support the behavior in [RFC6040]. | ||||
| Note that if an ETR/PETR is also an ITR/PITR and chooses to re- | Note that if an ETR/PETR is also an ITR/PITR and chooses to re- | |||
| encapsulate after decapsulating, the net effect of this is that the | encapsulate after decapsulating, the net effect of this is that the | |||
| new outer header will carry the same Time to Live as the old outer | new outer header will carry the same Time to Live as the old outer | |||
| header minus 1. | header minus 1. | |||
| Copying the Time to Live (TTL) serves two purposes: first, it | Copying the Time to Live (TTL) serves two purposes: first, it | |||
| preserves the distance the host intended the packet to travel; | preserves the distance the host intended the packet to travel; | |||
| second, and more importantly, it provides for suppression of looping | second, and more importantly, it provides for suppression of looping | |||
| packets in the event there is a loop of concatenated tunnels due to | packets in the event there is a loop of concatenated tunnels due to | |||
| misconfiguration. | misconfiguration. | |||
| The Explicit Congestion Notification ('ECN') field occupies bits 6 | The Explicit Congestion Notification ('ECN') field occupies bits 6 | |||
| and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic | and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic | |||
| Class' field [RFC3168]. The 'ECN' field requires special treatment | Class' field [RFC6040]. The 'ECN' field requires special treatment | |||
| in order to avoid discarding indications of congestion [RFC3168]. An | in order to avoid discarding indications of congestion [RFC6040]. An | |||
| ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner | |||
| header to the outer header. Re-encapsulation MUST copy the 2-bit | header to the outer header. Re-encapsulation MUST copy the 2-bit | |||
| 'ECN' field from the stripped outer header to the new outer header. | 'ECN' field from the stripped outer header to the new outer header. | |||
| If the 'ECN' field contains a congestion indication codepoint (the | If the 'ECN' field contains a congestion indication codepoint (the | |||
| value is '11', the Congestion Experienced (CE) codepoint), then ETR/ | value is '11', the Congestion Experienced (CE) codepoint), then ETR/ | |||
| PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped | PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped | |||
| outer header to the surviving inner header that is used to forward | outer header to the surviving inner header that is used to forward | |||
| the packet beyond the ETR. These requirements preserve CE | the packet beyond the ETR. These requirements preserve CE | |||
| indications when a packet that uses ECN traverses a LISP tunnel and | indications when a packet that uses ECN traverses a LISP tunnel and | |||
| becomes marked with a CE indication due to congestion between the | becomes marked with a CE indication due to congestion between the | |||
| skipping to change at page 22, line 22 ¶ | skipping to change at page 22, line 25 ¶ | |||
| An ITR stateful solution to handle MTU issues is described as follows | An ITR stateful solution to handle MTU issues is described as follows | |||
| and was first introduced in [OPENLISP]: | and was first introduced in [OPENLISP]: | |||
| 1. The ITR will keep state of the effective MTU for each Locator per | 1. The ITR will keep state of the effective MTU for each Locator per | |||
| Map-Cache entry. The effective MTU is what the core network can | Map-Cache entry. The effective MTU is what the core network can | |||
| deliver along the path between the ITR and ETR. | deliver along the path between the ITR and ETR. | |||
| 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet | 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet | |||
| with the DF bit set to 1, exceeds what the core network can | with the DF bit set to 1, exceeds what the core network can | |||
| deliver, one of the intermediate routers on the path will send an | deliver, one of the intermediate routers on the path will send an | |||
| ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse | ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ | |||
| the ICMPv6 message to determine which Locator is affected by the | Fragmentation-Needed to the ITR, respectively. The ITR will | |||
| effective MTU change and then record the new effective MTU value | parse the ICMP message to determine which Locator is affected by | |||
| in the Map-Cache entry. | the effective MTU change and then record the new effective MTU | |||
| value in the Map-Cache entry. | ||||
| 3. When a packet is received by the ITR from a source inside of the | 3. When a packet is received by the ITR from a source inside of the | |||
| site and the size of the packet is greater than the effective MTU | site and the size of the packet is greater than the effective MTU | |||
| stored with the Map-Cache entry associated with the destination | stored with the Map-Cache entry associated with the destination | |||
| EID the packet is for, the ITR will send an ICMPv6 "Packet Too | EID the packet is for, the ITR will send an ICMPv4 ICMP | |||
| Big" message back to the source. The packet size advertised by | Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" | |||
| the ITR in the ICMPv6 message is the effective MTU minus the LISP | message back to the source. The packet size advertised by the | |||
| ITR in the ICMP message is the effective MTU minus the LISP | ||||
| encapsulation length. | encapsulation length. | |||
| Even though this mechanism is stateful, it has advantages over the | Even though this mechanism is stateful, it has advantages over the | |||
| stateless IP fragmentation mechanism, by not involving the | stateless IP fragmentation mechanism, by not involving the | |||
| destination host with reassembly of ITR fragmented packets. | destination host with reassembly of ITR fragmented packets. | |||
| 8. Using Virtualization and Segmentation with LISP | 8. Using Virtualization and Segmentation with LISP | |||
| There are several cases where segregation is needed at the EID level. | There are several cases where segregation is needed at the EID level. | |||
| For instance, this is the case for deployments containing overlapping | For instance, this is the case for deployments containing overlapping | |||
| skipping to change at page 34, line 19 ¶ | skipping to change at page 34, line 25 ¶ | |||
| 20.1. Normative References | 20.1. Normative References | |||
| [I-D.ietf-lisp-6834bis] | [I-D.ietf-lisp-6834bis] | |||
| Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID | |||
| Separation Protocol (LISP) Map-Versioning", draft-ietf- | Separation Protocol (LISP) Map-Versioning", draft-ietf- | |||
| lisp-6834bis-02 (work in progress), September 2018. | lisp-6834bis-02 (work in progress), September 2018. | |||
| [I-D.ietf-lisp-rfc6833bis] | [I-D.ietf-lisp-rfc6833bis] | |||
| Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | |||
| "Locator/ID Separation Protocol (LISP) Control-Plane", | "Locator/ID Separation Protocol (LISP) Control-Plane", | |||
| draft-ietf-lisp-rfc6833bis-13 (work in progress), August | draft-ietf-lisp-rfc6833bis-14 (work in progress), | |||
| 2018. | September 2018. | |||
| [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
| DOI 10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
| <https://www.rfc-editor.org/info/rfc768>. | <https://www.rfc-editor.org/info/rfc768>. | |||
| [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| DOI 10.17487/RFC0791, September 1981, | DOI 10.17487/RFC0791, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc791>. | <https://www.rfc-editor.org/info/rfc791>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
| "Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
| Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
| DOI 10.17487/RFC2474, December 1998, | DOI 10.17487/RFC2474, December 1998, | |||
| <https://www.rfc-editor.org/info/rfc2474>. | <https://www.rfc-editor.org/info/rfc2474>. | |||
| [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion | |||
| of Explicit Congestion Notification (ECN) to IP", | Notification", RFC 6040, DOI 10.17487/RFC6040, November | |||
| RFC 3168, DOI 10.17487/RFC3168, September 2001, | 2010, <https://www.rfc-editor.org/info/rfc6040>. | |||
| <https://www.rfc-editor.org/info/rfc3168>. | ||||
| [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
| Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
| RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
| <https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| skipping to change at page 40, line 5 ¶ | skipping to change at page 40, line 5 ¶ | |||
| The LISP working group would like to give a special thanks to Jari | The LISP working group would like to give a special thanks to Jari | |||
| Arkko, the Internet Area AD at the time that the set of LISP | Arkko, the Internet Area AD at the time that the set of LISP | |||
| documents were being prepared for IESG last call, and for his | documents were being prepared for IESG last call, and for his | |||
| meticulous reviews and detailed commentaries on the 7 working group | meticulous reviews and detailed commentaries on the 7 working group | |||
| last call documents progressing toward standards-track RFCs. | last call documents progressing toward standards-track RFCs. | |||
| Appendix B. Document Change Log | Appendix B. Document Change Log | |||
| [RFC Editor: Please delete this section on publication as RFC.] | [RFC Editor: Please delete this section on publication as RFC.] | |||
| B.1. Changes to draft-ietf-lisp-rfc6830bis-17 | B.1. Changes to draft-ietf-lisp-rfc6830bis-18 | |||
| o Posted mid-September 2018. | ||||
| o Changes to reflect comments from Secdir review (Mirja). | ||||
| B.2. Changes to draft-ietf-lisp-rfc6830bis-17 | ||||
| o Posted September 2018. | o Posted September 2018. | |||
| o Indicate in the "Changes since RFC 6830" section why the document | o Indicate in the "Changes since RFC 6830" section why the document | |||
| has been shortened in length. | has been shortened in length. | |||
| o Make reference to RFC 8085 about UDP congestion control. | o Make reference to RFC 8085 about UDP congestion control. | |||
| o More editorial changes from multiple IESG reviews. | o More editorial changes from multiple IESG reviews. | |||
| B.2. Changes to draft-ietf-lisp-rfc6830bis-16 | B.3. Changes to draft-ietf-lisp-rfc6830bis-16 | |||
| o Posted late August 2018. | o Posted late August 2018. | |||
| o Distinguish the message type names between ICMP for IPv4 and ICMP | o Distinguish the message type names between ICMP for IPv4 and ICMP | |||
| for IPv6 for handling MTU issues. | for IPv6 for handling MTU issues. | |||
| B.3. Changes to draft-ietf-lisp-rfc6830bis-15 | B.4. Changes to draft-ietf-lisp-rfc6830bis-15 | |||
| o Posted August 2018. | o Posted August 2018. | |||
| o Final editorial changes before RFC submission for Proposed | o Final editorial changes before RFC submission for Proposed | |||
| Standard. | Standard. | |||
| o Added section "Changes since RFC 6830" so implementators are | o Added section "Changes since RFC 6830" so implementators are | |||
| informed of any changes since the last RFC publication. | informed of any changes since the last RFC publication. | |||
| B.4. Changes to draft-ietf-lisp-rfc6830bis-14 | B.5. Changes to draft-ietf-lisp-rfc6830bis-14 | |||
| o Posted July 2018 IETF week. | o Posted July 2018 IETF week. | |||
| o Put obsolete of RFC 6830 in Intro section in addition to abstract. | o Put obsolete of RFC 6830 in Intro section in addition to abstract. | |||
| B.5. Changes to draft-ietf-lisp-rfc6830bis-13 | B.6. Changes to draft-ietf-lisp-rfc6830bis-13 | |||
| o Posted March IETF Week 2018. | o Posted March IETF Week 2018. | |||
| o Clarified that a new nonce is required per RLOC. | o Clarified that a new nonce is required per RLOC. | |||
| o Removed 'Clock Sweep' section. This text must be placed in a new | o Removed 'Clock Sweep' section. This text must be placed in a new | |||
| OAM document. | OAM document. | |||
| o Some references changed from normative to informative | o Some references changed from normative to informative | |||
| B.6. Changes to draft-ietf-lisp-rfc6830bis-12 | B.7. Changes to draft-ietf-lisp-rfc6830bis-12 | |||
| o Posted July 2018. | o Posted July 2018. | |||
| o Fixed Luigi editorial comments to ready draft for RFC status. | o Fixed Luigi editorial comments to ready draft for RFC status. | |||
| B.7. Changes to draft-ietf-lisp-rfc6830bis-11 | B.8. Changes to draft-ietf-lisp-rfc6830bis-11 | |||
| o Posted March 2018. | o Posted March 2018. | |||
| o Removed sections 16, 17 and 18 (Mobility, Deployment and | o Removed sections 16, 17 and 18 (Mobility, Deployment and | |||
| Traceroute considerations). This text must be placed in a new OAM | Traceroute considerations). This text must be placed in a new OAM | |||
| document. | document. | |||
| B.8. Changes to draft-ietf-lisp-rfc6830bis-10 | B.9. Changes to draft-ietf-lisp-rfc6830bis-10 | |||
| o Posted March 2018. | o Posted March 2018. | |||
| o Updated section 'Router Locator Selection' stating that the Data- | o Updated section 'Router Locator Selection' stating that the Data- | |||
| Plane MUST follow what's stored in the Map-Cache (priorities and | Plane MUST follow what's stored in the Map-Cache (priorities and | |||
| weights). | weights). | |||
| o Section 'Routing Locator Reachability': Removed bullet point 2 | o Section 'Routing Locator Reachability': Removed bullet point 2 | |||
| (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port | |||
| Unreachable),5 (receive a Map-Reply as a response) and RLOC | Unreachable),5 (receive a Map-Reply as a response) and RLOC | |||
| probing | probing | |||
| o Removed 'Solicit-Map Request'. | o Removed 'Solicit-Map Request'. | |||
| B.9. Changes to draft-ietf-lisp-rfc6830bis-09 | B.10. Changes to draft-ietf-lisp-rfc6830bis-09 | |||
| o Posted January 2018. | o Posted January 2018. | |||
| o Add more details in section 5.3 about DSCP processing during | o Add more details in section 5.3 about DSCP processing during | |||
| encapsulation and decapsulation. | encapsulation and decapsulation. | |||
| o Added clarity to definitions in the Definition of Terms section | o Added clarity to definitions in the Definition of Terms section | |||
| from various commenters. | from various commenters. | |||
| o Removed PA and PI definitions from Definition of Terms section. | o Removed PA and PI definitions from Definition of Terms section. | |||
| o More editorial changes. | o More editorial changes. | |||
| o Removed 4342 from IANA section and move to RFC6833 IANA section. | o Removed 4342 from IANA section and move to RFC6833 IANA section. | |||
| B.10. Changes to draft-ietf-lisp-rfc6830bis-08 | B.11. Changes to draft-ietf-lisp-rfc6830bis-08 | |||
| o Posted January 2018. | o Posted January 2018. | |||
| o Remove references to research work for any protocol mechanisms. | o Remove references to research work for any protocol mechanisms. | |||
| o Document scanned to make sure it is RFC 2119 compliant. | o Document scanned to make sure it is RFC 2119 compliant. | |||
| o Made changes to reflect comments from document WG shepherd Luigi | o Made changes to reflect comments from document WG shepherd Luigi | |||
| Iannone. | Iannone. | |||
| o Ran IDNITs on the document. | o Ran IDNITs on the document. | |||
| B.11. Changes to draft-ietf-lisp-rfc6830bis-07 | B.12. Changes to draft-ietf-lisp-rfc6830bis-07 | |||
| o Posted November 2017. | o Posted November 2017. | |||
| o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | o Rephrase how Instance-IDs are used and don't refer to [RFC1918] | |||
| addresses. | addresses. | |||
| B.12. Changes to draft-ietf-lisp-rfc6830bis-06 | B.13. Changes to draft-ietf-lisp-rfc6830bis-06 | |||
| o Posted October 2017. | o Posted October 2017. | |||
| o Put RTR definition before it is used. | o Put RTR definition before it is used. | |||
| o Rename references that are now working group drafts. | o Rename references that are now working group drafts. | |||
| o Remove "EIDs MUST NOT be used as used by a host to refer to other | o Remove "EIDs MUST NOT be used as used by a host to refer to other | |||
| hosts. Note that EID blocks MAY LISP RLOCs". | hosts. Note that EID blocks MAY LISP RLOCs". | |||
| skipping to change at page 42, line 48 ¶ | skipping to change at page 42, line 48 ¶ | |||
| o ETRs may, rather than will, be the ones to send Map-Replies. | o ETRs may, rather than will, be the ones to send Map-Replies. | |||
| o Recommend, rather than mandate, max encapsulation headers to 2. | o Recommend, rather than mandate, max encapsulation headers to 2. | |||
| o Reference VPN draft when introducing Instance-ID. | o Reference VPN draft when introducing Instance-ID. | |||
| o Indicate that SMRs can be sent when ITR/ETR are in the same node. | o Indicate that SMRs can be sent when ITR/ETR are in the same node. | |||
| o Clarify when private addreses can be used. | o Clarify when private addreses can be used. | |||
| B.13. Changes to draft-ietf-lisp-rfc6830bis-05 | B.14. Changes to draft-ietf-lisp-rfc6830bis-05 | |||
| o Posted August 2017. | o Posted August 2017. | |||
| o Make it clear that a Reencapsulating Tunnel Router is an RTR. | o Make it clear that a Reencapsulating Tunnel Router is an RTR. | |||
| B.14. Changes to draft-ietf-lisp-rfc6830bis-04 | B.15. Changes to draft-ietf-lisp-rfc6830bis-04 | |||
| o Posted July 2017. | o Posted July 2017. | |||
| o Changed reference of IPv6 RFC2460 to RFC8200. | o Changed reference of IPv6 RFC2460 to RFC8200. | |||
| o Indicate that the applicability statement for UDP zero checksums | o Indicate that the applicability statement for UDP zero checksums | |||
| over IPv6 adheres to RFC6936. | over IPv6 adheres to RFC6936. | |||
| B.15. Changes to draft-ietf-lisp-rfc6830bis-03 | B.16. Changes to draft-ietf-lisp-rfc6830bis-03 | |||
| o Posted May 2017. | o Posted May 2017. | |||
| o Move the control-plane related codepoints in the IANA | o Move the control-plane related codepoints in the IANA | |||
| Considerations section to RFC6833bis. | Considerations section to RFC6833bis. | |||
| B.16. Changes to draft-ietf-lisp-rfc6830bis-02 | B.17. Changes to draft-ietf-lisp-rfc6830bis-02 | |||
| o Posted April 2017. | o Posted April 2017. | |||
| o Reflect some editorial comments from Damien Sausez. | o Reflect some editorial comments from Damien Sausez. | |||
| B.17. Changes to draft-ietf-lisp-rfc6830bis-01 | B.18. Changes to draft-ietf-lisp-rfc6830bis-01 | |||
| o Posted March 2017. | o Posted March 2017. | |||
| o Include references to new RFCs published. | o Include references to new RFCs published. | |||
| o Change references from RFC6833 to RFC6833bis. | o Change references from RFC6833 to RFC6833bis. | |||
| o Clarified LCAF text in the IANA section. | o Clarified LCAF text in the IANA section. | |||
| o Remove references to "experimental". | o Remove references to "experimental". | |||
| B.18. Changes to draft-ietf-lisp-rfc6830bis-00 | B.19. Changes to draft-ietf-lisp-rfc6830bis-00 | |||
| o Posted December 2016. | o Posted December 2016. | |||
| o Created working group document from draft-farinacci-lisp | o Created working group document from draft-farinacci-lisp | |||
| -rfc6830-00 individual submission. No other changes made. | -rfc6830-00 individual submission. No other changes made. | |||
| Authors' Addresses | Authors' Addresses | |||
| Dino Farinacci | Dino Farinacci | |||
| Cisco Systems | Cisco Systems | |||
| Tasman Drive | Tasman Drive | |||
| End of changes. 33 change blocks. | ||||
| 60 lines changed or deleted | 71 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/ | ||||