Network Working Group N. Kushalnagar
Request for Comments: 4919 Intel Corp
Category: Informational G. Montenegro
Microsoft Corporation
C. Schumacher
Danfoss A/S
August 2007
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only.
このドキュメントでは、IEEE 802.15.4ネットワーク上でIPを送信するための前提条件、問題文と目標を説明します。このドキュメントで列挙目標のセットは、最初のセットのみを形成します。
Table of Contents
目次
1. Introduction ....................................................2
2. Overview ........................................................2
3. Assumptions .....................................................3
4. Problems ........................................................4
4.1. IP Connectivity ............................................4
4.2. Topologies .................................................5
4.3. Limited Packet Size ........................................6
4.4. Limited Configuration and Management .......................6
4.5. Service Discovery ..........................................6
4.6. Security ...................................................6
5. Goals ...........................................................7
6. Security Considerations .........................................9
7. Acknowledgements ...............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Low-power wireless personal area networks (LoWPANs) comprise devices that conform to the IEEE 802.15.4-2003 standard by the IEEE [IEEE802.15.4]. IEEE 802.15.4 devices are characterized by short range, low bit rate, low power, and low cost. Many of the devices employing IEEE 802.15.4 radios will be limited in their computational power, memory, and/or energy availability.
低電力無線パーソナルエリアネットワーク（LoWPANs）は、IEEE [IEEE802.15.4]によってIEEE 802.15.4-2003規格に準拠するデバイスを含みます。 IEEE 802.15.4デバイスは、短距離、低ビットレート、低消費電力、及び低コストによって特徴付けられます。 IEEE 802.15.4無線を採用するデバイスの多くは、彼らの計算能力、メモリ、および/またはエネルギーの利用に制限されます。
This document gives an overview of LoWPANs and describes how they benefit from IP and, in particular, IPv6 networking. It describes LoWPAN requirements with regards to the IP layer and the above, and spells out the underlying assumptions of IP for LoWPANs. Finally, it describes problems associated with enabling IP communication with devices in a LoWPAN, and defines goals to address these in a prioritized manner. Admittedly, not all items on this list may be necessarily appropriate tasks for the IETF. Nevertheless, they are documented here to give a general overview of the larger problem. This is useful both to structure work within the IETF as well as to better understand how to coordinate with external organizations.
この文書では、LoWPANsの概要を説明しますと、彼らは特定の、IPv6のネットワークでは、IPの恩恵を受けると方法を説明します。これは、IP層および上記にに関してLoWPAN要件について説明し、LoWPANsのためのIPの基礎となる仮定を綴ります。最後に、それはLoWPAN内のデバイスとのIP通信を可能に関連する問題について説明し、優先順位付け方法でこれらに対処するための目標を定義します。確かに、このリストにないすべての項目は、IETFのために、必ずしも適切なタスクかもしれません。それにもかかわらず、彼らはより大きな問題の一般的な概要を与えるためにここに記載されています。これは、両方のは、IETF内の作業を構造化するだけでなく、優れた外部機関と連携する方法を理解しておくと便利です。
A LoWPAN is a simple low cost communication network that allows wireless connectivity in applications with limited power and relaxed throughput requirements. A LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors. LoWPANs conform to the IEEE 802.15.4-2003 standard [IEEE802.15.4].
LoWPANは、限られた電力と緩和スループット要件を有するアプリケーションで無線接続を可能にする単純な低コストの通信網です。 LoWPANは通常、実際のアプリケーション、例えば、無線センサーへの物理的環境を接続するために一緒に働くのデバイスを含んでいます。 LoWPANsは、IEEE 802.15.4-2003標準[IEEE802.15.4]に準拠しています。
Some of the characteristics of LoWPANs are as follows:
次のようにLoWPANsの特性は以下の通りです。
1. Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting 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 81 octets for data packets.
1.小さなパケットサイズ。最大物理層パケットは127バイトであることを考えると、メディアアクセス制御層で得られた最大フレームサイズが102オクテットです。リンク・レイヤ・セキュリティは、最大の場合（21 9対AES-CCM-128の場合のオーバーヘッドのオクテット、およびAES-CCM-32およびAES-CCM-64、それぞれ13）に、81個のオクテットを残し、さらにオーバーヘッドを課しますデータパケットのために。
2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses.
両方の16ビットのショートまたはIEEE 64ビットの拡張媒体アクセス制御アドレス2.サポート。
3. Low bandwidth. Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz, and 868 MHz, respectively).
3.低帯域幅。現在定義された物理層（それぞれ2.4ギガヘルツ、915メガヘルツ、及び868メガヘルツ）の各々についての250 kbpsの、40 kbpsの、20 kbpsのデータレート。
6. Low cost. These devices are typically associated with sensors, switches, etc. This drives some of the other characteristics such as low processing, low memory, etc. Numerical values for "low" elided on purpose since costs tend to change over time.
6.低コスト。コストは時間とともに変化する傾向があるので、これらのデバイスは、典型的には、これは意図的に省略さ「低」のためのこのような低い処理などの他の特性の一部、メモリ不足等の数値を駆動する等のセンサ、スイッチ、関連付けられています。
7. Large number of devices expected to be deployed during the lifetime of the technology. This number is expected to dwarf the number of deployed personal computers, for example.
技術の寿命の間に展開することが期待されるデバイスの7大多数。この数は、例えば、展開のパーソナルコンピュータの数を小さく見せすることが期待されます。
8. Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Furthermore, sometimes the location of these devices may not be easily accessible. Additionally, these devices may move to new locations.
それらはアドホック方式で展開される傾向があるようにデバイスの8場所は、典型的には、事前に定義されていません。また、時にはこれらのデバイスの位置を容易にアクセス可能でないかもしれません。さらに、これらのデバイスは、新しい場所に移動することができます。
9. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc.
不確実なラジオの接続、バッテリーの消耗、デバイスのロックアップ、物理的改ざんなど：LoWPANs内9.デバイスは、様々な理由により信頼性が低い傾向にあり
10. In many environments, devices connected to a LoWPAN may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods.
10.多くの環境で、LoWPANに接続されたデバイスは、エネルギーを節約するために長期間スリープ、及びこれらの睡眠期間中に通信することができないことができます。
The following sections take into account these characteristics in describing the assumptions, problems statement, and goals for LoWPANs, and, in particular, for 6LoWPANs (IPv6-based LoWPAN networks).
次のセクションでは、6LoWPANs（LoWPANネットワークをIPv6ベース）のために、特に、LoWPANsの前提条件、問題文と目標を記述する際に考慮にこれらの特性を取る、と。
Given the small packet size of LoWPANs, this document presumes applications typically send small amounts of data. However, the protocols themselves do not restrict bulk data transfers.
LoWPANsの小さなパケットサイズを考えると、このドキュメントは、アプリケーションが一般的に少量のデータを送信する前提としています。しかし、プロトコル自体はバルク・データ転送を制限するものではありません。
LoWPANs, as described in this document, are based on IEEE 802.15.4-2003. It is possible that the specification may undergo changes in the future and may change some of the requirements mentioned above.
LoWPANsは、この文書で説明したように、IEEE 802.15.4-2003に基づいています。仕様は、将来の変化を受けることと、上記要件の一部を変更することが可能です。
Some of these assumptions are based on the limited capabilities of devices within LoWPANs. As devices become more powerful, and consume less power, some of the requirements mentioned above may be somewhat relaxed.
これらの仮定のいくつかはLoWPANs内のデバイスの限られた能力に基づいています。デバイスがより強力になり、消費電力が少ないため、上記の要件の一部は、ややリラックスしたかもしれません。
While some LoWPAN devices are expected to be extremely limited (the so-called "Reduced Function Devices" or RFDs), more capable "Full Function Devices" (FFDs) will also be present, albeit in much smaller numbers. FFDs will typically have more resources and may be mains powered. Accordingly, FFDs will aid RFDs by providing functions such as network coordination, packet forwarding, interfacing with other types of networks, etc.
いくつかのLoWPANデバイスは、非常に（いわゆる「縮小機能デバイス」またはRFDS）制限されることが期待される一方で、より高機能な「フル機能デバイス」（FFDs）もはるかに小さい数字ではあるが、存在することになります。 FFDsは、一般的に、より多くのリソースを持つことになりますと、主電源電力を供給することができます。従って、FFDsは等ネットワーク調整、パケット転送、ネットワークの他のタイプとのインターフェースとしての機能を提供することによってRFDSを助けます
The application of IP technology is assumed to provide the following benefits:
IP技術の適用は、次のような利点を提供すると想定されます。
1. The pervasive nature of IP networks allows use of existing infrastructure.
1. IPネットワークの普及性質は、既存のインフラストラクチャを使用することができます。
2. IP-based technologies already exist, are well-known, and proven to be working.
2. IPベースの技術は、既に、存在してよく知られており、そして仕事ができることが証明します。
3. An admittedly non-technical but important consideration is that IP networking technology is specified in open and freely available specifications, which is favorable or at least able to be better understood by a wider audience than proprietary solutions.
3.アン確かに非技術的だが重要な考慮事項は、IPネットワーキング技術が優れて独自のソリューションよりも幅広い視聴者が理解有利または少なくともことが可能で、オープンで自由に利用できる仕様に指定されていることです。
4. Tools for diagnostics, management, and commissioning of IP networks already exist.
4.診断用ツール、管理、およびIPネットワークの試運転がすでに存在しています。
5. IP-based devices can be connected readily to other IP-based networks, without the need for intermediate entities like translation gateways or proxies.
5. IPベースのデバイスは、変換ゲートウェイまたはプロキシなどの中間エンティティを必要とせず、容易に他のIPベースのネットワークに接続することができます。
Based on the characteristics defined in the overview section, the following sections elaborate on the main problems with IP for LoWPANs.
概要セクションで定義された特性に基づいて、次のセクションでは、LoWPANsのためのIPの主な問題について詳しく説明します。
The requirement for IP connectivity within a LoWPAN is driven by the following:
LoWPAN内のIP接続のための要件は、次によって駆動されます。
1. The many devices in a LoWPAN make network auto configuration and statelessness highly desirable. And for this, IPv6 has ready solutions.
1. LoWPANで多くのデバイスは、ネットワークの自動設定とステートレスは非常に望ましくします。このため、IPv6は準備ができてソリューションを提供しています。
2. The large number of devices poses the need for a large address space, well met by IPv6.
2.多数のデバイスがよくIPv6ので会った、大規模なアドレス空間の必要性を提起します。
3. Given the limited packet size of LoWPANs, the IPv6 address format allows subsuming of IEEE 802.15.4 addresses if so desired.
所望であれば3. LoWPANsの限られたパケットサイズを考えると、IPv6アドレスのフォーマットは、IEEE 802.15.4アドレスの包摂が可能になります。
4. Simple interconnectivity to other IP networks including the Internet.
インターネットを含む他のIPネットワークへ4.シンプルな相互接続。
However, given the limited packet size, headers for IPv6 and layers above must be compressed whenever possible.
しかし、限られたパケットのサイズを考えると、IPv6および上記層のヘッダは、可能な限り圧縮されなければなりません。
LoWPANs must support various topologies including mesh and star.
LoWPANsはメッシュとスターなど、さまざまなトポロジをサポートしている必要があります。
Mesh topologies imply multi-hop routing, to a desired destination. In this case, intermediate devices act as packet forwarders at the link layer (akin to routers at the network layer). Typically these are "full function devices" that have more capabilities in terms of power, computation, etc. The requirements on the routing protocol are:
メッシュトポロジーは、所望の宛先に、マルチホップルーティングを意味します。この場合、中間装置は、（ネットワーク層におけるルータに類似）リンク層でパケットフォワーダとして作用します。 ：典型的には、これらは、ルーティングプロトコル上の要件は、電力の面で多くの機能を持っている「フル機能デバイス」、計算、等です
1. Given the minimal packet size of LoWPANs, the routing protocol must impose low (or no) overhead on data packets, hopefully independently of the number of hops.
1 LoWPANsの最小パケットサイズを考慮すると、ルーティングプロトコルは、うまくいけば、独立してホップ数のデータパケットに低い（または全く）オーバーヘッドを課す必要があります。
2. The routing protocols should have low routing overhead (low chattiness) balanced with topology changes and power conservation.
2.ルーティングプロトコルは、トポロジの変更と省電力とバランス低ルーティングオーバーヘッド（低chattiness）を有するべきです。
3. The computation and memory requirements in the routing protocol should be minimal to satisfy the low cost and low power objectives. Thus, storage and maintenance of large routing tables is detrimental.
前記ルーティングプロトコルにおける計算およびメモリの要件は、低コストかつ低消費電力の目標を満たすために最小であるべきです。したがって、大きなルーティングテーブルの格納及び維持は有害です。
4. Support for network topologies in which either FFDs or RFDs may be battery or mains-powered. This implies the appropriate considerations for routing in the presence of sleeping nodes.
FFDs又はRFDSのいずれかが電池または電源駆動可能なネットワークトポロジ4.サポート。これは、睡眠ノードの存在下でのルーティングのために適切な考慮を意味しています。
As with mesh topologies, star topologies include provisioning a subset of devices with packet forwarding functionality. If, in addition to IEEE 802.15.4, these devices use other kinds of network interfaces such as ethernet or IEEE 802.11, the goal is to seamlessly integrate the networks built over those different technologies. This, of course, is a primary motivation to use IP to begin with.
メッシュトポロジーと同様に、スタートポロジでは、パケット転送機能を持つデバイスのサブセットをプロビジョニング含まれています。 IEEE 802.15.4に加えて、これらのデバイスは、イーサネット（登録商標）やIEEE 802.11などのネットワークインターフェイスの他の種類を使用した場合、目標は、シームレスに、これらの異なる技術の上に構築されたネットワークを統合することです。これは、当然のことながら、そもそもIPを使用する主な動機です。
Applications within LoWPANs are expected to originate small packets. Adding all layers for IP connectivity should still allow transmission in one frame, without incurring excessive fragmentation and reassembly. Furthermore, protocols must be designed or chosen so that the individual "control/protocol packets" fit within a single 802.15.4 frame. Along these lines, IPv6's requirement of sub-IP reassembly (see Section 5) may pose challenges for low-end LoWPAN devices that do not have enough RAM or storage for a 1280-octet packet.
LoWPANs内のアプリケーションは、小さなパケットを発信することが期待されています。 IP接続のための全ての層を追加すると、依然として過剰な断片化と再アセンブリを招くことなく、1つのフレーム内の送信を可能にすべきです。さらに、プロトコルを設計または個々の「制御/プロトコルパケットが」単一802.15.4フレーム内に収まるように選択されなければなりません。これらの線に沿って、サブIPの再構築のIPv6の要件の1280オクテットのパケットのための十分なRAMやストレージを持たないローエンドのLoWPANデバイスのための課題を提起する（第5章を参照してください）。
As alluded to above, devices within LoWPANs are expected to be deployed in exceedingly large numbers. Additionally, they are expected to have limited display and input capabilities. Furthermore, the location of some of these devices may be hard to reach. Accordingly, protocols used in LoWPANs should have minimal configuration, preferably work "out of the box", be easy to bootstrap, and enable the network to self heal given the inherent unreliable characteristic of these devices. The size constraints of the link layer protocol should also be considered. Network management should have little overhead, yet be powerful enough to control dense deployment of devices.
上記で触れたように、LoWPANs内のデバイスは、極めて大量に配備されることが期待されます。さらに、それらは限られた表示および入力機能を有することが期待されます。さらに、これらのデバイスのいくつかの場所では届きにくいかもしれません。したがって、LoWPANsで使用されるプロトコルは、最小構成を持っている必要があり、好ましくはブートストラップすることは容易で、「箱から出し」作業、およびこれらのデバイスの固有の信頼性の低い特性を与えヒール自己にネットワークを有効にします。リンク層プロトコルのサイズの制約も考慮すべきです。ネットワーク管理は、わずかなオーバーヘッドを持って、まだデバイスの高密度の展開を制御するために十分に強力でなければなりません。
LoWPANs require simple service discovery network protocols to discover, control and maintain services provided by devices. In some cases, especially in dense deployments, abstraction of several nodes to provide a service may be beneficial. In order to enable such features, new protocols may have to be designed.
LoWPANsは、発見制御およびデバイスが提供するサービスを維持するために、簡単なサービス発見ネットワークプロトコルが必要です。いくつかの場合において、特に稠密な展開において、サービスを提供する複数のノードの抽象化は有益であり得ます。このような機能を有効にするためには、新しいプロトコルを設計しなければならないことがあります。
IEEE 802.15.4 mandates link-layer security based on AES, but it omits any details about topics like bootstrapping, key management, and security at higher layers. Of course, a complete security solution for LoWPAN devices must consider application needs very carefully. Please refer to the security consideration section below for a more detailed discussion and in-depth security requirements.
IEEE 802.15.4義務付けリンク層のセキュリティはAESに基づいていますが、それは、より高い層では、ブートストラップ、キー管理、およびセキュリティなどのトピックについての詳細は省略します。もちろん、LoWPANデバイス用の完全なセキュリティソリューションは、非常に慎重にアプリケーションのニーズを考慮する必要があります。より詳細な議論については、以下のセキュリティ考慮セクションとの綿密なセキュリティ要件を参照してください。
The goals mentioned below are general and not limited to IETF activities. As such, they may not only refer to work that can be done within the IETF (e.g., specification required to transmit IP, profile of best practices for transmitting IP packets, and associated upper level protocols, etc). They also point at work more relevant to other standards bodies (e.g., desirable changes to or profiles relevant to IEEE 802.15.4, W3C, etc). When the goals fall under the IETF's purview, they serve to point out what those efforts should strive to accomplish, regardless of whether they are pursued within one (or more) new (or existing) working groups. When the goals do not fall under the purview of the IETF, documenting them here serves as input to other organizations [LIAISON].
下記の目標は、一般的であり、IETF活動に限定されません。そのようなものとして、それらは唯一IETF内で行うことができる仕事を参照しなくてもよい（例えば、指定IP、IPパケットを送信するためのベスト・プラクティス、および関連する上位レベルのプロトコルなどのプロファイルを送信するのに必要）。彼らはまた、職場で他の標準化団体（IEEE 802.15.4、W3Cに関連例えば、望ましい変更又はプロファイル等）に、より関連性の高いポイント。目標はIETFの範囲に該当するとき、彼らはそれらの努力にかかわらず、それらが1つ（またはそれ以上）の作業新しい（または既存の）グループ内で追求されているかどうかの、達成するために努力しなければならないものを指摘するのに役立ちます。目標がIETFの範囲に該当しない場合は、ここではそれらを文書化することは、他の組織[LIAISON]への入力として機能します。
Note that a common underlying goal is to reduce packet overhead, bandwidth consumption, processing requirements, and power consumption.
共通基盤となる目標は、パケットのオーバーヘッド、帯域幅の消費、処理要件、および消費電力を削減することであることに注意してください。
The following are the goals according to priority for LoWPANs:
以下はLoWPANsのための優先順位に従って目標です。
1. Fragmentation and Reassembly layer: As mentioned in the overview, the protocol data units may be as small as 81 bytes. 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 fragmentation and reassembly adaptation layer must be provided at the layer below IP.
1.断片化と再構成層：概要で述べたように、プロトコルデータユニットは81のバイトと同じくらい小さくてもよいです。これは、はるか1280オクテットの最小IPv6パケットサイズより明らかであり、IPv6仕様のセクション5 [RFC2460]に合わせて、断片化及び再アセンブリアダプテーション層はIPの下の層に提供されなければなりません。
2. Header Compression: Given that in the worst case the maximum size available for transmitting IP packets over an IEEE 802.15.4 frame is 81 octets, and that the IPv6 header is 40 octets long, (without optional headers), this leaves only 41 octets for upper-layer protocols, like UDP and TCP. UDP uses 8 octets in the header and TCP uses 20 octets. This leaves 33 octets for data over UDP and 21 octets for data over TCP. Additionally, as pointed above, there is also a need for a fragmentation and reassembly layer, which will use even more octets leaving very few octets for data. Thus, if one were to use the protocols as is, it would lead to excessive fragmentation and reassembly, even when data packets are just 10s of octets long. This points to the need for header compression. As there is much published and in-progress standardization work on header compression, the 6LoWPAN community needs to investigate using existing header compression techniques, and, if necessary, specify new ones.
2.ヘッダ圧縮：与えられた最悪の場合には（オプションヘッダなし）、IEEE 802.15.4フレーム上にIPパケットを送信するために利用可能な最大サイズが81個のオクテットであり、IPv6ヘッダは40オクテットの長さであることは、これが唯一の41を残すことUDPやTCPなどの上位層プロトコルのためのオクテット、。 UDPヘッダに8つのオクテットを使用し、TCPは、20個のオクテットを使用しています。これは、UDPおよびTCP上のデータのための21個のオクテットを超えるデータの33個のオクテットを残します。上記の指摘のようにまた、データのための非常に少数のオクテットを残し、さらにオクテットを使用する断片化と再組み立て層、も必要とされています。 1のようなプロトコルを使用した場合このように、それはデータパケットが長いだけ10Sオクテットの場合であっても、過度の断片化と再構築につながります。これは、ヘッダ圧縮の必要性を指します。ずっとそこに公開され、ヘッダー圧縮の進行中の標準化作業すると、6LoWPANコミュニティは、必要に応じて、新しいものを指定し、既存のヘッダー圧縮技術を使用して調査する必要があり、。
3. Address Autoconfiguration: [6LoWPAN] specifies methods for creating IPv6 stateless address auto configuration. Stateless auto configuration (as compared to stateful) is attractive for 6LoWPANs, because it reduces the configuration overhead on the hosts. There is a need for a method to generate an "interface identifier" from the EUI-64 [EUI64] assigned to the IEEE 802.15.4 device.
3.アドレス自動設定：[6LoWPAN]はIPv6ステートレスアドレス自動構成を作成するためのメソッドを指定します。それはホスト上の設定オーバーヘッドを減少させるため、（ステートフルと比較して）ステートレス自動構成は、6LoWPANsにとって魅力的です。 「インタフェース識別子」を生成するための方法が必要であるEUI64 [EUI64] IEEE 802.15.4デバイスに割り当てられました。
4. Mesh Routing Protocol: A routing protocol to support a multi-hop mesh network is necessary. There is much published work on ad-hoc multi hop routing for devices. Some examples include [RFC3561], [RFC3626], [RFC3684], all experimental. Also, these protocols are designed to use IP-based addresses that have large overheads. For example, the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] routing protocol uses 48 octets for a route request based on IPv6 addressing. Given the packet-size constraints, transmitting this packet without fragmentation and reassembly may be difficult. Thus, care should be taken when using existing routing protocols (or designing new ones) so that the routing packets fit within a single IEEE 802.15.4 frame.
前記メッシュルーティングプロトコル：マルチホップメッシュネットワークをサポートするためのルーティングプロトコルが必要です。デバイスのためのアドホックマルチホップルーティング上の多くの公表された研究があります。いくつかの例は、[RFC3561]、[RFC3626]、[RFC3684]、すべての実験が含まれます。また、これらのプロトコルには大きなオーバーヘッドを持っているIPベースのアドレスを使用するように設計されています。例えば、アドホックオンデマンド距離ベクトル（AODV）[RFC3561]ルーティングプロトコルは、IPv6アドレスに基づいてルート要求48個のオクテットを使用します。パケット・サイズの制約を考えると、断片化と再構築せずにこのパケットを送信することは難しいかもしれません。既存のルーティングプロトコルを使用して（または新しいものをデザインする）、ルーティングパケットは、単一のIEEE 802.15.4フレーム内に収まるようにする場合このように、注意が必要です。
5. Network Management: One of the points of transmitting IPv6 packets is to reuse existing protocols as much as possible. Network management functionality is critical for LoWPANs. However, management solutions need to meet the resource constraints as well as the minimal configuration and self-healing functionality described in Section 4.4. The Simple Network Management Protocol (SNMP) [RFC3410] is widely used for monitoring data sources and sensors in conventional networks. SNMP functionality may be translated "as is" to LoWPANs with the benefit to utilize existing tools. However, due to the memory, processing, and message size constraints, further investigation is required to determine if the use of SNMPv3 is suitable, or if an appropriate adaptation of SNMPv3 or use of different protocols is in order.
5.ネットワーク管理：IPv6パケットを送信するポイントの1つは、可能な限り既存のプロトコルを再利用することです。ネットワーク管理機能は、LoWPANsために重要です。ただし、管理ソリューションは、リソースの制約だけでなく、セクション4.4で説明した最小構成や自己修復機能を満たしている必要があります。簡易ネットワーク管理プロトコル（SNMP）[RFC3410]は広く、従来のネットワークにおいてデータ・ソースおよびセンサを監視するために使用されます。 SNMP機能は、既存のツールを利用する利点とLoWPANsに「そのまま」に翻訳することができます。しかしながら、メモリ、処理、およびメッセージサイズの制約のため、更なる調査がのSNMPv3の使用が適切である場合、またはSNMPv3の又は異なるプロトコルの使用の適切な適応が順序であるかどうかを決定する必要があります。
6. Implementation Considerations: It may be the case that transmitting IP over IEEE 802.15.4 would become more beneficial if implemented in a "certain" way. Accordingly, implementation considerations are to be documented.
6.実装に関する考慮事項：それは、「ある」の方法で実装されている場合、IEEE802.15.4上でIPを送信することは、より有益になる場合があり得ます。したがって、実装上の考慮事項は文書化されることになります。
7. Application and higher layer Considerations: As header compression becomes more prevalent, overall performance will depend even more on efficiency of application protocols. Heavyweight protocols based on XML such as SOAP [SOAP], may not be suitable for LoWPANs. As such, more compact encodings (and perhaps protocols) may become necessary. The goal here is to specify or suggest modifications to existing protocols so that they are suitable for LoWPANs. Furthermore, application level interoperability specifications may also become necessary in the future and may thus be specified.
7.アプリケーションおよび上位層の考慮：ヘッダ圧縮は、より一般的になるにつれて、全体的なパフォーマンスは、アプリケーションプロトコルの効率に一層依存するであろう。そのようなSOAP [SOAP]などのXMLに基づいてヘビープロトコルは、LoWPANsに適していないかもしれません。このように、よりコンパクトな符号化（およびおそらくプロトコル）が必要になることができます。ここでの目標は、彼らがLoWPANsに適しているように、既存のプロトコルへの変更を指定するか、または提案することです。また、アプリケーションレベルの相互運用性仕様はまた、将来的に必要になることがあり、したがって、指定されてもよいです。
8. Security Considerations: Security threats at different layers must be clearly understood and documented. Bootstrapping of devices into a secure network could also be considered given the location, limited display, high density, and ad-hoc deployment of devices.
8.セキュリティについての考慮事項：異なる層でのセキュリティ上の脅威が明確に理解し、文書化されなければなりません。セキュアネットワークへのデバイスのブートストラップはまた、位置、限られたディスプレイ、高密度、およびデバイスのアドホック展開を与え考えられます。
IPv6 over LoWPAN (6LoWPAN) applications often require confidentiality and integrity protection. This can be provided at the application, transport, network, and/or at the link layer (i.e., within the 6LoWPAN set of specifications). In all these cases, prevailing constraints will influence the choice of a particular protocol. Some of the more relevant constraints are small code size, low power operation, low complexity, and small bandwidth requirements.
LoWPAN以上のIPv6（6LoWPAN）アプリケーションは、多くの場合、機密性と完全性保護を必要としています。これは、アプリケーション、トランスポート、ネットワークに、及び/又は（すなわち、仕様の6LoWPANセット内の）リンク層で提供することができます。これらすべての例では、現行の制約は、特定のプロトコルの選択に影響を与えるだろう。より関連性の制約の中には、小さなコードサイズ、低電力動作、低複雑、かつ小さな帯域幅の要件です。
Given these constraints, first, a threat model for 6LoWPAN devices needs to be developed in order to weigh any risks against the cost of their mitigations while making meaningful assumptions and simplifications. Some examples for threats that should be considered are man-in-the-middle attacks and denial of service attacks.
これらの制約を考えると、まず、6LoWPANデバイス用の脅威モデルは、意味のある仮定して単純化しながら、その緩和策のコストに対するあらゆるリスクを比較検討するために開発する必要があります。考慮すべき脅威のためのいくつかの例は、man-in-the-middle攻撃やサービス拒否攻撃です。
A separate set of security considerations apply to bootstrapping a 6LoWPAN device into the network (e.g., for initial key establishment). This generally involves application level exchanges or out-of-band techniques for the initial key establishment, and may rely on application-specific trust models; thus, it is considered extraneous to 6LoWPAN and is not addressed in these specifications. In order to be able to select (or design) this next set of protocols, there needs to be a common model of the keying material created by the initial key establishment.
セキュリティ問題の別のセットは、ネットワーク（例えば、初期鍵確立のため）に6LoWPANデバイスをブートストラップに適用されます。これは、一般的に最初の鍵確立のためのアプリケーション・レベルの交換またはアウトオブバンド技術を含む、アプリケーション固有の信頼モデルに依存してもよいです。したがって、6LoWPANに余分とみなされ、これらの仕様で対処されていません。プロトコルのこの次のセット選択（または設計）することができるようにするために、最初の鍵の確立により作成された鍵材料の一般的なモデルが必要です。
Beyond initial key establishment, protocols for subsequent key management as well as to secure the data traffic do fall under the purview of 6LoWPAN. Here, the different alternatives (TLS, IKE/ IPsec, etc.) must be evaluated in light of the 6LoWPAN constraints.
初期鍵確立を超えて、データトラフィックを保護するために、後続のキー管理などのためのプロトコルは、6LoWPANの範囲に該当します。ここでは、異なる選択肢（TLS、IKE / IPsecの、など）は6LoWPAN制約に照らして評価されなければなりません。
One argument for using link layer security is that most IEEE 802.15.4 devices already have support for AES link-layer security. AES is a block cipher operating on blocks of fixed length, i.e., 128 bits. To encrypt longer messages, several modes of operation may be used. The earliest modes described, such as ECB, CBC, OFB and CFB provide only confidentiality, and this does not ensure message integrity. Other modes have been designed which ensure both confidentiality and message integrity, such as CCM* mode. 6LoWPAN networks can operate in any of the previous modes, but it is desirable to utilize the most secure modes available for link-layer security (e.g., CCM*), and build upon it.
リンク・レイヤ・セキュリティを使用するための1つの引数は、ほとんどのIEEE 802.15.4デバイスはすでにAESリンク層セキュリティのサポートを持っているということです。 AESは、固定長のブロック上で動作するブロック暗号、すなわち、128ビットです。長いメッセージを暗号化するには、いくつかの動作モードを使用することができます。このようECB、CBC、OFBとCFBとして説明した最も初期のモードは、唯一の機密性を提供し、これは、メッセージの完全性を保証するものではありません。他のモードは、CCMの*モードとして、機密性とメッセージの完全性の両方を保証するように設計されています。 6LoWPANネットワークは、以前のモードのいずれかで動作することができ、リンク・レイヤ・セキュリティ（例えば、CCMの*）のために利用可能な最も安全なモードを利用し、その上に構築することが望ましいです。
For network layer security, two models are applicable: end-to-end security, e.g., using IPsec transport mode, or security that is limited to the wireless portion of the network, e.g., using a security gateway and IPsec tunnel mode. The disadvantage of the latter is the larger header size, which is significant at the 6LoWPAN frame MTUs. To simplify 6LoWPAN implementations, it is beneficial to identify the relevant security model, and to identify a preferred set of cipher suites that are appropriate given the constraints.
ネットワーク層セキュリティのために、2つのモデルが適用される：エンドツーエンドのセキュリティ、例えば、セキュリティゲートウェイとのIPsecトンネルモードを使用して、例えば、ネットワークの無線部分に限定されるのIPsecトランスポート・モード、またはセキュリティを使用します。後者の欠点は、6LoWPANフレームのMTUに重要である、より大きなヘッダサイズです。 6LoWPAN実装を簡単にするために、関連するセキュリティモデルを識別するために、制約所与適切である暗号スイートの好ましいセットを識別するために有益です。
Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti, Brijesh Kumar, and Miguel Garcia for their comments and help in shaping this document.
彼らのコメントのためのジェフ・マリガン、Soohongダニエル・パーク、Samita Chakrabarti、Brijeshクマー、およびミゲル・ガルシアに感謝し、この文書を形成する上で役立ちます。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[IEEE802.15.4] IEEEコンピュータ学会、 "IEEE規格802.15.4-2003"、2003年10月。
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE, http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html.
、IEEE、http://standards.ieee.org/ regauth / OUI /チュートリアル/ EUI64.html [EUI64] "64ビットのグローバル識別子（EUI64）登録機関のためのガイドライン"。
[6LoWPAN] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[6LoWPAN]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、進歩、2005年5月での作業。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
[RFC3561]パーキンス、C.、ベルディング・ロイヤー、E.、およびS.ダス、 "アドホックオンデマンド距離ベクトル（AODV）ルーティング"、RFC 3561、2003年7月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626]クラウゼン、T.およびP.ジャケ、 "最適化されたリンクステートルーティングプロトコル（OLSR）"、RFC 3626、2003年10月。
[RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004.
"リバースパス転送（TBRPF）に基づいて、トポロジー普及" [RFC3684]オジェ、R.、テンプリン、F.、およびM.ルイス、RFC 3684、2004年2月。
[SOAP] "XML Protocol Working Group", W3C, http://www.w3c.org/2000/xp/Group/.
[SOAP] "XMLプロトコルワーキンググループ"、W3C、http://www.w3c.org/2000/xp/Group/。
[LIAISON] "IETF Liaison Activities", IETF, http://www.ietf.org/liaisonActivities.html.
[LIAISON] "IETFリエゾン活動"、IETF、http://www.ietf.org/liaisonActivities.html。
Authors' Addresses
著者のアドレス
Nandakishore Kushalnagar Intel Corp
なんだきしょれ くしゃｌながｒ いんてｌ こｒｐ
EMail: nandakishore.kushalnagar@intel.com
メールアドレス：nandakishore.kushalnagar@intel.com
Gabriel Montenegro Microsoft Corporation
ガブリエルモンテネグロマイクロソフト株式会社
EMail: gabriel.montenegro@microsoft.com
メールアドレス：gabriel.montenegro@microsoft.com
Christian Peter Pii Schumacher Danfoss A/S
クリスチャン・ピーターPIIシューマッハダンフォスA / S
EMail: schumacher@danfoss.com
メールアドレス：schumacher@danfoss.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。