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

Hi Mark,

So let me summarise my opinion on this topic - hopefully we could find
some consensus... ;)

- First of all you are right, there are scenarios when it might be
beneficial to communicate to hosts some exclusion lists (esp. for
specifying AAAAs which should be ignored if present and still trigger
DNS64 synthesis).
- Those cases seem to be quite limited  subset of all Pref64 use cases (IMHO).
- Based on what I've seen in the real life, have read on the list and
have heard at IETF, the vast majority of Pref64 use cases are for /96.
But not all of them.
- If my calculations are correct, for the /96 Pref64 case combining
Pref64 and APL together does not save bits and does not make RA
smaller. Sometimes it's even the opposite.
- On the other hand, decoupling the Pref64 from the APL would provide
the following benefits:
  --- simplifies the options parsing (making it easier for understand
and implement);
  --- speeds up the adoption, implementation and deployment (the
simpler the feature the easier to get it implemented by the
vendor...usually...;)
  --- solve the issue of referencing the experimental RFC in the standard one.
  --- (ps correct me if I'm wrong): it would allow end systems which
have RFC7050 implemented and are not willing to implement Pref64 RA
option to use the APL option still (if the network sends it). So even
RFC7050-only end hosts would benefit from the APL option if we get
them decoupled.
- if you are concerned about administrative overhead of writing two
drafts - as I've said before I'm more than happy to write the draft
and send it to you for review/comments. Not sure if there are any
slots left for Montreal but we could definitely do it in Singapore.
(I'd not be surprised if the total amount of text in that drat would
be less than we have sent in that email thread ;)))).

What do you think? Are there any reasons still to get have the Pref64
and  the APL bound together?

On Tue, Jul 2, 2019 at 2:41 PM Mark Andrews <marka@isc.org> wrote:
>
>
> > On 2 Jul 2019, at 10:48 am, Erik Kline <ek@loon.com> wrote:
> >
> >
> >
> > On Fri, 28 Jun 2019 at 14:54, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> >
> > Mark Andrews <marka@isc.org> wrote:
> >     > Except it DOES NOT depend on search lists. The name is absolute. I was
> >     > pointing out to Jen why depending on a search list was a bad idea.
> >
> > To clarify, I think there are two ideas:
> >
> > 1) reserving _dns64, + search list to get APL
> > 2) sending the absolute name to get APL.
> >
> > I understand you are proposing (2), and I'm thanking you for clarifying that.
> >
> > Am I right in reading that https://tools.ietf.org/html/rfc3123 is Experimental?  Did another doc change the status of APL RRs?
>
> No.
>
> > I like APL RRs, but if we want a standards track type RA option, should APLs get a bump in status first (purely for the lie-flat seats, of course)?
>
> I don’t see the need.  It’s not required.  It’s just something that has to be noted in the write up.
>
> If the primary doesn’t support APL in (RFC 3123) text format it should support it in unknown record format (RFC 3597).  All intermediate servers and resolvers (including stub resolvers) if they are STD13 compliant will handle it.  It is just a opaque blob of data to be transferred and STD13 requires *all* resolvers to be able to lookup and return unknown types as opaque data.  Yes, this is a forward compatibility requirement in STD13.
>
> All that is required is that there be a stable reference which we have with RFC 3123.
>
> > --
> > 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
> > --------------------------------------------------------------------
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry