On 10/7/16, 6:27 AM, "sunset4 on behalf of JORDI PALET MARTINEZ" <[email protected] on behalf of [email protected]> wrote: >This is what I’m proposing. May be I miss explained it. > >NOT asking EVERY device in our network to HAVE 464XLAT client (CLAT), but having ONLY our “CPE” to have it. > >Nodes will not notice anything. > >This is what is going to happen in the future in most of the networks because they will not have IPv4 for every customer, so why not trying it ourselves? Already happening in many cellular networks, like in US, which are close to have 60% IPv6 traffic already. You think 464xlat is what's going to happen in the future in most networks? Mobile networks, yes, it's a primary transition mechanisms. Wi-fi networks operated by ISPs or enterprises are more likely to use NAT64, DS-Lite, or MAP, based on what I'm seeing people working on.
I disagree in several points: 1) 464XLAT is not only for cellular networks, just read the draft. 2) It has been implemented by some CPE vendors. It can be run in Virtual Machines as well. a. http://www.necat.co.jp/en/ipv6/index.html b. https://conference.apnic.net/__data/assets/pdf_file/0013/50701/34th_apnic_464xlat.pdf 3) I’ve tested it in several ISP network. Trials at the time being, but coming into production. 4) NAT64 is WORST than 464XLAT. NAT64 doesn’t sort out the problems for apps using literals. 464XLAT sort it out. Yes, NAT64 was developed first, but that’s the reason 464XLAT was needed, because not everything was working in NAT64. 5) If you don’t trust 464XLAT, then you can’t trust in NAT64, because is just an “incomplete” version of 464XLAT. I agree with you that DS-Lite and MAP are other choices, comparable with 464XLAT. They will be a better test, for sure than just NAT64. If you want something more lightweight than DS-Lite, probably will be better to use lw4o6. Just to make sure it has been understood: I’m not asking to implement anything in the clients of our network. Nobody needs to install anything. We just need to have a VM or a set of them if we don’t trust on the hardware performance, as the “CPE router” of the IETF SSIDs that we want to run this. This VM need to incorporate the CLAT client. Our network will behave as an enterprise network which as only IPv6 native connectivity to Internet, and the ISP (in this case our own network) will running the PLAT (NAT64/DNS64). If you still want to try the NAT64 one more, you can have the NAT64 SSID, that has been already tested in all the RIR meetings, etc. But this will not run any apps that use literals, old APIs, etc. My fear with 464xlat is that it's largely untested in environments like the IETF. I would not support making it the default SSID. We've had a NAT64 SSID for several years; it could be promoted to default, if we can demonstrate with confidence that everyone can still get their work done. ⇒ NAT64 as default is not and option. It breaks everything using literals. We want to have a good experience I guess, and be able to detect what will fail in the future (logging CLAT and NAT64/DNS64 usage), not break the IETF network. Lee > >Saludos, >Jordi > > >-----Mensaje original----- >De: sunset4 <[email protected]> en nombre de Philip Homburg <[email protected]> >Responder a: <[email protected]> >Fecha: viernes, 7 de octubre de 2016, 12:04 >Para: <[email protected]> >CC: "Bjoern A. Zeeb" <[email protected]> >Asunto: Re: [sunset4] Sunset4 work > > In your letter dated Thu, 06 Oct 2016 23:28:32 +0000 you wrote: > > Nastygram. So make the default IETF SSIDs IPv6-only or (+NAT64) > > if you want. Then have the ietf-legacy network, which would give > > you IPv4 and a portal page penalty that you have to state the nature > > why you have to use this network and cant live on the default one. > > Id be so curious to see what happens when people finally have to > > start thinking about it.. and open internal tickets .. It was > > great fun doing it 6-ish years ago, .. > > Personally, I consider offering NAT64 over wifi quite absurd. The obvious > way to provide access to legacy IPv4 is some form of NAT4. How it is > transported over the rest of the network is upto the network operator. But > the obvious interface is RFC 894. > > So on networks that promote NAT64 (FOSDEM has this setup for quite a number of > years now) I just connect to the legacy network. Their legacy network has > perfectly fine IPv6, so I consider it way better than the NAT64 that > 'everybody' likes to push. > > For the specific mobile weirdness, NAT64 make sense. But everywhere else, > requiring every device to have 464xlat to deal with IPv4 literals is just > bad engineering. If your backbone is IPv6-only, then the obvious solution > is to deal with this in CPEs, wifi access points, etc. Not to require all > hosts to know the details of your network. > > > _______________________________________________ > sunset4 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sunset4 > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >The IPv6 Company > >This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > >_______________________________________________ >sunset4 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sunset4 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
