idnits 2.17.1 draft-souvatzis-ipv6-arcnet-02.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-26) 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. == 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. ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (23 July 1997) is 9774 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 44, but not defined == Unused Reference: 'ARCIPV4' is defined on line 121, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1884 (ref. 'AARCH') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1971 (ref. 'CONF') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 1970 (ref. 'DISC') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'PHDS' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT I. Souvatzis 3 Expires 22 January 1998 The NetBSD Project 4 23 July 1997 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), ds.internic.net (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 Introduction 32 This memo specifies a frame format for transmission of IPv6 [IPV6] 33 packets and the method of forming IPv6 link-local addresses on ARCnet 34 networks. It also specifies the content of the Source/Target Link- 35 layer Address option used by the Router Solicitation, Router 36 Advertisement, Neighbor Solicitation, and Neighbor Advertisement 37 messages described in [DISC], when those messages are transmitted on 38 an ARCnet. 40 Frame Format 42 IPv6 packets are link layer fragmented and reassembled according to 43 [PHDS]. A brief but sufficient discussion of this fragmentation 44 method can be found in [ARCIP4]. 46 The protocol id used is hex D4, the same as for IPv4. IPv6 packets 47 are recognized by looking at the version number in the high half of 48 the first octet of the data, which is 4 for IPv4 and 6 for IPv6. 50 Maximum Transmission Unit 52 The maximum IPv6 packet length possible using this encapsulation 53 method is 60,480 octets. Since this length is impractical, all ARCnet 54 implementations on a given ARCnet network will need to agree on a 55 smaller value. In the presence of a router, this size should be 56 reduced by a Router Advertisement [DISC] containing an MTU option, or 57 by manual configuration of each node. If a Router Advertisement is 58 received with an MTU option specifying an MTU larger than 60480, or 59 larger than a manually configured value less than 60480, that MTU 60 option must be ignored. 62 In any case, implementations must be able to send and receive IPv6 63 datagrams up to 576 octets in length, and are strongly encouraged to 64 handle IPv6 datagrams up to 1500 octets in length. 66 Implementations may accept arriving IPv6 datagrams which are larger 67 than their configured maximum transmission unit. They are not 68 required to discard such datagrams. 70 Stateless Auto-configuration and Link-Local Addresses 72 The address token [CONF] for an ARCnet interface is the interface's 73 configured 8-bit hardware address, in canonical bit order. 75 An IPv6 address prefix used for stateless auto-configuration of an 76 ARCnet interface must be 120 bits in length. 78 The IPv6 Link-local address [AARCH] for an ARCnet interface is formed 79 by appending the interface's hardware address to the 120-bit prefix 80 FE80::/120 82 +-------+-------+-------+-------+-------+-------+------+---------------+ 83 | FE 80 00 00 00 00 00 00 | 84 +-------+-------+-------+-------+-------+-------+------+---------------+ 85 | 00 00 00 00 00 00 00 | ARCnet address| 86 +-------+-------+-------+-------+-------+-------+------+---------------+ 88 Address Mapping -- Unicast 90 The procedure for mapping IPv6 addresses into ARCnet link-layer 91 addresses is described in [DISC]. The Source/Target link layer 92 Address option has the following form when the link layer is ARCnet. 94 +-------+-------+---------------+-------+-------+---...------+ 95 | Type |Length | ARCnet Address| 5 octets of padding | 96 +-------+-------+---------------+-------+-------+---...------+ 98 Option fields: 99 Type 1 for Source Link-layer address. 100 2 for Target Link-layer address. 101 Length 1 (in units of 8 octets). 103 ARCnet address 105 The 8 bit ARCnet address, in canonical bit order. 107 Address Mapping -- Multicast 109 As ARCnet only provides 1 multicast address (hex 00), all IPv6 110 multicast packets must be mapped to this address. 112 Security Considerations 114 Security issues are not discussed in this memo. 116 References 118 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 119 Architecture", RFC 1884, December 1995. 121 [ARCIPV4] Provan, D., "Transmitting IP Traffic over ARCNET Networks", 122 RFC1201, Novell, Inc., February 1991 124 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 125 Autoconfiguration", RFC 1971, August 1996. 127 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 128 for IP Version 6 (IPv6)", RFC 1970, August 1996. 130 [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) 131 Specification. RFC1883. 133 [PHDS] Novell, Inc., "ARCNET Packet Header Definition Standard", 134 Novell, Inc., November 1989. 136 Author's Address 138 Ignatios Souvatzis 139 The NetBSD Project 140 Stationenweg 29 141 D-53332 Bornheim 142 Germany 144 Phone (work): +49 (228) 734316 146 EMail: is@netbsd.org