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

If both end-sites have IPv6 support, the IPv6 addresses will be reachable.

In your example you mention that the PC server is dual-stacked (it can be IPv6-only), and the car can be either dual-stacked or IPv6-only. So, the car can always contact the PC server. There is no need for any transition mechanism in this scenario.

What it doesn't make any sense in today's world is to do this deployment with IPv4-only in any of the sides. That's a negation of the reality: IoT with IPv4 (and in general any new deployment with IPv4) doesn't make any sense.

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.

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".

Regards,
Jordi
@jordipalet

El 26/3/21 7:04, "v6ops en nombre de Alexandre Petrescu" <v6ops-bounces@ietf.org en nombre de alexandre.petrescu@gmail.com> escribió:

    Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
    > Dear Alex,
    > 
    > On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]
    >> Does IPv6 mandate the use of DNS64 and NAT64?
    > 
    > Of course, not. :)
    > 
    > There are several IPv4 as a Services solutions exist. We have covered
    >  the five most prominent ones 464XLAT, DS-Lite, MAP-E, MAP-T and
    > lw4o6 in our I-D: 
    > https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-06

    I looked at it.

    There is a need to illustrate also a drawback in 464XLAT/DNS64 in
    cellular operator networks: they can be used to offer an IPv6 address to
    a smartphone and the smartphone to browse IPv4 sites.

    But they cant be used to offer an IPv6 address to a server behind an IoT
    router and be reachable from another IPv6 client in the Internet.

    The result of that impossibility is that IPv4 with port translation (but
    not PCP) is preferred in such a setting, instead of IPv6.  It is not a
    happy situation.

    The use-case is the following: in a street deployment a traffic lights
    controller controls the traffic lights.  This controller is a PC with
    Ethernet interface, linux, IPv6 and IPv4 stacks.  The car needs to know
    the status of the color (red/green, time left, etc.)  The car tries to
    http to that PC Server.  The PC needs to connect to the Internet via a
    cellular network operator.  An IoT router (4G and Ethernet small router,
    linux, IPv4, IPv6) is thus plugged on the PC.  The cellular network
    operator offers a /64, and also NAT64/DNS64 to those who need it.

    In trying to identify where in the draft could this be already
    explained, I found section "4.3.  Support for Public Server Operation".
      But I think that section does not really explain my problem.

    Alex

    > 
    > Your ISP is likely using one of them.
    > 
    > Best regards,
    > 
    > Gábor
    > 
    > _______________________________________________ v6ops mailing list 
    > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    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.