INTERNET-DRAFT H. Courtice draft-elpro-ipv4-lowpan-00 ELPRO Technologies Updates: 4944 April 11, 2008 Category: Experimental Expires: October 13, 2008 Extending 6LowPan to support IPv4 Packets 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. Abstract RFC4944 describes header compression formats for IPV6 (HC1) and for TCP, UDP and ICMP (HC2). No compression format is defined for IPV4 headers. This document describes a compression scheme for IPV4 headers which closely follows the IPV6 header compression format HC1 described in RFC4944. [Page 1] Internet-Draft April 2008 1. Introduction RFC4944 defines an extensive scheme for transmitting IPV6 frames over 802.15.4 low power personal area networks. This includes frame format, packet fragmentation, and address translation between 802.15.4 addressing and IPV6 addressing. The large majority of this work is also applicable to IPV4 frames. To extend RFC4944 to allow transmission of IPV4 frames over 802.15.4 networks simply requires the addition of an extra header compression format for IPV4 headers in line with the IPV6 header compression format defined in RFC4944. This document defines such a scheme. In addition, this document describes a scheme for converting 16-bit 802.15.4 link addresses to IPV4 internet addresses. 2. Deriving IPV4 Address from 802.15.4 link layer addresses To derive a 32-bit IP address from the 16-bit 802.15.4 link address of any 802.15.4 station simply concatenate the 16-bit PAN-ID of the 802.15.4 network with the 16-bit link address of the 802.15.4 station. 3. Header Compression 3.1 Encoding of IPV4 Header fields RFC4944 Section 10.1. describes an encoding method to reduce the number of bytes required to encode an IPV6 header to as little as two bytes using a bit-mask to indicate which sections of the header are carried in-line, and which fields are given either default values or values obtainable from the link-layer data frame. Here a similar method is described for IPV4 headers. IPV4 header fields may be compressed as by comparison with the most common values found in an IPV4 header: Version is IPV4; IPV4 source and destination addresses may be inferred from the layer two source and destination address (as described in section 1. above); the packet length can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header (if present); both the Type of service and the Flow Label are zero; The header length is 5 and the Next Header is one of: UDP, ICMP or TCP. The LOWPAN_HC4 encoding field incorporates 8 bits to encode which header fields are compressed and which are carried in-line following the LOWPAN_HC4 encoding field. In the same manner as for LOWPAN_HC1 compression, the LOWPAN_HC4 encoding may be followed by an HC2 encoding, and in this case the non-compressed fields follow the HC2 encoding field. [Page 2] Internet-Draft April 2008 The address fields encoded by HC4 encoding are interpreted as follows: inline: full 32-bit IPV4 addres is carried inline (section 3.) compressed: The IPV4 address is elided and is inferred from the 802.15.4 layer two address by concatenating the PAN ID with the 16-bit 802.15.4 short address. In the case that a mesh-header is included, the IPV4 address is derived from the layer two addresses in the mesh header (RFC4944 Section 5.2) The HC4 encoding is shown below (starging with bit 0 and ending at bit 7): IPV4 Source address (bit 0) 0: Source address carried inline 1: Source address compressed IPV4 Destination address (bit 1) 0: Destination address carried inline 1: Destination address compressed IPV4 Fragmentation compression (bit 2) 0: IPV4 Fragmentation fields carried in line 1: IPV4 Fragmentation compressed - MV = 0, DF = 0 Fragment Offset = 0, Id = 0. IP Header Length Compression (bit 3) 0: IHL Field carried in line, with IP options fields following directly 1: IHL Field compressed, value = 5. Type of service compression (bit 4) 0: Not compressed, 8 bits of Type of service field carried inline 1: Compressed - Type of service is "Precedence = 000; D=0; T=0; R=0" Next Header / Protocol field compression (bits5 and 6) 00: Protcocol field uncompressed - full 8 bits carried in line. 01: Protocol field is 17, UDP 10: Protocol field is 1, ICMP 11: Protocol field is 6, TCP bit 7 0: No more header compression bits 1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format. Bits 5 and 6 determine which of the possible HC2 encodings apply (e.g., UDP, ICMP, or TCP encodings). [Page 3] Internet-Draft April 2008 3.2 Non-Compressed IPV4 fields The non-compressed IPV4 field that MUST always be present is the TTL field (8 bits). This field MUST always follow the encoding fields (e.g., "HC4 encoding", perhaps including other future encoding fields). Other non-compressed fields MUST follow the TTL Field as implied by the "HC4 encoding" in the exact same order as shown above (Section 3.1): source address (32 bits), destination address (32 bits), Fragmentation Fields (32 bits), IP Header Length and additional IP Options fields (8 + 32 x (n-5) bits), Type of service (8 bits) and Next Header (8 bits). The actual next header (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields. 3.4 Dispatch value for LOWPAN_HC4 The dispatch value bit pattern indicating LOWPAN_HC4 header compression is: 01 000100 LOWPAN_HC4 - LOWPAN_HC4 compressed IPV4 4. IANA Considerations This document creates an new entry in the IANA registry "6lowpan-parameters" for the "Dispatch type field" described in RFC4944 section 5. This document adds the bit pattern: 01 000100 LOWPAN_HC4 - LOWPAN_HC4 compressed IPV4 5. Security Considerations This document raises no additional security considerations beyond those described in RFC4944. 6. Acknowledgements Thanks to the authors of RFC4944 as this work is an incremental addition to their work. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997 [RFC4944] Nontenegro, G., "Transmission of IPv6 Packets over IEEE 802.15.4 Network", RFC 4944, September 2007 [Page 4] Internet-Draft April 2008 Author's Address Harry Courtice ELPRO Technologies Pty Ltd email: harry.courtice@elprotech.com Expires: October 13, 2008 Copyright (C) The IETF Trust (2008). 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. 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. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html