Network Working Group G. Montenegro Internet-Draft Sun Microsystems, Inc. Expires: July 26, 2005 January 25, 2005 Transmission of IPv6 Packets over IEEE 802.15.4 Networks draft-montenegro-lowpan-ipv6-over-802.15.4 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Montenegro Expires July 26, 2005 [Page 1] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 3 2. IEEE 802.15.4 mode for IP . . . . . . . . . . . . . . . . . . 3 3. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 4 4. Adaptation Layer and Frame Format . . . . . . . . . . . . . . 5 4.1 Link Fragmentation . . . . . . . . . . . . . . . . . . . . 5 4.2 Reassembly . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Stateless Address Autoconfiguration . . . . . . . . . . . . . 8 6. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 9 7. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 9 8. Header Compression . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 11 8.2 Non-Compressed IPv6 Fields . . . . . . . . . . . . . . . . 13 9. Packet Delivery in a Mesh . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 13.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Montenegro Expires July 26, 2005 [Page 2] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 1. Introduction The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal area networks. This document defines the frame format for transmission of IPv6 [RFC2460] packets as well as the formation of IPv6 link-local addresses and statelessly autoconfigured addresses on top of IEEE 802.15.4 networks. Since IPv6 requires support of packet sizes much larger than the largest IEEE 802.15.4 frame size, an adaptation layer is defined. This document also defines the header compression functionality required to make IPv6 practical on IEEE 802.15.4 networks. Likewise, the functionality required for packet delivery in IEEE 802.15.4 meshes is defined. However, a full specification of mesh routing (the specific protocol used, the interactions with neighbor discovery, etc) is out of scope of this document. 1.1 Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. IEEE 802.15.4 mode for IP IEEE 802.15.4 defines several modes of operation. The specification allows for frames in which either the source or destination addresses (or both) are elided. The mechanisms defined in this document require that both source and destination addresses be included in the IEEE 802.15.4 frame header. The source or destination PAN ID fields may be included. This document requires that at least the Contention-based channel access (CSMA/CA) be used, and does not require the Guaranteed Time Service (GTS). IEEE 802.15.4 allows the use of either IEEE 64 bit extended addresses or (after an association event) 16 bit addresses unique within the PAN. This document assumes use of 64 bit extended addresses, but 16 bit address support may be added in a future revision. This document assumes that a PAN maps to a specific IPv6 link, hence it implies a unique prefix. If the PAN ID (16 bits) is included in the IEEE 802.15.4 headers, it may be possible to use it to automatically map to the corresponding IPv6 prefix. One possible method is to concatenate the 16 bits of PAN ID to a /48 in order to obtain the link prefix. Whichever method is used, the assumption in this document is that a given PAN ID maps to a unique IPv6 prefix. As usual, hosts learn IPv6 prefixes via router advertisements ([I-D.ietf-ipv6-2461bis]). Montenegro Expires July 26, 2005 [Page 3] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 3. Maximum Transmission Unit The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets. However, a full packet does not fit in an IEEE 802.15.4 frame. 802.15.4 protocol data units have different sizes depending on how much overhead is present [ieee802.15.4]. Starting from a maximum physical layer packet size of 127 octets (aMaxPHYPacketSize) and a maximum frame overhead of 25 (aMaxFrameOverhead), the resultant maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets available. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with section 5 of the IPv6 specification [RFC2460], a fragmention and reassembly adaptation layer must be provided at the layer below IP. Such a layer is defined below in Section 4. Furthermore, since the IPv6 header is 40 octets long, this leaves only 41 octets for upper-layer protocols, like UDP. The latter uses 8 octets in the header which leaves only 33 octets for application data. Additionally, as pointed out above, there is a need for a fragmentation and reassembly layer, which will use even more octets. The above considerations lead to the following two observations: 1. The adaptation layer must be provided to comply with IPv6 requirements of minimum MTU. However, it is expected that (a) most applications of IEEE 802.15.4 will not use such large packets, and (b) small application payloads in conjunction with proper header compression will produce packets that fit within a single IEEE 802.15.4 frame. The justification for this adaptation layer is not just for IPv6 compliance, as it is quite likely that the packet sizes produced by certain application exchanges (e.g., configuration or provisioning) may require a small number of fragments. 2. Even though the above space calculation shows the worst case scenario, it does point out the fact that header compression is compelling to the point of almost being unavoidable. Since we expect that most (if not all) applications of IP over IEEE 802.15.4 will make use of header compression, it is defined below in Section 8. NOTE: In traditional IEEE 802 applications, a further 8 octets are taken up by LLC/SNAP encapsulation [RFC1042], which would leave only 73 octets for upper layer protocols (e.g., IP). SNAP encapsulation is not used in this specification. Any heartburn about this? Must Montenegro Expires July 26, 2005 [Page 4] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 think about compatibility with other applications (what do these do?). To guarantee interoperability, we might want to add the SNAP header. It's just more fixed overhead, as instead of following with the ether_type for IPv6 (and overloading the version field as per the hack in RFCs 1144 and 2507), we would want to follow the SNAP header with a new identifier for the adaptation layer defined below. 4. Adaptation Layer and Frame Format 4.1 Link Fragmentation All IP datagrams transported over IEEE 802.15.4 are prefixed by an encapsulation header with one of the formats illustrated below. If an entire IP datagram may be transmitted within a single 802.15.4 packet, it is unfragmented and the first octet of the data payload SHALL conform to the format illustrated below. In this case, the overhead is 1 octet. It is expected that this will be, by far, the most common case. NOTE: All fields marked "reserved" or "rsv" SHALL be zero. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|prot_type|M| IPv6 packet (or Final Destination) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Unfragmented encapsulation header format Field definitions are as follows: LF: This 2 bit field SHALL be zero. prot_type: This 5 bit field SHALL indicate the nature of the datagram that follows. In particular, the prot_type for IPv6 is 1 hexadecimal. The value 2 hexadecimal is defined below for header compression (Section 8). Other protocols may use this encapsulation format, but such use is outside the scope of this document. Subsequent assignments are to be handled by IANA (Section 10). NOTE: This field serves a purpose similar to that of the PPP DLL or ethertype protocol numbers (16 bits). However, in the interest of reducing the overhead in the common case, here we only have 6 bits. Assuming that we do not use the value zero, this leaves 31 type assignments in total. It is apparent that this may be enough. But in case it is not, it is important to know that it is Montenegro Expires July 26, 2005 [Page 5] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 possible to grow beyond these 5 bits. One way to do so is to assume that the actual field holds 7 bits, which leaves plenty of possibilities for future assignments. In such a case, the above format could only be used with the first 31 types assignments. Use of types beyond the initial ones assignments would require use of the frame format below. This format, defined below to transmit the *first* fragment, can be overloaded to mean "first *and* last" (i.e., unfragmented). This can be accomplished by using a datagram_label of zero (otherwise illegal), and/or simply in an implicit fashion via the datagram_size information. Accordingly, it seems prudent to leave a "rsv" field in front of the prot_type field in the frame below, pending further discussion. M: This bit is used to signal whether there is a "Final Destination" field as used for ad hoc or mesh routing. If set to 1, a "Final Destination" field precedes the IPv6 packet (Section 9). If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. The first link fragment SHALL conform to the format shown below. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF|rsv | prot_type |M|datagram_label | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: First fragment encapsulation header format The second and subsequent link fragments (up to and including the last) SHALL conform to the format shown below. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LF| datagram_offset |datagram_label | datagram_size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Subsequent fragment(s) encapsulation header format Field definitions are as follows: LF: This 2 bit field SHALL specify the relative position of the link fragment within the IP datagram, as encoded by the following table. Montenegro Expires July 26, 2005 [Page 6] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 LF Position +------------------------+ | 00 | Unfragmented | | 01 | First | | 10 | Last | | 11 | Interior | +------------------------+ Figure 4: Link Fragment Bit Pattern datagram_size: This 11 bit field encodes the size of the entire IP datagram. The value of datagram_size SHALL be the same for all link fragments of an IP datagram and SHALL be 40 octets more (the size of the IPv6 header) than the value of Payload Length in the datagram's IPv6 header [RFC2460]. Typically, this field needs to encode a maximum length of 1280 (IEEE 802.15.4 link MTU as defined in this document), and as much as 1500 (the default maximum IPv6 packet size if IPv6 fragmentation is in use). Therefore, this field is 11 bits long, which works in either case. NOTE: This field does not need to be in every packet, as one could send it with the first fragment and elide it subsequently. However, including it in every link fragment eases the task of reassembly in the event that a second (or subsequent) link fragment arrives before the first. In this case, the guarantee of learning the datagram_size as soon as any of the fragments arrives tells the receiver how much buffer space to set aside as it waits for the rest of the fragments. The format above trades off simplicity for efficiency. prot_type: This 7 bit field is present only in the first link fragment. For possible values, see Section 10. M: This bit is only present in the first link fragment. If set to 1, a "Final Destination" field to aid in mesh routing is present as per Section 9. fragment_offset: This field is present only in the second and subsequent link fragments and SHALL specify the offset, in octets, of the fragment from the beginning of the IP datagram. The first octet of the datagram (the start of the IP header) has an offset of zero; the implicit value of fragment_offset in the first link fragment is zero. This field is 11 bits long, as per the datagram_size explanation above. Montenegro Expires July 26, 2005 [Page 7] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 datagram_label: The value of datagram_label (datagram label) SHALL be the same for all link fragments of an IP datagram. The sender SHALL increment datagram_label for successive, fragmented datagrams; the incremented value of datagram_label SHALL wrap from 255 back to one. The value zero is not used. NOTE: The value zero is reserved as per the note under Figure 1. This may allow for a future overloading of the "first fragment" header to also mean "first and last fragment", thus allowing the use of extended protocol type numbers (8 bits instead of 6 bits). All IP datagrams SHALL be preceded by one of the encapsulation headers described above. This permits uniform software treatment of datagrams without regard to the mode of their transmission. 4.2 Reassembly The recipient of an IP datagram transmitted via more than one 802.15.4 packet SHALL use both the sender's 802.15.4 source address and datagram_label to identify all the link fragments from a single datagram. Upon receipt of a link fragment, the recipient may place the data payload (except the encapsulation header) within an IP datagram reassembly buffer at the location specified by fragment_offset. The size of the reassembly buffer may be determined from datagram_size. If a link fragment is received that overlaps another fragment identified by the same source address and datagram_label, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of fragment_offset from the encapsulation header and data_length from the 802.15.4 packet header. Upon detection of a IEEE 802.15.4 Disassociation event, the recipient(s) SHOULD discard all link fragments of all partially reassembled IP datagrams, and the sender(s) SHOULD discard all not yet transmitted link fragments of all partially transmitted IP datagrams. 5. Stateless Address Autoconfiguration The Interface Identifier [RFC3513] for an IEEE 802.15.4 interface is based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4 device. The Interface Identifier is formed from the EUI-64 according to the "IPv6 over Ethernet" specification [RFC2464]. Montenegro Expires July 26, 2005 [Page 8] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 A different MAC address set manually or by software MAY be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit. An IPv6 address prefix used for stateless autoconfiguration [I-D.ietf-ipv6-rfc2462bis] of an IEEE 802.15.4 interface MUST have a length of 64 bits. 6. IPv6 Link Local Address The IPv6 link-local address [RFC3513] for an IEEE 802.15.4 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64. 10 bits 54 bits 64 bits +----------+-----------------------+----------------------------+ |1111111010| (zeros) | Interface Identifier | +----------+-----------------------+----------------------------+ Figure 5 7. Unicast Address Mapping The procedure for mapping IPv6 unicast addresses into IEEE 802.15.4 link-layer addresses is described in [I-D.ietf-ipv6-2461bis]. The Source/Target Link-layer Address option has the following form when the link layer is IEEE 802.15.4. Montenegro Expires July 26, 2005 [Page 9] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- IEEE 802.15.4 -+ | | +- -+ | | +- Address -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Padding -+ | | +- (all zeros) -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Option fields: Type: 1: for Source Link-layer address. 2: for Target Link-layer address. Length: 2 (in units of 8 octets). IEEE 802.15.4 Address: The 64 bit IEEE 802.15.4 address, in canonical bit order. This is the address the interface currently responds to. This address may be different from the built-in address used to derive the Interface Identifier, because of privacy or security (e.g., of neighbor discovery) considerations. 8. Header Compression There is much published and in-progress standardization work on header compression. Nevertheless, header compression for IPv6 over IEEE 802.15.4 has differing constraints summarized as follows: Existing work assumes that there are many flows between any two devices. Here, we assume that most of the time there will be only one flow, and this allows a very simple and low context flavor of header compression. Montenegro Expires July 26, 2005 [Page 10] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 Given the very limited packet sizes, it is highly desirable to integrate layer 2 with layer 3 compression, something typically not done. It is expected that IEEE 802.15.4 devices will be deployed in multi-hop networks. However, header compression in a mesh departs from the usual point-to-point link scenario in which the compressor and decompressor are in direct and exclusive communication with each other. In an IEEE 802.15.4 network, it is highly desirable for a device to be able to send header compressed packets via any of its neighbors, with as little preliminary context-building as possible. Whenever preliminary context is required, here it is highly desirable to allow building it by not relying exclusively on the in-line negotiation phase. For example, if we assume there is some manual configuration phase that precedes deployment (perhaps with human involvement), then one should be able to leverage this phase to set up context such that the first packet sent will already be compressed. Header compression sends IPv6 packets in alternate and smaller formats. Thus, depending on which fields are being compressed, compressed headers may use any of different formats. In addition, compressors and decompressors must agree on the formats, and this compression negotiation is typically done via certain signaling packets. Any new packets formats required by header compression reuse the basic packet formats defined in Section 4 by using different values for the prot_type (defined below). 8.1 Encoding of IPv6 Header Fields However, it is possible to use header compression even in advance of setting up the customary state. Thus, the following common IPv6 header values may be compressed from the onset: Version is IPv6, both IPv6 source and destination are link local, the IPv6 bottom 64 bits can be inferred from the layer two source and destination, the packet length can be inferred from the layer two, both the Traffic Class and the Flow Label are zero, and the Next Header is UDP, ICMP or TCP. Thus, the IPv6 header info that always needs to be carried is the Hop Limit (8 bits). Depending on how closely the packet fits this common case, different fields may not be compressible thus needing to be carried as well. Such a packet is compressible via the LOWPAN_HC1 format (assigned a prot_type value of 2 hexadecimal). It uses the "HC1 encoding" field (8 bits) to encode the different combinations as shown below. Montenegro Expires July 26, 2005 [Page 11] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC1 encoding | Non-Compressed fields follow... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: LOWPAN_HC1 (common compressed header format) As can be seen below (bit 7), an HC2 encoding may follow an HC1 octet. In this case, the non-compressed fields follow the HC2 encoding field (TBD). The address fields encoded by "HC1 encoding" are interpreted as follows: PI: Prefix included in-line PC: Prefix compressed (link-local prefix assumed) II: Interface identifier included in-line IC: Interface identifier compressed (derived from link-layer address) The "HC1 encoding" is shown below (starting with bit 0 and ending at bit 7): IPv6 source address (bits 0 and 1): 00: PI, II 01: PI, IC 10: PC, II 11: PC, IC IPv6 destination address (bits 2 and 3): 00: PI, II 01: PI, IC 10: PC, II 11: PC, IC Traffic Class and Flow Label (bit 4): 0: not compressed, full 8 bits for Traffic Class and 20 bits for Flow Label are sent 1: Traffic Class and Flow Label are zero Next Header (bits 5 and 6): 00: not compressed, full 8 bits are sent 01: UDP 10: ICMP Montenegro Expires July 26, 2005 [Page 12] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 11: TCP HC2 encoding(bit 7): 0: No more header compression bits 1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format (TBD) 8.2 Non-Compressed IPv6 Fields The non-compressed IPv6 field that MUST be always present is the Hop Count (8 bits). This field MUST always follow the encoding fields (e.g., "HC1 encoding" as shown in Figure 7), perhaps including other future encoding fields). Other non-compressed fields must follow the Hop Count as implied by the "HC1 encoding" in the exact same order as shown above (Section 8.1): source address prefix (64 bits) and/or interface identifier (64 bits), destination address prefix (64 bits) and/or interface identifier (64 bits), Traffic Class (8 bits), Flow Label (20 bits) and Next Header (8 bits). The actual next header (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields. 9. Packet Delivery in a Mesh IEEE 802.15.4 does not define a mesh routing capability. Nevertheless, it is expected that most 802.15.4 networks will use mesh routing. In such cases, an ad hoc or mesh routing procotol populates the devices' routing tables. A device that wishes to send a packet may, in such cases, use other intermediate devices as forwarders towards the final destination. This typically implies that , in addition to the link-layer destination address of the packet, the link-layer address of the intended forwarder is required (although other delivery mechanisms may be possible). This is the purpose of the 'M' bit that immediately follows the 'prot_type' field. If the 'M' bit is set, there is a "Final Destination" field included in the packet immediately following the current header (e.g., possibly preceding any existing header compression fields). This implies that the "Final Destination" field will immediately follow an unfragmented packet as per Figure 1 (i.e., preceding the IPv6 Header), or immediately following the first fragment header as per Figure 2. If a node wishes to use a forwarder to deliver a packet, it puts the forwarder's link-layer address in the link-layer destination address field. It must also set the 'M' bit, and include a "Final Destination" field with the final destination's link-layer address. Similarly, if a node receives a frame with the 'M' bit set, it must look at the "Final Destination" field to determine the real destination. Upon consulting its routing table, it determines what the next hop towards that destination should be. The node then Montenegro Expires July 26, 2005 [Page 13] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 reduces the "Hops Left" field. If the result is zero, the node discards the packet. Otherwise, it puts the next hop's address in the link layer destination address field, and transmits the packet. If upon examining the "Final Destination" field the node determines that it has direct reachability, it removes the "Final Destination" field, sets that final address as the link layer destination address, and transmits the packet. The "Final Destination" field is defined as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Hops Left | Address of final destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Final Destination Field Field definitions are as follows: S: This bit field SHALL be zero. Future revisions will use this bit to signal the use of a short 16 bit address instead of the default IEEE extended 64 bit address format. Hops Left: This 7 bit field SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is discarded if Hops Left is decremented to 0. Address: This is the final destination's link layer address. This document assumes that this field is 64 bits long, but a future revision may add support for short addresses (16 bits). 10. IANA Considerations This document creates a new IANA registry for the prot_type (Protocol Type) field shown in the packet formats in Section 4. This document defines the values 1 and 2 hexadecimal for IPv6 and the LOWPAN_HC1 header compression format, respectively. Future assignments in this field are to be coordinated via IANA under the policy of "Specification Required" [RFC2434]. It is expected that this policy will allow for other (non-IETF) organizations to more easily obtain assignments. This document defines this field to be 5 bits long. The value 0 being reserved and not used, this allows for a total of 31 different values. If there is a need for more assignments, future specifications may lengthen this field, e.g., by overloading the packet format in Figure 2 (Section 4). Montenegro Expires July 26, 2005 [Page 14] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 11. Security Considerations The method of derivation of Interface Identifiers from MAC addresses is intended to preserve global uniqueness when possible. However, there is no protection from duplication through accident or forgery. Neighbor Discovery in IEEE 802.15.4 links may be susceptible to threats as detailed in [RFC3756]. Accordingly, Secure Neighbor Discovery is recommended. Mesh routing is expected to be common in IEEE 802.15.4 networks. This implies additional threats due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some capability for link-layer security. Users are urged to make use of such provisions if at all possible and practical. Doing so will alleviate the threats referred to above. 12. Acknowledgements Thanks to the authors of RFC 2464 and RFC 2734, as parts of this document are patterned after theirs. Thanks also to Geoff Mulligan and Nandakishore Kushalnagar for discussions which have helped shaped this document. 13. References 13.1 Normative References [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/regauth/oui/tutorials/EUI64.html . [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-01 (work in progress), October 2004. [I-D.ietf-ipv6-rfc2462bis] Thomson, S., "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07 (work in progress), December 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Montenegro Expires July 26, 2005 [Page 15] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003. 13.2 Informative References [I-D.ietf-ipngwg-icmp-v3] Conta, A., "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-06 (work in progress), November 2004. [I-D.ietf-ipv6-node-requirements] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier's AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols vol 1, issues 2-3, September 2003. [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, February 1988. [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Montenegro Expires July 26, 2005 [Page 16] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 Author's Address Gabriel Montenegro Sun Microsystems, Inc. EMail: gab@sun.com Montenegro Expires July 26, 2005 [Page 17] Internet-Draft IPv6 over IEEE 802.15.4 January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Montenegro Expires July 26, 2005 [Page 18]