Re: I-D Action: draft-bourbaki-6man-classless-ipv6-06.txt

Le 19/04/2022 à 02:39, Lorenzo Colitti a écrit :
[...]
> endlessly extend the network by using NAT. IPv6 allows this too, but
> in a different way:

I agree too that it is good to let extend the network.

> because the address assignment unit is fixed at /64, and /64 always
> has enough room for more addresses, any network participant can
> extend the network by ensuring individual /128s are routed or bridged

Routed 'or' bridged?  Mostly bridged, I think.

I think the fixed /64 limit allows extension of the network mostly by 
bridging mechanisms, and less by routing mechanisms.

It is impossible to use simple IP routing to extend a /64 subnet any 
further.  One would need another /64 for that extension to work.

Routing individual /128s ('host-based' routing) might work, but might 
have certain inconvenients in the potentially large number of entries in 
a routing table - 2^64 ?

Besides, there is no particularly deployed protocol to insert these 
entries, as far as I know.  For example, SLAAC forms an address, but 
does not add an entry in others' routing tables for that address. 
RFC8987 "DHCPv6 PD relay _requirements_" (not solution) section 4.2 
'Routing Requirements' involves, er, DHCPv6, which, er, is not deployed 
where needed by this /64 parameter (cellular networks).

> within their network. If we remove the fixed boundary, then that is
> no longer possible

I agree that if the /64 limit were removed, or parameterized, as Brian 
said, then bridging at /64 would no longer be safe to assume to work. 
In particular, RFC7278 '64share' - a bridging technology - would no 
longer work, and android smartphones would no longer 'tether' 
meaningfully: a /64 subnet would not work if the host had a 65bit IID. 
Or, tethering was often a useful technology in extreme circumstances, 
such as crisis where ADSL o rfiber were disappearing.  One wouldnt want 
that tethering to stop working.

But there could be middle grounds.

Then, there is this 64sharev2, and a few other drafts.

Alex

> without sacrificing end-to-end connectivity which
> is a major improvement that IPv6 can provide over IPv4. I'm sure many
> others feel the same way, which is presumably why the draft did not
> progress the last time.
> 
> If the authors really intend this document to be about routing only,
>  they should ensure the text states that plainly. I'm sure it would
> be less controversial and more likely to gain consensus.
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------