| < draft-ietf-lisp-vendor-lcaf-09.txt | draft-ietf-lisp-vendor-lcaf-10.txt > | |||
|---|---|---|---|---|
| LISP Working Group A. Rodriguez-Natal | LISP Working Group A. Rodriguez-Natal | |||
| Internet-Draft Cisco | Internet-Draft Cisco | |||
| Intended status: Experimental V. Ermagan | Intended status: Experimental V. Ermagan | |||
| Expires: October 1, 2021 Google | Expires: 14 October 2022 Google | |||
| A. Smirnov | A. Smirnov | |||
| V. Ashtaputre | V. Ashtaputre | |||
| Cisco | Cisco | |||
| D. Farinacci | D. Farinacci | |||
| lispers.net | lispers.net | |||
| March 30, 2021 | 12 April 2022 | |||
| Vendor Specific LISP Canonical Address Format (LCAF) | Vendor Specific LISP Canonical Address Format (LCAF) | |||
| draft-ietf-lisp-vendor-lcaf-09 | draft-ietf-lisp-vendor-lcaf-10 | |||
| Abstract | Abstract | |||
| This document describes a new LISP Canonical Address Format (LCAF), | This document describes a new LISP Canonical Address Format (LCAF), | |||
| the Vendor Specific LCAF. This LCAF enables organizations to have | the Vendor Specific LCAF. This LCAF enables organizations to have | |||
| internal encodings for LCAF addresses. | internal encodings for LCAF addresses. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| 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 October 1, 2021. | This Internet-Draft will expire on 14 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 | |||
| 3. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 | 3. Vendor Specific LCAF . . . . . . . . . . . . . . . . . . . . 2 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 | 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 1. Introduction | 1. Introduction | |||
| The LISP Canonical Address Format (LCAF) [RFC8060] defines the format | The LISP Canonical Address Format (LCAF) [RFC8060] defines the format | |||
| and encoding for different address types that can be used on LISP | and encoding for different address types that can be used on LISP | |||
| [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] deployments. | [I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6833bis] deployments. | |||
| However, certain deployments require specific format encodings that | However, certain deployments require specific format encodings that | |||
| may not be applicable outside of the use-case for which they are | may not be applicable outside of the use-case for which they are | |||
| defined. The Vendor Specific LCAF allows organizations to create | defined. This document updates [RFC8060] to introduce a Vendor | |||
| LCAF addresses to be used only internally on particular LISP | Specific LCAF that defines how organizations can create LCAF | |||
| deployments. | addresses to be used only internally on particular LISP deployments. | |||
| 2. Requirements Notation | 2. Requirements Notation | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. Vendor Specific LCAF | 3. Vendor Specific LCAF | |||
| skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
| The Vendor Specific LCAF relies on using the IEEE Organizationally | The Vendor Specific LCAF relies on using the IEEE Organizationally | |||
| Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across | Unique Identifier (OUI) [IEEE.802_2001] to prevent collisions across | |||
| vendors or organizations using the LCAF. The format of the Vendor | vendors or organizations using the LCAF. The format of the Vendor | |||
| Specific LCAF is provided below. | Specific LCAF is provided below. | |||
| 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | AFI = 16387 | Rsvd1 | Flags | | | AFI = 16387 | Rsvd1 | Flags | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type = 255 | Rsvd2 | Length | | | Type = TBD | Rsvd2 | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Rsvd3 | Organizationally Unique Identifier (OUI) | | | Rsvd3 | Organizationally Unique Identifier (OUI) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Internal format... | | | Internal format... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Vendor Specific LCAF | Figure 1: Vendor Specific LCAF | |||
| The fields in the first 8 octets of the above Vendor Specific LCAF | The fields in the first 8 octets of the above Vendor Specific LCAF | |||
| are actually the fields defined in the general LCAF format specified | are actually the fields defined in the general LCAF format specified | |||
| in [RFC8060]. The "Type" field MUST be set to the value 255 to | in [RFC8060]. The "Type" field MUST be set to the value 255 to | |||
| indicate that this is a Vendor Specific LCAF. The Length field has | indicate that this is a Vendor Specific LCAF. The Length field has | |||
| to be set accordingly to the length of the internal format plus the | to be set accordingly to the length of the internal format plus the | |||
| OUI plus the Rsvd3 fields as for [RFC8060]. The fields defined by | OUI plus the Rsvd3 fields as for [RFC8060]. The fields defined by | |||
| the Vendor Specific LCAF are: | the Vendor Specific LCAF are: | |||
| Rsvd3: This 8-bit field is reserved for future use. It MUST be | Rsvd3: This 8-bit field is reserved for future use. It MUST be | |||
| skipping to change at page 4, line 10 ¶ | skipping to change at page 4, line 10 ¶ | |||
| If a LISP device receives a LISP message containing a Vendor Specific | If a LISP device receives a LISP message containing a Vendor Specific | |||
| LCAF with an OUI that it does not understand, it MUST drop the | LCAF with an OUI that it does not understand, it MUST drop the | |||
| message and it SHOULD create a log message. | message and it SHOULD create a log message. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| This document enables organizations to define new LCAFs for their | This document enables organizations to define new LCAFs for their | |||
| internal use. It is the responsibility of these organizations to | internal use. It is the responsibility of these organizations to | |||
| properly assess the security implications of the formats they define. | properly assess the security implications of the formats they define. | |||
| Security considerations from [RFC8060] apply to this document. | ||||
| 5. Acknowledgments | 5. Acknowledgments | |||
| The authors would like to thank Joel Halpern and Luigi Iannone for | The authors would like to thank Joel Halpern and Luigi Iannone for | |||
| their suggestions and guidance regarding this document. | their suggestions and guidance regarding this document. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| Following the guidelines of [RFC8126], this document requests IANA to | Following the guidelines of [RFC8126], IANA is asked to assign a | |||
| update the "LISP Canonical Address Format (LCAF) Types" Registry | value (255 is suggested) for the Vendor Specific LCAF from the "LISP | |||
| defined in [RFC8060] to allocate the following assignment: | Canonical Address Format (LCAF) Types" registry (defined in | |||
| [RFC8060]) as follows: | ||||
| +---------+---------------------+-------------------------------+ | +=========+=====================+============================+ | |||
| | Value # | LISP LCAF Type Name | Reference | | | Value # | LISP LCAF Type Name | Reference | | |||
| +---------+---------------------+-------------------------------+ | +=========+=====================+============================+ | |||
| | 255 | Vendor Specific | Section 3 | | | TBD | Vendor Specific | [This Document], Section 3 | | |||
| +---------+---------------------+-------------------------------+ | +---------+---------------------+----------------------------+ | |||
| Table 1: Vendor Specific LCAF assignment | Table 1: Vendor Specific LCAF assignment | |||
| 7. Normative References | 7. Normative References | |||
| [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, "The Locator/ID Separation Protocol (LISP)", | |||
| (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), | Work in Progress, Internet-Draft, draft-ietf-lisp- | |||
| November 2020. | rfc6830bis-36, 18 November 2020, | |||
| <https://www.ietf.org/archive/id/draft-ietf-lisp- | ||||
| rfc6830bis-36.txt>. | ||||
| [I-D.ietf-lisp-rfc6833bis] | [I-D.ietf-lisp-rfc6833bis] | |||
| Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- | Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, | |||
| Aparicio, "Locator/ID Separation Protocol (LISP) Control- | "Locator/ID Separation Protocol (LISP) Control-Plane", | |||
| Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), | Work in Progress, Internet-Draft, draft-ietf-lisp- | |||
| November 2020. | rfc6833bis-30, 18 November 2020, | |||
| <https://www.ietf.org/archive/id/draft-ietf-lisp- | ||||
| rfc6833bis-30.txt>. | ||||
| [IEEE.802_2001] | [IEEE.802_2001] | |||
| IEEE, "IEEE Standard for Local and Metropolitan Area | IEEE, "IEEE Standard for Local and Metropolitan Area | |||
| Networks: Overview and Architecture", IEEE 802-2001, | Networks: Overview and Architecture", IEEE 802-2001, | |||
| DOI 10.1109/ieeestd.2002.93395, July 2002, | DOI 10.1109/ieeestd.2002.93395, 27 July 2002, | |||
| <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>. | <http://ieeexplore.ieee.org/servlet/opac?punumber=7732>. | |||
| [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>. | |||
| [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | |||
| Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | |||
| February 2017, <https://www.rfc-editor.org/info/rfc8060>. | February 2017, <https://www.rfc-editor.org/info/rfc8060>. | |||
| skipping to change at page 5, line 27 ¶ | skipping to change at page 5, line 33 ¶ | |||
| <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>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Alberto Rodriguez-Natal | Alberto Rodriguez-Natal | |||
| Cisco | Cisco | |||
| San Jose, CA | Spain | |||
| USA | ||||
| Email: natal@cisco.com | Email: natal@cisco.com | |||
| Vina Ermagan | Vina Ermagan | |||
| USA | United States of America | |||
| Email: ermagan@gmail.com | Email: ermagan@gmail.com | |||
| Anton Smirnov | Anton Smirnov | |||
| Cisco | Cisco | |||
| Diegem | Diegem | |||
| Belgium | Belgium | |||
| Email: asmirnov@cisco.com | Email: asmirnov@cisco.com | |||
| Vrushali Ashtaputre | Vrushali Ashtaputre | |||
| Cisco | Cisco | |||
| San Jose, CA | San Jose, CA | |||
| USA | United States of America | |||
| Email: vrushali@cisco.com | Email: vrushali@cisco.com | |||
| Dino Farinacci | Dino Farinacci | |||
| lispers.net | lispers.net | |||
| San Jose, CA | San Jose, CA | |||
| USA | United States of America | |||
| Email: farinacci@gmail.com | Email: farinacci@gmail.com | |||
| End of changes. 20 change blocks. | ||||
| 44 lines changed or deleted | 43 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||