RFC4562 日本語訳
4562 MAC-Forced Forwarding: A Method for Subscriber Separation on anEthernet Access Network. T. Melsen, S. Blake. June 2006. (Format: TXT=30332 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Melsen
Request for Comments: 4562 S. Blake
Category: Informational Ericsson
June 2006
Melsenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4562秒間ブレークCategory: 情報のエリクソン2006年6月
MAC-Forced Forwarding:
A Method for Subscriber Separation on an Ethernet Access Network
MAC無理矢理の推進: イーサネットアクセスネットワークにおける加入者分離のためのメソッド
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 Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
このドキュメントは、ブリッジしているイーサネットセグメントの上でIPv4ゲートウェイにアクセスするローカル・エリア・ネットワーク(LAN)ステーションの層-2分離を確実にするためにメカニズムについて説明します。
The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts.
メカニズム(「MAC無理矢理の推進」と呼ばれる)は、サブネットにもかかわらず、異なった顧客構内の同じIPv4の中に位置したホストの間のイーサネットメディアAccess Control(MAC)アドレス解決を禁止するAddress Resolutionプロトコル(ARP)プロキシ機能を実装して、事実上、すべての上流のトラフィックをIPv4ゲートウェイに向けます。 IPv4ゲートウェイはIP-層の接続性をこれらの同じホストの間に提供します。
Melsen & Blake Informational [Page 1] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[1ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
Table of Contents
目次
1. Introduction ....................................................2
1.1. Access Network Requirements ................................3
1.2. Using Ethernet as an Access Network Technology .............4
2. Terminology .....................................................5
3. Solution Aspects ................................................6
3.1. Obtaining the IP and MAC Addresses of the Access Routers ...6
3.2. Responding to ARP Requests .................................7
3.3. Filtering Upstream Traffic .................................8
3.4. Restricted Access to Application Servers ...................8
4. Access Router Considerations ....................................8
5. Resiliency Considerations .......................................9
6. Multicast Considerations ........................................9
7. IPv6 Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. 序論…2 1.1. ネットワーク要件にアクセスしてください…3 1.2. アクセスとしてイーサネットを使用して、技術をネットワークでつないでください…4 2. 用語…5 3. ソリューション局面…6 3.1. アクセスルータのIPとMACアドレスを得ます…6 3.2. ARP要求に応じます…7 3.3. 上流のトラフィックをフィルターにかけます…8 3.4. アクセスをアプリケーション・サーバーに制限します…8 4. ルータ問題にアクセスしてください…8 5. 弾性問題…9 6. マルチキャスト問題…9 7. IPv6問題…10 8. セキュリティ問題…10 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…12
1. Introduction
1. 序論
The main purpose of an access network is to provide connectivity between customer hosts and service provider access routers (ARs), typically offering reachability to the Internet and other IP networks and/or IP-based applications.
アクセスネットワークの主な目的は顧客ホストとサービスプロバイダーアクセスルータ(ARs)の間に接続性を提供することです、インターネットと他のIPネットワーク、そして/または、IPベースのアプリケーションに可到達性を通常提供して。
An access network may be decomposed into a subscriber line part and an aggregation network part. The subscriber line - often referred to as "the first mile" - is characterized by an individual physical (or logical, in the case of some wireless technologies) connection to each customer premises. The aggregation network - "the second mile" - performs aggregation and concentration of customer traffic.
アクセスネットワークは加入者系列部分と集合ネットワーク一部に分解されるかもしれません。 加入者回線(しばしば「最初のマイル」と呼ばれる)は物理的で、(いくつかの無線技術の場合で論理的)の個人によって特徴付けられます。顧客が仮定するそれぞれとの接続。 集合ネットワーク(「2番目のマイル」)は顧客トラフィックの集合と集中を実行します。
The subscriber line and the aggregation network are interconnected by an Access Node (AN). Thus, the AN constitutes the border between individual subscriber lines and the common aggregation network. This is illustrated in the following figure.
加入者系列と集合ネットワークはAccess Node(AN)によってインタコネクトされます。 したがって、ANは個々の加入者系列と一般的な集合ネットワークとの境界を構成します。 これは以下の図で例証されます。
Melsen & Blake Informational [Page 2] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[2ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
Access Aggregation Access Subscriber Customer
Routers Network Nodes Lines Premises
Networks
+----+ |
--+ AR +-----------| +----+
+----+ | | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
+----+ | | +----------------[]--------
--+ AR +-----------| +----+
+----+ |
集合アクセス加入者顧客ルータがネットワークでつなぐアクセスは+をネットワークでつなぎますノード線が、前提である。----+ | --+ アルゴン+-----------| +----+ +----+ | | +----------------[]-------- |--------+| | | +----------------[]-------- | +----+ | | +----+ | | +----------------[]-------- |--------+| | | +----------------[]-------- | +----+ | | +----+ | | +----------------[]-------- |--------+| +----+ | | +----------------[]-------- --+ アルゴン+-----------| +----+ +----+ |
1.1. Access Network Requirements
1.1. アクセスネットワーク要件
There are two basic requirements that an access network solution must satisfy:
アクセスネットワークソリューションが満足させられなければならないという2つの基本的な要件があります:
1. Layer-2 separation between customer premises.
1. 顧客構内の間の層-2分離。
2. High IPv4 address assignment efficiency.
2. 高いIPv4は課題効率を扱います。
It is required that all traffic to and from customer hosts located at different premises (i.e., accessed via different subscriber lines or via different access networks) be forwarded via an AR, and not bridged or switched at layer-2 (Requirement 1; see also requirement R-40 in [TR101]). This enables the access network service provider to use the AR(s) to perform security filtering, policing, and accounting of all customer traffic. This implies that within the access network, layer-2 traffic paths should not exist that circumvent an AR (with some exceptions; see Section 3.4).
ホストと異なった構内(すなわち、異なった加入者系列の近く、または、異なったアクセスネットワークを通して、アクセスされる)に位置する顧客ホストからのすべてのトラフィックが層-2でARを通して進められて、ブリッジされるというわけではありませんし、また切り換えられるというわけではないのが必要です(要件1; また、[TR101]で要件R-40を見てください)。 これは、アクセスネットワークサービスプロバイダーがセキュリティフィルタリングを実行するのにAR(s)を使用するのを可能にします、すべての顧客トラフィックについて取り締まって、説明して。 これは、アクセスネットワークの中では、層-2つのトラフィック経路が存在するべきでないのを含意します。それはARを回避します(いくつかの例外で; セクション3.4を見てください)。
In ATM-based access networks, the separation of individual customer hosts' traffic is an intrinsic feature achieved by the use of ATM permanent virtual connections (PVCs) between the customers' access device (e.g., DSL modem) and the AR (typically co-located/integrated with access control functionality in a Broadband Remote Access Server
ATMを拠点とするアクセスネットワークでは、個々の顧客ホストのトラフィックの分離が顧客のアクセスデバイス(例えば、DSLモデム)とARの間のATM相手固定接続(PVCs)の使用で獲得された本質的な特徴である、(Broadband Remote Access Serverのアクセス制御の機能性と通常共同見つけられているか、または統合されます。
Melsen & Blake Informational [Page 3] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[3ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
(BRAS)). In this case, the AN is an ATM-based Digital Subscriber Line Access Multiplexer (DSLAM).
(ブラ。) この場合、ANはATMベースのDigital Subscriber線Access Multiplexer(DSLAM)です。
This document, however, targets Ethernet-based access networks. Techniques other than ATM PVCs must be employed to ensure the desired separation of traffic to and from individual customer hosts.
しかしながら、このドキュメントはイーサネットを拠点とするアクセスネットワークを狙います。 ホストと、そして、個々の顧客ホストからトラフィックの必要な分離を確実にするのにATM PVCs以外のテクニックを使わなければなりません。
Efficient address assignment is necessary to minimize consumption of the scarce IPv4 address space (Requirement 2). See [RFC3069] for further discussion. Address assignment efficiency is improved if host addresses are assigned out of one or more large pools, rather than by being assigned out of separate, smaller subnet blocks allocated to each customer premises. IPv6 address assignment efficiency is of much less concern, and it is anticipated that IPv6 deployments will allocate separate IPv6 subnet blocks to each customer premises [v6BB].
効率的なアドレス課題が、不十分なIPv4アドレス空間(要件2)の消費を最小にするのに必要です。 さらなる議論に関して[RFC3069]を見てください。 ホスト・アドレスが顧客が仮定するそれぞれに割り当てられた別々の、そして、よりわずかなサブネットブロックから割り当てられることによってというよりむしろ1つ以上の大きいプールから割り当てられるなら、アドレス課題効率は改良されています。 IPv6アドレス課題効率はまして、関心のものです、そして、IPv6展開がそれぞれの顧客構内[v6BB]に別々のIPv6サブネットブロックを割り当てると予期されます。
1.2. Using Ethernet as an Access Network Technology
1.2. アクセスネットワーク技術としてイーサネットを使用します。
A major aspect of using Ethernet as an access technology is that traffic pertaining to different customer hosts is conveyed over a shared broadcast network. Layer-2 isolation between customer premises networks could be provided by implementing access router functionality in each EAN, treating each subscriber line as a separate IP interface. However, there are a variety of reasons why it is often desirable to avoid IP routing in the access network, including the need to satisfy regulatory requirements for direct layer-2 accessibility to multiple IP service providers. In addition, this solution would not solve Requirement 2.
アクセス技術が異なった顧客ホストに関係するそのトラフィックであるのでイーサネットを使用する主要な局面は共有された放送網の上に伝えられます。 アクセスが各EANのルータの機能性であると実装することによって、顧客構内ネットワークの間の層-2分離を提供できるでしょう、別々のIPインタフェースとしてそれぞれの加入者系列を扱って。 しかしながら、アクセスネットワークでIPルーティングを避けるのがしばしば望ましいさまざまな理由があります、複数のIPサービスプロバイダーへのダイレクト層-2のアクセシビリティのための法的な要求事項を満たす必要性を含んでいて。 さらに、このソリューションはRequirement2を解決しないでしょう。
To avoid IP routing within the access network, the Ethernet aggregation network is bridged via EANs to individual Ethernet networks at the customers' premises. If the EANs were standard Ethernet bridges, then there would be direct layer-2 visibility between Ethernet stations (hosts) located at different customers' premises. Specifically, hosts located within the same IP subnet would have this visibility. This violates Requirement 1 (Section 1.1) and introduces security issues, as malicious end-users thereby can attack hosts at other customers' premises directly at the Ethernet layer.
アクセスネットワークの中でIPルーティングを避けるために、イーサネット集合ネットワークは顧客の構内の個々のイーサネットネットワークへのEANsを通してブリッジされます。 EANsが標準のイーサネットブリッジであるなら、異なった顧客の構内に位置するイーサネットステーション(ホスト)の間には、層-2目に見えることがダイレクトにあるでしょうに。 明確に、同じIPサブネットの中に位置したホストはこの目に見えることを持っているでしょう。 これは、Requirement1(セクション1.1)に違反して、安全保障問題を紹介します、その結果、悪意があるエンドユーザは直接イーサネット層の他の顧客の構内でホストを攻撃できます。
Existing standardized solutions may be deployed to prevent layer-2 visibility between stations:
既存の標準液はステーションの間の層-2目に見えることを防ぐために配布されるかもしれません:
o PPP over Ethernet [RFC2516]. The use of PPPoE creates individual
PPP sessions between hosts and one or more BRASes over a bridged
Ethernet topology. Traffic always flows between a BRAS and hosts,
o イーサネット[RFC2516]の上のppp。 PPPoEの使用はホストと1BRASesとの個々のPPPセッションをブリッジしているイーサネットトポロジーの上に作成します。 トラフィックはBRASとホストの間をいつも流れます。
Melsen & Blake Informational [Page 4] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[4ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
never directly between hosts. The AN can force upstream traffic
to flow only to the BRAS initially selected by the host.
直接ホストの間で決してそうしません。 ANによって、トラフィックは上流へやむを得ず初めはホストによって選択されたBRASだけに注ぐことができます。
o VLAN per-customer premises network [RFC3069]. Traffic to/from
each customer premises network can be separated into different
VLANs across the aggregation network between the AN and the AR.
o 1顧客あたりのVLAN構内は[RFC3069]をネットワークでつなぎます。 ANとARの間の集合ネットワークの向こう側に構内がネットワークでつなぐ各顧客からの/へのトラフィックを異なったVLANsに切り離すことができます。
Both solutions provide layer-2 isolation between customer hosts, but they are not considered optimal for broadband access networks, because:
両方のソリューションが層-2分離を顧客ホストの間に提供しますが、彼らが広帯域アクセスネットワークに最適であることは考えられない、:
o PPPoE does not support efficient multicast: packets must be
replicated on each PPPoE session to hosts listening on a specific
multicast group. This negates one of the major advantages of
using Ethernet (instead of ATM) as an access technology. This is
an especially problematic limitation for services such as IPTV,
which require high bandwidth per-multicast group (channel), and
which may often have hundreds or thousands of listening customer
hosts per group.
o PPPoEは効率的なマルチキャストをサポートしません: それぞれのPPPoEセッションのときに特定のマルチキャストグループで聴いているホストにパケットを模写しなければなりません。 これはアクセス技術としてイーサネット(ATMの代わりに)を使用する主要な利点の1つを否定します。 これはIPTVなどのサービスのための特に問題の多い制限です。(IPTVは1マルチキャストあたりの高帯域グループ(チャンネル)を必要として、しばしば1グループあたりの顧客ホストを聴く数百か数千を持っているかもしれません)。
o Using VLANs to isolate individual customer premises networks also
forces multicast packets to be replicated to each VLAN with a
listening host. Furthermore, the basic limit of a maximum of 4096
VLANs per-Ethernet network limits the scalability of the solution.
This scalability limit can be removed by deploying VLAN stacking
techniques within the access network, but this approach increases
provisioning complexity.
o 孤立している個々の顧客構内へのVLANsがネットワークでつなぐ使用によって、また、マルチキャストパケットは聴取ホストと共に各VLANにやむを得ず模写されます。 その上、イーサネットがネットワークでつなぐ最大4096VLANsの基本的な限界はソリューションのスケーラビリティを制限します。 アクセスネットワークの中で積み重ねのテクニックをVLANに配布することによって、このスケーラビリティ限界を取り除くことができますが、この進入路は複雑さに食糧を供給しながら、増加します。
The solution proposed in this document avoids these problems.
本書では提案されたソリューションはこれらの問題を避けます。
2. Terminology
2. 用語
Access Node (AN)
The entity interconnecting individual subscriber lines to the
shared aggregation network.
実体の内部連絡している個々の加入者のアクセスNode(AN)は共有された集合ネットワークまで立ち並んでいます。
Access Router (AR)
The entity interconnecting the access network to the Internet or
other IP-based networks. The AR provides connectivity between
hosts on the access network at different customer premises. It is
also used to provide security filtering, policing, and accounting
of customer traffic.
Router(AR)にアクセスしてください。インターネットか他のIP接続を基本にしたネットワークとアクセスネットワークとインタコネクトする実体。 ARは異なった顧客構内のアクセスネットワークでホストの間に接続性を提供します。 また、顧客トラフィックについて取り締まって、説明して、セキュリティフィルタリングを提供するのも使用されています。
Application Server (AS)
A server, usually owned by a service provider, that attaches
directly to the aggregation network and is directly reachable at
layer-2 by customer hosts.
サーバであって、通常、サービスプロバイダーによって所有されているアプリケーションServer(AS)、それは、直接集合ネットワークに付いて、顧客ホストで層-2で直接届いています。
Melsen & Blake Informational [Page 5] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[5ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
Ethernet Access Node (EAN)
An Access Node supporting Ethernet-based subscriber lines and
uplinks to an Ethernet-based aggregation network and MAC-Forced
Forwarding. For example, for xDSL access, the EAN is an
Ethernet-centric DSLAM. The EAN is a special type of filtering
bridge that does not forward Ethernet broadcast and multicast
frames originating on a subscriber line to other subscriber lines,
but either discards them or forwards them upstream (towards the
aggregation network). The EAN also discards unicast Ethernet
frames that originate on a subscriber line and are not addressed
to an AR.
イーサネットベースの集合へのイーサネットベースの加入者系列をサポートするAccess NodeとアップリンクがネットワークでつなぐイーサネットAccess Node(EAN)とMAC無理矢理のForwarding。 例えば、xDSLアクセスのために、EANはイーサネット中心のDSLAMです。 EANが加入者系列で他の加入者系列に起因するイーサネット放送とマルチキャストフレームを進めないブリッジをフィルターにかける特別なタイプですが、どちらかが、上流へ(集合ネットワークに向かって)それらを捨てるか、またはそれらを進めます。 また、EANは加入者系列で起因して、ARに扱われないユニキャストイーサネットフレームを捨てます。
3. Solution Aspects
3. ソリューション局面
The basic property of the solution is that the EAN ensures that upstream traffic is always sent to a designated AR, even if the IP traffic should ultimately flow between customer hosts located within the same IP subnet.
ソリューションの基礎特性はEANが、上流のトラフィックがいつも指定されたARに送られるのを確実にするということです、IPトラフィックが結局同じIPサブネットの中に位置した顧客ホストの間を流れても。
The solution has three major aspects:
ソリューションには、3つの主要な局面があります:
1. Initially, the EAN obtains the IP and MAC addresses of the allowed
target ARs for each customer host.
1. 初めは、EANは許容目標ARsのIPとMACアドレスをそれぞれの顧客ホストとして得ます。
2. The EAN replies to any upstream ARP request [RFC0826] from
customer hosts with the MAC address of an allowed target AR.
2. EANは許容目標ARのMACアドレスで顧客ホストからARPが要求するどんな上流[RFC0826]にも答えます。
3. The EAN discards any upstream unicast traffic to MAC addresses
other than the allowed target ARs. The EAN also discards all
non-essential broadcast and multicast packets received on
subscriber lines.
3. EANは許容目標ARs以外のMACアドレスへのどんな上流のユニキャストトラフィックも捨てます。 また、EANはすべての不要不急な放送と加入者系列で受けられたマルチキャストパケットを捨てます。
These aspects are discussed in the following sections.
以下のセクションでこれらの局面について議論します。
3.1. Obtaining the IP and MAC Addresses of the Access Routers
3.1. アクセスルータのIPとMACアドレスを得ます。
An access network may contain multiple ARs, and different hosts may be assigned to different (groups of) ARs. This implies that the EAN must register the assigned AR addresses on a per-customer host basis.
アクセスネットワークが複数のARsを含むかもしれなくて、異なったホストが異なるのに選任されるかもしれない、(分類する、)、ARs。 これは、EANが1顧客あたり1個のホストベースに関する割り当てられたARアドレスを登録しなければならないのを含意します。
For each customer host, one of the ARs is acting as the default gateway. If a customer has simultaneous access to multiple ARs, the other ARs typically will provide access to other IP networks.
それぞれの顧客ホストに関しては、ARsの1つはデフォルトゲートウェイとして機能しています。 顧客が複数のARsに同時アクセスを持っていると、他のARsは他のIPネットワークへのアクセスを通常提供するでしょう。
The EAN learns the IPv4 address of the allowed target ARs in one of two ways, depending on the host IPv4 address assignment method. For each host using Dynamic Host Configuration Protocol (DHCP), the EAN learns the AR IPv4 addresses dynamically by snooping the DHCPACK
EANは2つの方法の1つで許容目標ARsのIPv4アドレスを学びます、ホストIPv4アドレス課題メソッドによって。 Dynamic Host Configuration Protocol(DHCP)を使用している各ホストに関しては、EANは、DHCPACKについて詮索することによって、ダイナミックにAR IPv4アドレスを学びます。
Melsen & Blake Informational [Page 6] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[6ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
reply to a host [RFC2131]. If a host using DHCP shall have simultaneous access to multiple ARs, DHCP option 121 [RFC3442] or DHCP option 33 [RFC2132] must be used to specify them for that host. If static address assignment is used instead of DHCP, then AR IPv4 addresses must be pre-provisioned in the EAN by the network operator. In both cases, the EAN will ARP to determine the ARs' corresponding MAC addresses. This can be done immediately after the IPv4 addresses are learned or when the MAC addresses are first required.
ホスト[RFC2131]に答えてください。 DHCPを使用しているホストが複数のARsに同時アクセスを持っているものとするなら、そのホストに彼らを指定するのに、DHCPオプション121[RFC3442]かDHCPオプション33[RFC2132]を使用しなければなりません。 静的なアドレス課題がDHCPの代わりに使用されるなら、ネットワーク・オペレータはEANでAR IPv4アドレスにあらかじめ食糧を供給しなければなりません。 どちらの場合も、EANは、ARPがARsの対応するMACアドレスを決定することを望んでいます。 IPv4アドレスが学習される直後最初にMACアドレスを必要とするのに、これができます。
The DHCP server can associate customer hosts with subscriber lines if the EAN uses the DHCP Relay Agent Information Option (82) to convey a subscriber line identifier to the DHCP server in DHCP messages flowing upstream from the customer host [RFC3046].
EANが顧客ホスト[RFC3046]から逆流しながらDHCPメッセージで加入者系列識別子をDHCPサーバに伝えるのにDHCP Relayエージェント情報Option(82)を使用するなら、DHCPサーバは顧客ホストを加入者系列に関連づけることができます。
3.2. Responding to ARP Requests
3.2. ARP要求に応じます。
If all customer networks were assigned individual IP subnet blocks (and if routing protocols were blocked inside the access network), then all upstream traffic would normally go to an AR (typically the default gateway), and the EAN could validate all upstream traffic by checking that the destination MAC address matched that of an AR.
個々のIPサブネットブロックがすべての顧客ネットワークに配属されるなら(ルーティング・プロトコルがアクセスネットワークの中で妨げられたなら)、通常、すべての上流のトラフィックがAR(通常デフォルトゲートウェイ)に行くでしょうに、そして、送付先MACアドレスがARのものに合っていたのをチェックすることによって、EANはすべての上流のトラフィックを有効にすることができるでしょう。
However, to comply with Requirement 2 of Section 1.1, residential customer networks are not (usually) assigned individual IPv4 subnet blocks. In other words, several hosts located at different premises are within the same IPv4 subnet. Consequently, if a host wishes to communicate with a host at another premises, an ARP request is issued to obtain that host's corresponding MAC address. This request is intercepted by the EAN's ARP proxy, and an ARP reply is sent, specifying an allowed AR MAC address (typically the default gateway's) as the requested layer-2 destination address, in a manner similar to the "proxy ARP" mechanism described in [RFC1812]. In this way, the ARP table of the requesting host will register an AR MAC address as the layer-2 destination for any host within that IPv4 subnet (except those at the same customer premises; see below).
しかしながら、セクション1.1のRequirement2に従うために、(通常、)個々のIPv4サブネットブロックは住宅用顧客ネットワークに配属されません。 言い換えれば、異なった構内に位置する数人のホストが同じIPv4サブネットの中にいます。 その結果、ホストが別の構内のホストとコミュニケートしたいなら、ARP要求は、そのホストの対応するMACアドレスを得るために出されます。 EANのARPプロキシはこの要求を妨害します、そして、ARP回答を送ります、要求された層-2送付先アドレスとして許容AR MACアドレス(通常デフォルトゲートウェイのもの)を指定して、[RFC1812]で説明された「プロキシARP」メカニズムと同様の方法で。 このように、要求ホストのARPテーブルはどんなホストのための層-2の目的地としてもそのIPv4サブネットの中にAR MACアドレスを登録するでしょう(同じ顧客構内のそれらを除いて; 以下を見てください)。
ARP requests for an IPv4 address of an allowed target AR are replied to by the EAN's ARP proxy with that AR's MAC address, rather than the MAC address of the default gateway AR.
許容目標ARのIPv4アドレスを求めるARP要求はデフォルトゲートウェイARのMACアドレスよりむしろそのARのMACアドレスでEANのARPプロキシによって答えられます。
An exception is made when a host is ARPing for another host located within the same premises network. If this ARP request reaches the EAN, it should be discarded, because it is assumed to be answered directly by the target host within the premises network. The EAN must keep track of all assigned IPv4 addresses on a subscriber line so that it can detect these ARP requests and discard them.
ホストが同じ構内ネットワークの中に位置した別のホストのためのARPingであるときに、例外は作られます。 このARP要求がEANに達するなら、それは捨てられるべきです、それが構内ネットワークの中で直接目標ホストによって答えられると思われるので。 EANは、これらのARP要求を検出して、それらを捨てることができるように、加入者系列に関するすべての割り当てられたIPv4アドレスの動向をおさえなければなりません。
Melsen & Blake Informational [Page 7] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[7ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
3.3. Filtering Upstream Traffic
3.3. 上流のトラフィックをフィルターにかけます。
Since the EAN's ARP proxy will always reply with the MAC address of an AR, the requesting host will never learn MAC addresses of hosts located at other premises. However, malicious customers or malfunctioning hosts may still try to send traffic using other unicast destination MAC addresses. The EAN must discard all unicast frames received on a subscriber line that are not addressed to a destination MAC address for an allowed AR (with some exceptions; see Section 3.4.
EANのARPプロキシがいつもARのMACアドレスで返答するので、要求ホストは、ホストのMACアドレスが他の構内で場所を見つけられたことを決して学ばないでしょう。 しかしながら、悪意がある顧客か誤動作しているホストが、他のユニキャスト送付先MACアドレスを使用することでまだトラフィックを送ろうとするかもしれません。 EANは許容ARのための送付先MACアドレスに扱われないで、フレームが加入者系列で受けたすべてのユニキャストを捨てなければなりません。(若干の例外はあるものの、セクション3.4を見てください。
Similarly, broadcast or multicast packets received on a subscriber line must never be forwarded on other subscriber lines, but only on EAN uplinks to the aggregation network. An EAN must discard all non-ARP broadcast packets received on subscriber lines, except when DHCP is in use, in which case, the EAN must forward client-to-server DHCP broadcast messages (DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPINFORM) [RFC2131] upstream. An EAN should rate limit upstream broadcast packets.
同様に、他の加入者系列、しかし、単にEANアップリンクのときに加入者系列で受けられた放送かマルチキャストパケットを集合ネットワークに決して送ってはいけません。 EANは加入者系列に受け取られたすべての非ARP放送パケットを捨てなければなりません、DHCPが使用中である時を除いて、その場合EANは上流へ、クライアントからサーバへのDHCP同報メッセージ(DHCPDISCOVER、DHCPREQUEST、DHCPDECLINE、DHCPINFORM)[RFC2131]を転送しなければなりません。 EANは、限界が上流の放送パケットであると評定するはずです。
Broadcast packets forwarded on an EAN uplink may be forwarded to other EANs by the aggregation network. EANs should discard all broadcast packets received from the aggregation network, except ARPs from ARs for subscriber hosts and server-to-client DHCP messages (DHCPOFFER, DHCPACK, DHCPNAK) [RFC2131], when DHCP is in use.
EANアップリンクに送られた放送パケットは集合ネットワークによって他のEANsに送られるかもしれません。 EANsは集合ネットワークから受け取られたすべての放送パケットを捨てるはずです、加入者ホストとサーバからクライアントへのDHCPメッセージ(DHCPOFFER、DHCPACK、DHCPNAK)[RFC2131]のためのARsからのARPsを除いて、DHCPが使用中であるときに。
Filtering of multicast packets to and from an EAN uplink is discussed in Section 6.
セクション6でアップリンクとEANアップリンクからのマルチキャストパケットのフィルタリングについて議論します。
3.4. Restricted Access to Application Servers
3.4. アプリケーション・サーバーへの制限されたアクセス
The previous discussion (Section 3.1) describes how customer hosts are allowed direct layer-2 connectivity only to one or more ARs. Similarly, a customer host could be allowed direct layer-2 access to one or more Application Servers (ASes) which are directly connected to the aggregation network. There is no functional difference in the way MAC-Forced Forwarding treats access to ARs and ASes.
前の議論(セクション3.1)はダイレクト層-2の接続性がどう単に1ARsまで許容されているかを顧客ホストに説明します。 同様に、直接集合ネットワークに接続される1Application Servers(ASes)へのダイレクト層-2アクセスを顧客ホストに許すことができました。 MAC無理矢理のForwardingがARsとASesへのアクセスを扱う方法のどんな機能的な違いもありません。
4. Access Router Considerations
4. アクセスルータ問題
Traffic between customer hosts that belong to the same IPv4 subnet but are located at different customer premises will always be forwarded via an AR. In this case, the AR will forward the traffic to the originating network, i.e., on the same interface from where it was received. This normally results in an ICMP redirect message [RFC0792] being sent to the originating host. To prevent this behavior, the ICMP redirect function for aggregation network interfaces must be disabled in the AR.
ARを通していつも同じIPv4サブネットに属しますが、異なった顧客構内に位置している顧客ホストの間のトラフィックを進めるでしょう。 この場合、ARは起因するネットワークにトラフィックを送るでしょう、すなわち、それが受け取られたところからの同じインタフェースで。 通常、これは、送信元ホストに送りながら、ICMPの再直接のメッセージ[RFC0792]をもたらします。 この振舞いを防ぐために、ARで集合ネットワーク・インターフェースへのICMPの再直接の機能を無効にしなければなりません。
Melsen & Blake Informational [Page 8] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[8ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
5. Resiliency Considerations
5. 弾性問題
The operation of MAC-Forced Forwarding does not interfere with or delay IP connectivity recovery in the event of a sustained AR failure. Use of DHCP to configure hosts with information on multiple, redundant ARs, or use of Virtual Router Redundancy Protocol (VRRP) [RFC3768] to implement AR redundancy, allows IP connectivity to be maintained.
MAC無理矢理のForwardingの操作は、持続しているARの故障の場合、IP接続性回復を妨げもしませんし、遅らせもしません。 複数の、そして、余分なARsの情報でホストを構成するDHCPの使用、またはARが冗長であると実装するVirtual Router Redundancyプロトコル(VRRP)[RFC3768]の使用が、IPの接続性が維持されるのを許容します。
MAC-Forced Forwarding is a stateful protocol. If static IPv4 address assignment is used in the access network, then the EAN must be pre- provisioned with state information for the customer hosts which may be reached via a subscriber line, and the ARs associated with those hosts. In the event of a transient EAN failure, the EAN's state database can be quickly recovered from its configuration storage.
MAC無理矢理のForwardingはstatefulプロトコルです。 静的なIPv4アドレス課題がアクセスネットワークに使用されるなら、顧客ホストへの加入者系列、およびそれらのホストに関連しているARsを通して達するかもしれない州の情報でEANにあらかじめ食糧を供給しなければなりません。 一時的なEANの故障の場合、すばやくEANの州のデータベースから構成ストレージを取り戻すことができます。
If DHCP is used to assign IPv4 addresses in the access network, then MAC-Forced Forwarding operates as a soft-state protocol. Since the DHCP and ARP messages that are snooped to construct the EAN state database are usually sent infrequently, a transient failure may not be detected by either the AR(s) or the customer hosts. Therefore, a transient failure of an EAN could lead to an extended loss of connectivity. To minimize connectivity loss, an EAN should maintain its dynamic state database in resilient storage to permit timely database and connectivity restoration.
DHCPがアクセスネットワークでアドレスをIPv4に割り当てるのに使用されるなら、MAC無理矢理のForwardingは軟性国家プロトコルとして作動します。 通常EAN州のデータベースを構成するために詮索されるDHCPとARPメッセージをまれに送るので、一時障害はAR(s)か顧客ホストのどちらかによって検出されないかもしれません。 したがって、EANの一時障害は接続性の拡張損失を出すかもしれません。 接続性の損失を最小にするなら、EANは、タイムリーなデータベースと接続性回復を可能にするために立ち直りの早いストレージにおける動態データベースを維持するはずです。
The EAN is a single point of attachment between a subscriber line and the aggregation network; hence, the EAN is a single point of connectivity failure. Customers seeking more resilient connectivity should multi-home.
EANは加入者系列と集合ネットワークの間の1接着点です。 したがって、EANは1ポイントの接続性失敗です。 より弾力がある接続性を求めている顧客はマルチ家でそうするべきです。
6. Multicast Considerations
6. マルチキャスト問題
Multicast traffic delivery for streams originating within the aggregation network or further upstream and delivered to one or more customer hosts in an access network is supported in a scalable manner by virtue of Ethernet's native multicast capability. Bandwidth efficiency can be enhanced if the EAN behaves as an IGMP snooping bridge; e.g., if it snoops on IGMP Membership Report and Leave Group messages originating on subscriber lines to prune the set of subscriber lines on which to forward particular multicast groups [RFC3376].
アクセスネットワークで集合ネットワークか一層の上流の中で起因して、1人以上の顧客ホストに提供されたストリームのためのマルチキャストトラフィック配送はイーサネットのネイティブのマルチキャスト能力によってスケーラブルな方法でサポートされます。 EANがIGMP詮索ブリッジとして振る舞うなら、帯域幅効率を高めることができます。 例えば、IGMP Membership ReportとLeave Groupメッセージで詮索するなら、加入者の上で起因するのは、特定のマルチキャストグループ[RFC3376]を転送する加入者系列のセットから余計なものを取り除くために立ち並んでいます。
An EAN must discard all IPv4 multicast packets received on a subscriber line other than IGMP Membership Report and Leave Group messages [RFC3376]. If a customer host wishes to source multicast packets to a group, the host must tunnel them upstream to a multicast router; e.g., an AR acting as a Protocol Independent Multicast -
EANはIGMP Membership Report以外の加入者系列とLeave Groupメッセージ[RFC3376]に受け取られたすべてのIPv4マルチキャストパケットを捨てなければなりません。 顧客ホストがグループへのソースマルチキャストパケットに願うなら、ホストは上流へマルチキャストルータにそれらにトンネルを堀らなければなりません。 例えば、プロトコル無党派Multicastとして機能するAR、-
Melsen & Blake Informational [Page 9] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[9ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
Sparse Mode (PIM-SM) Designated Router [RFC2362]. An AR will forward them back into the access network if there are any listening customer hosts.
まばらなモード(PIM-Sm)はルータ[RFC2362]を指定しました。 何か聴取顧客ホストがいれば、ARはアクセスネットワークにそれらを送って戻すでしょう。
EAN processing of IPv6 multicast packets is discussed in the next section.
次のセクションでIPv6マルチキャストパケットのEAN処理について議論します。
7. IPv6 Considerations
7. IPv6問題
MAC-Forced Forwarding is not directly applicable for IPv6 access networks for the following reasons:
IPv6アクセスネットワークには、MAC無理矢理のForwardingは以下の理由で直接適切ではありません:
1. IPv6 access networks do not require the same efficiency of address
allocation as IPv4 access networks. It is expected that customer
premises networks will be allocated unique network prefixes (e.g.,
/48) accommodating large numbers of customer subnets and hosts
[v6BB].
1. IPv4がネットワークにアクセスするとき、IPv6アクセスネットワークはアドレス配分の同じ効率を必要としません。 ユニークなネットワーク接頭語(例えば、/48)が多くの顧客サブネットとホスト[v6BB]を収容しながらネットワークがそうする顧客構内に割り当てられると予想されます。
2. IPv6 nodes do not use ARP, but instead use the Neighbor Discovery
Protocol [RFC2461] for layer-2 address resolution.
2. IPv6ノードはARPを使用しませんが、層-2アドレス解決に、代わりに、Neighborディスカバリープロトコル[RFC2461]を使用してください。
To simultaneously support both IPv6 and MAC-Forced Forwarding for IPv4, an EAN can implement the unicast, broadcast, and multicast filtering rules described in Section 3.3. To correctly perform unicast filtering, the EAN must learn the IPv6 and MAC addresses of the allowed ARs for a particular subscriber line. It can learn these addresses either through static configuration or by snooping Router Discovery messages exchanged between the customer premises router and one or more ARs [RFC2461].
同時にIPv4のために両方がIPv6とMAC無理矢理のForwardingであるとサポートするために、EANはユニキャスト、放送、およびセクション3.3で説明されたマルチキャストフィルタリング規則を実装することができます。 正しくユニキャストフィルタリングを実行するために、EANは特定の加入者系列のために許容ARsのIPv6とMACアドレスを学ばなければなりません。 それは静的な構成を通して、または、顧客構内ルータと1ARs[RFC2461]の間で交換されたRouterディスカバリーメッセージについて詮索することでこれらのアドレスを学ぶことができます。
Multicast is an intrinsic part of the IPv6 protocol suite. Therefore, an EAN must not indiscriminately filter IPv6 multicast packets flowing upstream, although it may rate limit them. Detailed IPv6 multicast filtering rules are not discussed in this document.
マルチキャストはIPv6プロトコル群の本質的な一部です。 したがって、EANは無差別に逆流するIPv6マルチキャストパケットをフィルターにかけてはいけなくて、それですが、レートがそれらを制限しますように。 本書では詳細なIPv6マルチキャストフィルタリング規則について議論しません。
8. Security Considerations
8. セキュリティ問題
MAC-Forced Forwarding is, by its nature, a security function, ensuring layer-2 isolation of customer hosts sharing a broadcast access medium. In that sense, it provides security equivalent to alternative PVC-based solutions. Security procedures appropriate for any shared access medium are equally appropriate when MAC-Forced Forwarding is employed. It does not introduce any additional vulnerabilities over those of standard Ethernet bridging.
放送アクセス媒体を共有している顧客ホストの層-2分離を確実にして、MAC無理矢理のForwardingは本質的にセキュリティ機能です。 その意味で、それは代替のPVCベースのソリューションに同等なセキュリティを提供します。 MAC無理矢理のForwardingが採用しているとき、どんな共用アクセス媒体にも、適切なセキュリティ手順は等しく適切です。 それは標準のイーサネットのブリッジすることのものにどんな追加脆弱性も取り入れません。
In addition to layer-2 isolation, an EAN implementing MAC-Forced Forwarding must discard all upstream broadcast packets, except for valid DHCP messages, and ARP requests (which are proxied by the EAN).
層-2分離に加えて、MAC無理矢理のForwardingを実装するEANはすべての上流の放送パケットを捨てなければなりません、有効なDHCPメッセージ、およびARP要求(EANによってproxiedされる)を除いて。
Melsen & Blake Informational [Page 10] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[10ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
In particular, the EAN must discard any DHCP server replies originating on a subscriber line. Further, an EAN may rate limit upstream broadcast DHCP messages.
特に、EANは加入者系列で起因するどんなDHCPサーバ回答も捨てなければなりません。 さらに、EANは、限界が上流の放送DHCPメッセージであると評定するかもしれません。
An EAN implementing MAC-Forced Forwarding must keep track of IPv4 addresses allocated on subscriber lines. Therefore, the EAN has sufficient information to discard upstream traffic with spoofed IPv4 source addresses.
MAC無理矢理のForwardingを実装するEANは加入者系列に割り当てられたIPv4アドレスの動向をおさえなければなりません。 したがって、EANには、偽造しているIPv4ソースアドレスで上流のトラフィックを捨てることができるくらいの情報があります。
9. Acknowledgements
9. 承認
The authors would like to thank Ulf Jonsson, Thomas Narten, James Carlson, Rolf Engstrand, Tomas Thyni, and Johan Kolhi for their helpful comments.
作者は彼らの役に立つコメントについてウルフ・イェンソン、トーマスNarten、ジェームス・カールソン、ロルフEngstrand、トマスThyni、およびジョハンKolhiに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC0826] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換すると、トランスミッションのためのイーサネット・アドレスはイーサネットハードウェアの上に48.bitに記述される」STD37、RFC826、1982年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTP業者拡大」、RFC2132、1997年3月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3046] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC3442] レモン、T.、チェーシャー州、S.、およびB.フォルツ、「Dynamic Host Configuration Protocol(DHCP)バージョン4インチClassless Static Route Option、RFC3442、2002年12月。」
Melsen & Blake Informational [Page 11] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[11ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
10.2. Informative References
10.2. 有益な参照
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[RFC3768]Hinden、2004年4月のR.、「仮想のルータ冗長プロトコル(VRRP)」RFC3768。
[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月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516] Mamakos、L.、Lidl、K.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるための方法(PPPoE)」、RFC2516(1999年2月)。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for
Efficient IP Address Allocation", RFC 3069, February 2001.
[RFC3069] マクファーソンとD.とB.ダイクス、「効率的なIPアドレス配分のためのVLAN集合」、RFC3069、2001年2月。
[TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation",
Technical Report TR-101, April 2006.
[TR101]DSLフォーラム、「イーサネットベースのDSL集合への移動」、技術報告書TR-101、2006年4月。
[v6BB] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
J. Palet, "ISP IPv6 Deployment Scenarios in Broadband
Access Networks", Work in Progress.
S.、アフマド、A.、Popoviciu、C.、Savola、P.、およびJ.殻、「広帯域アクセスネットワークにおけるISP IPv6展開シナリオ」という[v6BB]Asadullahは進行中で働いています。
Authors' Addresses
作者のアドレス
Torben Melsen Ericsson Faelledvej Struer DK-7600 Denmark
トルベン・MelsenエリクソンFaelledvejスドルアDK-7600デンマーク
EMail: Torben.Melsen@ericsson.com
メール: Torben.Melsen@ericsson.com
Steven Blake Ericsson 920 Main Campus Drive Suite 500 Raleigh, NC 27606 USA
スティーブン・ブレーク・エリクソンの920の主なキャンパスドライブSuite500NC27606ローリー(米国)
Phone: +1 919 472 9913 EMail: steven.blake@ericsson.com
以下に電話をしてください。 +1 9913年の919 472メール: steven.blake@ericsson.com
Melsen & Blake Informational [Page 12] RFC 4562 MAC-Forced Forwarding June 2006
MAC無理矢理の[12ページ]RFC4562推進2006年6月の情報のMelsenとブレーク
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Melsen & Blake Informational [Page 13]
Melsenであって、ブレークInformationalです。[13ページ]
一覧
スポンサーリンク
