Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Mark Smith <markzzzsmith@gmail.com> Thu, 24 October 2019 11:13 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EC120E12 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 04:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 xP8RBmUfHnd8 for <v6ops@ietfa.amsl.com>; Thu, 24 Oct 2019 04:13:17 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 F06B9120E48 for <v6ops@ietf.org>; Thu, 24 Oct 2019 04:13:16 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id s71so7379566oih.11 for <v6ops@ietf.org>; Thu, 24 Oct 2019 04:13:16 -0700 (PDT)
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; bh=vgmJnvg2zZYGyuTBcLOVYrENiSXg4jx3qCMTwhz3UEE=; b=oCitzQYPTk7GXXcnKoPSZgiFnIAPfhtxokhRQTcZodd8jeLjCLr1KyDYZk0lbRt3Ru cArX5//XsIFsMX7GKz7lujtzPzIO1j0C2FAK2wO7uReMijstvjoGZys+GP2Fp71dL6wz NvPbG9NAc/vtjo60C3+JmKC11pqng1g68OyNF+QoO0hkKxYgT6cj9eJW0AUU/LsXdVXf YsNVIKfTQ8jMzD6dhXf/ZOHEnbDr+IVEQATVvq+kpgL86biHCD2//2nj39198EoMWrQ4 +7pvqEgwfDD2keBv8u5y/4GWqNow2OeAOl0feD9vnQlh7LSvxs4Hfo2aBFXqm+5gmfJm /dmQ==
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; bh=vgmJnvg2zZYGyuTBcLOVYrENiSXg4jx3qCMTwhz3UEE=; b=V53/9cxmlIRz3rbSrehu4Ks8jVhH4Iu7p5L3vQgbTYMdaGp01zN7sVBxe9zszNFc49 yiO1GyAosDJxD7q0Eguk6wuvlRrjd+JXEIvMYEZ/ajdxerarsPa65WMX6zTazE3Ewxn9 OcTjdqgPxLD7z8W1x6VVU2YjYgvjRvxyiaa1g9y9C0FIod3R9nosTh5JRFJo6UGMut3u 91xd71jeXQFPbjZQD3DiZuaDLi82DbR314/nuliJo40I/oQvOX4JblzGwCkXHplOpX6h k+Mp4eTOmQP8GAbISmEG0OV2We2hZL+jwqcyB06ak0myLauDBtCwEWaoRmpe0wpvyntn 6aMQ==
X-Gm-Message-State: APjAAAU95HSY6ooeoeZLyAwG4boDpDs/VhXe1xI6y5JuSJz1aUtp3kjj 0yObJNHbGyOruMyzLSED0wR2RbKTgjgV83tdhzQ=
X-Google-Smtp-Source: APXvYqxCJMS5xL5MmI7/ThSUhm+/2y9rXMXiBYsTrJZcMTlDdevrO3VHiDzyuiHhBRwXiwOsXTGbtgPBvtRxGwlReHg=
X-Received: by 2002:aca:2211:: with SMTP id b17mr4175021oic.38.1571915596234; Thu, 24 Oct 2019 04:13:16 -0700 (PDT)
MIME-Version: 1.0
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <CAO42Z2x7vudujw5t++obry56g=VNjQXXTHFK8pBPk0jmk78Bcg@mail.gmail.com> <CAJoHkZ8pTjszP0vw4BjX0HUhmPa6wJONzdy2JEm5iqAfBUvjRg@mail.gmail.com> <CAO42Z2wCYi4KWTEz1hUSPVr9+hu8GaHRkPuvQQ2P00knvnPaaQ@mail.gmail.com> <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org>
In-Reply-To: <848BA3B3-36B4-4C42-86D0-88759BC45D5A@employees.org>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 24 Oct 2019 22:13:05 +1100
Message-ID: <CAO42Z2xpJo1CxmtmnT863dfxJqAe2N2ypnF_umFPN_k+1Zv+mA@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Trevor Warwick <twarwick@gmail.com>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb041b0595a61e43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YmQvgHBH-GyMFgUC2ryav-ASzDE>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Oct 2019 11:13:26 -0000

On Thu, 24 Oct 2019, 21:47 Ole Troan, <otroan@employees.org> wrote:

> Mark,
>
> Right. Instant/flash renumbering is not supported in IP networks.
> IPv6 does nothing to help with this, well, assuming a network hiding
> behind NAT, it makes it harder.
> Apart from "does not work", what more can the IETF say or do here?
>

I think the issue could be not real knowing or thinking about any
alternatives and not knowing that while it may have been possible to
continue to follow the dial up model for IPv4 with NAT, that model can't be
stretched to accommodate IPv6 and delegated prefixes without causing the
issues in the draft.

So an Informational RFC?



> Cheers,
> Ole
>
> > On 24 Oct 2019, at 12:43, Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> >
> >
> > On Thu, 24 Oct 2019, 20:59 Trevor Warwick, <twarwick@gmail.com> wrote:
> >
> > On Thu, 24 Oct 2019 at 09:18, Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> >
> > I thought about this in the exact context of the scenario of this draft.
> Although the design of the broadband deployment I worked on always planned
> to give out stable prefixes, I worked through this scenario and realised
> that so many complex issues disappear if you provide stable prefixes.
> >
> > Fundamentally, if an ISP is selling an always on link to the same
> location, then the addressing should be as permanent as the link delivery
> location is.
> >
> >
> > If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes,
> what are the possible scenarios if you don't try hard to keep the prefixes
> stable?
> >
> > Why don't you want to try hard? Not trying hard gives customers a bad
> experience. They're paying you to try hard to give them the best suitable
> service you can give them.
> >
> >
> > - You could be running a closed environment where all customers are
> forced to use your CPE, in which case you can make sure that your CPE has
> various   hacks added to try to cope with prefix instability and avoid
> customer hosts experiencing connectivity issues when prefixes change. Maybe
> you can make this work well enough, and advanced customers who don't want
> to use your CPE are just out of luck.
> >
> > - If you're in an environment where customers can chose their own CPE,
> then it seems almost guaranteed that there will be connectivity problems
> when the prefix changes, because many CPE implementations don't handle this
> situation at all. So you're then relying on hosts falling back seamlessly
> to IPv4, in order to continue to have connectivity. In which case, I'd
> wonder why you're bothering to provide an IPv6 service in the first place.
> >
> > See what I said about selling an always on service to a fixed location,
> and the addressing having the same amount of stability as the service and
> link itself.
> >
> > The reason this problem really exists is that ISPs have fundamentally
> continued to treat residential, always on broadband customers although they
> were still dial up customers. Nothing has changed - per BRAS (NAS) IP
> address pools, pool route aggregation at the router, customer gets a single
> IPv4 address when they attach, that can change each time they attach. PPPoE
> is making Ethernet connectivity resemble dial up connectivity.
> >
> > Now this dial up model is trying to be applied to semi-permanent IPv6
> services, where it's even less applicable now that customers get their own
> routed address space on a semi-permanent link.
> >
> > Treat all customers as routed subnet SOHO customers, so they get the
> same prefix regardless of which BRAS they attach to. Move the route
> aggregation boundary to a higher level to e.g. a cluster of BRASes, or a
> region.
> >
> > Use an IPv6 address provisioning model that suites and matches the
> service they're paying for, not a nearly 30 year old dial up model.
> >
> > If your customers can BYO their CPE, then stable prefixes are the only
> choice.
> >
> > See slide 6.
> >
> > Residential IPv6 CPE - What Not to Do and Other Observations
> >
> https://www.slideshare.net/mobile/markzzzsmith/residential-ipv6-cpe-what-not-to-do-and-other-observations
> >
> >
> >
> >
> > I do think this is an important problem that needs to be solved, for
> this context and the others mentioned in the draft.
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>