idnits 2.17.1 draft-fujisawa-ip1394-ipv6-01.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-25) 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 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IPV6], [DISC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 1998) is 9293 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) == Outdated reference: A later version (-19) exists of draft-ietf-ip1394-ipv4-11 -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec-v2 is -01, but you're referring to -02. ** 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. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-discovery-v2 is -02, but you're referring to -03. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-trans-ethernet is -03, but you're referring to -04. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft K. Fujisawa 3 Sony Corporation 4 Expires: May, 1999 November 1998 6 Transmission of IPv6 Packets over IEEE 1394 Networks 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 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. 31 This document proposes the frame format for transmission of IPv6 32 [IPV6] packets and the method of forming IPv6 link-local addresses 33 and statelessly autoconfigured addresses on IEEE1394 networks. 34 It also proposes the content of the Source/Target Link-layer Address 35 option used in Neighbor Discovery [DISC] when the messages are 36 transmitted on an IEEE1394 network. 38 1. INTRODUCTION 40 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. 41 IETF IP1394 Working Group is standardizing the method to carry IPv4 42 datagrams and ARP packets over IEEE1394 subnetwork [IP1394]. 44 This document proposes the frame format for transmission of IPv6 45 [IPV6] packets and the method of forming IPv6 link-local addresses 46 and statelessly autoconfigured addresses on IEEE1394 networks. 47 It also proposes the content of the Source/Target Link-layer Address 48 option used in Neighbor Discovery [DISC] when the messages are 49 transmitted on an IEEE1394 network. 51 2. IPv6-CAPABLE NODES 53 An IPv6-capable node shall fulfill the requirements described 54 in "3. IP-CAPABLE NODES" of [IP1394]. 56 Following lists are excerpted from [IP1394] for convenience. 58 - the max_rec field in its bus information block shall be at least 8; 59 this indicates an ability to accept write requests with data 60 payload of 512 octets. The same ability shall also apply to read 61 requests; that is, the node shall be able to transmit a response 62 packet with a data payload of 512 octets; 64 - it shall be isochronous resource manager capable, as specified by 65 1394; 67 - it shall support both reception and transmission of asynchronous 68 streams as specified by P1394a; 70 - it shall implement the NETWORK_CHANNELS register; and 72 - it shall be network protocol manager (NPM) capable. 74 3. LINK ENCAPSULATION AND FRAGMENTATION 76 The encapsulation and fragmentation mechanism should be the same 77 as "6. LINK ENCAPSULATION AND FRAGMENTATION" of [IP1394]. 79 The ether_type value for IPv6 is 0x86dd. 81 The default MTU size for IPv6 packets on an IEEE1394 network is 1500 82 octets. This size may be reduced by a Router Advertisement [DISC] 83 containing an MTU option which specifies a smaller MTU, or by manual 84 configuration of each node. If a Router Advertisement received on 85 an IEEE1394 interface has an MTU option specifying an MTU larger than 86 1500, or larger than a manually configured value, that MTU option may 87 be logged to system management but must be otherwise ignored. The 88 mechanism to extend MTU size between particular two nodes is for 89 further study. 91 4. STATELESS AUTOCONFIGURATION 93 The Interface Identifier [AARCH] for an IEEE1394 interface is formed 94 from the interface's built-in EUI-64 by complementing the 95 "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of 96 the first octet of the EUI-64. Complementing this bit will generally 97 change a 0 value to a 1, since an interface's built-in address is 98 expected to be from a universally administered address space and 99 hence have a globally unique value. A universally administered EUI- 100 64 is signified by a 0 in the U/L bit position, while a globally 101 unique IPv6 Interface Identifier is signified by a 1 in the 102 corresponding position. For further discussion on this point, see 103 [AARCH]. 105 An IPv6 address prefix used for stateless autoconfiguration [ACONF] 106 of an IEEE1394 interface must have a length of 64 bits. 108 5. LINK-LOCAL ADDRESSES 110 The IPv6 link-local address [AARCH] for an IEEE1394 interface is 111 formed by appending the Interface Identifier, as defined above, to 112 the prefix FE80::/64. 114 10 bits 54 bits 64 bits 115 +----------+-----------------------+----------------------------+ 116 |1111111010| (zeros) | Interface Identifier | 117 +----------+-----------------------+----------------------------+ 119 6. ADDRESS MAPPING FOR UNICAST 121 The procedure for mapping IPv6 unicast addresses into IEEE1394 link- 122 layer addresses uses the Neighbor Discovery [DISC]. 123 The Source/Target Link-layer Address option has the following form 124 when the link layer is IEEE1394. 126 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length = 3 | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ 131 | node_unique_ID | 132 +--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | node_ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | unicast_FIFO | 136 +--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | max_rec | spd | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | reserved | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Type 1 for Source Link-layer address. 143 2 for Target Link-layer address. 145 Length 3 (in units of 8 octets). 147 The meaning of 'node_unique_ID', 'node_ID', 'unicast_FIFO', 'max_rec' 148 and 'spd' sub-fields are specified in [IP1394]. 150 Note that 'node_ID' may change when 1394 bus-reset occurs. The 151 mapping cache held in the node should be cleared on 1394 bus-reset. 153 7. IPv6 MULTICAST 155 By default, all best-effort IPv6 multicast shall use asynchronous 156 stream packets whose channel number is equal to the channel field 157 from the NETWORK_CHANNELS register. 159 Best-effort IPv6 multicast for particular multicast group addresses 160 may utilize a different channel number if such a channel number is 161 allocated and advertised prior to use, by the multicast channel 162 allocation protocol (MCAP), as described in [IP1394]. The 'type' 163 field in MCAP group address descriptor shall be 2 to indicate an IPv6 164 group address descriptor. 166 8. OPEN ISSUES 168 a) The mechanism to extend MTU size between particular two nodes. 170 b) The mechanism to allocate and distribute a 1394 isochronous 171 channel number for isochronous transmission of IPv6 packets, 172 for an unicast or multicast flow. 174 Security Considerations 176 Security issues are not discussed in this document. 178 Acknowledgement 180 The auther would like to acknowledge the author of [ETHER] since some 181 part of this document has been derived from [ETHER]. 183 References 185 [IP1394] IP1394 Working Group, "IPv4 over IEEE 1394", currently 186 draft-ietf-ip1394-ipv4-11.txt. 188 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 189 Specification", currently draft-ietf-ipngwg-ipv6-spec-v2- 190 02.txt. 192 [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing 193 Architecture", RFC2373. 195 [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address 196 Autoconfiguration", currently draft-ietf-ipngwg-addrconf- 197 v2-02.txt. 199 [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery 200 for IP Version 6 (IPv6)", currently draft-ietf-ipngwg- 201 discovery-v2-03.txt. 203 [ETHER] M. Crawford, "Transmission of IPv6 Pacekts over Ethernet 204 Networks", currently draft-ietf-ipngwg-trans-ethernet-04.txt 206 Author's address 208 Kenji Fujisawa 209 Sony Corporation 210 IT Laboratories, Computer Systems Laboratory 211 6-7-35, Kitashinagawa, 212 Shinagawa-ku, Tokyo, 141-0001 Japan 213 Phone: +81-3-5448-4602 214 E-mail: fujisawa@sm.sony.co.jp 216 Technical changes from old version (-00.txt) 218 - Two octets padding in the Source/Target Link-layer Address option 219 of the Neighbor Discovery has been removed.