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

Mark Smith <> Thu, 24 October 2019 10:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C2591200CC for <>; Thu, 24 Oct 2019 03:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6D3_xE6q0nW3 for <>; Thu, 24 Oct 2019 03:43:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4EEB1200B5 for <>; Thu, 24 Oct 2019 03:43:54 -0700 (PDT)
Received: by with SMTP id 83so20204419oii.1 for <>; Thu, 24 Oct 2019 03:43:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JA3SgdNu8WqMWlN4MhDuuAbWDyD1Wlu2MX2043PrKP0=; b=E3Gtg//dLb+E6xqTFpcXb3ilmUI1iueKwGvT+tbMQ8XtlcbVz8NzKHYsWN+EJZ33I6 lCVEl5fU1jhFaEXhhVheAx+cdBnKgs96VHGn9UnCsz3v2jO+PBNbkENiMYq8BHhLGyte bIyCWQXb59fitFacPiBzOWmaXtLU9fsccx29pIsGXz/3tddimtktb5iOrWIVwKjE7im+ 3j6EyarDrZljZa0UujSXkVkNFGVsDZJK7ePaEtlDnVePPN2qsY3zRIRIkCnlGl+YQAdW pL1iLSwtdMvtN3gH2OndyiT12YsSCx7A/T8OeMCIPLBNbQG9Rg2jjEdGr6A6/R1PS0wD HJ6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JA3SgdNu8WqMWlN4MhDuuAbWDyD1Wlu2MX2043PrKP0=; b=j3sD6LGQA3oXtFiMFm0fhL97TJon09Mq9nRfGDLC/NgK/TagbZ4pTZ5NdFbJQaURc/ 2Z5lNMIxVuSH5+I8TGtluTglo+sO3ZN1CjSuzBJCn6f8IjJdGbjOU69tfkcSHSrcUxCy RSBSjgJ8fV1vZXdQhHJZ4oO3s46KjrbxjDnbRwHOq3zuGbAx9bqHeiEjGJc+GWl6dhTr GYyHue0e5t75oy4zcNMzv+1jIloGstsQI2KY+bDjAvKouV4jhN9i77uCw+8ee9CQu+Il +seMlxB136QBqv/xPrE0+dyq0INYcfCXNCS5ic1ihNZHfvyXGw4TewG1dpmK19/if5Pp JDgg==
X-Gm-Message-State: APjAAAUKFmleffsrkRogeBOqac8w8iv/nD/fXXzGIqOCXY2iRyFDolzp +YJ3GyeXXfbT6lgW3teZU2g7Xc8yAeFkqeSGDjY=
X-Google-Smtp-Source: APXvYqxKbDYhRxfMo8SjmHpXhLRFhB4QhhHHugv0EcC/YQ1o8xLbv7j+oSKfkYDI1PPE9QIin7vbjV+4UHpLrrd3ypI=
X-Received: by 2002:a54:4198:: with SMTP id 24mr3833704oiy.164.1571913834129; Thu, 24 Oct 2019 03:43:54 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Thu, 24 Oct 2019 21:43:43 +1100
Message-ID: <>
To: Trevor Warwick <>
Cc: v6ops list <>
Content-Type: multipart/alternative; boundary="000000000000b36bfa0595a5b505"
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 10:43:56 -0000

On Thu, 24 Oct 2019, 20:59 Trevor Warwick, <> wrote:

> On Thu, 24 Oct 2019 at 09:18, Mark Smith <> 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

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

See slide 6.

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