Internet DRAFT - draft-elpro-ipv4-lowpan
draft-elpro-ipv4-lowpan
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
