[IPv6]Re: explaining to marketing why they have no IPv6 demand (Re: Re: IPv6 Milestone)

["Nathan Sherrard (nsherrar)" <[e-mail]>]

I want to echo Erik's comment upthread of "NPTv6 is nice but doesn't help when the prefix sizes don't match, and in some of these environments that is the reality."

This may be more of a v6ops point (like much of this thread), but the ultra-conservative nature of many ISP's in giving out DHCPv6-PD PA space really limits the usefulness of NPTv6 in practice.
I agree NPTv6 is preferable to NAPT66 in many ways, but for Enterprises (which again, I support, and feel are underrepresented here) who want to design a decent addressing plan it's almost a non-starter when given a /61 or even a /56 at a particular location.

Each site's addressing plan thus becomes either boutique (i.e., not scalable/manageable) or is limited to the least common denominator, which is almost certainly too small to be useful.
Thus, if an org. can't guarantee they'll have enough space on the provider side, it's easier/safer to fall back to NAPT66.

This is now more an RIR topic, but I don't see any reason ISP's shouldn’t acquire enough space for themselves to where they could hand out a /48 to every single customer site of theirs, regardless of market and size. 

[And although I'm primarily speaking business customers, the same logic could even hold true for residential as well. Sure, 2 billion households at /48 per household would require a /17 of space but that's less than 0.01% of current GUA allocation. Obviously I'm not saying home users would use the space in the same way an Enteprise would, I'm more just making the point for emphasis. ]

Handing out /56, /61 and /64 is hindering IPv6 adoption while saving negligible space.

Nathan

On  Thursday, May 7, 2026 1:04 PM, Sebastian Moeller <moeller0=[e-mail]> wrote:

Hi Michael,

On May 7, 2026 5:46:58 PM GMT+02:00, Michael Richardson <[e-mail]> wrote:
>
>Sebastian Moeller <moeller0=[e-mail]> wrote:
>    >> On 7. May 2026, at 06:49, Brian E Carpenter
>    >> <[e-mail]> wrote:
>    >>
>    >>> Since all flows are translated to a device-unique SRC address, return
>    >>> routing solves itself.
>    >>
>    >> And like it or not, with NPTv6 all flows are translated to a
>    >> device-unique SRC _prefix_, return routing solves itself. This is
>    >> better because it guarantees you can never run out of ports.
>
>    > [SM] Is port scarcity an issue with NAT66? given that one has 64bit
>    > space to assign one's own interface ID I do not see that happen. Sure
>    > NPTv6 is a nice optimisation, but conceptually it is just one of the
>    > cases covered by NAT66, no?
>
>NPTv6 is a win over NAPT66 because, as the IID is ideally not changed, 
>then the translation device needs no state.  That means it can probably 
>be done at multi-hundred Gb/s, not much harder than the routing.  Even 
>L2 MAC address lookup might be more expensive...

[SM] Fair points that I ignored with my mere enduser hat on...

>
>    >> Against this model, it doesn't really matter how hard you argue that
>    >> we'll solve multihoming without translation at some unknown future
>    >> date.
>
>    > [SM] OK, so if this is our consensus, an RFC would be helpful to
>    > document that.
>
>I reluctangly accept this.
>
>I still pine for SHIM6 :-)
>(Maybe I need a mock-funeral for SHIM6, so I can get closure..)

[SM] I am not a fan of the different NATs either and would prefer something else instead...

>
>
>
>
>
>
>--
>Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
>
>**       My working hours and your working hours may be different.         **
>** Please do not feel obligated to reply outside your normal working 
>hours **
>
>
>
>

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------