[要約] RFC 7563は、Proxy Mobile IPv6(PMIPv6)アクセスネットワーク識別子オプションの拡張に関するものです。このRFCの目的は、PMIPv6ネットワークでのモビリティ管理を向上させるために、アクセスネットワーク識別子オプションの機能を拡張することです。

Internet Engineering Task Force (IETF)                     R. Pazhyannur
Request for Comments: 7563                                   S. Speicher
Updates: 6757                                              S. Gundavelli
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                              J. Korhonen
                                                    Broadcom Corporation
                                                       J. Kaippallimalil
                                                                  Huawei
                                                               June 2015
        

Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option

プロキシモバイルIPv6(PMIPv6)アクセスネットワーク識別子オプションの拡張

Abstract

概要

The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

アクセスネットワーク識別子(ANI)モビリティオプションは、RFC 6757「プロキシモバイルIPv6のアクセスネットワーク識別子(ANI)オプション」で導入されました。これにより、モバイルアクセスゲートウェイ(MAG)は、ネットワーク識別子、地理位置情報、オペレーター識別子などの識別子を伝達できます。この仕様は、市区町村の場所とMAGグループIDを保持するサブオプションを使用して、アクセスネットワークIDモビリティオプションを拡張します。この仕様は、ANIオプションが更新される時期と頻度を決定するANI Update-Timerサブオプションも定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7563.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7563で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(http://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Extension  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Civic-Location Sub-Option . . . . . . . . . . . . . . . .   5
     3.2.  MAG-Group-Identifier Sub-Option . . . . . . . . . . . . .   6
     3.3.  ANI Update-Timer Sub-Option . . . . . . . . . . . . . . .   6
   4.  Protocol Considerations . . . . . . . . . . . . . . . . . . .   7
     4.1.  MAG Considerations  . . . . . . . . . . . . . . . . . . .   7
     4.2.  LMA Considerations  . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
        
1. Introduction
1. はじめに

"Access Network Identifier (ANI) Option for Proxy Mobile IPv6" [RFC6757] introduced the ANI mobility option. This enabled a Mobile Access Gateway (MAG) to provide the Network-Identifier, Geo-Location, and Operator-Identifier sub-options. When the access network is WLAN, the Network-Identifier sub-option may contain the Service Set Identifier (SSID) and the Basic Service Set Identifier (BSSID) of the Access Point (AP) and the geolocation of the AP, and the Operator-Identifier may contain the realm of the operator managing the WLAN. The MAG sends the above information to the Local Mobility Anchor (LMA). The LMA may use this information to determine access-network-specific policies (in terms of Quality of Service (QoS), Deep Packet Inspection (DPI), etc.). Further, the LMA may make this information available to location-based applications.

「プロキシモバイルIPv6のAccess Network Identifier(ANI)オプション」[RFC6757]では、ANIモビリティオプションが導入されました。これにより、モバイルアクセスゲートウェイ(MAG)は、ネットワーク識別子、地理位置情報、およびオペレーター識別子のサブオプションを提供できるようになりました。アクセスネットワークがWLANの場合、Network-Identifierサブオプションには、アクセスポイント(AP)のサービスセット識別子(SSID)と基本サービスセット識別子(BSSID)、およびAPの地理位置情報と、オペレーター識別子には、WLANを管理する事業者の領域を含めることができます。 MAGは上記の情報をローカルモビリティアンカー(LMA)に送信します。 LMAはこの情報を使用して、アクセスネットワーク固有のポリシー(Quality of Service(QoS)、Deep Packet Inspection(DPI)などに関して)を決定します。さらに、LMAはこの情報をロケーションベースのアプリケーションで利用できるようにする場合があります。

While the above mentioned sub-options provide a rich set of information, in this document we describe the need for extending the ANI sub-options that are particularly useful in WLAN deployments. In WLAN deployments (especially indoor AP deployments), it is difficult to provide geospatial coordinates of APs. At the same time, for many location-based applications the civic location is sufficient. This motivates the need for an ANI Civic-Location sub-option. In many deployments, operators tend to create groups of APs into "AP-Groups". These groups have a group identifier. The group identifier is used as a proxy for coarse location (such as the floor of a building or a small building). The group identifier may also be used to provide a common policy (e.g., QoS, charging, DPI) for all APs in that group. This specification provides a sub-option for the MAG to convey a group identifier to the LMA. The provisioning of the group identifier is outside the scope of this specification and is typically done via a configuration mechanism such as CLI (Command-line Interface) or via Control and Provisioning of Wireless Access Points (CAPWAP) [RFC5415] [RFC5416].

上記のサブオプションは豊富な情報を提供しますが、このドキュメントでは、WLAN展開で特に役立つANIサブオプションを拡張する必要性について説明します。 WLAN展開(特に屋内AP展開)では、APの地理空間座標を提供することは困難です。同時に、多くの場所ベースのアプリケーションでは、都市の場所で十分です。これにより、ANI Civic-Locationサブオプションが必要になります。多くの展開では、オペレータはAPのグループを「APグループ」に作成する傾向があります。これらのグループにはグループ識別子があります。グループIDは、大まかな場所(建物の床や小さな建物など)のプロキシとして使用されます。グループ識別子を使用して、そのグループ内のすべてのAPに共通のポリシー(QoS、課金、DPIなど)を提供することもできます。この仕様は、MAGがグループ識別子をLMAに伝達するためのサブオプションを提供します。グループ識別子のプロビジョニングはこの仕様の範囲外であり、通常はCLI(コマンドラインインターフェイス)などの構成メカニズムまたはワイヤレスアクセスポイントの制御とプロビジョニング(CAPWAP)[RFC5415] [RFC5416]を介して行われます。

This document also provides a new sub-option that determines how often the MAG will update the ANI. In typical deployments, it is expected that the MAG will update the ANI as soon as it changes. This is certainly true when the MAG is co-located with the AP. When a client roams from one AP to another AP, the MAG on the roamed (or sometimes referred to as the target) AP will provide the new ANI (for example, the network identifier and geolocation of the new AP). However, if the MAG is co-located with an Access Controller (also known as Wireless LAN Controller (WLC)), then a client roaming from one AP to another AP does not necessarily perform an ANI update. The WLC handles client mobility between APs and as a result, intra-WLC mobility is hidden from the LMA.

このドキュメントは、MAGがANIを更新する頻度を決定する新しいサブオプションも提供します。典型的な展開では、MAGは変更されるとすぐにANIを更新することが予想されます。これは、MAGがAPと同じ場所に配置されている場合は確かに当てはまります。クライアントが1つのAPから別のAPにローミングすると、ローミングされた(またはターゲットと呼ばれることもある)APのMAGが新しいANI(たとえば、新しいAPのネットワーク識別子や地理位置情報)を提供します。ただし、MAGがアクセスコントローラー(ワイヤレスLANコントローラー(WLC)とも呼ばれます)と同じ場所に配置されている場合、あるAPから別のAPにローミングするクライアントは必ずしもANI更新を実行しません。 WLCはAP間のクライアントモビリティを処理するため、WLC内モビリティはLMAから隠されます。

In such deployments, the information conveyed in the ANI sub-options (e.g., location) becomes stale and is only refreshed at the time of lifetime expiry. The MAG could deal with this by sending a Proxy Binding Update (PBU) whenever a client moves between APs just for the purpose of updating the ANI sub-option. Alternately, this document allows the LMA to determine how often it wants to know about the changes in the ANI sub-option; for example, in some cases the LMA may not care about the ANI sub-option except at the time of initial binding, or in some cases it may care about every AP transition. The sub-option allows the LMA to tell the MAG the desired update frequency. As always, mobility events or re-registration events will update the ANI sub-options. The LMA can use the ANI Update-Timer option to set the maximum frequency at which it wants to receive ANI updates. This is particularly useful in environments where a MAG covers a large number of Wi-Fi APs and there is high client mobility between the APs; for example, in a stadium Wi-Fi deployment, if a LMA does not want ANI updates any more often than 100 seconds, then it can propose 100 seconds as the value for ANI Update-Timer.

このような展開では、ANIサブオプションで伝えられる情報(場所など)は古くなり、有効期限が切れたときにのみ更新されます。 MAGは、ANIサブオプションを更新するためだけにクライアントがAP間を移動するたびに、Proxy Binding Update(PBU)を送信することでこれに対処できます。または、このドキュメントにより、LMAはANIサブオプションの変更について知りたい頻度を決定できます。たとえば、LMAは最初のバインディング時を除いてANIサブオプションを気にしない場合や、すべてのAPの移行を気にする場合があります。サブオプションにより、LMAはMAGに必要な更新頻度を通知できます。いつものように、モビリティイベントまたは再登録イベントは、ANIサブオプションを更新します。 LMAは、ANI Update-Timerオプションを使用して、ANI更新を受信する最大頻度を設定できます。これは、MAGが多数のWi-Fi APをカバーし、AP間のクライアントモビリティが高い環境で特に役立ちます。たとえば、スタジアムWi-Fi展開で、LMAが100秒を超える頻度でANI更新を望まない場合、LMAはANI Update-Timerの値として100秒を提案できます。

[RFC6757] provides ANI sub-options to carry geolocation information. In this document, we provide additional sub-options to carry the civic location and group identifier. This document also defines an ANI sub-option to enable a MAG to communicate how often the MAG will update the ANI information.

[RFC6757]は、地理​​位置情報を運ぶためのANIサブオプションを提供します。このドキュメントでは、都市の場所とグループ識別子を保持するための追加のサブオプションを提供します。このドキュメントでは、MAGがANI情報を更新する頻度をMAGが通信できるようにするANIサブオプションも定義しています。

2. Conventions and Terminology
2. 表記法と用語
2.1. Conventions
2.1. 規約

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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

2.2. Terminology
2.2. 用語

All of the mobility-related terms used in this document are to be interpreted as defined in [RFC5213] and [RFC5844]. In this document, Civic Location is defined as follows.

このドキュメントで使用されているモビリティ関連の用語はすべて、[RFC5213]および[RFC5844]で定義されているとおりに解釈されます。このドキュメントでは、Civic Locationは次のように定義されています。

Civic Location: There are two common ways to identify the location of an object, either through geospatial coordinates or by so-called civic addresses. Geospatial coordinates indicate longitude, latitude, and altitude, while civic addresses indicate a street address or sometimes the location within a building (such as a room number). Civic location refers to the civic address.

市民の場所:オブジェクトの場所を特定するには、地理空間座標またはいわゆる市民の住所のいずれかを使用して、2つの一般的な方法があります。地理空間座標は経度、緯度、高度を示しますが、都市の住所は通りの住所、または建物内の場所(部屋番号など)を示す場合があります。市の場所は、市の住所を指します。

3. Protocol Extension
3. プロトコル拡張
3.1. Civic-Location Sub-Option
3.1. Civic-Locationサブオプション

The Civic-Location is a mobility sub-option carried in the Access Network Identifier option defined in [RFC6757]. This sub-option carries the civic location information of the mobile node as known to the MAG. The format of this option is defined below.

Civic-Locationは、[RFC6757]で定義されているAccess Network Identifierオプションに含まれるモビリティサブオプションです。このサブオプションは、MAGに認識されているモバイルノードの都市ロケーション情報を伝送します。このオプションのフォーマットは以下に定義されています。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ANI Type=4     |  ANI Length   |   Format      | Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            civic location                                     ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 1: Civic-Location Sub-Option

図1:Civic-Locationサブオプション

ANI Type: 4

ANIタイプ:4

ANI Length: Total length of this sub-option in octets, excluding the ANI Type and ANI Length fields.

ANI長さ:オクテット単位のこのサブオプションの全長(ANIタイプおよびANI長さフィールドを除く)。

Format: This specifies the encoding format of the civic location. The value 0 is defined in this specification as described below. The remaining values (1 through 255) are reserved.

形式:これは、都市の場所のエンコード形式を指定します。この仕様では、値0が以下のように定義されています。残りの値(1〜255)は予約されています。

0: This value denotes Binary Encoding. The location format is based on the encoding format defined in Section 3.1 of [RFC4776], whereby the first 3 octets are not put into the civic location field (i.e., the code for the DHCP option, the length of the DHCP option, and the 'what' element are not included). What is included is the two-octet country code field, followed by one or more civic address elements. The country-code is a two-letter ISO 3166 country code in capital ASCII letters, e.g., US. The structure of the civic address elements that follow the country code field is as defined in Section 3.3 of [RFC4776].

0:この値はバイナリエンコーディングを示します。場所の形式は、[RFC4776]のセクション3.1で定義されているエンコード形式に基づいています。これにより、最初の3オクテットが都市の場所フィールドに入力されません(つまり、DHCPオプションのコード、DHCPオプションの長さ、および「what」要素は含まれません)。含まれているのは、2オクテットの国コードフィールドであり、その後に1つ以上の市民住所要素が続きます。国コードは、大文字のASCII文字の2文字のISO 3166国コードです(例:US)。国コードフィールドに続く市民住所要素の構造は、[RFC4776]のセクション3.3で定義されています。

Reserved: This MUST be set to zero when sending and ignored when received.

予約済み:送信時にはゼロに設定し、受信時には無視する必要があります。

civic location: This field will contain the civic location. The format (encoding) type is specified in the format field of this sub-option. Note that the length SHALL NOT exceed 253 bytes.

都市の場所:このフィールドには、都市の場所が含まれます。フォーマット(エンコード)タイプは、このサブオプションのフォーマットフィールドで指定されます。長さが253バイトを超えてはならないことに注意してください。

3.2. MAG-Group-Identifier Sub-Option
3.2. MAG-Group-Identifierサブオプション

The MAG group identifier is a mobility sub-option carried in the Access Network Identifier option defined in [RFC6757]. The MAG group identifier identifies the group affiliation of the MAG within that Proxy Mobile IPv6 domain. The group identifier is not assumed to be globally unique across different network operators. However, the group identifier should be unique within an operator network. In domains spanning multiple operators, it is recommended that the Operator-Identifier sub-option (defined in [RFC6757]) be used in addition to the MAG-Group-Identifier sub-option to ensure uniqueness. When the MAG is configured with a group identifier, the MAG should send its group identifier in the PBU. Note that the configuration of this identifier is outside the scope of this specification; the usage of the identifier by the LMA is left to implementation. The format of this sub-option is defined below.

MAGグループ識別子は、[RFC6757]で定義されているAccess Network Identifierオプションに含まれるモビリティサブオプションです。 MAGグループIDは、そのプロキシモバイルIPv6ドメイン内のMAGのグループ所属を識別します。グループ識別子は、さまざまなネットワークオペレータ間でグローバルに一意であるとは想定されていません。ただし、グループ識別子は事業者ネットワーク内で一意である必要があります。複数のオペレーターにまたがるドメインでは、MAG-Group-Identifierサブオプションに加えて、Operator-Identifierサブオプション([RFC6757]で定義)を使用して、一意性を確保することをお勧めします。 MAGにグループIDが構成されている場合、MAGはそのグループIDをPBUで送信する必要があります。この識別子の構成はこの仕様の範囲外であることに注意してください。 LMAによる識別子の使用は実装に任されています。このサブオプションのフォーマットは以下に定義されています。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ANI Type=5     |  ANI Length   |  group identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 2: MAG-Group-Identifier Sub-Option

図2:MAG-Group-Identifierサブオプション

ANI Type: 5

ANIタイプ:5

ANI Length: Total length of this sub-option in octets, excluding the ANI Type and ANI Length fields. The value is always 2.

ANI長さ:オクテット単位のこのサブオプションの全長(ANIタイプおよびANI長さフィールドを除く)。値は常に2です。

group identifier: This is a 3-octet unsigned integer value assigned to a group of MAGs.

グループ識別子:これは、MAGのグループに割り当てられる3オクテットの符号なし整数値です。

3.3. ANI Update-Timer Sub-Option
3.3. ANI更新タイマーサブオプション

The ANI Update-Timer is a mobility sub-option carried in the ANI option defined in [RFC6757]. Section 4 describes how the MAG and LMA use this sub-option.

ANI Update-Timerは、[RFC6757]で定義されているANIオプションに含まれるモビリティサブオプションです。セクション4では、MAGとLMAがこのサブオプションをどのように使用するかについて説明します。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |ANI Type=6     |  ANI Length   |       Update-Timer            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Figure 3: ANI Update-Timer Sub-Option

図3:ANI Update-Timerサブオプション

ANI Type: 6

ANIタイプ:6

ANI Length: Total length of this sub-option in octets, excluding the ANI Type and ANI Length fields. The value is always 2.

ANI長さ:オクテット単位のこのサブオプションの全長(ANIタイプおよびANI長さフィールドを除く)。値は常に2です。

Update-Timer: Update-Timer is a 16-bit unsigned integer. The unit of time is 4 seconds (time unit of 4 seconds ensures consistency with the time units for the binding lifetime). A value of 0 indicates that the MAG will send an updated ANI mobility option as soon as it discovers a change in ANI values. A non-zero value indicates that the MAG may not send ANI values immediately after they have changed but rather send ANI updates when the Update-Timer expires.

Update-Timer:Update-Timerは、16ビットの符号なし整数です。時間の単位は4秒です(4秒の時間単位は、バインディングの有効期間の時間単位との一貫性を保証します)。値0は、MAGがANI値の変更を検出するとすぐに、更新されたANIモビリティオプションを送信することを示します。ゼロ以外の値は、MAGが変更後すぐにANI値を送信せず、Update-Timerが期限切れになったときにANI更新を送信する可能性があることを示します。

4. Protocol Considerations
4. プロトコルに関する考慮事項

The following considerations apply to the LMA and the MAG.

LMAとMAGには次の考慮事項が適用されます。

4.1. MAG Considerations
4.1. MAGに関する考慮事項

o The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to store the access-network-related information elements associated with the current session. Specifically, the following parameters are defined:

o [RFC5213]のセクション6.1で説明されているモバイルアクセスゲートウェイによって維持される概念的なバインディングアップデートリストエントリのデータ構造は、現在のセッションに関連付けられているアクセスネットワーク関連の情報要素を格納するように拡張されています。具体的には、次のパラメータが定義されています。

* civic location

* 市民の場所

* MAG group identifier

* MAGグループID

* ANI Update-Timer

* ANI更新タイマー

o If the mobile access gateway is configured to support the Access Network Information sub-options defined in this specification, it includes this option with the specific sub-options in all PBU messages (including PBUs for lifetime extension and for deregistration) that it sends to the LMA. The Access Network Information option is constructed as specified in Section 3.

o モバイルアクセスゲートウェイが、この仕様で定義されているアクセスネットワーク情報サブオプションをサポートするように構成されている場合は、このオプションをすべてのPBUメッセージ(ライフタイム延長および登録解除用のPBUを含む)に送信する特定のサブオプションが含まれます。 LMA。 [ネットワーク情報へのアクセス]オプションは、セクション3で指定されているとおりに作成されます。

o ANI Update-Timer Considerations: The MAG sets the Update-Timer based on an exchange of timer values with the LMA. When the ANI Update-Timer sub-option is carried in a PBU, it is considered as a proposed value for the Update-Timer. The LMA may change the value of the Update-Timer received in the PBU. When the LMA-provided value for the Update-Timer is different than what is sent by the MAG, the MAG should use the LMA-provided value. If the MAG does not receive an ANI Update-Timer sub-option in the Proxy Binding Acknowledgement (PBA) (in response to sending the sub-option in the PBU), then MAG behavior is in accordance to [RFC6757]. When ANI parameters of a mobility session change, the MAG checks whether the Update-Timer has expired. If the Update-Timer has expired, the MAG sends a PBU with the ANI option. The ANI option reflects the updated access network parameters for that mobility session. If the Update-Timer has not expired, the MAG does not send a PBU. When the Update-Timer for a mobility session expires, the MAG checks whether the ANI parameters have changed. If the parameters have changed from the last reported values, the MAG sends a PBU with an ANI option. If the parameters have not changed, the MAG does not send a PBU (and the Update-Timer remains expired). Note that the MAG may send a PBU even before the Update-Timer expires. This could be, for example, to initiate a QoS service request to the LMA (see [RFC7222]). In such cases, the MAG must reset the Update-Timer when it sends a PBU.

o ANI更新タイマーの考慮事項:MAGは、LMAとのタイマー値の交換に基づいて更新タイマーを設定します。 ANI Update-TimerサブオプションがPBUで実行される場合、それはUpdate-Timerの推奨値と見なされます。 LMAは、PBUで受信したUpdate-Timerの値を変更する場合があります。 LMAが提供するUpdate-Timerの値がMAGから送信される値と異なる場合、MAGはLMAが提供する値を使用する必要があります。 MAGが(PBUでのサブオプションの送信に応じて)プロキシバインディング確認(PBA)でANI Update-Timerサブオプションを受信しない場合、MAGの動作は[RFC6757]に従います。モビリティセッションのANIパラメータが変更されると、MAGはUpdate-Timerが期限切れになったかどうかを確認します。 Update-Timerの有効期限が切れている場合、MAGはANIオプションを指定してPBUを送信します。 ANIオプションは、そのモビリティセッションの更新されたアクセスネットワークパラメータを反映します。 Update-Timerの有効期限が切れていない場合、MAGはPBUを送信しません。モビリティセッションのUpdate-Timerが期限切れになると、MAGは、ANIパラメータが変更されたかどうかを確認します。パラメータが最後に報告された値から変更されている場合、MAGはANIオプションを使用してPBUを送信します。パラメーターが変更されていない場合、MAGはPBUを送信しません(そして、Update-Timerは期限切れのままです)。 MAGは、Update-Timerが期限切れになる前でもPBUを送信する場合があることに注意してください。これは、たとえば、LMAへのQoSサービス要求を開始するためのものです([RFC7222]を参照)。このような場合、MAGはPBUを送信するときにUpdate-Timerをリセットする必要があります。

o If the mobile access gateway had any of the Access Network Information mobility options included in the PBU sent to an LMA, then the PBA received from the LMA should contain the Access Network Information mobility option with the specific sub-options. If the mobile access gateway receives a PBA with a successful Status Value but without an Access Network Information mobility option, then the mobile access gateway may log the event and, based on its local policy, even proceed to terminate the mobility session. In this case, the mobile access gateway knows the LMA does not understand the Access Network Information mobility option.

o モバイルアクセスゲートウェイのLMAに送信されたPBUに含まれるアクセスネットワーク情報モビリティオプションのいずれかがある場合、LMAから受信したPBAには、特定のサブオプションを持つアクセスネットワーク情報モビリティオプションが含まれている必要があります。モバイルアクセスゲートウェイが、ステータス値は成功したがアクセスネットワーク情報モビリティオプションのないPBAを受信した場合、モバイルアクセスゲートウェイはイベントをログに記録し、ローカルポリシーに基づいて、モビリティセッションの終了に進むことさえできます。この場合、モバイルアクセスゲートウェイは、LMAがアクセスネットワーク情報モビリティオプションを理解していないことを認識しています。

4.2. LMA Considerations
4.2. LMAに関する考慮事項

o The conceptual Binding Cache entry data structure maintained by the LMA, described in Section 5.1 of [RFC5213], is extended to store the access-network-related information elements associated with the current session. Specifically, the following parameters are defined:

o [RFC5213]のセクション5.1で説明されているLMAによって維持される概念的なバインディングキャッシュエントリのデータ構造は、現在のセッションに関連付けられているアクセスネットワーク関連の情報要素を格納するように拡張されています。具体的には、次のパラメータが定義されています。

* civic location

* 市民の場所

* MAG group identifier

* MAGグループID

* ANI Update-Timer

* ANI更新タイマー

o On receiving a PBU message from a MAG with the ANI option, the LMA must process the option and update the corresponding fields in the Binding Cache entry. If the option is not understood by that LMA implementation, it will skip the option and process the PBU without these options.

o AMAオプションを使用してMAGからPBUメッセージを受信すると、LMAはオプションを処理し、バインディングキャッシュエントリの対応するフィールドを更新する必要があります。オプションがそのLMA実装によって理解されない場合、オプションはスキップされ、これらのオプションなしでPBUが処理されます。

o If the received PBU message does not include the Access Network Information option, then the mobility session associated with that PBU is updated to remove any access network information elements.

o 受信したPBUメッセージにAccess Network Informationオプションが含まれていない場合、そのPBUに関連付けられているモビリティセッションが更新され、アクセスネットワーク情報要素が削除されます。

o If the LMA understands/supports the Access Network Identifier mobility sub-options defined in this specification, then the LMA echoes the Access Network Identifier mobility option with the specific sub-option(s) that it accepted back to the mobile access gateway in a PBA. The Civic-Location and MAG-Group-Identifier sub-options defined in this specification should not be altered by the LMA. The LMA may change the value of the ANI Update-Timer sub-option. It may choose to either echo the same value or increase or decrease the timer value. For example, if the LMA does not want to receive frequent updates (as implied by the timer value), it may choose to increase the value. Similarly, if the LMA needs to receive ANI updates as soon as possible, then it may set the value to zero (0) in the PBA.

o LMAがこの仕様で定義されているアクセスネットワーク識別子モビリティサブオプションを理解/サポートしている場合、LMAはアクセスネットワーク識別子モビリティオプションを、PBA内のモバイルアクセスゲートウェイに受け入れた特定のサブオプションとともにエコーします。 。この仕様で定義されているCivic-LocationおよびMAG-Group-Identifierサブオプションは、LMAによって変更されるべきではありません。 LMAは、ANI Update-Timerサブオプションの値を変更する場合があります。同じ値をエコーするか、タイマー値を増減するかを選択できます。たとえば、LMAが頻繁な更新の受信を望まない場合(タイマー値によって暗示されるように)、値を増やすことを選択できます。同様に、LMAがANI更新をできるだけ早く受信する必要がある場合、PBAで値をゼロ(0)に設定することがあります。

5. IANA Considerations
5. IANAに関する考慮事項

IANA has registered the values described below.

IANAは以下の値を登録しています。

o This specification defines a new Access Network Identifier sub-option called the Civic-Location sub-option. This mobility sub-option is described in Section 3.1 and this sub-option can be carried in the Access Network Identifier mobility option. The type value <4> has been allocated from the registry "Access Network Information (ANI) Sub-Option Type Values".

o この仕様は、Civic-Locationサブオプションと呼ばれる新しいAccess Network Identifierサブオプションを定義しています。このモビリティサブオプションはセクション3.1で説明されており、このサブオプションはAccess Network Identifierモビリティオプションで使用できます。タイプ値<4>は、レジストリ「Access Network Information(ANI)Sub-Option Type Values」から割り当てられています。

o This specification defines a new Access Network Identifier sub-option called the MAG-Group-Identifier sub-option. This mobility sub-option is described in Section 3.2 and this sub-option can be carried in Access Network Identifier mobility option. The type value <5> has been allocated from the registry "Access Network Information (ANI) Sub-Option Type Values".

o この仕様は、MAG-Group-Identifierサブオプションと呼ばれる新しいAccess Network Identifierサブオプションを定義しています。このモビリティサブオプションはセクション3.2で説明されており、このサブオプションはAccess Network Identifierモビリティオプションで実行できます。タイプ値<5>は、レジストリ「Access Network Information(ANI)Sub-Option Type Values」から割り当てられています。

o This specification defines a new Access Network Identifier sub-option called the ANI Update-Timer sub-option. This sub-option is described in Section 3.3 and this sub-option can be carried in the Access Network Identifier mobility option. The type value <6> has been allocated from the registry "Access Network Information (ANI) Sub-Option Type Values".

o この仕様は、ANI Update-Timerサブオプションと呼ばれる新しいAccess Network Identifierサブオプションを定義しています。このサブオプションはセクション3.3で説明されており、このサブオプションはAccess Network Identifierモビリティオプションで使用できます。タイプ値<6>は、レジストリ「Access Network Information(ANI)Sub-Option Type Values」から割り当てられています。

6. Security Considerations
6. セキュリティに関する考慮事項

The Civic-Location sub-option defined in this specification is carried in the Access Network Identifier option defined in [RFC6757]. This sub-option is carried in PBU and PBA messages. This sub-option is carried like any other Access Network Identifier sub-option as defined in [RFC6757]. Therefore, it inherits its security guidelines from [RFC5213] and [RFC6757] and does not require any additional security considerations.

この仕様で定義されているCivic-Locationサブオプションは、[RFC6757]で定義されているAccess Network Identifierオプションに含まれています。このサブオプションは、PBUおよびPBAメッセージで伝達されます。このサブオプションは、[RFC6757]で定義されている他のAccess Network Identifierサブオプションと同様に実行されます。したがって、[RFC5213]および[RFC6757]からセキュリティガイドラインを継承し、セキュリティに関する追加の考慮事項を必要としません。

The Civic-Location sub-option exposes the civic location of the network to which the mobile node is attached. This information is considered to be very sensitive, so care must be taken to secure the Proxy Mobile IPv6 signaling messages when carrying this sub-option. The base Proxy Mobile IPv6 specification [RFC5213] specifies the use of IPsec for securing the signaling messages, and those mechanisms can be enabled for protecting this information. Operators can potentially apply IPsec Encapsulating Security Payload (ESP) with confidentiality and integrity protection for protecting the location information. The other way to protect the sensitive location information of network users is of course to not send it in the first place. Users of the Civic-Location sub-option should provision location values with the highest possible level of granularity, e.g., to the province or city level rather than provisioning specific addresses.

Civic-Locationサブオプションは、モバイルノードが接続されているネットワークの都市の場所を公開します。この情報は非常に機密性が高いと見なされているため、このサブオプションを伝送する場合は、プロキシモバイルIPv6シグナリングメッセージを保護するように注意する必要があります。ベースのプロキシモバイルIPv6仕様[RFC5213]は、シグナリングメッセージを保護するためのIPsecの使用を指定しており、これらのメカニズムを有効にして、この情報を保護できます。オペレーターは、位置情報を保護するための機密性と整合性の保護を備えたIPsecカプセル化セキュリティペイロード(ESP)を適用する可能性があります。もちろん、ネットワークユーザーの機密性の高い位置情報を保護するもう1つの方法は、そもそも送信しないことです。 Civic-Locationサブオプションのユーザーは、特定の住所をプロビジョニングするのではなく、最高レベルの粒度で、たとえば州または都市レベルにロケーション値をプロビジョニングする必要があります。

Access-network-specific information elements that the mobile access gateway sends may have been dynamically learned over DHCP or using other protocols. If proper security mechanisms are not in place, the exchanged information between the MAG and LMA may be compromised. This situation may result in incorrect service policy enforcement at the LMA and impact other services that depend on this access network information. This threat can be mitigated by ensuring the communication path between the mobile access gateway and the access points is properly secured by the use of IPsec, Transport Layer Security (TLS), or other security protocols.

モバイルアクセスゲートウェイが送信するアクセスネットワーク固有の情報要素は、DHCPまたは他のプロトコルを使用して動的に学習された可能性があります。適切なセキュリティメカニズムが導入されていない場合、MAGとLMAの間で交換される情報が危険にさらされる可能性があります。この状況により、LMAでのサービスポリシーの適用が不正確になり、このアクセスネットワーク情報に依存する他のサービスに影響を与える場合があります。この脅威は、モバイルアクセスゲートウェイとアクセスポイント間の通信パスがIPsec、トランスポート層セキュリティ(TLS)、またはその他のセキュリティプロトコルを使用して適切に保護されていることを確認することで軽減できます。

7. References
7. 参考文献
7.1. Normative References
7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, DOI 10.17487/RFC4776, November 2006, <http://www.rfc-editor.org/info/rfc4776>.

[RFC4776] Schulzrinne、H。、「Divamic Host Configuration Protocol(DHCPv4 and DHCPv6)Option for Civic Addresses Configuration Information」、RFC 4776、DOI 10.17487 / RFC4776、2006年11月、<http://www.rfc-editor.org/ info / rfc4776>。

[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.

[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、DOI 10.17487 / RFC5213、August 2008、<http ://www.rfc-editor.org/info/rfc5213>。

[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.

[RFC5844]脇川、R.、S。ガンダベリ、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、DOI 10.17487 / RFC5844、2010年5月、<http://www.rfc-editor.org/info/rfc5844>。

[RFC6757] Gundavelli, S., Ed., Korhonen, J., Ed., Grayson, M., Leung, K., and R. Pazhyannur, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6", RFC 6757, DOI 10.17487/RFC6757, October 2012, <http://www.rfc-editor.org/info/rfc6757>.

[RFC6757] Gundavelli、S.、Ed。、Korhonen、J.、Ed。、Grayson、M.、Leung、K.、and R. Pazhyannur、 "Access Network Identifier(ANI)Option for Proxy Mobile IPv6"、RFC 6757 、DOI 10.17487 / RFC6757、2012年10月、<http://www.rfc-editor.org/info/rfc6757>。

[RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality-of-Service Option for Proxy Mobile IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, <http://www.rfc-editor.org/info/rfc7222>.

[RFC7222] Liebsch、M.、Seite、P.、Yokota、H.、Korhonen、J。、およびS. Gundavelli、「Proxy-of-Service Option for Proxy Mobile IPv6」、RFC 7222、DOI 10.17487 / RFC7222、May 2014、<http://www.rfc-editor.org/info/rfc7222>。

7.2. Informative References
7.2. 参考引用

[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, <http://www.rfc-editor.org/info/rfc5415>.

[RFC5415] Calhoun、P.、Ed。、Montemurro、M.、Ed。、and D. Stanley、Ed。、 "Control And Provisioning of Wireless Access Points(CAPWAP)Protocol Specification"、RFC 5415、DOI 10.17487 / RFC5415、 2009年3月、<http://www.rfc-editor.org/info/rfc5415>。

[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, DOI 10.17487/RFC5416, March 2009, <http://www.rfc-editor.org/info/rfc5416>.

[RFC5416] Calhoun、P。、編、Montemurro、M、編、およびD. Stanley、編、「IEEE 802.11用のワイヤレスアクセスポイント(CAPWAP)プロトコルバインディングの制御とプロビジョニング」、RFC 5416、DOI 10.17487 / RFC5416、2009年3月、<http://www.rfc-editor.org/info/rfc5416>。

Acknowledgements

謝辞

This document benefited considerably from the numerous improvements proposed by Kent Leung.

このドキュメントは、Kent Leungによって提案された多数の改善からかなりの恩恵を受けました。

Authors' Addresses

著者のアドレス

Rajesh S. Pazhyannur Cisco Systems 170 West Tasman Drive San Jose, California 95134 United States EMail: rpazhyan@cisco.com

Rajesh S. Pazhyannur Cisco Systems 170 West Tasman Driveカリフォルニア州サンノゼ95134米国Eメール:rpazhyan@cisco.com

Sebastian Speicher Cisco Systems Richtistrasse 7 Wallisellen, Zurich 8304 Switzerland EMail: sespeich@cisco.com

Sebastian Speicher Cisco Systems Richtistrasse 7 Wallisellen、Zurich 8304 Switzerlandメール:sespeich@cisco.com

Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, California 95134 United States EMail: sgundave@cisco.com

Sri Gundavelli Cisco Systems 170 West Tasman Driveカリフォルニア州サンノゼ95134米国Eメール:sgundave@cisco.com

Jouni Korhonen Broadcom Corporation 3151 Zanker Road San Jose, California 95134 United States EMail: jouni.nospam@gmail.com

Jouni Korhonen Broadcom Corporation 3151 Zanker Roadカリフォルニア州サンノゼ95134アメリカ合衆国Eメール:jouni.nospam@gmail.com

John Kaippallimalil Huawei 5340 Legacy Drive, Suite 175 Plano, Texas 75024 United States EMail: john.kaippallimalil@huawei.com

John Kaippallimalil Huawei 5340 Legacy Drive、Suite 175 Plano、Texas 75024 United Statesメール:john.kaippallimalil@huawei.com