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

[Mark Andrews <[e-mail]>]

Well the information in needed the moment you use the DNS64 prefix anywhere else than in the setup for a virtual interface.  The only reason you can get away with it in that scenario is that the routing table acts as a filter and only then if you have the node learning the routes and it is not relying on default to reach the rest of the internal subnets. 

Adding it in a second option also increases the RA overhead. Your main objection it that it increases the size of the RA option but you want to add the overhead of a second RA option.

Go try and set up a validating DNS64 server on a tethered host and see if you can.  Note everything you need to guess when you configure it.  Include some local printers in the DNS and try to print to them. Point the clients on this node at this DNS64 server. Now consider that you need to automate that. 

This is today. This is what the DNS64 RFC expects clients to do. 
-- 
Mark Andrews

> On 29 Jun 2019, at 10:38, Lorenzo Colitti <[e-mail]> wrote:
> 
>> On Sat, 29 Jun 2019, 04:01 Michael Richardson, <[e-mail]> wrote:
>>     > As a co-author, I don't see a real operational need for this at the moment.
>>     > Why is this not something that we can define later on in its own draft,
>>     > once we get more support for it and consensus that it is a useful thing to
>>     > do?
>> 
>> I'm not okay with this: I'd really like to be able to specify this in an RFP.
>> I'm okay with the mechanism being optional to support.
> 
> 
> That was not my point. My point was: why does this functionality need to be in this option? Why does it need to be in this draft? For example - why can't you and Mark submit a separate draft - at your earliest convenience - defining a new RA option to do this?
> 
> Particularly given that you're saying this would be optional to implement, it seems natural to have two different options.
>