Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Fred Baker <[e-mail]>]

Sorry for the delay in following up. This is an active thread.

> On Dec 4, 2019, at 3:26 PM, Jen Linkova <[e-mail]> wrote:
> 
> On Thu, Dec 5, 2019 at 7:49 AM Fred Baker <[e-mail]> wrote:
>>> One of the biggest issue in deploying IPv6-only LANs is how to do it
>>> incrementally, when some hosts work just fine in NAT64 environment
>>> while some legacy devices still need IPv4.
>> 
>> A general comment - I don't think this is "devices" as much as it is "applications". I'm thinking here of issues raised in RFC 2993 among others.
> 
> You are right, it's applications getting broken w/o IPv4 indeed. The
> text is saying 'devices' just for the sake of brevity: as a network
> engineer I see *devices* connecting to the network, and IPv4 addresses
> being assigned to the devices. A device just a box with a number of
> applications (+ an OS) running inside.
> However there are cases when an application needs an IPv4 address to
> operate while the whole device does not. Think of a device with
> 464XLAT  enabled (e.g. an Android phone). The same application might
> work perfectly fine on a mobile phone connected to an IPV6-only WiFi
> but gets broken if I run it on my macbook connected to the same
> network.
> 
> Would it be better if the sentence you quoted would be saying 'while
> some legacy devices still need IPv4 addresses as their OSes and/or
> applications depend on IPv4'?

It might.

I spent some time looking for the definition of "dual stack" (for another reason), and found that while the term is used in some 94 IPv6-related RFCs, it is never really defined. To me, and I think the authors of those various RFCs, the implication is that one could turn either IPv4 or IPv6 off, and peers using the remaining protocol would still be able to use whatever service the device or application offers. At my former employer, the term was generally used to mean that a system was generally IPv4-capable but had some IPv6 capabilities as well. The nearest thing to a definition that I found was in RFC 3750, but even there one has to read it carefully.

RFC 3750 makes the point about the OS offering either or both, but some applications requiring IPv4, and of transitions being not only for the OS, but for applications.

>> I would argue that NAT64 is subject to the same issues as NAT44; there is a coupling between the network and application layers in that an IP address is used as an application layer identifier, and a coupling between addressing domains in the network in that hosted applications presume that an address they use is meaningful to and means the same to an application in another domain. RFC 3439 talk about coupling primarily in terms of time, but couplings such as I describe are also dangerous, and I would argue that the issues raised in RFC 2993 are direct results of coupling. So, whenever an address is embedded in application data and interpreted or used by the peer application, there will be a NAT issue.
>> 
>> What would I want to do about it? I would not want to see an ALG (to my mind, that works against higher layer security such as TLS or IPSec), but rather see the application use an application layer identifier such as a DNS name.
> 
> NAT64 is not perfect and is not a silver bullet but I do not think we
> have any better tool right now. At least NAT64 is used for iPv4-only
> destinations only so damage is contained (and the footprint will be
> reducing over time, I hope).

Speaking as a co-author of stateless IPv4/IPv6 NAT (which is about connecting from {IPv4|IPv6} to {IPv6|IPv4}, and is used by NAT64, which is about connecting statefully from an IPv6-only network to an IPv4-only network), I would agree that neither stateless nor stateful IPv4/IPv6 translation is a "silver bullet" - primarily due to issues raised in RFC 2993. My co-authors wanted to not have to move all of their IPv4-only servers to the IPv6-only network before being about to test it. They wanted the evolving IPv6-only network to be able to access IPv4-only servers on day 1, even though they had the full intention of making all servers IPv6-capable over time, or duplicating them with IPv6-only servers. Translation gave them the capability of getting there in a limited fashion while they pursued the remainder of the process.

The "better tool", if I understand RFC 2993 correctly, would be 
(1) to remove network layer addresses from application layer applications, so that there is no coupling between the application layer and the network layer, or
(2) make the application equally able to use IPv4 or IPv6 addresses, or
(3) deploy separate instances of the application for use in IPv4 and IPv6 networks. 

Each has issues...