Re: Extending a /64

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > b1) steal the uplink /64 (64share)

I don't know this term "64share"
Is there a draft to go with this, or is it just what I wrote in another email?
(onlink=false, plus Proxy-ND)

I wrote draft-richardson-6man-cpe-provisioning in 2019 based upon discussion
earlier.  There are too many TBD.

A few people from 6man had said that they would help, but we were all too
busy, and then pandemic.   I expected to chatting it up at meeting this year
in person.

The concept was that if we can do a capabilities negotiation/announcement
early enough (such as in IP6CP for PPP links), then we can avoid putting the
single /64 on the PPP link, but instead route all of it to the device.

That solves 90% of the smartphone has nothing to share, and probably solves
90% of the fixed LTE mobile use cases.
Yes, any ISP clueful enough to implement this could also implement DHCPv6-PD,
and perhaps that's really the point: it a bit of bait and switch on the clueless.

    > f) P2P Ethernet. Hosts are not on the same physical link, so let's stop
    > pretending they are. A consequence of that is that links don't need
    > subnets. Only assign addresses to
    > hosts. draft-troan-6man-p2p-ethernet-00

In the WiFi WPA3 world, every device gets their own WEP keys, and they can
never communicate without going through (hairpin) the AP.
So, WiFi now is totally hub and spoke.  There are significant performance
savings if we stop pretending L2 multicast really works.

This is where we should go.
This is a BIG DEAL, even though conceptually it's quite simple.
We need to make sure that we are not pushing string here though.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide