Network Working Group S. Krishnan, Ed.
Request for Comments: 4957 Ericsson Research
Category: Informational N. Montavont
GET ENST Bretagne
E. Njedjou
France Telecom
S. Veerepalli
Qualcomm
A. Yegin, Ed.
Samsung
August 2007
Link-Layer Event Notifications for Detecting Network Attachments
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
抽象
Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies.
特定のネットワークアクセス技術は、IPへのリンク層のステータスの各種情報を提供することが可能です。リンク層イベント通知は、IPが迅速に設定の変更を検出することができます。この文書では、よく知られているアクセス技術から入手可能な情報の非網羅的なカタログを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Link-Layer Event Notifications . . . . . . . . . . . . . . . . 5
3.1. GPRS/3GPP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. cdma2000/3GPP2 . . . . . . . . . . . . . . . . . . . . . . 7
3.3. IEEE 802.11/WiFi . . . . . . . . . . . . . . . . . . . . . 8
3.4. IEEE 802.3 CSMA/CD . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Link Integrity Tests in 802.3 Networks . . . . . . . . 10
3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer
Event Notifications . . . . . . . . . . . . . . . . . 11
3.4.3. 802.1AB Link-Layer Discovery Protocol . . . . . . . . 12
3.4.4. Other Heuristics . . . . . . . . . . . . . . . . . . . 13
3.4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
It is not an uncommon occurrence for a node to change its point of attachment to the network. This can happen due to mobile usage (e.g., a mobile phone moving among base stations) or nomadic usage (e.g., road-warrior case).
これは、ノードがネットワークへの接続点を変更するための珍しい発生しません。これは、モバイル使用（例えば、基地局間を移動する携帯電話）またはノマディック使用（例えば、道路戦士の場合）に起こることができます。
A node changing its point of attachment to the network may end up changing its IP subnet and therefore require reconfiguration of IP-layer parameters, such as IP address, default gateway information, and DNS server address. Detecting the subnet change can usually use network-layer indications (such as a change in the advertised prefixes for IPv6). But such indications may not be always available (e.g., Detecting Network Attachment in IPv6 (DNAv6)) to the node upon changing its point of attachment.
ネットワークへの接続点を変更するノードは、そのIPサブネットを変更終わる、従って、IPアドレス、デフォルトゲートウェイ情報、およびDNSサーバアドレスとしてIPレイヤパラメータの再設定を必要とし得ます。サブネットの変化を検出することは、通常、（例えばIPv6のアドバタイズされたプレフィクスの変化のような）ネットワーク層指示を使用することができます。そのような表示は常に利用可能ではないかもしれない（例えば、IPv6の（DNAv6）で検出ネットワーク接続）接続点を変更する際のノード。
Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalog of information available from some access technologies, and discusses the interpretation of this information at the IP layer. This document is not intended to specify or change the behavior of these access technologies in any manner.
リンク層イベント通知は、IPが迅速に設定の変更を検出することができます。この文書では、いくつかのアクセス技術から入手可能な情報の非網羅的なカタログを提供し、IP層でのこの情報の解釈について説明します。この文書は、指定するか、またはいずれかの方法でこれらのアクセス技術の動作を変更するものではありません。
Additional information can be conveyed along with the event, such as the identifier of the network attachment point (e.g., IEEE 802.11 Basic Service Set Identification (BSSID) and Service Set Identifier (SSID)), or network-layer configuration parameters obtained via the link-layer attachment process if available. It is envisaged that such event notifications can in certain circumstances be used to expedite the inter-subnet movement detection and reconfiguration process. For example, the notification indicating that the node has established a new link-layer connection may be used for immediately probing the network for a possible configuration change. In the absence of such a notification from the link layer, IP has to wait for indications that are not immediately available, such as receipt of the next scheduled router advertisement, unreachability of the default gateway, etc.
追加情報は、ネットワーク接続ポイント（例えば、IEEE 802.11基本サービスセット識別（BSSID）とサービスセット識別子（SSID））、またはリンクを介して得られたネットワーク層構成パラメータの識別子として、イベントと一緒に搬送することができます利用可能な場合-layer付着プロセス。そのようなイベント通知は、特定の状況ではサブネット間動き検出及び再構成プロセスを促進するために使用できることが想定されます。例えば、ノードが新しいリンク層接続を確立したことを示す通知が直ちに可能な構成変更のためのネットワークを探索するために使用することができます。リンク層から、このような通知がない場合には、IPは、など次のスケジュールされたルータ広告を受信し、デフォルトゲートウェイの到達不能としてすぐに利用できないの適応症、待たなければなりません
It should be noted that a link-layer event notification does not always translate into a subnet change. Even if the node has torn down a link-layer connection with one attachment point and established a new connection with another, it may still be attached to the same IP subnet. For example, several IEEE 802.11 access points can be attached to the same IP subnet. Moving among these access points does not warrant any IP-layer configuration change.
リンク層イベント通知は、常にサブネット変更に変換されないことに留意すべきです。ノードは、1つの取付け点とのリンク層接続を解体し、互いの新たな接続を確立したとしても、それはまだ、同じIPサブネットに取り付けられてもよいです。例えば、いくつかのIEEE 802.11アクセスポイントは、同じIPサブネットに取り付けることができます。これらのアクセスポイント間で移動すると、任意のIP-層構成の変更を保証するものではありません。
In order to enable an enhanced scheme for detecting change of subnet, we need to define link-layer event notifications that can be realistically expected from various access technologies. The objective of this document is to provide a catalogue of link-layer events and notifications in various architectures. While this document mentions the utility of this information for detecting change of subnet (or, detecting network attachment - DNA), the detailed usage is left to other documents, namely, DNA solution specifications.
サブネットの変更を検出するための強化スキームを有効にするために、我々は現実的に、様々なアクセス技術から期待できるリンク層イベント通知を定義する必要があります。このドキュメントの目的は、様々なアーキテクチャにおけるリンク層イベントと通知のカタログを提供することです。この文書は、サブネットの変化（又は、ネットワーク接続検出 - DNA）を検出するためにこの情報の有用性に言及しながら、詳細な使用方法は、他のドキュメント、即ち、DNA溶液の仕様に任されています。
The document limits itself to the minimum set of information that is necessary for solving the DNA problem [RFC4135]. A broader set of information (e.g., signal strength, packet loss, etc.) and events (e.g. link down) may be used for other problem spaces, such as anticipation-based Mobile IP fast handovers [RFC4881], [RFC4068], etc.
文書は、DNAの問題[RFC4135]を解くために必要な情報の最小セットに自分自身を制限します。より広範な情報の組（例えば、信号強度、パケット損失）とイベント（例えば、ダウンリンク）は、予想ベースのモバイルIP高速ハンドオーバ[RFC4881]、[RFC4068]などのような他の問題空間に使用することができます。
These event notifications are considered with hosts in mind, although they may also be available on the network side (e.g., on the access points and routers). An API or protocol-based standard interface may be defined between the link layer and IP for conveying this information. That activity is beyond the scope of this document.
それらはまた、ネットワーク側で利用可能であってもよいが、これらのイベント通知は、（例えば、アクセスポイントおよびルータで、）、心の中でホストと考えられています。 APIまたはプロトコルベースの標準インターフェースは、この情報を搬送するためリンクレイヤとIPとの間に画定されてもよいです。その活動は、このドキュメントの範囲を超えています。
Link: is a communication facility or medium over which network nodes can communicate. Each link is associated with a minimum of two endpoints. An "attachment point" is the link endpoint on the link to which the node is currently connected, such as an access point, a base station, or a wired switch.
リンク：ネットワークノードが通信することができる上に通信設備又は媒体です。各リンクは、2つのエンドポイントの最小値と関連しています。 「接続ポイント」は、アクセスポイント、基地局、又は有線スイッチのようなノードが現在接続されているリンク上のリンクのエンドポイントです。
Link up: is an event provided by the link layer that signifies a state change associated with the interface becoming capable of communicating data packets. This event is associated with a link-layer connection between the node and an attachment point.
アップリンク：インターフェースは、データパケットを通信することが可能になっに関連する状態変化を意味するリンク層により提供されるイベントです。このイベントは、ノードと取付点との間のリンク層接続に関連付けられています。
BSSID: Basic Service Set Identification
BSSID：基本サービスセットの識別
DNA: Detecting Network Attachment
DNA：ネットワーク接続検出
GPRS: General Packet Radio Service
GPRS：汎用パケット無線サービス
PDP: Packet Data Protocol
PDP：パケットデータプロトコル
SSID: Service Set Identifier
SSID：サービスセット識別子
Link-layer event notifications are considered to be one of the inputs to the DNA process. A DNA process is likely to take other inputs (e.g., presence of advertised prefixes, reachability of default gateways) before determining whether IP-layer configuration must be updated. It is expected that the DNA process can take advantage of link-layer notifications when they are made available to IP. While by itself a link-layer notification may not constitute all the input DNA needs, it can at least be useful for prompting the DNA process to collect further information (i.e., other inputs to the process). For example, the node may send a router solicitation as soon as it learns that a new link-layer connection is established.
リンク層イベント通知は、DNAプロセスへの入力の一つであると考えられています。 DNAプロセスは、他の入力を取る可能性がある（例えば、広告された接頭辞、デフォルトゲートウェイの到達可能性の有無）IP層構成を更新する必要があるかどうかを決定する前に。彼らはIPに提供されるときDNAプロセスは、リンク層通知を利用できることが期待されます。自身がリンク層通知は、すべての入力DNAニーズを構成するものではないが、それは、少なくともさらに情報（プロセスに、すなわち他の入力）を収集するためにDNAの処理を促すために有用であり得ます。例えば、ノードは、すぐにそれが新しいリンク層接続が確立されていることを学習しながら、ルータ要請を送信することができます。
The link-layer event that is considered most useful to DNA process is the link up event. The associated notifications can be provided to the IP-layer after the event concludes successfully. The link up events and notifications are associated with a network interface on the node. The IP module may receive simultaneous independent notifications from each one of the network interfaces on the node.
DNAプロセスに最も有用であると考えられるリンク層イベントは、リンクアップイベントです。イベントが正常に終了した後に関連する通知はIP層に提供することができます。リンクアップイベントと通知は、ノード上のネットワークインターフェイスに関連付けられています。 IPモジュールは、ノード上のネットワークインターフェースのそれぞれからの同時独立通知を受信することができます。
The actual event is managed by the link layer of the node through execution of link-layer protocols and mechanisms. Once the event successfully completes within the link layer, its notification is delivered to the IP-layer. By the time the notification is delivered, the link layer of the node must be ready to accept IP packets from the IP and the physical layers. Each time an interface changes its point of attachment, a link up event should be generated.
実際のイベントは、リンク層プロトコルおよびメカニズムを実行することにより、ノードのリンク層によって管理されています。イベントが正常にリンク層の中に完了すると、その通知は、IP層に配信されます。通知が配信される時までに、ノードのリンク層はIP層と物理層からIPパケットを受け入れる準備ができなければなりません。インターフェースは、接続点を変更するたびに、リンクアップイベントが生成されなければなりません。
There is a non-deterministic usage of the link up notification to accommodate implementations that desire to indicate the link is up, but the data transmission may be blocked in the network (see IEEE 802.3 discussion). A link up notification may be generated with an appropriate attribute, conveying its non-deterministic nature, to convey the event. Alternatively, the link-layer implementation may choose to delay the link up notification until the risk conditions cease to exist.
そこにリンクがアップであることを示すことを望む実装に対応するために、リンクアップ通知の非決定論的用法であるが、データ伝送ネットワークでブロックされてもよい（IEEE 802.3議論を参照されたいです）。リンクアップ通知がイベントを伝えるために、その非決定論的な性質を運ぶ、適切な属性を生成することができます。また、リンク層の実装はリスク条件が存在しなくなるまでリンクアップ通知を遅らせるように選択することができます。
If a non-deterministic link up was generated, another link up must follow as soon as the link layer is capable of generating a deterministic notification. The event attributes may indicate whether the packets transmitted since the previous notification were presumed to be blocked or allowed by the network, if the link layer could determine the exact conditions.
非決定論的リンクアップが生成された場合は、別のリンクアップ、リンク層は、確定通知を生成することが可能であるとすぐに従わなければなりません。イベント属性は、リンク層は、正確な条件を決定することができる場合は、前の通知以降送信されたパケットは、ネットワークによってブロックまたは許可することが推定されたかどうかを示すことができます。
The deterministic link up event following a non-deterministic link up event can be treated differently by consumers of the link up event. For example, the second link up event need not trigger a confirmation process, if the first one already did.
非決定論的リンクアップイベントの確定リンクアップイベント、リンクアップイベントの消費者によって異なって処理することができます。例えば、第2のリンクアップイベント最初のものはすでになかった場合、確認処理をトリガする必要はありません。
A node may have to change its IP-layer configuration even when the link-layer connection stays the same. An example scenario is the IPv6 subnet renumbering [RFC2461]. Therefore, there exist cases where IP-layer configuration may have to change even without the IP layer receiving a link up notification. Therefore, a link-layer notification is not a mandatory indication of a subnet change.
ノードは、リンク層の接続が同じまま場合でも、そのIP層の設定を変更する必要があります。例示的なシナリオでは[RFC2461]をリナンバリングIPv6サブネットです。したがって、IP層構成は、リンクアップ通知を受信したIP層がなくても変更する必要ができる場合が存在します。したがって、リンク層通知は、サブネット変更の必須の指標ではありません。
A link up notification may optionally deliver information relating to the attachment point. Such auxiliary information may include the identity of the attachment point (e.g., base station identifier), or the IP-layer configuration parameters associated with the attached subnet (e.g., subnet prefix, default gateway address, etc.). While merely knowing that a new link-layer connection is established may prompt the DNA process to immediately seek other clues for detecting a network configuration change, auxiliary information may constitute further clues (and even the final answers sometimes). In cases where there is a one-to-one mapping between the attachment point identifiers and the IP-layer configurations, learning the former can reveal the latter. Furthermore, IP-layer configuration parameters obtained during the link-layer connection may be exactly what the DNA process is trying to discover.
リンクアップ通知は、必要に応じてアタッチメントポイントに関する情報を配信してもよいです。そのような補助情報は、アタッチメントポイントのアイデンティティ（例えば、基地局識別子）、または添付のサブネット（例えば、サブネットプレフィックス、デフォルトゲートウェイアドレス、等）に関連付けられたIP層構成パラメータを含むことができます。単に新しいリンク層接続が確立されていることを知ることは、直ちにネットワーク構成の変化を検出するための他の手がかりを求めるDNAプロセスを促すことができる一方で、補助情報は、（時には、さらに最終的な回答）さらなる手がかりを構成することができます。アタッチメントポイント識別子とIP層構成との間に1対1のマッピングが存在する場合には、前者を学習することは、後者を明らかにすることができます。さらに、リンク層の接続時に取得したIP層構成パラメータは、DNAプロセスを発見しようとしているまさにかもしれません。
The link-layer process leading to a link up event depend on the link technology. While a link-layer notification must always indicate that the link up event occurred, the availability and types of auxiliary information on the attachment point depends on the link-layer technology as well. The following subsections examine four link-layer technologies and describe when a link-layer notification is generated and what information is included in it.
リンクアップイベントにつながるリンク層プロセスはリンク技術に依存しています。リンク層通知が常にリンクアップイベントが発生したことを示す必要がありますが、取付点の可用性と補助情報の種類は、同様に、リンク層技術に依存します。以下のサブセクションでは、4リンク層技術を検討し、リンク層通知が生成され、どのような情報が、それに含まれている場合について説明します。
GSM Packet Radio System (GPRS) provides packet-switched data transmission over a cellular network [GPRS][GPRS-LINK].
GSMパケット無線システム（GPRS）は、セルラーネットワークを介してパケット交換データ伝送を提供する[GPRS] [GPRS-LINK]。
The GPRS architecture consists of a Radio Access Network and a packet domain Core Network.
GPRSアーキテクチャは、無線アクセスネットワークとパケットドメインコアネットワークから構成されています。
- The GPRS Radio Access Network is composed of Mobile Terminals (MTs), a Base Station Subsystem and Serving GPRS Support Nodes (SGSNs).
- GPRS無線アクセスネットワークは、モバイル端末（MTS）からなる基地局サブシステムとGPRSサポートノード（SGSNの）を提供しています。
- An IP Core Network that acts as the transport backbone of user datagrams between SGSNs and Gateway GPRS Support Nodes (GGSNs). The GGSN ensures the GPRS IP core network connectivity with external networks, such as the Internet or Local Area Networks. The GGSN acts as the default IP gateway for the MT.
- SGSNとゲートウェイGPRSサポートノード（GGSNの）間のユーザデータグラムの輸送バックボーンとして機能IPコアネットワーク。 GGSNは、インターネットやローカルエリアネットワークなどの外部ネットワークとGPRS IPコアネットワークの接続性を保証します。 GGSNは、MTのデフォルトIPゲートウェイとして機能します。
A GPRS MT that wants to establish IP connectivity establishes first a connection to the GPRS network and one or more PDP Context associations between the MT and the GGSN. It is only after the PDP Context has been established and after address autoconfiguration and tunneling mechanism have taken place that the MT's IP packets can be forwarded to and from its remote IP peers. The aim of PDP Context establishment is also to provide IP-level configuration on top of the GPRS link-layer attachment.
IP接続を確立することを望んでいるGPRS MTは最初MTとGGSN間のGPRSネットワークへの接続と1つ以上のPDPコンテキストの関連付けを確立します。これは、PDPコンテキストが確立されており、アドレス自動設定およびトンネリングメカニズムの後にMTのIPパケットは、そのリモートIPピアにしてから転送することができることを行われた後にのみです。 PDPコンテキスト確立の目的は、GPRSリンク層添付の上にIPレベルの構成を提供することもあります。
Successful establishment of a PDP Context on a GPRS link signifies the availability of IP service to the MT. Therefore, this link-layer event generates a link up event notification sent to the IP layer.
GPRSリンク上のPDPコンテキストの成功の確立はMTにIPサービスの可用性を意味します。したがって、このリンク層イベントは、IPレイヤに送信され、リンクアップイベント通知を生成します。
An MT may establish a secondary PDP Context while reusing the IP configuration acquired from a previously established and active PDP Context. Such a secondary PDP Context does not provide additional information to the IP layer and only allows another quality-of-service (QoS) profile to be used. The activation of such a secondary PDP context does not usually generate a link up event since it does not require new IP parameters. However, other additional PDP Context activations are to be treated as indicated earlier.
以前に確立され、アクティブPDPコンテキストから取得したIP構成を再利用しながら、MTは、セカンダリPDPコンテキストを確立することができます。このような二次PDPコンテキストは、IPレイヤに追加情報を提供するだけ別のサービス品質（QoS）プロファイルを使用することができません。それは新しいIPパラメータを必要としないので、このような二次PDPコンテキストの活性化は、通常、リンクアップイベントを生成しません。しかしながら、他の追加PDPコンテキストアクティベーションは、先に示したように扱われるべきです。
With IPv4, the auxiliary information carried along with this notification is the IPv4 address of the MT that is obtained as part of the PDP Context. With IPv6, the PDP Context activation response does not come along with a usable IPv6 address. Effectively, the IPv6 address received from the GGSN in the PDP address field of the message does not contain a valid prefix. The MN actually only uses the interface identifier extracted from that field to form a link-local address that it uses afterwards to obtain a valid prefix (e.g., by stateless [RFC2462][GPRS-CN] or stateful [RFC3315] [GPRS-GSSA] address configuration). Therefore, no IPv6-related auxiliary information is provided to the IP layer.
IPv4では、この通知と共に運ば補助情報は、PDPコンテキストの一部として得られるMTのIPv4アドレスです。 IPv6では、PDPコンテキスト起動応答は、使用可能なIPv6アドレスと一緒に来ません。実際には、IPv6アドレスは、有効なプレフィックスが含まれていないメッセージのPDPアドレス・フィールドにGGSNから受信しました。 MNは、実際にはそれがステートレス[RFC2462] [GPRS-CN]またはステートフル[RFC3315] [GPRS-GSSAによって有効な接頭辞（例えば、取得するために後で使用するリンクローカルアドレスを形成するために、そのフィールドから抽出されたインタフェース識別子を使用しています】アドレス設定）。そのため、IPv6関連補助情報は、IP層に設けられていません。
cdma2000-based 3GPP2 packet data services provide mobile users wide area high-speed access to packet switched networks [CDMA2K]. Some of the major components of the 3GPP2 packet network architecture consist of:
CDMA2000ベースの3GPP2パケットデータサービスは、モバイルユーザーが交換網[CDMA2K]をパケットに広域の高速アクセスを提供します。 3GPP2パケットネットワークアーキテクチャの主要コンポーネントのいくつかはで構成されています。
- Mobile Station (MS), which allows mobile access to packet-switched networks over a wireless connection.
- 無線接続を介してパケット交換ネットワークへのモバイルアクセスを許可する移動局（MS）。
- Radio Access Network, which consists of the Base Station Transceivers, Base Station Controllers, and the Packet Control Function.
- 基地局トランシーバから成る無線アクセスネットワーク、基地局コントローラ、およびパケット制御機能。
- Network Access Server known as the Packet Data Switching Node (PDSN). The PDSN also serves as default IP gateway for the IP MS.
- ネットワーク・アクセス・サーバは、パケットデータスイッチングノード（PDSN）として知られています。 PDSNは、IP MSのデフォルトIPゲートウェイとして機能します。
3GPP2 networks use the Point-to-Point Protocol (PPP [RFC1661]) as the link-layer protocol between the MS and the PDSN. Before any IP packets may be sent or received, PPP must reach the Network-Layer Protocol phase, and the IP Control Protocol (IPCP [RFC1332], IPV6CP [RFC2472]) must reach the Opened state. When these states are reached in PPP, a link up event notification is delivered to the IP layer.
3GPP2ネットワークは、MSとPDSNとの間のリンク層プロトコルとしてポイントツーポイントプロトコル（PPP [RFC1661]）を使用します。任意のIPパケットを送信または受信することができる前に、PPPは、ネットワーク層のプロトコルフェーズに達しなければならない、とIP制御プロトコル（IPCP [RFC1332]は、IPV6CP [RFC2472]）はOpened状態に達しなければなりません。これらの状態は、PPPに達している場合、リンクアップイベント通知は、IPレイヤに配信されます。
When the PPP is used for 3GPP2 Simple (i.e., non-Mobile) IPv4 Service, IPCP enables configuration of an IPv4 address on the MS. This IPv4 address is provided as the auxiliary information along with the link up notification. IPV6CP used for Simple IPv6 service does not provide an IPv6 address, but the interface identifiers for local and remote endpoints of the PPP link. Since there is no standards-mandated correlation between the interface identifier and other IP-layer configuration parameters, this information is deemed not useful for DNA (nevertheless, it may be provided as auxiliary information for other uses).
PPPは、3GPP2単純な（すなわち、非モバイル）IPv4のサービスのために使用される場合、IPCPは、MSにIPv4アドレスの設定を可能にします。このIPv4アドレスは、リンクアップ通知と一緒に補助情報として提供されます。 IPV6CPは、シンプルIPv6サービスがIPv6アドレスを提供しないために使用されるが、PPPリンクのローカルおよびリモートエンドポイント用のインタフェース識別子。インタフェース識別子と他のIP層構成パラメータとの間には標準義務付け相関がないので、この情報は（それにもかかわらず、他の用途のための補助情報として提供されてもよい）DNAのために有用ではないとみなされます。
IEEE 802.11-based WiFi networks are the wireless extension of the Local Area Networks. Currently available standards are IEEE 802.11b [IEEE-802.11b], IEEE 802.11g [IEEE-802.11g], and IEEE 802.11a [IEEE-802.11a]. The specifications define both the MAC layer and the physical layer. The MAC layer is the same for all these technologies.
IEEE 802.11ベースのWi-Fiネットワークは、ローカルエリアネットワークの無線拡張したものです。現在利用可能な標準規格はIEEE 802.11bの[IEEE-802.11]、IEEE 802.11グラム[IEEE-802.11グラム]、およびIEEE 802.11aの[IEEE-802.11aの]です。仕様は、MAC層と物理層の両方を定義します。 MAC層は、これらすべての技術についても同様です。
Two operating modes are available in the IEEE 802.11 series, either infrastructure mode or ad-hoc mode. In infrastructure mode, all link-layer frames are transmitted to an access point (AP) that then forwards them to the final receiver. A station (STA) establishes an IEEE 802.11 association with an AP in order to send and receive IP packets. In a WiFi network that uses Robust Secure Network (RSN [IEEE-802.11i]), successful completion of the 4-way handshake between the STA and AP commences the availability of IP service. The link up event notification is generated upon this event. In non-RSN-based networks, successful association or re-association events on the link layer causes a link up notification sent to the IP layer.
2つの動作モードは、どちらかのインフラストラクチャモードまたはアドホックモード、IEEE 802.11シリーズでご利用いただけます。インフラストラクチャモードでは、すべてのリンク層フレームは、最終的な受信機に転送し、アクセスポイント（AP）に送信されます。ステーション（STA）は、IPパケットを送信及び受信するためにAPとIEEE 802.11アソシエーションを確立します。ロバストセキュアネットワーク（RSN [IEEE-802.11i規格]）を使用してWi-Fiネットワークでは、STAとAPの間で4ウェイハンドシェイクが正常に完了は、IPサービスの利用を開始します。リンクアップイベント通知は、このイベント時に生成されます。非RSNベースのネットワークでは、リンク層で成功した会合または再アソシエーションのイベントは、IP層に送信され、リンクアップ通知の原因となります。
As part of the link establishment, the STA learns the BSSID and SSID associated with the AP. The BSSID is a unique identifier of the AP, usually set to the MAC address of the wireless interface of the AP. The SSID carries the identifier of the Extended Service Set (ESS) -- the set composed of APs and associated STAs that share a common distribution system. The BSSID and SSID may be provided as auxiliary information along with the link up notification. Unfortunately, this information does not provide a deterministic indication of whether the IP-layer configuration must be changed upon movement. There is no standards-mandated one-to-one relation between the BSSID/SSID pairs and IP subnets. An AP with a given BSSID can connect a STA to any one of multiple IP subnets. Similarly, an ESS with the given SSID may span multiple IP subnets. And finally, the SSIDs are not globally unique. The same SSID may be used by multiple independent ESSs. Nevertheless, BSSID/SSID information may be used in a probabilistic way by the DNA process; hence, it is provided with the link up event notification.
リンク確立の一部として、STAがAPに関連付けられたBSSIDとSSIDを学習します。 BSSIDは、通常、APの無線インターフェイスのMACアドレスに設定APの一意な識別子です。一般的な分配システムを共有するAPと関連付けられたSTAの構成セット - SSIDは、拡張サービスセット（ESS）の識別子を運びます。 BSSIDとSSIDは、リンクアップ通知と一緒に補助情報として提供されてもよいです。残念ながら、この情報には、IP層構成は、移動時に変更しなければならないかどうかの決定論的な指示を提供しません。 BSSID / SSIDペアとIPサブネットの間には、標準に義務付けられた1対1の関係はありません。与えられたBSSIDとのAPは、複数のIPサブネットのいずれかにSTAを接続することができます。同様に、指定されたSSIDとESSは、複数のIPサブネットにまたがることができます。そして最後に、SSIDがグローバルに一意ではありません。同じSSIDは、複数の独立のESSによって使用されてもよいです。それにもかかわらず、BSSID / SSID情報はDNAプロセスによって確率的な方法で使用することができます。したがって、それは、リンクアップイベント通知が設けられています。
In ad-hoc mode, mobile stations (STA) in range may directly communicate with each other, i.e., without any infrastructure or intermediate hop. The set of communicating STAs is called IBSS for Independent Basic Service Set. In an IBSS, only STA services are available, i.e., authentication, deauthentication, privacy, and MAC Service Data Unit (MSDU) delivery. STAs do not associate with each other, and therefore may exchange data frames in state 2 (authenticated and not associated) or even in state 1 (unauthenticated and unassociated) if the Distribution System is not used (i.e., "To DS" and "From DS" bits are clear). If authentication is performed, a link up indication can be generated upon authentication. Concerning the link layer identification, both the BSSID (which is a random MAC address chosen by a STA of the IBSS) and SSID may be used to identify a link, but not to make any assumptions on the IP network configuration.
アドホックモードでは、範囲内の移動局（STA）は、直接、任意のインフラストラクチャまたは中間ホップすることなく、すなわち、互いに通信することができます。通信のSTAのセットは、独立した基本サービスセット用IBSSと呼ばれています。 IBSSでは、唯一のSTAサービスは、すなわち、認証、認証解除、プライバシー、およびMACサービスデータユニット（MSDU）配達可能です。 STAは互いに会合していないので、配信システム（すなわち、「DSに」使用「からのものでない場合（非認証と関連付けられていない）状態2でデータフレームを交換（認証と関連付けられていない）、あるいは状態1でよいですDS」ビット）が明確です。認証が実行されている場合は、リンクアップ表示は、認証時に発生することができます。リンク層識別について、（IBSSのSTAによって選択されたランダムなMACアドレス）BSSID及びSSIDの両方がリンクを識別するために使用されてもよいが、IPネットワーク構成上の仮定を行うことはありません。
IEEE 802.3 CSMA/CD (commonly referred to as Ethernet) is the most commonly deployed Local Area Network technology in use today. As deployed today, it is specified by a physical layer/medium access control (MAC) layer specification [IEEE-802.3]. In order to provide connection of different LANs together into a larger network, 802.3 LANs are often bridged together [IEEE-802.1D].
IEEE 802.3 CSMA / CD（一般的にイーサネットと呼ばれる）は、今日使用されている最も一般的に展開され、ローカルエリアネットワーク技術です。今日配備されるように、それが物理層/メディアアクセス制御（MAC）レイヤ仕様[IEEE-802.3]によって指定されます。大規模なネットワークに互いに異なるLANの接続を提供するために、802.3 LANはしばしば[IEEE-802.1D]一緒にブリッジされます。
In this section, the terms 802.3 and Ethernet are used interchangeably. This section describes some issues in providing link-layer indications on Ethernet networks, and shows how bridging affects these indications.
このセクションでは、用語802.3およびイーサネットは、交換可能に使用されます。このセクションでは、イーサネットネットワーク上のリンクレイヤの表示を提供するいくつかの問題を説明し、ブリッジングは、これらの指示にどのように影響するかを示しています。
In Ethernet networks, hosts are connected by wires or by optic fibre to a switch (bridge), a bus (e.g., coaxial cable), a repeater (hub), or directly to another Ethernet device. Interfaces are symmetric, in that while many different physical layers may be present, medium access control is uniform for all devices.
イーサネットネットワークでは、ホストは、直接別のイーサネットデバイスにスイッチ（ブリッジ）、バス（例えば、同軸ケーブル）、リピータ（ハブ）にワイヤによって、または光ファイバで接続されています。インターフェイスは、すべてのデバイスのために、多くの異なる物理層が存在してもよいが、媒体アクセス制御が均一で、対称です。
In order to determine whether the physical medium is ready for frame transfer, IEEE 802.3 Ethernet specifies its own link monitoring mechanism, which is defined for some, but not all, classes of media. Where available, this Link Integrity Test operation is used to identify when packets are able to be received on an Ethernet segment. It is applicable to both wired and optical physical layers, although details vary between technologies (link pulses in twisted pair copper, light levels in fibre).
物理媒体は、フレーム転送の準備ができているかどうかを決定するために、IEEE 802.3イーサネット（登録商標）は、いくつかのために定義されている独自のリンク監視機構を指定し、全てではないが、メディアのクラス。利用可能な場合、このリンクインテグリティテスト運転は、パケットがイーサネットセグメントで受信されることが可能である場合に識別するために使用されます。詳細は技術（ツイストペア銅、ファイバ内の光レベルのリンクパルス）の間で変化するが、それは、有線および光の両方の物理層に適用可能です。
Link Integrity Tests in 802.3 networks typically occur at initial physical connection time (for example, at the auto-negotiation stage) and periodically afterwards. They make use of physical-layer specific operations to determine if a medium is able to support link-layer frames [IEEE-802.3].
802.3ネットワークにおけるリンク完全性テストは、典型的には、定期的に、その後の最初の物理的な接続時間（例えば、オートネゴシエーション段階）とで生じます。彼らは、媒体がリンク層フレーム[IEEE-802.3]をサポートできるかどうかを決定するために物理層固有の操作を利用します。
The status of the link as determined by the Link Integrity Test is stored in the variable 'link_status'. Changes to the value of link_status (for example due to Link Integrity Test failure) will generate link indications if the technology-dependent interface is implemented on an Ethernet device [IEEE-802.3].
リンク完全性試験によって決定されるように、リンクのステータスを変数「link_status」に格納されています。技術依存インタフェースは、イーサネットデバイスに実装されている場合link_statusの値への変更が（リンク完全性テストの失敗に起因するなど）リンク適応を生成する[IEEE-802.3]。
The link_status has possible values of FAIL, READY, and OK. In FAIL state, Link Integrity Tests have failed. In READY state, the link segment has passed integrity tests, but auto-negotiation has not completed. In OK state, the medium is able to send and receive packets.
link_statusはFAIL、READY、およびOKの可能な値を持っています。 FAIL状態では、リンク完全性テストが失敗しています。 READY状態では、リンクセグメントは、完全性テストに合格していますが、自動ネゴシエーションが完了していません。 OK状態で、培地は、パケットを送受信することができます。
Upon transition to a particular state, the Physical Medium Attachment subsystems generates a PMA_LINK.indicate(link_status). Indications of OK state may be used to generate a link up event notification. These indications do not definitively ensure that packets will be able to be received through the bridge domain, though (see the next section). Such operations are governed by bridging.
特定の状態への遷移時に、物理媒体アタッチメントサブシステムはPMA_LINK.indicate（link_status）を生成します。 OK状態の兆候は、リンクアップイベント通知を生成するために使用することができます。 （次のセクションを参照）にもかかわらずこれらの表示は、決定的に、パケットはブリッジドメインを介して受信することができるようになることを保証するものではありません。このような操作は、ブリッジングによって支配されています。
3.4.2. IEEE 802.1D Bridging and Its Effects on Link-layer Event Notifications
3.4.2. IEEE 802.1Dブリッジングおよびリンク層イベント通知とその効果
Ethernet networks commonly consist of LANs joined together by transparent bridges (usually implemented as switches). Transparent bridges require the active topology to be loop free. This is achieved through the Spanning Tree Protocol (STP) or the Rapid Spanning Tree Protocol (RSTP). These protocols exchange Bridge Protocol Data Units (BPDUs), as defined in [IEEE-802.1D]; this leads to the blocking of ports (i.e., not forwarding), where required.
イーサネットネットワークは、一般的にLANの（通常はスイッチとして実装）透明ブリッジによって接合成ります。トランスペアレントブリッジは、ループのないように、アクティブトポロジーを必要としています。これは、スパニングツリープロトコル（STP）または高速スパニングツリープロトコル（RSTP）によって達成されます。これらのプロトコル交換ブリッジプロトコルデータユニット（BPDU）、[IEEE-802.1D]で定義されます。これは、ポートの遮断（すなわち、転送せず）、必要につながります。
By default, the spanning tree protocol does not know whether a particular newly connected piece of Ethernet will cause a loop.
デフォルトでは、スパニングツリープロトコルは、イーサネットの特定の新しく接続された作品は、ループの原因となるかどうか分かりません。
Therefore, it will block all traffic from and to newly connected ports with the exception of some unbridged management frames. The STP will determine if the port can be connected to the network in a loop-free manner.
したがって、それはいくつかの非架橋管理フレームを除いてから、新しく接続されたポートへのすべてのトラフィックをブロックします。ポートがループのない方法でネットワークに接続できるかどうSTPが決定するであろう。
For these technologies, even though the link layer appears available, no data packet forwarding will occur until it is determined that the port can be connected to the network in a loop-free environment.
ポートがループのない環境でネットワークに接続することができると判断されるまで、これらの技術については、リンク層が利用可能に表示されていても、何のデータパケットの転送は行われません。
For hosts that are providing indications to upper-layer protocols, even if the host itself does not implement bridging or STP, packet delivery across the network can be affected by the presence of bridges.
ホスト自体が架橋又はSTP実装していない場合であっても、上位層プロトコルへの表示を提供しているホストの場合、ネットワークを介してパケット配信はブリッジの存在によって影響され得ます。
A host connected to a bridge port does not receive any explicit indication that the bridge has started forwarding packets. Therefore, a host may not know when STP operations have completed, or when it is safe to inform upper layers to transmit packets.
ブリッジポートに接続されたホストは、ブリッジがパケットを転送開始したことを明示的な指示を受信しません。したがって、ホストは、STP操作が完了した時に知ることができない、またはそれが安全であるとき、パケットを送信するために上位層に通知します。
Where it is not known that forwarding operations are available, a host should assume that RSTP or STP is being performed. Hosts may listen to STP/RSTP and 802.1AB messages to gain further information about the timing of full connectivity on the link, for example, to override an existing indication.
転送操作が利用可能であることを知られていない場合は、ホストは、そのRSTPを前提としなければならないか、STPが実行されています。ホストは既存の表示を無効にするために、例えば、リンク上の完全な接続のタイミングについてのさらなる情報を得るために、STP / RSTPと802.1ABのメッセージを聞くことがあります。
Notably, though, it is not easy for a host to distinguish between disabled bridge ports and non-bridge ports with no active transmitters on them, as Disabled ports will have no traffic on them, and incur 100% sender loss.
注目すべきは、しかし、無効ポートが彼らに何のトラフィックを持っていない、100％の送信者の損失を被るように、ホストは、それらの上にアクティブな送信機で無効ブリッジポートと非ブリッジポートを区別するために簡単ではありません。
If no bridge configuration messages are received within the Bridge_Max_Age interval (default 20s) then it is likely that there is no visible bridge whose port is enabled for bridging (S8.4.5 of [IEEE-802.1D]), since at least two BPDU hello messages would have
何ブリッジ構成メッセージはBridge_Max_Age間隔（デフォルト20S）内に受信されない場合、そのポート（[IEEE-802.1D]のS8.4.5）を架橋するために有効になっている目に見えるブリッジは、少なくとも2つのBPDUハローので、存在しない可能性がありますメッセージは持っているでしょう
been lost. Upon this timeout, a link up notification is generated, if one has not been already.
失われました。 1がすでにされていない場合、このタイムアウトすると、リンクアップ通知は、生成されます。
If a BPDU is received, and the adjacent bridge is running the original Spanning Tree Protocol, then a host cannot successfully send packets until at least twice the ForwardDelay value in the received BPDU has elapsed. After this time, a link up notification is generated. If the previous link up notification was non-deterministic, then this notification includes an attribute signifying that the packets sent within the prior interval were lost.
BPDUが受信され、隣接するブリッジは、元のスパニングツリープロトコルを実行している場合、ホストが正常に少なくとも二回受信したBPDU中ForwardDelayの値が経過するまで、パケットを送信することはできません。この時間の後、リンクアップ通知が生成されます。前のリンクアップ通知が非決定論的だった場合、この通知は、前区間内に送信されたパケットが失われたことを意味属性を含んでいます。
If the bridge is identified as performing Rapid Spanning Tree Protocol (RSTP), it instead waits Bridge_Max_Age after packet reception (advertised in the BPDU's Max Age field), before forwarding. For ports which are known to be point-to-point through auto-negotiation, this delay is abbreviated to 3 seconds after auto-negotiation completes [IEEE-802.1D].
ブリッジは、ラピッドスパニングツリープロトコル（RSTP）を行うと識別された場合、それは代わりに転送する前に、（BPDUの最大年齢フィールドにアドバタイズ）パケット受信後Bridge_Max_Ageを待ちます。自動ネゴシエーションは[IEEE-802.1D]完了した後に、ポイントツーポイント自動ネゴシエーションを介してであることが知られているポートの場合、この遅延は3秒と略記されます。
The recently defined 802.1AB Link-Layer Discovery Protocol (LLDP) provides information to devices that are directly adjacent to them on the local LAN [IEEE-802.1ab].
最近定義された802.1ABリンク層検出プロトコル（LLDP）は、ローカルLAN [IEEE-802.1AB]でそれらに直接隣接しているデバイスに情報を提供します。
LLDP sends information periodically and at link status change time to indicate the configuration parameters of the device. Devices may send or receive these messages, or do both.
LLDPは、定期的に情報を送信し、リンクステータス変更時にデバイスの構成パラメータを示すために。デバイスは、送信またはこれらのメッセージを受信、またはその両方を行うことができます。
The LLDP message may contain a System Capabilities TLV, which describes the MAC- and IP-layer functions that a device is currently using. Where a host receives the System Capabilities TLV indicating that no Bridging is occurring on the LLDP transmitter, no delays for STP calculation will be applied to packets sent through this transmitter. This would allow the generation of a link up notification.
LLDPメッセージは、デバイスが現在使用しているMAC-及びIPレイヤ機能を記述するシステム機能TLVを含んでいてもよいです。ホストはないブリッジがLLDP送信に発生していないことを示すシステム機能のTLVを受信する場合、STP計算のための遅延は、この送信機を介して送信されるパケットに適用されません。これは、リンクアップ通知の生成を可能にします。
Additionally, if a host receives a System Capabilities TLV indicating that the LLDP transmitter is a bridge, the host's advertisement that it is an (end-host) Station-Only may tell the bridge not to run STP and may immediately allow forwarding.
さらに、ホストは、LLDP送信機は、それが（エンドホスト）であることを、ホストの広告ブリッジであることを示すシステム機能のTLVを受信した場合の駅のみのSTPを実行しないようにブリッジを伝えることが、すぐに転送を可能にすることができます。
Proprietary extensions may also indicate that data forwarding is already available on such a port. Discussion of such optimizations is out of scope for this document.
独自の拡張機能は、データ転送は、ポート上ですでに利用可能であることを示してもよいです。このような最適化の議論はこの文書の範囲外です。
Because the protocol is new and not widely deployed, it is unclear how this protocol will eventually affect DNA in IPv4 or IPv6 networks.
プロトコルは新しく、広く展開されていないので、このプロトコルは、最終的にはIPv4またはIPv6ネットワークでDNAにどのように影響するかは不明です。
In 802.3 networks, Network Interface Cards (NICs) are often capable of returning a speed and duplex indication to the host. Changes in these characteristics may indicate a connection to a new layer 2 network.
802.3ネットワークでは、ネットワークインタフェースカード（NIC）は、多くの場合、ホストに速度およびデュプレックス指示を戻すことが可能です。これらの特性の変化は、新たなレイヤ2ネットワークへの接続を示す場合があります。
Link-layer indications in Ethernet-like networks are complicated by additional unadvertised delays due to spanning tree calculations. This may cause re-indication or retraction of indications previously sent to upper layer protocols.
イーサネットのようなネットワークにおけるリンク層指示が原因スパニングツリーの計算に追加の非通知の遅れによって複雑にされています。これは以前に上位層プロトコルに送信された適応症の再表示または後退を引き起こすことがあります。
Attackers may spoof various indications at the link layer, or manipulate the physical medium directly in an effort to confuse the host about the state of the link layer. For instance, attackers may spoof error messages or disturb the wireless medium to cause the host to move its connection elsewhere or even to disconnect. Attackers may also spoof information to make the host believe it has a connection when, in reality, it does not. In addition, wireless networks such as 802.11 are susceptible to an attack called the "Evil Twin" attack where an attacker sets up an Access Point with the same SSID as a legitimate one and gets the use to connect to the fake access point instead of the real one. These attacks may cause use of non-preferred networks or even denial of service.
攻撃者はリンク層で種々の適応症を偽造、またはリンク層の状態についてのホストを混同するための努力に直接物理的媒体を操作することができます。例えば、攻撃者は、エラーメッセージを偽造またはホストを切断する他の場所、あるいはその接続を移動させるために無線媒体を乱すことがあります。攻撃者は、ホストを作るためになりすました情報は、それが現実で、それはない、接続を持っていると考えていることがあります。また、このような802.11などの無線ネットワークは、攻撃を受けやすいの代わりに、攻撃者が正規のものと同じSSIDでアクセスポイントを設定し、偽のアクセスポイントに接続するために使用を取得する「悪のツイン」攻撃と呼ばれています本物。これらの攻撃は、非優先ネットワークの利用やサービスのさえ拒否を引き起こす可能性があります。
This specification does not provide any protection of its own for the indications from the lower layers. But the vulnerabilities can be mitigated through the use of techniques in other parts of the protocol stack. In particular, it is recommended that authentication, replay, and integrity protection of link-layer management messages are enabled when available. For example, the IEEE 802.1ae standard [IEEE-802.1ae] defines such mechanisms for IEEE 802-compliant MAC layers. Additionally, the protocol stack may also use some network-layer mechanisms to achieve partial protection. For instance, SEND [RFC3971] could be used to confirm secure reachability with a router. However, network layer mechanisms are unable to deal with all problems, such as insecure lower-layer notifications that lead to the link not functioning properly.
この仕様は、下位層からの指示のために、独自の任意の保護を提供しません。しかし脆弱性は、プロトコルスタックの他の部分の技術の使用によって軽減することができます。特に、利用可能な場合、認証、リプレイ、およびリンク層管理メッセージの完全性保護が有効になっていることをお勧めします。例えば、IEEE 802.1AE標準[IEEE-802.1AE]は、IEEE802準拠のMAC層のためのそのようなメカニズムを定義します。さらに、プロトコル・スタックはまた、部分的な保護を達成するために、いくつかのネットワーク層メカニズムを使用することができます。例えば、[RFC3971]を送信ルータとの安全な到達可能性を確認するために使用することができます。しかし、ネットワーク層メカニズムは、そのようなリンクが正しく機能していないにつながる安全性の低い下層の通知など、すべての問題に対処することはできません。
In addition to the people listed in the author list, text for the specific link-layer technologies covered by this document was contributed by Thomas Noel (IEEE 802.11b) and Greg Daley (IEEE 802.3). The authors would like to thank them for their efforts in bringing this document to fruition.
著者のリストに記載されている人々に加えて、この文書でカバー特定のリンク層技術のためのテキストは、トーマス・ノエル（IEEE 802.11bの）とグレッグ・デイリー（IEEE 802.3）によって寄贈されました。著者は結実するには、この文書を持って来るで彼らの努力に感謝したいと思います。
The authors would like to acknowledge Bernard Aboba, Sanjeev Athalye, JinHyeock Choi, John Loughney, Pekka Nikander, Brett Pentland, Tom Petch, Dan Romascanu, Pekka Savola, Steve Bellovin, Thomas Narten, Matt Mathis, Alfred Hoenes, and Muhammad Mukarram bin Tariq for their useful comments and suggestions.
作者はバーナードAboba、サンジーブAthalye、JinHyeockチェ・ジョンLoughney、ペッカNikander、ブレット・ペントランド、トム・ペッチ、ダンRomascanu、ペッカSavola、スティーブBellovin氏、トーマスNarten氏、マット・マシス、アルフレッドHoenes、そしてムハンマドMukarramビンタリクを承認したいと思います彼らの役に立つコメントと提案のため。
[CDMA2K] "cdma2000 Wireless IP Network Standard", , December 2000.
[CDMA2K] "CDMA2000無線IPネットワーク標準"、2000年12月。
[GPRS] "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS) Service description; Stage 2", 3GPP TS 03.60 version 7.9.0 Release 98.
[GPRS] "デジタルセルラー通信システム（フェーズ2+）;一般パケット無線サービス（GPRS）サービス記述;ステージ2"、3GPP TS 03.60バージョン7.9.0リリース98。
[GPRS-LINK] "Digital cellular telecommunications system (Phase 2+); Radio subsystem link control", 3GPP GSM 03.05 version 7.0.0 Release 98.
[GPRS-LINK] "デジタルセルラー通信システム（フェーズ2+）;無線サブシステムリンク制御"、3GPP GSM 03.05バージョン7.0.0リリース98。
[IEEE-802.11a] Institute of Electrical and Electronics Engineers, "IEEE Std 802.11a-1999, supplement to IEEE Std 802.11-1999, Part 11: Wireless MAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ band", IEEE Standard 802.11a, September 1999.
[IEEE-802.11aの]電気電子技術者協会、「IEEE 802.11aのSTD-1999、IEEE標準802.11-1999、パート11の補足：ワイヤレスMAN媒体アクセス制御（MAC）および物理層（PHY）仕様：ハイ5GHz帯の高速物理層」、IEEE規格の802.11a、1999年9月。
[IEEE-802.11b] Institute of Electrical and Electronics Engineers, "IEEE Std 802 Part 11, Information technology - Telecomunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY) Specifications", IEEE Standard 802.11b, August 1999.
電気電子技術者の[IEEE-802.11]研究所、「IEEE規格802パート11、情報技術 - Telecomunicationsとシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 特定の要件 - パート11：無線LAN媒体アクセス制御（MAC）物理層（PHY）仕様」、IEEE規格802.11bの、1999年8月。
[IEEE-802.11g] Institute of Electrical and Electronics Engineers, "IEEE Std 802.11g-2003, Amendment to IEEE Std 802.11, 1999 edition, Part 11: Wireless MAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. Amendment 4: Further Higher Data Rate Extension in the 2.4 GHz Band", IEEE Standard 802.11g, June 2003.
電気電子技術者の[IEEE-802.11グラム]研究所、「IEEE規格802.11gの-2003、IEEE標準802.11、1999年版、パート11に改正：ワイヤレスMAN媒体アクセス制御（MAC）および物理層（PHY）仕様改正。 4：2.4GHz帯」、IEEE規格802.11グラム、2003年6月にさらに高いデータレート拡張。
[IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Supplement to STANDARD FOR Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Specification for Enhanced Security", IEEE 802.11i, December 2004.
電気電子技術者の[IEEE-802.11i規格]研究所、「システム間のテレコミュニケーションと情報交換するための標準的な補足 - LAN / MAN具体的な要件 - パート11：無線媒体アクセス制御（MAC）および物理層（PHY）仕様：仕様セキュリティ強化」、IEEE 802.11i規格、2004年12月の。
[IEEE-802.1D] Institute of Electrical and Electronics Engineers, "IEEE standard for local and metropolitan area networks - common specifications - Media access control (MAC) Bridges", ISO/IEC IEEE Std 802.1D, 2004.
電気電子技術者の[IEEE 802.1D-]研究所、 "ローカルおよびメトロポリタンエリアネットワークのためのIEEE標準 - 共通仕様 - メディアアクセス制御（MAC）ブリッジ"、ISO / IEC IEEE規格802.1D、2004。
[IEEE-802.1ab] Institute of Electrical and Electronics Engineers, "Draft Standard for Local and Metropolitan Networks: Station and Media Access Control Connectivity Discovery (Draft 13)", IEEE draft Std 802.1AB, 2004.
電気電子技術者の[IEEE-802.1AB]研究所、「ローカルのためのドラフト標準とメトロポリタンネットワーク：駅やメディアアクセス制御接続ディスカバリー（ドラフト13）」、IEEEドラフトSTD 802.1AB、2004。
[IEEE-802.1ae] Institute of Electrical and Electronics Engineers, "IEEE Std 802.1AE, Local and Metropolitan Area Networks - Media Access Control (MAC) Security", IEEE Standard 802.1ae, June 2006.
[IEEE-802.1AE]電気電子技術者協会、 "ローカルIEEE STD 802.1AE、およびメトロポリタンエリアネットワーク - メディアアクセス制御（MAC）セキュリティ"、IEEE標準802.1AE、2006年6月。
[IEEE-802.3] Institute of Electrical and Electronics Engineers, "IEEE standard for local and metropolitan area networks - Specific Requirements, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", ISO/IEC IEEE Std 802.3, 2002.
[IEEE-802.3]電気電子技術者協会、「ローカルおよびメトロポリタンエリアネットワークのためのIEEE標準 - 固有の要件、パート3：衝突検出（CSMA / CD）アクセス方法および物理層仕様搬送波感知多重アクセス」、ISOは/ IEC IEEE 802.3、2002。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D.およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 2472、1998年12月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005.
[RFC4135]チェ、JH。そして、G.デイリー、「IPv6におけるネットワーク接続検出の目標」、RFC 4135、2005年8月。
[GPRS-CN] "Technical Specification Group Core Network; Internetworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) (Release 6)", 3GPP TS 29.061 version 6.1.0 2004-06.
[GPRS-CN]「技術仕様グループコアネットワーク、公衆陸上移動網（PLMN）をサポートするパケットベースのサービスおよびパケットデータネットワーク（PDN）間のインターネットワーキング（リリース6）」、3GPP TS 29.061バージョン6.1.0 2004-06。
[GPRS-GSSA] "Technical Specification Group Services and System Aspect; General Packet Radio Service (GPRS) Service description; Stage 2 (Release 6)", 3GPP TS 23.060 version 6.5.0 2004-06.
[GPRS-GSSA] "技術仕様グループサービスおよびシステムアスペクト;汎用パケット無線サービス（GPRS）サービスの説明;ステージ2（リリース6）"、3GPP TS 23.060バージョン6.5.0 2004-06。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068] Koodli、R.、 "モバイルIPv6のための高速ハンドオーバ"、RFC 4068、2005年7月。
[RFC4881] El Malki, K., "Low-Latency Handoffs in Mobile IPv4", RFC 4881, June 2007.
[RFC4881]エルMalki、K.、 "モバイルIPv4における低遅延ハンドオフ"、RFC 4881、2007年6月。
Authors' Addresses
著者のアドレス
Suresh Krishnan (editor) Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナン（編集者）エリクソン研究8400 Decarie大通りマウントロイヤル、QCカナダの町
EMail: suresh.krishnan@ericsson.com
メールアドレス：suresh.krishnan@ericsson.com
Nicolas Montavont GET ENST Bretagne 2, rue de la chataigneraie Cesson-Sevigne 35576 France
ニコラスMontavontはENST 2、RUE・デ・ラ・Chataigneraie 35576セッソンセビニェフランスGET
Phone: (33) 2 99 12 70 23 EMail: nicolas.montavont@enst-bretagne.fr
電話：（33）2 99 12 70 23 Eメール：nicolas.montavont@enst-bretagne.fr
Eric Njedjou France Telecom 4, Rue du Clos Courtel BP 91226 Cesson Sevigne 35512 France
エリックNjedjouフランステレコム4、ルードゥクロCourtel BP 91226 35512セッソンセヴィニエフランス
Phone: +33 299124878 EMail: eric.njedjou@orange-ftgroup.com
電話：+33 299124878 Eメール：eric.njedjou@orange-ftgroup.com
Siva Veerepalli Qualcomm 5775 Morehouse Drive San Diego, CA 92131 USA
シヴァVeerepalliクアルコム5775モアハウスドライブサンディエゴ、CA 92131 USA
Phone: +1 858 658 4628 EMail: sivav@qualcomm.com
電話：+1 858 658 4628 Eメール：sivav@qualcomm.com
Alper E. Yegin (editor) Samsung Istanbul Turkey
アルパースE. Yegin（エディタ）サムスンイスタンブールトルコ
Phone: +90 533 348 2402 EMail: a.yegin@partner.samsung.com
電話：+90 533 348 2402 Eメール：a.yegin@partner.samsung.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機能のための基金は現在、インターネット協会によって提供されます。