Network Working Group J. Hui Internet-Draft Arch Rock Corporation Intended status: Informational Z. Shelby Expires: January 7, 2008 Sensinode D. Culler Arch Rock Corporation July 6, 2007 Interoperability Test for 6LoWPAN draft-hui-6lowpan-interop-00 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 7, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a first step in testing and demonstrating the interoperability of independent 6LoWPAN implementations. Hui, et al. Expires January 7, 2008 [Page 1] Internet-Draft 6LoWPAN Interop Test July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Level 0 Interoperability Requirements . . . . . . . . . . . . . 3 3. Level 1 Interoperability Requirements . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Hui, et al. Expires January 7, 2008 [Page 2] Internet-Draft 6LoWPAN Interop Test July 2007 1. Introduction A method for transmitting IPv6 [RFC2460] packets over IEEE 802.15.4 [ieee802.15.4] networks was specified in [I-D.ietf-6lowpan-format] as a proposed standard. To advance the specification to a draft standard, the Internet standards process [RFC2026] requires demonstration of at least two independent and interoperable implementations in order to advance the specification to a draft standard. The 6LoWPAN format supports a pay-as-you-go approach, where simple, common-case packets are highly compressed and less commonly used mechanisms are inserted as needed. While complete interoperability will require demonstrating all possible combinations of the 6LoWPAN format, it is often useful to test and demonstrate smaller portions along the way. This memo defines the first step in the process, identified as Level 0 and Level 1 6LoWPAN Interoperability. Level 0 is basic uncompress IPv6 unicast communication of IPv6 datagrams. Level 1 addresses the simple, but common case: fully-compressed link- local, unicast communication of IPv6 datagrams. It is anticipated that additional interoperability levels will be defined in the future. This memo only provides information to the Internet community, it does not specify an Internet standard of any kind. 2. Level 0 Interoperability Requirements Level 0 interoperability must demonstrate the capability to both generate and process uncompressed unicast packets. Because 6LoWPAN only defines the format (i.e. how bits go on the air), ICMPv6 and UDP echo request/reply are used as the protocols for demonstration. Level 0 interoperability does not demonstrate the ability to generate or process the 6LoWPAN Mesh, Fragmentation, or Broadcast headers. The Level 0.0 interoperability requirements are as follows: o The 6LoWPAN implementation must support a uncompressed header for link-local unicast. Version is IPv6. Next Header is either UDP or ICMP. The IEEE 802.15.4 header contains full 8-byte EUI-64 addressing for both source and destination addresses, the PAN ID compression is enabled, and no link-layer security mechanisms are enabled. The 802.15.4 header size in this scenario is 21 octets, not including the length field (1 octet). The 802.15.4 footer consists of the FCS (2 octets). Hui, et al. Expires January 7, 2008 [Page 3] Internet-Draft 6LoWPAN Interop Test July 2007 o The 6LoWPAN implementation must support ICMPv6 echo and reply processing as specified in ICMPv6 [RFC4443]. The generation of ICMPv6 echo requests can be signaled by an internal timer, commands through an independent interface (e.g. serial), or external events (e.g. user button). The generation of ICMPv6 echo replies should be generated in response to echo requests as specified in [RFC4443]. Because this interoperability level does not demonstrate fragmentation and IEEE 802.15.4's MTU 127 octets, echo request/reply payloads will be limited to what fits in a single frame. o The 6LoWPAN implementation must support UDP echo/reply on port 7 as specified in Echo Protocol [RFC0862]. The use of UDP echo/ reply must follow the same generation and maximum size guidelines as above for ICMPv6 echo/reply. The Level 0.1 interoperability requirements are as follows: o The 6LoWPAN implementation must support a uncompressed header as per level 0.0, but for global unicast addresses. 3. Level 1 Interoperability Requirements Level 1 interoperability must demonstrate the capability to both generate and process LOWPAN_HC1 packets. Because 6LoWPAN only defines the format (i.e. how bits go on the air), ICMPv6 and UDP echo request/reply are used as the protocols for demonstration. Level 1 interoperability does not demonstrate the ability to generate or process the 6LoWPAN Mesh, Fragmentation, or Broadcast headers. The Level 1 interoperability requirements are as follows: o The 6LoWPAN implementation must support a fully-compressed header. A fully-compressed header is defined as the minimal header format (inclusive of 802.15.4) that supports the required functionality. In the case of link-local unicast, the IPv6 header is compressed down to two octets: Hop Limit (1 octet) and LOWPAN_HC1 Encoding (1 octet). Of the compressed IPv6 header fields, Version is IPv6, Traffic Class and Flow Label is zero, Payload Length and both addresses are derived from the 802.15.4 header, and Next Header is either UDP or ICMP as specified in LOWPAN_HC1 Encoding. A LoWPAN Dispatch header (1 octet) is used to identify LOWPAN_HC1 encoding. The IEEE 802.15.4 header contains full 8-byte EUI-64 addressing for both source and destination addresses, the PAN ID compression is enabled, and no link-layer security mechanisms are enabled. The 802.15.4 header size in this scenario is 21 octets, not including the length field (1 octet). The 802.15.4 footer Hui, et al. Expires January 7, 2008 [Page 4] Internet-Draft 6LoWPAN Interop Test July 2007 consists of the FCS (2 octets). o The 6LoWPAN implementation must support ICMPv6 echo and reply processing as specified in ICMPv6 [RFC4443]. The generation of ICMPv6 echo requests can be signaled by an internal timer, commands through an independent interface (e.g. serial), or external events (e.g. user button). The generation of ICMPv6 echo replies should be generated in response to echo requests as specified in [RFC4443]. Because this interoperability level does not demonstrate fragmentation and IEEE 802.15.4's MTU 127 octets, echo request/reply payloads will be limited to what fits in a single frame. o The 6LoWPAN implementation must support UDP [RFC0768] with HC_UDP encoding with a fully-compressed header. A fully-compressed header is defined as having the HC_UDP encoding (1 octet), compressed UDP source and destination ports (1 octet), as well as compressed length. The UDP checksum field is not compressed (2 octets). The total size of the UDP header is (4 octets). o The 6LoWPAN implementation must support UDP echo/reply specified in Echo Protocol [RFC0862]. Because HC_UDP does not support compression of port value 7, Level 1.0 interop specifies using port 61616 + 7 = 61623 as the echo port. The use of UDP echo/ reply must follow the same generation and maximum size guidelines as above for ICMPv6 echo/reply. The header formats (including 802.15.4 and 6LoWPAN) of this interoperability test is shown in Figure 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.15.4 Len | 802.15.4 FCF | 802.15.4 DSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.15.4 Dest PANID | 802.15.4 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address | 802.15.4 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address |LoWPAN HC1 Dsp | HC1 encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop limit | ICMPv6 Header + Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hui, et al. Expires January 7, 2008 [Page 5] Internet-Draft 6LoWPAN Interop Test July 2007 Figure 1: Fully-Compressed ICMPv6 Over Link-Local Unicast 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.15.4 Len | 802.15.4 FCF | 802.15.4 DSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.15.4 Dest PANID | 802.15.4 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Destination ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address | 802.15.4 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Source ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address |LoWPAN HC1 Dsp | HC1 encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | HC_UDP encod | UDP Header + Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Fully-Compressed UDP Over Link-Local Unicast 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations This memo does not specify any additional security considerations to those in [I-D.ietf-6lowpan-format]. 6. Normative References [I-D.ietf-6lowpan-format] Montenegro, G., "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", draft-ietf-6lowpan-format-13 (work in progress), April 2007. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision Hui, et al. Expires January 7, 2008 [Page 6] Internet-Draft 6LoWPAN Interop Test July 2007 3", BCP 9, RFC 2026, October 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", September 2006. Authors' Addresses Jonathan W. Hui Arch Rock Corporation 657 Mission St. Ste 600 San Francisco, California 94105 USA Phone: 415 692 0828 Email: jhui@archrock.com Zach Shelby Sensinode Teknologiantie 6 Oulu, Oulu 90570 Finland Phone: +358 40 7796297 Email: zach.shelby@sensinode.com David E. Culler Arch Rock Corporation 657 Mission St. Ste 600 San Francisco, California 94105 USA Phone: 415 692 0828 Email: dculler@archrock.com Hui, et al. Expires January 7, 2008 [Page 7] Internet-Draft 6LoWPAN Interop Test July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hui, et al. Expires January 7, 2008 [Page 8]