idnits 2.17.1 draft-souvatzis-ipv6-arcnet-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-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 (5 October 1996) is 10065 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 43, but not defined == Unused Reference: 'ARCIPV4' is defined on line 120, 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. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT I. Souvatzis 2 Expires 5 April 1997 The NetBSD Project 3 5 October 1996 5 A Method for the Transmission of IPv6 Packets over ARCnet Networks. 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Distribution of this memo is unlimited. Please send comments to the 27 author. 29 Introduction 31 This memo specifies a frame format for transmission of IPv6 [IPV6] 32 packets and the method of forming IPv6 link-local addresses on ARCnet 33 networks. It also specifies the content of the Source/Target Link- 34 layer Address option used by the Router Solicitation, Router 35 Advertisement, Neighbor Solicitation, and Neighbor Advertisement 36 messages described in [DISC], when those messages are transmitted on 37 an ARCnet. 39 Frame Format 41 IPv6 packets are link layer fragmented and reassembled according to 42 [PHDS]. A brief but sufficient discussion of this fragmentation 43 method can be found in [ARCIP4]. 45 The protocol id used is hex D4, the same as for IPv4. IPv6 packets 46 are recognized by looking at the version number in the high half of 47 the first octet of the data, which is 4 for IPv4 and 6 for IPv6. 49 Maximum Transmission Unit 51 The maximum IPv6 packet length possible using this encapsulation 52 method is 60,480 octets. Since this length is impractical, all ARCnet 53 implementations on a given ARCnet network will need to agree on a 54 smaller value. In the presence of a router, this size should be 55 reduced by a Router Advertisement [DISC] containing an MTU option, or 56 by manual configuration of each node. If a Router Advertisement is 57 received with an MTU option specifying an MTU larger than 60480, or 58 larger than a manually configured value less than 60480, that MTU 59 option must be ignored. 61 In any case, implementations must be able to send and receive IPv6 62 datagrams up to 576 octets in length, and are strongly encouraged to 63 handle IPv6 datagrams up to 1500 octets in length. 65 Implementations may accept arriving IPv6 datagrams which are larger 66 than their configured maximum transmission unit. They are not 67 required to discard such datagrams. 69 Stateless Auto-configuration and Link-Local Addresses 71 The address token [CONF] for an ARCnet interface is the interface's 72 configured 8-bit hardware address, in canonical bit order. 74 An IPv6 address prefix used for stateless auto-configuration of an 75 ARCnet interface must be 120 bits in length. 77 The IPv6 Link-local address [AARCH] for an ARCnet interface is formed 78 by appending the interface's hardware address to the 120-bit prefix 79 FE80::0.0.0 81 +-------+-------+-------+-------+-------+-------+------+---------------+ 82 | FE 80 00 00 00 00 00 00 | 83 +-------+-------+-------+-------+-------+-------+------+---------------+ 84 | 00 00 00 00 00 00 00 | ARCnet address| 85 +-------+-------+-------+-------+-------+-------+------+---------------+ 87 Address Mapping -- Unicast 89 The procedure for mapping IPv6 addresses into ARCnet link-layer 90 addresses is described in [DISC]. The Source/Target link layer 91 Address option has the following form when the link layer is ARCnet. 93 +-------+-------+---------------+-------+-------+---...------+ 94 | Type |Length | ARCnet Address| 5 octets of padding | 95 +-------+-------+---------------+-------+-------+---...------+ 97 Option fields: 98 Type 1 for Source Link-layer address. 99 2 for Target Link-layer address. 100 Length 1 (in units of 8 octets). 102 ARCnet address 104 The 8 bit ARCnet address, in canonical bit order. 106 Address Mapping -- Multicast 108 As ARCnet only provides 1 multicast address (hex 00), all IPv6 109 multicast packets must be mapped to this address. 111 Security Considerations 113 Security issues are not discussed in this memo. 115 References 117 [AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing 118 Architecture", RFC 1884, December 1995. 120 [ARCIPV4] Provan, D., "Transmitting IP Traffic over ARCNET Networks", 121 RFC1201, Novell, Inc., February 1991 123 [CONF] Thomson, S., and T. Narten, "IPv6 Stateless Address 124 Autoconfiguration", RFC 1971, August 1996. 126 [DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 127 for IP Version 6 (IPv6)", RFC 1970, August 1996. 129 [IPV6] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) 130 Specification. RFC1883. 132 [PHDS] Novell, Inc., "ARCNET Packet Header Definition Standard", 133 Novell, Inc., November 1989. 135 Author's Address 137 Ignatios Souvatzis 138 The NetBSD Project 139 Muehlental 27 140 D-53639 Koenigswinter 141 Germany 143 Phone (work): +49 (228) 734316 145 EMail: is@netbsd.org