Subject: Fwd: New Version Notification for draft-andrews-6man-dns64-exclude-00.txt

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jul 2019 17:27:05 -0400

For consideration 

-- 
Mark Andrews

Begin forwarded message:

> From: [email-masked]
> Date: 22 July 2019 at 19:00:41 GMT-4
> To: "Mark Andrews" <[email-masked]>, "M. Andrews" <[email-masked]>
> Subject: New Version Notification for draft-andrews-6man-dns64-exclude-00.txt
> 
> 
> A new version of I-D, draft-andrews-6man-dns64-exclude-00.txt
> has been successfully submitted by M.  Andrews and posted to the
> IETF repository.
> 
> Name:        draft-andrews-6man-dns64-exclude
> Revision:    00
> Title:        DNS64 Exclusion List RA Option
> Document date:    2019-07-22
> Group:        Individual Submission
> Pages:        4
> URL:            https://www.ietf.org/internet-drafts/draft-andrews-6man-dns64-exclude-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-andrews-6man-dns64-exclude/
> Htmlized:       https://tools.ietf.org/html/draft-andrews-6man-dns64-exclude-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-andrews-6man-dns64-exclude
> 
> 
> Abstract:
>   To allow automatic device configuration to a DNS64 process behind a
>   IPv6-only link it is necessary to provide AAAA and A record exclusion
>   lists.  This document provide such a mechanism.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 25 Jul 2019 17:49:10 -0400

Hi Mark,

My understanding is that you are trying to make possible via RA the same we do in bind9 (and other DNS servers that support DNS64) with “exclude”, such as in:

dns64 64:ff9b::/96 {

        clients { any; };

        mapped { any; };

        exclude { 0::/3; 4000::/2; 8000::/1; 2001:db8::/32; };

        break-dnssec no;

        };

Right ?

If that’s the case, I fully support this document. I’ve however doubts about using APL, being experimental. Of course, an easy solution is to reclasify it as standard as well? Any reason for not doing so?

May be an example as the one I used above, can make it more “readable” for those not used to DNS64 configurations?

Regards,

Jordi

@jordipalet

El 25/7/19 17:27, "ipv6 en nombre de Mark Andrews" <[email-masked] en nombre de [email-masked]> escribió:

For consideration 

-- 

Mark Andrews

Begin forwarded message:

Abstract:

The IETF Secretariat

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Jen Linkova <[email-masked]>
Date: Sat, 27 Jul 2019 01:51:05 +1000

Hi Mark,

Thanks for writing this.
It might be useful to add some text to clarify the client behaviour in
terms of DNS TTL and the RA option lifetime. What is the host expected
to do when the lifetime for the APL RA option expired (or the RA with
lifetime = 0 is received) but the TTL is not expired yet?

Thanks!

On Fri, Jul 26, 2019 at 7:27 AM Mark Andrews <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jul 2019 05:40:53 +1000

> On 26 Jul 2019, at 7:49 am, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Mark,
>  

Correct.

You negate the exclude IPv4 ranges in the APL record and append “any;" to get the mapped acl.

	dns64.example.com. IN APL !1:10.0.0/24 1:10/8

becomes

	mapped { 1:10.0.0/24; !1:10/8; any; };

The exclude IPv6 addresses map directly;

	dns64.example.com. IN APL 2:64:ff9b::/32

becomes

	excluded { 2:64:ff9b::/32; };

> If that’s the case, I fully support this document. I’ve however doubts about using APL, being experimental. Of course, an easy solution is to reclasify it as standard as well? Any reason for not do…

I’m not aware of any reason to not reclassify it.  It’s been in implemented for 18 years now.  It’s also
compatible with UNKNOWN record processing.  One falls back to UNKNOWN record format when you have a family
other that 1 or 2.

> May be an example as the one I used above, can make it more “readable” for those not used to DNS64 configurations?

Sure I can extend the existing example.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jul 2019 05:59:28 +1000

> On 27 Jul 2019, at 1:51 am, Jen Linkova <[email-masked]> wrote:
> 
> Hi Mark,
> 
> Thanks for writing this.

There is also the PREF64 lifetime to consider.

There is 2 choices here.

1) take the minimum of RA option lifetimes and the DNS TTL 

or

2) just use the minimum of the RA options lifetimes

for deciding when to refresh the configuration.  The simplest solution
would be to do 2 (min RA option lifetimes) and note that DNS changes may
not take effect until the RA updates.

Mark