Re: [v6ops] draft-lmhp-v6ops-transition-comparison-06

[Alexandre Petrescu <[e-mail]>]

Le 26/03/2021 à 16:42, JORDI PALET MARTINEZ a écrit :
> 
> 
> 
>      Le 26/03/2021 à 16:12, JORDI PALET MARTINEZ a écrit :
>      >
>      >> So, the car can always contact the PC server. There is no need for
>      >> any transition mechanism in this scenario.
>      >
>      > But how the PC gets an IPv6 address through the Ethernet on the IoT
>      > Router that connects on 4G?  The 4G only gives it a /64.  The IoT
>      > Router does not implement clatd etc.
>      >
>      > -> The 4G devices today, allow /64 prefix sharing,
> 
>      Only smartphones Android and iOS allow for /64 prefix sharing.  They
>      promote that functionality in an app.
> 
>      Other IoT routers on 4G dont do that.
> 
> -> They are broken then - complain to the vendor, 

How can I complain to a vendor of not implementing '64hare' which is an 
INFORMATIONAL RFC?

Either make the RFC Stds Track or not try to put it on the list of 
absolute requirements for a device...

>      > It is not blocked by "hardware" but may be by
>      > baseband modem firmware.
> 
>      'is not' on one hand and 'may' on the other hand - I can only agree with
>      you, but there is something missing.
> 
>      That is the situation right now.
> 
> -> IETF is not the place to resolve buggy implementations, only complaining to vendors will resolve it, and ultimately, finding alternative suppliers.

We will not resolve buggy implementations here.

We will continue to stale.

> 
>      >> One example of this was, a few years ago, the contract awarded to
>      >> Telefónica for 53 millions of gas and electricity meters in UK,
>      >> worth 1.5 billion pounds in 15 years, using cellular and 6LOWPAN.
>      >> If they have done it with IPv4, they will have needed 34 million
>      >> NATs, according to their own calculations.
>      >
>      > The IoT devices that I acquire on the market dont do 6lowpan.  There
>      > are indeed many 6lowpan devices but there are also many other IoT
>      > devices that connect on 4G, have Bluetooth/WiFi/Ethernet/Galileo and
>      > yet dont do 6lowpan.
>      >
>      > -> Those devices don't deserve the right to be called IoT then. A
>      > real IoT devices must have IPv6 support.
> 
>      Ah?  DO you mean that an IoT device on the market that does not do
>      6lowpan or does not do IPv6 can not be called IoT?
> 
>      This might go very far, but should be considered.
> 
> -> From the perspective of IETF, technically we could document it. However, the problem is more a marketing advise. Most of the companies selling all kind of cheap sensors, just don't care, they will keep calling "IoT" to any crap hardware, even if is not IP enabled at all (I've seen RF-only sensors being called IoT sensors ...).

Might be to say IoT sensors are just the RF-only devices.

But how about 'IoT Routers'?

We propose the definition of an 'IoT Router' to be this:
>    IoT Router - a device of class IoT.  It has several wired and
>    wireless interfaces.  One wireless interface is of type cellular,
>    like 4G or 5G.  This cellular interface is egress.  The other
>    interfaces are ingress.  There are at least two ingress interfaces.
>    There is at least one set of two interfaces that can not be bridged
>    together, for example 802.11b and Bluetooth.  If all ingress
>    interfaces in the IoT Router can be bridged, for example 802.11b and
>    Ethernet, then there is at least one other router in the same local
>    network as the IoT Router, that can not be bridged to this IoT
>    Router.  The IoT Router needs more than one /64 prefix.  An example
>    of IoT Router is Sierra Wirelss mangOH Red, or Maestro Wireless E220.


> 
>      >> https://www.google.com/search?q=telefonica+awarded+uk+meters
>      >>
>      >> Now, if you want to make it more complex, and you really need to
>      >> keep IPv4 incoming connections, you can still configure the NAT64
>      >> for that, either for specific ports or addresses. However, as said,
>      >> it doesn't make sense to use IPv4 for new deployments of
>      >> "anything".
>      >
>      > If I _have_ to do NAT, then NAT44 is largely sufficient.  There is
>      > no need for v4-v6 transition mechanisms (I mean not in these trials
>      > I consider).
>      >
>      > -> It is utopic to believe that NAT44 will keep scaling ...
> 
>      I can agree that in the long term NAT44 might not scale, but I can also
>      agree that NAT64 wouldnt scale either.
> 
> -> NAT64 scales if we continue "real" IPv6 deployment *because* it means that you use less and less NAT64 translations, so less IPv4 addresses required on the NAT64 Internet-facing interfaces. The nice think about 464XLAT is that you "drop" IPv4 in a natural way, just passing the time, nothing to be done. When you do IPv6-only deployments (with IPv4aaS) in ISPs, you suddenly see (at least in residential networks) 75%-85% of the traffic being IPv6-only end-to-end.

Hmmm, thinking abou tit.

Alex

> 
>      Yes, let us do IPv6, unless one calls IPv6 the IPv4+translation :-)
> 
>      Alex
> 
>      >
>      >
>      >
>      >
>      >
>      > ********************************************** IPv4 is over Are you
>      > ready for the new Internet ? http://www.theipv6company.com The IPv6
>      > Company
>      >
>      > This electronic message contains information which may be privileged
>      > or confidential. The information is intended to be for the exclusive
>      > use of the individual(s) named above and further non-explicilty
>      > authorized disclosure, copying, distribution or use of the contents
>      > of this information, even if partially, including attached files, is
>      > strictly prohibited and will be considered a criminal offense. If you
>      > are not the intended recipient be aware that any disclosure, copying,
>      > distribution or use of the contents of this information, even if
>      > partially, including attached files, is strictly prohibited, will be
>      > considered a criminal offense, so you must reply to the original
>      > sender to inform about this communication and delete it.
>      >
>      >
>      >
>      > _______________________________________________ v6ops mailing list
>      > [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>      >
> 
>      _______________________________________________
>      v6ops mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>