[要約] RFC 8273は、ホストごとに一意のIPv6プレフィックスを割り当てるための手法を提案しています。その目的は、ネットワークのアドレス割り当ての効率性とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. Brzozowski
Request for Comments: 8273 Comcast Cable
Category: Informational G. Van de Velde
ISSN: 2070-1721 Nokia
December 2017
Unique IPv6 Prefix per Host
ホストごとの一意のIPv6プレフィックス
Abstract
概要
This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.
このドキュメントでは、既存のIPv6プロトコルを利用して、ホストに（共有IPv6プレフィックスからの一意のIPv6アドレスの代わりに）一意のIPv6プレフィックスを割り当てることを可能にするアプローチについて説明します。一意のサービスプロバイダーIPv6アドレスで一意のIPv6プレフィックスを使用する利点には、共有ネットワークセグメントでのホスト分離の向上と加入者管理の強化が含まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8273.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8273で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation and Scope of Applicability . . . . . . . . . . . . 3
3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
4. Assignment of IPv6 Unique Prefixes . . . . . . . . . . . . . 4
5. Best Practices for IPv6 Neighbor Discovery . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The concepts in this document were originally developed as part of a large-scale production deployment of IPv6 support for a provider-managed shared-access network service.
このドキュメントの概念は、最初はプロバイダーが管理する共有アクセスネットワークサービスのIPv6サポートの大規模な実稼働展開の一部として開発されました。
A shared-access network service is a service offering in which a particular Layer 2 (L2) access network (e.g., Wi-Fi) is shared and used by multiple visiting devices (i.e., subscribers). Many service providers offering shared-access network services have legal requirements, or find it good practice, to provide isolation between the connected visitor devices to control potential abuse of the shared-access network.
共有アクセスネットワークサービスは、特定のレイヤー2（L2）アクセスネットワーク（Wi-Fiなど）が共有され、複数の訪問先デバイス（つまり、加入者）によって使用されるサービスです。共有アクセスネットワークサービスを提供する多くのサービスプロバイダーは、共有アクセスネットワークの悪用の可能性を制御するために、接続されたビジターデバイスを分離するための法的要件があるか、またはそれが適切であると考えています。
A network implementing a unique IPv6 prefix per host can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as Duplicate Address Detection (DAD) reply spoofing, Neighbor Discovery (ND) cache exhaustion, malicious redirects, and rogue Router Advertisements (RAs). This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.
ホストごとに一意のIPv6プレフィックスを実装するネットワークでは、デバイスがファーストホップルーターを経由しない限り相互にパケットを送信できないようにすることができます。これにより、重複ローカルアドレス検出（DAD）応答のなりすまし、近隣探索（ND）キャッシュの枯渇、悪意のあるリダイレクト、不正なルーターアドバタイズ（RA）など、リンクローカルICMPv6パケットに依存するデバイス間の攻撃に対する堅牢な保護が自動的に提供されます。この形式の保護は、DADプロキシ、強制転送、NDスヌーピングなどの代替メカニズムよりもはるかにスケーラブルで堅牢です。
In this document IPv6 support does not preclude support for IPv4; however, the primary objective for this work was to make it so that user equipment (UE) were capable of an IPv6-only experience from a network operator's perspective. In the context of this document, UE can be 'regular' end-user equipment as well as a server in a data center, assuming a shared network (wired or wireless) exists.
このドキュメントでは、IPv6サポートはIPv4のサポートを排除するものではありません。ただし、この作業の主な目的は、ネットワークオペレーターの観点から、ユーザー機器（UE）がIPv6のみのエクスペリエンスを実現できるようにすることでした。このドキュメントのコンテキストでは、共有ネットワーク（有線または無線）が存在する場合、UEはデータセンター内のサーバーと同様に「通常の」エンドユーザー機器になることができます。
Details of IPv4 support are out of scope for this document. This document will also, in general, outline the requirements that must be satisfied by UE to allow for an IPv6-only experience.
IPv4サポートの詳細は、このドキュメントの範囲外です。このドキュメントでは、一般に、IPv6のみのエクスペリエンスを実現するためにUEが満たさなければならない要件についても概説します。
In most current deployments, assignment of UE IPv6 addresses is commonly done using IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] and/or DHCP IA_NA (Identity Association - Non-temporary Address) [RFC3315]. During the time when this approach was developed and subsequently deployed, it was observed that some operating systems did not support the use of DHCPv6 for the acquisition of IA_NA per [RFC7934]. To not exclude any known IPv6 implementations, IPv6-SLAAC-based subscriber and address management is the recommended technology to reach the highest percentage of connected IPv6 devices on a provider-managed shared-access network service. In addition, an IA_NA-only network is not recommended per Section 8 of [RFC7934]. This document will detail the mechanics involved for IPv6-SLAAC-based address and subscriber management coupled with stateless DHCPv6, where beneficial.
現在のほとんどの展開では、UE IPv6アドレスの割り当ては、一般的にIPv6ステートレスアドレス自動構成（SLAAC）[RFC4862]またはDHCP IA_NA（ID関連付け-非一時アドレス）[RFC3315]を使用して行われます。このアプローチが開発され、その後展開されたとき、一部のオペレーティングシステムは、[RFC7934]によるIA_NAの取得のためのDHCPv6の使用をサポートしていないことが確認されました。既知のIPv6実装を除外しないために、IPv6-SLAACベースのサブスクライバーおよびアドレス管理は、プロバイダーが管理する共有アクセスネットワークサービス上の接続されたIPv6デバイスの最高の割合に到達するための推奨テクノロジーです。さらに、[RFC7934]のセクション8によると、IA_NAのみのネットワークは推奨されません。このドキュメントでは、有益な場合はステートレスDHCPv6と組み合わせたIPv6-SLAACベースのアドレスおよびサブスクライバー管理に関連するメカニズムについて詳しく説明します。
This document focuses upon the process for UE to obtain a unique IPv6 prefix.
このドキュメントでは、UEが一意のIPv6プレフィックスを取得するプロセスに焦点を当てています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The motivation for this work falls into the following categories:
この作業の動機は次のカテゴリに分類されます。
o Give deployment advice for IPv6 that will allow a stable and secure IPv6-only experience, even if IPv4 support is present
o IPv4サポートが存在する場合でも、安定した安全なIPv6のみのエクスペリエンスを可能にするIPv6の導入アドバイスを提供します
o Ensure support for IPv6 is efficient and does not impact the performance of the underlying network and, in turn, the customer experience
o IPv6のサポートが効率的であり、基盤となるネットワークのパフォーマンス、ひいてはカスタマーエクスペリエンスに影響を与えないことを確認する
o Allow for the greatest flexibility across host implementations to allow for the widest range of addressing and configuration mechanisms to be employed. Ensure that the widest population of UE implementations can leverage the availability of IPv6
o ホストの実装全体で最大の柔軟性を実現し、幅広いアドレッシングおよび構成メカニズムを使用できるようにします。 UE実装の最も幅広い集団がIPv6の可用性を活用できるようにする
o Lay the technological foundation for future work related to the use of IPv6 over shared media, requiring optimized subscriber management
o 最適化された加入者管理を必要とする、共有メディア上でのIPv6の使用に関連する将来の作業のための技術的基盤を築く
o Ensure that two devices (subscriber/hosts), both attached to the same provider-managed shared-access network, should only be able to communicate through the provider-managed first-hop router. Often, service providers have legal requirements, or find it good practice, to provide isolation between the connected visitor devices in order to control potential abuse of the shared-access network.
o プロバイダーが管理する共有アクセスネットワークに接続されている2つのデバイス（サブスクライバー/ホスト）が、プロバイダーが管理するファーストホップルーター経由でのみ通信できることを確認します。多くの場合、サービスプロバイダーは、共有アクセスネットワークの悪用の可能性を制御するために、接続されたビジターデバイス間の分離を提供するための法的要件を持っているか、または適切な慣行を見つけています。
o Provide guidelines regarding best common practices around IPv6 ND [RFC4861] and IPv6-address-management settings between the first-hop router and directly connected hosts/subscribers.
o ファーストホップルーターと直接接続されたホスト/サブスクライバー間のIPv6 ND [RFC4861]およびIPv6-address-management設定に関するベストプラクティスに関するガイドラインを提供します。
The first-hop router discussed in this document is the L3 Edge router responsible for the communication with the devices (hosts and subscribers) directly connected to a provider-managed shared-access network; it is also responsible for transporting traffic between the directly connected devices and between directly connected devices and remote devices.
このドキュメントで説明するファーストホップルーターは、プロバイダーが管理する共有アクセスネットワークに直接接続されているデバイス（ホストとサブスクライバー）との通信を担当するL3エッジルーターです。また、直接接続されたデバイス間および直接接続されたデバイスとリモートデバイス間のトラフィックの転送も行います。
The work detailed in this document is focused on providing details regarding best common practices of the IPv6 ND and related IPv6- address-management settings between the first-hop router and directly connected hosts/subscribers. The documented best current practice helps a service provider to better manage the provider-managed shared-access network on behalf of the connected devices.
このドキュメントで詳述されている作業は、IPv6 NDのベストプラクティスと、ファーストホップルーターと直接接続されているホスト/サブスクライバーとの間の関連するIPv6-アドレス管理設定に関する詳細を提供することに焦点を当てています。文書化された現在のベストプラクティスは、サービスプロバイダーが接続デバイスに代わってプロバイダー管理の共有アクセスネットワークをより適切に管理するのに役立ちます。
This document recommends providing a unique IPv6 prefix to devices connected to the provider-managed shared-access network. Each unique IPv6 prefix can function as a control-plane anchor point to make sure that each device receives expected subscriber policy and service levels (throughput, QoS, security, parental control, subscriber-mobility management, etc.).
このドキュメントでは、プロバイダーが管理する共有アクセスネットワークに接続されているデバイスに一意のIPv6プレフィックスを提供することを推奨しています。一意の各IPv6プレフィックスは、コントロールプレーンのアンカーポイントとして機能し、各デバイスが期待されるサブスクライバーポリシーとサービスレベル（スループット、QoS、セキュリティ、ペアレンタルコントロール、サブスクライバーモビリティ管理など）を確実に受信できるようにします。
When a UE connects to the provider-managed shared-access network, it will initiate the IP configuration phase. During this phase, the UE will, from an IPv6 perspective, attempt to learn the default IPv6 gateway, the IPv6 prefix information, the DNS information [RFC8106], and the remaining information required to establish globally routable IPv6 connectivity. For that purpose, the subscriber sends an RS (Router Solicitation) message.
UEがプロバイダー管理の共有アクセスネットワークに接続すると、IP構成フェーズが開始されます。このフェーズでは、UEはIPv6の観点から、デフォルトのIPv6ゲートウェイ、IPv6プレフィックス情報、DNS情報[RFC8106]、およびグローバルにルーティング可能なIPv6接続を確立するために必要な残りの情報を学習しようとします。そのために、サブスクライバーはRS（ルーター要請）メッセージを送信します。
The first-hop router receives this subscriber RS message and starts the process of composing the response to the subscriber-originated RS message. The first-hop router will answer using a solicited RA to the subscriber.
ファーストホップルータはこのサブスクライバRSメッセージを受信し、サブスクライバから発信されたRSメッセージへの応答を作成するプロセスを開始します。最初のホップのルーターは、要請されたRAを使用して加入者に応答します。
When the first-hop router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the unique IPv6 prefix contained in the RA. This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in Sections 6.2.4 and 6.2.6 of [RFC4861]; but, instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the unique IPv6 prefix contained in the RA MUST be used as the link-layer destination [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent (unicast) to the link-local address of the subscriber as detailed in Section 6.2.6 of [RFC4861]; nevertheless, unsolicited RAs are always sent to the all-nodes group.
ファーストホップルーターが要請RA応答を送信するか、定期的に非送信請求RAを送信する場合、RAは、RAに含まれる一意のIPv6プレフィックスが割り当てられている加入者にのみ送信される必要があります。これは、[RFC4861]のセクション6.2.4および6.2.6で説明されているように、要請されたRA応答または要請されていないRAをすべてのノードグループに送信することによって実現されます。ただし、全ノードグループに関連付けられたリンク層マルチキャストアドレスを使用する代わりに、RAに含まれる一意のIPv6プレフィックスが割り当てられているサブスクライバーのリンク層ユニキャストアドレスをリンク層宛先として使用する必要があります[ RFC6085]。または、オプションとして、[RFC4861]のセクション6.2.6に記載されているように、要請されたRA応答をサブスクライバーのリンクローカルアドレスに送信（ユニキャスト）することもできます。それにもかかわらず、非送信請求RAは常にすべてのノードグループに送信されます。
This solicited RA contains two important parameters for the subscriber to consume: a unique IPv6 prefix (currently a /64 prefix) and some flags. The unique IPv6 prefix can be derived from a locally managed pool or aggregate IPv6 block assigned to the first-hop router or from a centrally allocated pool. The flags indicate that the subscriber should use SLAAC and/or DHCPv6 for address assignment; it may indicate whether the autoconfigured address is on/off-link and if 'Other' information (e.g., DNS server address) needs to be requested.
この要請されたRAには、サブスクライバーが使用する2つの重要なパラメーターが含まれています。一意のIPv6プレフィックス（現在は/ 64プレフィックス）といくつかのフラグです。一意のIPv6プレフィックスは、ローカルで管理されているプールまたはファーストホップルーターに割り当てられた集約IPv6ブロック、または中央に割り当てられたプールから派生できます。フラグは、加入者がアドレス割り当てにSLAACやDHCPv6を使用する必要があることを示しています。自動構成されたアドレスがオン/オフリンクであるかどうか、および「その他」の情報（DNSサーバーのアドレスなど）を要求する必要があるかどうかを示します。
The IPv6 RA flags used for best common practice in IPv6-SLAAC-based provider-managed shared-access networks are:
IPv6-SLAACベースのプロバイダー管理の共有アクセスネットワークでのベストプラクティスに使用されるIPv6 RAフラグは次のとおりです。
o M-flag = 0 (The subscriber address is not managed through DHCPv6); this flag may be set to 1 in the future if/when DHCPv6-prefix-delegation support is desired.)
o M-flag = 0（サブスクライバーアドレスはDHCPv6で管理されません）; DHCPv6-prefix-delegationサポートが必要な場合、このフラグは将来1に設定される可能性があります。
o O-flag = 1 (DHCPv6 is used to request configuration information, i.e., DNS, NTP information, not for IPv6 addressing.)
o O-flag = 1（DHCPv6は、IPv6アドレッシングではなく、構成情報、つまりDNS、NTP情報を要求するために使用されます。）
o A-flag = 1 (The subscriber can configure itself using SLAAC.)
o A-flag = 1（サブスクライバーはSLAACを使用して自身を構成できます。）
o L-flag = 0 (The prefix is not an on-link prefix, which means that the subscriber will never assume destination addresses that match the prefix are on-link and will always send packets to those addresses to the appropriate gateway according to route selection rules.)
o L-flag = 0（プレフィックスはオンリンクプレフィックスではありません。つまり、サブスクライバーは、プレフィックスと一致する宛先アドレスがオンリンクであるとは想定せず、ルート選択に従ってそれらのアドレスへのパケットを常に適切なゲートウェイに送信します。ルール）
The use of a unique IPv6 prefix per subscriber adds an additional level of protection and efficiency. The protection exists because all external communication of a connected device is directed to the first-hop router as required by [RFC4861]. Best efficiency is achieved because the recommended RA flags allow the broadest support on connected devices to receive a valid IPv6 address (i.e., privacy addresses [RFC4941] or SLAAC [RFC4862]).
サブスクライバーごとに一意のIPv6プレフィックスを使用すると、保護と効率がさらに高まります。接続されたデバイスのすべての外部通信は、[RFC4861]で要求される最初のホップのルーターに向けられるため、保護が存在します。推奨されるRAフラグにより、接続されたデバイスで最も幅広いサポートが有効なIPv6アドレス（つまり、プライバシーアドレス[RFC4941]またはSLAAC [RFC4862]）を受信できるため、最高の効率が得られます。
The architected result of designing the RA as documented above is that each subscriber gets its own unique IPv6 prefix. Each host can consequently use SLAAC or any other method of choice to select its /128 unique address. Either stateless DHCPv6 [RFC3736] or IPv6 Router Advertisement Options for DNS Configuration [RFC8106] can be used to get the IPv6 address of the DNS server. If the subscriber desires to send anything external, including towards other subscriber devices (assuming device-to-device communications is enabled and supported), then, due to the L-bit being unset, [RFC4861] requires that this traffic be sent to the first-hop router.
上記のようにRAを設計した結果、各サブスクライバーは固有のIPv6プレフィックスを取得します。したがって、各ホストはSLAACまたはその他の任意の方法を使用して、/ 128の一意のアドレスを選択できます。ステートレスDHCPv6 [RFC3736]またはDNS構成のIPv6ルーターアドバタイズメントオプション[RFC8106]を使用して、DNSサーバーのIPv6アドレスを取得できます。サブスクライバーが他のサブスクライバーデバイス（デバイス間の通信が有効でサポートされていると想定）への送信を含め、外部に何かを送信したい場合、Lビットが設定されていないため、[RFC4861]はこのトラフィックをファーストホップルーター。
After the subscriber received the RA and the associated flags, it will assign itself a 128-bit IPv6 address using SLAAC. Since the address is composed by the subscriber device itself, it will need to verify that the address is unique on the shared network. The subscriber will, for that purpose, perform the DAD algorithm. This will occur for each address the UE attempts to utilize on the provider-managed shared-access network.
サブスクライバーはRAおよび関連するフラグを受信した後、SLAACを使用して128ビットのIPv6アドレスを割り当てます。アドレスは加入者デバイス自体によって構成されているため、アドレスが共有ネットワーク上で一意であることを確認する必要があります。そのために、加入者はDADアルゴリズムを実行します。これは、UEがプロバイダー管理の共有アクセスネットワークで利用しようとするアドレスごとに発生します。
An operational consideration when using IPv6-address assignment with IPv6 SLAAC is that after the onboarding procedure, the subscriber will have a prefix with certain preferred and valid lifetimes. The first-hop router extends these lifetimes by sending an unsolicited RA, the applicable MaxRtrAdvInterval on the first-hop router MUST, therefore, be lower than the preferred lifetime. One consequence of this process is that the first-hop router never knows when a subscriber stops using addresses from a prefix, and additional procedures are required to help the first-hop router to gain this information. When using stateful DHCPv6 IA_NA for IPv6-subscriber-address assignment, this uncertainty on the first-hop router does not have an impact due to the stateful nature of the assignment of DHCPv6 IA_NA addresses.
IPv6 SLAACでIPv6-address割り当てを使用する場合の運用上の考慮事項は、オンボーディング手順の後で、サブスクライバーが特定の優先される有効な有効期間を持つプレフィックスを持つことです。ファーストホップルーターは、非送信請求RAを送信することでこれらのライフタイムを延長します。したがって、ファーストホップルーターの該当するMaxRtrAdvIntervalは、推奨ライフタイムよりも短くなければなりません（MUST）。このプロセスの1つの結果は、サブスクライバーがプレフィックスからのアドレスの使用を停止したことをファーストホップルーターが知ることはなく、ファーストホップルーターがこの情報を取得できるようにするには、追加の手順が必要です。 IPv6サブスクライバーアドレスの割り当てにステートフルDHCPv6 IA_NAを使用する場合、DHCPv6 IA_NAアドレスの割り当てのステートフルな性質により、ファーストホップルーターのこの不確実性は影響しません。
The following is a reference table of the key IPv6 router and neighbor discovery timers for provider-managed shared-access networks:
以下は、プロバイダーが管理する共有アクセスネットワークの主要なIPv6ルーターと近隣探索タイマーの参照表です。
o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 300 s (or when battery consumption is a concern 686 s, see note below)
o 最大IPv6ルーターアドバタイズメントインターバル（MaxRtrAdvInterval）= 300秒（またはバッテリー消費が懸念される場合は686秒、以下の注を参照）
o IPv6 Router Lifetime = 3600 s (see note below)
o IPv6ルーターの寿命= 3600秒（下記の注を参照）
o Reachable time = 30 s
o 到達可能時間= 30秒
o IPv6 Valid Lifetime = 3600 s
o IPv6の有効期間= 3600秒
o IPv6 Preferred Lifetime = 1800 s
o IPv6推奨ライフタイム= 1800秒
o Retransmit timer = 0 s
o 再送信タイマー= 0秒
Note: When servicing large numbers of battery powered devices, [RFC7772] suggests a maximum of seven RAs per hour and a 45-90 minute IPv6 Router Lifetime. To achieve a maximum of seven RAs per hour, the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is the important parameter, and it MUST be greater than or equal to 514 seconds (1/7 of an hour). Further, as discussed in Section 6.2.1. of [RFC4861], MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval; therefore, MaxRtrAdvInterval MUST additionally be greater than or equal to 686 seconds. As for the recommended IPv6 Router Lifetime, since this technique requires that RAs be sent using the link-layer unicast address of the subscriber, the concerns over multicast delivery discussed in [RFC7772] are already mitigated; therefore, the above suggestion of 3600 seconds (an hour) seems sufficient for this use case.
注：多数の電池式デバイスを保守する場合、[RFC7772]は1時間あたり最大7つのRAと45〜90分のIPv6ルーターライフタイムを提案しています。 1時間あたり最大7つのRAを達成するには、最小IPv6ルーターアドバタイズメントインターバル（MinRtrAdvInterval）が重要なパラメーターであり、514秒（1時間の1/7）以上である必要があります。さらに、セクション6.2.1で説明されています。 [RFC4861]、MinRtrAdvInterval <= 0.75 * MaxRtrAdvInterval;したがって、MaxRtrAdvIntervalはさらに686秒以上である必要があります。推奨されるIPv6ルーターの寿命については、この手法ではサブスクライバーのリンク層ユニキャストアドレスを使用してRAを送信する必要があるため、[RFC7772]で説明されているマルチキャスト配信に関する懸念は既に緩和されています。したがって、この使用例では、上記の3600秒（1時間）の提案で十分です。
IPv6 SLAAC requires the router to maintain neighbor state, which implies costs in terms of memory, power, message exchanges, and message processing. Stale entries can prove an unnecessary burden, especially on Wi-Fi interfaces. It is RECOMMENDED that stale neighbor state be removed quickly.
IPv6 SLAACでは、ルーターがネイバー状態を維持する必要があります。これは、メモリ、電力、メッセージ交換、およびメッセージ処理の点でコストを意味します。古くなったエントリは、特にWi-Fiインターフェースで、不必要な負担になる可能性があります。古いネイバー状態をすばやく削除することをお勧めします。
When employing stateless IPv6 address assignment, a number of widely deployed operating systems will attempt to utilize [RFC4941] temporary 'private' addresses.
ステートレスIPv6アドレス割り当てを採用する場合、広く展開されている多くのオペレーティングシステムが[RFC4941]の一時的な「プライベート」アドレスを利用しようとします。
Similarly, when using this technology in a data center, the UE server may need to use several addresses from the same unique IPv6 prefix, for example, because is using multiple virtual hosts, containers, etc., in the bridged-virtual switch. This can lead to the consequence that a UE has multiple /128 addresses from the same IPv6 prefix. The first-hop router MUST be able to handle the presence and use of multiple globally routable IPv6 addresses.
同様に、データセンターでこのテクノロジーを使用する場合、たとえば、ブリッジ仮想スイッチで複数の仮想ホスト、コンテナーなどを使用しているため、UEサーバーは同じ一意のIPv6プレフィックスからいくつかのアドレスを使用する必要がある場合があります。これは、UEが同じIPv6プレフィックスからの複数の/ 128アドレスを持つという結果につながる可能性があります。ファーストホップルーターは、グローバルにルーティング可能な複数のIPv6アドレスの存在と使用を処理できなければなりません（MUST）。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
The mechanics of IPv6 privacy extensions [RFC4941] are compatible with assignment of a unique IPv6 prefix per host. However, when combining both IPv6 privacy extensions and a unique IPv6 prefix per host, a reduced privacy experience for the subscriber is introduced. This is because a prefix may be associated with a subscriber, even when the subscriber has implemented IPv6 privacy extensions [RFC4941]. If the operator assigns the same unique prefix to the same link-layer address every time a host connects, any remote party who is aware of this fact can easily track a host simply by tracking its assigned prefix. This nullifies the benefit provided by privacy addresses [RFC4941]. If a host wishes to maintain privacy on such networks, it SHOULD ensure that its link-layer address is periodically changed or randomized.
IPv6プライバシー拡張[RFC4941]の仕組みは、ホストごとに一意のIPv6プレフィックスを割り当てることと互換性があります。ただし、IPv6プライバシー拡張とホストごとの一意のIPv6プレフィックスの両方を組み合わせると、サブスクライバーのプライバシーエクスペリエンスが低下します。これは、サブスクライバーがIPv6プライバシー拡張[RFC4941]を実装している場合でも、プレフィックスがサブスクライバーに関連付けられる可能性があるためです。オペレーターがホストに接続するたびに同じリンク層アドレスに同じ一意のプレフィックスを割り当てると、この事実を知っているリモートパーティは、割り当てられたプレフィックスを追跡するだけで簡単にホストを追跡できます。これはプライバシーアドレス[RFC4941]によって提供される利点を無効にします。ホストがそのようなネットワーク上でプライバシーを維持したい場合は、そのリンク層アドレスが定期的に変更またはランダム化されるようにする必要があります。
No other additional security considerations are made in this document.
このドキュメントでは、その他のセキュリティに関する考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC3736] Droms、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、DOI 10.17487 / RFC3736、2004年4月、<https://www.rfc-editor.org/info/rfc3736> 。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, DOI 10.17487/RFC6085, January 2011, <https://www.rfc-editor.org/info/rfc6085>.
[RFC6085] Gundavelli、S.、Townsley、M.、Troan、O。、およびW. Dec、「イーサネット上のIPv6マルチキャストパケットのアドレスマッピング」、RFC 6085、DOI 10.17487 / RFC6085、2011年1月、<https：// www.rfc-editor.org/info/rfc6085>。
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772] Yourtchenko、A。およびL. Colitti、「ルーターアドバタイズメントのエネルギー消費の削減」、BCP 202、RFC 7772、DOI 10.17487 / RFC7772、2016年2月、<https://www.rfc-editor.org/info/ rfc7772>。
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.
[RFC7934] Colitti、L.、Cerf、V.、Cheshire、S。、およびD. Schinazi、「Host Address Availability Recommendations」、BCP 204、RFC 7934、DOI 10.17487 / RFC7934、2016年7月、<https：// www .rfc-editor.org / info / rfc7934>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<https：// www .rfc-editor.org / info / rfc8106>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
Acknowledgements
謝辞
The authors would like to explicitly thank David Farmer and Lorenzo Colitti for their extended contributions and suggested text.
著者は、David FarmerとLorenzo Colittiの貢献とテキストの提案に深く感謝します。
In addition, the authors would like to thank the following, in alphabetical order, for their contributions:
さらに、執筆者は、貢献に対して以下をアルファベット順に感謝します。
Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Killian Desmedt, Wim Henderickx, Brad Hilgenfeld, Erik Kline, Suresh Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, and Sanjay Wadhwa
フレッドベイカー、ベンキャンベル、ブライアンカーペンター、ティムチョン、キリアンデスメット、ウィムヘンデリックス、ブラッドヒルゲンフェルド、エリッククライン、スレッシュクリシュナン、ウォーレンクマリ、トーマスリン、ジョルディパレット、フィルサンダーソン、コリーンシマニック、ジンメイタトゥヤ、エリックヴィンケ、サンジャイワダワ
Authors' Addresses
著者のアドレス
John Jason Brzozowski Comcast Cable 1701 John F. Kennedy Blvd. Philadelphia, PA United States of America
ジョンジェイソンブロゾフスキーコムキャストケーブル1701ジョンF.ケネディブルバード。フィラデルフィア、ペンシルバニア州アメリカ合衆国
Email: john_brzozowski@cable.comcast.com
Gunter Van de Velde Nokia Antwerp Belgium
Gunter Van de Velde Nokia Antwerpベルギー
Email: gunter.van_de_velde@nokia.com