In message <65D79ACB-372A-4978-9030-FFAB4967A2BD@xxxxxxxxxxxxxx>, JORDI PALET M ARTINEZ writes: > Hi Med, > > In line â?¦ > > Saludos, > Jordi > > > -----Mensaje original----- > De: ietf <ietf-bounces@xxxxxxxx> en nombre de > <mohamed.boucadair@xxxxxxxxxx> > Responder a: <mohamed.boucadair@xxxxxxxxxx> > Fecha: martes, 1 de agosto de 2017, 8:07 > Para: "jordi.palet@xxxxxxxxxxxxxx" <jordi.palet@xxxxxxxxxxxxxx>, > "ietf@xxxxxxxx" <ietf@xxxxxxxx> > Asunto: RE: RESENDING - Incremental Deployment of IPv6-only Wi-Fi for > IETF Meetings > > Hi Jordi, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : ietf [mailto:ietf-bounces@xxxxxxxx] De la part de JORDI PALET > > MARTINEZ > > Envoyé : lundi 31 juillet 2017 23:18 > > Ã? : ietf@xxxxxxxx > > Objet : Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi > > for IETF Meetings > > > > NAT64 was invented for a specific case (when apps use DNS and the > > right APIs). > > [Med] This may be misinterpreted as there is a dependency of NAT64 on > DNS. This is not technically true. This was clarified in > https://tools.ietf.org/html/rfc6889 > > [Jordi] Right, I was not pretending to be technically perfect, but > introducing when NAT64 fails in our network. > > This approach is pragmatic in the sense that there is no dependency > on DNS implementation for the successful NAT handling. As long as > there is a function (e.g., DNS64 [RFC6147] or other means) that can > construct an IPv6-embedded IPv4 address with a pre-configured IPv6 > prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 > will work just fine. > > FWIW, there are even NAT64 deployments that do not even rely on > DNS64. > > [Jordi] Agree, we can talk about â??DNS64 functionâ?? instead of DNS64. > Again, in our IETF network there is a DNS64, so not the issue here. > > > > > We realized then that app/devices vendors are lazy, or just they > > are out of the market, so we invented 464XLAT, which uses the same > > concept as > > NAT64/DNS64, but improves it by using the CLAT, a small daemon code > > in the > > OS or the CPE to solve the problems of the literal addresses and > > non-APIs > > apps/devices. > > > > We donâ??t need to tell the customers to disable IPv4 in their LANs, > > we need > > to make sure that we deploy CPEs that support CLAT. > > [Med] Is there any CPE-based 464xlat deployment out there? > > [Jordi] Iâ??ve identified 4 vendors up to now, with different products > each. Iâ??m sure there are more. I also know that other vendors did the > development for specific customers and Iâ??m also aware of other customers > that asked for it. We have also the open source implementations, such as > OpenWRT, supporting thousands of devices. Precisely this is my point. As > IETF, our work is not just inventing transitions mechanism, but also > making sure that if we state a set of requirements for CPEs, we include > the support for those transition mechanisms. People ask for lots of things and even write code. That doesn't mean that the thing they ask for is actually good or there is not something better. This IETF should be recommending what is actually best. > > This way, users donâ??t > > need to throw away old devices or apps, neither learn anything > > about IPv4 > > or IPv6, and everybody is happy. > > > > We are trying to solve a problem with NAT64 which we knew > > since it was invented that it canâ??t be solved. We donâ??t have > > the time (unless some magic is discovered) to now tell every > > ISP that is deploying IPv6 and NAT64, to instead of NAT64 > > have something different. > > [Med] These operators (with CPEs) are already doing something > *different*: DS-Lite and the like. NAT64 is widely deployed in cellular > networks (host-based model), which is really straightforward. > > [Jordi] I agree, but if you have a network with cellular and wireline > access, you may want to have a single transition mechanisms instead of > two. If we donâ??t want to use NAT64 in wireline, then why we are trying to > push it as the default SSID in our IETF network? Because that's what everyone TALKS about. NAT64 was sexy. If we were being honest with ourselves we would do NAT64, then DS-Lite, then MAP at consecutive IETFs and release a recommendation for wireline deployments based off the experience or at least a report on the issues found. > It is a matter of > preference of one or another transition mechanisms. All them have good > and bad things. I see much simpler the combination of NAT64+CLAT than > DS-Lite or MAP, in addition to the ONLY support in cellular networks is > precisely NAT64/464XLAT, which means is the MOST extended transition > mechanism by millions (billions?) of users. It makes a lot of sense to me > to go in all the infrastructures to the one that has more deployment > already. Not really. Cellular networks went with anything available, rather than the best. We are continuing the pay the price for that. > > The solution is > > there, if CPE vendors implement it, and we are talking about an > > available > > open source code (several implementations) that take a few bytes. > > > > We are already doing this effort in v6ops, I started trying to tell > > the RFC7084 about the need to update it, but didnâ??t succeeded. It > > seems that now we may want to have instead of a CPE requirements > > including this, an additional document to be a must for CPE vendors > > to support it, in case the CPE expects â??IPv4 old devices and appsâ?? > > in the LANs (which is real world life, and will be for 3-5 years). > > [Med] I'm afraid we don't need it. The IETF already specified tools > to address that case (DS-Lite, MAP-E). > > [Jordi] I guess no need to repeat myself â?¦ > > > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: ietf <ietf-bounces@xxxxxxxx> en nombre de Ole Jacobsen > > <olejacobsen@xxxxxx> > > Responder a: Ole Jacobsen <olejacobsen@xxxxxx> > > Fecha: lunes, 31 de julio de 2017, 23:01 > > Para: Ted Lemon <mellon@xxxxxxxxx> > > CC: <ietf@xxxxxxxx> > > Asunto: Re: RESENDING - Incremental Deployment of IPv6-only Wi-Fi > for IETF > > Meetings > > > > > > You said: > > > > > > Brian, why on earth would we want to advertise IPv6 to IETF > > > attendees? We invented IPv6. If we really can't run a > v6-only > > > network at IETF, what that says is that we have failed > utterly and > > > expensively. I do not believe that this is correct: IPv6 > works very > > > well. > > > > Putting on my naive end-user hat: > > > > That might be true, but here is the thing: "The mission of the > IETF is > > to make the INTERNET work better..." (my emphasis) > > > > For at least a decade now, I've been told that I should "just > use > > IPv6" and some conferences have even "forced" me to do so. > > > > I always respond with this question: "Does running IPv6 allow > me to > > connect to the Internet?" (meaning the v4 Internet for the most > part). > > The answer always seems to be: "Yes, but you have to manually > > configure this and, oh by the way, this won't work at all and > that app > > might not behave as expected." > > > > Demonstrating this to people who are experts seems like a waste > > of time. > > > > So it sounds to me like we HAVE indeed failed utterly and > expensively. > > 99% of Internet users do not have any idea what version of IP > they are > > running just as they have no idea what a MAC address is or > why/if they > > should care. > > > > I'd love to see IPv6 succeed, but it is apparently impossible > to do so > > without teaching end-users a lot of stuff they really have no > interest > > in or ability to learn. What a shame. > > > > Ole > > > > > > > > > > > > ********************************************** > > 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. > > > > > > > > > > ********************************************** > 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. > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx