[ipv6-wg] SLAAC in renumbering events

Folks,

If you follow the 6man working group of the IETF you may have seen a
bunch of emails on this topic, on a thread resulting from an IETF
Internet-Draft we published with Jan Žorž about "Reaction of Stateless
Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at:
https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt
 )

Short version of story:

There are a number of scenarios where SLAAC hosts may end up using stale
configuration information.

For example, a typical IPv6 deployment scenario is that in which a CPE
router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a
sub-prefix of of the leased prefix on the LAN-side, via SLAAC. In such
scenarios, if the CPE router crashes and reboots, it may loose all
information about the previously-leased prefix. Upon reboot, the CPE
router may be leased a new prefix that will result in a new sub-prefix
being advertised on the LAN-side of the CPE router.

As a result, hosts will normally configure addresses for the
newly-advertised prefix, but will normally also keep (and use) the
previously-configured (and now stale!) IPv6 addresses, leading to
interoperability problems.

The RIPE-690 BCOP document had originally tried to address this problem
by recommending operators to lease stable IPv6 prefixes to CPE routers.
However, for a variety of reasons ISP may not be able (or may not want)
to lease stable prefixes, and may instead lease dynamic prefixes.

Most of the voices on the 6man wg mailing-list fell into one of the
following camps:

 * "ISPs should be leasing stable prefixes -- if they don't, they are
    asking for trouble!"

 * "CPE routers should record leased prefixes on stable storage, such
   that they can 'deprecate' such prefixes upon restart -- if they
   don't, they are asking for trouble!"

 * "No matter whose fault is this (if there is any single party to blame
   in the first place), we should improve the robustness of IPv6
   deployments"


Our Internet-Draft tries to improve the current state of affairs via the
following improvements:

* Allow hosts to gracefully recover from stale network configuration
  information -- i.e., detect and discard stale network configuration
  information

* Have SLAAC routers employ more appropriate timers, such that
  information is phased-out in a timelier manner -- unless it is
  actively refreshed by Router Advertisement messages

* Specify the interaction between DHCPv6-PD and SLAAC -- which was
  rather under-specified

* Require CPE routers to store leased prefixes on stable storage, and
  deprecate stale prefixes (if necessary) upon restart

We are looking forward to more input on the document (or any comments on
the issue being discussed), particularly from operators.

So feel free to send your comments on/off list as you prefer

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492