RFC 2469

A Caution On The Canonical Ordering Of Link-Layer Addresses

📅 published December 1998, from ietf

RFC 2469, Network Working Group 🌸 Category: Informational (just sharing info, not a standard 💅) Authors: T. Narten and C. Burton, both at IBM 🧚 Date: December 1998 📅 Obsoletes / Updates: this RFC doesn't list anything it obsoletes or updates ✨

Status of this Memo 💖

okay so this memo is bestie-level info for the Internet community. it does not specify an Internet standard of any kind 🙈 distribution of this memo is unlimited, so share it with whoever 🫶

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 🌈

okay real quick, protocols like ARP and Neighbor Discovery have data fields that hold link-layer addresses. so for everything to interoperate properly, the sender has to make sure the receiver pulls out those bits and reads them correctly 🔥 in most cases those fields must be in "canonical form" 💜 the messy part is that not all LAN adaptors are consistent about canonical form, so implementations may need to explicitly bit swap individual bytes to get the right format 😭 this doc is here to warn implementors so they don't fall into the trap of using non-canonical forms when canonical forms are required 🫶

Table of Contents 🍓

1.  Introduction.............................................    2
2.  Canonical Form...........................................    2
3.  Implementors Beware: Potential Trouble Spots.............    3
   3.1.  Neighbor Discovery in IPv6..........................    3
   3.2.  IPv4 and ARP........................................    3
4.  Security Considerations..................................    3
5.  References...............................................    4
6.  Authors' Addresses.......................................    4
7.  Full Copyright Statement.................................    5

1. Introduction 🌸

so protocols like ARP [ARP] and ND [DISCOVERY] have fields that carry link-layer addresses 👀 for everything to interoperate, the sender has to make sure the receiver extracts those bits and reads them the right way ✨ usually those fields must be in "canonical form" 💅 but like I said, not every LAN adaptor is consistent about it, so implementations might need to explicitly bit swap individual bytes to get the correct format 😭

2. Canonical Form 🎀

so canonical form is also called "LSB format" and "Ethernet format" 🧚 it's the format a LAN adapter address should be shown to the user, according to the 802 LAN standard ✨ the cleanest way to think about it: the first bit of each byte that shows up on the LAN maps to the least significant (aka right-most) bit of each byte in memory 🔥 this is the bit that puts the group address indicator (the bit that says unicast vs. multicast) in the least significant bit of the first byte 💖 Ethernet and 802.3 hardware are consistent with this, which is iconic of them 👑

unfortunately, Token Ring (and some FDDI) hardware is NOT consistent with that 💀 it maps the first bit of each byte to the most significant (aka left-most) bit in memory, so the group address indicator ends up in the most significant bit of the first byte 🙈 this is called "MSB format", "IBM format", "Token-Ring format", and "non-canonical form" 🦋 here's the difference, using the canonical address 12-34-56-78-9A-BC as the example:

In memory,      12       34       56       78       9A       BC
canonical:   00010010 00110100 01010110 01111000 10011010 10111100

             1st bit appearing on LAN (group address indicator)
             |
On LAN:      01001000 00101100 01101010 00011110 01011001 00111101

In memory,
MSB format:  01001000 00101100 01101010 00011110 01011001 00111101
                48       2C       6A       1E       59       3D

the takeaway is that addresses pulled out of adaptors, assigned to adaptors, or pulled out of link-layer packet headers from adaptors may need to be bit-swapped to get them into canonical form 😭 and the reverse is also true: canonical-form addresses handed to adaptors (to set an address, to specify a destination in a link-layer header, etc.) may need to be bit-swapped so the adaptor processes them as expected 💅

3. Implementors Beware: Potential Trouble Spots ⚠️

okay implementors, this part is the tea. read it twice 🫖💀

3.1. Neighbor Discovery in IPv6 🧚

all of the IPv6 over specific link layers documents say link-layer addresses must be transmitted in canonical order [IPv6-ETHER, IPv6-FDDI, IPv6-TOKEN] ✨ as far as the authors can tell, all Ethernet LAN adaptors use canonical order, so no special processing is needed there 💖 on the other hand, some FDDI and all Token Ring adaptors appear to use non-canonical format 😭 so implementors must insure that any addresses in link-layer address options of Neighbor Discovery [DISCOVERY] messages are sent in canonical order, and that any link-layer addresses extracted from ND packets are interpreted correctly on the local machine and its adaptors 🔥

3.2. IPv4 and ARP 🌈

Ethernet addresses in ARP packets are in canonical order 💅 Token Ring is the odd one out: when running ARP over Token Ring, the de facto practice is to transmit addresses in non-canonical order 🙈 because all Token Ring adaptors assume non-canonical ordering, nodes attached to the same Token Ring have no interoperability problems with each other 🫶

but in some environments, Token Rings and Ethernets are connected via a bridge 👀 when a node on the Token Ring tries to talk to a node on the Ethernet, communication would normally fail, because the Ethernet misreads the Token Ring address (and vice versa) 💀 to get around this, bridges that forward packets between dissimilar network types bit swap the addresses in the address fields of ARP packets forwarded from a network of one type to the other 👑

4. Security Considerations 🔐

the tea ☕: there are no known security issues raised by this document 💜 stay safe anyway, obviously 💅

5. References 📚

[ARP]        Plummer, D., "An Ethernet Address Resolution Protocol",
             STD 37, RFC 826, November 1982.

[DISCOVERY]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 2461, December
             1998.

[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
             Ethernet Networks", RFC 2464, December 1998.

[IPv6-FDDI]  Crawford, M., "Transmission of IPv6 Packets over FDDI
             Networks", RFC 2467, December 1998.

[IPv6-TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of
             IPv6 Packets over Token Ring Networks", RFC 2470,
             December 1998.

6. Authors' Addresses 🧚

Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195
Research Triangle Park, NC 27709-2195

Phone: 919-254-7798
EMail: narten@raleigh.ibm.com

Charles F. Burton, III
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195
Research Triangle Park, NC 27709-2195

Phone: 919-254-4355
EMail: burton@rtp.vnet.ibm.com

the legal text below is kept word for word, bestie 🫶

Copyright (C) The Internet Society (1998).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
📦 where this page comes from