RFC4887 日本語訳
4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V.Devarapalli. July 2007. (Format: TXT=40372 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Thubert
Request for Comments: 4887 Cisco Systems
Category: Informational R. Wakikawa
Keio University and WIDE
V. Devarapalli
Azaire Networks
July 2007
Thubertがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4887年のシスコシステムズカテゴリ: 情報のR.Wakikawa慶応義塾大学とDevarapalli Azaireが2007年7月にネットワークでつなぐ広いV.
Network Mobility Home Network Models
ネットワーク移動性ホームネットワークモデル
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists.
Network Mobility(ネモ)のためにホームNetworkを配備するとき、この紙は用法パターンと関連問題のいくつかを記録します--モバイルRoutersを有効にします、ネモBasic Supportに従って。 ここの目的は特にホームNetworkの組織に関するいくつかの例を提供することです、ネモ関連のメーリングリストでそれらについて議論したとき。
Thubert, et al. Informational [Page 1] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[1ページ]のRFC4887ホームネットワークモデル
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. General Expectations . . . . . . . . . . . . . . . . . . . . . 4
4. MIP Home Network . . . . . . . . . . . . . . . . . . . . . . . 5
5. NEMO Extended Home Network . . . . . . . . . . . . . . . . . . 5
5.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Returning Home . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Home Address from MNP . . . . . . . . . . . . . . . . . . 7
5.4. Deployment Caveats . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Mobile Router Side . . . . . . . . . . . . . . . . . . 8
5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
6. NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 8
6.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Returning Home . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Returning Home with the Egress Interface . . . . . . . 10
6.2.2. Returning Home with the Ingress Interface . . . . . . 10
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Deployment Caveats . . . . . . . . . . . . . . . . . . . . 11
6.4.1. Home Agent Side . . . . . . . . . . . . . . . . . . . 11
6.4.2. Mobile Router Side . . . . . . . . . . . . . . . . . . 11
7. NEMO Virtual Home Network . . . . . . . . . . . . . . . . . . 12
7.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 14
8. NEMO Mobile Home Network . . . . . . . . . . . . . . . . . . . 14
8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語と概念. . . . . . . . . . . . . . . . . . . 4 3。 一般期待. . . . . . . . . . . . . . . . . . . . . 4 4。 MIPホームネットワーク. . . . . . . . . . . . . . . . . . . . . . . 5 5。 ネモはホームネットワーク. . . . . . . . . . . . . . . . . . 5 5.1を広げました。 構成. . . . . . . . . . . . . . . . . . . . . . 5 5.2。 ホーム. . . . . . . . . . . . . . . . . . . . . . 6 5.3を返します。 MNP. . . . . . . . . . . . . . . . . . 7 5.4からのホームアドレス。 展開警告. . . . . . . . . . . . . . . . . . . . 8 5.4.1。 モバイルルータ側. . . . . . . . . . . . . . . . . . 8 5.5。 適用性. . . . . . . . . . . . . . . . . . . . . . 8 6。 ネモはホームネットワーク. . . . . . . . . . . . . . . . . 8 6.1に集めました。 構成. . . . . . . . . . . . . . . . . . . . . . 8 6.2。 ホーム. . . . . . . . . . . . . . . . . . . . . . 9 6.2.1を返します。 出口のインタフェース. . . . . . . 10 6.2.2があるホームを返します。 イングレスインタフェース. . . . . . 10 6.3があるホームを返します。 適用性. . . . . . . . . . . . . . . . . . . . . . 11 6.4。 展開警告. . . . . . . . . . . . . . . . . . . . 11 6.4.1。 ホームのエージェントサイド. . . . . . . . . . . . . . . . . . . 11 6.4.2。 モバイルルータ側. . . . . . . . . . . . . . . . . . 11 7。 ネモVirtualのホームネットワーク. . . . . . . . . . . . . . . . . . 12 7.1。 構成. . . . . . . . . . . . . . . . . . . . . . 12 7.2。 適用性. . . . . . . . . . . . . . . . . . . . . . 14 8。 ネモ移動住宅ネットワーク. . . . . . . . . . . . . . . . . . . 14 8.1。 構成. . . . . . . . . . . . . . . . . . . . . . 14 8.2。 適用性. . . . . . . . . . . . . . . . . . . . . . 17 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 17 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 17 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 18
Thubert, et al. Informational [Page 2] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[2ページ]のRFC4887ホームネットワークモデル
1. Introduction
1. 序論
This document assumes that the reader is familiar with IPv6 Mobility as defined by Mobile IPv6 and the Network Mobility (NEMO) Basic Support. In order to read this document properly, it is important to realize that in NEMO, the Home Network can encompass much more than the Home Link, as it spans the Home Link and all the Links that the Mobile Routers (MRs) carry with them. Exactly how the two concepts relate in a given deployment depends on the organization of the Home Network, as described below.
このドキュメントは、モバイルIPv6とNetwork Mobility(ネモ)の基本的なSupportによって定義されるように読者がIPv6 Mobilityに詳しいと仮定します。 適切にこのドキュメントを読んで、モバイルRouters(MRs)が彼らと共に運ぶのは、ネモ、ホームLinkにかかるときNetworkがホームLinkよりはるかに取り囲むことができるホーム、およびすべてのリンクスでそれがわかるために重要です。 2つの概念が与えられた展開でちょうどどう関係するかをホームNetworkの組織に頼っています、以下で説明されるように。
Five different organizations of the Home Network including a hierarchical construction are documented:
階層的な工事を含むホームNetworkの5つの異なった組織が記録されます:
MIPv6 Home Network: A short reminder of what the Home Network is
with Mobile IP, in order to help the reader figure out the
evolution toward NEMO.
MIPv6ホームネットワーク: 読者がネモに向かって発展を見積もるのを助けるホームNetworkがモバイルIPがある何であるかに関する短い督促状。
NEMO Extended Home Network: In this arrangement, the Home Network is
only one subnet of a larger aggregation that encompasses the
Mobile Networks, called Extended Home Network. When at home, a
Mobile Router performs normal routing between the Home Link and
the Mobile Networks. More in Section 5.
ネモはホームネットワークを広げました: ExtendedホームNetworkは、このアレンジメントでは、ホームNetworkがモバイルNetworksを取り囲むより大きい集合の1つのサブネットにすぎないと呼びました。 モバイルRouterが家でホームLinkとモバイルNetworksの間の正常なルーティングを実行するとき。 さらにセクション5で。
NEMO Aggregated Home Network: In this arrangement, the Home Network
actually overlaps with the Mobile Networks. When at home, a
Mobile Router acts as a bridge between the Home Link and the
Mobile Networks. More in Section 6.
ネモはホームネットワークに集めました: このアレンジメントでは、ホームNetworkは実際にモバイルNetworksに重なります。 モバイルRouterがホームLinkとモバイルNetworksの間の橋として家で機能するとき。 さらにセクション6で。
Virtual Home Network: In this arrangement, there is no physical Home
Link at all for the Mobile Routers to come back home to. More in
Section 7.
仮想のホームネットワーク: このアレンジメントには、モバイルRoutersが家に戻るようになるように、物理的なホームLinkが全くありません。 さらにセクション7で。
NEMO Mobile Home Network: In this arrangement, there is a bitwise
hierarchy of Home Networks. A global Home Network is advertised
to the infrastructure by a head Home Agent (HA) and further
subnetted into Mobile Networks. Each subnet is owned by a Mobile
Router that registers it in a NEMO fashion while acting as a Home
Agent for that network. More in Section 8.
ネモ移動住宅ネットワーク: このアレンジメントには、あります。aはホームNetworksの階層構造をbitwiseします。 グローバルなホームNetworkはヘッドホームのエージェント(HA)によってインフラストラクチャに広告を出されて、さらにモバイルNetworksに「副-網で覆」われます。 各サブネットはそのネットワークのホームのエージェントとして務めている間にネモファッションでそれを登録するモバイルRouterによって所有されています。 さらにセクション8で。
In all cases, the Home Agents collectively advertise only the aggregation of the Mobile Networks. The subnetting is kept within the Home Agents and the Mobile Routers, as opposed to advertised by means of routing protocols to other parties.
すべての場合では、ホームのエージェントはまとめてモバイルNetworksの集合だけの広告を出します。 サブネッティングはホームのエージェントとモバイルRoutersの中に保たれます、相手へのルーティング・プロトコルによって広告を出されることと対照的に。
The examples provided here aim at illustrating the NEMO Basic Support [5] but do not aim at limiting its scope of application; additional cases may be added in the future.
ここに提供された例は、ネモBasic Support[5]を例証するのを目的としますが、適用範囲を制限するのは目的としません。 追加ケースは将来、加えられるかもしれません。
Thubert, et al. Informational [Page 3] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[3ページ]のRFC4887ホームネットワークモデル
2. Terminology and Concepts
2. 用語と概念
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [2].
キーワードが解釈しなければならない、RFC2119[2]で説明されるように本書ではNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Most of the mobility-related terms used in this document are defined in the Mobility Related Terminology document [3] and in the Mobile IPv6 (MIP6) specification [4].
本書では使用される移動性関連の用語の大部分はMobilityの関連Terminologyドキュメント[3]とモバイルIPv6(MIP6)仕様[4]に基づき定義されます。
In addition, some terms were created or extended for NEMO. These specific terms are defined in the Mobile Network Terminology document [6]:
さらに、いくつかの期間が、ネモのために作成されたか、または延ばされました。 これらの種の用語はモバイルNetwork Terminologyドキュメント[6]で定義されます:
Home Link
ホームのリンク
Home Network
ホームネットワーク
Home Address
ホームアドレス
MRHA Tunnel
MRHAトンネル
Mobile Aggregated Prefix
モバイル集められた接頭語
Aggregated Home Network
ホームネットワークに集めます。
Extended Home Network
拡張ホームネットワーク
Virtual Home Network
仮想のホームネットワーク
Mobile Home Network
移動住宅ネットワーク
3. General Expectations
3. 一般期待
With Mobile IPv6, the Home Network is generally a physical network interconnecting the Home Agents and the Mobile Nodes that are at home. NEMO extends the concept of home so that it is not only a flat subnet composed of Home Addresses but an aggregation that is itself subnetted in Mobile and Home Networks. This aggregation is still referred to as home.
モバイルIPv6と共に、一般に、ホームNetworkは家にあるホームのエージェントとモバイルNodesとインタコネクトする物理ネットワークです。 ネモが家の概念について敷衍するので、ホームAddressesで構成された平坦なサブネットだけではなく、それはモバイルとホームNetworksで「副-網で覆」われる集合でもあります。 この集合はまだ家と呼ばれています。
As an example, consider the case where the aggregation has a global routing prefix of m = 48 bits (A:B:C::/48), with a subnet ID size of n = 16 bits (n + m = 64):
例と、集合が48m=ビット(A:B: C: : /48)のグローバルなルーティング接頭語を持っているケースを考えてください、16n=ビット(n+m=64)のサブネットIDサイズで:
Thubert, et al. Informational [Page 4] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[4ページ]のRFC4887ホームネットワークモデル
When a Mobile Router, MR1, uses the Mobile Network Prefix (MNP) A:B: C:1::/64 with the NEMO Basic Support, MR1 may register using a Home Address from the Home network (i.e., A:B:C:0::1) or a Home Address from one of its MNPs (i.e., A:B:C:1::1) depending on the deployment.
モバイルRouter(MR1)がモバイルNetwork Prefix(MNP)A:Bを使用すると: C: 1:、:ネモBasic Supportがある/64、MR1は展開によって、ホームネットワーク(すなわち、A:B:C:0: : 1)かホームAddressからMNP(すなわち、A:B:C:1: : 1)の1つからホームAddressを使用することで登録するかもしれません。
In a given deployment, one subnet may be reserved for the Home Link (A:B:C:0::/64) while the others are attributed to Mobile Routers as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be to configure the aggregation of Mobile Networks as the subnet on the Home Link, and let the Mobile Routers manage the overlapping networks. Finally, the aggregation could be configured on a virtual network, with no physical Home Link at all, in which case home means topologically and administratively close to the Home Agent that advertises the virtual network.
与えられた展開では、他のものがモバイルRoutersにモバイルNetworks(A:B:C:1: : MR1のための/64としての)とみなされている間、1つのサブネットがホームLink(A:B:C:0: : /64)のために予約されるかもしれません。 別のアプローチは、モバイルRoutersにサブネットとしてホームLinkでモバイルNetworksの集合を構成して、重なっているネットワークを経営させることであることができました。 最終的に、仮想ネットワークで集合を構成できました、全く物理的なホームLinkがなければ、その場合、家はホームのエージェントの近くでそれが仮想ネットワークの広告を出すことを位相的に行政上意味します。
The following sections provide additional information on these forms of Home Network.
以下のセクションはホームNetworkのこれらのフォームに関する追加情報を提供します。
4. MIP Home Network
4. MIPホームネットワーク
In the Mobile IPv6 (MIP6) specification [4], Mobile Nodes are at home when they are connected to their Home Link, where they recognize their Home Prefix in Router Advertisement messages. Also, a binding is checked using Duplicate Address Detection (DAD) on the Home Link, and Home Agents discover each other by means of Neighbor Discovery (ND) extensions over that link.
モバイルIPv6(MIP6)仕様[4]には、彼らが彼らのホームLink(彼らはRouter Advertisementメッセージで自分達のホームPrefixを認識する)に接続されるとき、モバイルNodesが家にあります。 また、結合はホームLink、およびホームのエージェントのチェックの使用Duplicate Address Detection(DAD)がそのリンクの上のNeighborディスカバリー(ノースダコタ)拡大によって互いを発見するということです。
The Home Prefix that is advertized on the Home Link is a final prefix, as opposed to an aggregation, and it may be used by hosts on the Home Link for autoconfiguration purposes.
ホームLinkでadvertizedされるホームPrefixは集合と対照的に最終的な接頭語です、そして、それは自動構成目的にホームLinkの上のホストによって使用されるかもしれません。
As we see, the concept of a Home Network for Mobile IPv6 is really a prefix on a link, served by one or more Home Agents as opposed to a routed mesh. We will see in the next sections that NEMO needs additional prefixes for use by the Mobile Networks. For that reason, NEMO extends the concept of Home Network into a more complex, aggregated structure.
私たちが見るように、モバイルIPv6のためのホームNetworkの概念は本当に発送されたメッシュと対照的に1人以上のホームのエージェントによって勤められたリンクの上の接頭語です。 私たちは、次のセクションでネモがモバイルNetworksによる使用に追加接頭語を必要とするのがわかるでしょう。 その理由で、ネモは、より複雑で、集められた構造にホームNetworkの概念について敷衍します。
5. NEMO Extended Home Network
5. ネモはホームネットワークを広げました。
5.1. Configuration
5.1. 構成
One simple way of extending the MIP Home Network is to use additional prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as Mobile Network Prefixes. As this model trivially extends the MIP Home Network, the resulting aggregation is called a NEMO Extended Home Network. It is depicted in Figure 1.
MIPホームNetworkを広げる1つの簡単な方法はMIPv6から引き継がれたホームLink Prefixへの隣接の追加接頭語を使用することです、モバイルNetwork Prefixesとして。 このモデルがMIPホームNetworkを些細なことに広げているのに従って、結果として起こる集合はネモExtendedホームNetworkと呼ばれます。 それは図1に表現されます。
Thubert, et al. Informational [Page 5] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[5ページ]のRFC4887ホームネットワークモデル
|
route v /48 A:B:C::/48
| /48A:B: Cに対して以下を発送してください:/48
HA
| /64 Home Link: A:B:C:0::/64
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
| | | |
------ ------ ------ ------
/64 /64 /64 /64 MNP: A:B:C:i::/64
ハ| /64ホームリンク: A:B:C:0:、:/64 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN| | | | ------ ------ ------ ------ /64 /64 /64 /64MNP: A:B:C:i:、:/64
Extended Home Network
<----------------------------------------------------------->
拡張ホームネットワーク<。----------------------------------------------------------->。
Home Net Mobile Net Mobile Net ... Mobile Net
<------------><------------><------------> ... <------------>
ホームネットモバイルのネットのモバイルネット… モバイルネット<。------------><、-、-、-、-、-、-、-、-、-、-、--、><、-、-、-、-、-、-、-、-、-、-、-->… <、-、-、-、-、-、-、-、-、-、-、-->。
Figure 1: Extended Home Network
図1: 拡張ホームネットワーク
In that arrangement:
そのアレンジメントで:
o There is one physical Home Network and multiple Mobile Networks
o 1物理的なホームNetworkと複数のモバイルNetworksがあります。
o The Home Prefix and the MNPs are tailored to allow for IPv6
Stateless Address Autoconfiguration with typical interface
identifier length for the type of interface (for example, can be
/64).
o ホームPrefixとMNPは、インタフェースのタイプに関して典型的なインタフェース識別子の長さがあるIPv6 Stateless Address Autoconfigurationを考慮するために仕立てられます(例えば、/64であることができる)。
o The prefix length of the Extended Home Network is shorter than
that of the Home Network and the MNPs, since it is an aggregation
(for example, can be /48).
o ExtendedホームNetworkの接頭語の長さはホームNetworkのものとMNPより短いです、それが集合(例えば、/48であることができる)であるので。
o Since the Extended Home Network operations inherit trivially from
MIPv6, it can be seen as natural that the Mobile Routers be
assigned their Home Addresses from the prefix on the Home Link.
In that case, a Home Agent can perform DAD on the Home Link as
prescribed by Mobile IPv6 for the Mobile Router Home Addresses
(MRHAs).
o ExtendedホームNetwork操作がMIPv6を些細なことに受け継ぐので、彼らのホームAddressesがホームLinkの上の接頭語からモバイルRoutersに割り当てられるのを自然であるとみなすことができます。 その場合、モバイルRouterホームAddresses(MRHAs)のためのモバイルIPv6によって処方されるようにホームのエージェントはホームLinkにDADを実行できます。
5.2. Returning Home
5.2. 戻っているホーム
In the Extended Home Network model, the Home Network is configured on a physical interface of the Home Agent, the Home Link.
ExtendedホームNetworkモデルでは、ホームNetworkはホームのエージェント(ホームLink)の物理インターフェースで構成されます。
A Mobile Router returns home by connecting directly to the Home Link, and dropping the MRHA tunnel.
モバイルRouterは直接ホームLinkに接続して、低下するのによる家にMRHAトンネルを返します。
Thubert, et al. Informational [Page 6] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[6ページ]のRFC4887ホームネットワークモデル
When at home, the Mobile Router ensures the connectivity of the Mobile Network using standard router operations.
モバイルRouterが家で標準のルータ操作を使用することでモバイルNetworkの接続性を確実にするとき。
In implicit mode, the Home Agent has the necessary information to continue routing to the MNPs in the absence of registration, assuming that the Mobile Router is at home, and the participation of the Mobile Router to the home Interior Gateway Protocol (IGP) is not required.
ホームのエージェントには、暗黙のモードで、登録がないときMNPに掘り続ける必要事項があります、モバイルRouterが家にあって、家のInteriorゲートウェイプロトコル(IGP)へのモバイルRouterの参加は必要でないと仮定して。
But in explicit mode, or if the Mobile Router uses an IGP over the MRHA tunnel, then it needs to resume its IGP operations on the Home Link in order to advertise its Mobile Networks to the HA, unless some other means such as static routes are deployed to cover the case.
しかし、次に、明白なモードかそれともモバイルRouterがMRHAトンネルの上でIGPを使用するかどうかでは、モバイルNetworksのHAに広告を出すためにホームLinkでIGP操作を再開するのが必要です、スタティックルートなどのある他の手段がケースをカバーするために配備されない場合。
Alternative procedures for ensuring the connectivity of the Mobile Networks when at home are described in Section 7.
家にあるときモバイルNetworksの接続性を確実にするための交替手続きはセクション7で説明されます。
5.3. Home Address from MNP
5.3. MNPからのホームアドレス
We saw that a natural extension of the MIP procedure is to derive the Home Address of a Mobile Router from the prefix on the Home Link. Alternatively, NEMO basic support allows that a Mobile Router forms its Home Address from one of its Mobile Network Prefixes.
私たちは、MIP手順の自然な拡大がホームLinkの上の接頭語からモバイルRouterのホームAddressを引き出すことであることを見ました。 あるいはまた、ネモ基本的なサポートで、モバイルRouterはモバイルNetwork Prefixesの1つからホームAddressを形成できます。
In that case, the Home Address does not match the Home Link Prefix, and there is a need to configure the Home Agent in a specific mode with the support for the Extended Home Network and the range of the Mobile Network Prefixes. Based on that new configuration, the Home Agent can accept a Home Address that is not from the Home Link, and it will know that it should not perform any DAD.
その場合、ホームAddressはホームLink Prefixに合っていません、そして、ExtendedホームNetworkのサポートとモバイルNetwork Prefixesの範囲で特定のモードでホームのエージェントを構成する必要があります。 その新しい構成に基づいて、ホームのエージェントはホームLinkから来ていないホームAddressを受け入れることができます、そして、それは少しのDADも実行するべきでないのを知るでしょう。
Also, if the Mobile Router uses a Home Address that is derived from its MNP, some specific support is required on the Mobile Router as well. In order to determine that it is at home, the Mobile Router recognizes the well-known prefix of its Home Agent as opposed to matching the prefix on the Home Link with that of its Home Address.
また、モバイルRouterがMNPから得られるホームAddressを使用するなら、何らかの特定のサポートがまた、モバイルRouterで必要です。 それが家にあることを決定するために、ホームLinkの上の接頭語をホームAddressのものに合わせることと対照的にモバイルRouterはホームのエージェントの周知の接頭語を認識します。
When connecting to the Home Link, the Mobile Router also need to autoconfigure an address on the Egress interface as opposed to assigning its home Address to the interface.
また、ホームLinkに接続するとき、モバイルRouterは、家のAddressをインタフェースに割り当てることと対照的にEgressインタフェースに関するアドレスを自動構成する必要があります。
For all these reasons, this submode of Extended Home Network is not a trivial extension of the MIPv6 Home Model, and it might not be compatible with all implementations.
これらのすべての理由で、ExtendedホームNetworkのこの「副-モード」はMIPv6ホームModelの些細な拡大ではありません、そして、それはすべての実現と互換性がないかもしれません。
Thubert, et al. Informational [Page 7] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[7ページ]のRFC4887ホームネットワークモデル
5.4. Deployment Caveats
5.4. 展開警告
5.4.1. Mobile Router Side
5.4.1. モバイルルータ側
In explicit mode, the routing to the MNP via the Mobile Router must be restored when the Mobile Router is at home. This is normally performed by the Mobile Router by means of the existing IGP. In that case, a specific support is required on the Mobile Router to control the routing protocol operation, enabling the participation in the IGP if and only if the Mobile Router is at home.
モバイルRouterが家にあるとき、明白なモードで、モバイルRouterを通したMNPへのルーティングを回復しなければなりません。 通常、これは既存のIGPによってモバイルRouterによって実行されます。 そして、その場合、特定のサポートがルーティング・プロトコル操作を制御するのにモバイルRouterで必要です、IGPへの参加を可能にしてモバイルRouterが家にある場合にだけ。
The NEMO Basic Support does not mandate a specific routing protocol though the support for some well-known routing protocols can be expected from many implementations. An implementation might provide an automatic toggle to start/stop routing on an egress interface when the mobile router comes back/leaves home. When such a toggle is unavailable, then a specific interface should be reserved to attach to home with the appropriate settings for security and routing.
多くの実現からいくつかの周知のルーティング・プロトコルのサポートを予想できますが、ネモBasic Supportは特定のルーティング・プロトコルを強制しません。 実現は家で出口のインタフェースで掘るのを始めるか、または止める可動のルータが来る自動トグルに後部/葉を提供するかもしれません。 そのようなトグルが入手できないと、特定のインタフェースは、セキュリティとルーティングのために適切な設定と共に家へ帰るために付くために予約されるべきです。
5.5. Applicability
5.5. 適用性
The Extended Home Network keeps the MIP6 concept of a Home Network for both Mobile Nodes and Mobile Routers to take their Home Address from. Since there is no overlap between the prefixes that are assigned to MNPs and prefix(es) that are dedicated to the Home Link, it is possible for MNs and Mobile Routers to coexist with that model.
ExtendedホームNetworkは彼らのホームAddressを取るモバイルNodesとモバイルRoutersの両方のためにホームNetworkのMIP6概念を保ちます。 MNPに割り当てられる接頭語とホームLinkに捧げられる接頭語(es)の間には、オーバラップが全くないので、MNsとモバイルRoutersがそのモデルと共存するのは、可能です。
Also, when the Home Address is derived from the prefix on the Home Link, the Home Agent behavior on the link trivially extends that of MIP and the support for that configuration should be available with all implementations.
また、ホームLinkで接頭語からホームAddressを得るとき、リンクにおけるホームエージェントの振舞いはMIPのものを些細なことに拡張しています、そして、その構成のサポートはすべての実現で利用可能であるべきです。
There are a number of issues with returning home when a Mobile Router configures its Home Address from the MNP as described in Section 5.3. Therefore, we do not recommend this mechanism if the Mobile Routers attach to the Home Network.
モバイルRouterがセクション5.3で説明されるようにMNPからホームAddressを構成するとき家に帰る多くの問題があります。 したがって、モバイルRoutersがホームNetworkに付くなら、私たちはこのメカニズムを推薦しません。
6. NEMO Aggregated Home Network
6. ネモはホームネットワークに集めました。
6.1. Configuration
6.1. 構成
One other approach is to consider that the aggregation of all the MNPs is used plainly as the Home Link Prefix. In this model, the Home Network is referred to as a NEMO Aggregated Home Network. This means that the Mobile Aggregated Prefix is configured on the Home Link and advertised by the Home Agent as a subnet, as depicted in Figure 2.
他の1つのアプローチはすべてのMNPの集合がホームLink Prefixとして明らかに使用されると考えることです。 このモデルで、ホームNetworkはネモAggregatedホームNetworkと呼ばれます。 これは、モバイルAggregated PrefixがホームLinkで構成されて、サブネットとしてホームのエージェントによって広告を出されることを意味します、図2に表現されるように。
Thubert, et al. Informational [Page 8] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[8ページ]のRFC4887ホームネットワークモデル
HA
| /56 Aggreg /56
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
| | | |
------ ------ ------ ------
/64 /64 /64 /64 Aggreg|i /64 0 < i <= N
ハ| /56Aggreg /56--+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN| | | | ------ ------ ------ ------ /64 /64 /64 /64Aggreg|i/64 0<i<はNと等しいです。
Aggregated Home Network == Home Network
<----------------------------------------------------------->
ホームネットワーク=ホームネットワーク<に集めます。----------------------------------------------------------->。
Mobile Net Mobile Net Mobile Net ... Mobile Net
<------------><------------><------------> ... <------------>
モバイルネットのモバイルネットのモバイルネット… モバイルネット<。------------><、-、-、-、-、-、-、-、-、-、-、--、><、-、-、-、-、-、-、-、-、-、-、-->… <、-、-、-、-、-、-、-、-、-、-、-->。
Figure 2: Aggregated Home Network
図2: ホームネットワークに集めます。
In that model, it seems natural to subnet the whole range of addresses into Mobile Network prefixes, as opposed to reserving one prefix for the Home Link, which would boil down to the Extended Home Network model. If the prefix on the Home Link is really an aggregation and not a final prefix, it should not be allowed for autoconfiguration or Home Address allocation.
そのモデルでは、モバイルNetworkへの全体の範囲のアドレスが前に置くサブネットに自然に見えます、詰まるところ、ExtendedホームNetworkモデルになるだろうホームLinkのために1つの接頭語を予約することと対照的に。 ホームLinkの上の接頭語が最終的な接頭語ではなく、本当に集合であるなら、自動構成かホームAddress配分のためにそれを許容するべきではありません。
Note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs. Taking the Home Address from its own range guarantees the uniqueness of the suffix. That uniqueness can be checked by the Mobile Router on its Ingress network (see [3]) using DAD.
それ自身のMNPの1つからホームAddressを使用することで登録するためにその場合、それがモバイルRouterのために理解できることに注意してください。 それ自身の範囲からAddressを家へ持ち帰ると、接尾語のユニークさは保証されます。 モバイルRouterはIngressネットワークでそのユニークさをチェックできます。([3]) DADを使用することで、見てください。
6.2. Returning Home
6.2. 戻っているホーム
The Aggregated Home Prefix is configured on a physical interface of the Home Agent, the Home Link. As a consequence, the Home Agent has a connected route to the Aggregated Home Network over the Home Link.
AggregatedホームPrefixはホームのエージェント、ホームLinkの物理インターフェースで構成されます。 結果として、ホームのエージェントはホームLinkの上にAggregatedホームNetworkに接続ルートを持っています。
A Mobile Router returns home by connecting directly to the Home Link, and dropping the MRHA tunnel. The Mobile Router recognizes its Home Link by a prefix match with its Home Agent.
モバイルRouterは直接ホームLinkに接続して、低下するのによる家にMRHAトンネルを返します。 モバイルRouterは、接頭語によるホームLinkがホームのエージェントに合わせると認めます。
When the Mobile Router forms its Home Address out of one of its MNPs, since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address actually matches both prefixes. To properly identify the Home Network as it returns home, the MR must expect a shorter prefix length than that of the MNP from which the Home Address was formed.
モバイルRouterがMNPの1つからホームAddressを形成するとき、ホームNetwork接頭語がすべてのMNPを取り囲む集合であるので、ホームAddressは実際に両方の接頭語に合っています。 ホームNetworkがそれであると適切に認識するのを家に帰ります、とMRはホームAddressが形成されたMNPのものより短い接頭語の長さに予想しなければなりません。
Thubert, et al. Informational [Page 9] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[9ページ]のRFC4887ホームネットワークモデル
6.2.1. Returning Home with the Egress Interface
6.2.1. 出口のインタフェースがある戻っているホーム
A Mobile Router coming home via its Egress interface sees overlapping prefixes between the Ingress and the Egress interfaces and some specific support may be needed:
Egressインタフェースを通して帰って来るモバイルRouterは、重なるのがIngressとEgressの間にインタフェースを前に置いて、何らかの特定のサポートが必要であるかもしれないことがわかります:
When a Mobile Router connects to the Home Link using its Egress Interface, it might set up a bridge between its Ingress interface(s) and the Home Link, if the interfaces are compatible.
モバイルRouterがEgress Interfaceを使用することでホームLinkに接続するとき、IngressインタフェースとホームLinkの間の橋を設立するかもしれません、インタフェースは互換性があるなら。
Alternatively, the Mobile Router might perform ND proxying for all addresses in its MNPs, between the Egress interface and the related Ingress interface, as described in [8]. Since the prefixes on the Egress and Ingress interfaces are overlapping, routing is disallowed.
あるいはまた、モバイルRouterはMNPのすべてのアドレスのためにproxyingされるノースダコタを実行するかもしれません、Egressインタフェースと関連するIngressインタフェースの間で、[8]で説明されるように。 EgressとIngressインタフェースの接頭語が重なっているので、ルーティングは禁じられます。
The Mobile Router does not need to join the local IGP when returning home, even if it is using the explicit Prefix Mode. When the Mobile Router is not registered, the Home Agent simply expects that all Mobile Network Nodes (MNNs) will be reachable over the Home Link.
家に帰るとき、モバイルRouterは地方のIGPを接合する必要はありません、明白なPrefix Modeを使用していても。 モバイルRouterが登録されていないとき、ホームのエージェントは、すべてのモバイルNetwork Nodes(MNNs)にホームLinkの上で届くと単に予想します。
HA
|
-------+--+--- /56
|
Egress |
MR at home
|
--+--- /64
ハ| -------+--+--- /56 | 出口| 家のMR| --+--- /64
Figure 3: Bridging between Egress and Ingress
図3: 出口とイングレスの間の橋を架けること
6.2.2. Returning Home with the Ingress Interface
6.2.2. イングレスインタフェースがある戻っているホーム
Alternatively, if the Mobile Router has a single Ingress interface, the Mobile Router may use the NEMO-Link to connect to the Home Link, merging the two links in a single consistent network.
あるいはまた、モバイルRouterに単一のIngressインタフェースがあるなら、モバイルRouterはホームLinkに接続するのにネモ-リンクを使用するかもしれません、ただ一つの一貫したネットワークにおける2個のリンクを合併して。
HA
|
-------+-+---- /56
|
---+-- /64
|
MR at home
Egress |
ハ| -------+-+---- /56 | ---+-- /64 | 家のEgressのMR|
Figure 4: Merging the Home and the Mobile Networks
図4: ホームとモバイルネットワークを合併します。
Thubert, et al. Informational [Page 10] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[10ページ]のRFC4887ホームネットワークモデル
This fits the connected route model, since the Aggregated Home Network is truly located on that network. Note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs.
AggregatedホームNetworkが本当にそのネットワークに位置しているので、これは接続ルートモデルに合います。 それ自身のMNPの1つからホームAddressを使用することで登録するためにその場合、それがモバイルRouterのために理解できることに注意してください。
6.3. Applicability
6.3. 適用性
With this model, there is no specific space for independent nodes, as any address in the aggregation belongs to a MNP, and thus to a Mobile Router. This configuration excludes the cohabitation with MIP6 MNs on the Home Link.
このモデルと共に、集合のどんなアドレスもMNPに属すことと、そして、その結果、独立しているノードと、モバイルRouterへのどんな特定のスペースもありません。 この構成はホームLinkの上のMIP6 MNsと共に同棲を除きます。
6.4. Deployment Caveats
6.4. 展開警告
6.4.1. Home Agent Side
6.4.1. ホームのエージェント側
A node on the Home Link receiving a Router Advertisement that includes the Aggregated Home Network prefix might use that prefix for Address Autoconfiguration. Such a node would also install a connected route to the Aggregated Home Network over the Home Link.
AggregatedホームNetwork接頭語を含んでいるRouter Advertisementを受けるホームLinkの上のノードはAddress Autoconfigurationにその接頭語を使用するかもしれません。 また、そのようなノードはホームLinkの上のAggregatedホームNetworkに接続ルートをインストールするでしょう。
As a result, unless the node has a better (longest match) route to a given Mobile Network Prefix, it would look up all MNNs on that MNP using Neighbor Discovery over its interface to the Home Link, and fail.
その結果、ノードが、より良い(最も長いマッチ)ルートを与えられたモバイルNetwork Prefixに持っていない場合、それは、インタフェースの上でホームLinkにNeighborディスカバリーを使用することでそのMNPの上のすべてのMNNsを見上げて、失敗するでしょう。
Thus, on the Home Link, the Home Agent must intercept all the packets for ALL the Mobile Network Nodes on the registered prefixes; that is, for ALL nodes attached to Mobile Routers that are away from home. This should be a layer 2 operation, rather than layer 3. The Home Agent might, for example, perform some form of ND proxying for all addresses in all registered Mobile Network Prefixes.
したがって、ホームLinkでは、ホームのエージェントは登録された接頭語のすべてのモバイルNetwork Nodesのためにすべてのパケットを妨害しなければなりません。 すなわち、家にいないモバイルRoutersに添付されたすべてのノードのために。 これは層3よりむしろ層2の操作であるべきです。 例えば、ホームのエージェントはすべての登録されたモバイルNetwork Prefixesのすべてのアドレスのためにproxyingされる何らかのフォームのノースダコタを実行するかもしれません。
The Home Agent must also protect the MNP space from autoconfiguration by uncontrolled visitors at Neighbor Discovery level.
また、ホームのエージェントは非制御の訪問者で自動構成からNeighborディスカバリーレベルでMNPスペースを保護しなければなりません。
There is a need to provide a specific configuration on the Home Agent to specify that it operates in Aggregated Mode. If a Home Agent implementation is simply derived from that of MIP, then the capability to perform the required proxying might not exist, and the Aggregated Mode will not operate properly for nodes on the Home Link.
それがAggregated Modeで作動すると指定するためにホームのエージェントの上で特定の構成を提供する必要があります。 MIPのものからホームエージェント実現を単に得るなら、必要なproxyingを実行する能力は存在しないかもしれません、そして、Aggregated ModeはホームLinkの上のノードのために適切に作動しないでしょう。
6.4.2. Mobile Router Side
6.4.2. モバイルルータ側
If the Mobile Router returns home by Egress, a specific support is required to control the bridging operation depending on whether or not a Mobile Router is at home. This support might not be present in all implementations.
モバイルRouterがEgressで家に帰るなら、特定のサポートが、モバイルRouterが家にあるかどうかによる橋を架ける作業を制御するのに必要です。 このサポートはすべての実現で存在していないかもしれません。
Thubert, et al. Informational [Page 11] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[11ページ]のRFC4887ホームネットワークモデル
The NEMO Basic Support does not mention a specific behavior for bridging though bridging capabilities can be expected from many implementations. An implementation might provide an automatic toggle to start/stop bridging on an Egress interface when the Mobile Router comes back/leaves home. When such a toggle is unavailable, then a specific interface should be reserved to attach to home with the appropriate settings for security and bridging.
多くの実現から橋を架ける能力を予想できますが、ネモBasic Supportは橋を架ける特異的行動について言及しません。 モバイルRouterが/葉を家に支持しに来るとき、実現は、Egressインタフェースに橋を架けるのを始めるか、または止めるために自動トグルを提供するかもしれません。 そのようなトグルが入手できないと、特定のインタフェースは、セキュリティと橋を架けるために適切な設定と共に家へ帰るために付くために予約されるべきです。
Also, note that NEMO authorizes multiple registrations for a same MNP by different Mobile Routers. This is a case of multihoming, and it normally means that the Mobile Routers are interconnected by the Ingress network that bears the common MNP. But there is no provision in NEMO Basic Support to test that this condition is met at binding time and maintained over time.
また、ネモが異なったモバイルRoutersで同じMNPのための複数の登録証明書を認可することに注意してください。 これはマルチホーミングのそうです、そして、通常、それはモバイルRoutersが一般的なMNPに堪えるIngressネットワークによってインタコネクトされることを意味します。 しかし、テストするこの状態がバインディング・タイムに満たされて、時間がたつにつれて維持されるネモBasic Supportへの支給が全くありません。
It is thus possible for 2 different Mobile Routers to register the same prefix with different Home Addresses, and this will cause an undetected problem if the corresponding Ingress interfaces are not connected.
その結果、2異なったモバイルRoutersが異なったホームAddressesに同じ接頭語を登録するのが、可能であり、対応するIngressインタフェースが接続されていないと、これは非検出された問題を引き起こすでしょう。
When the Home Address of a Mobile Router is derived from its MNP, there is thus an additional risk of an undetected misconfiguration if the Home Address is autoconfigured from the Ingress interface as opposed to statically assigning an address and MNP.
MNPからモバイルRouterのホームAddressを得るとき、その結果、静的にアドレスとMNPを割り当てることと対照的にホームAddressがIngressインタフェースから自動構成されるなら、undetected misconfigurationの追加リスクがあります。
A Mobile Router that is at home must own an address from the aggregation on its Egress interface and an address from its MNP -- a subnet of that aggregation -- on its Ingress interface. A pure router will reject that configuration, and the Mobile Router needs to act as a bridge to use it. In order to deploy the Aggregated Home Network model, one must check whether that support is available in the Mobile Routers if returning home is required.
家にあるモバイルRouterはIngressインタフェースでEgressインタフェースの集合からのアドレスとMNP(その集合のサブネット)からのアドレスを所有しなければなりません。 純粋なルータはその構成を拒絶するでしょう、そして、モバイルRouterはそれを使用するために橋として機能する必要があります。 AggregatedホームNetworkモデルを配備するために、家に帰るのが必要であるなら、モバイルRoutersでそのサポートが利用可能であるかどうかチェックしなければなりません。
7. NEMO Virtual Home Network
7. ネモVirtualのホームネットワーク
7.1. Configuration
7.1. 構成
The Home Link can be configured on the Home Agent on a virtual link, in which case there is no physical Home Link for Mobile Routers to return home to, or for Home Agents to discover each other and perform the ND-level interactions on, as described in Mobile IPv6 [4].
モバイルRoutersが家に帰るようにどんな物理的なホームLinkもどのケースにないかでエージェントか互いを発見して、モバイルIPv6[4]での説明されるとしての進行中のノースダコタ-レベル相互作用を実行するホームのエージェントのために仮想のリンクの上にホームのエージェントの上でホームLinkを構成できます。
Thubert, et al. Informational [Page 12] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[12ページ]のRFC4887ホームネットワークモデル
/48 e.g.: A:B:C::/48
HA
| /64 A:B:C::/64
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
/64 /64 /64 /64 A:B:C:i::/64 0 < i <= N
/、48 例えば: A:B: C:、:/48、ハ。| /64A:B: C:、:/64 --+-----+--+- . -+- . -+-- | | | | MR1 MR2 MRi MRN/64/64/64/64A:B:C:i:、:/64 0<i<=N
Figure 5: Virtual Home Network
図5: 仮想のホームネットワーク
The Extended Home Network and the Aggregated Home Network models can be adapted for virtual links.
ExtendedホームNetworkとAggregatedホームNetworkモデルを仮想のリンクに適合させることができます。
As in the case of a physical link, the Home Address of a Mobile Router can be constructed based on a dedicated subnet of the Home Prefix or one of the Mobile Router MNPs.
物理的なリンクに関するケースのように、ホームPrefixのひたむきなサブネットかモバイルRouter MNPの1つに基づいてモバイルRouterのホームAddressを組み立てることができます。
Note that since the Home Address is never checked for DAD, it makes the configuration easier to take it from the MNP as opposed to a specific subnet.
ホームAddressがDADがないかどうか決してチェックされないので構成を特定のサブネットと対照的にMNPから分かるのが、より簡単にすることに注意してください。
There are certain advantages to making the Home Link a virtual link:
ホームLinkを仮想のリンクにするある利点があります:
A virtual link may not experience any disruption related to
physical maintenance or to hardware problems, so it is more
available than a physical link. The high availability of the Home
Link is critical for the mobility service.
仮想のリンクが物理的な維持に関連する少しの分裂も経験しないかもしれないか、またはしたがって、ハードウェア問題に、それは物理的なリンクより利用可能です。 移動性サービスに、ホームLinkの高可用性は重要です。
The Home Agent does not have to defend the Mobile Router's Home
Address through Proxy Neighbor Discovery. The Home Agent does not
also have to perform Duplicate Address Detection (DAD) for the
Mobile Router's Home Address when it receives a Binding Update
from the Mobile Router.
ホームのエージェントはProxy Neighborディスカバリーを通してモバイルRouterのホームAddressを防御する必要はありません。 また、モバイルRouterからBinding Updateを受けるとき、ホームのエージェントはモバイルRouterのホームAddressのために、Duplicate Address Detection(DAD)を実行する必要はありません。
The Mobile Router does not have to implement the Returning Home
procedure (Section 11.5.4 of Mobile IPv6 [4]).
モバイルRouterはザ・リターニング/死霊のキラー・スートンホーム手順を実行する必要はありません。(.4モバイルセクション11.5IPv6[4])。
There are also some drawbacks to the Virtual Home Link approach:
また、VirtualホームLinkアプローチへのいくつかの欠点があります:
RFC 3775 [4] and RFC 3963 [5] do not provide the specific support
for a Mobile Node to emulate returning home on a Virtual Home
Network. In particular, in the case of NEMO, the routing
information from the Mobile Router being injected on the IGP might
adversely affect IPv6 route aggregation on the Home Network.
RFC3775[4]とRFC3963[5]は、VirtualホームNetworkを家に帰りながら、モバイルNodeが見習う特定のサポートを提供しません。 ネモの場合では、特に、IGPで注入されるモバイルRouterからのルーティング情報はホームNetworkのIPv6ルート集合に悪影響を与えるかもしれません。
There can be only one Home Agent since Mobile IPv6 relies on
Neighbor Discovery on the Home Link for other Home Agent discovery
and for Duplicate Address Detection.
モバイルIPv6が他のホームエージェント発見とDuplicate Address DetectionのためにホームLinkでNeighborディスカバリーを当てにするので、1人のホームのエージェントしかいることができません。
Thubert, et al. Informational [Page 13] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[13ページ]のRFC4887ホームネットワークモデル
The Home Agent must maintain a Binding Cache entry for a Mobile
Router and forwarding state for its Mobile Network even when the
Mobile Router is directly connected to it. All traffic to and
from the Mobile Network is sent through the bi-directional tunnel
regardless of the Mobile Router location. This results in a
tunneling overhead even though the Mobile Router is connected to
the Home Network.
モバイルRouterが直接それに接続さえされるとき、ホームのエージェントはモバイルNetworkのためにモバイルRouterと推進状態にBinding Cacheエントリーを維持しなければなりません。 モバイルRouter位置にかかわらず双方向のトンネルを通してNetworkとモバイルNetworkからのすべての交通を送ります。 モバイルRouterはホームNetworkに接続されますが、これはトンネリングオーバーヘッドをもたらします。
Suggestions on how to perform an equivalent of returning home on a Virtual Home Network have been proposed, but this topic is outside of the scope of this document.
どうVirtualホームNetworkを家に帰る同等物を実行するかに関する提案は提案されましたが、この話題はこのドキュメントの範囲の外にあります。
7.2. Applicability
7.2. 適用性
NEMO operations rely on ND extensions over the Home Link for the Home Agent to Home Agent communication.
ネモ操作はホームのエージェントのためにホームLinkの上のノースダコタの拡大にホームエージェントコミュニケーションに依存します。
Making the Home Link virtual bars the deployment of multiple Home Agents, which may be desirable for reasons of load balancing. Please refer to the NEMO multihoming issues [9] for more on this.
ホームのLinkの仮想のバーを複数のホームのエージェントの展開にします。(そのエージェントは、ロードバランシングの理由で望ましいかもしれません)。 これで以上についてネモマルチホーミング問題[9]を参照してください。
Yet, for a deployment where a single Home Agent is enough, making the Home Link virtual reduces the vulnerability to some attacks and to some hardware failures, while making the Home Agent operation faster.
しかし、展開のために、ホームをLinkに仮想ですると、独身のホームのエージェントが十分であるところで脆弱性はホームエージェント操作をより速くしている間、いくつかの攻撃と、そして、いくつかのハードウェアの故障に減少します。
Note that NEMO basic does not mandate the support of Virtual Home Networks.
ネモ基礎がVirtualホームNetworksのサポートを強制しないことに注意してください。
8. NEMO Mobile Home Network
8. ネモ移動住宅ネットワーク
8.1. Configuration
8.1. 構成
In this arrangement, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent(s) and further subnetted into Mobile Networks. As a result, only the Home Agent(s) responsible for the most global (shortest prefix) aggregation receive all the packets for all the MNPs, which are leaves in the hierarchy tree.
このアレンジメントには、あります。aはホームNetworksの階層構造をbitwiseします。 グローバルなホームNetworkはヘッドホームのエージェントによってインフラストラクチャに広告を出されて、さらにモバイルNetworksに「副-網で覆」われます。 その結果、最もグローバルな(最も短い接頭語)集合に責任があるホームのエージェントだけがすべてのMNPのためにすべてのパケットを受けます。(MNPは階層構造木の葉です)。
Each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network. This Mobile Router is at home at the upper level of hierarchy. This configuration is referred to as Mobile Home.
各サブネットはそのネットワークのホームのエージェントとして務めている間にネモファッションでそれを登録するモバイルRouterによって所有されています。 上側のレベルの階層構造にはこのモバイルRouterが家にあります。 この構成はモバイルホームと呼ばれます。
An example of this is the Cab Co configuration. Cab Co is a taxi company that uses a /32 prefix for its Home Network, this prefix being advertised by the company headquarters (HQ). Regional offices are deployed around the country. Even though these regional offices
この例はCab Co構成です。 タクシーCoはホームNetwork(会社の本部(HQ)によって広告に掲載されているこの接頭語)に/32接頭語を使用するタクシー会社です。 支社は国中で配備されます。 これらの支社です。
Thubert, et al. Informational [Page 14] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[14ページ]のRFC4887ホームネットワークモデル
are relatively stable in terms of location and prefix requirement -- say, this changes every few years -- making them mobile allows a simpler management when a move has to take place, or should the ISP service change.
位置で比較的安定していて、要件--これはあらゆる数年単位で変化します--移動が行われなければならないとき、それらを可動にすると、より簡単な管理が許されると言うのを前に置くべきであるか、またはサービスが変えるISPを前に置くべきです。
To illustrate this configuration, we make up the prefixes to reflect their role, like CAB:C0::/32 for the Home Network:
私たちはこの構成を例証するために、以下をCAB: C0のようにそれらの役割を反映する接頭語にします:ホームネットワークのための/32:
global Home Network CAB:C0::/32 advertised by HQ
<------------------------------------------------------------------>
Network CAB: グローバルなホームC0:、:HQ<によって広告に掲載された/32------------------------------------------------------------------>。
HQ Extended Home Net Mobile Home for SFO office
(casa)
CAB:C0:CA5A::/48 CAB:C0:5F0::/48
<----------------------------> ... <------------------------------->
|
Home for offices HQ |
CAB:C0:CA5A:CA5A::/64 MN |
<----------------------><----> |
CAB:C0:CA5A:CA5A::CA5A |
CAB:C0:CA5A:CA5A::CA5B |
are HAs on link with for each office a route like |
|
CAB:C0:CA5A:CA5A::5F0 <---------------------- via
is the Home addr
of SFO office
SFOオフィス(カーサ)CAB:C0:CA5A:のためのHQ Extendedのホームのネットのモバイルホーム:/48タクシー:C0:5F0:、:/48<。---------------------------->… <-------------------------------> | オフィスHQのためのホーム| タクシー: C0: CA5A: CA5A::/64ミネソタ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、><、-、-、--、>| タクシー: C0: CA5A: CA5A::CA5A| タクシー: C0: CA5A: CA5A::CA5B| HAsがオンである、それぞれのオフィスaルートにリンクします。| | タクシー: C0: CA5A: CA5A::5F0<。---------------------- を通してホームはSFOオフィスのaddrです。
Figure 6: CAB Company HQ Configuration
図6: タクシー会社HQ構成
Finally, each regional office owns a number of taxis, each one equipped with a mobile router and an associated /64 prefix.
最終的に、各支社は多くのタクシー(可動のルータと関連/64接頭語を備えていたそれぞれ)を所有しています。
For each Office, say San Francisco (SFO) as an example:
各オフィスに、例としてサンフランシスコ(SFO)を言ってください:
Thubert, et al. Informational [Page 15] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[15ページ]のRFC4887ホームネットワークモデル
Mobile Home Network CAB:C0:5F0::/48 owned by SFO office
<------------------------------------------------------------------>
移動住宅ネットワークタクシー:C0:5F0:、:SFOオフィス<によって所有されていた/48------------------------------------------------------------------>。
SFO Home Network Mobile Networks for taxis
for taxis <---------------------...--------------------->
CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/64
<-------------------><-------------------> ... <------------------->
CAB:C0:5F0:5F0::5F0 |
is HA on link with for |
each taxi a route like |
|
CAB:C0:5F0:5F0::CAB1 <------ via
is the Home Address
of CAB 1
タクシー<のためのタクシーのためのSFOのホームのNetworkのモバイルNetworks---------------------...--------------------->タクシー:C0:5F0: 5F0:、:64タクシー: /C0:5F0:CAB1:、:/64タクシー:C0:5F0: …::/64<。-------------------><、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-->… <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-->タクシー:C0:5F0: 5F0:、:5F0| リンクの上にHAがあります。| タクシーaルートそれぞれ同様です。| | タクシー:C0:5F0: 5F0:、:CAB1<。------ を通してホームはCAB1のAddressです。
Figure 7: CAB Company regional configuration
図7: CABの会社の地方の構成
Note that this is a hierarchy in terms of MR-HA relationship, which may not be reflected in the physical arrangement of nodes at a given point of time. For instance, in the Cab Co case, some SFO cabs might attach to any hot spot or Cab Co office in a different city, and the SFO office might be at home if it is co-located with the headquarters. But note that SFO should never attach to one of its own cabs. This would create a stalemate situation, as documented in the NEMO Route Optimization (RO) problem statement [7].
これがMR-HA関係に関する階層構造であることに注意してください。(関係は時間の与えられたポイントでノードの物理的なアレンジメントに反映されないかもしれません)。 例えば、Cab Co場合では、いくつかのSFOタクシーが異なった都市のどんなホットスポットやCab Coオフィスにも付くかもしれません、そして、それが本部で共同見つけられているなら、SFOオフィスが家にあるかもしれません。 しかし、SFOがそれ自身のタクシーの1つに決して付くはずがないことに注意してください。 これはネモRoute Optimization(RO)問題声明[7]に記録されるように手詰まりの状況を作成するでしょう。
But it is also possible to reflect the organizational hierarchy in a moving cloud of Mobile Routers. If a Mobile Home Agent acts as root-MR for a nested configuration of its own Mobile Routers, then the communication between Mobile Routers is confined within the nested structure.
しかし、また、モバイルRoutersの感動的な雲に組織階層を反映するのも可能です。 モバイルホームのエージェントがそれ自身のモバイルRoutersの入れ子にされた構成のための根-MRとして務めるなら、モバイルRoutersのコミュニケーションは入れ子構造の中で限定されます。
This can be illustrated in the case of a fleet at sea. Assume that SFO is a communication ship of a fleet, using a satellite link to join the infrastructure, and that the cabs are Mobile Routers installed on smaller ships, equipped with low-range radios.
海で船隊の場合でこれを例証できます。 インフラストラクチャを接合するのに衛星中継を使用して、SFOが船隊のコミュニケーション船であり、タクシーが、より小さい低い範囲ラジオを装備している船の上にインストールされたモバイルRoutersであると仮定してください。
If SFO is also the root-MR of a nested structure of its own cabs, the communication between cabs is relayed by SFO and does not require the satellite link. As for traffic to the outside of the nested NEMO, SFO recursively terminates the nested tunnels from its cabs and reencapsulates all the packets between the nested cloud and correspondents in the infrastructure in a single tunnel to CA5A. As a result, the unwanted effect of nesting of tunnels is avoided over the Internet part of the packet path.
また、SFOがそれ自身のタクシーの入れ子構造についてMRを根づかせるなら、タクシーのコミュニケーションは、SFOによってリレーされて、衛星中継を必要としません。 入れ子にされたネモの外部への交通に関して、SFOはタクシーからの入れ子にされたトンネルを再帰的に終えて、reencapsulatesはCA5Aへの単一のトンネルのインフラストラクチャにおける入れ子にされた雲と通信員の間のすべてのパケットを終えます。 その結果、トンネルの巣篭もりの求められていない効果はパケット経路のインターネット地域の上避けられます。
Thubert, et al. Informational [Page 16] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[16ページ]のRFC4887ホームネットワークモデル
8.2. Applicability
8.2. 適用性
This complex topology applies to a large distributed fleet, mostly if there is a single interchange point with the Internet (e.g., a Network Address Transition (NAT) or a SOCKS [1] server farm) where the super Home Agent could be located.
この複雑なトポロジーは大きい分配された船隊に適用されます、ほとんどインターネット(例えば、Network Address Transition(NAT)かSOCKS[1]サーバー・ファーム)がある単一の置き換えポイントが最高のホームのエージェントが位置できたところにあれば。
One specific benefit is that when 2 Mobile Routers travel together with a common Home Agent, the traffic between the 2 is not necessarily routed via the infrastructure, but can stay confined within the mobile cloud, the Mobile Home Agent acting as a rendezvous point between the Mobile Routers. This applies particularly well for a fleet at sea when the long-haul access may be as expensive as a satellite link.
1つの特定の利益はモバイルRoutersが一般的なホームのエージェント、交通と共に旅行する2であるときに、2が必ずインフラストラクチャで発送されるというわけではありませんが、可動の雲の中で狭い状態で残ることができるということです、ランデブーがモバイルRoutersの間で指すのでモバイルホームのエージェントが行動して。 長期アクセスが衛星中継と同じくらい高価であるときに、これは海で船隊に特によく申し込みます。
9. Security Considerations
9. セキュリティ問題
This document only explains how a Home Network can be deployed to support Mobile Routers and does not introduce any additional security concerns. Please see RFC 3963 [5] for security considerations for the NEMO Basic Support protocol.
このドキュメントで、ホームNetworkがどうモバイルRoutersを支持するために配備できて、少しの追加担保関心も導入しないかがわかるだけです。 ネモBasic Supportプロトコルに関してセキュリティ問題のためのRFC3963[5]を見てください。
10. Acknowledgements
10. 承認
The authors wish to thank Erik Nordmark, Jari Arkko, Henrik Levkowetz, Scott Hollenbeck, Ted Hardie, David Kessens, Pekka Savola, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick Wetterwald, Alexandru Petrescu, and David Binet for their contributions.
彼らの貢献のためのエリックNordmarkに感謝するという作者願望、ヤリArkko、Henrik Levkowetz、スコットHollenbeck、テッド・ハーディー、デヴィッドKessens、ペッカSavola、ケントレオン、ティエリー・エルンスト、TJ Kniveton、パトリックWetterwald、Alexandruペトレスク、およびデヴィッドBinet。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L.
Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[1] ヒル、M.、Ganis M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、1996年3月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[3] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
Thubert, et al. Informational [Page 17] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[17ページ]のRFC4887ホームネットワークモデル
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
July 2007.
[6] エルンストとT.とH.ラック、「ネットワーク移動性サポート用語」、2007年7月。
11.2. Informative References
11.2. 有益な参照
[7] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
Route Optimization Problem Statement", RFC 4888, July 2007.
[7] ウンとC.とThubertとP.と亘理、M.とF.チャオ、「ネットワーク移動性経路最適化問題声明」、RFC4888、2007年7月。
[8] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[8] ターレル、D.、Talwar、M.、およびC.パテル、「隣人発見プロキシ(第プロキシ)」、RFC4389、2006年4月。
[9] Ng, C., "Analysis of Multihoming in Network Mobility Support",
Work in Progress, February 2007.
[9] ウン、C.、「ネットワーク移動性サポートにおける、マルチホーミングの分析」、処理中の作業、2007年2月。
Authors' Addresses
作者のアドレス
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
パスカルThubertシスコシステムズVillage d'EntreprisesグリーンSide400、アベニューdeルーマニーユBatiment T3、Biot--ソフィアAntipolis06410フランス
Phone: +33 4 97 23 26 34 EMail: pthubert@cisco.com
以下に電話をしてください。 +33 4 97 23 26 34はメールされます: pthubert@cisco.com
Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN
龍治Wakikawa慶応義塾大学と広い5322遠藤藤沢神奈川252-8520日本
EMail: ryuji@sfc.wide.ad.jp
メール: ryuji@sfc.wide.ad.jp
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 94054 USA
ビジェイDevarapalli Azaireは3121ジェイ・通りカリフォルニア94054サンタクララ(米国)をネットワークでつなぎます。
EMail: vijay.devarapalli@azairenet.com
メール: vijay.devarapalli@azairenet.com
Thubert, et al. Informational [Page 18] RFC 4887 Home Network Models with NEMO Basic July 2007
Thubert、他 ネモが2007年7月に基本的の情報[18ページ]のRFC4887ホームネットワークモデル
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機能のための基金は現在、インターネット協会によって提供されます。
Thubert, et al. Informational [Page 19]
Thubert、他 情報[19ページ]
一覧
スポンサーリンク
