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

[Michael Richardson <[e-mail]>]

I just watched the 6man recording on draft-ietf-6man-ra-pref64.
I am very enthusiastic about having this progress, because it enables DNSSEC
resolution to be done on the host.
(We just have to find a way in CAPPORT to shame

The document says:

   In a network that provides both IPv4 and NAT64, it may be desirable
   for certain IPv4 addresses not to be translated.  An example might be
   private address ranges that are local to the network and should not
   be reached through the NAT64.  This type of configuration cannot be
   conveyed to hosts using this option, or through other NAT64 prefix
   provisioning mechanisms such as [RFC7050] or [RFC7225].  This problem
   does not apply in IPv6-only networks, because in such networks, the
   host does not have an IPv4 address and cannot reach any IPv4
   destinations without the NAT64.

And I guess I disagree with this in a subtle way, which Section 7
(multihoming) tries to deal with.   Maybe you could write:

   In a provisioning domain that provides both IPv4 and NAT64, it may be desirable
   for certain IPv4 addresses not to be translated.  An example might be
   private address ranges that are local to the provisioning domain and should not
   be reached through the NAT64.  This type of configuration cannot be
   conveyed to hosts using this option, or through other NAT64 prefix
   provisioning mechanisms such as [RFC7050] or [RFC7225].  This problem
   does not apply to hosts that are provisioned in IPv6-only networks,
   because in such networks, the host does not have an IPv4 address and
   cannot reach any IPv4 destinations without the NAT64.
   Section 7 deals with the multihoming sitution more.

----

The slides had some optional stuff which I think is gone from the document.
Mark Andrews made some suggestions, which I did not understand what happened.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-