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

The RA optionally includes the name of the APL record.  Inclusion is signalled by the option length. 

  It could also be published at ipv4only.arpa as well. The RA wins if both exist and are different. 

-- 
Mark Andrews

> On 28 May 2019, at 06:29, Mark Andrews <marka@isc.org> wrote:
> 
> You use  an APL record to define which addresses are mapped/excluded  (the difference is where the negations goes and whether you include the /0 entries at the end normally) on a first match basis. 
> 
> e.g.
> 
> APL !1:10.0.0.0/8 1:0.0.0.0/0
> 
> Not net 10 but everything else. 
> 
> TYPE42 \#9 00 01 08 81 0a 00 01 00 00
> 
> The above is a mapping list not a exclude list. 
> 
> You can also encode the IPv6 prefixes you want to ignore when determining if you are doing.  This is useful for when you want to be IPv6 internally but don’t have external connectivity  or you only have partial IPv6 connectivity or for ignoring the results of a seperate DNS64 mapping. 
> 
> Both lists can be encoded in a single APL record. Also it is easy enough to encode the record in unknown record format by hand as the encoding is not hard to do.  See above. 
> 
> -- 
> Mark Andrews
> 
>> On 28 May 2019, at 01:57, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> 
>> 
>> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------