Re: A common problem with SLAAC in "renumbering" scenarios

Mark Smith <markzzzsmith@gmail.com> Thu, 31 January 2019 21:26 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC11130F6A; Thu, 31 Jan 2019 13:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz_g_mj8YqBL; Thu, 31 Jan 2019 13:26:38 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71349130F2C; Thu, 31 Jan 2019 13:26:38 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id u18so4022200oie.10; Thu, 31 Jan 2019 13:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZO9bXTZh4hCy2fr4xlre8MvQjFGVRmIrDi4LR1BN3To=; b=sUdq8E18vwqpQKetl1wBcPUPd8bAiM/pfJdxtZFJHIgd/X49Vn01yJZLsmCUQ9UKpM wZ29eoUnP63rYKEZJv9OLv3oYfuPzIwwYKMzvDeNbZhfmXqWEIHrTfXFqGJMp9XYw7fS Ww7ZwkZlM58lIh8iKvg6s18CWvPlVsRlyllLteVMpT4e034+lt8InzMSrN52Qf1J7Krc JaRZ4UT7Vdggplx16SK04HgsIs93fRmZVnUcFBZiMWWd03rtT25j7EjJnnN906uAClzH Cb9e1xlifH1BEIVhwcYSyOxmfrfV5nNagM0yFWxSGExoaHcG0EC9wKUt1RK690GNAOea 8egg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZO9bXTZh4hCy2fr4xlre8MvQjFGVRmIrDi4LR1BN3To=; b=aQRO3JGvqF+19cpfQkHHnlFAlFXjZ0GZbda5TJHQ4PDGbsO+KpjU4G3Mqzo6MJY4MI uPAAdy+iow4ELyclbgROEVHYcTuDAHwuYP32JHa+2Tfg7pH5P7VyjFX2k/IZLNcqLR3V JG6K3JgoA2w5/wuJb8GSnL1ihXpd9KyhsAFutVN9YmwO5CQYvct+yhbbCbK1buow6LBG AdB4Lrb+XZysONCj9eQ8aeMavNLBupPBA62rOwA+XqP4mcaRlQEfP24+bH9h2ccGNeKK WFsghiAgjf3/MyJZ6lKaRi4M+bixCHocuGReibP7cL1SSZLvmvgihww5ZNZHQNlsWXJP tfwA==
X-Gm-Message-State: AJcUukcVdJOnspzIMFSQG6/fg1yRZsKU3ZTD1tAzIszXoykgYqbO+PQQ qtKjvbTCgNiEwh5i4x//95NXogbK6Z8qWMCthR3hMiJB
X-Google-Smtp-Source: ALg8bN48MyvYK6pqtOlntg98Rsgqdr6cP1ixift7H5bBp2iM0Kr8awA40gcHyU44xjgK8vnbl9inILw4sRLpLkvoyV4=
X-Received: by 2002:aca:5a88:: with SMTP id o130mr17107417oib.275.1548969997342; Thu, 31 Jan 2019 13:26:37 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com>
In-Reply-To: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 01 Feb 2019 08:26:10 +1100
Message-ID: <CAO42Z2xp5sBMfDP3z2SX9roomo_uGTAWLfTqBeQESS5pnkoqBw@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Fernando Gont <fgont@si6networks.com>
Cc: "6man@ietf.org" <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VU4VRrxB3QfHkuexGpZmzZF6G0g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jan 2019 21:26:42 -0000

Hi,

So I thought about this problem back when I was doing some work with
IPv6 CPE vendors and working on a production IPv6 residential
deployment in 2010. As the CPE vendors were commonly using 'radvd', I
thought it would be easier for me to write some code for that to
handle this situation and push it directly to the 'radvd' people
rather than try to go through the vendors and have them up stream it.

Here's the descriptions of the two options that were added for a
prefix (from radvd.conf(5))

       DeprecatePrefix on|off

              Upon  shutdown,  this  option  will cause radvd to deprecate the
              prefix by announcing it in the radvd shutdown  RA  with  a  zero
              preferred  lifetime and a valid lifetime slightly greater than 2
              hours. This will encourage end-nodes using this prefix to depre‐
              cate any associated addresses immediately. Note that this option
              should only be used when only one router is announcing the  pre‐
              fix onto the link, otherwise end-nodes will deprecate associated
              addresses despite the prefix still  being  valid  for  preferred
              use.

              See  RFC4862, section 5.5.3., "Router Advertisement Processing",
              part (e).

              Default: off


       DecrementLifetimes on|off

              This option causes radvd to decrement the  values  of  the  pre‐
              ferred  and  valid lifetimes for the prefix over time. The life‐
              times are decremented by the number of seconds  since  the  last
              RA. If radvd receives a SIGUSR1 signal, it will reset the values
              of the preferred and valid lifetimes back to the initial  values
              used by radvd when it started. If radvd never receives a SIGUSR1
              signal, it will continue to decrement the  lifetimes  until  the
              preferred  lifetime  reaches  zero. After a final RA with a zero
              value preferred lifetime, radvd will cease to announce the  pre‐
              fix.  If a SIGUSR1 signal then causes the lifetimes to be reset,
              the prefix will then re-appear in the RAs.

              This option is intended to be used in conjunction with a  DHCPv6
              client that is using the Identity Association for Prefix Delega‐
              tion (IA_PD) option to acquire a prefix from a Delegating Router
              for use by a Requesting Router. In this scenario, the prefix(es)
              from within the delegated prefix that  are  announced  by  radvd
              would age in parallel with and at the same rate as the delegated
              prefix, and expire at approximately the same time, if the  dele‐
              gated prefix's life isn't extended.

              See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration
              Protocol (DHCP) version 6".

              Default: off



As mentioned in the first option description, to deprecate an
address/prefix, a RA PIO valid lifetime of zero is invalid, and must
be greater than 7200 seconds / 2 hours. This is to prevent a DoS by a
rogue RA announcing a 0 valid lifetime. RFC4862, section 5.5.3.,
"Router Advertisement Processing", part (e) discusses this. I chose
the value 7203 seconds.

The second option is to ensure synchronised ageing of addresses on
hosts in parallel with the age of the DHCPv6-PD prefix. In case of a
CPE reboot, if the CPE gets a different new prefix via DHCPv6-PD, the
new prefix's lifetimes will probably be greater than those of the old
DHCPv6-PD prefix, and if I recall correctly, I was seeing hosts choose
to use the highest preferred lifetime addresses. So the addresses from
the newer PD prefix should be used by hosts, and the addresses from
the old and now invalid one should eventually age out and disappear.
I've recently thought there was something in the source address
selection RFC about choosing highest value lifetimes in source address
selection, however I can't seem to find it, so I may be
misremembering.

This second option isn't perfect though, as it won't work if the newer
PD prefix has lower initial lifetimes than the current lifetimes of
the old prefix at the time CPE reboots. That could happen if an ISP
has decided to roll out lower PD prefix lifetimes.

More broadly, a router reboot is or should be a transient packet loss
event. Hosts are expected to tolerate transient packet loss, which is
why TCP didn't originally have any keepalives at all, and the
keepalives it commonly has now has a large initial timeout value of 2
hours. Devices (well, routers) in the Internet aren't intended to have
knowledge of transport layer connections, so that if they reboot they
don't have to reacquire or relearn transport layer connection state
before being able to forward hosts' packets. IPv4/IPv6 forwarding is
purposely stateless.

So if a CPE reboots and reattaches to the network/Internet at the same
point, it should be given back the same DHCPv6-PD prefix i.e. the
stable prefix scenario. If the CPE reattaches to the network at a
different point (for some definition of different attachment point
e.g. different access link, different PPPoE username), then giving it
a different PD prefix is reasonable and probably should be expected.

I sympathise with the privacy issue of the stable prefix. I think it
would be better to have the end-user initiate a PD prefix change via a
web portal or similar, rather than rebooting their CPE, because it
isn't possible for an ISP to distinguish whether a CPE reboot was
caused by a bug or the end-user was actively doing it for the purposes
of changing the PD prefix, so it isn't possible to absolutely know if
the same or a different PD prefix should be given back to the CPE.

If an ISP wants to or needs to initiate the prefix changes, they could
have a mechanism to cycle customers through old and new DHCPv6-PD
prefixes, phasing them in and out over time using IPv6 address ageing.
I don't think that would be a very simple mechanism to build, however
there is the cost of providing prefix privacy over time. (One issue
might be that some customers have connections they want to have up for
long periods of time e.g. a CCTV video feed, longer than the ISP
chosen default prefix lifetime for privacy. Those customers should
probably given a option somewhere to opt out of the changing prefixes,
or to be able to set their own privacy prefix change interval.)

Note that the ISP I worked for in 2010 provided (an still provides)
stable PD prefixes (and dynamic SLAAC ones on the PPPoE/PPP session),
so the ability to cope with changing PD prefixes upon CPE reboot
wasn't a capability we required. I mainly spent my own time on the
problem and the 'radvd' code.

I think that's all of what I thought about this at the time, I'll see
if I can remember anything else.

Regards,
Mark.



On Thu, 31 Jan 2019 at 22:01, Fernando Gont <fgont@si6networks.com> wrote:
>
> Folks,
>
> We have posted a new I-D discussing a problem that can arise in typical
> deployment scenarios where the CPE obtains a prefix via DHCPv6-PD and
> advertises a prefix on the LAN side.
>
> Our draft is available at:
> https://tools.ietf.org/html/draft-gont-6man-slaac-renum
>
>
> The Abstract is:
>    A very common IPv6 deployment scenario is that in which a CPE employs
>    DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one
>    prefix from within the leased prefix is advertised on a local network
>    via SLAAC.  In scenarios where e.g. the CPE crashes and reboots,
>    nodes on the local network continue using outdated prefixes which
>    result in connectivity problems.  This document analyzes this problem
>    scenario, and proposes workarounds.
>
> Any comments will be welcome.
>
> Thanks!
>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------