Re: [v6ops] Implementation Status of PREF64

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Owen


> 
> 
> 
>> On Oct 13, 2021, at 13:08 , Pascal Thubert (pthubert) <pthubert=[e-mail]> wrote:
>> 
>> Hello Owen 
>> 
>> The thing of the past is probably still perfect in some unmanaged networks but I understand that your focus is not those.
>> 
>> /64 came with neatly with EUI 64 as you point out, and we are deprecating that for privacy. 
> 
> Yes, but we’re choosing a new form of 64-bit random number to take its place, so from my perspective, it’s still basically
> a form of EUI-64 addressing even though not based on the actual MAC address.
> 
>> Switching better than routing in the domain we call a subnet is also becoming obsolete since even when we think we switch we probably route at L2 or in an underlay.
> 
> I guess that depends on how you define “L2 routing”. My definition is of routing involves deprecating the hop count (TTL in v4) and replacing the L2 headers. Forwarding
> at L2 is (mostly) one of repeating or bridging (which usually called switching due to differences in hardware between modern switches and traditional bridges). Repeating
> is what happened in old UTP hubs and even older DELNI boxes.

Yes terminology… for your points above routing is preferable and that’s exactly what I m getting at. Then there’s the major hassle of the broadcast domain. I take it that we agree and move on.

> 
>> Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to that’s exactly my pevery host just to be able to route inside the subnet at L2. 
> 
> Need is an interesting thing, but I don’t think it’s particularly relevant. I think the true question is what is useful to do and doesn’t pose an undue threat to addressing in the process. I think /64 meets that test.
> 
> Depending on your definition of “need”, we could claim that each device only needs one address behind which it can nat everything else on the device or behind the device and use ULA there. That’s not the model of IPv6 I want to see deployed, but if you push the bare-bones need argument far enough, that’s where you end up.
> 
> I’d much rather see us do reasonable addressing, issuing reasonable subnets (/64 seems perfectly fine to me) and one on.

I’m totally happy with /64 subnet. Then there’s the terminology again and old concepts that make little sense. What do we call a subnet today ?  I like to consider it as an administrative group with the main property that you do not need to renumber as long as your mobility is between routers that serve that group. Other property is that it is the final aggregation that the infrastructure serves. 

With a definition like this it is possible to assign any portion of the address space to the nodes, as long as we prevent overlap. E.g. assign one or more /96 to Calico to map IPv4 10.0.0.0/8 Private Spaces in a cloud server.

 To partition a subnet in any fashion we like we need routing inside the subnet. And DHCP PD could be a tool to get there.

> 
>> We can easily route to /112 or even to /128. I’m used to the latter because we build subnets of thousands of nodes in IoT and we know the nodes from a registrar, typically DHCPv6. But I see benefits of giving a prefix to the phone or the PC and let it distribute the addresses to stuff like VMs and tethered nodes.
> 
> Meh. If that works for you in your environment, more power to you.
> 
>> Why insist on /64 per host? Seems to me that the properties that we want do not depend much on where we cut.
> 
> I’m not insisting on any particular size in any given network’s implementation. I am insisting that we don’t put silly limits on what people can do because someone has a misguided fear of running out of prefixes.

I guess we agree. I wish to give more power to netops to do what they want inside their subnet. Forcing a single broadcast domain and only /128 is incredibly restrictive and totally decoupled from modern needs.

> 
>> What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100) per host gives you all that.
> 
> Why would we want it?
> 

Real world exemple: 

Say I have a large campus, with WiFi coverage throughout. Say I want to move around with no renumbering. Say that when I print I want the printer to be the one in my room wherever I am in the campus.

The traditional IPv4 approach is the get an address from the subnet that is served by the AP that you connected to when you entered the campus and tunnel there when you move beyond the small area covered by the subnet. Meaning that your broadcast domain remains that small area and your prints will always get there.

With IPv6 a subnet could easily span the campus, but the broadcast domain could not. Ideally the node would see:

- a broadcast domain with mDNS devices such as the printer down the corridor. This means limited to one open space or a few smaller rooms

- an IP link to the routers that serve the broadcast domain. The box that we call an AP could easily serve as router and/or ND routing proxy (RFC 8929) within the subnet (call it a L3 AP just like your switch is probably an L3 switch).

- An IP subnet that has enough capacity to serve the whole campus.

We could easily be providing all this to our customers but we’re not. We prefer sterile discussions at 6MAN or NANOG and the consequence of our inaction is that they keep deploying  IPv6 as if it was IPv4 with little to no evolution/ benefit. And we complain for the lack of adoption!

Please, peace: we have 20 years of experience that a discussion for the sake of discussing does not get us anywhere. Could we for once work on an acceptable trade off?

Your point: our common customers want one state per device because state is expensive. They do not want uncontrolled address allocation and silent nodes that come with it. They have that with IPv4 do not want to loose that going v6. I share that view and observe the same thing.

Also: They do not want broadcast storms that clog their bandwidth, waste energy and spectrum. They want to scale to a campus or a factory without renumbering.  They want simple (flat) networks as opposed to the tunnels above. They want service for the end users, e.g., the nearest printer.

Looking for a consensus:

You want to assign/128 to the host and defend the case of the use of DHCP in the managed subnet.

Lorenzo does not want /128 to the host but agrees with DHCP PD.

Gert wants to avoid the waste of address space just because we can. 

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?

Pascal 

> Owen
> 
>> 
>> 
>> Regards,
>> 
>> Pascal
>> 
>>>> Le 13 oct. 2021 à 19:26, Owen DeLong <owen=[e-mail]> a écrit :
>>> 
>>> 
>>> 
>>>> On Oct 13, 2021, at 09:58 , Gert Doering <[e-mail]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On Tue, Oct 12, 2021 at 12:39:43PM -0700, Owen DeLong wrote:
>>>>>> (ceterum censeo, /64 was not a very smart decision)
>>>>> We can agree to disagree. So far, I???ve seen no data to support that.
>>>> 
>>>> Indeed.
>>>> 
>>>> So far I have not seen any data that supports "/64 was a good idea" :-)
>>> 
>>> It’s working quite well in a number of networks I’ve deployed.
>>> 
>>> It’s convenient for EUI-64 addressing.
>>> 
>>> Reviewing the record, it seems we were destined for something like 64-bit
>>> addressing overall before IETF decided to consider EUI-64 addressing and
>>> added 64-bits to the plan, so one can argue that without the idea of
>>> universal /64 addressing we’d have a whole lot fewer network numbers
>>> available.
>>> 
>>> So now you have seen data to suggest that /64 was a good idea.
>>> 
>>> Do you have any data support your claim that /64 was not?
>>> 
>>> Owen
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>