RFC4957 日本語訳
4957 Link-Layer Event Notifications for Detecting Network Attachments.S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin,Ed.. August 2007. (Format: TXT=41840 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのS.クリシュナン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4957年のエリクソン研究カテゴリ: 情報のN.Montavontは2007年8月にエドENSTブルターニュE.NjedjouフランステレコムS.VeerepalliクアルコムA.Yegin、三星を得ます。
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).
IETFが信じる著作権(C)(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が迅速に構成変更を検出するのを助けることができます。 このドキュメントはよく知られるアクセス技術から利用可能な情報の非徹底的なカタログを提供します。
Krishnan, et al. Informational [Page 1] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[1ページ]のRFC4957L2通知
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 リンクレイヤイベント通知. . . . . . . . . . . . . . . . 5 3.1。 GPRS/3GPP. . . . . . . . . . . . . . . . . . . . . . . . 6 3.2cdma2000/3GPP2. . . . . . . . . . . . . . . . . . . . . . 7 3.3。 IEEE802.11/WiFi. . . . . . . . . . . . . . . . . . . . . 8 3.4。 IEEE802.3CSMA/CD. . . . . . . . . . . . . . . . . . . . 9 3.4.1。 802.3のネットワーク. . . . . . . . 10 3.4で.2に保全テストをリンクしてください。 リンクレイヤイベント通知. . . . . . . . . . . . . . . . . 11 3.4.3へのIEEE 802.1Dのブリッジするのとその効果。 802.1 ABリンクレイヤ発見プロトコル. . . . . . . . 12 3.4.4。 他の発見的教授法. . . . . . . . . . . . . . . . . . . 13 3.4.5。 概要. . . . . . . . . . . . . . . . . . . . . . . 13 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 5。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 14 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 14 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 14 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 16
Krishnan, et al. Informational [Page 2] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[2ページ]のRFC4957L2通知
1. Introduction
1. 序論
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層のパラメタの再構成を必要とするかもしれません、IPアドレスや、デフォルトゲートウェイ情報や、DNSサーバアドレスなどのように。 サブネット変化を検出すると、通常、ネットワーク層指摘(IPv6のための広告を出している接頭語における変化などの)を使用できます。 しかし、そのような指摘はいつも接着点を変えるときのノードに利用可能であるかもしれないというわけではありません(例えば、IPv6(DNAv6)のDetecting Network Attachment)。
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.
イベントと共に追加情報を伝えることができます、ネットワーク付着点(例えば、IEEE802.11Basic Service Set Identification(BSSID)とService Set Identifier(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サブネットに付けられているかもしれません。 例えば、数IEEE802.11に、同じIPサブネットにアクセスポイントを付けることができます。 これらのアクセスポイントの中で移行するのは少しのIP-層の構成変更も保証しません。
Krishnan, et al. Informational [Page 3] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[3ページ]のRFC4957L2通知
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の間で定義されるかもしれません。 その活動はこのドキュメントの範囲を超えています。
2. Terminology
2. 用語
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: サービスセット識別子
Krishnan, et al. Informational [Page 4] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[4ページ]のRFC4957L2通知
3. Link-Layer Event Notifications
3. リンクレイヤイベント通知
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-層の構成をアップデートしなければならないかどうか決定する前に、他の入力(例えば、広告を出している接頭語の存在、デフォルトゲートウェイの可到達性)を取りそうです。 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.
リンクが上がっているのを示すことを望んでいる実装を収容するために、通知の上にリンクの非決定論的な使用法がありますが、データ伝送はネットワークで妨げられるかもしれません(IEEE802.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.
非決定論的なリンクであるなら、上は生成されました、リンクレイヤが決定論的な通知を生成することができるとすぐに必須尾行への別のリンク。 イベント属性は、ネットワークによって妨げられたか、または前の通知以来伝えられたパケットがあえて許容されたかどうかを示すかもしれません、リンクレイヤが正確な状態を決定できるなら。
Krishnan, et al. Informational [Page 5] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[5ページ]のRFC4957L2通知
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番目のリンクは確認プロセスの引き金となる必要はなくて、1つは1番目であるなら既にしました。
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つのリンクレイヤ技術を調べて、リンクレイヤ通知がいつ発生しているか、そして、どんな情報がそれに含まれているかを説明します。
3.1. GPRS/3GPP
3.1. GPRS/3GPP
GSM Packet Radio System (GPRS) provides packet-switched data transmission over a cellular network [GPRS][GPRS-LINK].
GSM Packet Radio System(GPRS)はセルラー・ネットワーク[GPRS][GPRS-LINK]の上にパケット交換データ送信を提供します。
The GPRS architecture consists of a Radio Access Network and a packet domain Core Network.
GPRSアーキテクチャはRadio Access NetworkとパケットドメインCore Networkから成ります。
- The GPRS Radio Access Network is composed of Mobile Terminals
(MTs), a Base Station Subsystem and Serving GPRS Support Nodes
(SGSNs).
- GPRS Radio Access NetworkはモバイルTerminals(MTs)、基地駅のSubsystemとServing GPRS Support Nodes(SGSNs)で構成されます。
Krishnan, et al. Informational [Page 6] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[6ページ]のRFC4957L2通知
- 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とゲートウェイGPRS Support Nodes(GGSNs)の間のユーザデータグラムの輸送バックボーンとして機能するIP Core Network。 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 Context協会を確立します。 PDP Contextが設立された後とだけアドレス自動構成とトンネリングメカニズムが行われた後に、同輩とそのリモートIP同輩からMTのIPパケットを進めることができます。 PDP Context設立の目的はまた、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 Contextのうまくいっている設立は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 Contextから取得されたIP構成を再利用している間、セカンダリPDP Contextを設立するかもしれません。 そのようなセカンダリPDP ContextはIP層に追加情報を供給しないで、別の品質を許容するだけです。-サービス(QoS)では、使用されるのは輪郭を描いてください。 新しいIPパラメタを必要としないので、通常、そのようなセカンダリPDP文脈の起動はイベントへのリンクを生成しません。 しかしながら、他の追加PDP Context起動は、より早く示されるように扱われることです。
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 Contextの一部として得られるMTのIPv4アドレスです。 IPv6で、PDP Context活性化反応は使用可能なIPv6アドレスと共に来ません。 事実上、メッセージのPDPアドレス・フィールドのGGSNから受け取られたIPv6アドレスは有効な接頭語を含んでいません。 ミネソタは実際にそれがその後有効な接頭語(例えば、状態がない[RFC2462][GPRS-CN]かstateful[RFC3315][GPRS-GSSA]アドレス構成による)を得るのに使用するリンクローカルアドレスを形成するためにその分野から抜粋されたインタフェース識別子を使用するだけです。 したがって、どんなIPv6関連の補助の情報もIP層に提供しません。
3.2. cdma2000/3GPP2
3.2. cdma2000/3GPP2
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パケット網アーキテクチャのいくつかの主要コンポーネントが以下から成ります。
Krishnan, et al. Informational [Page 7] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[7ページ]のRFC4957L2通知
- 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.
- ラジオAccess Network。(そのAccess Networkは基地の駅のTransceivers、基地の駅のControllersと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.
- Packet Data Switching Node(PDSN)として知られているAccess Serverをネットワークでつないでください。 また、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の間のリンク層プロトコルとしてPointからポイントへのプロトコル(PPP[RFC1661])を使用します。 どんなIPパケットも送るか、または受け取るかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、IP Controlプロトコル(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 Simple(すなわち、非モバイルの)IPv4 Serviceに使用されるとき、IPCPはMSに関するIPv4アドレスの構成を可能にします。リンクに伴う補助の情報としてこのIPv4アドレスを通知に提供します。 Simple IPv6サービスに使用されるIPV6CPはIPv6アドレスではなく、PPPリンクの地方の、そして、遠く離れた終点のためのインタフェース識別子を提供します。 インタフェース識別子と他のIP層の設定パラメータの間には、規格の強制された相関関係が全くないので、この情報はDNAの役に立たないと考えられます(それにもかかわらず、他の用途のための補助の情報としてそれを提供するかもしれません)。
3.3. IEEE 802.11/WiFi
3.3. IEEE802.11/WiFi
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]、IEEE802.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
2つのオペレーティング・モードがIEEE802.11シリーズ(インフラストラクチャモードかアドホック・モードのどちらか)で利用可能です。 インフラストラクチャモードで、すべてのリンクレイヤフレームが次に最終的な受信機にそれらを送るアクセスポイント(AP)に送信されます。ステーション(STA)は、IPパケットを送って、受けるためにAPとのIEEE802.11協会を設立します。 Robust Secure Network(RSN[IEEE-802.11i])を使用するWiFiネットワークでは、STAとAPの間の4ウェイ握手の無事終了はIPサービスの有用性を始めます。 リンクは上昇します。
Krishnan, et al. Informational [Page 8] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[8ページ]のRFC4957L2通知
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.
イベント通知はこのイベントで生成されます。 非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のユニークな識別子です。 SSIDはExtended Service Set(ESS)に関する識別子を運びます--一般的な流通制度を共有するAPsと関連STAsで構成されたセット。 リンクに伴う補助の情報としてBSSIDとSSIDを通知に提供するかもしれません。 残念ながら、この情報は動きのときにIP-層の構成を変えなければならないかどうか決定論的なしるしを供給しません。 BSSID/SSID組とIPサブネットとの1〜1つの規格で強制された関係が全くありません。 与えられたBSSIDとAPは複数のIPサブネットのいずれにもSTAを接続できます。 同様に、与えられたSSIDとESSは複数のIPサブネットにかかるかもしれません。 そして、最終的に、SSIDsはグローバルにユニークではありません。 同じSSIDは複数の独立しているESSsによって使用されるかもしれません。 それにもかかわらず、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)は直接互いにコミュニケートするかもしれません、すなわち、少しもインフラストラクチャや中間的ホップなしで。 STAsを伝えるセットは無党派Basic Service SetのためにIBSSと呼ばれます。 すなわち、単にIBSSでは、STAサービスは利用可能です。認証、反認証、プライバシー、およびMAC Service Data Unit(MSDU)配送。 STAsは互いと交際しないで、したがって、Distribution Systemが使用されていないなら(すなわち、「DS」と「DS」ビットは明確です)、州2(認証されて、関連づけられません)か状態1(非認証して、非連想しました)でさえデータフレームを交換するかもしれません。 認証が実行されるなら、認証のときに指示へのリンクを生成することができます。 リンクレイヤ識別に関して、BSSID(IBSSのSTAによって選ばれた無作為のMACアドレスである)とSSIDの両方が、IPにおけるどんな仮定もネットワーク・コンフィギュレーションにするのではなく、リンクを特定するのに使用されるかもしれません。
3.4. IEEE 802.3 CSMA/CD
3.4. IEEE802.3CSMA/CD
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].
IEEE802.3CSMA/CD(一般的にイーサネットと呼ばれる)は今日、使用中のローカル・エリア・ネットワーク技術であると最も一般的に配布されます。 今日配布されるように、物理的な層/媒体アクセス制御(MAC)層の仕様[IEEE-802.3]でそれは指定されます。 異なったLANの接続をより大きいネットワークに一緒に提供するために、802.3のLANがしばしば一緒に[IEEE-802.1D]ブリッジされます。
Krishnan, et al. Informational [Page 9] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[9ページ]のRFC4957L2通知
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 Test操作が、パケットがいつイーサネットセグメントに受け取ることができるかを特定するのに使用されます。 それはワイヤードなものと同様に光学の物理的な層に適切です、詳細は技術の間で異なりますが(撚り合わせている組銅におけるパルスをリンクしてください、繊維の中の光源レベル)。
3.4.1. Link Integrity Tests in 802.3 Networks
3.4.1. 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のネットワークにおけるリンクIntegrity Testsはその後、初期の物理接続時(例えば自動交渉段階で)と定期的に通常起こります。 彼らは、媒体が、リンク層のフレームが[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 Integrity Testで同じくらい断固としたリンクの状態は可変'リンク_状態'に保存されます。 技術依存するインタフェースがイーサネットデバイス[IEEE-802.3]で実装されると、リンク_状態(例えば、Link Integrity Testの故障による)の値への変化はリンク指摘を生成するでしょう。
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.
リンク_状態に、FAIL、READY、およびOK可能な値があります。 FAIL状態では、Link Integrity Testsは失敗しました。 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.
特定の状態への変遷のときに、Physical Medium Attachmentサブシステムは、PMA_がLINK.indicateであると生成します(_状態をリンクしてください)。 OK州のしるしは、イベント通知にリンクを生成するのに使用されるかもしれません。 これらの指摘は、もっとも、パケットがブリッジドメインを通して受け取ることができるのを決定的に確実にしません(次のセクションを見てください)。 そのような操作は、ブリッジすることによって、治められます。
Krishnan, et al. Informational [Page 10] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[10ページ]のRFC4957L2通知
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から一般的に成ります。 透明なブリッジは、アクティブなトポロジーには輪がないのを必要とします。 これはSpanning Treeプロトコル(STP)かRapid Spanning Treeプロトコル(RSTP)を通して達成されます。 これらのプロトコルは[IEEE-802.1D]で定義されるようにBridgeプロトコルData Units(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.
もっとも、著しく、ホストがそれらの上でアクティブな送信機なしで障害があるブリッジポートと非ブリッジポートを見分けるのは、簡単ではありません、Disabledポートがそれらの上にトラフィックを全く持たないで、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
ポートがブリッジするために可能にされるどんな目に見えるブリッジ([IEEE-802.1D]のS8.4.5)もありそうにはありません、Bridge_マックス_Age間隔(デフォルト20年代)中にブリッジ構成メッセージを全く受け取らないなら少なくとも2BPDU以来こんにちは、メッセージは持っているでしょう。
Krishnan, et al. Informational [Page 11] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[11ページ]のRFC4957L2通知
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が受け取られていて、隣接しているブリッジがオリジナルのSpanning Treeプロトコルを実行しているなら、少なくとも容認されたBPDUのForwardDelay値の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].
ブリッジがRapid Spanning Treeプロトコル(RSTP)を実行するとして特定されるなら、パケットレセプション(BPDUのマックスAge分野では、広告を出す)の後に代わりにBridge_マックス_Ageを待ちます、推進の前に。 自動交渉で二地点間であることが知られているポートに関しては、自動交渉が[IEEE-802.1D]を完成した後にこの遅れは3秒まで簡略化されています。
3.4.3. 802.1AB Link-Layer Discovery Protocol
3.4.3. 802.1 ABリンクレイヤ発見プロトコル
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 Link-層のプロトコル(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メッセージはSystem Capabilities TLVを含むかもしれません。(System Capabilities TLVはデバイスが現在使用しているMACとIP-層の機能について説明します)。 ホストがどんなBridgingもLLDP送信機の上に起こっていないのを示すSystem Capabilities 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送信機がブリッジ、ホストの広告であることを示しながらホストがSystem Capabilities 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に影響するかは、不明瞭です。
Krishnan, et al. Informational [Page 12] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[12ページ]のRFC4957L2通知
3.4.4. Other Heuristics
3.4.4. 他の発見的教授法
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のネットワークでは、Network Interface Cards(NICs)は速度と重複の指示をホストにしばしば返すことができます。 これらの特性における変化は新しい層2のネットワークに接続を示すかもしれません。
3.4.5. Summary
3.4.5. 概要
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.
イーサネットのようなネットワークにおけるリンクレイヤ指摘はスパニングツリー計算のため追加「非-広告を出」している遅れによって複雑にされます。 これは以前に上側の層のプロトコルに送られた指摘の再指示か取消しを引き起こすかもしれません。
4. Security Considerations
4. セキュリティ問題
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と共にAccess Pointをセットアップして、使用が本物の代わりににせのアクセスポイントに接続するのを手に入れるところに「悪双子」の攻撃と呼ばれる攻撃に影響されやすいです。 これらの攻撃は非都合のよいネットワークの使用かサービスの否定さえ引き起こすかもしれません。
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層のためにそのようなメカニズムを定義します。 また、さらに、プロトコル・スタックは、部分的な保護を達成するのにいくつかのネットワーク層メカニズムを使用するかもしれません。 例えば、ルータがある安全な可到達性を確認するのに、SEND[RFC3971]を使用できました。 しかしながら、ネットワーク層メカニズムはすべての問題に対処できません、適切に機能しないリンクに通じる不安定な下層通知などのように。
Krishnan, et al. Informational [Page 13] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[13ページ]のRFC4957L2通知
5. Contributors
5. 貢献者
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.
作者リストに記載された人々に加えて、このドキュメントでカバーされた特定のリンクレイヤ技術のためのテキストはトーマスNoel(IEEE 802.11b)とグレッグ・デイリー(IEEE802.3)によって寄付されました。 作者は彼らの取り組みについてこのドキュメントを実現する際に彼らに感謝したがっています。
6. Acknowledgements
6. 承認
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、Sanjeev Athalye、JinHyeockチェ、ジョンLoughney、ペッカNikander、ブレットPentland、トムPetch、ダンRomascanu、ペッカSavola、スティーブBellovin、トーマスNarten、マット・マシス、アルフレッドHoenes、およびムハンマドMukarram容器タリクを承認したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[CDMA2K] "cdma2000 Wireless IP Network Standard", ,
December 2000.
[CDMA2K]「cdma2000のワイヤレスのIPネットワーク規格」、12月2000日
[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)は記述を修理します。 3GPP TS03.60バージョン7.9.0Release98、2インチを上演してください。
[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 GSM03.05バージョン7.0.0Release98。
[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 Std802.11-1999、Part11に以下を補ってください」 ワイヤレスのMAN Medium Access Control(MAC)とPhysical Layer(PHY)仕様: 「5GHZバンドにおける高速Physical Layer」、IEEE Standard 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.11b]米国電気電子技術者学会、「情報技術--システムの間のテレコミュニケーションズと情報交換--IEEE Std802Part11、地方、およびメトロポリタンエリアネットワーク(決められた一定の要求)は11を分けます」。 「ワイヤレスのラン媒体アクセス制御(MAC)と物理的な層(PHY)の仕様」、IEEEの標準の802.11b、1999年8月。
Krishnan, et al. Informational [Page 14] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[14ページ]のRFC4957L2通知
[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 Std802.11g2003、IEEE Std802.11、1999版、Part11へのAmendment:」 ワイヤレスのMAN Medium Access Control(MAC)とPhysical Layer(PHY)仕様。 修正4: IEEE標準の802.11gと、2003年6月の「2.4ギガヘルツバンドにおけるさらなるより高いデータ信号速度拡大。」
[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/男性決められた一定の要求--パート11の規格に補ってください」 ワイヤレスのMedium Access Control(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]米国電気電子技術者学会、「地方の、そして、首都のネットワークの規格を作成してください」 「駅とメディアAccess Control Connectivityディスカバリー(草稿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規格--特定のRequirements、Part3:、」 「衝突検出型搬送波検知多重アクセス(CSMA/CD)はメソッドと物理的な層の仕様にアクセスする」ISO/IEC IEEE Std802.3、2002。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー(G.、「pppインターネットプロトコル制御プロトコル(IPCP)」RFC1332)は1992がそうするかもしれません。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
Krishnan, et al. Informational [Page 15] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[15ページ]のRFC4957L2通知
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2472] ハスキンとD.とE.アレン、「pppの上のIPバージョン6」、RFC2472、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", RFC 4135, August 2005.
JH[RFC4135]チェ、G.デイリー、「検出の目標は2005年8月にIPv6"、RFC4135で付属をネットワークでつなぎます」。
7.2. Informative References
7.2. 有益な参照
[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]「仕様書グループコアネットワーク」。 「ベースのサービスをパケットにサポートするPublic LandのモバイルNetwork(PLMN)とPacket Data Networksの間のインターネットワーキング(PDN)(リリース6)」、3GPP TS29.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 TS23.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)のための隣人発見」、RFC2461、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"、RFC4881、2007年6月の低遅延Handoffs。」
Krishnan, et al. Informational [Page 16] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[16ページ]のRFC4957L2通知
Authors' Addresses
作者のアドレス
Suresh Krishnan (editor) Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Sureshクリシュナン(エディタ)エリクソンResearch8400Decarie Blvd. 王立の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 GET ENSTブルターニュ2、de la chataigneraie Cesson-セビニェ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
エリックNjedjouフランステレコム4、Rue du Clos Courtel BP91226Cessonセビニェ35512・フランス
Phone: +33 299124878 EMail: eric.njedjou@orange-ftgroup.com
以下に電話をしてください。 +33 299124878はメールされます: eric.njedjou@orange-ftgroup.com
Siva Veerepalli Qualcomm 5775 Morehouse Drive San Diego, CA 92131 USA
シバVeerepalliクアルコム5775モアハウス・Driveカリフォルニア92131サンディエゴ(米国)
Phone: +1 858 658 4628 EMail: sivav@qualcomm.com
以下に電話をしてください。 +1 4628年の858 658メール: sivav@qualcomm.com
Alper E. Yegin (editor) Samsung Istanbul Turkey
Alper E.Yegin(エディタ)三星イスタンブールトルコ
Phone: +90 533 348 2402 EMail: a.yegin@partner.samsung.com
以下に電話をしてください。 +90 2402年の533 348メール: a.yegin@partner.samsung.com
Krishnan, et al. Informational [Page 17] RFC 4957 L2 Notifications for DNA August 2007
クリシュナン、他 DNA2007年8月のための情報[17ページ]のRFC4957L2通知
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Krishnan, et al. Informational [Page 18]
クリシュナン、他 情報[18ページ]
一覧
スポンサーリンク
