Re: [v6ops] IPv6-Only Preferred DHCPv4 option

[Jen Linkova <[e-mail]>]

On Thu, Dec 5, 2019 at 8:00 PM Bjørn Mork <[e-mail]> wrote:
> There is a fair amount of IoT devices requiring access to one specific
> CDN hosted dual-stack service, and only that. These devices will always
> work in an IPv6 only environment, even without NAT64, and they know it.
>
> Not that these hosts ever will implement any new DHCP feature, but still..
>
> Hosts considering NAT64 optional for IPv6-only operation will probably
> become more and more common as "all" (most) services get dual-stack.  I
> believe you are limiting the scope unnecessarily by requiring NAT64
> here.

You are right indeed. Strictly speaking what the option signals is
'all destinations the host might want to connect to are reachable over
IPv6 - either natively or by some transition mechanism deployed in the
network'. Indeed *some* devices might not need NAT64 even now if all
destinations they ever need access are IPv6-enabled. Maybe one day,
when 99.999% of traffic becomes IPv6 we might not need NAT64.
However practically speaking...While a device *might* be sure that it
does not even need NAT64 and can operate on pure IPv6-only, I do not
believe it's a realistic or practical to expect that a network
operator would mark the given segment as 'IPv4-as-a-Service' w/o
deploying NAT64.
While writing the text I did think about corner cases 'all
destinations the network provides an access to are Ipv6-enabled so
NAT64 is not needed' but they are a corner cases and trying to capture
them in the draft might do more harm than good...

What we might do is to clarify the definition of an IPv6-only capable
host and say that a host MAY be considered an IPv6-only capable if
it's guaranteed somehow that all destinations the host ever is going
to reach are IPv6-enabled - but I'm not really sure it's a good idea..


-- 
SY, Jen Linkova aka Furry