RFC 3827

Additional Snoop Datalink Types

📅 published June 2004, from ietf

okay bestie, this one is RFC 3827, "Additional Snoop Datalink Types," written by K. Sarcar (Kanoj Sarcar) at Sun Microsystems, Inc. 💖 It's marked Informational and dated June 2004. The header has no Obsoletes or Updates line, so it doesn't replace or change any earlier RFC. 🌸

Status of this Memo ✨

This memo gives information to the Internet community. It is not a standard of any kind. Anyone can distribute it without limit. 🫶

Copyright (C) The Internet Society (2004).

Abstract 💜

The snoop file format is how people store and swap datalink layer packet traces 📦. This document adds extensions to that file format so it can handle new media. 🔥

1. Introduction 🌈

[RFC1761] is the one that defines the snoop file format. It's used to store captured network packets for tools that capture, display, and interpret network traffic 👀. The file format has a header with a Datalink Type field, which tells you what kind of datalink the network uses. This document gives that field new values and sets up an IANA registry so future datalink types have a home 💅.

On top of the Datalink Type codes already listed in [RFC1761], this document defines these type codes for the matching media:

          Datalink Type           Code
          -------------           ----

          Fibre Channel           16
          ATM                     17
          ATM Classical IP        18
          IP over Infiniband      26

The IP over Infiniband packet format is described in [IPoIB]. 🌸

3. IANA Considerations 👑

This document creates a new IANA registry called "Snoop Datalink Types." It holds the possible 32-bit (4 octet) snoop datalink types 🔢. The registry includes the values that were already defined in [RFC1761], listed here:

          Datalink Type           Code
          -------------           ----

          IEEE 802.3              0
          IEEE 802.4 Token Bus    1
          IEEE 802.5 Token Ring   2
          IEEE 802.6 Metro Net    3
          Ethernet                4
          HDLC                    5
          Character Synchronous   6
          IBM Channel-to-Channel  7
          FDDI                    8
          Other                   9

The registry also holds the values from section 2 of this document. ✨

All new allocations and assignments to this registry, starting at code 27, follow the First Come First Served policy in [BCP0026]. Type codes up to 26 that this section doesn't define (10-15 and 19-25) are reserved 🔒.

4. Security Considerations 💀

Adding new datalink type codes to the existing file format poses no known security risks. Lowkey the safest part of the whole doc 🙈.

5. Acknowledgements 🫶

The author thanks Jim Carlson, Brent Callaghan, and Bill Strahm for reviewing this document meticulously 🍓.

6. References 🧚

6.1. Normative References 🔥

[RFC1761] Callaghan, B. and R. Gilligan, "Snoop Version 2 Packet
          Capture File Format", RFC 1761, February 1995.

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

6.2. Informative References 🌙

[IPoIB]   Kashyap, V. and H.K. Chu, "IP encapsulation and address
          resolution over InfiniBand networks", Work in Progress,
          April 2003.

7. Author's Address 📮

Kanoj Sarcar
Sun Microsystems, Inc.
14 Network Circle
Bldg 14, MPK14-333
Menlo Park, CA  94025

Phone: 1-650-786-4785
EMail: kanoj.sarcar@sun.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions in BCP 78. Except as stated there, the authors keep 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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the technology in this document are valid or cover it. It also doesn't say whether any license under those rights is available. It hasn't made any independent effort to find such rights either 🕵️. Info on how RFC documents deal with rights is in BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses to be made available, or the results of attempts to get a general license or permission for implementers or users of this spec, are available from the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📨

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from