Re: [v6ops] Implementation Status of PREF64

Owen DeLong <> Sat, 16 October 2021 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7CDB3A0A1E for <>; Sat, 16 Oct 2021 00:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5X5rc-BevZGP for <>; Sat, 16 Oct 2021 00:32:31 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 12AE03A0A22 for <>; Sat, 16 Oct 2021 00:32:30 -0700 (PDT)
Received: from ([IPv6:2001:470:496b:0:5973:e987:1d7e:88d5]) (authenticated bits=0) by (8.16.1/8.15.2) with ESMTPSA id 19G7W56c1147943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Oct 2021 00:32:06 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 19G7W56c1147943
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1634369531; bh=A0KQ+5JSMeEcPZl2IKfQOPWUR58ZQhkWvdofax4C0nE=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=kwQraU8BGC8AFM5mPNsyFcW+xAZMIIrbFBfOZRck4k4XZB/UHSby393ShOylwg87I OW8sUgupbNCR5y98JQwVmxP8ZkZVNNKJaMj2buLxCEkUOPyxR/5hMTDrhu44X727eB 3Xm2YxmBMotLv6dLZaIMyBOvLLMU82tvegq+mCG4=
From: Owen DeLong <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C3AF62EC-E372-4B65-BFDB-68122F0D2987"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Sat, 16 Oct 2021 00:31:46 -0700
In-Reply-To: <>
Cc: Ole Troan <>, "Pascal Thubert (pthubert)" <>, IPv6 Ops WG <>, Owen DeLong <>
To: Ted Lemon <>
References: <> <> <>
X-Mailer: Apple Mail (2.3654.
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 ( [IPv6:2620:0:930:0:0:0:200:2]); Sat, 16 Oct 2021 00:32:11 -0700 (PDT)
Archived-At: <>
Subject: Re: [v6ops] Implementation Status of PREF64
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: Sat, 16 Oct 2021 07:32:36 -0000

> That said, we're comparing apples to oranges here. On a home network, the operator is /never/ going to configure DHCPv6. Sure, there are people here who would, but they don't have a home network—they have a managed network that is in their home. So yes, they would need a /56 or maybe even a /48 (but probably not).

I wouldn’t say “never” here. The average home operator may not configure, but commonly uses and many home operators do configure DHCPv4. I see no reason to expect that there won’t eventually be home IPv6 CPE with extended capabilities that don’t fit in SLAAC and require at least the O bit DHCPv6 if not full M-bit implementation.

> On my home network, I just use SLAAC, and there's no problem. My Thread network also does SLAAC (or whatever the Thread mesh does—I don't really know, but definitely not DHCPv6).

I use SLAAC for some of the subnets in my home and it works fine for those purposes. I have some subnets where I want t assign persistent, predictable, memorable addresses to some devices. I have some devices that need information like boot files, NTP servers, etc. For those cases, I do use DHCPv6 on those subnets and they are running without A and with M+O bits.

> So what other networks besides home networks are limited to a /56?

Some (really annoying, are you listening Comcast) Cable MSOs provide a /60 to residential and /56 to SMB.


> On Thu, Oct 14, 2021 at 3:07 PM Ole Troan < <>> wrote:
>> On 14 Oct 2021, at 19:11, Ted Lemon < <>> wrote:
>> On Thu, Oct 14, 2021 at 2:56 AM Pascal Thubert (pthubert) < <>> wrote:
>> A prefix to the host gives Lorenzo the addresses he needs for his devices.  It gives your customers the single state per logical node that they want. It allows to separate what netops manage (down to /64 and direct assignment within) and devops (whatever they do with the longer prefix they get for their node). It does not impose any size for what’s assigned, could be a different thing for each host. It means routing inside the subnet which removes the dreadful broadcast domain.
>> I see an opportunity for consensus. Can we work that out together and bring a real IPv6 value?
>> If your proposal is that we use a /64 per host as a way to meet these needs, I agree. This solves everybody's actual problems. There is the issue that some people have expressed a preference for prefixes wider than 64 bits, but this is a preference—there's no technical reason to do this. It's not wrong to have preferences, but it would be nice if we could somehow finally put this discussion to bed.
> Limiting networks that are assigned a /56 to only 256 logical nodes is a non starter. 
> O. 
> _______________________________________________
> v6ops mailing list