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

Mark Smith <markzzzsmith@gmail.com> Thu, 14 February 2019 04:47 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 E3C5A130F75 for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 20:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U0OYLQ0uTFWe for <ipv6@ietfa.amsl.com>; Wed, 13 Feb 2019 20:47:10 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 E8C4C130F70 for <ipv6@ietf.org>; Wed, 13 Feb 2019 20:47:09 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id w25so8344124otm.13 for <ipv6@ietf.org>; Wed, 13 Feb 2019 20:47:09 -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=WQQ6Puy+AhupEDN0CW1+1aCWJckPQJlU7vuSrjCuMUY=; b=DZAylHGvNZ6oLYiDsCFc2okp9jlqY7nmku+4HX683twVRTUoWKvN3P6Yf+8yOTFW6y CsJylTgoIlUqjqni3zQfzfi3RP9l3KwArlu9cXWoqJJ5fXBWb1+DI1PmqvlA0UpDWlJa zd2ki9vajPdrPPU749Bsnakm+DF3sSwFa96fW0uHgK7mbCqtJrR97GrkkpvsUadNxUo+ fCzsqZLSbGDtGbX67AG37QSH0Byzgkih96u/U64BiIO4hDdcSQIMIGeFzW3k24hqp4LI TgLlJnLQs1BA5pbZx1MO+kGBA64bVR4sOc9xKTb97Om8NgDPZvDTwAyt46m5xapgGVTs GQWg==
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=WQQ6Puy+AhupEDN0CW1+1aCWJckPQJlU7vuSrjCuMUY=; b=U/NtKdIG2kAgKwZ+9FIFMX4MsQHRrDMas4/UP3HTSGHF/f+ba9bqQ9+UL4kXIBTScG 6WALwSKEHvdwHsUtrV7oe94jyKzdY/HSKALEZVVhhMs9TkzlkUcmoVpaafpfjscrbNUK y5gChfhMx4+AEt+iAGcCtcbkq4PvR1cxl4b43d7b1rDXQAdS8sOecbWocpT18oMv4PwZ BISXkz0cJJ5PQPXvD2rLmRYCHUhKBDzUC3zzx60ELnrf0lmO+Q1qdayT1dVg3A1RiZUy jr+A005Lz8Sbha03CFVHZMrJdozvMXh0EQQMmgHtpcYhxuwvbYcTv4Prto0alvB8GNFT Lgag==
X-Gm-Message-State: AHQUAuZw8R03b8lpx40m2G8ULG9N7cgZmrUd2mXP/iBpM2mCA//FDJIY 3gj+dJTcdAUKxyKrJsNmBpa06Ntl/b1UgKTRfsM=
X-Google-Smtp-Source: AHgI3IZCvk9KpRksSfKpdCUUar5MTBSvfbxuZmPToDSlYAOPbUxSxjgFnI1J3BCLAvEdTlXN3hsWz6WY7F21JuywlUQ=
X-Received: by 2002:aca:4756:: with SMTP id u83mr1132783oia.60.1550119628912; Wed, 13 Feb 2019 20:47:08 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <alpine.DEB.2.20.1901311236320.5601@uplift.swm.pp.se> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <d40b41c3-ff1b-cab4-a8de-16692a78e8fd@go6.si> <D1E45CAD-08D0-43D4-90F7-C4DD44CB32C0@employees.org> <alpine.DEB.2.20.1902041330531.23912@uplift.swm.pp.se> <46B8DB92-DC81-4242-9780-0D00FB6BDB7A@employees.org> <1c7ebabb-d6f6-d877-d4aa-d6c0fc7d5c60@go6.si> <6278.1549471453@dooku.sandelman.ca> <CAO42Z2xdKtLJV11KXELBKca6CWn=B6Avz6bO_94kFFXaKiZ-pQ@mail.gmail.com> <4602.1549908472@localhost> <CAO42Z2w1swQNuwnrOyTCEMXt0NSyrBx7Ww3kUN-7dfEV=fvk3A@mail.gmail.com> <c16e0e1f-1ed2-ad88-80f1-070bdd8bccca@go6.si> <1F2C2AEE-1C7D-481C-BBA7-7E507312C53A@employees.org> <e56a6e5b-648d-200e-c35d-97f15a31fb2a@asgard.org> <CAO42Z2zh7fKAgQJq9aLCTiFoSSsTeGM=pK3gXitg+gcxH=9fhQ@mail.gmail.com> <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com>
In-Reply-To: <d38857c2-6e92-91d6-bb5d-d3eeeb61276a@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 14 Feb 2019 15:46:42 +1100
Message-ID: <CAO42Z2yb47OyXk__Sz-kO00pfcBJgLAhff5DF=mpAddR0iCnAA@mail.gmail.com>
Subject: Re: A common problem with SLAAC in "renumbering" scenarios
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Lee Howard <lee@asgard.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_m6DGgqHQ6zR7fFZo2GOlFTY7hc>
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, 14 Feb 2019 04:47:12 -0000

Hi Brian,


On Wed, 13 Feb 2019 at 12:05, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 2019-02-13 13:43, Mark Smith wrote:
> > On Wed, 13 Feb 2019 at 08:55, Lee Howard <lee@asgard.org> wrote:
> >>
> >> Seems like I may still disagree about the architecture of the Internet. . .
> >>
> >> On 2/12/19 9:53 AM, Ole Troan wrote:
> >>> Jan,
> >>>
> >>>> On 12 Feb 2019, at 04:36, Jan Zorz - Go6 <jan@go6.si> wrote:
> >>>>
> >>>> Surprisingly, this is not causing major problems. Similar to IPv4, where changing the public IPv4 address on the CPE that is doing NAT to the internal LAN doesn't have considerable effect on the hosts inside (well, some sessions could drop on change, but that's the price you pay with NAT). In IPv6, if source and destination address is the same - if network in between changes and re-establishes quick enough - that should work (and it works in deployments out there ;) )
> >>> “Not considerable effect”?
> >>> It breaks all existing connections.
> >>
> >> This is packet switching, not circuit switching. Be resilient.
> >>
> >
> > The questions are where and where best to implement that resilience?
> >
> > IP layer? Within transport layer protocols? Within the transport
> > layer/application API? Within each application?
>
> All of the above. Seriously. Resilience to "things that should never happen" is basic good software engineering. The trick is to make sure that the resilience costs nothing when things are normal, if possible.
>

(So I'm sure you know how to suck eggs ... c.f. RFC 1958 :-) )

I'm all for robustness, however there are also diminishing returns and
duplication of implementations and corresponding costs to avoid.

If this problem was a solved within each application (i.e. the problem
of unexpectedly failing transport layer connections caused by
unexpected IP address changes), it doesn't need to be solved at any of
the lower layers. Of course, trouble is, that imposes the recovery
mechanism implementation cost on each and every application that wants
or needs it.

I also think it is better to solve problems where or as close to where
their root cause is. The further away from the cause, the less
effective the solution may be, and also it may cost more to solve it.

The root cause of this issue is ISPs not providing a static/stable PD
prefix across CPE reboots, or reconnection to a different BNG caused
by link failure (e.g. landing on a different BNG after PPPoE PADI).

An ISP can eliminate that cause by providing customers with stable PD
prefixes. They may already have something quite similar if they've
supported IPv4 routed prefixes to customers via RADIUS/Framed-Route
(typically SOHO customers). They just need to build an IPv6 version of
it and use it for all of their customers.

The CPE proposal in this draft is an imperfect mitigation, distant
from where the cause exists. I don't disagree with it, however it
depends on CPE firmware developers, rather than something the ISP
itself can do.

When the CPE firmware is developed, it has to be tested and deployed.
If the ISP provides managed CPE, which can be a luxury compared to
some markets, then there will need to be 10s of 1000s if not 100s of
1000s of CPE firmware upgrades performed, outside of normal usage
hours. It the ISP doesn't provide managed CPE, then the lag on
deployment is in the order of years, because it depends on when
customers replace their, what they perceive to be perfectly
functioning harder until it fails, CPE. It's a lot of effort, and
conditional on the level of administrative control over CPE the ISP
has. It seems to me that an ISP solving it at the backend would be
easier, cheaper and more universal, meaning regardless of CPE type and
version.

So to me, the cheapest and best solution is for the an ISP to provide
a static/stable PD prefix to the customer (even though I've written
code to try to mitigate it i.e. . DeprecatePrefix and
DecrementLifetimes in radvd in the past.)

Regards,
Mark.



>     Brian
>