idnits 2.17.1 draft-souvatzis-ipv6-arcnet-04.txt: -(173): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(176): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == There are 5 instances of lines with non-ascii characters in the document. == 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 Abstract section. ** 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: ---------------------------------------------------------------------------- -- 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 (1 October 1998) is 9332 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) == Missing Reference: 'ARCIP4' is mentioned on line 48, but not defined == Unused Reference: 'ARCIPV4' is defined on line 179, but no explicit reference was found in the text == Unused Reference: 'EUI64' is defined on line 189, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. 'AARCH') (Obsoleted by RFC 3513) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addrconf-v2 is -01, but you're referring to -02. -- No information found for draft-ietf-ipngwg-discov - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DISC' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-trans-ethernet is -03, but you're referring to -04. (However, the state information for draft-ietf-ipngwg-discov is not up-to-date. The last update was unsuccessful) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec-v2 is -01, but you're referring to -02. (However, the state information for draft-ietf-ipngwg-discov is not up-to-date. The last update was unsuccessful) -- Possible downref: Non-RFC (?) normative reference: ref. 'PHDS' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT I. Souvatzis 3 Expires 1 April 1999 The NetBSD Project 4 1 October 1998 6 A Method for the Transmission of IPv6 Packets over ARCnet Networks. 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this memo is unlimited. Please send comments to the 28 author. 30 1. Introduction 32 This memo specifies a frame format for transmission of IPv6 [IPV6] 33 packets and the method of forming IPv6 link-local and statelessly 34 autoconfigured addresses on ARCnet networks. It also specifies the 35 content of the Source/Target Link-layer Address option used by the 36 Router Solicitation, Router Advertisement, Neighbor Solicitation, 37 Neighbor Advertisement and Redirect messages described in [DISC], 38 when those messages are transmitted on an ARCnet. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 41 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in 43 RFC 2119 [KWORD]. 45 2. Frame Format 46 IPv6 packets are link layer fragmented and reassembled according to 47 [PHDS]. A brief but sufficient discussion of this fragmentation 48 method can be found in [ARCIP4]. 50 The protocol id used is D4 hexadecimal, the same as for IPv4. IPv6 51 packets are recognized by looking at the version number in the high 52 half of the first octet of the data, which is 4 for IPv4 and 6 for 53 IPv6. This method of distinguishing IPv6 packets was chosen because 54 there are only 256 values of ARCnet protocol ids available. 56 3. Maximum Transmission Unit 58 The maximum IPv6 packet length possible using this encapsulation 59 method is 60480 octets. Since this length is impractical because of 60 its worst case transmission time of several seconds, all ARCnet 61 implementations on a given ARCnet network should agree on a smaller 62 value. 64 Implementations SHOULD support an MTU of 9072 octets and MUST support 65 the minimum MTU required by [IPV6]. 67 In the presence of a router, this size MAY be changed by a Router 68 Advertisement [DISC] containing an MTU option. If a Router 69 Advertisement is received with an MTU option specifying an MTU larger 70 than 60480, or larger than a manually configured value less than 71 60480, that MTU option may be logged to system management but MUST be 72 otherwise ignored. 74 If no router is available, the local MTU MUST be left at 9072 or MUST 75 be manually configured to the same different value on all connected 76 stations. 78 Implementations MAY accept arriving IPv6 datagrams which are larger 79 than their configured maximum transmission unit. They are not 80 required to discard such datagrams. If they can not handle larger 81 datagrams, they MAY log the event to the system administration, but 82 MUST otherwise silently discard them. 84 4. Stateless Auto-configuration 86 If a node has an EUI-64 which is not used to form the Interface 87 Identifier for any other interface, it SHOULD use that EUI-64 to form 88 the Interface Identifier for its ARCnet interface. If that EUI-64 is 89 in use for another interface attached to a different link, it MAY be 90 used for the ARCnet interface as well. 92 The Interface Identifier is then formed from the EUI-64 by 93 complementing the "Universal/Local" (U/L) bit, which is the next- to- 94 lowest order bit of the first octet of the EUI-64. 96 When a node has no EUI-64 available for forming its ARCnet Interface 97 Identifer, it MUST form that identifier as specified in [AARCH], 98 Appendix A, section "Links with Non-Global Identifier". That is, the 99 8 bit manually configured ARCnet address is appended to the 56 zero 100 bits. 102 For example, for an ARCnet interface with the configured address of 103 49 hexadecimal this results in the following identifier: 105 |0 1|1 3|3 4|4 6| 106 |0 5|6 1|2 7|8 3| 107 +----------------+----------------+----------------+----------------+ 108 |0000000000000000|0000000000000000|0000000000000000|0000000001001001| 109 +----------------+----------------+----------------+----------------+ 111 Note that this results in the universal/local bit set to "0" to 112 indicate local scope. 114 An IPv6 address prefix used for stateless auto-configuration [ACONF] 115 of an ARCnet interface MUST have a length of 64 bits. 117 5. Link-Local Addresses 119 The IPv6 link-local address [AARCH] for an Ethernet interface is 120 formed by appending the Interface Identifier, as defined above, to 121 the prefix FE80::/64. 123 10 bits 54 bits 64 bits 124 +----------+-----------------------+----------------------------+ 125 |1111111010| (zeros) | Interface Identifier | 126 +----------+-----------------------+----------------------------+ 128 6. Address Mapping -- Unicast 130 The procedure for mapping IPv6 addresses into ARCnet link-layer 131 addresses is described in [DISC]. The Source/Target link layer 132 Address option has the following form when the link layer is ARCnet. 134 0 1 135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Type | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |ARCnet address | | 140 +---------------+ -+ 141 | | 142 +- 5 octets of padding -+ 143 | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Option fields: 148 Type 1 for Source Link-layer address. 149 2 for Target Link-layer address. 150 Length 1 (in units of 8 octets). 152 ARCnet address The 8 bit ARCnet address, in canonical bit order. 154 7. Address Mapping -- Multicast 156 As ARCnet only provides 1 multicast address (00 hexadecimal), all 157 IPv6 multicast addresses must be mapped to this address. 159 8. Security Considerations 161 The method of derivation of Interface Identifiers from ARCnet 162 addresses is intended to preserve local uniqueness when possible. 163 However, there is no protection from duplication through accident or 164 forgery. 166 9. Acknowledgements 168 Big parts of the new version of this draft are either based on 169 [ETHIPV6] or on Matt Crawfords review of an earlier version. 171 10. References 173 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architec� 174 ture", RFC 2373. 176 [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfigura� 177 tion", currently draft-ietf-ipngwg-addrconf-v2-02.txt. 179 [ARCIPV4] Provan, D., "Transmitting IP Traffic over ARCNET Networks", 180 RFC1201, Novell, Inc., February 1991. 182 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 183 for IP Version 6 (IPv6)", currently draft-ietf-ipngwg-discov� 184 ery-v2-03.txt. 186 [ETHIPV6] M. Crawford, "Transmission of IPv6 Packets over Ethernet Net� 187 works", currently draft-ietf-ipngwg-trans-ethernet-04.txt 189 [EUI64] "64-Bit Global Identifier Format Tutorial", http://stan� 190 dards.ieee.org/db/oui/tutorials/EUI64.html. 192 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 193 Specification", currently draft-ietf-ipngwg-ipv6-spec- 194 v2-02.txt. 196 [KWORD] S.Bradner, "Key words for use in RFCs to Indicate Requirement 197 Levels", RFC 2119. 199 [PHDS] Novell, Inc., "ARCNET Packet Header Definition Standard", 200 November 1989. 202 10. Author's Address 204 Ignatios Souvatzis 205 The NetBSD Project 206 Stationenweg 29 207 D-53332 Bornheim 208 Germany 210 Phone (work): +49 (228) 734316 212 EMail: is@netbsd.org