Re: [v6ops] "Getting IPv6 Private Addressing Right" AusNOG presentation

[Alexandre Petrescu <[e-mail]>]

Le 18/09/2019 à 02:38, Mark Smith a écrit :
> 
> 
> On Tue, 17 Sep 2019, 23:36 Alexandre Petrescu, 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
>     Le 17/09/2019 à 15:30, Gert Doering a écrit :
>      > Hi,
>      >
>      > On Tue, Sep 17, 2019 at 03:22:13PM +0200, Alexandre Petrescu wrote:
>      >> One cant share such a /64 to a downstream WiFi and a downstream
>      >> 802.11-OCB because they are not precisely the same LLC, and they
>     cant be
>      >> bridged.  (same problem with downstream Ethernet and Bluetooth,
>     Ethernet
>      >> and USB, and many others).
>      >
>      > Sure you can... ND proxy, etc.
> 
>     ND proxy, or lack of it on IoT Router, has other inconvenients and
>     advantages that we could discuss.
> 
>      > I didn't say "bridge" on purpose
> 
>     I see, I agree that word was missing from what you said, so I should
>     have assumed you thought rather ND proxy or other non L2 bridging.
> 
>     Remark neither 64share nor ND proxy are Standards.
> 
> 
> I contributed to 64share because I thought it was good to have some of 
> these options written down.
> 
> The trouble with it is that it's trying to be half way between full 
> routing between interfaces and bridging between interfaces. That doesn't 
> really fit with our models and protocols, which is why it has issues.
> 
> It's no more than a workaround.

I think we can write down like that in the draft, if you do not mind.

> 
> DHCPv6-PD is the proper solution, however the real issue is caused by 
> how 3GPP do entire device version number snapshots.

I did not know 3GPP specs were oriented more towards device, whereas I 
agree IETF specs are more protocol oriented, with ends of protocols.

>  From the RFC Intro:
> 
> "3GPP mobile cellular networks such as Global System for Mobile
>     Communications (GSM), Universal Mobile Telecommunications System
>     (UMTS), and Long Term Evolution (LTE) have architectural support for
>     IPv6 [RFC6459], but only 3GPP Release-10 and onwards of the 3GPP
>     specification [TS.23401] supports DHCPv6 Prefix Delegation [RFC3633]
>     for delegating IPv6 prefixes to a single LAN link."

I agree.  This TS23401 spec from June 2019 says "The UE uses DHCPv6 to 
request additional IPv6 prefixes (i.e. prefixes in addition to the 
default prefix)".

It is not yet the best way to do it (why two prefixes?), but it is a way 
forward.

Our implementation requests a /56 and makes several /64s.  One of those 
/64s could be used on the egress interface, but I do not see the 
necessity for a whole /64 on the egress.  The computer just needs one 
address on that interface.

> On a normal computer, if you want DHCPv6-PD support, you just install it 
> and try to use it. It generally works or it doesn't.
> 
> On a 3GPP "Smartphone", which is actually just a computer too with a 
> specific type of link-layer interface, you can't install new software to 
> give it a new network capability, because then it doesn't comply with 
> the 3GPP spec. it is supposed to.
> 
> The versioning model of 3GPP is whole of device, where as the IETF model 
> is per protocol. That means having to come up with non-IETF spec 
> compliant work arounds like 64share when there is a conflict in these 
> models.
> 
> It would be better if 3GPP started to think of smartphones as portable 
> personal computers that happen to be able to make phone calls, and 
> allowed them to follow the more discrete and incremental protocol 
> version model.

I agree.

Alex

> 
> As that industry has more than a century of think of devices in 
> end-users hands as voice devices first, and anything else as an add on 
> (like running non-voice apps), I'm not sure we'll ever see them change 
> from this versioning model.
> 
> Regards,
> Mark.
> 
> 
>     Alex
> 
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>