idnits 2.17.1 draft-fujisawa-ip1394-ipv6-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-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. == 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. ** There are 3 instances of lines with control characters in the document. ** 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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-09 -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addr-arch-v2 is -06, but you're referring to -07. -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-addrconf-v2 is -01, but you're referring to -02. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Kenji Fujisawa 3 Sony Corporation 4 Expires: January, 1999 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 35 Address option used in Neighbor Discovery [DISC] when the messages 36 are 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 48 Address option used in Neighbor Discovery [DISC] when the messages 49 are transmitted on an IEEE1394 network. 51 2. IPv6-CAPABLE NODES 53 An IPv6-capable node shall fulfill the requirements descrived 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 with "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 86 than 1500, or larger than a manually configured value, that MTU 87 option may be logged to system management but must be otherwise 88 ignored. The mechanism to extend MTU size between particular two 89 nodes is for further study. 91 4. STATELESS AUTOCONFIGURATION 93 The Interface Identifier [AARCH] for an IEEE1394 interface is 94 formed from the interface's built-in EUI-64 by complementing 95 the "Universal/Local" (U/L) bit, which is the next-to-lowest 96 order bit of the first octet of the EUI-64. Complementing 97 this bit will generally change a 0 value to a 1, since an 98 interface's built-in address is expected to be from a universally 99 administered address space and hence have a globally unique value. 100 A universally administered EUI-64 is signified by a 0 in the U/L 101 bit position, while a globally unique IPv6 Interface Identifier 102 is signified by a 1 in the corresponding position. 103 For further discussion on this point, see [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 122 link-layer addresses uses the Neighbor Discovery [DISC]. 123 The Source/Target Link-layer Address option has the following 124 form 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 | reserved | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | 132 +--- node_unique_ID ---+ 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | node_ID | unicast_FIFO_hi | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | unicast_FIFO_lo | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | max_rec | sspd | 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 mapping 151 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 164 IPv6 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 References 180 [IP1394] IP1394 Working Group, "IPv4 over IEEE 1394", currently 181 draft-ietf-ip1394-ipv4-09.txt. 183 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 184 Specification", currently draft-ietf-ipngwg-ipv6-spec-v2- 185 01.txt. 187 [AARCH] R. Hinden, S. Deering "IP Version 6 Addressing 188 Architecture", currently draft-ietf-ipngwg-addr-arch-v2- 189 07.txt. 191 [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address 192 Autoconfiguration", currently draft-ietf-ipngwg-addrconf- 193 v2-02.txt. 195 [DISC] T. Narten, E. Nordmark, W. A. Simpson, "Neighbor Discovery 196 for IP Version 6 (IPv6)", currently draft-ietf-ipngwg- 197 discovery-v2-02.txt. 199 Author's address 201 Kenji Fujisawa 202 Sony Corporation 203 IT Laboratories, Computer Systems Laboratory 204 6-7-35, Kitashinagawa, 205 Shinagawa-ku, Tokyo, 141-0001 Japan 206 Phone: +81-3-5448-4602 207 E-mail: fujisawa@sm.sony.co.jp