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