[要約] RFC 4919は、6LoWPAN（Low-Power Wireless Personal Area Networks）におけるIPv6の概要、前提条件、問題の説明、および目標を提供しています。このRFCの目的は、低電力ワイヤレスネットワークでのIPv6の実装と利用を促進することです。
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
低電力ワイヤレスパーソナルエリアネットワーク（6lowpans）を超えるIPv6：概要、仮定、問題声明、および目標
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）The IETF Trust（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.
低電力のワイヤレスパーソナルエリアネットワーク（ローパン）は、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.
このドキュメントは、ローパンの概要を示し、それらがIP、特にIPv6ネットワーキングからどのように利益を得るかを説明します。IPレイヤーと上記に関するローパンの要件について説明し、ローパンのIPの根本的な仮定を詳しく説明しています。最後に、ローパン内のデバイスとの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].
ローパンは、電力が限られており、スループット要件がリラックスしたアプリケーションでワイヤレス接続を可能にする単純な低コスト通信ネットワークです。ローパンには通常、物理環境を実際のアプリケーション、たとえばワイヤレスセンサーに接続するために連携するデバイスが含まれます。ローパンはIEEE 802.15.4-2003標準に準拠しています[IEEE802.15.4]。
Some of the characteristics of LoWPANs are as follows:
ローパンの特性のいくつかは次のとおりです。
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オクテットです。リンク層のセキュリティはさらにオーバーヘッドを課します。これは、最大の場合（AES-CCM-128ケースのオーバーヘッド21オクテット、それぞれAES-CCM-32およびAES-CCM-64で9および13）に81オクテットを残します。データパケット用。
2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses.
2. 16ビットショートまたはIEEE 64ビットの両方の拡張メディアアクセスコントロールアドレスのサポート。
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 GHz、915 MHz、および868 MHz）の各250 kbps、40 kbps、および20 kbpsのデータレート。
4. Topologies include star and mesh operation.
4. トポロジには、星とメッシュの操作が含まれます。
5. Low power. Typically, some or all devices are battery operated.
5. 低電力。通常、一部またはすべてのデバイスはバッテリーで動作します。
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. テクノロジーの存続期間中に展開されると予想される多数のデバイス。この数は、たとえば、展開されたパーソナルコンピューターの数をwarっていると予想されます。
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.
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. 多くの環境では、ローパンに接続されたデバイスは、エネルギーを節約するために長期間眠ることがあり、これらの睡眠期間中に通信できません。
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（IPv6ベースのローパンネットワーク）の仮定、問題の声明、および目標を説明します。
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, 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.
このドキュメントで説明されているように、ローパンは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.
これらの仮定のいくつかは、ローパン内のデバイスの限られた機能に基づいています。デバイスがより強力になり、消費電力が少なくなるにつれて、上記の要件の一部は多少緩和される可能性があります。
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.
一部のローパンデバイスは非常に限られていると予想されますが（いわゆる「機能デバイスの削減」またはRFDS）、より少ない数字ではありますが、より有能な「フル機能デバイス」（FFD）も存在します。FFDは通常、より多くのリソースを持ち、メイン駆動型である可能性があります。したがって、FFDは、ネットワーク調整、パケット転送、他のタイプのネットワークとのインターフェースなどの機能を提供することにより、RFDを支援します。
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.
概要セクションで定義されている特性に基づいて、次のセクションでは、ローパンのIPの主な問題について詳しく説明します。
The requirement for IP connectivity within a LoWPAN is driven by the following:
ローパン内のIP接続の要件は、以下によって駆動されます。
1. The many devices in a LoWPAN make network auto configuration and statelessness highly desirable. And for this, IPv6 has ready solutions.
1. ローパンの多くのデバイスは、ネットワークの自動構成とステートレス性を非常に望ましいものにします。このため、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. ローパンのパケットサイズが限られていることを考えると、IPv6アドレス形式では、必要に応じてIEEE 802.15.4アドレスを包含できます。
4. Simple interconnectivity to other IP networks including the Internet.
4. インターネットを含む他のIPネットワークとの単純な相互接続性。
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.
ローパンは、メッシュやスターなどのさまざまなトポロジをサポートする必要があります。
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. ローパンの最小限のパケットサイズを考えると、ルーティングプロトコルは、ホップの数とは無関係に、データパケットに低い（またはNO）オーバーヘッドを課す必要があります。
2. The routing protocols should have low routing overhead (low chattiness) balanced with topology changes and power conservation.
2. ルーティングプロトコルは、トポロジの変更と発電の保存とバランスが取れているルーティングオーバーヘッド（低いおしゃべり）を持つ必要があります。
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.
3. ルーティングプロトコルの計算およびメモリの要件は、低コストと低電力の目標を満たすために最小限でなければなりません。したがって、大規模なルーティングテーブルの保管とメンテナンスは有害です。
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.
4. FFDまたはRFDのいずれかがバッテリーまたはメイン駆動型である可能性があるネットワークトポロジのサポート。これは、睡眠ノードの存在下でのルーティングに関する適切な考慮事項を意味します。
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.
メッシュトポロジと同様に、Starトポロジには、パケット転送機能を備えたデバイスのサブセットのプロビジョニングが含まれます。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.
ローパン内のアプリケーションは、小さなパケットを発信すると予想されます。IP接続のためにすべてのレイヤーを追加すると、過度の断片化と再組み立てが発生することなく、1つのフレームに送信が可能になります。さらに、個々の「コントロール/プロトコルパケット」が単一の802.15.4フレーム内に収まるように、プロトコルを設計または選択する必要があります。これらの線に沿って、IPv6のサブIP再組み立ての要件（セクション5を参照）は、1280オクテットパケットに十分なRAMまたはストレージを持っていないローエンドローパンデバイスに課題をもたらす可能性があります。
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 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.
ローパンでは、デバイスが提供するサービスを発見、制御、および保守するために、簡単なサービスディスカバリーネットワークプロトコルが必要です。場合によっては、特に密集した展開では、サービスを提供するためのいくつかのノードの抽象化が有益です。このような機能を有効にするには、新しいプロトコルを設計する必要がある場合があります。
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に基づいてリンク層セキュリティを義務付けていますが、高レイヤーでのブートストラップ、キー管理、セキュリティなどのトピックに関する詳細は省略されています。もちろん、ローパンデバイスの完全なセキュリティソリューションは、アプリケーションのニーズを非常に慎重に考慮する必要があります。より詳細な議論と詳細なセキュリティ要件については、以下のセキュリティ対価セクションを参照してください。
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:
以下は、ローパンの優先度に応じた目標です。
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上のデータの場合は33オクテット、TCP上のデータには21オクテットが残ります。さらに、上記のように、断片化と再組み立て層の必要性もあります。これにより、さらに多くのオクテットがデータ用のオクテットがほとんど残っていません。したがって、データパケットが10オクテットの長さであっても、プロトコルをそのまま使用する場合、過度の断片化と再組み立てにつながります。これは、ヘッダー圧縮の必要性を示しています。ヘッダー圧縮に関する多くの公開および進行中の標準化作業があるため、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. アドレスAutoconfiguration：[6lowpan] IPv6 Statelessアドレス自動構成を作成する方法を指定します。ステートレス自動構成（Statefulと比較して）は、ホストの構成オーバーヘッドを削減するため、6lowpansにとって魅力的です。IEEE 802.15.4デバイスに割り当てられたEUI-64 [EUI64]から「インターフェイス識別子」を生成する方法が必要です。
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.
4. メッシュルーティングプロトコル：マルチホップメッシュネットワークをサポートするルーティングプロトコルが必要です。デバイス用のアドホックマルチホップルーティングに関する多くの公開作業があります。いくつかの例には、[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つは、既存のプロトコルを可能な限り再利用することです。ネットワーク管理機能は、ローパンにとって重要です。ただし、管理ソリューションは、リソースの制約と、セクション4.4で説明されている最小構成と自己修復機能を満たす必要があります。シンプルなネットワーク管理プロトコル（SNMP）[RFC3410]は、従来のネットワークのデータソースとセンサーの監視に広く使用されています。SNMP機能は、既存のツールを利用するために利益のあるローパンに「現状のまま」翻訳される場合があります。ただし、メモリ、処理、およびメッセージサイズの制約により、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. 実装の考慮事項：IEEE 802.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に基づくヘビー級プロトコルは、ローパンには適していない場合があります。そのため、よりコンパクトなエンコーディング（およびおそらくプロトコル）が必要になる場合があります。ここでの目標は、既存のプロトコルを指定または提案して、ローパンに適していることです。さらに、アプリケーションレベルの相互運用性仕様も将来必要になる場合があるため、指定される場合があります。
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（6lowpan）を超えるIPv6アプリケーションは、多くの場合、機密性と整合性の保護が必要です。これは、アプリケーション、トランスポート、ネットワーク、および/またはリンクレイヤー（つまり、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デバイスの脅威モデルを開発する必要があります。考慮すべき脅威のいくつかの例は、中間の攻撃とサービス攻撃の拒否です。
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の範囲に該当します。ここでは、6lowpanの制約に照らして、さまざまな代替案（TLS、IKE/ IPSECなど）を評価する必要があります。
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.
Geoff Mulligan、Soohong Daniel Park、Samita Chakrabarti、Brijesh Kumar、Miguel Garciaのコメントとこの文書の形成に感謝します。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、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 Computer Society、「IEEEStd。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.
[EUI64]「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、IEEE、http：//standards.ieeee.org/ regauth/oui/tutorials/eui64.html。
[6LoWPAN] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[6Lowpan] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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] Harrington、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] Perkins、C.、Belding-Royer、E。、およびS. Das、「アドホックオンデマンド距離ベクトル（AODV）ルーティング」、RFC 3561、2003年7月。
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
[RFC3626] Clausen、T。およびP. Jacquet、「最適化されたリンク状態ルーティングプロトコル（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.
[RFC3684] Ogier、R.、Templin、F。、およびM. Lewis、「逆パス転送に基づくトポロジ普及（TBRPF）」、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 liaison activity"、ietf、http://www.ietf.org/liaisonactivities.html。
Authors' Addresses
著者のアドレス
Nandakishore Kushalnagar Intel Corp
Nandakishore Kushalnagar Intel Corp
EMail: nandakishore.kushalnagar@intel.com
Gabriel Montenegro Microsoft Corporation
ガブリエルモンテネグロマイクロソフトコーポレーション
EMail: gabriel.montenegro@microsoft.com
Christian Peter Pii Schumacher Danfoss A/S
クリスチャン・ピーター・ピイ・シューマッハ・ダンフォスA/s
EMail: schumacher@danfoss.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。