RFC 8978

Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events 💖

Okay bestie, let's start with the title block 🎀 This is RFC 8978, published in March 2021 by the IETF. The authors are:

• F. Gont (SI6 Networks) 🦋
• J. Žorž (6connect) 🌸
• R. Patterson (Sky UK) 💜

The category is Informational and the ISSN is 2070-1721. The title block doesn't list anything this document obsoletes or updates, so it doesn't replace or change any older RFC. 🧚

Abstract ✨

So picture this 🌸 IPv6 prefix info goes stale, but nobody reliably tells the hosts. This happens when a Customer Edge router crashes and reboots without remembering the prefixes it was using. With no explicit, reliable signal, hosts on the local network can keep using stale prefixes for an unacceptably long time, like several days, and then connectivity breaks 😭 This document describes the issue, talks through operational workarounds that may help make networks more robust, and flags areas where more work may be needed. 💅

Status of This Memo

This one isn't an Internet Standards Track spec. It's published for informational purposes 🧚

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🤓

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8978 🔗

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚖️

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

1. Introduction ✨

Okay, so the basics 🎀 IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] tells hosts which prefixes to use for address configuration. It does this with Prefix Information Options (PIOs) sent in Router Advertisement (RA) messages. IPv6 mostly assumes prefixes are stable. Renumbering only happens in a planned way: old prefixes get deprecated (and eventually invalidated) through reduced prefix lifetimes, and new prefixes come in with longer lifetimes at the same time. Lovely and tidy 💅

Then there are the chaotic moments. These are the so-called "flash-renumbering" events, where a prefix a network is using suddenly becomes invalid and gets replaced by a new one 😭 In some of these scenarios, the local router causing the renumbering can still try to deprecate (and eventually invalidate) the prefix in use, by explicitly signaling the network about it. In other scenarios, it can't do that.

Here's the core problem 🥺 In scenarios where network configuration info about IPv6 prefixes goes invalid without any explicit and reliable signal, hosts on the local network may keep using stale prefixes for an unacceptably long period of time. That leads to connectivity problems.

So where can this show up? Not only in these cases, but here are some big ones 👑

• The most common IPv6 setup for residential or small office networks. A Customer Edge (CE) router uses DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service Provider (ISP). A sub-prefix of that leased prefix gets advertised on the LAN side of the CE router through Stateless Address Autoconfiguration (SLAAC) [RFC4862]. If the CE router crashes and reboots, it may get a different prefix from the one it had before, so it advertises a new sub-prefix on the LAN side through SLAAC. Hosts will usually configure addresses for the new sub-prefix, but they'll also normally keep the addresses configured for the old sub-prefix and may actively use them. Their Preferred Lifetime and Valid Lifetime let them do exactly that 🙈
• A router (for example, a Customer Edge router) advertises autoconfiguration prefixes that came from DHCPv6-PD, using constant PIO lifetimes that aren't synchronized with the DHCPv6-PD lease time. Section 6.3 of [RFC8415] actually requires that synchronization, so this breaks the rule from [RFC8415]. It's still not an unusual behavior, though. This is especially common in implementations where DHCPv6-PD lives in a different software module than SLAAC 🤷‍♀️
• A switch-port a host is plugged into gets moved to another subnet (VLAN), either from manual switch-port reconfiguration or 802.1x reauthentication. There's evidence that some 802.1x supplicants don't reset network settings after a successful 802.1x authentication. If a host fails 802.1x authentication, it may get put in a "quarantine" VLAN. If it later authenticates successfully, it may end up with IPv6 addresses from both the old ("quarantine") and the new VLANs 😵‍💫
• During a planned renumbering event, a router is set up to send an RA with a PIO for the "old" prefix, where the Preferred Lifetime is zero and the Valid Lifetime is set to a small value. It also sends a PIO for the new prefix with default lifetimes. But unsolicited RAs go to a multicast destination address, and multicast is pretty unreliable on busy Wi-Fi networks, so local hosts might never receive the RA 📡
• An automated device config management system periodically pushes configs to network devices. In these cases, devices may just immediately forget their previous configuration instead of withdrawing it gracefully. If a push changes the prefix configured on a particular subnet, hosts attached to that subnet might never hear about the change, so their addresses from the "old" prefix might not get deprecated (and eventually invalidated) on time. A related scenario is an incorrect renumbering event, where an administrator renumbers a network by just deleting the "old" prefix from the configuration and configuring a new one instead 😬

Here's the thing: without any explicit and reliable signal to deprecate (and eventually invalidate) stale prefixes, hosts may keep using the addresses they already configured. That usually means packets get filtered or blackholed, either on the CE router or somewhere in the ISP network 🕳️

Now the timing part, which is kind of wild 😳 The default Preferred Lifetime and Valid Lifetime values for PIOs specified in [RFC4861] mean that in the scenarios above, stale addresses would stick around and could still be used for new communication for an unacceptably long time: one month and one week, respectively. That can cause interoperability problems, when hosts should be moving over to the newly advertised prefix(es) much more quickly.

Some devices have come up with ad hoc fixes. For example, a device might send RAs to deprecate (and eventually invalidate) apparently stale prefixes when it receives any packet using a source address from a prefix that isn't currently advertised for address configuration on the local network [FRITZ]. But this can cause other interoperability problems, especially in multihomed or multi-prefix scenarios. That's a clear sign this area needs proper advice 📣

Unresponsiveness to flash-renumbering events comes from two things. First, the network can't deprecate (and eventually invalidate) stale information. Second, hosts can't react to network configuration changes quickly enough. Ideally, flash-renumbering events wouldn't happen at all, and when they do, hosts would be explicitly and reliably told about them. But for robustness, it's really important that hosts can recover from stale configuration information even when these events happen and the network can't reliably notify them 💪

Section 2 analyzes this problem in more detail. Section 3 describes possible operational mitigations. Section 4 describes possible future work to address the problem above. 🗺️

2. Analysis of the Problem 🔍

As noted in Section 1, the problem discussed in this document gets worse because of the default values of some protocol parameters and other factors. The following sections break down each of them in detail 🧠✨

2.1. Use of Dynamic Prefixes ✨

okay so in networks that use dynamic prefixes 🦋, renumbering events push updated network config through the whole network, so they get handled gracefully 💖. but if the renumbering happens along with, e.g., loss of configuration state by some of the devices involved (like a router crashes, reboots, and gets leased a new prefix) 😭, it can turn into a flash-renumbering event, where new prefixes show up without the old ones being properly phased out 💀.

In simple residential or small office setups, this whole problem would be avoided if DHCPv6-PD leased "stable" prefixes 🏠. but a recent survey [UK-NOF] found that 37% of the responding ISPs employ dynamic IPv6 prefixes 🤯. so dynamic prefixes are an operational reality, fr fr.

Deployment reality aside, stable prefixes come with a bunch of possible issues too:

• Provisioning systems may be unable to deliver stable IPv6 prefixes. 🙃
• 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. so basically, every time a prefix is leased, the resulting prefixes can become dynamic, even if the device doing the leasing got a stable prefix from its upstream router. 🌀
• While there is a range of information that may be used to correlate network activity [RFC7721], stable prefixes clearly make network activity correlation easier, and may reduce the effectiveness of "temporary addresses" [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. 🔐
• 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 (like the ones above), IPv6 deployments might employ dynamic prefixes (even at the expense of the issues discussed in this document), and a network's dynamics might be such that it behaves like it has dynamic prefixes. rather than trying to regulate how operators run their networks, this document aims at improving network robustness in the deployed Internet. 💅✨

2.2. Default PIO Lifetime Values in IPv6 Stateless Address Autoconfiguration (SLAAC) 🕰️

the impact of this issue depends on the lifetime values used for PIOs, because those values decide how long the matching addresses stay preferred and valid 📅. so when this problem hits, the longer the PIO lifetimes, the bigger the impact 📈.

[RFC4861] sets these default PIO lifetime values:

• Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
• Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)

in bad situations, like when the network info has gone stale and the network never sends any explicit and reliable signal about it (as described in Section 1) 😵, it could take hosts up to 7 days (one week) to deprecate the matching addresses, and up to 30 days (one month) to finally invalidate and remove any addresses configured for the stale prefix 🫠. so yeah, hosts will typically take an unacceptably long time (on the order of several days) to recover from these scenarios 🐌.

2.3. Recovering from Stale Network Configuration Information 🔄

SLAAC hosts can't recover from stale network config info, and here's why 🙅‍♀️:

• In scenarios where SLAAC routers explicitly signal the renumbering event, hosts will typically deprecate, but not invalidate, the stale addresses. that's because item "e)" of Section 5.5.3 of [RFC4862] says an unauthenticated RA may never reduce the valid lifetime of an address to less than two hours 🚫. so communication with the new "users" of the stale prefix won't be possible, since the stale prefix still counts as "on-link" for the local hosts 🥲.
• Without explicit signaling from SLAAC routers, SLAAC hosts will typically fail to recover from stale configuration information in a timely manner 😩. hosts would need to rely on the last Preferred Lifetime and Valid Lifetime advertised for the stale prefix, so the matching addresses can become deprecated and then invalidated. Please see Section 2.2 of this document for a discussion of the default PIO lifetime values 📚.

2.4. Lack of Explicit Signaling about Stale Information 📣

whenever prefix info has changed, a SLAAC router should advertise not only the new info but also the stale info, with appropriate lifetime values (both the Preferred Lifetime and the Valid Lifetime set to 0) 🧹. that gives SLAAC hosts explicit signaling to remove the stale info (including configured addresses and routes). but in certain scenarios, like when a CE router crashes and reboots, the CE router may have no knowledge about the previously advertised prefixes, so it might be unable to advertise them with appropriate lifetimes (needed to deprecate and eventually invalidate them) 😬.

anyway, as discussed in Section 2.3, PIOs with small Valid Lifetimes in unauthenticated RAs won't lower the Valid Lifetime to any value shorter than two hours (as per [RFC4862]) ⏳. so even if a SLAAC router tried to explicitly signal the network about the stale config info via unauthenticated RAs, implementations compliant with [RFC4862] would deprecate the matching prefixes but would fail to invalidate them 🤦‍♀️.

   |  NOTE:
   |
   |  Some implementations have been updated to honor small PIO
   |  lifetimes values, as proposed in [RENUM-RXN].  For example,
   |  please see [Linux-update].

2.5. Interaction between DHCPv6-PD and SLAAC 🤝

DHCPv6-PD is normally used along with SLAAC, but the interaction between the two protocols is mostly unspecified 🫣. not unusually, the two protocols live in two different software components, and the interface between them is some sort of script that feeds the SLAAC implementation with values learned from DHCPv6-PD 📜.

sometimes the prefix lease time gets fed as a constant value to the SLAAC router implementation. so 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 those prefixes for longer than they were leased via DHCPv6-PD 🚨.

3. Operational Mitigations 🛠️

The following subsections discuss possible operational workarounds for the problems mentioned above 🧰.

3.1. Stable Prefixes 🧊

As noted in Section 2.1, using stable prefixes would eliminate the issue in some of the scenarios discussed in Section 1 of this document, like the typical home network deployment 🏡. but, as noted in Section 2.1, there might be reasons an administrator may want or need to use dynamic prefixes 🤷‍♀️.

3.2. SLAAC Parameter Tweaking 🎛️

an operator may want to override some SLAAC parameters so that, normally, the associated timers get refreshed/reset ✅. but when there are network faults (like the one discussed in this document), those timers go off and trigger some fault-recovering action (e.g., deprecate and eventually invalidate stale addresses) ⏰.

these router config variables from [RFC4861] (matching the "lifetime" parameters of PIOs) could be overridden like this:

• AdvPreferredLifetime: 2700 seconds (45 minutes)
• AdvValidLifetime: 5400 seconds (90 minutes)

   |  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's clear that using addresses configured for a given prefix is tied to using the next-hop router that advertised the prefix, it doesn't 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 💪.
• Lacking RAs that refresh info, addresses configured for advertised prefixes become deprecated in a more timely manner 🏃‍♀️. so Rule 3 of [RFC6724] makes other configured addresses (if available) get used instead ✨.
• Reducing the Valid Lifetime of PIOs helps cut down the amount of time a host may hang onto stale info, and the amount of time an advertising router would need to advertise stale prefixes in order to invalidate them 🗑️. reducing the Preferred Lifetime of PIOs helps cut down the time it takes a host to prefer other working prefixes (see Section 12 of [RFC4861]) 🏁. however, the values suggested in this section are an improvement over the defaults in [RFC4861], but they're a trade-off among a bunch of factors, including responsiveness and possible impact on the battery life of connected devices [RFC7772], etc. ⚖️ so they may or may not give enough mitigation to the problem discussed here 🤞.

4. Future Work 🔮

Improvements in Customer Edge routers [RFC7084], so they can signal hosts about stale prefixes to deprecate (and eventually invalidate) them, can help mitigate this problem for the "home network" scenario 🏠🫶. that work is currently being pursued in [RENUM-CPE] 👩‍💻.

Improvements in the SLAAC protocol [RFC4862] and some IPv6-related algorithms, like "Default Address Selection for Internet Protocol Version 6 (IPv6)" [RFC6724], would help make the network more robust 🦾. that work is currently being pursued in [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 📝.

5. IANA Considerations 🎀

Good news for IANA: there's nothing to do here! This document has no IANA actions. Easy breezy 🦋

6. Security Considerations 💀

Okay bestie, this section is serious, so let's get into it. This document talks about a problem that can pop up when flash-renumbering events happen, and it suggests workarounds to help with that problem. 🚨 It does not introduce any new security issues, so the same security considerations as for [RFC4861] and [RFC4862] apply. Go read those too, they've got your back 🫶

7. References 📚

7.1. Normative References

These are the must-reads, the foundation of the whole vibe ✨

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

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

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

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

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

7.2. Informative References

These are the extra-spicy reads for when you want the full story 💅

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

[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/>.

[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/>.

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

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

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

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

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

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

[UK-NOF]   Palet Martinez, J., "IPv6 Deployment Survey and BCOP", UK
           NOF 39, January 2018,
           <https://indico.uknof.org.uk/event/41/contributions/542/>.

Acknowledgments 🫶

Shoutout time, the squad deserves it! 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 giving super valuable comments on earlier draft versions of this document. 💖

The authors would also 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 giving valuable comments on a previous document on which this document is based. 🌸

Fernando wants to thank Alejandro D'Egidio and Sander Steffann for chatting through these issues with him. He also wants to thank Brian Carpenter, who has answered tons of questions over the years and given comments that have really helped his protocol work. 🧚

The problem discussed in this document has already been written up by Jen Linkova in [DEFAULT-ADDR] and also in [RIPE-690]. Section 1 borrows text from [DEFAULT-ADDR], which Jen Linkova wrote. Credit where credit is due, iykyk 👑

Authors' Addresses 💌

Fernando Gont
SI6 Networks
Segurola y Habana 4310, 7mo Piso
Villa Devoto
Ciudad Autónoma de Buenos Aires
Argentina

Email: fgont@si6networks.com
URI:   https://www.si6networks.com


Jan Žorž
6connect, Inc.

Email: jan@6connect.com


Richard Patterson
Sky UK

Email: richard.patterson@sky.uk