[要約] RFC 8978は、IPv6のステートレスアドレス自動設定(SLAAC)がフラッシュ再番号付けイベントにどのように反応するかを定義します。この文書の目的は、ネットワークが急速に再番号付けされた際に、デバイスが効率的に新しいアドレスを取得し、古いアドレスを廃棄する方法を提供することです。主に、動的なネットワーク環境や、IPアドレスの変更が頻繁に発生する可能性があるシナリオで利用されます。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 8978 SI6 Networks
Category: Informational J. Žorž
ISSN: 2070-1721 6connect
R. Patterson
Sky UK
March 2021
Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events
IPv6ステートレスアドレス自動設定（SLAAC）のFlash-Nerdumberingイベントの反応
Abstract
概要
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed.
その条件の明示的で信頼できるシグナリングなしにIPv6プレフィックスに関するネットワーク構成情報が無効になるシナリオでは、（カスタマーエッジルータが以前に採用されているプレフィックスの知識なしにクラッシュして再起動するときなど）、ローカルネットワーク上のホストは古くなっています。許容できないほど長い時間（数日程度の）の接頭辞をして、接続の問題が発生します。この文書ではこの問題について説明し、ネットワークの堅牢性を改善するのに役立つ可能性がある運用上の回避策について説明します。さらに、さらに作業が必要な領域を強調表示します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc8978.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8978で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Analysis of the Problem
2.1. Use of Dynamic Prefixes
2.2. Default PIO Lifetime Values in IPv6 Stateless Address
Autoconfiguration (SLAAC)
2.3. Recovering from Stale Network Configuration Information
2.4. Lack of Explicit Signaling about Stale Information
2.5. Interaction between DHCPv6-PD and SLAAC
3. Operational Mitigations
3.1. Stable Prefixes
3.2. SLAAC Parameter Tweaking
4. Future Work
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] conveys information about prefixes to be employed for address configuration via Prefix Information Options (PIOs) sent in Router Advertisement (RA) messages. IPv6 largely assumes prefix stability, with network renumbering only taking place in a planned manner: old prefixes are deprecated (and eventually invalidated) via reduced prefix lifetimes and new prefixes are introduced (with longer lifetimes) at the same time. However, there are several scenarios that may lead to the so-called "flash-renumbering" events, where a prefix employed by a network suddenly becomes invalid and replaced by a new prefix. In some of these scenarios, the local router producing the network renumbering event may try to deprecate (and eventually invalidate) the currently employed prefix (by explicitly signaling the network about the renumbering event), whereas in other scenarios, it may be unable to do so.
IPv6ステートレスアドレスAutoConfiguration（SLAAC）[RFC4862]は、ルータ広告（RA）メッセージで送信されたプレフィックス情報オプション（PIO）を介して、アドレス設定に採用されるプレフィックスに関する情報を伝えます。IPv6はプレフィックスの安定性を大きくし、ネットワークの変更は計画的な方法でのみ行われます。古いプレフィックスは、プレフィックスの寿命を減らして（そして最終的に無効化されています）、同時に新しいプレフィックスが導入されます（寿命が長い）。ただし、ネットワークによって採用されているプレフィックスが突然無効になり、新しいプレフィックスに置き換えられた、いわゆる「フラッシュ番号」イベントにつながる可能性があるいくつかのシナリオがあります。これらのシナリオのいくつかでは、ネットワーク番号の変更イベントを生成するローカルルータは、現在採用されているプレフィックスを非推奨（そして最終的に無効にする）を試みることができます（そして、その番号なしイベントに関するネットワークを明示的にシグナリングすることによって）、他のシナリオではできない可能性があります。そう。
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition, hosts on the local network may continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems.
その条件の明示的で信頼できるシグナリングなしにIPv6プレフィックスに関連するネットワーク構成情報が無効になるシナリオでは、ローカルネットワーク上のホストは不適切な長期間にわたって古いプレフィックスを使用し続けることができ、したがって接続の問題が発生する可能性があります。
Scenarios where this problem may arise include, but are not limited to, the following:
この問題が発生する可能性があるシナリオには、以下のものが含まれますが、これらに限定されません。
* The most common IPv6 deployment scenario for residential or small office networks, where a Customer Edge (CE) router employs DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service Provider (ISP), and a sub-prefix of the leased prefix is advertised on the LAN side of the CE router via Stateless Address Autoconfiguration (SLAAC) [RFC4862]. In scenarios where the CE router crashes and reboots, the CE router may obtain (via DHCPv6-PD) a different prefix from the one previously leased and therefore advertise (via SLAAC) a new sub-prefix on the LAN side. Hosts will typically configure addresses for the new sub-prefix but will also normally retain and may actively employ the addresses configured for the previously advertised sub-prefix, since their associated Preferred Lifetime and Valid Lifetime allow them to do so.
* Customer Edge（CE）ルータがDHCPv6プレフィックス委任（DHCPv6-PD）を採用（DHCPv6-PD）[RFC8415]を採用し、インターネットサービスプロバイダ（ISP）、およびサブの要求を要求するための最も一般的なIPv6展開シナリオ。リースプレフィックスの接頭辞は、ステートレスアドレス自動設定（SLAAC）[RFC4862]を介してCEルータのLAN側で宣伝されています。CEルータがクラッシュして再起動するシナリオでは、CEルータは（DHCPv6-PDを介して）以前にリーティに異なるプレフィックスを取得することができ、したがって（SLAACを介して）LAN側の新しいサブプレフィックスを宣伝することができます。ホストは通常、新しいサブプレフィックスのアドレスを設定しますが、それに関連する優先寿命と有効な有効期間がそうすることができるため、通常、前回アドバタイズされたサブプレフィックス用に設定されているアドレスを積極的に使用できます。
* A router (e.g., Customer Edge router) advertises autoconfiguration prefixes (corresponding to prefixes learned via DHCPv6-PD) with constant PIO lifetimes that are not synchronized with the DHCPv6-PD lease time (even though Section 6.3 of [RFC8415] requires such synchronization). While this behavior violates the aforementioned requirement from [RFC8415], it is not an unusual behavior. For example, this is particularly true for implementations in which DHCPv6-PD is implemented in a different software module than SLAAC.
* ルータ（Customer Edge Router）は、DHCPv6-PDリース時間と同期されていない一定のPIOライフタイムで（DHCPv6-PDを介したプレフィックスに対応）をアドバタイズします（RFC8415のセクション6.3であっても、DHCPv6-PDを介したプレフィックスに対応）。。この行動は[RFC8415]から前述の要件に違反していますが、それは異常な行動ではありません。たとえば、これは、DHCPv6-PDがSLAACとは異なるソフトウェアモジュールで実装されている実装に特に当てはまります。
* A switch-port that a host is connected to is moved to another subnet (VLAN) as a result of manual switch-port reconfiguration or 802.1x reauthentication. There has been evidence that some 802.1x supplicants do not reset network settings after successful 802.1x authentication. If a host fails 802.1x authentication for some reason, it may be placed in a "quarantine" VLAN; if successfully authenticated later on, the host may end up having IPv6 addresses from both the old ("quarantine") and new VLANs.
* ホストが接続されているスイッチポートは、手動スイッチポートの再構成または802.1X再認証の結果として別のサブネット（VLAN）に移動します。802.1x認証が成功した後に、802.1倍のサプリカントがネットワーク設定をリセットしないという証拠がありました。何らかの理由でホストが802.1X認証に失敗した場合は、「検疫」VLANに配置できます。後で認証に成功した場合、ホストは古い（「検疫」）と新しいVLANの両方からIPv6アドレスを持つことになることがあります。
* During a planned network renumbering event, a router is configured to send an RA including a Prefix Information Option (PIO) for the "old" prefix with the Preferred Lifetime set to zero and the Valid Lifetime set to a small value, as well as a PIO for the new prefix with default lifetimes. However, due to unsolicited RAs being sent to a multicast destination address, and multicast being rather unreliable on busy Wi-Fi networks, the RA might not be received by local hosts.
* 計画されたネットワークの番号変更イベントの間、ルータは、ゼロに設定された「古い」プレフィックスのプレフィックス情報オプション（PIO）を含むRAを、ゼロに設定され、有効な有効期間、および小さい値に設定されているRAを送信するように設定されています。デフォルトの寿命を持つ新しいプレフィックスのPIO。ただし、迷惑メールがマルチキャスト宛先アドレスに送信され、マルチキャストがビジーWi-Fiネットワーク上でかなり信頼できないため、RAはローカルホストによって受信されない可能性があります。
* An automated device config management system performs periodic config pushes to network devices. In these scenarios, network devices may simply immediately forget their previous configuration, rather than withdraw it gracefully. If such a push results in changing the prefix configured on a particular subnet, hosts attached to that subnet might not get notified about the prefix change, and their addresses from the "old" prefix might not be deprecated (and eventually invalidated) in a timely manner. A related scenario is an incorrect network renumbering event, where a network administrator renumbers a network by simply removing the "old" prefix from the configuration and configuring a new prefix instead.
* 自動デバイス構成管理システムは、ネットワークデバイスに定期的な設定プッシュを実行します。これらのシナリオでは、ネットワークデバイスはそれを正常に撤回するのではなく、直ちにそれらの以前の設定を忘れることができます。そのようなプッシュが特定のサブネット上に設定されているプレフィックスの変更になると、そのサブネットに添付されているホストがプレフィックスの変更について通知されず、「古い」プレフィックスからのアドレスは推奨されない（そして最終的には無効化されています）。マナー関連するシナリオは、コンフィギュレーションから「古い」プレフィックスを削除し、代わりに新しいプレフィックスを構成するだけで、ネットワーク管理者がネットワークを変更している間違ったネットワーク番号の変更イベントです。
Lacking any explicit and reliable signaling to deprecate (and eventually invalidate) the stale prefixes, hosts may continue to employ the previously configured addresses, which will typically result in packets being filtered or blackholed either on the CE router or within the ISP network.
古くて信頼できるシグナリングを解除する（そして最終的に無効にする）古いプレフィックスを解決すると、ホストは以前に設定されたアドレスを使用し続けることができます。これにより、通常、CEルータ上またはISPネットワーク内でフィルタリングされるか、またはBlownoledがフィルタリングされる
The default values for the Preferred Lifetime and Valid Lifetime of PIOs specified in [RFC4861] mean that, in the aforementioned scenarios, the stale addresses would be retained and could be actively employed for new communication instances for an unacceptably long period of time (one month and one week, respectively). This could lead to interoperability problems, instead of hosts transitioning to the newly advertised prefix(es) in a more timely manner.
[RFC4861]で指定されているPIOの優先寿命と有効な有効期間のデフォルト値は、前述のシナリオでは、古いアドレスが保持され、許容できないほど長期間の新しい通信インスタンスに積極的に採用される可能性があることを意味します（1か月そしてそれぞれ1週間）。これにより、新しくアドバタイズされたプレフィックス（ES）に遷移しているホストの代わりに、相互運用性の問題が発生する可能性があります。
Some devices have implemented ad hoc mechanisms to address this problem, such as sending RAs to deprecate (and eventually invalidate) apparently stale prefixes when the device receives any packets employing a source address from a prefix not currently advertised for address configuration on the local network [FRITZ]. However, this may introduce other interoperability problems, particularly in multihomed/multi-prefix scenarios. This is a clear indication that advice in this area is warranted.
デバイスが現在ローカルネットワーク上のアドレス設定のためにアドレス設定を宣伝していないプレフィックスからソースアドレスを採用した場合のRASの送信（および最終的には無効化）のプレフィックスを表示するなど、この問題に対処するためのアドホックメカニズムを実装しました。フリッツ]。ただし、これは、特にマルチホーム/マルチプレフィックスシナリオで、他の相互運用性の問題を導入する可能性があります。これは、この分野のアドバイスが保証されることを明確に示しています。
Unresponsiveness to these flash-renumbering events is caused by the inability of the network to deprecate (and eventually invalidate) stale information as well as by the inability of hosts to react to network configuration changes in a more timely manner. Clearly, it would be desirable that these flash-renumbering events do not occur and that, when they do occur, hosts are explicitly and reliably notified of their occurrence. However, for robustness reasons, it is paramount for hosts to be able to recover from stale configuration information even when these flash-renumbering events occur and the network is unable to explicitly and reliably notify hosts about such conditions.
これらのFlash-Nerdumberingイベントへの応答性は、ネットワークが廃止されたことが（そして最終的に無効にする）古い情報と、ホストがネットワーク構成の変更に反応することによって、よりタイムリーにネットワーク構成変更に反応することによって引き起こされます。明らかに、これらのフラッシュ番号が発生していないことが望ましくなく、それらが発生したときに、ホストは明示的にそして確実にそれらの出現を通知することが望ましいであろう。ただし、堅牢性の理由から、これらのフラッシュ番号付けイベントが発生している場合でも、ホストが古い設定情報から回復できるようになり、ネットワークがそのような条件についてのホストに明示的かつ確実に通知できないことは最優先事項です。
Section 2 analyzes this problem in more detail. Section 3 describes possible operational mitigations. Section 4 describes possible future work to mitigate the aforementioned problem.
セクション2はこの問題をより詳細に分析します。セクション3は可能な操作上の軽減を説明しています。第4節では、前述の問題を軽減するための将来の可能な作業が説明されている。
As noted in Section 1, the problem discussed in this document is exacerbated by the default values of some protocol parameters and other factors. The following sections analyze each of them in detail.
セクション1に記載されているように、この文書で説明した問題は、いくつかのプロトコルパラメータおよびその他の要因のデフォルト値によって悪化されています。以下のセクションで、それらのそれぞれを詳細に分析します。
In network scenarios where dynamic prefixes are employed, renumbering events lead to updated network configuration information being propagated through the network, such that the renumbering events are gracefully handled. However, if the renumbering event happens along with, e.g., loss of configuration state by some of the devices involved in the renumbering procedure (e.g., a router crashes, reboots, and gets leased a new prefix), this may result in a flash-renumbering event, where new prefixes are introduced without properly phasing out the old ones.
動的プレフィックスが採用されているネットワークシナリオでは、イベントを参照すると、暗号化イベントが適切に処理されるように、ネットワークを伝播する更新されたネットワーク構成情報がリードされます。ただし、変更されたイベントが変更された場合など、参照状態の喪失（ルータがクラッシュし、再起動し、新しいプレフィックスを再起動し、リースされている）とともに発生した場合、フラッシュになる可能性があります。新しいプレフィックスが正しく整列させずに新しいプレフィックスが導入されたイベントの番号変更。
In simple residential or small office scenarios, the problem discussed in this document would be avoided if DHCPv6-PD leased "stable" prefixes. However, a recent survey [UK-NOF] indicates that 37% of the responding ISPs employ dynamic IPv6 prefixes. That is, dynamic IPv6 prefixes are an operational reality.
単純な住宅または小規模オフィスのシナリオでは、DHCPv6-PDが「安定した」プレフィックスを除いて、この文書で説明した問題は回避されます。ただし、最近の調査[UK-NOF]は、対応ISPの37％が動的IPv6プレフィックスを採用していることを示しています。つまり、動的IPv6プレフィックスは運用現実です。
Deployment reality aside, there are a number of possible issues associated with stable prefixes:
展開現実の脇には、安定したプレフィックスに関連する多くの可能な問題があります。
* Provisioning systems may be unable to deliver stable IPv6 prefixes.
* プロビジョニングシステムは、安定したIPv6プレフィックスを配信できない可能性があります。
* While an ISP might lease stable prefixes to the home or small office, the Customer Edge router might in turn lease sub-prefixes of these prefixes to other internal network devices. Unless the associated lease databases are stored on non-volatile memory, these internal devices might get leased dynamic sub-prefixes of the stable prefix leased by the ISP. In other words, every time a prefix is leased, there is the potential for the resulting prefixes to become dynamic, even if the device leasing sub-prefixes has been leased a stable prefix by its upstream router.
* ISPがホームまたはスモールオフィスに安定した接頭辞をリースしている可能性があるが、カスタマーエッジルータはこれらの接頭辞のサブプレフィックスを他の内部ネットワークデバイスにリースしている可能性があります。関連するリースデータベースが不揮発性メモリに格納されていない限り、これらの内部デバイスは、ISPによってリースされた安定したプレフィックスのリースされた動的サブプレフィックスを得ることがあります。つまり、プレフィックスがリースされるたびに、デバイスリースサブプレフィックスがそのアップストリームルータによって安定したプレフィックスをリストされていても、結果のプレフィックスが動的になる可能性があります。
* While there is a range of information that may be employed to correlate network activity [RFC7721], the use of stable prefixes clearly simplifies network activity correlation and may reduce the effectiveness of "temporary addresses" [RFC8981].
* ネットワーク活動[RFC7721]を相関させるために採用され得る情報の範囲があるが、安定したプレフィックスの使用はネットワーク活動相関を明確に単純化し、「一時アドレス」[RFC8981]の有効性を低下させる可能性がある。
* There might be existing advice for ISPs to deliver dynamic IPv6 prefixes *by default* (e.g., see [GERMAN-DP]) over privacy concerns associated with stable prefixes.
* 安定したプレフィックスに関連したプライバシーに関する懸念を超えて、Dynamic IPv6プレフィックス*をデフォルト*（例えば、ドイツ語 - DP]参照）で既存のアドバイスがあるかもしれません。
* There might be scalability and performance drawbacks of either a disaggregated distributed routing topology or a centralized topology, which are often required to provide stable prefixes, i.e., distributing more-specific routes or summarizing routes at centralized locations.
* 分離された分散ルーティングトポロジまたは集中型トポロジのいずれかのスケーラビリティと性能上の欠点がある可能性があります。これは、安定したプレフィックスを提供すること、すなわちより特定のルートを配信すること、または集中化された場所での経路をまとめるために必要とされる。
For a number of reasons (such as the ones stated above), IPv6 deployments might employ dynamic prefixes (even at the expense of the issues discussed in this document), and there might be scenarios in which the dynamics of a network are such that the network exhibits the behavior of dynamic prefixes. Rather than trying to regulate how operators may run their networks, this document aims at improving network robustness in the deployed Internet.
多くの理由（上記のものなど）の場合、IPv6展開は動的プレフィックスを使用することがあります（この文書で説明した問題を犠牲にしても）、ネットワークのダイナミクスがそのようなシナリオがあるかもしれません。ネットワークは動的プレフィックスの動作を示します。オペレータがネットワークを実行する方法を調整しようとするのではなく、この文書はデプロイされたインターネットのネットワークの堅牢性の向上を目的としています。
2.2. Default PIO Lifetime Values in IPv6 Stateless Address Autoconfiguration (SLAAC)
2.2. IPv6ステートレスアドレス自動設定（SLAAC）のデフォルトのPIOライフタイム値
The impact of the issue discussed in this document is a function of the lifetime values employed for PIOs, since these values determine for how long the corresponding addresses will be preferred and considered valid. Thus, when the problem discussed in this document is experienced, the longer the PIO lifetimes, the higher the impact.
この文書で説明されている問題の影響は、これらの値が対応するアドレスがどのくらい優先され、有効であるかを決定するので、PIOSに使用される有効期間の値の関数です。したがって、この文書で説明した問題が経験された場合、PIOの寿命が長くなるほど、影響が大きい。
[RFC4861] specifies the following default PIO lifetime values:
[RFC4861]次のデフォルトのPIOライフタイム値を指定します。
* Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
* 好ましい寿命（AdvPreferredLifetime）：604800秒（7日）
* Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
* 有効な有効期間（AdvValidLifetime）：2592000秒（30日）
Under problematic circumstances, such as when the corresponding network information has become stale without any explicit and reliable signal from the network (as described in Section 1), it could take hosts up to 7 days (one week) to deprecate the corresponding addresses and up to 30 days (one month) to eventually invalidate and remove any addresses configured for the stale prefix. This means that it will typically take hosts an unacceptably long period of time (on the order of several days) to recover from these scenarios.
（セクション1で説明されているように）ネットワークからの明示的で信頼できる信号がない場合など、対応するネットワーク情報が古くなっている場合など、問題のある状況下では、対応するアドレスを廃止するために最大7日間（1週間）のホストを取ることができます。最終的に無効になって、古いプレフィックスに設定されたアドレスを削除するために30日（1か月）。これは、通常、これらのシナリオから回復するためにそれが通常、許容できないほど長期間（数日のオーダーで）ホストになることを意味します。
SLAAC hosts are unable to recover from stale network configuration information, since:
SLAACホストは、以来、Staleネットワーク構成情報から回復できません。
* In scenarios where SLAAC routers explicitly signal the renumbering event, hosts will typically deprecate, but not invalidate, the stale addresses, since item "e)" of Section 5.5.3 of [RFC4862] specifies that an unauthenticated RA may never reduce the valid lifetime of an address to less than two hours. Communication with the new "users" of the stale prefix will not be possible, since the stale prefix will still be considered "on-link" by the local hosts.
* SLAACルータがその番号変更イベントを明示的に信号を表示するシナリオでは、[RFC4862]のセクション5.5.3のセクション5.5.3の項目「E）」は、認証されていないRAが有効な有効なRAが決して減少しないことを指定しています。アドレスの2時間未満古くなったプレフィックスの新しい「ユーザー」との通信は、ローカルホストによって古い接頭辞が「オンリンク」と見なされるため、不可能になりません。
* In the absence of explicit signaling from SLAAC routers, SLAAC hosts will typically fail to recover from stale configuration information in a timely manner, since hosts would need to rely on the last Preferred Lifetime and Valid Lifetime advertised for the stale prefix, for the corresponding addresses to become deprecated and subsequently invalidated. Please see Section 2.2 of this document for a discussion of the default PIO lifetime values.
* SLAACルータからの明示的なシグナリングがない場合、SLAACホストは通常、ホストが最後に優先されたLifeTimeと有効な有効期間に依存する必要があるため、対応するアドレスについては、ホストがタイムリーな方法で回復できません。非推奨になり、その後無効化されています。デフォルトのPIO Lifetime値の説明については、このドキュメントの2.2項を参照してください。
Whenever prefix information has changed, a SLAAC router should advertise not only the new information but also the stale information with appropriate lifetime values (both the Preferred Lifetime and the Valid Lifetime set to 0). This would provide explicit signaling to SLAAC hosts to remove the stale information (including configured addresses and routes). However, in certain scenarios, such as when a CE router crashes and reboots, the CE router may have no knowledge about the previously advertised prefixes and thus might be unable to advertise them with appropriate lifetimes (in order to deprecate and eventually invalidate them).
プレフィックス情報が変更されたときはいつでも、SLAACルーターは新しい情報だけでなく、適切な寿命値（優先寿命と有効な有効期間の両方が0に設定されている）を持つ古い情報もアドバタイズする必要があります。これにより、SLAACホストへの明示的なシグナリング（設定されたアドレスとルートを含む）を削除することができます。ただし、CEルータがクラッシュして再起動したときなど、特定のシナリオでは、以前にアドバタイズされたプレフィックスに関する知識がない可能性があります。
In any case, we note that, as discussed in Section 2.3, PIOs with small Valid Lifetimes in unauthenticated RAs will not lower the Valid Lifetime to any value shorter than two hours (as per [RFC4862]). Therefore, even if a SLAAC router tried to explicitly signal the network about the stale configuration information via unauthenticated RAs, implementations compliant with [RFC4862] would deprecate the corresponding prefixes but would fail to invalidate them.
いずれにせよ、セクション2.3で説明したように、認証されていないRASの有効な寿命が小さいPIOは、（RFC4862のように）2時間より短い値に有効な寿命を下げないことに注意してください。したがって、SLAACルーターが未認証RASを介して古い設定情報に関するネットワークを明示的に信号を明示しようとしたとしても、[RFC4862]に準拠した実装は対応する接頭辞を廃止するが、それらを無効にすることに失敗する。
| NOTE:
|
| Some implementations have been updated to honor small PIO
| lifetimes values, as proposed in [RENUM-RXN]. For example,
| please see [Linux-update].
While DHCPv6-PD is normally employed along with SLAAC, the interaction between the two protocols is largely unspecified. Not unusually, the two protocols are implemented in two different software components, with the interface between the two implemented by means of some sort of script that feeds the SLAAC implementation with values learned from DHCPv6-PD.
DHCPV6-PDは通常SLAACと一緒に採用されているが、2つのプロトコル間の相互作用は大きく不特定である。異常ではなく、2つのプロトコルは2つの異なるソフトウェアコンポーネントで実装され、2つのインタフェースは、SLAAC実装をDHCPv6-PDから学習された値でSLAACの実装をフィードしています。
At times, the prefix lease time is fed as a constant value to the SLAAC router implementation, meaning that, eventually, the prefix lifetimes advertised on the LAN side will span *past* the DHCPv6-PD lease time. This is clearly incorrect, since the SLAAC router implementation would be allowing the use of such prefixes for a period of time that is longer than the one they have been leased for via DHCPv6-PD.
時には、プレフィックスのリース時間はSLAACルータの実装に一定値としてフィードされています。つまり、最終的には、LAN側で広告されているプレフィックスの寿命は*過去* DHCPV6-PDリース時間に及ぶことを意味します。SLAACルータの実装は、DHCPv6-PDのためにリースされている期間より長い期間のようなプレフィックスの使用を可能にするので、これは明らかに正しくありません。
The following subsections discuss possible operational workarounds for the aforementioned problems.
次のサブセクションでは、前述の問題についての可能な操作上の回避策について説明します。
As noted in Section 2.1, the use of stable prefixes would eliminate the issue in *some* of the scenarios discussed in Section 1 of this document, such as the typical home network deployment. However, as noted in Section 2.1, there might be reasons for which an administrator may want or may need to employ dynamic prefixes.
セクション2.1に記載されているように、安定したプレフィックスの使用は、一般的なホームネットワーク展開など、このドキュメントのセクション1で説明されているシナリオの*いくつかの*の問題を排除するでしょう。ただし、セクション2.1に記載されているように、管理者が望むか、動的プレフィックスを使用する必要がある理由があるかもしれません。
An operator may wish to override some SLAAC parameters such that, under normal circumstances, the associated timers will be refreshed/ reset, but in the presence of network faults (such as the one discussed in this document), the associated timers go off and trigger some fault recovering action (e.g., deprecate and eventually invalidate stale addresses).
オペレータは、通常の状況下では、関連付けられているタイマーがリフレッシュ/リセットされるように、いくつかのSLAACパラメータを上書きしたい場合がありますが、ネットワーク障害が発生します（このドキュメントで説明しているものなど）、関連付けられているタイマーが消去され、トリガーが発生します。いくつかの障害回復アクション（たとえば、廃止され、最終的には古いアドレスを無効にします）。
The following router configuration variables from [RFC4861] (corresponding to the "lifetime" parameters of PIOs) could be overridden as follows:
[RFC4861]からの次のルータ構成変数（PIOのライフタイムパラメータに対応）は、次のように上書きされる可能性があります。
* AdvPreferredLifetime: 2700 seconds (45 minutes)
* ADVPREFERREDLIFETIME：2700秒（45分）
* AdvValidLifetime: 5400 seconds (90 minutes)
* ADVVALIDLIFETIME：5400秒（90分）
| NOTES:
|
| The aforementioned values for AdvPreferredLifetime and
| AdvValidLifetime are expected to be appropriate for most
| networks. In some networks, particularly those where the
| operator has complete control of prefix allocation and where
| hosts on the network may spend long periods of time sleeping
| (e.g., sensors with limited battery), longer values may be
| appropriate.
|
| A CE router advertising a sub-prefix of a prefix leased via
| DHCPv6-PD will periodically refresh the Preferred Lifetime and
| the Valid Lifetime of an advertised prefix to
| AdvPreferredLifetime and AdvValidLifetime, respectively, as
| long as the resulting lifetimes of the corresponding prefixes
| do not extend past the DHCPv6-PD lease time [RENUM-CPE].
RATIONALE:
根拠：
* In the context of [RFC8028], where it is clear that use of addresses configured for a given prefix is tied to using the next-hop router that advertised the prefix, it does not make sense for the Preferred Lifetime of a PIO to be larger than the Router Lifetime (AdvDefaultLifetime) of the corresponding Router Advertisement messages. The Valid Lifetime is set to a larger value to cope with transient network problems.
* [RFC8028]のコンテキストでは、指定されたプレフィックスに設定されたアドレスの使用がプレフィックスをアドバタイズしたネクストホップルータを使用することに関連している場合、PIOの優先寿命が大きくなることは意味がありません。対応するルータ広告メッセージのルータの有効期間（advdefaultLifetime）よりも。一時的なネットワークの問題に対処するために、有効な有効期間が大きい値に設定されます。
* Lacking RAs that refresh information, addresses configured for advertised prefixes become deprecated in a more timely manner; therefore, Rule 3 of [RFC6724] causes other configured addresses (if available) to be used instead.
* 情報を更新するRASを欠く、アドバタイズされたプレフィックスに設定されたアドレスは、よりタイムリーに推奨されなくなります。したがって、[RFC6724]の規則3は、代わりに他の設定されたアドレス（使用可能な場合）を使用します。
* Reducing the Valid Lifetime of PIOs helps reduce the amount of time a host may maintain stale information and the amount of time an advertising router would need to advertise stale prefixes to invalidate them. Reducing the Preferred Lifetime of PIOs helps reduce the amount of time it takes for a host to prefer other working prefixes (see Section 12 of [RFC4861]). However, we note that while the values suggested in this section are an improvement over the default values specified in [RFC4861], they represent a trade-off among a number of factors, including responsiveness, possible impact on the battery life of connected devices [RFC7772], etc. Thus, they may or may not provide sufficient mitigation to the problem discussed in this document.
* PIOSの有効な有効期間を短縮すると、ホストが古い情報を維持できる時間と広告ルータが無効にするために古いプレフィックスをアドバタイズする必要がある時間を短縮するのに役立ちます。PIOSの好ましい寿命を短縮するのに役立ちますHostが他の作業プレフィックスを好むのにかかる時間を短縮するのに役立ちます（[RFC4861]のセクション12を参照）。ただし、このセクションで提案されている値は[RFC4861]で指定されているデフォルト値の改善ですが、応答性を含むいくつかの要因、接続されたデバイスのバッテリ寿命への影響の可能性のあるトレードオフを表していることに注意してください。したがって、この文書で説明した問題に対する十分な緩和を提供してもしなくてもよい。
Improvements in Customer Edge routers [RFC7084], such that they can signal hosts about stale prefixes to deprecate (and eventually invalidate) them accordingly, can help mitigate the problem discussed in this document for the "home network" scenario. Such work is currently being pursued in [RENUM-CPE].
顧客エッジルータの改善[RFC7084]は、それらがそれに応じてそれらを非推奨（そして最終的に無効にする）を推奨（そして最終的に無効にする）を通知することができるように、「ホームネットワーク」シナリオのためにこの文書で説明した問題を軽減するのに役立ちます。そのような仕事は現在[renum-cpe]で追求されています。
Improvements in the SLAAC protocol [RFC4862] and some IPv6-related algorithms, such as "Default Address Selection for Internet Protocol Version 6 (IPv6)" [RFC6724], would help improve network robustness. Such work is currently being pursued in [RENUM-RXN].
SLAACプロトコル[RFC4862]の改善と「インターネットプロトコルバージョン6（IPv6）」[RFC6724]などの「デフォルトアドレス選択」などの一部のIPv6関連のアルゴリズムは、ネットワークの堅牢性を向上させるのに役立ちます。そのような作品は現在[RENUM-RXN]で追求されています。
The aforementioned work is considered out of the scope of this present document, which only focuses on documenting the problem and discussing operational mitigations.
前述の作業は、この本文書の範囲外であると考えられており、それは問題の文書化および作業緩和の議論に焦点を当てている。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document discusses a problem that may arise in scenarios where flash-renumbering events occur and proposes workarounds to mitigate the aforementioned problem. This document does not introduce any new security issues; therefore, the same security considerations as for [RFC4861] and [RFC4862] apply.
この文書では、フラッシュ番号付けイベントが発生し、前述の問題を軽減するための回避策を提案するシナリオで発生する可能性がある問題について説明します。この文書では、新しいセキュリティ問題は紹介されません。したがって、[RFC4861]と[RFC4862]と同じセキュリティ上の考慮事項が適用されます。
[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、「IPバージョン6（IPv6）の隣接発見（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ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724] Thaler、D.、ED。、Draves、R.、Matsumoto、A.、T. Chown、「インターネットプロトコルバージョン6のデフォルトアドレス選択（IPv6）」、RFC 6724、DOI 10.17487 / RFC6724、2012年9月<https：//www.rfc-editor.org/info/rfc6724>。
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, <https://www.rfc-editor.org/info/rfc8028>.
[RFC8028] Baker、F.およびB.Carpenter、「マルチプレフィックスネットワーク内のホストによるファーストホップルータ選択」、RFC 8028、DOI 10.17487 / RFC8028、2016年11月、<https：///www.rfc-編集者。org / info / rfc8028>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[DEFAULT-ADDR] Linkova, J., "Default Address Selection and Subnet Renumbering", Work in Progress, Internet-Draft, draft-linkova-6man-default-addr-selection-update-00, 30 March 2017, <https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00>.
[default-addr] Linkova、J.、 "Default Addressの選択とサブネットの番号なし"、進行中の作業、インターネットドラフト、drapt-linkova-6man-default-addr-selection-update-00,2017、<https：//tools.ietf.org/html/draft-linkova-6man-default-addr-Selection-update-00>
[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network (updated with solution)", SI6 Networks, February 2016, <https://www.si6networks.com/2016/02/16/quiz-weird-ipv6- traffic-on-the-local-network-updated-with-solution/>.
[Fritz] Gont、F.、 "クイズ：ソリューションで更新された（ソリューションで更新された）"、2016年2月、<https://www.si6networks.com/2016/02/16/2016/02/16/2016/02/16/3016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016/02/16/2016 / 02/16Weird-IPv6 - ローカルネットワーク更新 - ソリューション/>。
[GERMAN-DP]
BFDI, "Einführung von IPv6: Hinweise für Provider im
Privatkundengeschäft und Hersteller" [Introduction of
IPv6: Notes for providers in the consumer market and
manufacturers], Entschliessung der 84. Konferenz der
Datenschutzbeauftragten des Bundes und der Lander
[Resolution of the 84th Conference of the Federal and
State Commissioners for Data Protection], November 2012,
<http://www.bfdi.bund.de/SharedDocs/Publikationen/
Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
6.pdf?__blob=publicationFile>.
[Linux-update] Gont, F., "Subject: [net-next] ipv6: Honor all IPv6 PIO Valid Lifetime values", message to the netdev mailing list, 19 April 2020, <https://patchwork.ozlabs.org/project/netdev/ patch/20200419122457.GA971@archlinux-current.localdomain/>.
[Linux-Update] gont、f.、 "subject：[net-next] IPv6：すべてのIPv6 PIO有効な有効期間の値"、NetDevメーリングリストへのメッセージ、https://patchwork.ozlabs.org/ project / netdev / patch / 20200419122457.ga971@archlinux-current.localdomain/>。
[RENUM-CPE] Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events", Work in Progress, Internet-Draft, draft-ietf-v6ops-cpe-slaac-renum-07, 16 February 2021, <https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-07>.
[Renum-CPE]ゴント、F.、Zorz、J.、Patterson、R.、およびB. Volz、「顧客エッジルータのIPv6の反応の改善」、進行中の作業、インターネットドラフト、ドラフトIETF-V6OPS-CPE-SLAAC-RENUM-07,2021、<https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-07>
[RENUM-RXN] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Work in Progress, Internet-Draft, draft-ietf-6man-slaac-renum-02, 19 January 2021, <https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-02>.
[RENUM-RXN] Gont、F.、Zorz、J.、R.Patterson、「ステートレスアドレスの自動設定の堅牢性（SLAAC）のフラッシュ中番号の変更イベントの改善、進行中の作業、インターネットドラフト、ドラフト-IETF-6Man-slaac-renum-02、2021年1月19日、<https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-02>
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C.、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www.rfc-editor.org / info / rfc7084>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F.、およびD.Thaler、「IPv6アドレス生成メカニズムのためのセキュリティとプライバシーに関する考察」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：///www.rfc-Editor.org/info/rfc7721>。
[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>。
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC8981] Gont、F.、Krishnan、S.、Narten、T.、およびR. Draves、「IPv6のステートレスアドレス自動設定のための一時アドレス拡張機能」、RFC 8981、DOI 10.17487 / RFC8981、2021年2月、<https：//www.rfc-editor.org/info/rfc8981>。
[RIPE-690] Žorž, J., Steffann, S., Dražumerič, P., Townsley, M., Alston, A., Doering, G., Palet Martinez, J., Linkova, J., Balbinot, L., Meynell, K., and L. Howard, "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose", RIPE 690, October 2017, <https://www.ripe.net/publications/docs/ripe-690>.
[RIPE-690]、J.、Steffann、S.、Drałumerić、P.、Townsley、M.、Alston、A.、Douer、G.、Palet Martinez、J.、Linkova、J.、Balbinot、L.、Meynell、K.、およびL. Howard、「オペレータのための最良の現在の運用慣行：エンドユーザーのためのIPv6プレフィックスの割り当て - 永続性対永続性、および選択するサイズ」、熟した690、2017年10月、<https：//www.ripe.net/publications/docs/ripe-690>。
[UK-NOF] Palet Martinez, J., "IPv6 Deployment Survey and BCOP", UK NOF 39, January 2018, <https://indico.uknof.org.uk/event/41/contributions/542/>.
[UK-NOF] Palet Martinez、J.、「IPv6展開調査とBCOP」、英国NOF 39、2018年1月、<https：//indico.uknof.org.uk/event/41/contributions/542/>。
Acknowledgments
謝辞
The authors would like to thank (in alphabetical order) Brian Carpenter, Alissa Cooper, Roman Danyliw, Owen DeLong, Martin Duke, Guillermo Gont, Philip Homburg, Sheng Jiang, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Warren Kumari, Ted Lemon, Juergen Schoenwaelder, Éric Vyncke, Klaas Wierenga, Robert Wilton, and Dale Worley for providing valuable comments on earlier draft versions of this document.
著者らは、（アルファベット順に）Brian Carpenter、Alissa Cooper、Roman Danyliw、Owen Delong、Martin Duke、Martin Duke、Philip Homburg、Sheng Jiang、Murray Kucherawy、Warren Kumari、Tedレモン、Juergen Schoenwaelder、エリコン・ビンケ、Klaas Wierenga、Robert Wilton、およびDale Worleyは、この文書の前の版のバージョンについて貴重なコメントを提供します。
The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, Uesley Correa, Owen DeLong, Gert Doering, Martin Duke, Fernando Frediani, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez, Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan for providing valuable comments on a previous document on which this document is based.
著者らは、（アルファベット順）Mikael Abrahamsson、Luis Balbinot、Brian Carpenter、Brian Carpenter、Tassos Chatzithomooglou、Uesley Correa、Owen Delong、Gert Duke、Martin Duke、Fernando Frediani、Steinar Hauc、Philip Horard、Lee Howard、クリスチャンのHuitema、Ted Lemon、Albert Manfredi、Jordi Palet Martinez、Michael Richardson、Mark Smith、Tarko Tikan、およびOle Troanこの文書が基づいている以前の文書に貴重なコメントを提供します。
Fernando would like to thank Alejandro D'Egidio and Sander Steffann for a discussion of these issues. Fernando would also like to thank Brian Carpenter who, over the years, has answered many questions and provided valuable comments that have benefited his protocol-related work.
これらの問題について議論するために、フェルナンドはAlejandro D'EgidioとSander Steffannに感謝します。また、Fernandoはまた、長年にわたり多くの質問に答えて、彼のプロトコル関連の仕事に恩恵を受けた貴重なコメントを提供したBrian Carpenterに感謝します。
The problem discussed in this document has been previously documented by Jen Linkova in [DEFAULT-ADDR] and also in [RIPE-690]. Section 1 borrows text from [DEFAULT-ADDR], authored by Jen Linkova.
この文書で説明した問題は、JEN Linkovaが[Default-Addr]と[RIPE-690]に以前に文書化されています。セクション1 JEN Linkovaが作成した[default-addr]からテキストを借りる。
Authors' Addresses
著者の住所
Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autónoma de Buenos Aires Argentina
Fernando Gont Si 6 Networks Segurola y Habana 4310,7mo Piso Villa Devoto CiudadAutónomade Buenos Airesアルゼンチン
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Jan Žorž 6connect, Inc.
1月1日6connect、Inc。
Email: jan@6connect.com
Richard Patterson Sky UK
Richard Patterson Sky UK.
Email: richard.patterson@sky.uk