RFC 4581

Cryptographically Generated Addresses (CGA) Extension Field Format

📅 published October 2006, from ietf

RFC 4581: Cryptographically Generated Addresses (CGA) Extension Field Format 💖

okay bestie, let's get into it 🎀

Who wrote it: M. Bagnulo (UC3M) and J. Arkko (Ericsson) 🫶 Category: Standards Track 👑 Date: October 2006 🌸 Updates: RFC 3972 ✨ (this one builds on the CGA spec, so it's not standing alone) Network Working Group (the crew that made it happen) 🧚

Status of This Memo 📜

this is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 💅 check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol 🔥 distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2006). 💜

Abstract ✨

this doc defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions 🦋 it also updates RFC 3972 🎀

Table of Contents 🗂️

1. Introduction ....................................................2
2. CGA Extension Field Format ......................................2
3. IANA Considerations .............................................2
4. Security Considerations .........................................3
5. Acknowledgements ................................................3
6. Normative References ............................................3

1. Introduction 🌸

okay so the CGA spec [1] lets you stick extra info into Extension Fields inside the CGA Parameter Data Structure 🧚 and people are clearly lowkey obsessed with this idea, so it makes total sense that more than one mechanism is gonna need it 😭 to make adding a bunch of data items way easier, this doc updates RFC 3972 [1] and defines a Type-Length-Value format for the Extension Fields 💖 it's giving organization, no cap 💅

2. CGA Extension Field Format 🍓

data items going into Extension Fields of the CGA Parameter Data Structure MUST be encoded using this Type-Length-Value (TLV) format 🔥 this part is non-negotiable bestie 🙈

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Extension Type        |   Extension Data Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Extension Data                          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the fields, ranked by vibes 🦋

  • Extension Type: a 16-bit identifier for what kind of Extension Field this is ✨
  • Extension Data Length: a 16-bit unsigned integer that tells you how long the Extension Data field is, in octets 🧮
  • Extension Data: variable-length, and it's specific to whichever Extension Type you're dealing with 💅

3. IANA Considerations 🏛️

IANA has created and will maintain a registry called "CGA Extension Type" 👑 the values in this namespace are 16-bit unsigned integers 🔢 the initial values for the CGA Extension Type field are listed below, and future assignments go through Standards Action [2] 🫶 each assignment is a name plus a value 💖

as recommended in [3], this doc makes these assignments for experimental and testing use 🧪

  • the value 0xFFFD, named Exp_FFFD 🦋
  • the value 0xFFFE, named Exp_FFFE 🌸
  • the value 0xFFFF, named Exp_FFFF 🌈

4. Security Considerations 💀

⚠️ okay this one is SERIOUS bestie, don't skip it 😭

no security concerns are raised by adopting the CGA Extension format in this document 🙏 BUT (and this is a big but) proper security analysis is required whenever new CGA Extensions get defined 🚨 that's how you make sure they don't introduce new vulnerabilities to the existing CGA schemes 🔥 literally do not skip this step 💀

5. Acknowledgements 🫶

comments on this document came from Sam Hartman, Allison Mankin, Pekka Savola, Thomas Narten, Tuomas Aura, Stefan Rommer, Julien Laganier, and James Kempf 💜 thank u all, you're iconic ✨

6. Normative References 📚

[1]  Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
     3972, March 2005.

[2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[3]  Narten, T., "Assigning Experimental and Testing Numbers
     Considered Useful", BCP 82, RFC 3692, January 2004.

Authors' Addresses 🗺️

Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid  28911
SPAIN

Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI:   http://www.it.uc3m.es


Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@ericsson.com

Copyright (C) The Internet Society (2006).

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

this document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document, or on whether any license under such rights might or might not be available 🤷‍♀️ it also doesn't claim to have made any independent effort to identify such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗

the IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard 📬 send that info to ietf-ipr@ietf.org 💌

Acknowledgement 🙏

funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌟

📦 where this page comes from