[要約] RFC 4957は、ネットワーク接続の検出のためのリンク層イベント通知に関する規格です。その目的は、ネットワークデバイスの接続と切断を自動的に検出し、ネットワーク管理者に通知することです。
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）The IETF Trust（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））、またはリンクを介して取得したネットワークレイヤー構成パラメーターなど、イベントとともに伝えることができます。 - 利用可能な場合は、レイヤーアタッチメントプロセス。このようなイベント通知は、特定の状況で使用されて、サブネット間の移動検出と再構成プロセスを促進するために使用できると想定されています。たとえば、ノードが新しいリンク層接続を確立していることを示す通知は、構成の可能性のためにネットワークをすぐに調査するために使用される場合があります。リンクレイヤーからのこのような通知がない場合、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プロセスへの入力の1つであると見なされます。DNAプロセスは、IP層構成を更新する必要があるかどうかを判断する前に、他の入力（たとえば、広告のプレフィックスの存在、デフォルトゲートウェイの到達可能性）を取得する可能性があります。DNAプロセスは、IPが利用できるようになったときにリンク層通知を活用できると予想されます。リンク層通知自体は、すべての入力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プロセスに最も役立つと考えられているリンク層イベントは、Link Upイベントです。関連する通知は、イベントが正常に終了した後、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番目のリンクUPイベントでは、最初のリンクが既に行った場合、確認プロセスをトリガーする必要はありません。
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.
リンクアップ通知は、オプションでアタッチメントポイントに関連する情報を提供する場合があります。このような補助情報には、アタッチメントポイント（ベースステーション識別子など）のID、または添付のサブネットに関連付けられた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サポートノード（SGSNS）で構成されています。
- 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.
- SGSNSとGateway GPRSの間のユーザーデータグラムのトランスポートバックボーンとして機能するIPコアネットワークは、ノード（GGSN）をサポートします。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は、最初にGPRSネットワークとMTとGGSNの間の1つ以上のPDPコンテキスト関連への接続を確立します。MTのIPパケットをリモートIPピアとの間で転送できるのは、PDPコンテキストが確立された後、AutoconfigurationおよびTunnelingメカニズムが行われた後です。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.
MTは、以前に確立されたアクティブなPDPコンテキストから取得されたIP構成を再利用しながら、二次PDPコンテキストを確立する場合があります。このようなセカンダリPDPコンテキストは、IPレイヤーに追加情報を提供せず、別のサービス品質（QoS）プロファイルのみを使用できます。このようなセカンダリPDPコンテキストのアクティブ化は、通常、新しいIPパラメーターを必要としないため、リンクアップイベントを生成しません。ただし、他の追加の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アドレスとは伴いません。効果的に、メッセージのPDPアドレスフィールドのGGSNから受信したIPv6アドレスには、有効なプレフィックスが含まれていません。MNは実際にそのフィールドから抽出されたインターフェイス識別子のみを使用して、その後使用して有効なプレフィックスを取得するリンクローカルアドレスを形成します（例：Stateless [RFC2462] [GPRS-CN]またはStateful [RFC3315] [GPRS-GSSA]アドレス構成）。したがって、IPレイヤーにIPv6関連の補助情報は提供されません。
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]）は開かれた状態に到達する必要があります。これらの状態が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アドレスは、リンクアップ通知とともに補助情報として提供されます。単純なIPv6サービスに使用されるIPv6CPは、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ベースのWiFiネットワークは、ローカルエリアネットワークのワイヤレス拡張です。現在利用可能な基準は、IEEE 802.11b [IEEE-802.11b]、IEEE 802.11g [IEEE-802.11g]、および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.
IEEE 802.11シリーズ、インフラストラクチャモードまたはアドホックモードのいずれかの2つの操作モードが利用可能です。インフラストラクチャモードでは、すべてのリンク層フレームがアクセスポイント（AP）に送信され、最終レシーバーに転送されます。ステーション（STA）は、IPパケットを送信および受信するために、IEEE 802.11 APとAPとの関連を確立します。堅牢なセキュアネットワーク（RSN [IEEE-802.11i]）を使用するWiFiネットワークでは、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の一意の識別子であり、通常、APのワイヤレスインターフェイスのMACアドレスに設定されています。SSIDには、拡張サービスセット（ESS）の識別子が搭載されています。これは、共通の配信システムを共有するAPと関連するSTAで構成されるセットです。BSSIDとSSIDは、リンクアップ通知とともに補助情報として提供される場合があります。残念ながら、この情報は、移動時にIP層構成を変更する必要があるかどうかの決定論的な指標を提供しません。BSSID/SSIDペアとIPサブネットの間には、規格が義務付けている1対1の関係はありません。特定のBSSIDを持つAPは、STAを複数のIPサブネットのいずれかに接続できます。同様に、指定された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」と「」（から」と状態1（認証されていない）または状態1（認証されていない）でデータフレームを交換する場合があります。DS "ビットはクリアです）。認証が実行された場合、認証時にリンクアップ表示を生成できます。リンクレイヤーの識別に関して、BSSID（IBSSのSTAによって選択されたランダムMACアドレス）と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の値が可能です。故障状態では、リンクの整合性テストが失敗しました。Ready Stateでは、リンクセグメントは整合性テストに合格していますが、自動ネゴシエーションは完了していません。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状態の適応は、リンクアップイベント通知を生成するために使用できます。ただし、これらの適応症は、パケットをブリッジドメインを介して受信できることを明確に保証するものではありません（次のセクションを参照）。このような操作は、ブリッジングによって管理されています。
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）を通じて達成されます。これらのプロトコルは、[IEEE-802.1d]で定義されているように、ブリッジプロトコルデータユニット（BPDUS）を交換します。これにより、必要に応じてポートのブロック（つまり、転送されない）につながります。
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 been lost. Upon this timeout, a link up notification is generated, if one has not been already.
Bridge_max_ageインターバル（デフォルト20秒）内にブリッジ構成メッセージが受信されない場合、橋渡し用にポートが有効になっている目に見えるブリッジがない可能性があります（[IEEE-802.1d]のS8.4.5）、少なくとも2つのBPDU Helloからメッセージは失われていたでしょう。このタイムアウトでは、まだそうでない場合、リンクアップ通知が生成されます。
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が受信され、隣接するブリッジが元のSpanningツリープロトコルを実行している場合、ホストは受信したBPDUの少なくとも2倍のフォワードデレイ値が経過するまでパケットを正常に送信できません。この時間の後、リンクアップ通知が生成されます。前のリンクアップ通知が非決定的である場合、この通知には、前の間隔内で送信されたパケットが失われたことを示す属性が含まれます。
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を待ちます。オートネゴシエーションを介してポイントツーポイントであることが知られているポートの場合、この遅延は、自動ネゴシエーションが完了してから3秒まで短縮されます[IEEE-802.1d]。
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が含まれている場合があります。ホストがシステム機能TLVを受信する場合、LLDPトランスミッターでブリッジングが発生していないことを示す場合、このトランスミッターを介して送信されたパケットに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ネットワークでは、ネットワークインターフェイスカード（NICS）は、多くの場合、ホストに速度と二重表示を返すことができます。これらの特性の変更は、新しいレイヤー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と同じ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]は、IEEE 802準拠の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.
著者リストにリストされている人々に加えて、このドキュメントでカバーされている特定のリンク層技術のテキストは、Thomas Noel（IEEE 802.11b）とGreg Daley（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.
著者は、バーナード・アボバ、サンジーエフ・アサリエ、ジンヒヨック・チョイ、ジョン・ラフニー、ペッカ・ニカンダー、ブレット・ペントランド、トム・ペッチ、ダン・ロマスカヌ、ペッカ・サヴォラ、スティーブ・ベロヴィン、トーマス・ナルテン、マット・マシス、アルフレッド・ホーエン、ムハマド・ムカラム彼らの有用なコメントと提案のために。
[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] "Digital Cellular Telecommunications System（フェーズ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 STD 802.11A-1999、IEEE STD 802.11-1999の補足、パート11：ワイヤレスMANメディアアクセス制御（MAC）および物理層（PHY）仕様：高 - 高1999年9月、IEEE Standard 802.11aの5 GHzバンドの速度物理層。
[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.11B]電気および電子機器エンジニア研究所、「IEEE STD 802パート11、情報技術 - システム間の通信と情報交換 - ローカルおよびメトロポリタンエリアネットワーク - 特定の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様 "、IEEE Standard 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.11G]電気および電子機器エンジニア研究所、「IEEE STD 802.11G-2003、IEEE STD 802.11、1999エディション、パート11：ワイヤレスMANメディアアクセス制御（MAC）および物理層（PHY）仕様。4：2003年6月、IEEE Standard 802.11gの2.4 GHzバンドのさらに高いデータレート拡張。
[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 STD 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 Standard 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 STD 802.3、2002。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472] Haskin、D。およびE. Allen、「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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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. Daley、「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]「技術仕様グループコアネットワーク;パケットベースのサービスとパケットデータネットワーク（PDN）（リリース6）をサポートするパブリックランドモバイルネットワーク（PLMN）間のインターネットワーク、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. Simpson、「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] El Malki、K。、「モバイルIPv4の低遅延ハンドオフ」、RFC 4881、2007年6月。
Authors' Addresses
著者のアドレス
Suresh Krishnan (editor) Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan（編集者）Ericsson Research 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
EMail: suresh.krishnan@ericsson.com
Nicolas Montavont GET ENST Bretagne 2, rue de la chataigneraie Cesson-Sevigne 35576 France
ニコラス・モンタヴォント・ゲット・エンスト・ブルターニュ2、rue de de la chataigneraie cesson-sevigne 35576フランス
Phone: (33) 2 99 12 70 23 EMail: nicolas.montavont@enst-bretagne.fr
電話：（33）2 99 12 70 23メール：nicolas.montavont@enst-bretagne.fr
Eric Njedjou France Telecom 4, Rue du Clos Courtel BP 91226 Cesson Sevigne 35512 France
Eric Njedjou France Telecom 4、Rue Du Clos Courtel BP 91226 CESSON SEVIGNE 35512 FRANCE
Phone: +33 299124878
EMail: eric.njedjou@orange-ftgroup.com
Siva Veerepalli Qualcomm 5775 Morehouse Drive San Diego, CA 92131 USA
Siva Veerepalli Qualcomm 5775 Morehouse Drive San Diego、CA 92131 USA
Phone: +1 858 658 4628
EMail: sivav@qualcomm.com
Alper E. Yegin (editor) Samsung Istanbul Turkey
Alper E. Yegin（編集者）サムスンイスタンブールトルコ
Phone: +90 533 348 2402
EMail: a.yegin@partner.samsung.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エディター機能の資金は現在、インターネット協会によって提供されています。