Re: [v6ops] reclassify 464XLAT as standard instead of info

[Ca By <[e-mail]>]

On Fri, Sep 22, 2017 at 5:45 AM Rajiv Asati (rajiva) <[e-mail]>
wrote:

>
> I don't think that there any iOS app that is not IPv6-only compatible
> (since the apple AppStore mandate more than a year* ago). Is there one ?
>

I am simply here to disabuse you of the notion that this rule has been
perfect for the folks involved.


> If Google playstore could mandate something similar (perhaps, there is one
> that I am not aware of), then almost all mobile UEs can happily live with v6-only
> without any Clat function.  Better battery life, likely.
>

Fully agree. What if Google playstore cannot / will not enforce such a rule
?  We in v6ops / sunset4  are well aware that asking for a poney seldom
results in a poney .... hence warty solutions that thread one needle to
move another needle. Putting the E back into IETF.


> Hence, There is no need for XLAT being a BCP at this time in that regard.
>
> Of course, NAT64 inside the network would still be needed to accommodate
> the smaller  (% of traffic) v4-only internet connectivity. But that's an
> ongoing saga of another debate.
>
>
>
> However, there is one exception - tethering ::
>

Ah. What little control we have.


if mobile UE is tethered and the other devices connecting to its W/LAN are
> stuck in legacy v4-only, then mobile ISPs might prefer to not leave them
> behind to ensure customer experience. What "technical" options do we have
> then? Well, really two == Let go of v6-only access (provide an IPv4-only
> APN if tethering is enabled resulting in a dual-stack UE) or stick with
> v6-only access, but turn on CLAT function !!
>
> Cheers,
> Rajiv
>
>
> * https://developer.apple.com/support/ipv6/
>
>
> On Sep 22, 2017, at 8:22 AM, Gert Doering <[e-mail]> wrote:
>
> Hi,
>
>
>
> On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote:
>
> On 22 Sep 2017, at 13:48, Gert Doering <[e-mail]> wrote:
>
> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote:
>
> IPv6 applications need to add code to WORKAROUND breakages caused
>
> by NAT64 the way they need add WORKAROUNDS for the NAT breakages
>
> even if they are not using NAT64 or NAT respectively.  The cancer
>
> that is NAT64 needs to be eradicated.
>
>
> It will nicely go away if all endpoints are reachable over v6.
>
>
> I think that?fs the concern. That it will not.
>
> IPv6 applications will have code to accommodate for NAT64 forever.
>
>
> Yeah, but you can't have the cake and eat it.  Either we go v6-only
> everywhere, or we keep running IPv4 everywhere until everybody else
> is done, or we introduce v4/v6 NATs, or we add a CLAT to every single
> operating system out there.
>
> What's it gonna be, boys?
>
> (Oh, "or we give up, roll back existing v6 deployments, and live happy
> with v4 nat forever".  FAR less work, and for Joe Average User, it won't
> make a difference.  Facebook and Youtube will continue to work, and
> their IoT devices will keep drilling holes into firewalls to ensure that
> they can be exploited no matter what)
>
>
>
> Gert Doering
>        -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: [phone]           USt-IdNr.: DE813185279
>
> _______________________________________________
>
>
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>