Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

["Heatley,N,Nick,TQB R" <[e-mail]>]

James,
Have you also ruled out the IPv6-only device performing the synthesis of an AAAA based on A itself? Remo
Nick

From: v6ops [mailto:[e-mail]] On Behalf Of james woodyatt
Sent: 12 October 2017 22:44
To: [e-mail]
Cc: [e-mail]
Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

On Oct 12, 2017, at 13:07, JORDI PALET MARTINEZ <[e-mail]<mailto:[e-mail]>> wrote:

I fail to see the problem.

Yes, I see that.


I think if you build an IPv6-only link layer device (6LoWPAN), that needs to communicate with servers across the Internet, the logic thing, is to make sure that those remote servers are IPv6 enabled.

My problem: I want to provide a reference platform for independent 3rd-parties to use in building Internet applications on devices with IPv6-only network interfaces. Those devices are very constrained resource environments, and putting an IPv4 stack on them would apply a significant multiplier to their unit cost. So, to make them capable of communicating with legacy application servers that are not yet IPv6-enabled, we’ve entirely given up on making them reachable via the public Internet. They are only reachable through tunnels to walled-garden services, which are capable of proxying the legacy IPv4 services at the application layer. Which means 3rd-parties have to put their devices into a supported walled-garden if they want their applications to work.


I don’t see the need/case for a “new” 6LoWPAN device trying to reach an old IPv4-only server AND not getting that upgraded.

It’s only a problem if you don’t want to be forced into deploying walled gardens everywhere to act as application proxies for every little hardware device in your personal network. Many people think nothing of that problem. It’s a very common view. I only want to observe that the various large transitional cloud computing providers (*cough* *cough*) are, without doubt, happy to see that view reinforced by supposedly neutral standards bodies, and I’m certainly not criticizing it here. Just pointing out that the occasional lip service we see paid here to the idea that walled gardens are a problem is pretty silly at this point.


Despite, that, I agree that DNS64 sort out the problem, and that’s why in my document I suggest that DNS64 must be there, at the same time that we take measures to avoid breaking DNSSEC.

So, repeating somehow same question I did to Mikael a couple of emails ago … Do you think DNS64 must be there if measures to avoid breaking DNSSEC are taken ?

I did at one time, but I’ve given up on trying to stop 464XLAT from animating the shambling undead corpse of IPv4.

--james woodyatt <[e-mail]<mailto:[e-mail]>>