idnits 2.17.1 draft-narten-canonical-ordering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...al form using...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 1997) is 9666 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6-ETHER' is defined on line 165, but no explicit reference was found in the text == Unused Reference: 'IPv6-FDDI' is defined on line 169, but no explicit reference was found in the text == Unused Reference: 'IPv6-TOKEN' is defined on line 172, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-ipngwg-discovery-v2-00 == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-trans-fddi-net-03 == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-trans-tokenring-03 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 Charles Burton 4 IBM 5 November 5, 1997 7 A Caution On The Canonical Ordering Of Link-Layer Addresses 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Distribution of this memo is unlimited. 31 This Internet Draft expires May 5, 1998. 33 Abstract 35 Protocols such as ARP and Neighbor Discovery have data fields that 36 contain link-layer addresses. In order to interoperate properly, a 37 sender setting such a field must insure that the receiver extracts 38 those bits and interprets them correctly. In most cases, such fields 39 must be in "canonical form." Unfortunately, not all LAN adaptors are 40 consistent in their use of canonical form, and implementations may 41 need to explicitly bit swap individual bytes in order to obtain the 42 correct format. This document provides information to implementors to 43 help them avoid the pitfall of using non-canonical forms when 44 canonical forms are required. 46 Contents 48 Status of this Memo.......................................... 1 50 1. Introduction............................................. 2 52 2. Canonical Form........................................... 2 54 3. Implementors Beware: Potential Trouble Spots............. 3 55 3.1. Neighbor Discovery in IPv6.......................... 3 56 3.2. IPv4 and ARP........................................ 4 58 4. Security Considerations.................................. 4 60 5. References............................................... 4 62 6. Authors' Addresses....................................... 4 64 1. Introduction 66 Protocols such as ARP [ARP] and ND [DISCOVERY] have data fields that 67 contain link-layer addresses. In order to interoperate properly, a 68 sender setting such a field must insure that the receiver extracts 69 those bits and interprets them correctly. In most cases, such fields 70 must be in "canonical form." Unfortunately, not all LAN adaptors are 71 consistent in their use of canonical form, and implementations may 72 need to explicitly bit swap individual bytes in order to obtain the 73 correct format. 75 2. Canonical Form 77 Canonical form (also known as "LSB format" and "Ethernet format") is 78 the name given to the format of a LAN adapter address as it should be 79 presented to the user according to the 802 LAN standard. It is best 80 defined as how the bit order of an adapter address on the LAN media 81 maps to the bit order of an adapter address in memory: The first bit 82 of each byte that appears on the LAN maps to the least significant 83 (i.e., right-most) bit of each byte in memory (the figure below 84 illustrates this). This puts the group address indicator (i.e., the 85 bit that defines whether an address is unicast or multicast) in the 86 least significant bit of the first byte. Ethernet and 802.3 hardware 87 behave consistently with this definition. 89 Unfortunately, Token Ring (and some FDDI) hardware does not behave 90 consistently with this definition; it maps the first bit of each byte 91 of the adapter address to the most significant (i.e., left-most) bit 92 of each byte in memory, which puts the group address indicator in the 93 most significant bit of the first byte. This mapping is variously 94 called "MSB format", "IBM format", "Token-Ring format", and "non- 95 canonical form". The figure below illustrates the difference between 96 canonical and non-canonical form using the canonical form address 97 12-34-56-78-9A-BC as an example: 99 In memory, 12 34 56 78 9A BC 100 canonical: 00010010 00110100 01010110 01111000 10011010 10111100 102 1st bit appearing on LAN (group address indicator) 103 | 104 On LAN: 01001000 00101100 01101010 00011110 01011001 00111101 106 In memory, 107 MSB format: 01001000 00101100 01101010 00011110 01011001 00111101 108 48 2C 6A 1E 59 3D 110 The implication of this inconsistency is that addresses extracted 111 from adaptors, assigned to adaptors, or extracted from link-layer 112 packet headers obtained from adaptors may need to be bit-swapped to 113 put them into canonical form. Likewise, addresses in canonical form 114 that are handed to adaptors (e.g., to set an address, to specify a 115 destination address in a link-layer header, etc.) may need to be 116 bit-swapped in order for the adaptor to process the request as 117 expected. 119 3. Implementors Beware: Potential Trouble Spots 121 3.1. Neighbor Discovery in IPv6 123 All of the IPv6 over specific link layers documents specify that 124 link-layer addresses must be transmitted in canonical order [IPv6- 125 ETHER, IPv6-FDDI, IPv6-TOKEN]. As far as the authors can tell, all 126 Ethernet LAN adaptors use canonical order and no special processing 127 by implementations is needed. In contrast, some FDDI and all Token 128 Ring adaptors appear to use non-canonical format. Implementors must 129 insure that any addresses that appear in link-layer address options 130 of Neighbor Discovery [DISCOVERY] messages are sent in canonical 131 order and that any link-layer addresses extracted from ND packets are 132 interpreted correctly on the local machine and its adaptors. 134 3.2. IPv4 and ARP 136 Ethernet addresses that appear in ARP packets are in canonical order. 137 In contrast, when running ARP over Token Ring, the de facto practice 138 is to transmit addresses in non-canonical order. Because all Token 139 Ring adaptors assume non-canonical ordering, no interoperability 140 problems result between communicating nodes attached to the same 141 Token Ring. 143 In some environments, however, Token Rings and Ethernets are 144 connected via a bridge. When a node on the Token Ring attempts to 145 communicate with a node on the Ethernet, communication would normally 146 fail, since the Ethernet will misinterpret the Token Ring address 147 (and vice versa). To get around this problem, bridges that forward 148 packets between dissimilar network types perform bit swaps of the 149 addresses in the address fields of ARP packets that are forwarded 150 from a network of one type to one of the other. 152 4. Security Considerations 154 There are no known security issues raised by this document. 156 5. References 158 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 159 37, RFC 826, November 1982. 161 [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 162 Discovery for IP Version 6 (IPv6)", draft-ietf-ipngwg- 163 discovery-v2-00.txt. 165 [IPv6-ETHER] M. Crawford, "Transmission of IPv6 Packets over 166 Ethernet Networks", draft-ietf-ipngwg-trans-ethernet- 167 03.txt. 169 [IPv6-FDDI] M. Crawford, "Transmission of IPv6 Packets over FDDI 170 Networks", draft-ietf-ipngwg-trans-fddi-net-03.txt. 172 [IPv6-TOKEN] S. Thomas, "Transmission of IPv6 Packets over Token 173 Ring Networks", draft-ietf-ipngwg-trans-tokenring-03.txt. 175 6. Authors' Addresses 177 Thomas Narten 178 IBM Corporation 179 3039 Cornwallis Ave. 180 PO Box 12195 181 Research Triangle Park, NC 27709-2195 183 Phone: 919-254-7798 184 EMail: narten@raleigh.ibm.com 186 Charles F. Burton, III 187 IBM Corporation 188 3039 Cornwallis Ave. 189 PO Box 12195 190 Research Triangle Park, NC 27709-2195 192 Phone: 919-254-4355 193 EMail: burton@rtp.vnet.ibm.com