RFC4919 日本語訳

Network Working Group                                     N. Kushalnagar
Request for Comments: 4919                                    Intel Corp
Category: Informational                                    G. Montenegro
                                                   Microsoft Corporation
                                                           C. Schumacher
                                                             Danfoss A/S
                                                             August 2007

Kushalnagarがコメントのために要求するワーキンググループN.をネットワークでつないでください: 4919年のインテルCorpカテゴリ: 情報のG.モンテネグロマイクロソフト社C.シューマッハDanfoss A/S2007年8月

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

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

このドキュメントはIEEE802.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

1. 序論…2 2. 概要…2 3. 仮定…3 4. 問題…4 4.1. IPの接続性…4 4.2. Topologies…5 4.3. 株式会社パケットサイズ…6 4.4. 構成と管理を制限します…6 4.5. 発見を修理してください…6 4.6. セキュリティ…6 5. 目標…7 6. セキュリティ問題…9 7. 承認…10 8. 参照…10 8.1. 標準の参照…10 8.2. 有益な参照…10

Kushalnagar, et al.          Informational                      [Page 1]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[1ページ]のRFC4919 6LoWPAN問題と目標2007年8月

1.  Introduction

1. 序論

   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]でIEEE802.15.4-2003規格に一致しているデバイスを包括します。 IEEE802.15.4台のデバイスが短距離の、そして、低ビット伝送速度、低パワー、および低価格によって特徴付けられます。 IEEE802.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の概要を与えて、彼らがどうIPと特にIPv6ネットワークの利益を得るかを説明します。 それは、あいさつがIP層と上記にある状態でLoWPAN要件について説明して、LoWPANsのためにIPの基本的な仮定について詳しく説明します。 最終的に、それは、デバイスがLoWPANにある状態でIPコミュニケーションを可能にすると関連している問題について説明して、最優先する方法でこれらを扱うために目標を定義します。 明白にすべてではなく、このリストの上の項目はIETFのための必ず適切なタスクであるかもしれません。 それにもかかわらず、それらは、より大きい問題の概要を与えるためにここに記録されます。 これは外部の組織と共に調整する方法を理解しているほうがよいほどともにまた、IETFの中の構造仕事の役に立ちます。

2.  Overview

2. 概要

   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はIEEE802.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の八重奏です。 リンクレイヤセキュリティはさらなるオーバーヘッドを課します。(最大の場合AES-CCM-32とAES-CCM-64のための9と(それぞれAES-CCM-128場合における、オーバーヘッドの21の八重奏対13)では、それは、81の八重奏をデータ・パケットに残します)。

   2.   Support for both 16-bit short or IEEE 64-bit extended media
        access control addresses.

2. 両方には、短いかIEEEの16ビットの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ギガヘルツ、915MHz、および868MHz)のための250キロビット毎秒、40キロビット毎秒、および20キロビット毎秒のデータ信号速度。

   4.   Topologies include star and mesh operation.

4. Topologiesは星を含んで、操作を網の目にかけます。

Kushalnagar, et al.          Informational                      [Page 2]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[2ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   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. 多くのデバイスが、技術の生涯配布されると予想しました。 この数が例えば、配布しているパーソナルコンピュータの数を小さくすると予想されます。

   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. LoWPANsの中のデバイスは、理由のバラエティーのために頼り無い傾向があります: 不確実なラジオの接続性、バッテリーの放電、デバイス留置所、物理的な改ざんなど

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

以下のセクションはLoWPANs、および特に6LoWPANs(IPv6を拠点とするLoWPANネットワーク)の仮定、問題声明、および目標について説明する際にこれらの特性を考慮に入れます。

3.  Assumptions

3. 仮定

   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はIEEE802.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の中でデバイスの限られた能力に基づいています。 デバイスが、より強力になって、より少ないパワーを消費するとき、前記のように要件のいくつかがいくらかリラックスするかもしれません。

Kushalnagar, et al.          Informational                      [Page 3]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[3ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   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接続を基本にしたネットワークに接続できます、翻訳ゲートウェイやプロキシのような中間的実体の必要性なしで。

4.  Problems

4. 問題

   Based on the characteristics defined in the overview section, the
   following sections elaborate on the main problems with IP for
   LoWPANs.

概要部で定義された特性に基づいて、以下のセクションはLoWPANsのためにIPに関する主な問題について詳しく説明します。

4.1.  IP Connectivity

4.1. 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によってよく満たされた大きいアドレス空間の必要性を引き起こします。

Kushalnagar, et al.          Informational                      [Page 4]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[4ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   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の限られたパケットサイズを考えて、そう望まれているなら、IEEE802.15.4のアドレスがIPv6アドレス形式によって包括されます。

   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のためのヘッダーと上の層を圧縮しなければなりません。

4.2.  Topologies

4.2. Topologies

   LoWPANs must support various topologies including mesh and star.

LoWPANsはメッシュを含む様々なtopologiesをサポートして、主演しなければなりません。

   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:

メッシュtopologiesは必要な目的地にマルチホップルーティングを含意します。 この場合、リンクのパケット混載業者が層にするとき(ルータとネットワーク層における同系の)、中間的デバイスは作動します。 通常これらはパワー、計算などに関して、より多くの能力がある「完全な機能デバイス」です。 ルーティング・プロトコルに関する要件は以下の通りです。

   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.

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. ネットワークには、FFDsかRFDsのどちらかがバッテリーかメインによる動力付きであるかもしれないtopologiesをサポートしてください。 これは眠っているノードがあるときルーティングのために適切な問題を含意します。

   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.

メッシュtopologiesのように、星のtopologiesは、パケット推進の機能性でデバイスの部分集合に食糧を供給するのを含んでいます。 IEEEに加えた802.15、.4、目標はこれらのデバイスが他の種類のイーサネットかIEEE802.11などのネットワーク・インターフェースを使用して、シームレスにそれらの異なった技術の上に造られたネットワークを統合することです。 これはもちろん初めにIPを使用するプライマリ動機です。

Kushalnagar, et al.          Informational                      [Page 5]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[5ページ]のRFC4919 6LoWPAN問題と目標2007年8月

4.3.  Limited Packet Size

4.3. 株式会社パケットサイズ

   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フレームの中に合います。 これらの系列に沿って、IPv6のサブIP再アセンブリ(セクション5を見る)の要件は十分なRAMを持っていないローエンドLoWPANデバイスのための挑戦か1280八重奏のパケットのためのストレージを引き起こすかもしれません。

4.4.  Limited Configuration and Management

4.4. 株式会社構成と管理

   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で使用されるプロトコルは最小量の構成を持つべきであり、望ましくは、「創造的に」働いてください、そして、これらのデバイスの固有の頼り無い特性を考えて、独力で進んで、可能にする小休止が自己へのネットワークであったなら回復してください。 また、リンクレイヤプロトコルのサイズ規制は考えられるべきです。 ネットワークマネージメントは、ほとんどオーバーヘッドを持っていませんが、デバイスの濃い展開を制御するほど強力であるはずです。

4.5.  Service Discovery

4.5. サービス発見

   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は、デバイスによって提供されたサービスを発見して、制御して、維持するために簡単なサービス発見ネットワーク・プロトコルを必要とします。 いくつかの場合、特に濃い展開では、サービスを提供するいくつかのノードの抽象化は有益であるかもしれません。 そのような特徴を可能にするために、新しいプロトコルは設計されなければならないかもしれません。

4.6.  Security

4.6. セキュリティ

   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.

リンクレイヤセキュリティがAESに基礎づけたIEEE802.15.4の命令、それだけが、より高い層でブートストラップ法、かぎ管理、およびセキュリティのような話題に関するどんな詳細も省略します。 もちろん、LoWPANデバイスのための完全なセキュリティソリューションは非常に慎重にアプリケーションの必要性を考えなければなりません。 より詳細な議論と深さのセキュリティ要件の下の警備上の配慮部を参照してください。

Kushalnagar, et al.          Informational                      [Page 6]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[6ページ]のRFC4919 6LoWPAN問題と目標2007年8月

5.  Goals

5. 目標

   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. 断片化とReassemblyは層にします: 概要で言及されるように、プロトコルデータ単位は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. ヘッダー圧縮: そんなに最悪の場合にはIEEE802.15の上にIPパケットを伝えるのに有効な最大サイズを考えて、.4フレームが81の八重奏であり、IPv6ヘッダーが長い間40の八重奏である、(任意のヘッダーのない)、これは上側の層のプロトコルに41の八重奏だけを残します、UDPとTCPのように。 UDPはヘッダーの8つの八重奏を使用します、そして、TCPは20の八重奏を使用します。 これはUDPの上のデータと21のための33の八重奏をTCPの上のデータのための八重奏に残します。 さらに、断片化と再アセンブリ層の必要も上に指されるようにあります。(データのためのほんのわずかな八重奏を残して、層はさらに多くの八重奏を使用するでしょう)。 したがって、1つがそのままでプロトコルを使用するなら、それは長い間、過度の断片化といつデータ・パケットが八重奏でただ10年代になりさえあるかまで導くでしょうに。 これはヘッダー圧縮の必要性を示します。 ヘッダー圧縮に対するたくさん発行されて、進行中の標準化仕事があって、6LoWPAN共同体は、既存のヘッダー圧縮のテクニックを使用することで調査して、必要なら、新しいものを指定する必要があります。

Kushalnagar, et al.          Informational                      [Page 7]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[7ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   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に、状態がない自動構成(statefulするように比べて)は魅力的です。 [EUI64]が割り当てたEUI-64からIEEE802.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.

4. ルーティング・プロトコルを網の目にかけてください: マルチホップが網目状ネットワークであるとサポートするルーティング・プロトコルが必要です。 デバイスのための広告hocマルチホップルーティングに対する仕事はたくさん発行されます。 いくつかの例がすべて実験的に[RFC3561]、[RFC3626]、[RFC3684]を含んでいます。 また、これらのプロトコルは、大きいオーバーヘッドを持っているIPベースのアドレスを使用するように設計されています。 例えば、Ad hoc On-要求Distance Vector(AODV)[RFC3561]ルーティング・プロトコルはIPv6アドレシングに基づくルート要求に48の八重奏を使用します。 パケットサイズ規制を考えて、断片化と再アセンブリなしでこのパケットを伝えるのは難しいかもしれません。 既存のルーティング・プロトコルを使用するとき(新しいものを設計して)、したがって、注意するべきであるので、ルーティングパケットは単一のIEEE802.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で説明された自己の治療の機能性を満たす必要があります。 Simple Network Managementプロトコル(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. 実装問題: それがIEEEの上のケースのそんなに伝わっているIPであるかもしれない、802.15、.4、「ある」方法で実装されるなら、より有益になるでしょう。 それに従って、実装問題は記録されることです。

   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

7. アプリケーションと、より高い層のConsiderations: ヘッダー圧縮が、より一般的になるとき、総合的な性能はさらにアプリケーション・プロトコルの効率にさえ依存するでしょう。 SOAP[SOAP]などのXMLに基づくヘビー級のプロトコルはLoWPANsに適当でないかもしれません。 そういうものとして、よりコンパクトなencodings(そして、恐らくプロトコル)は必要になるかもしれません。 ここの目標がしたがって、既存のプロトコルへの変更を指定するか、または示すことである、それ

Kushalnagar, et al.          Informational                      [Page 8]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[8ページ]のRFC4919 6LoWPAN問題と目標2007年8月

       they are suitable for LoWPANs.  Furthermore, application level
       interoperability specifications may also become necessary in the
       future and may thus be specified.

それらは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. セキュリティ問題: 異なった層の軍事的脅威を明確に理解されて、記録しなければなりません。 また、位置を考えて、安全なネットワークへのデバイスのブートストラップ法を考えることができました、限られたディスプレイ、デバイスの高密度の、そして、臨時の展開。

6.  Security Considerations

6. セキュリティ問題

   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

リンクレイヤセキュリティを使用して、それはほとんどのIEEEです。1つの議論、802.15台の.4デバイスがAESのためにリンクレイヤがセキュリティであると既にサポートさせます。 AESはすなわちブロックの固定長を128ビット作動させるブロック暗号です。 より長いメッセージを暗号化するために、いくつかの運転モードが使用されるかもしれません。 ECBなどのように説明される中で最も前のモード、CBC、OFB、およびCFBは秘密性だけを提供します、そして、これはメッセージの保全を確実にしません。 そして両方に秘密性を確実にする他のモードが設計されている。

Kushalnagar, et al.          Informational                      [Page 9]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[9ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   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.

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フレームMTUsで重要です)。 6LoWPAN実装を簡素化するために、関連機密保護モデルを特定して、都合のよいセットの規制を考えて、適切な暗号スイートを特定するのは有益です。

7.  Acknowledgements

7. 承認

   Thanks to Geoff Mulligan, Soohong Daniel Park, Samita Chakrabarti,
   Brijesh Kumar, and Miguel Garcia for their comments and help in
   shaping this document.

彼らのコメントをジェフMulligan、SoohongダニエルPark、Samita Chakrabarti、Brijeshクマー、およびミゲル・ガルシアをありがとうございます、このドキュメントを形成するのを手伝ってください。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

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

   [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。」

8.2.  Informative References

8.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。

   [6LoWPAN]      Thomson, S., Narten, T., and T. Jinmei, "IPv6
                  Stateless Address Autoconfiguration", Work in
                  Progress, May 2005.

仕事進行中のS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」という[6LoWPAN]トムソンは、2005がそうするかもしれません。

   [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)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。

Kushalnagar, et al.          Informational                     [Page 10]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[10ページ]のRFC4919 6LoWPAN問題と目標2007年8月

   [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.ダス、「臨時のOn-要求Distance Vector(AODV)ルート設定」、RFC3561、2003年7月。

   [RFC3626]      Clausen, T. and P. Jacquet, "Optimized Link State
                  Routing Protocol (OLSR)", RFC 3626, October 2003.

[RFC3626] クローゼンとT.とP.ジャケ、「最適化されたリンク州のルーティング・プロトコル(OLSR)」、RFC3626、2003年10月。

   [RFC3684]      Ogier, R., Templin, F., and M. Lewis, "Topology
                  Dissemination Based on Reverse-Path Forwarding
                  (TBRPF)", RFC 3684, February 2004.

[RFC3684]オジェ、R.、テンプリン、F.、およびM.ルイス、「逆経路推進(TBRPF)に基づくトポロジー普及」、RFC3684、2004年2月。

   [SOAP]         "XML Protocol Working Group", W3C,
                  http://www.w3c.org/2000/xp/Group/.

[石鹸]「XMLプロトコル作業部会」、W3C、 http://www.w3c.org/2000/xp/Group/ 。

   [LIAISON]      "IETF Liaison Activities", IETF,
                  http://www.ietf.org/liaisonActivities.html.

[連絡]「IETF連絡活動」、IETF、 http://www.ietf.org/liaisonActivities.html 。

Authors' Addresses

作者のアドレス

   Nandakishore Kushalnagar
   Intel Corp

Nandakishore Kushalnagarインテル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シューマッハDanfoss A/S

   EMail: schumacher@danfoss.com

メール: schumacher@danfoss.com

Kushalnagar, et al.          Informational                     [Page 11]

RFC 4919               6LoWPAN Problems and Goals            August 2007

Kushalnagar、他 情報[11ページ]のRFC4919 6LoWPAN問題と目標2007年8月

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に情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Kushalnagar, et al.          Informational                     [Page 12]

Kushalnagar、他 情報[12ページ]