RFC4944 日本語訳

4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G.Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT=67232 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                      G. Montenegro
Request for Comments: 4944                         Microsoft Corporation
Category: Standards Track                                 N. Kushalnagar
                                                              Intel Corp
                                                                  J. Hui
                                                               D. Culler
                                                          Arch Rock Corp
                                                          September 2007

コメントを求めるワーキンググループG.モンテネグロ要求をネットワークでつないでください: 4944年のマイクロソフト社カテゴリ: 標準化過程N.KushalnagarインテルCorp J.ホイD.害獣駆除業者アーチ岩石のCorp2007年9月

        Transmission of IPv6 Packets over IEEE 802.15.4 Networks

IEEE802.15.4のネットワークの上のIPv6パケットのトランスミッション

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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.
   Additional specifications include a simple header compression scheme
   using shared context and provisions for packet delivery in IEEE
   802.15.4 meshes.

このドキュメントはIPv6パケットのトランスミッションのためにフレーム形式について説明します、そして、IPv6のリンクローカルのアドレスと国がなさが自動構成した形成の方法はIEEEで802.15の.4ネットワークに演説します。 追加仕様は、パケット配信にIEEE802.15.4個のメッシュで共有された文脈と条項を使用することで簡単なヘッダー圧縮技術を含んでいます。

Montenegro, et al.          Standards Track                     [Page 1]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[1ページ]RFC4944IPv6

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
     1.2.  Terms Used . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  IEEE 802.15.4 Mode for IP  . . . . . . . . . . . . . . . . . .  3
   3.  Addressing Modes . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Maximum Transmission Unit  . . . . . . . . . . . . . . . . . .  5
   5.  LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . .  6
     5.1.  Dispatch Type and Header . . . . . . . . . . . . . . . . .  8
     5.2.  Mesh Addressing Type and Header  . . . . . . . . . . . . . 10
     5.3.  Fragmentation Type and Header  . . . . . . . . . . . . . . 11
   6.  Stateless Address Autoconfiguration  . . . . . . . . . . . . . 13
   7.  IPv6 Link Local Address  . . . . . . . . . . . . . . . . . . . 14
   8.  Unicast Address Mapping  . . . . . . . . . . . . . . . . . . . 14
   9.  Multicast Address Mapping  . . . . . . . . . . . . . . . . . . 16
   10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
     10.2. Encoding of UDP Header Fields  . . . . . . . . . . . . . . 19
     10.3. Non-Compressed Fields  . . . . . . . . . . . . . . . . . . 21
       10.3.1.  Non-Compressed IPv6 Fields  . . . . . . . . . . . . . 21
       10.3.2.  Non-Compressed and Partially Compressed UDP Fields  . 21
   11. Frame Delivery in a Link-Layer Mesh  . . . . . . . . . . . . . 21
     11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     15.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Alternatives for Delivery of Frames in a Mesh . . . . 28

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件記法. . . . . . . . . . . . . . . . . . 3 1.2 用語は.3 2を使用しました。 IP. . . . . . . . . . . . . . . . . . 3 3のためのIEEE802.15.4モード。 モード. . . . . . . . . . . . . . . . . . . . . . . 4 4を記述します。 マキシマム・トランスミッション・ユニット. . . . . . . . . . . . . . . . . . 5 5。 LoWPAN適合層とフレーム形式. . . . . . . . . . . 6 5.1。 タイプとヘッダー. . . . . . . . . . . . . . . . . 8 5.2を急派してください。 タイプとヘッダー. . . . . . . . . . . . . 10 5.3に演説して、かみ合ってください。 断片化タイプとヘッダー. . . . . . . . . . . . . . 11 6。 国がないアドレス自動構成. . . . . . . . . . . . . 13 7。 IPv6はローカルアドレス. . . . . . . . . . . . . . . . . . . 14 8をリンクします。 ユニキャストアドレス・マッピング. . . . . . . . . . . . . . . . . . . 14 9。 マルチキャストアドレス・マッピング. . . . . . . . . . . . . . . . . . 16 10。 ヘッダー圧縮. . . . . . . . . . . . . . . . . . . . . . 16 10.1。 IPv6ヘッダーフィールド. . . . . . . . . . . . . . 17 10.2はコード化されます。 UDPヘッダーフィールド. . . . . . . . . . . . . . 19 10.3はコード化されます。 非圧縮された分野. . . . . . . . . . . . . . . . . . 21 10.3.1。 非圧縮されたIPv6分野. . . . . . . . . . . . . 21 10.3.2。 非圧縮されて部分的に圧縮されたUDP分野. 21 11。 リンクレイヤメッシュ. . . . . . . . . . . . . 21 11.1で配送を縁どってください。 LoWPANは.23 12を放送します。 IANA問題. . . . . . . . . . . . . . . . . . . . . 23 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 25 14。 承認. . . . . . . . . . . . . . . . . . . . . . . 25 15。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 15.1。 引用規格. . . . . . . . . . . . . . . . . . . 26 15.2。 メッシュ. . . . 28でのフレームの配送のための有益な参照. . . . . . . . . . . . . . . . . . 26付録A.代替手段

1.  Introduction

1. 序論

   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 mechanisms
   for header compression required to make IPv6 practical on IEEE
   802.15.4 networks, and the provisions required for packet delivery in
   IEEE 802.15.4 meshes.  However, a full specification of mesh routing
   (the specific protocol used, the interactions with neighbor
   discovery, etc) is out of the scope of this document.

IEEE802.15.4規格[ieee802.15.4]は低パワーの個人的な領域ネットワークを狙います。 このドキュメントはIPv6[RFC2460]パケットのトランスミッションのためにフレーム形式をIPv6のリンクローカルのアドレスと国がなさの自動構成された構成がIEEEの上で802.15の.4ネットワークに演説するのと同じくらいよく定義します。 IPv6が最も大きいIEEE802.15.4フレーム・サイズよりはるかに大きいパケットサイズのサポートを必要とするので、適合層は定義されます。 また、ヘッダー圧縮がIEEEで実用的な造のIPv6に802.15の.4ネットワークを必要としたので、このドキュメントはメカニズムを定義します、そして、条項がIEEE802.15.4個のメッシュのパケット配信に必要です。 しかしながら、このドキュメントの範囲の外にメッシュルーティング(使用される、特定のプロトコル、隣人発見との相互作用など)の完全な仕様があります。

Montenegro, et al.          Standards Track                     [Page 2]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[2ページ]RFC4944IPv6

1.1.  Requirements Notation

1.1. 要件記法

   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].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

1.2.  Terms Used

1.2. 使用される用語

   AES:  Advanced Encryption Scheme

AES: 高度な暗号化計画

   CSMA/CA:  Carrier Sense Multiple Access / Collision Avoidance

CSMA/カリフォルニア: 搬送波感知多重アクセス/衝突回避用レーダー警報装置

   FFD:  Full Function Device

FFD: 完全な機能装置

   GTS:  Guaranteed Time Service

GTS: 保証寿命サービス

   MTU:  Maximum Transmission Unit

MTU: マキシマム・トランスミッション・ユニット

   MAC:  Media Access Control

Mac: メディアアクセス管理

   PAN:  Personal Area Network

以下を撮影してください。 パーソナル・エリア・ネットワーク

   RFD:  Reduced Function Device

RFD: 減少している機能装置

2.  IEEE 802.15.4 Mode for IP

2. IPのためのIEEE802.15.4モード

   IEEE 802.15.4 defines four types of frames: beacon frames, MAC
   command frames, acknowledgement frames, and data frames.  IPv6
   packets MUST be carried on data frames.  Data frames may optionally
   request that they be acknowledged.  In keeping with [RFC3819], it is
   recommended that IPv6 packets be carried in frames for which
   acknowledgements are requested so as to aid link-layer recovery.

IEEE802.15.4は4つのタイプのフレームを定義します: フレーム、MACコマンド・フレーム、承認フレーム、およびデータフレームを照らしてください。 データフレームの上にIPv6パケットを運ばなければなりません。 データフレームは、それらが承認されるよう任意に要求するかもしれません。 [RFC3819]と共に保つのにおいて、IPv6パケットが承認がリンクレイヤ回復を支援するために要求されているフレームで運ばれるのは、お勧めです。

   IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon-
   enabled [ieee802.15.4].  The latter is an optional mode in which
   devices are synchronized by a so-called coordinator's beacons.  This
   allows the use of superframes within which a contention-free
   Guaranteed Time Service (GTS) is possible.  This document does not
   require that IEEE networks run in beacon-enabled mode.  In nonbeacon-
   enabled networks, data frames (including those carrying IPv6 packets)
   are sent via the contention-based channel access method of unslotted
   CSMA/CA.

IEEE、「非-標識」が802.15の.4ネットワークが可能にすることができますか、または標識は[ieee802.15.4]を可能にしました。 後者は装置はいわゆるコーディネータの標識によって連動させられる任意のモードです。 これは無主張のGuaranteed Time Service(GTS)が可能である「スーパー-フレーム」の使用を許します。 このドキュメントは、IEEEネットワークが標識で可能にされたモードに立候補するのを必要としません。 「非-標識」の可能にされたネットワークでは、unslotted CSMA/カリフォルニアの主張ベースのチャンネルアクセス法でデータフレーム(IPv6パケットを運ぶものを含んでいる)を送ります。

   In nonbeacon-enabled networks, beacons are not used for
   synchronization.  However, they are still useful for link-layer
   device discovery to aid in association and disassociation events.
   This document recommends that beacons be configured so as to aid
   these functions.  A further recommendation is for these events to be

「非-標識」によって可能にされたネットワークでは、標識は同期に使用されません。 しかしながら、それらはまだ協会で支援するリンクレイヤ装置発見と「不-協会」出来事の役に立っています。 このドキュメントは、標識がこれらの機能を支援するために構成されることを勧めます。 存在のためにこれらの出来事はさらなる推薦があります。

Montenegro, et al.          Standards Track                     [Page 3]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[3ページ]RFC4944IPv6

   available at the IPv6 layer to aid in detecting network attachment, a
   problem being worked on at the IETF at the time of this writing.

この書くこと時点でIETFでネットワーク付属、扱われることにおける問題を検出する際に支援するIPv6層では、利用可能です。

   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 also be included.

仕様はソースか送付先アドレスが削除される(ともに)フレームを考慮します。 本書では定義されたメカニズムは、ソースと送付先アドレスの両方がIEEE802.15.4フレームヘッダーに含まれているのを必要とします。 また、ソースか目的地PAN ID分野が含まれるかもしれません。

3.  Addressing Modes

3. アドレッシング・モード

   IEEE 802.15.4 defines several addressing modes: it allows the use of
   either IEEE 64-bit extended addresses or (after an association event)
   16-bit addresses unique within the PAN [ieee802.15.4].  This document
   supports both 64-bit extended addresses, and 16-bit short addresses.
   For use within 6LoWPANs, this document imposes additional constraints
   (beyond those imposed by IEEE 802.15.4) on the format of the 16-bit
   short addresses, as specified in Section 12.  Short addresses being
   transient in nature, a word of caution is in order: since they are
   doled out by the PAN coordinator function during an association
   event, their validity and uniqueness is limited by the lifetime of
   that association.  This can be cut short by the expiration of the
   association or simply by any mishap occurring to the PAN coordinator.
   Because of the scalability issues posed by such a centralized
   allocation and single point of failure at the PAN coordinator,
   deployers should carefully weigh the tradeoffs (and implement the
   necessary mechanisms) of growing such networks based on short
   addresses.  Of course, IEEE 64-bit extended addresses may not suffer
   from these drawbacks, but still share the remaining scalability
   issues concerning routing, discovery, configuration, etc.

IEEE802.15.4はいくつかのアドレッシング・モードを定義します: それはPAN[ieee802.15.4]の中でユニークな64ビットの拡張アドレスか(協会イベントの後の)16ビットのアドレスをIEEEの使用に許容します。 このドキュメントは64ビットの拡張アドレスと16ビットの短いアドレスの両方をサポートします。 6LoWPANsの中の使用のために、このドキュメントが追加規制を課す、(IEEEによって課されたもの、802.15、.4、)、16ビットの形式では、アドレスをショートしてください、セクション12で指定されるように。 短いアドレスが現実に一時的であることで、警告の単語は整然としています: 協会イベントの間、PANコーディネータ機能でそれらを分け与えるので、それらの正当性とユニークさはその協会の生涯までに制限されます。 協会の満了か単にPANコーディネータの心に浮かぶどんな不運も短くこれを切ることができます。 PANコーディネータでそのような集結された配分と失敗の単一のポイント引き起こされたスケーラビリティ問題のために、デプロイヤは慎重に、短いアドレスに基づくそのようなネットワークを育てる見返り(必要なメカニズムを実行する)を熟慮するべきです。 もちろん、ルーティング、発見、構成などに関してまだ残っているスケーラビリティ問題を共有している以外に、IEEE広げられた64ビットアドレスはこれらの欠点に苦しまないかもしれません。

   This document assumes that a PAN maps to a specific IPv6 link.  This
   complies with the recommendation that shared networks support link-
   layer subnet [RFC3819] broadcast.  Strictly speaking, it is multicast
   not broadcast that exists in IPv6.  However, multicast is not
   supported natively in IEEE 802.15.4.  Hence, IPv6 level multicast
   packets MUST be carried as link-layer broadcast frames in IEEE
   802.15.4 networks.  This MUST be done such that the broadcast frames
   are only heeded by devices within the specific PAN of the link in
   question.  As per Section 7.5.6.2 in [ieee802.15.4], this is
   accomplished as follows:

このドキュメントは、特定のIPv6へのPAN地図がリンクされると仮定します。 これは共用回線網サポートリンク層のサブネット[RFC3819]が放送するという推薦に従います。 厳密に言うと、IPv6に存在するのは、放送されなかったマルチキャストです。 しかしながら、マルチキャストはIEEE802.15.4でネイティブに支持されません。 したがって、リンク層ブロードキャストがIEEEで802.15の.4ネットワークを縁どるとき、IPv6の平らなマルチキャストパケットを運ばなければなりません。 放送フレームが問題のリンクの特定のPANの中の装置によって意に介されるだけであるように、これをしなければなりません。 に従って、セクション7.5 .6 .2 [ieee802.15.4]では、これは以下の通り達成されます:

   1.  A destination PAN identifier is included in the frame, and it
       MUST match the PAN ID of the link in question.

1. 目的地PAN識別子はフレームに含まれています、そして、それは問題のリンクのPAN IDに合わなければなりません。

   2.  A short destination address is included in the frame, and it MUST
       match the broadcast address (0xffff).

2. 短い送付先アドレスはフレームに含まれています、そして、それは放送演説(0xffff)に合わなければなりません。

Montenegro, et al.          Standards Track                     [Page 4]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[4ページ]RFC4944IPv6

   Additionally, support for mapping of IPv6 multicast addresses per
   Section 9 MUST only be used in a mesh configuration.  A full
   specification of such functionality is out of the scope of this
   document.

さらに、メッシュ網にセクション9あたりのIPv6マルチキャストアドレスに関するマッピングのサポートを使用するだけでよいです。 このドキュメントの範囲の外にそのような機能性の完全な仕様があります。

   As usual, hosts learn IPv6 prefixes via router advertisements as per
   [RFC4861].

いつものように、ホストは[RFC4861]に従ってルータ通知でIPv6接頭語を学びます。

4.  Maximum Transmission Unit

4. マキシマム・トランスミッション・ユニット

   The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets.
   However, a full IPv6 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 5.

MTUサイズ、IEEE802.15の上のIPv6パケットに関しては、.4は1280の八重奏です。 しかしながら、完全なIPv6パケットはIEEE802.15.4フレームをうまくはめ込みません。 802.15.4 プロトコルデータ単位には、どのくらいのオーバーヘッドが存在しているかに依存する異なったサイズ[ieee802.15.4]があります。 127の八重奏の最大の物理的な層のパケット規模(aMaxPHYPacketSize)と25の最大のフレームオーバーヘッド(aMaxFrameOverhead)から始めて、メディアアクセス管理層の結果の最大のフレーム・サイズは102の八重奏です。 リンクレイヤセキュリティはさらなるオーバーヘッドを課します。(最大の場合AES-CCM-32とAES-CCM-64のための9と(それぞれAES-CCM-128場合における、オーバーヘッドの21の八重奏対13)では、それは、81の八重奏だけを利用可能な状態でおきます)。 明らかに遠くに1280の八重奏の最小のIPv6パケットサイズより下であるにはこれがあります、そして、IPv6のセクション5と共に仕様が[RFC2460]であると保つのに、IPの下の層でfragmentionと再アセンブリ適合層を提供しなければなりません。 そのような層は以下でセクション5で定義されます。

   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.

その上、長い間IPv6ヘッダーが40の八重奏であるので、これはUDPのような上側の層のプロトコルに41の八重奏だけを残します。 後者はアプリケーションのための33の八重奏だけをデータに残すヘッダーの8つの八重奏を使用します。 さらに、断片化と再アセンブリ層の必要が上で指摘されるようにあります。(それは、さらに多くの八重奏を使用するでしょう)。

   The above considerations lead to the following two observations:

上の問題は以下の2つの観測につながります:

   1.  The adaptation layer must be provided to comply with the IPv6
       requirements of a 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
       the 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.

1. 最小のMTUのIPv6要件に従うために適合層を提供しなければなりません。 しかしながら、(a) IEEE802.15.4のほとんどのアプリケーションがそのような大きいパケットを使用しないで、(b) 適切なヘッダー圧縮に関連したわずかなアプリケーションペイロードが単一のIEEE802.15.4フレームの中に合うパケットを作り出すと予想されます。 この適合層のための正当化はIPv6コンプライアンスだけのためのものではありません、あるアプリケーション交換(例えば、構成か食糧を供給する)で生産されたパケットサイズが少ない数の断片をかなり必要としそうなとき。

   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

2. 上の宇宙計算は最悪の事態のシナリオを示していますが、それはヘッダー圧縮がほとんど避けられなくなるまで無視できないという事実を指摘します。 私たち以来

Montenegro, et al.          Standards Track                     [Page 5]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[5ページ]RFC4944IPv6

       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 10.

.4が望んでいるIEEE802.15の上のIPのほとんどの(すべて)アプリケーションがヘッダー圧縮を利用して、それが以下でセクション10で定義されると予想してください。

5.  LoWPAN Adaptation Layer and Frame Format

5. LoWPAN適合層とフレーム形式

   The encapsulation formats defined in this section (subsequently
   referred to as the "LoWPAN encapsulation") are the payload in the
   IEEE 802.15.4 MAC protocol data unit (PDU).  The LoWPAN payload
   (e.g., an IPv6 packet) follows this encapsulation header.

このセクション(次に、「LoWPANカプセル化」と呼ばれる)で定義されたカプセル化書式はIEEE802.15.4MACプロトコルデータ単位(PDU)のペイロードです。 LoWPANペイロード(例えば、IPv6パケット)はこのカプセル化ヘッダーに続きます。

   All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are
   prefixed by an encapsulation header stack.  Each header in the header
   stack contains a header type followed by zero or more header fields.
   Whereas in an IPv6 header the stack would contain, in the following
   order, addressing, hop-by-hop options, routing, fragmentation,
   destination options, and finally payload [RFC2460]; in a LoWPAN
   header, the analogous header sequence is mesh (L2) addressing, hop-
   by-hop options (including L2 broadcast/multicast), fragmentation, and
   finally payload.  These examples show typical header stacks that may
   be used in a LoWPAN network.

輸送されて、すべてのLoWPANがデータグラムを要約しました。IEEE802.15の上では、.4はカプセル化ヘッダースタックによって前に置かれています。 ヘッダースタックの各ヘッダーはタイプがゼロでついて来たか、または、より多くのヘッダーがさばくヘッダーを含んでいます。 スタックが含むIPv6ヘッダー、以下のオーダーのアドレシング、ホップごとのオプション、ルーティング、断片化、目的地オプション、および最終的にペイロード[RFC2460]。 LoWPANヘッダーでは、類似のヘッダー系列は、メッシュ(L2)アドレシングと、ホップによるホップオプション(L2放送/マルチキャストを含んでいる)と、断片化と、最終的にペイロードです。 これらの例はLoWPANネットワークに使用されるかもしれない典型的なヘッダースタックを示しています。

   A LoWPAN encapsulated IPv6 datagram:

LoWPANはIPv6データグラムを要約しました:

      +---------------+-------------+---------+
      | IPv6 Dispatch | IPv6 Header | Payload |
      +---------------+-------------+---------+

+---------------+-------------+---------+ | IPv6発信| IPv6ヘッダー| 有効搭載量| +---------------+-------------+---------+

   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:

LoWPANはLOWPANを要約しました。_HC1はIPv6データグラムを圧縮しました:

      +--------------+------------+---------+
      | HC1 Dispatch | HC1 Header | Payload |
      +--------------+------------+---------+

+--------------+------------+---------+ | HC1発信| HC1ヘッダー| 有効搭載量| +--------------+------------+---------+

   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
   requires mesh addressing:

LoWPANはLOWPANを要約しました。_HC1は記述しながらメッシュを必要とするIPv6データグラムを圧縮しました:

      +-----------+-------------+--------------+------------+---------+
      | Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
      +-----------+-------------+--------------+------------+---------+

+-----------+-------------+--------------+------------+---------+ | メッシュタイプ| メッシュヘッダー| HC1発信| HC1ヘッダー| 有効搭載量| +-----------+-------------+--------------+------------+---------+

   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
   requires fragmentation:

LoWPANはLOWPANを要約しました。_HC1は断片化を必要とするIPv6データグラムを圧縮しました:

      +-----------+-------------+--------------+------------+---------+
      | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
      +-----------+-------------+--------------+------------+---------+

+-----------+-------------+--------------+------------+---------+ | タイプを破片手榴弾で殺傷してください。| ヘッダーを破片手榴弾で殺傷してください。| HC1発信| HC1ヘッダー| 有効搭載量| +-----------+-------------+--------------+------------+---------+

Montenegro, et al.          Standards Track                     [Page 6]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[6ページ]RFC4944IPv6

   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
   requires both mesh addressing and fragmentation:

LoWPANはLOWPANを要約しました。_HC1はメッシュアドレシングと断片化の両方を必要とするIPv6データグラムを圧縮しました:

      +-------+-------+-------+-------+---------+---------+---------+
      | M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
      +-------+-------+-------+-------+---------+---------+---------+

+-------+-------+-------+-------+---------+---------+---------+ | M Typ| M Hdr| F Typ| F Hdr| HC1 Dsp| HC1 Hdr| 有効搭載量| +-------+-------+-------+-------+---------+---------+---------+

   A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
   requires both mesh addressing and a broadcast header to support mesh
   broadcast/multicast:

LoWPANはLOWPANを要約しました。_HC1はメッシュアドレシングと放送ヘッダーの両方がメッシュ放送/マルチキャストを支持するのを必要とするIPv6データグラムを圧縮しました:

      +-------+-------+-------+-------+---------+---------+---------+
      | M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
      +-------+-------+-------+-------+---------+---------+---------+

+-------+-------+-------+-------+---------+---------+---------+ | M Typ| M Hdr| B Dsp| B Hdr| HC1 Dsp| HC1 Hdr| 有効搭載量| +-------+-------+-------+-------+---------+---------+---------+

   When more than one LoWPAN header is used in the same packet, they
   MUST appear in the following order:

1個以上のLoWPANヘッダーが同じパケットで使用されるとき、彼らは以下のオーダーに現れなければなりません:

      Mesh Addressing Header

ヘッダーに演説して、かみ合ってください。

      Broadcast Header

放送ヘッダー

      Fragmentation Header

断片化ヘッダー

   All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc.)
   SHALL be preceded by one of the valid LoWPAN encapsulation headers,
   examples of which are given above.  This permits uniform software
   treatment of datagrams without regard to the mode of their
   transmission.

すべてのプロトコルデータグラム(例えば、IPv6、圧縮されたIPv6ヘッダーなど) SHALL、有効なLoWPANカプセル化ヘッダーのひとりによって先行されてください。その例は上に出されます。 これは関係なしでデータグラムの一定のソフトウェア処理を彼らのトランスミッションの方法に可能にします。

   The definition of LoWPAN headers, other than mesh addressing and
   fragmentation, consists of the dispatch value, the definition of the
   header fields that follow, and their ordering constraints relative to
   all other headers.  Although the header stack structure provides a
   mechanism to address future demands on the LoWPAN adaptation layer,
   it is not intended to provided general purpose extensibility.  This
   format document specifies a small set of header types using the
   header stack for clarity, compactness, and orthogonality.

メッシュアドレシングと断片化を除いて、発信値と、続くヘッダーフィールドの定義と、他のすべてのヘッダーに比例して規制を注文するのからLoWPANヘッダーの定義は成ります。 ヘッダースタック構造はLoWPAN適合層に今後の要求を記述するためにメカニズムを提供しますが、それは提供された汎用の伸展性に意図しません。 この形式ドキュメントは、明快、コンパクト性、および直交性にヘッダースタックを使用することで小さいヘッダータイプを指定します。

Montenegro, et al.          Standards Track                     [Page 7]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[7ページ]RFC4944IPv6

5.1.  Dispatch Type and Header

5.1. 発信タイプとヘッダー

   The dispatch type is defined by a zero bit as the first bit and a one
   bit as the second bit.  The dispatch type and header are shown here:

発信タイプは2番目のビットとしてゼロ・ビットによって最初のビットと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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 1| Dispatch  |  type-specific header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| 発信| タイプ特有のヘッダー+++++++++++++++++++++++++++++++++

   Dispatch               6-bit selector.  Identifies the type of header
                          immediately following the Dispatch Header.

6ビットのセレクタを派遣してください。 すぐにDispatch Headerに続いて、ヘッダーのタイプを特定します。

   type-specific header   A header determined by the Dispatch Header.

Dispatch Headerで断固としたタイプ特有のヘッダーAヘッダー。

                    Figure 1: Dispatch Type and Header

図1: 発信タイプとヘッダー

   The dispatch value may be treated as an unstructured namespace.  Only
   a few symbols are required to represent current LoWPAN functionality.
   Although some additional savings could be achieved by encoding
   additional functionality into the dispatch byte, these measures would
   tend to constrain the ability to address future alternatives.

発信値は不統一な名前空間として扱われるかもしれません。 ほんのいくつかのシンボルが、現在のLoWPANの機能性を表すのに必要です。 発信バイトに追加機能性をコード化することによって、いくつかの追加貯蓄を達成できるでしょうが、これらの測定は、将来の代替手段を記述する能力を抑制する傾向があるでしょう。

Montenegro, et al.          Standards Track                     [Page 8]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[8ページ]RFC4944IPv6

           Pattern    Header Type
         +------------+-----------------------------------------------+
         | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
         | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
         | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
         | 01  000011 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  001111 | reserved   - Reserved for future use          |
         | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |
         | 01  010001 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 01  111110 | reserved   - Reserved for future use          |
         | 01  111111 | ESC        - Additional Dispatch byte follows |
         | 10  xxxxxx | MESH       - Mesh Header                      |
         | 11  000xxx | FRAG1      - Fragmentation Header (first)     |
         | 11  001000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  011111 | reserved   - Reserved for future use          |
         | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
         | 11  101000 | reserved   - Reserved for future use          |
         |   ...      | reserved   - Reserved for future use          |
         | 11  111111 | reserved   - Reserved for future use          |
         +------------+-----------------------------------------------+

パターンヘッダータイプ+------------+-----------------------------------------------+ | 00 xxxxxx| NALP--LoWPANフレームでない| | 01 000001 | IPv6--解凍されたIPv6アドレス| | 01 000010 | LOWPAN_HC1--LOWPAN_HC1はIPv6を圧縮しました。| | 01 000011 | 今後の使用のために予約されて、予約されます。| | ... | 今後の使用のために予約されて、予約されます。| | 01 001111 | 今後の使用のために予約されて、予約されます。| | 01 010000 | LOWPAN_BC0--LOWPAN_BC0は放送します。| | 01 010001 | 今後の使用のために予約されて、予約されます。| | ... | 今後の使用のために予約されて、予約されます。| | 01 111110 | 今後の使用のために予約されて、予約されます。| | 01 111111 | ESC--追加Dispatchバイトは続きます。| | 10 xxxxxx| かみ合ってください--メッシュヘッダー| | 11 000xxx| FRAG1--断片化ヘッダー(1番目)| | 11 001000 | 今後の使用のために予約されて、予約されます。| | ... | 今後の使用のために予約されて、予約されます。| | 11 011111 | 今後の使用のために予約されて、予約されます。| | 11 100xxx| FRAGN--断片化ヘッダー(その後の)| | 11 101000 | 今後の使用のために予約されて、予約されます。| | ... | 今後の使用のために予約されて、予約されます。| | 11 111111 | 今後の使用のために予約されて、予約されます。| +------------+-----------------------------------------------+

                   Figure 2: Dispatch Value Bit Pattern

図2: 発信値のビット・パターン

   NALP:  Specifies that the following bits are not a part of the LoWPAN
      encapsulation, and any LoWPAN node that encounters a dispatch
      value of 00xxxxxx shall discard the packet.  Other non-LoWPAN
      protocols that wish to coexist with LoWPAN nodes should include a
      byte matching this pattern immediately following the 802.15.4.
      header.

NALP: 以下のビットがLoWPANカプセル化の一部でなく、00xxxxxxの発信値に遭遇するどんなLoWPANノードもパケットを捨てるだろうと指定します。 802.15.4ヘッダーに続いて、LoWPANノードと共存したがっている他の非LoWPANプロトコルはすぐにこのパターンに合っている1バイトを含むべきです。

   IPv6:  Specifies that the following header is an uncompressed IPv6
      header [RFC2460].

IPv6: 以下のヘッダーが解凍されたIPv6ヘッダー[RFC2460]であると指定します。

   LOWPAN_HC1:  Specifies that the following header is a LOWPAN_HC1
      compressed IPv6 header.  This header format is defined in
      Figure 9.

LOWPAN_HC1: 以下のヘッダーがLOWPAN_HC1がIPv6ヘッダーを圧縮したということであると指定します。 このヘッダー形式は図9で定義されます。

   LOWPAN_BC0:  Specifies that the following header is a LOWPAN_BC0
      header for mesh broadcast/multicast support and is described in
      Section 11.1.

LOWPAN_BC0: 以下のヘッダーがメッシュ放送/マルチキャストサポートのためのLOWPAN_BC0ヘッダーであると指定して、セクション11.1で説明されます。

   ESC:  Specifies that the following header is a single 8-bit field for
      the Dispatch value.  It allows support for Dispatch values larger
      than 127.

ESC: 以下のヘッダーがDispatch値のためのただ一つの8ビットの分野であると指定します。 それは127より大きいDispatch値のサポートを許します。

Montenegro, et al.          Standards Track                     [Page 9]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[9ページ]RFC4944IPv6

5.2.  Mesh Addressing Type and Header

5.2. タイプとヘッダーに演説して、かみ合ってください。

   The mesh type is defined by a one bit and zero bit as the first two
   bits.  The mesh type and header are shown here:

メッシュタイプは1ビットとゼロ・ビットによって最初の2ビットと定義されます。 メッシュタイプとヘッダーはここに示されます:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 0|V|F|HopsLft| originator address, final address
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0|V|F|HopsLft| 創始者アドレス、最終アドレス+++++++++++++++++++++++++++++++++

                 Figure 3: Mesh Addressing Type and Header

図3: タイプとヘッダーに演説して、かみ合ってください。

   Field definitions are as follows:

フィールド定義は以下の通りです:

   V: This 1-bit field SHALL be zero if the Originator (or "Very first")
      Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is
      a short 16-bit addresses.

V: それがさばくなら、この1ビットはゼロがOriginator(または、「まさしくその1番目」)アドレスがIEEEの拡張64ビットのアドレス(EUI-64)であるか、そして、1であったならSHALLをさばきます。短い16ビット・アドレス。

   F: This 1-bit field SHALL be zero if the Final Destination Address is
      an IEEE extended 64-bit address (EUI-64), or 1 if it is a short
      16-bit addresses.

F: この1ビットはSHALLをさばきます。それが短い16ビット・アドレスであるならファイナル・デスティネーションAddressがIEEE拡張64ビットのアドレス(EUI-64)、または1であるなら、ゼロになってください。

   Hops Left:  This 4-bit field SHALL be decremented by each forwarding
      node before sending this packet towards its next hop.  The packet
      is not forwarded any further if Hops Left is decremented to zero.
      The value 0xF is reserved and signifies an 8-bit Deep Hops Left
      field immediately following, and allows a source node to specify a
      hop limit greater than 14 hops.

ホップスはいなくなりました: この4ビットは発信する前の減少したそれぞれ進めているノードが次のホップに向かったこのパケットであったならSHALLをさばきます。 ホップスLeftがゼロまで減少するなら、パケットはこれ以上進められません。 値の0xFは、予約されていて、すぐに続いて、8ビットのDeepホップスLeft分野を意味して、ソースノードが14のホップより大きいホップ限界を指定するのを許容します。

   Originator Address:  This is the link-layer address of the
      Originator.

創始者アドレス: これはOriginatorのリンクレイヤアドレスです。

   Final Destination Address:  This is the link-layer address of the
      Final Destination.

ファイナル・デスティネーションアドレス: これはファイナル・デスティネーションのリンクレイヤアドレスです。

   Note that the 'V' and 'F' bits allow for a mix of 16 and 64-bit
   addresses.  This is useful at least to allow for mesh layer
   "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit
   short addresses.

ビットが16と64ビットのアドレスのミックスのために許容するその'V'と'F'に注意してください。 これは少なくともメッシュ層の「放送」を考慮するために役に立ちます、.4放送が記述する802.15が16ビットの短いアドレスと定義されるとき。

   A further discussion of frame delivery within a mesh is in
   Section 11.

メッシュの中のフレーム配送のさらなる議論がセクション11にあります。

Montenegro, et al.          Standards Track                    [Page 10]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[10ページ]RFC4944IPv6

5.3.  Fragmentation Type and Header

5.3. 断片化タイプとヘッダー

   If an entire payload (e.g., IPv6) datagram fits within a single
   802.15.4 frame, it is unfragmented and the LoWPAN encapsulation
   should not contain a fragmentation header.  If the datagram does not
   fit within a single IEEE 802.15.4 frame, it SHALL be broken into link
   fragments.  As the fragment offset can only express multiples of
   eight bytes, all link fragments for a datagram except the last one
   MUST be multiples of eight bytes in length.  The first link fragment
   SHALL contain the first fragment header as defined below.

全体のペイロード(例えば、IPv6)データグラムが単一の802.15.4フレームの中に合うなら、それは非断片化されます、そして、LoWPANカプセル化は断片化ヘッダーを含むべきではありません。 データグラムは単一のIEEE802.15.4フレームの中に合わないで、それはSHALLです。リンク断片に壊れてください。 断片オフセットが8バイトの倍数を言い表すことができるだけであるので、最後のもの以外のデータグラムのためのすべてのリンク断片が長さが8バイトの倍数であるに違いありません。 最初のリンク断片SHALLは以下で定義されるように最初の断片ヘッダーを含んでいます。

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0 0| データグラム_サイズ| データグラム_タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: First Fragment

図4: 最初の断片

   The second and subsequent link fragments (up to and including the
   last) SHALL contain a fragmentation header that conforms to the
   format shown below.

2番目の、そして、その後のリンク断片(最終を含めた)SHALLは以下に示された書式に従う断片化ヘッダーを含んでいます。

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
      +-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0 0| データグラム_サイズ| データグラム_タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |データグラム_オフセット| +-+-+-+-+-+-+-+-+

                      Figure 5: Subsequent Fragments

図5: その後の断片

   datagram_size:  This 11-bit field encodes the size of the entire IP
      packet before link-layer fragmentation (but after IP layer
      fragmentation).  The value of datagram_size SHALL be the same for
      all link-layer fragments of an IP packet.  For IPv6, this SHALL be
      40 octets (the size of the uncompressed IPv6 header) more than the
      value of Payload Length in the IPv6 header [RFC2460] of the
      packet.  Note that this packet may already be fragmented by hosts
      involved in the communication, i.e., this field needs to encode a
      maximum length of 1280 octets (the IEEE 802.15.4 link MTU, as
      defined in this document).

データグラム_サイズ: この11ビットの分野はリンクレイヤ断片化(しかしIP層の断片化の後に)の前に全体のIPパケットのサイズをコード化します。 値、データグラム_サイズSHALLにおいて、IPパケットのすべてのリンクレイヤ断片のための同じくらいはそうです。 IPv6、このSHALL、パケットのIPv6ヘッダー[RFC2460]の有効搭載量Lengthの値よりさらに40の八重奏(解凍されたIPv6ヘッダーのサイズ)になってください。 このパケットがコミュニケーションにかかわるホストによって既に断片化されるかもしれなくて、すなわち、この分野が、1280の八重奏の最大の長さをコード化する必要に注意してください(IEEE802.15.4はMTUをリンクします、本書では定義されるように)。

      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

以下に注意してください。 この分野はあらゆるパケットにある必要はありません、人が最初の断片でそれを送って、次にそれを削除できたとき。 しかしながら、2分の1と(その後)であるなら断片が再アセンブリにタスクを緩和するあらゆるリンクにそれを含んでいて、リンクしてください。

Montenegro, et al.          Standards Track                    [Page 11]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[11ページ]RFC4944IPv6

      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.

断片は1日以前、届きます。 この場合、断片の残りを待つとき、断片のどれかが届くとすぐに、データグラム_サイズについて知る保証は、どのくらいのバッファ領域をかたわらに置くかを受信機に言います。 効率のための簡単さでの取り引きを超えた形式。

   datagram_tag:  The value of datagram_tag (datagram tag) SHALL be the
      same for all link fragments of a payload (e.g., IPv6) datagram.
      The sender SHALL increment datagram_tag for successive, fragmented
      datagrams.  The incremented value of datagram_tag SHALL wrap from
      65535 back to zero.  This field is 16 bits long, and its initial
      value is not defined.

データグラム_タグ: データグラム_の値はすべてのリンクと同じくらいがペイロード(例えば、IPv6)データグラムの断片であったなら(データグラムタグ)SHALLにタグ付けをします。 送付者SHALLは連続して、断片化しているデータグラムデータグラム_タグSHALL包装の増加している値のためにデータグラム_タグを65535〜ゼロまで増加します。 この分野は長さ16ビットです、そして、初期の値は定義されません。

   datagram_offset:  This field is present only in the second and
      subsequent link fragments and SHALL specify the offset, in
      increments of 8 octets, of the fragment from the beginning of the
      payload datagram.  The first octet of the datagram (e.g., the
      start of the IPv6 header) has an offset of zero; the implicit
      value of datagram_offset in the first link fragment is zero.  This
      field is 8 bits long.

データグラム_は相殺されました: この分野は2番目の、そして、その後のリンク断片だけに存在しています、そして、SHALLはオフセットを指定します、ペイロードデータグラムの始まりからの8つの八重奏、断片の増分で。 データグラム(例えば、IPv6ヘッダーの始まり)の最初の八重奏には、ゼロのオフセットがあります。 最初のリンク断片で相殺されたデータグラム_の暗黙の値はゼロです。 この分野は長さ8ビットです。

   The recipient of link fragments SHALL use (1) the sender's 802.15.4
   source address (or the Originator Address if a Mesh Addressing field
   is present), (2) the destination's 802.15.4 address (or the Final
   Destination address if a Mesh Addressing field is present), (3)
   datagram_size, and (4) datagram_tag to identify all the link
   fragments that belong to a given datagram.

または、リンク断片SHALLの受取人が(1) 送付者の802.15.4ソースアドレスを使用する、(Originator Address、Mesh Addressing分野が存在している、)、(2) .4が扱う目的地の802.15、(Mesh Addressing分野が存在しているならファイナル・デスティネーションが扱う、)、(4) 与えられたデータグラムに属すすべてのリンク断片を特定する(3) データグラム_サイズ、およびデータグラム_タグ。

   Upon receipt of a link fragment, the recipient starts constructing
   the original unfragmented packet whose size is datagram_size.  It
   uses the datagram_offset field to determine the location of the
   individual fragments within the original unfragmented packet.  For
   example, it may place the data payload (except the encapsulation
   header) within a payload datagram reassembly buffer at the location
   specified by datagram_offset.  The size of the reassembly buffer
   SHALL be determined from datagram_size.

リンク断片を受け取り次第、受取人はサイズがデータグラム_サイズであるオリジナルの非断片化しているパケットを組み立て始めます。 それは、オリジナルの非断片化しているパケットの中で個々の断片の位置を決定するのにデータグラム_オフセット分野を使用します。 例えば、それはデータグラム_オフセットで指定された位置のペイロードデータグラム再アセンブリバッファの中にデータペイロード(カプセル化ヘッダーを除いた)を置くかもしれません。 再アセンブリのサイズはSHALLをバッファリングします。データグラム_サイズから、断固としてください。

   If a link fragment that overlaps another fragment is received, as
   identified above, and differs in either the size or datagram_offset
   of the overlapped fragment, 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 datagram_offset from the
   encapsulation header and "Frame Length" from the 802.15.4 Physical
   Layer Protocol Data Unit (PPDU) packet header.

別の断片を重ね合わせるリンク断片が上で特定されるように受け取られていて、異なるなら、サイズか重ね合わせられた断片のデータグラム_オフセット、再アセンブリバッファSHALLに既に蓄積された断片のどちらかでは捨てられてください。 新鮮な再アセンブリは最も最近容認されたリンク断片で始められるかもしれません。 断片オーバラップはカプセル化ヘッダーと「フレームの長さ」から802.15.4Physical LayerプロトコルData Unit(PPDU)パケットのヘッダーから相殺されたデータグラム_の組み合わせで決定します。

   Upon detection of a IEEE 802.15.4 Disassociation event, fragment
   recipients MUST discard all link fragments of all partially

IEEE802.15.4Disassociationイベントの検出のときに、断片受取人はすべてのすべてのリンク断片を部分的に捨てなければなりません。

Montenegro, et al.          Standards Track                    [Page 12]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[12ページ]RFC4944IPv6

   reassembled payload datagrams, and fragment senders MUST discard all
   not yet transmitted link fragments of all partially transmitted
   payload (e.g., IPv6) datagrams.  Similarly, when a node first
   receives a fragment with a given datagram_tag, it starts a reassembly
   timer.  When this time expires, if the entire packet has not been
   reassembled, the existing fragments MUST be discarded and the
   reassembly state MUST be flushed.  The reassembly timeout MUST be set
   to a maximum of 60 seconds (this is also the timeout in the IPv6
   reassembly procedure [RFC2460]).

組み立て直されたペイロードデータグラム、および断片送付者は始動しなければなりません。すべての部分的に伝えられたペイロード(例えば、IPv6)データグラムのすべてのまだ伝えられるというわけではないリンク断片を捨ててください。ノードが最初に与えられたデータグラム_タグで断片を受けるとき、同様に、それは再アセンブリタイマを始動します。 全体のパケットが組み立て直されていないなら今回が期限が切れるとき、既存の断片を捨てなければなりません、そして、再アセンブリ状態を洗い流さなければなりません。 最大60秒に再アセンブリタイムアウトを設定しなければなりません(また、これはIPv6 reassembly手順[RFC2460]においてタイムアウトです)。

6.  Stateless Address Autoconfiguration

6. 状態がないアドレス自動構成

   This section defines how to obtain an IPv6 interface identifier.

このセクションはIPv6インタフェース識別子を得る方法を定義します。

   The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may
   be based on the EUI-64 identifier [EUI64] assigned to the IEEE
   802.15.4 device.  In this case, the Interface Identifier is formed
   from the EUI-64 according to the "IPv6 over Ethernet" specification
   [RFC2464].

IEEE802.15.4インタフェースへのInterface Identifier[RFC4291]はIEEE802.15.4デバイスに割り当てられたEUI-64識別子[EUI64]に基づくかもしれません。 この場合、Interface Identifierは「イーサネットの上のIPv6」仕様[RFC2464]通りにEUI-64から形成されます。

   All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
   addresses (Section 3 and Section 12) are also possible.  In these
   cases, a "pseudo 48-bit address" is formed as follows.  First, the
   left-most 32 bits are formed by concatenating 16 zero bits to the 16-
   bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
   used).  This produces a 32-bit field as follows:

すべての802.15台の.4デバイスには、IEEE EUI-64アドレスがありますが、また、16ビットの短いアドレス(セクション3とセクション12)も可能です。 これらの場合では、「疑似48ビットのアドレス」は以下の通り形成されます。 まず最初に、最も左の32ビットは、16ビットPAN IDに16ゼロ・ビットを連結することによって、形成されます(あるいはまた、PAN IDが全く知られていないなら、16ゼロ・ビットが使用されるかもしれません)。 これは以下の32ビットの分野を生産します:

      16_bit_PAN:16_zero_bits

16_ビット_なべ: 16_ゼロ_ビット

   Then, these 32 bits are concatenated with the 16-bit short address.
   This produces a 48-bit address as follows:

そして、これらの32ビットは16ビットの短いアドレスで連結されます。 これは以下の48ビットのアドレスを製作します:

      32_bits_as_specified_previously:16_bit_short_address

_としての_が_以前に指定した32_ビット: 16_は_短い_アドレスに噛み付きました。

   The interface identifier is formed from this 48-bit address as per
   the "IPv6 over Ethernet" specification [RFC2464].  However, in the
   resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
   be set to zero in keeping with the fact that this is not a globally
   unique value.  For either address format, all zero addresses MUST NOT
   be used.

インタフェース識別子は「イーサネットの上のIPv6」仕様[RFC2464]に従ってこの48ビットのアドレスから形成されます。 結果のインタフェース識別子の「普遍的であるか地方」の(U/L)がどのようにSHALLに噛み付いたとしても、これがグローバルにユニークな値でないという事実で保つ際にゼロに設定されてください。 どちらのアドレス形式のためにも、ゼロが扱うすべてを使用してはいけません。

   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.

手動かソフトウェアによって設定された異なったMACアドレスは、Interface Identifierを引き出すのに使用されるかもしれません。 そのようなMACアドレスが使用されているなら、グローバルなユニークさの特性はU/Lビットの価値に反映されるべきです。

   An IPv6 address prefix used for stateless autoconfiguration [RFC4862]
   of an IEEE 802.15.4 interface MUST have a length of 64 bits.

IEEE802.15.4インタフェースの状態がない自動構成[RFC4862]に使用されるIPv6アドレス接頭語は64ビットの長さを持たなければなりません。

Montenegro, et al.          Standards Track                    [Page 13]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[13ページ]RFC4944IPv6

7.  IPv6 Link Local Address

7. IPv6リンクローカルアドレス

   The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface
   is formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

IEEE802.15.4インタフェースへのIPv6リンクローカルアドレス[RFC4291]はInterface Identifierを追加することによって、形成されます、上で定義されるように、接頭語FE80に:、:/64.

          10 bits            54 bits                  64 bits
       +----------+-----------------------+----------------------------+
       |1111111010|         (zeros)       |    Interface Identifier    |
       +----------+-----------------------+----------------------------+

10ビット54ビット64ビット+----------+-----------------------+----------------------------+ |1111111010| (ゼロ) | インタフェース識別子| +----------+-----------------------+----------------------------+

                                 Figure 6

図6

8.  Unicast Address Mapping

8. ユニキャストアドレス・マッピング

   The address resolution procedure for mapping IPv6 non-multicast
   addresses into IEEE 802.15.4 link-layer addresses follows the general
   description in Section 7.2 of [RFC4861], unless otherwise specified.

IEEE802.15.4のリンクレイヤアドレスにIPv6非マルチキャストアドレスを写像するためのアドレス解決手順は[RFC4861]のセクション7.2で概説に続きます、別の方法で指定されない場合。

   The Source/Target Link-layer Address option has the following forms
   when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or
   16-bit short addresses, respectively.

そして、リンクレイヤがIEEEであるときにSource/目標Link-層のAddressオプションには以下のフォームがある、802.15、.4、アドレスは、それぞれEUI-64か16ビットの短いアドレスです。

Montenegro, et al.          Standards Track                    [Page 14]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[14ページ]RFC4944IPv6

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |     Type      |    Length=2   |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                               |
                      +-        IEEE 802.15.4        -+
                      |          EUI-64               |
                      +-                             -+
                      |                               |
                      +-         Address             -+
                      |                               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                               |
                      +-         Padding             -+
                      |                               |
                      +-        (all zeros)          -+
                      |                               |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ=2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +IEEE802.15.4-+| EUI-64| +- -+ | | + アドレス-+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + -+を水増しすること。| | +(すべてのゼロ) -+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |     Type      |    Length=1   |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |     16-bit short Address      |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |                               |
                      +-         Padding             -+
                      |         (all zeros)           |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ=1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16ビットの短いAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + -+を水増しすること。| (すべてのゼロ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 7

図7

   Option fields:

オプション・フィールド:

   Type:

以下をタイプしてください。

      1: for Source Link-layer address.

1: Source Link-層のアドレスのために。

      2: for Target Link-layer address.

2: Target Link-層のアドレスのために。

   Length:  This is the length of this option (including the type and
      length fields) in units of 8 octets.  The value of this field is 2
      if using EUI-64 addresses, or 1 if using 16-bit short addresses.

長さ: これは8つの八重奏のユニットのこのオプション(タイプと長さの分野を含んでいる)の長さです。 16ビットの短いアドレスを使用するならEUI-64アドレス、または1を使用するなら、この分野の値は2です。

   IEEE 802.15.4 Address:  The 64-bit IEEE 802.15.4 address, or the 16-
      bit short address (as per the format in Section 9), in canonical

IEEE802.15.4アドレス: 64ビットのIEEE802.15.4アドレス、または正準の16ビット少ないアドレス(セクション9における形式に従って)

Montenegro, et al.          Standards Track                    [Page 15]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[15ページ]RFC4944IPv6

      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.

オーダーに噛み付きました。 これはインタフェースが現在応じるアドレスです。 このアドレスはInterface Identifierを引き出すのに使用される内蔵のアドレスと異なるかもしれません、プライバシーかセキュリティ(例えば、隣人発見の)問題のために。

9.  Multicast Address Mapping

9. マルチキャストアドレス・マッピング

   The functionality in this section MUST only be used in a mesh-enabled
   LoWPAN.  An IPv6 packet with a multicast destination address (DST),
   consisting of the sixteen octets DST[1] through DST[16], is
   transmitted to the following 802.15.4 16-bit multicast address:

メッシュで可能にされたLoWPANでこのセクションの機能性を使用するだけでよいです。 DST[16]を通して16八重奏DST[1]から成って、マルチキャスト送付先アドレス(DST)があるIPv6パケットは以下の802.15.4 16ビットマルチキャストアドレスに伝えられます:

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |1 0 0|DST[15]* |   DST[16]     |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0|DST[15]*| DST[16]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 8

エイト環

   Here, DST[15]* refers to the last 5 bits in octet DST[15], that is,
   bits 3-7 within DST[15].  The initial 3-bit pattern of "100" follows
   the 16-bit address format for multicast addresses (Section 12).

ここと、DST[15]*は八重奏DST[15]における最後の5ビット、すなわち、DST[15]の中のビット3-7を呼びます。 「100」の初期の3ビットのパターンはマルチキャストアドレス(セクション12)のための16ビットのアドレス形式に続きます。

   This allows for multicast support within 6LoWPAN networks, but the
   full specification of such support is out of the scope of this
   document.  Example mechanisms are: flooding, controlled flooding,
   unicasting to the PAN coordinator, etc.  It is expected that this
   would be specified by the different mesh routing mechanisms.

これは6LoWPANネットワークの中でマルチキャストサポートを考慮しますが、このドキュメントの範囲の外にそのようなサポートの完全な仕様があります。 例のメカニズムは以下の通りです。 氾濫、制御氾濫、PANコーディネータにunicastingすることなど。 これが異なったメッシュルーティングメカニズムによって指定されると予想されます。

10.  Header Compression

10. ヘッダー圧縮

   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:

ヘッダー圧縮に対するたくさん発行されて、進行中の標準化仕事があります。 それにもかかわらず、ヘッダー圧縮、IEEE802.15の上のIPv6に関しては、.4は以下の通り異なった規制をまとめさせます:

      Existing work assumes that there are many flows between any two
      devices.  Here, we assume a very simple and low-context flavor of
      header compression.  Whereas this works independently of flows
      (potentially several), it does not use any context specific to any
      flow.  Thus, it cannot achieve as much compression as schemes that
      build a separate context for each flow to be compressed.

既存の仕事は、どんな2台のデバイスの間にはも、多くの流れがあると仮定します。 ここで、私たちはヘッダー圧縮の非常に簡単で少ない関係の風味を仮定します。 これは流れ(潜在的に数個の)の如何にかかわらず働いていますが、それはどんな流れにも特定のどんな文脈も使用しません。 したがって、それは各流れが圧縮されるために別々の関係を築き上げる計画するのと同じくらい多くの圧縮を達成できません。

      Given the very limited packet sizes, it is highly desirable to
      integrate layer 2 with layer 3 compression, something
      traditionally not done (although now changing due to the ROHC
      (RObust Header Compression) working group).

非常に限られたパケットサイズを考えて、層2を層と統合するのは非常に望ましいです。3圧縮伝統的に(何かされなかった(現在、ROHC(RObust Header Compression)ワーキンググループのため変化しますが)もの)。

Montenegro, et al.          Standards Track                    [Page 16]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[16ページ]RFC4944IPv6

      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.

IEEE802.15.4台のデバイスがマルチホップネットワークで配布されると予想されます。 しかしながら、メッシュでのヘッダー圧縮はコンプレッサーと減圧装置が互いとのダイレクトで排他的なコミュニケーションにある普通のポイントツーポイント接続シナリオから出発します。 IEEE802.15.4ネットワークでは、デバイスが隣人のどれかを通して圧縮されたパケットをヘッダーに送ることができるのは、非常に望ましいです、できるだけ小さい予備の文脈ビルで。

   Any new packet formats required by header compression reuse the basic
   packet formats defined in Section 5 by using different dispatch
   values.

どんな新しいパケット・フォーマットも基本的なパケット・フォーマットがセクション5で異なった発信値を使用することによって定義したヘッダー圧縮再利用で必要です。

   Header compression may result in alignment not falling on an octet
   boundary.  Since hardware typically cannot transmit data in units
   less than an octet, padding must be used.  Padding is done as
   follows: First, the entire series of contiguous compressed headers is
   laid out (this document only defines IPv6 and UDP header compression
   schemes, but others may be defined elsewhere).  Then, zero bits
   SHOULD be added as appropriate to align to an octet boundary.  This
   counteracts any potential misalignment caused by header compression,
   so subsequent fields (e.g., non-compressed headers or data payloads)
   start on an octet boundary and follow as usual.

ヘッダー圧縮は八重奏境界の責任とならない整列をもたらすかもしれません。 ハードウェアが八重奏よりユニットのデータを通常送らないことができないので、詰め物を使用しなければなりません。 詰め物は以下の通り完了しています: まず最初に、隣接の圧縮されたヘッダーのシリーズもの全巻は広げられます(このドキュメントがIPv6とUDPヘッダー圧縮技術を定義するだけですが、他のものはほかの場所で定義されるかもしれません)。 次に、ビットSHOULDのゼロを合わせてください。八重奏境界に並ぶために適宜加えられてください。 これがヘッダー圧縮で引き起こされたどんな潜在的調整不良も打ち消すので、その後の野原(例えば、非圧縮されたヘッダーかデータペイロード)は、八重奏境界を始めて、いつものように続きます。

10.1.  Encoding of IPv6 Header Fields

10.1. IPv6ヘッダーフィールドのコード化

   By virtue of having joined the same 6LoWPAN network, devices share
   some state.  This makes it possible to compress headers without
   explicitly building any compression context state.  Therefore,
   6LoWPAN header compression does not keep any flow state; instead, it
   relies on information pertaining to the entire link.  The following
   IPv6 header values are expected to be common on 6LoWPAN networks, so
   the HC1 header has been constructed to efficiently compress them from
   the onset: Version is IPv6; both IPv6 source and destination
   addresses are link local; the IPv6 interface identifiers (bottom 64
   bits) for the source or destination addresses can be inferred from
   the layer two source and destination addresses (of course, this is
   only possible for interface identifiers derived from an underlying
   802.15.4 MAC address); 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
   Traffic Class and the Flow Label are zero; and the Next Header is
   UDP, ICMP or TCP.  The only field in the IPv6 header that always
   needs to be carried in full is the Hop Limit (8 bits).  Depending on
   how closely the packet matches this common case, different fields may
   not be compressible thus needing to be carried "in-line" as well
   (Section 10.3.1).  This common IPv6 header (as mentioned above) can
   be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet

同じ6LoWPANネットワークに加わったことによって、デバイスは何らかの状態を共有します。 これで、明らかにどんな圧縮文脈状態も造らないでヘッダーを圧縮するのは可能になります。 したがって、6LoWPANヘッダー圧縮は、どんな流れも状態であることを保ちません。 代わりに、それは全体のリンクに関係する情報を当てにします。 以下のIPv6ヘッダー値が6LoWPANネットワークで一般的であると予想されるので、HC1ヘッダーは開始からそれらを効率的に圧縮するために組み立てられました: バージョンはIPv6です。 IPv6ソースと送付先アドレスの両方がリンクローカルです。 層twoのソースと送付先アドレスからソースか送付先アドレスのためのIPv6インタフェース識別子(64ビットの下部)を推論できます(もちろん、.4MACが扱う基本的な802.15から引き出されたインタフェース識別子だけに、これは可能です)。 層twoからパケット長を推論できる、(IEEEの「フレームの長さ」、802.15、.4PPDU、)、断片ヘッダー(存在しているなら)の「データグラム_サイズ」分野から。 Traffic ClassとFlow Labelの両方がゼロです。 そして、Next HeaderはUDP、ICMPまたはTCPです。 IPv6ヘッダーにおけるいつもすべて運ばれる必要がある唯一の分野がHop Limit(8ビット)です。 パケットがどれくらい密接にこのよくある例に合っているかによって、その結果、また、「インライン」で(セクション10.3.1)運ばれるのが必要でありながら、異なった分野は圧縮性でないかもしれません。 この一般的なIPv6ヘッダー(以上のように)を2つの八重奏に圧縮できる、(HC1コード化のための1つの八重奏と1つの八重奏

Montenegro, et al.          Standards Track                    [Page 17]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[17ページ]RFC4944IPv6

   for the Hop Limit), instead of 40 octets.  Such a packet is
   compressible via the LOWPAN_HC1 format by using a Dispatch value of
   LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8
   bits) to encode the different combinations as shown below.  This
   header may be preceded by a fragmentation header, which may be
   preceded by a mesh header.

Hop Limit)、40の八重奏の代わりに。 そのようなパケットは「HC1コード化LOWPAN_HC1ヘッダー」分野(8ビット)があとに続いた、以下に示すように異なった組み合わせをコード化したLOWPAN_HC1のDispatch値を使用するのによるLOWPAN_HC1形式で圧縮性です。 このヘッダーは断片化ヘッダーによって先行されるかもしれません。(ヘッダーはメッシュヘッダーによって先行されるかもしれません)。

                           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...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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コード化| 非圧縮された野原は続きます… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 9: LOWPAN_HC1 (common compressed header encoding)

図9: LOWPAN_HC1(一般的な圧縮されたヘッダーコード化)

   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 (Section 10.3).

(ビット7)より下で見ることができるように、HC2コード化はHC1八重奏に続くかもしれません。 この場合、非圧縮された分野は分野(セクション10.3)をコード化するHC2に続きます。

   The address fields encoded by "HC1 encoding" are interpreted as
   follows:

「HC1コード化」でコード化されたアドレス・フィールドは以下の通り解釈されます:

      PI:  Prefix carried in-line (Section 10.3.1).

パイ: 接頭語はインラインで(セクション10.3.1)運ばれました。

      PC:  Prefix compressed (link-local prefix assumed).

PC: 接頭語は(想定されたリンクローカルの接頭語)を圧縮しました。

      II:  Interface identifier carried in-line (Section 10.3.1).

II: インタフェース識別子はインラインで(セクション10.3.1)運ばれました。

      IC:  Interface identifier elided (derivable from the corresponding
         link-layer address).  If applied to the interface identifier of
         either the source or destination address when routing in a mesh
         (Section 11), the corresponding link-layer address is that
         found in the "Mesh Addressing" field (Section 5.2).

IC: 削除された(対応するリンクレイヤアドレスから誘導できる)識別子を連結してください。 メッシュ(セクション11)で掘るとき、ソースか送付先アドレスに関するインタフェース識別子に適用されるなら、対応するリンクレイヤアドレスはそれが「メッシュアドレシング」分野で(セクション5.2)を見つけたということです。

   The "HC1 encoding" is shown below (starting with bit 0 and ending at
   bit 7):

「HC1コード化」は以下に示されます(ビット0から始まって、ビット7で終わって):

      IPv6 source address (bits 0 and 1):

IPv6ソースアドレス(ビット0と1):

         00:  PI, II

00: パイ、II

         01:  PI, IC

01: パイ、IC

         10:  PC, II

10: PC、II

         11:  PC, IC

11: PC、IC

Montenegro, et al.          Standards Track                    [Page 18]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[18ページ]RFC4944IPv6

      IPv6 destination address (bits 2 and 3):

IPv6送付先アドレス(ビット2と3):

         00:  PI, II

00: パイ、II

         01:  PI, IC

01: パイ、IC

         10:  PC, II

10: PC、II

         11:  PC, IC

11: PC、IC

      Traffic Class and Flow Label (bit 4):

トラフィックのクラスと流れは(ビット4)をラベルします:

         0: not compressed; full 8 bits for Traffic Class and 20 bits
            for Flow Label are sent

0: 圧縮されません。 Traffic Classに、完全な8ビットとFlow Labelのための20ビットを送ります。

         1: Traffic Class and Flow Label are zero

1: トラフィックClassとFlow Labelはゼロです。

      Next Header (bits 5 and 6):

次のヘッダー(ビット5と6):

         00:  not compressed; full 8 bits are sent

00: 圧縮されません。 完全な8ビットを送ります。

         01:  UDP

01: UDP

         10:  ICMP

10: ICMP

         11:  TCP

11: TCP

      HC2 encoding(bit 7):

HC2コード化(ビット7):

         0: No more header compression bits

0: それ以上のヘッダー圧縮ビットがありません。

         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).

1: より多くのHC2コード化形式あたりのヘッダー圧縮ビットに従って、HC1コード化はすぐに、続きました。 ビット5と6は、可能なHC2 encodingsのどれが(例えば、UDP、ICMP、またはTCP encodings)を適用するかを決定します。

10.2.  Encoding of UDP Header Fields

10.2. UDPヘッダーフィールドのコード化

   Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header
   field in the IPv6 header (for UDP, TCP, and ICMP).  Further
   compression of each of these protocol headers is also possible.  This
   section explains how the UDP header itself may be compressed.  The
   HC2 encoding in this section is the HC_UDP encoding, and it only
   applies if bits 5 and 6 in HC1 indicate that the protocol that
   follows the IPv6 header is UDP.  The HC_UDP encoding (Figure 10)
   allows compressing the following fields in the UDP header: source
   port, destination port, and length.  The UDP header's checksum field
   is not compressed and is therefore carried in full.  The scheme

LOWPAN_HC1のビット5と6で、IPv6ヘッダー(UDP、TCP、およびICMPのための)のNext Header分野を圧縮します。 また、これらのプロトコルヘッダー各人のさらなる圧縮も可能です。 このセクションはUDPヘッダー自体がどう圧縮されるかもしれないかを説明します。 このセクションでのHC2コード化はHC_UDPコード化です、そして、HC1のビット5と6が、IPv6ヘッダーに続くプロトコルがUDPであることを示す場合にだけ、それは適用されます。 (図10)をコード化するHC_UDPはUDPヘッダーの以下の分野を圧縮させます: ソースポート、仕向港、および長さ。 UDPヘッダーのチェックサム野原は、圧縮されないで、したがって、すべて運ばれます。 体系

Montenegro, et al.          Standards Track                    [Page 19]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[19ページ]RFC4944IPv6

   defined below allows compressing the UDP header to 4 octets instead
   of the original 8 octets.

定義された下で、オリジナルの8つの八重奏の代わりに4つの八重奏にUDPヘッダーを圧縮します。

   The only UDP header field whose value may be deduced from information
   available elsewhere is the Length.  The other fields must be carried
   in-line either in full or in a partially compressed manner
   (Section 10.3.2).

値がほかの場所で入手できている情報から推論されるかもしれない唯一のUDPヘッダーフィールドがLengthです。 完全であるか部分的に圧縮された方法(セクション10.3.2)でインラインで他の野原を運ばなければなりません。

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |HC_UDP encoding|     Fields carried in-line follow...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |HC_UDPコード化| インラインで運ばれた野原は続きます… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 10: HC_UDP (UDP common compressed header encoding)

図10: HC_UDP(UDP一般的な圧縮されたヘッダーコード化)

   The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and
   ending at bit 7):

UDPのための「HC_UDPコード化」は以下に示されます(ビット0から始まって、ビット7で終わって):

      UDP source port (bit 0):

UDPソースポート(ビット0):

         0: Not compressed, carried "in-line" (Section 10.3.2)

0: 「インライン」で運ばれて、圧縮されません。(セクション10.3.2)

         1: Compressed to 4 bits.  The actual 16-bit source port is
            obtained by calculating: P + short_port value.  The value of
            P is the number 61616 (0xF0B0).  The short_port is expressed
            as a 4-bit value which is carried "in-line" (Section 10.3.2)

1: 4ビットに圧縮されています。 計算することによって、実際の16ビットのソースポートを得ます: + P短い_は値を移植します。 Pの値はNo.61616です(0xF0B0)。 短い_ポートは「インライン」で運ばれる4ビットの値として急送されます。(セクション10.3.2)

      UDP destination port (bit 1):

UDP仕向港(ビット1):

         0: Not compressed, carried "in-line" (Section 10.3.2)

0: 「インライン」で運ばれて、圧縮されません。(セクション10.3.2)

         1: Compressed to 4 bits.  The actual 16-bit destination port is
            obtained by calculating: P + short_port value.  The value of
            P is the number 61616 (0xF0B0).  The short_port is expressed
            as a 4-bit value which is carried "in-line" (Section 10.3.2)

1: 4ビットに圧縮されています。 計算することによって、実際の16ビットの仕向港を入手します: + P短い_は値を移植します。 Pの値はNo.61616です(0xF0B0)。 短い_ポートは「インライン」で運ばれる4ビットの値として急送されます。(セクション10.3.2)

      Length (bit 2):

長さ(ビット2):

         0: not compressed, carried "in-line" (Section 10.3.2)

0: 「インライン」で運ばれて、圧縮されません。(セクション10.3.2)

         1: compressed, length computed from IPv6 header length
            information.  The value of the UDP length field is equal to
            the Payload Length from the IPv6 header, minus the length of
            any extension headers present between the IPv6 header and
            the UDP header.

1: 圧縮されていて、長さはIPv6ヘッダ長情報から計算されました。 UDP長さの分野の値はIPv6ヘッダーからの有効搭載量Lengthと等しいです、IPv6ヘッダーとUDPヘッダーの間に出席しているどんな拡張ヘッダーの長さを引いて。

      Reserved (bit 3 through 7)

予約されます。(ビット3〜7)

Montenegro, et al.          Standards Track                    [Page 20]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[20ページ]RFC4944IPv6

10.3.  Non-Compressed Fields

10.3. 非圧縮された分野

10.3.1.  Non-Compressed IPv6 Fields

10.3.1. 非圧縮されたIPv6分野

   This scheme allows the IPv6 header to be compressed to different
   degrees.  Hence, instead of the entire (standard) IPv6 header, only
   non-compressed fields need to be sent.  The subsequent header (as
   specified by the Next Header field in the original IPv6 header)
   immediately follows the IPv6 non-compressed fields.

この体系は、IPv6ヘッダーが異なった度合いに圧縮されるのを許容します。 したがって、全体(標準の)のIPv6ヘッダーの代わりに、非圧縮された分野だけが、送られる必要があります。 その後のヘッダー(オリジナルのIPv6ヘッダーのNext Header分野によって指定されるように)はすぐに、IPv6の後をつけます。非圧縮された分野。

   Uncompressed IPv6 addressing is described by a dispatch type
   containing an IPv6 dispatch value followed by the uncompressed IPv6
   header.  This dispatch type may be preceded by additional LoWPAN
   headers.

解凍されたIPv6アドレシングは解凍されたIPv6ヘッダーによって後をつけられたIPv6発信価値を含む発信タイプによって説明されます。 この発信タイプは追加LoWPANヘッダーによって先行されるかもしれません。

   The non-compressed IPv6 field that MUST be always present is the Hop
   Limit (8 bits).  This field MUST always follow the encoding fields
   (e.g., "HC1 encoding" as shown in Figure 9), perhaps including other
   future encoding fields).  Other non-compressed fields MUST follow the
   Hop Limit as implied by the "HC1 encoding" in the exact same order as
   shown above (Section 10.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.

いつも存在しなければならない非圧縮されたIPv6分野はHop Limit(8ビット)です。 この分野はいつもコード化野原(例えば、恐らく他の未来を含んでいると分野がコード化されて、図9)に示される「HC1コード化」)に続かなければなりません。 他の非圧縮された分野は(セクション10.1)の上の全く同じオーダーにおける「HC1コード化」で含意されるようにHop Limitに続かなければなりません: ソースアドレス接頭語(64ビット)、そして/または、インタフェース識別子(64ビット)、送付先アドレスは(64ビット)、そして/または、インタフェース識別子(64ビット)と、Traffic Class(8ビット)と、Flow Label(20ビット)とNext Header(8ビット)を前に置きます。 次の実際のヘッダー(例えば、UDP、TCP、ICMPなど)は非圧縮された野原の後をつけます。

10.3.2.  Non-Compressed and Partially Compressed UDP Fields

10.3.2. 非圧縮されて部分的に圧縮されたUDP分野

   This scheme allows the UDP header to be compressed to different
   degrees.  Hence, instead of the entire (standard) UDP header, only
   non-compressed or partially compressed fields need to be sent.

この体系は、UDPヘッダーが異なった度合いに圧縮されるのを許容します。 したがって、全体(標準の)のUDPヘッダーの代わりに、非圧縮されたか部分的に圧縮された分野だけが、送られる必要があります。

   The non-compressed or partially compressed fields in the UDP header
   MUST always follow the IPv6 header and any of its associated in-line
   fields.  Any UDP header in-line fields present MUST appear in the
   same order as the corresponding fields appear in a normal UDP header
   [RFC0768], e.g., source port, destination port, length, and checksum.
   If either the source or destination ports are in "short_port"
   notation (as indicated in the compressed UDP header), then instead of
   taking 16 bits, the inline port numbers take 4 bits.

UDPヘッダーの非圧縮されたか部分的に圧縮された分野はいつもIPv6ヘッダーと関連インライン野原のいずれにも続かなければなりません。 対応する野原が例えば、普通のUDPヘッダー[RFC0768]、ソースポート、仕向港、長さ、およびチェックサムに現れるのに従って、インライン分野が紹介するどんなUDPヘッダーも同次に現れなければなりません。 「短い_ポート」記法(圧縮されたUDPヘッダーにみられるように)でソースか仕向港があるなら、16ビット取ることの代わりに、インラインポートナンバーは4ビット取ります。

11.  Frame Delivery in a Link-Layer Mesh

11. リンクレイヤメッシュでのフレーム配送

   Even though 802.15.4 networks are expected to commonly use mesh
   routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not
   define such capability.  In such cases, Full Function Devices (FFDs)
   run an ad hoc or mesh routing protocol to populate their routing
   tables (outside the scope of this document).  In such mesh scenarios,

一般的に使用する.4のネットワークが予想される802.15はルーティングを網の目にかけますが、IEEE802.15.4-2003仕様[ieee802.15.4]はそのような能力を定義しません。 そのような場合、Full Function Devices(FFDs)は、彼らの経路指定テーブル(このドキュメントの範囲の外の)に居住するために臨時であるかメッシュルーティング・プロトコルを実行します。 そのようなものでは、シナリオを網の目にかけてください。

Montenegro, et al.          Standards Track                    [Page 21]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[21ページ]RFC4944IPv6

   two devices do not require direct reachability in order to
   communicate.  Of these devices, the sender is known as the
   "Originator", and the receiver is known as the "Final Destination".
   An originator device may use other intermediate devices as forwarders
   towards the final destination.  In order to achieve such frame
   delivery using unicast, it is necessary to include the link-layer
   addresses of the originator and final destinations, in addition to
   the hop-by-hop source and destination.

2台のデバイスは、交信するためにダイレクト可到達性を必要としません。 これらのデバイスでは、送付者は「創始者」として知られています、そして、受信機は「ファイナル・デスティネーション」として知られています。 創始者デバイスは混載業者として最終的な目的地に向かって他の中間的デバイスを使用するかもしれません。 ユニキャストを使用することでそのようなフレーム配送を達成するために、創始者と最終的な目的地のリンクレイヤアドレスを含むのが必要です、ホップごとのソースと目的地に加えて。

   This section defines how to effect delivery of layer 2 frames in a
   mesh, given a target "Final Destination" link-layer address.

このセクションはメッシュでの層2のフレームの配送に作用する方法を定義します、「ファイナル・デスティネーション」という目標リンクレイヤアドレスを考えて。

   Mesh delivery is enabled by including a Mesh Addressing header prior
   to any other headers of the LoWPAN encapsulation (Section 5), an
   unfragmented and fragmented header; a full-blown IPv6 header; or a
   compressed IPv6 header as per Section 10 or any others defined
   elsewhere.

メッシュ配送はLoWPANカプセル化(セクション5)のいかなる他のヘッダーの前にもMesh Addressingヘッダーを含んでいることによって、可能にされます、非断片化していて断片化しているヘッダー。 花盛りのIPv6ヘッダー。 または、セクション10かほかの場所で定義されたどんな他のものに従って圧縮されたIPv6ヘッダー。

   If a node wishes to use a default mesh forwarder to deliver a packet
   (i.e., because it does not have direct reachability to the
   destination), it MUST include a Mesh Addressing header with the
   originator's link-layer address set to its own, and the final
   destination's link-layer address set to the packet's ultimate
   destination.  It sets the source address in the 802.15.4 header to
   its own link-layer address, and puts the forwarder's link-layer
   address in the 802.15.4 header's destination address field.  Finally,
   it transmits the packet.

ノードがパケットを提供するのにデフォルトメッシュ混載業者を使用したいと思うなら(すなわち、ダイレクト可到達性を目的地に持っていないので)、それは創始者のリンクレイヤアドレスセットでそれ自身のものにMesh Addressingヘッダーを含めなければなりません、そして、最終的な目的地のリンクレイヤアドレスはパケットの最終仕向地にセットしました。 それは、802.15におけるソースアドレス.4ヘッダーをそれ自身のリンクレイヤアドレスに設定して、.4ヘッダーの送付先アドレスがさばく802.15に混載業者のリンクレイヤアドレスを入れます。 最終的に、それはパケットを伝えます。

   Similarly, if a node receives a frame with a Mesh Addressing header,
   it must look at the Mesh Addressing header's "Final Destination"
   field to determine the real destination.  If the node is itself the
   final destination, it consumes the packet as per normal delivery.  If
   it is not the final destination, the device then reduces the "Hops
   Left" field, and if the result is zero, discards the packet.
   Otherwise, the node consults its link-layer routing table, determines
   what the next hop towards the final destination should be, and puts
   that address in the destination address field of the 802.15.4 header.
   Finally, the node changes the source address in the 802.15.4 header
   to its own link-layer address and transmits the packet.

同様に、ノードがMesh Addressingヘッダーと共にフレームを受けるなら、それは、本当の目的地を決定するためにMesh Addressingヘッダーの「ファイナル・デスティネーション」分野を見なければなりません。 ノードがそれ自体で最終的な目的地であるなら、それは正常分娩に従ってパケットを消費します。 結果が最終的な目的地、次に、デバイスが「ホップス左」分野を減少させるということでなく、ゼロであり、パケットを捨てるなら。 さもなければ、ノードは、リンクレイヤ経路指定テーブルに相談して、最終的な目的地に向かった次のホップが何であるべきであるかを決定して、802.15のものの目的地アドレス・フィールドにそのアドレスを置きます。.4ヘッダー。 最終的に、ノードは、802.15におけるソースアドレス.4ヘッダーをそれ自身のリンクレイヤアドレスに変えて、パケットを伝えます。

   Whereas a node must participate in a mesh routing protocol to be a
   forwarder, no such requirement exists for simply using mesh
   forwarding.  Only "Full Function Devices" (FFDs) are expected to
   participate as routers in a mesh.  "Reduced Function Devices" (RFDs)
   limit themselves to discovering FFDs and using them for all their
   forwarding, in a manner similar to how IP hosts typically use default
   routers to forward all their off-link traffic.  For an RFD using mesh
   delivery, the "forwarder" is always the appropriate FFD.

ノードは混載業者になるようにメッシュルーティング・プロトコルに参加しなければなりませんが、どんなそのような要件も、単にメッシュ推進を使用するために存在していません。 「完全な機能デバイス」(FFDs)だけがルータとしてメッシュに参加すると予想されます。 「減少しているFunction Devices」(RFDs)は自分たちを彼らのすべての推進にFFDsを発見して、彼らを使用するのに制限します、IPホストがそれらのすべてのオフリンクにトラフィックを送るのにどうデフォルトルータを通常使用するかと同様の方法で。 メッシュ配送を使用するRFDに関しては、いつも「混載業者」は適切なFFDです。

Montenegro, et al.          Standards Track                    [Page 22]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[22ページ]RFC4944IPv6

11.1.  LoWPAN Broadcast

11.1. LoWPAN放送

   Additional mesh routing functionality is encoded using a routing
   header immediately following the Mesh header.  In particular, a
   broadcast header consists of a LOWPAN_BC0 dispatch followed by a
   sequence number field.  The sequence number is used to detect
   duplicate packets (and hopefully suppress them).

Meshヘッダーに続いて、追加メッシュルーティングの機能性は、すぐにルーティングヘッダーを使用することでコード化されます。 特に、放送ヘッダーは一連番号分野があとに続いたLOWPAN_BC0発信から成ります。 一連番号は、写しパケットを検出するのに使用されます(希望をいだいてそれらを抑圧してください)。

                           1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|1|LOWPAN_BC0 |Sequence Number|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1|LOWPAN_BC0|一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 11: Broadcast Header

図11: 放送ヘッダー

   Field definitions are as follows:

フィールド定義は以下の通りです:

   Sequence Number:  This 8-bit field SHALL be incremented by the
      originator whenever it sends a new mesh broadcast or multicast
      packet.  Full specification of how to handle this field is out of
      the scope of this document.

一連番号: 増加されていて、新しいメッシュ放送かマルチキャストパケットを送るときはいつも、この8ビットは創始者でSHALLをさばきます。 このドキュメントの範囲の外にどうこの分野を扱うかに関する完全な仕様があります。

   Further implications of such mesh-layer broadcast, e.g., whether it
   maps to a controlled flooding mechanism or its role in, say, topology
   discovery, is out of the scope of this document.

このドキュメントの範囲の外に例えば、それがたとえば、制御氾濫メカニズムか中のその役割にトポロジー発見を写像するか否かに関係なく、放送されたそのようなメッシュ層のさらなる含意があります。

   Additional mesh routing capabilities, such as specifying the mesh
   routing protocol, source routing, and so on may be expressed by
   defining additional routing headers that precede the fragmentation or
   addressing header in the header stack.  The full specification of
   such mesh routing capabilities are out of the scope of this document.

メッシュルーティング・プロトコル、ソースルーティングなどを指定などなどの追加メッシュルーティング能力は、ヘッダースタックで断片化かアドレシングヘッダーに先行する追加ルーティングヘッダーを定義することによって、言い表されるかもしれません。 このドキュメントの範囲の外にそのようなメッシュルーティング能力の完全な仕様があります。

12.  IANA Considerations

12. IANA問題

   This document creates two new IANA registries, as discussed below.
   Future assignments in these registries 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.

このドキュメントは以下で議論するように2つの新しいIANA登録を作成します。 これらの登録の将来の課題は「仕様が必要であること」の[RFC2434]方針の下におけるIANAを通して調整されることです。 この方針が、他の(非IETF)組織が、より容易に課題を得るのを許容すると予想されます。

   This document creates a new IANA registry for the Dispatch type field
   shown in the header definitions in Section 5.  This document defines
   the values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two
   escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow
   additional dispatch bytes).  This document defines this field to be 8
   bits long.  The values 00xxxxxx being reserved and not used, allows
   for a total of 192 different values, which should be more than

このドキュメントはセクション5とのヘッダー定義で示されたDispatchタイプ分野に新しいIANA登録を作成します。 このドキュメントはIPv6、LOWPAN_HC1ヘッダー圧縮、BC0が放送して、2エスケープが型に基づいて作る値(追加発信バイトを許容するためにLOWPANフレームとどんなESCも示さないNALP)を定義します。 このドキュメントは、長さ8ビットであるためにこの分野を定義します。 値の00xxxxxxは予約されて、使用されないで、合計192の異価を考慮します。(異価は、より多いはずです)。

Montenegro, et al.          Standards Track                    [Page 23]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[23ページ]RFC4944IPv6

   enough.  If header compression formats in addition to HC1 are defined
   or if additional TCP, ICMP HC2 formats are defined, it is expected
   that these will use reserved dispatch values following LOWPAN_HC1.
   If additional mesh delivery formats are defined these will use
   reserved values following LOWPAN_BC0.

十分。 HC1に加えたヘッダー圧縮書式が定義されるか、またはICMP HC2書式が追加TCPであるなら、定義されるなら、LOWPAN_HC1に続いて、これらが予約された発信値を使用すると予想されます。 追加メッシュ配送書式が定義されると、LOWPAN_BC0に続いて、これらは予約された値を使用するでしょう。

   This document creates a new IANA registry for the 16-bit short
   address fields as used in 6LoWPAN packets.

このドキュメントは6LoWPANパケットで使用されるように16ビットの短いアドレス・フィールドに新しいIANA登録を作成します。

                       0                   1
                       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |     16-bit short Address      |
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16ビットの短いAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 12

図12

   This registry MUST include the addresses 0xffff (16-bit broadcast
   address accepted by all devices currently listening to the channel)
   and 0xfffe as defined in [ieee802.15.4].  Additionally, within
   6LoWPAN networks, 16-bit short addresses MUST follow this format
   (referring to bit fields in the order from 0 to 7), where "x" is a
   place holder for an unspecified bit value:

この登録は[ieee802.15.4]で定義されるようにアドレスの0xffff(チャンネルの言うことを聞く現在すべてのデバイスによって受け入れられている16ビットの放送演説)と0xfffeを含まなければなりません。 さらに、6LoWPANネットワークの中では、16ビットの短いアドレスはこの形式(0〜7までのオーダーにおける噛み付いている野原について言及する)に続かなければなりません、「x」が不特定の噛み付いている値のための場所所有者であるところで:

   Range 1, 0xxxxxxxxxxxxxxx:  The first bit (bit 0) SHALL be zero if
      the 16-bit address is a unicast address.  This leaves 15 bits for
      the actual address.

範囲1、0xxxxxxxxxxxxxxx: 1番目はSHALLに噛み付きました(ビット0)。16ビット・アドレスがユニキャストアドレスであるなら、ゼロになってください。 これは15ビットを絶対番地に残します。

   Range 2, 100xxxxxxxxxxxxx:  Bits 0, 1, and 2 SHALL follow this
      pattern if the 16-bit address is a multicast address (see
      Section 9).  This leaves 13 bits for the actual multicast address.

範囲2、100xxxxxxxxxxxxx: ビット0、1、および2SHALLは16ビットのアドレスがマルチキャストアドレス(セクション9を見る)であるならこのパターンに従います。 これは実際のマルチキャストのための13ビットをアドレスに残します。

   Range 3, 101xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
      reserved.  Any future assignment shall follow the policy mentioned
      above.

範囲3、101xxxxxxxxxxxxx: この何ビット0、1、および2もパターンは予約されています。 どんな将来の課題も前記のように方針に従うものとします。

   Range 4, 110xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
      reserved.  Any future assignment shall follow the policy mentioned
      above.

範囲4、110xxxxxxxxxxxxx: この何ビット0、1、および2もパターンは予約されています。 どんな将来の課題も前記のように方針に従うものとします。

   Range 5, 111xxxxxxxxxxxxx:  This pattern for bits 0, 1, and 2 is
      reserved.  Any future assignment shall follow the policy mentioned
      above.

範囲5、111xxxxxxxxxxxxx: この何ビット0、1、および2もパターンは予約されています。 どんな将来の課題も前記のように方針に従うものとします。

Montenegro, et al.          Standards Track                    [Page 24]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[24ページ]RFC4944IPv6

13.  Security Considerations

13. セキュリティ問題

   The method of derivation of Interface Identifiers from EUI-64 MAC
   addresses is intended to preserve global uniqueness when possible.
   However, there is no protection from duplication through accident or
   forgery.

可能であるときに、EUI-64 MACアドレスからのInterface Identifiersの派生のメソッドがグローバルなユニークさを保存することを意図します。 しかしながら、ノー・プロテクションが複製から事故か偽造であります。

   Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
   threats as detailed in [RFC3756].  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 stated above.

IEEE802.15.4個のリンクの隣人ディスカバリーは[RFC3756]で詳しく述べられるように脅威に影響されやすいかもしれません。 メッシュルーティングがIEEE802.15.4のネットワークで一般的であると予想されます。 これは[KW03]に従って臨時のルーティングによる追加脅威を含意します。 IEEE802.15.4は何らかの能力をリンクレイヤセキュリティに提供します。 ユーザは、できれば、そのような条項を利用するよう促されて、実用的です。 そうするのは上に述べられた脅威を軽減するでしょう。

   A sizeable portion of IEEE 802.15.4 devices is expected to always
   communicate within their PAN (i.e., within their link, in IPv6
   terms).  In response to cost and power consumption considerations,
   and in keeping with the IEEE 802.15.4 model of "Reduced Function
   Devices" (RFDs), these devices will typically implement the minimum
   set of features necessary.  Accordingly, security for such devices
   may rely quite strongly on the mechanisms defined at the link layer
   by IEEE 802.15.4.  The latter, however, only defines the Advanced
   Encryption Standard (AES) modes for authentication or encryption of
   IEEE 802.15.4 frames, and does not, in particular, specify key
   management (presumably group oriented).  Other issues to address in
   real deployments relate to secure configuration and management.
   Whereas such a complete picture is out of the scope of this document,
   it is imperative that IEEE 802.15.4 networks be deployed with such
   considerations in mind.  Of course, it is also expected that some
   IEEE 802.15.4 devices (the so-called "Full Function Devices", or
   "FFDs") will implement coordination or integration functions.  These
   may communicate regularly with off-link IPv6 peers (in addition to
   the more common on-link exchanges).  Such IPv6 devices are expected
   to secure their end-to-end communications with the usual mechanisms
   (e.g., IPsec, TLS, etc).

それらのPANの中でいつも伝える802.15台の.4デバイスが予想されるIEEE(すなわち、IPv6用語によるそれらのリンクの中の)のかなり大きい部分。 「減少している機能デバイス」(RFDs)のIEEE802.15.4モデルと共に費用と電力消費量問題に対応して保つ際に、これらのデバイスは最小の必要特性を通常実装するでしょう。 それに従って、そのようなデバイスのためのセキュリティが全く強くリンクレイヤでIEEEによって定義されたメカニズムを当てにするかもしれない、802.15、.4 しかしながら、後者がIEEEの認証か暗号化のためのエー・イー・エス(AES)モードを定義するだけである、802.15個の.4フレーム、かぎ管理(おそらく、指向していた状態で、分類する)を特に指定しません。 本当の展開で扱う他の問題は安全な構成と管理に関連します。 このドキュメントの範囲の外にそのような完全な画像はありますが、IEEE802.15.4のネットワークが念頭でそのような問題で配布されるのは、必須です。 もちろん、また、いくつかのIEEE802.15.4デバイス(いわゆる「完全な機能デバイス」、または「FFDs」)が、コーディネートか統合が機能であると実装すると予想されます。 これらは定期的にオフリンクIPv6同輩(リンクにおけるより一般的な交換に加えた)とコミュニケートするかもしれません。 そのようなIPv6デバイスが普通のメカニズム(例えば、IPsec、TLSなど)とのそれらのエンド・ツー・エンド通信を保証すると予想されます。

14.  Acknowledgements

14. 承認

   Thanks to the authors of RFC 2464 and RFC 2734, as parts of this
   document are patterned after theirs.  Thanks to Geoff Mulligan for
   useful discussions which helped shape this document.  Erik Nordmark's
   suggestions were instrumental for the header compression section.
   Also thanks to Shoichi Sakane, Samita Chakrabarti, Vipul Gupta,
   Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus
   Westerlund, and Jari Arkko.

このドキュメントの部分が彼等のものの後に型に基づいて作られるとき、RFC2464とRFC2734の作者をありがとうございます。 おかげに、助けた役に立つ議論のためのジェフMulliganはこのドキュメントを形成します。 ヘッダー圧縮部分において、エリックNordmarkの提案は手段になっていました。 また、Shoichi Sakane、Samita Chakrabarti、Vipulグプタ、カルステン・ボルマン、Ki-Hyungキム、マリオ・マオ、フィル・レビー、マグヌスWesterlund、およびヤリArkkoをありがとうございます。

Montenegro, et al.          Standards Track                    [Page 25]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[25ページ]RFC4944IPv6

15.  References

15. 参照

15.1.  Normative References

15.1. 引用規格

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2434]       Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 2434, October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
                   Version 6 (IPv6) Specification", RFC 2460,
                   December 1998.

[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

   [RFC2464]       Crawford, M., "Transmission of IPv6 Packets over
                   Ethernet Networks", RFC 2464, December 1998.

[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。

   [RFC4291]       Hinden, R. and S. Deering, "IP Version 6 Addressing
                   Architecture", RFC 4291, February 2006.

[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。

   [RFC4861]       Narten, T., Nordmark, E., Simpson, W., and H.
                   Soliman, "Neighbor Discovery for IP version 6
                   (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。

   [RFC4862]       Thomson, S., Narten, T., and T. Jinmei, "IPv6
                   Stateless Address Autoconfiguration", RFC 4862,
                   September 2007.

[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。

   [ieee802.15.4]  IEEE Computer Society, "IEEE Std. 802.15.4-2003",
                   October 2003.

[ieee802.15.4] IEEEコンピュータ社会、"IEEE Std"。 2003年10月の「802.15.4-2003。」

15.2.  Informative References

15.2. 有益な参照

   [EUI64]         "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64)
                   REGISTRATION AUTHORITY", IEEE http://
                   standards.ieee.org/regauth/oui/tutorials/EUI64.html.

[EUI64] 「64ビットのグローバルな識別子(EUI-64)登録局のためのガイドライン」、IEEE http://standards.ieee.org/regauth/oui/チュートリアル/EUI64.html。

   [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.

[KW03] Karlofとクリスとワグナー、デヴィッド、「センサネットワークでルート設定を保証してください」 「攻撃とCountermeasures」(ElsevierのAdHoc Networks Journal、Sensor Network Applicationsとプロトコルvol1のSpecial Issue)は2-3を発行します、2003年9月。

   [RFC0768]       Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                   August 1980.

[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。

Montenegro, et al.          Standards Track                    [Page 26]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[26ページ]RFC4944IPv6

   [RFC3756]       Nikander, P., Kempf, J., and E. Nordmark, "IPv6
                   Neighbor Discovery (ND) Trust Models and Threats",
                   RFC 3756, May 2004.

[RFC3756] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。

   [RFC3819]       Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
                   Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
                   and L. Wood, "Advice for Internet Subnetwork
                   Designers", BCP 89, RFC 3819, July 2004.

[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。

Montenegro, et al.          Standards Track                    [Page 27]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[27ページ]RFC4944IPv6

Appendix A.  Alternatives for Delivery of Frames in a Mesh

メッシュでのフレームの配送のための付録A.代替手段

   Before settling on the mechanism finally adopted for delivery in a
   mesh (Section 11), several alternatives were considered.  In addition
   to the hop-by-hop source and destination link-layer addresses,
   delivering a packet in a LoWPAN mesh requires the end-to-end
   originator and destination addresses.  These could be expressed
   either as layer 2 or as layer 3 (i.e., IP ) addresses.  In the latter
   case, there would be no need to provide any additional header support
   in this document (i.e., within the LoWPAN header itself).  The link-
   layer destination address would point to the next hop destination
   address while the IP header destination address would point to the
   final destination (IP) address (possibly multiple hops away from the
   source), and similarly for the source addresses.  Thus, while
   forwarding data, the single-hop source and destination addresses
   would change at each hop (always pointing to the node doing the
   forwarding and the "best" next link-layer hop, respectively), while
   the source and destination IP addresses would remain unchanged.
   Notice that if an IP packet is fragmented, the individual fragments
   may arrive at any node out of order.  If the initial fragment (which
   contains the IP header) is delayed for some reason, a node that
   receives a subsequent fragment would lack the required information.
   It would be forced to wait until it receives the IP header (within
   the first fragment) before being able to forward the fragment any
   further.  This imposes some additional buffering requirements on
   intermediate nodes.  Additionally, such a specification would only
   work for one type of LoWPAN payload: IPv6.  In general, it would have
   to be adapted for any other payload, and would require that payload
   to provide its own end-to-end addressing information.

メッシュ(セクション11)での配送のために最終的に採用されたメカニズムについて決める前に、いくつかの選択肢が考えられました。 ホップごとのソースと送付先リンクレイヤアドレスに加えて、LoWPANメッシュでパケットを提供するのは終わりから終わりへの創始者と送付先アドレスを必要とします。 層2として、または、層3(すなわち、IP)のアドレスとしてこれらを言い表すことができました。 後者の場合には、本書では(すなわち、LoWPANヘッダー自体の中に)どんな追加ヘッダーサポートも提供する必要は全くないでしょう。 IPヘッダー送付先アドレスがソースアドレスのために、同様に、最終的な送付先(IP)アドレス(ソースから遠くのことによると複数のホップ)を示しているだろうという間、リンク層の送付先アドレスは次のホップ送付先アドレスを示すでしょう。 したがって、単一のホップソースと送付先アドレスはデータを転送している間、各ホップ(いつも推進をするノードと次の「最も良い」リンクレイヤホップを示しますそれぞれ)で変化するでしょう、IPが演説するソースと目的地は変わりがないでしょうが。 IPパケットが断片化されるなら、個々の断片がどんなノードにも故障していた状態で届くかもしれないのに注意してください。 初期の断片(IPヘッダーを含む)がある理由で遅らせられるなら、その後の断片を受けるノードは必須情報を欠いているでしょう。 それは断片をこれ以上進めることができる前にIPヘッダー(最初の断片の中の)を受けるまでやむを得ず待つでしょう。 これはいくつかの追加バッファリング要件を中間的ノードに課します。 さらに、そのような仕様は1つのタイプのLoWPANペイロードのために利くだけでしょう: IPv6。 一般に、終わりから終わりへのそれ自身のアドレス指定情報を提供するのが、いかなる他のペイロードのためにも適合させられなければならなくて、そのペイロードを必要とするでしょう。

   On the other hand, the approach finally followed (Section 11) creates
   a mesh at the LoWPAN layer (below layer 3).  Accordingly, the link-
   layer originator and final destination address are included within
   the LoWPAN header.  This enables mesh delivery for any protocol or
   application layered on the LoWPAN adaptation layer (Section 5).  For
   IPv6 as supported in this document, another advantage of expressing
   the originator and final destinations as layer 2 addresses is that
   the IPv6 addresses can be compressed as per the header compression
   specified in Section 10.  Furthermore, the number of octets needed to
   maintain routing tables is reduced due to the smaller size of
   802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6
   addresses (128 bits).  A disadvantage is that applications on top of
   IP do not address packets to link-layer destination addresses, but to
   IP (layer 3) destination addresses.  Thus, given an IP address, there
   is a need to resolve the corresponding link-layer address.
   Accordingly, a mesh routing specification needs to clarify the
   Neighbor Discovery implications, although in some special cases, it
   may be possible to derive a device's address at layer 2 from its

他方では、最終的に続かれるアプローチ(セクション11)はLoWPAN層(層3の下における)にメッシュを作成します。 それに従って、リンク層の創始者と最終的な送付先アドレスはLoWPANヘッダーの中に含まれています。 これはLoWPAN適合層(セクション5)で層にされたどんなプロトコルやアプリケーションのためのメッシュ配送も可能にします。 本書ではサポートされるIPv6に関しては、層2のアドレスとして創始者と最終的な目的地を言い表す別の利点はセクション10で指定されたヘッダー圧縮に従ってIPv6アドレスを圧縮できるということです。 その上、IPv6アドレス(128ビット)と比べて、経路指定テーブルを維持するのに必要である八重奏の数は802.15の.4アドレス(64ビットか16ビットのどちらか)の、より小さいサイズのため減少します。 不都合はIPの上のアプリケーションがリンクレイヤ送付先アドレスにパケットを扱うのではなく、IP(層3)送付先アドレスに扱うということです。 IPアドレスをこのようにして考えて、対応するリンクレイヤアドレスを決議する必要があります。 それに従って、aメッシュルーティング仕様は、Neighborディスカバリー含意をはっきりさせる必要があります、それが層2のデバイスのアドレスを引き出すのにおいていくつかの特別な場合では、可能であるかもしれませんがそれ

Montenegro, et al.          Standards Track                    [Page 28]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[28ページ]RFC4944IPv6

   address at layer 3 (and vice versa).  Such complete specification is
   outside the scope of this document.

層3(逆もまた同様に)のアドレス。 このドキュメントの範囲の外にそのような完全な仕様はあります。

Authors' Addresses

作者のアドレス

   Gabriel Montenegro
   Microsoft Corporation

ガブリエルモンテネグロマイクロソフト社

   EMail: gabriel.montenegro@microsoft.com

メール: gabriel.montenegro@microsoft.com

   Nandakishore Kushalnagar
   Intel Corp

Nandakishore KushalnagarインテルCorp

   EMail: nandakishore.kushalnagar@intel.com

メール: nandakishore.kushalnagar@intel.com

   Jonathan W. Hui
   Arch Rock Corp

ジョナサンW.ホイアーチ岩石のCorp

   EMail: jhui@archrock.com

メール: jhui@archrock.com

   David E. Culler
   Arch Rock Corp

デヴィッドE.害獣駆除業者アーチ岩石のCorp

   EMail: dculler@archrock.com

メール: dculler@archrock.com

Montenegro, et al.          Standards Track                    [Page 29]

RFC 4944                IPv6 over IEEE 802.15.4           September 2007

モンテネグロ、他 IEEE802.15.4 2007年9月の間の標準化過程[29ページ]RFC4944IPv6

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Montenegro, et al.          Standards Track                    [Page 30]

モンテネグロ、他 標準化過程[30ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

mlabel フロッピ・ディスクにボリューム・ラベルを付ける

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る