Re: NAT64 in RA, draft-ietf-6man-ra-pref64

[Jen Linkova <[e-mail]>]

On Sat, Jun 29, 2019 at 5:01 AM Michael Richardson
<[e-mail]> wrote:
> I'm not convinced that basic "single" interface smartphones need this.
> Where I think it becomes important is in desktops where enterprises try to
> move to IPv6-only networks, and wind up with islands of IPv4 legacy
> equipement that is internal only.

I must be stupid. I'm still struggling to understand the scenario it
could be useful.

First I think we need to clarify what  'IPv6-only' means.
If you mean 'IPv6-only hosts' than having the APL does not help as
hosts do not have IPv4 at all. Legacy IPv4 devices will be reachable
via NAT64.

If you mean 'dual-stack hosts on the dual-stack island which is
connected to the IPv6-only backbone -
then I can not understand why anyone would deploy such setup with
DNS64 instead of doing 464xlat.

> I think that this mechanism removes a friction point that would prevent
> enterprises from going IPv6-only for the majority of their desktop users.

In my experience of deploying IPv6-only enterprise networks (IPv6-only
== "hosts w/o IPv4 addresses") the ability to exclude particular
prefixes
from synthesis is not anywhere on the top blockers list. In my reality
the main friction points are:
- applications which fail if they can not detect IPv4 address/send
packet over IPv4;
- applications using IPv4 literals
- remote (outside of the enterprise control) VPN systems which fail if
the client does not have IPv4.
- validating resolvers

> Specifically, the small percentage of non-desktop-only users that might be
> attached to other legacy (factory/plant/etc.) equipment.

Could you draw a diagram? (Or we can have a chat in Montreal, if it's easier).
--
SY, Jen Linkova aka Furry