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

From: Jen Linkova <[email-masked]>
Date: Thu, 27 Jun 2019 20:35:57 +1000

Hi Mark,

On Tue, May 28, 2019 at 6:39 AM Mark Andrews <[email-masked]> wrote:
>
> The RA optionally includes the name of the APL record.  Inclusion is signalled by the option length.

I'm working on then -01 version of the draft and while trying to
incorporate the suggestion you made at the microphone @IETF104, I've
realized I'm still confused.

If I got it right, you are suggesting to use the option length to
indicate not just the prefix length, but the presence of the APL
record, right?
So how shall it look like?
Are you suggesting to use the Reserved bits to store the APL label length?

Let's look at all possible scenarios:

Scenario 1: /96 prefix, no APL.
The option length = 2, the option contains 96 bits of the prefix.

Scenario 2: non-/96 prefix, no APL.
The option length = 3, the last 32 bits of the option contains 8 bits
of the prefix length + reserved bits.

Scenario3: /96 prefix, APL name exists.
The option length is....well, I guess it would depend on the label
length, right? So 3 or more.
So the first 8 bits after the prefix length would be the APL label
length, then the APL (with padding to the 8 octets if needed).

Scenario 4:  non-/96 prefix, APL name exists
The same as scenario 3.

My concerns here are:
1) we are making the option parsing quite complicated just to
accomodate a hypothetical use case of 'dual-stack network with NAT64';
I'm afraid it might slow down the deployment.
2) the state machine is unclear to me:
- does the presence of the APL part mean that now the host MUST use
the DNS servers provided by the network to resolve the APL (remember,
one of the benefit of providing pref64 is ability to remove
dependencies on DNS64)? What if the host has DNS servers configured
manually? How could the client tell the difference?

So far I'm still not convinced that it's worth doing (at least currently).
If anything, I'd say the APL information should be in RDNSS option as
it shares fate with the DNS.

Or am I missing smth/misunderstood your suggestion?

> > On 28 May 2019, at 06:29, Mark Andrews <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Thu, 27 Jun 2019 20:54:05 +1000

Hi Michael,

>    Section 7 deals with the multihoming sitution more.

Thanks for the suggestion! I guess you are right, the "dual-stack +
NAT64" scenario is scoped to a PVD.
I'll update the section.

> The slides had some optional stuff which I think is gone from the document.

Quote the opposite, it has not been added there yet - we wanted to
discuss the options during the IETF104 and I'm incorporating
the feedback to the -01 version right now.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 Jun 2019 09:56:39 -0400

> manually? How could the client tell the difference?

Or if the device wants to use DoH (or has VPNs, or...)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jun 2019 11:16:36 +1000

0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                            Prefix/Suffix                      +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | PREFIX LENGTH |        DNS64 FILTER NAME                      |
     +-+-+-+-+-+-+-+-+                                               ~
     ~                                             +-+-+-+-+-+-+-+-+-+
     |                        DNS WIRE ENCODED     |PADDING IF NEEDED|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

e.g. _dns64.example.com or _dns64.home.arpa
06 5f 64 6e 73 36 34 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
or
06 5f 64 6e 73 36 34 04 68 6f 6d 65 04 61 72 70 61 00

If there is no filter name you encode the root label “." (00).

Any yes you would use the DNS servers in the RA to retrieve this or else
it wouldn’t work for split DNS.

Filters can be long. DNS has ~64K for encoding the filter information in.

While the first label doesn’t have to be _dns64, having a leading underscore
takes it out of hostname namespace.

To make a DNS query you prefix the name with a DNS header (12 octets)
and append 00 01 00 2a (IN/APL).

e.g 
	XX XX 00 00 00 01 00 00 00 00 00 00 06 5f 64 6e
	73 36 34 04 68 6f 6d 65 04 61 72 70 61 00 00 01
	00 2a

And as these are IPv6 nodes we also need to add a OPT record for
which the minimal one is 11 octets (00 YY YY 00 21 00 00 00 00 00 00)

e.g 
	XX XX 00 00 00 01 00 00 00 00 00 01 06 5f 64 6e
	73 36 34 04 68 6f 6d 65 04 61 72 70 61 00 00 01
	00 2a 00 YY YY 00 21 00 00 00 00 00 00

XX XX DNS ID
YY YY EDNS UDP BUFFER SIZE

> On 27 Jun 2019, at 8:35 pm, Jen Linkova <[email-masked]> wrote:
> 
> Hi Mark,
> 

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

---

From: Jen Linkova <[email-masked]>
Date: Fri, 28 Jun 2019 14:31:02 +1000

> Filters can be long. DNS has ~64K for encoding the filter information in.

The more I think about it the less I'm convinced it should be added to
this RA option. My concerns are:
1) do we really want to put DNS labels into the router configuration?
NAT64 prefix is smth which is defined and controlled by the routing
infrastructure, while this thing is totally different.

2) as you've said, filters can be long. How can we prevent inflating
the RA beyond any reasonable limit?

3) it would *only* work if the application using the APL is also using
the network-provided resolvers - and I can not see how it could be
guaranteed (== it would lead to rather non-obvious failure scenarios
and operational nightmares).

4) as I've mentioned before the use case seems to be pure hypothetical
(I can not recall anyone claiming it's a real operational problem -
but I might be wrong). In the scenario when a dual-stack network is
connected to IPv6-only uplink (so DNS64 synthesis shouldn't be
performed for the IPv4 addresses local to the network), 464XLAT would
be most likely solution.
SO for me it looks like a very special corner case for which we do not
have operational experience yet and which would most likely arise in
multihoming scenario. So should the need arise,
APL could be provided as a part of additional PVD information:
https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05#section-4
(or by using the universal RA option, maybe).

> takes it out of hostname namespace.

Stupid question: why can not we reserve a well-known label (_dns64 ?)
and let the client to request APL in the domains from its search list?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jun 2019 15:06:22 +1000

> On 28 Jun 2019, at 2:31 pm, Jen Linkova <[email-masked]> wrote:
> 

Why not?  DNS labels go in DHCP configurations all the time. What’s the
real difference?

> the RA beyond any reasonable limit?

You do it by indirection which this is doing.

> and operational nightmares).

No.  It just requires the OS to record the information where the application
can fetch it.  This allows DNS64 processing to be done in getaddrinfo() and
not in the DNS servers.

> (or by using the universal RA option, maybe).

Not really, DNS64 servers are configured with exclusion lists today.  When you
move DNS64 processing closer to the application, be it the CPE router, on node,
or in app you still need those exclusion lists.  At a minimum you need to
exclude ::ffff:0.0.0.0/96 to filter out the mapped addresses published in the
DNS.  You also need to exclude the well know DNS64 prefix.  The list only grows
from there.

> and let the client to request APL in the domains from its search list?

Because there is no requirement to publish a search list and if you are
sane you ignore them.  Search list are also badly implemented the same
unqualified name to match to different fully qualified names depending
upon the query type in the request as search algorithms don’t stop on
noerror/nodata and some don’t stop on servfail either.  There is a lot
of history behind the behaviour.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 28 Jun 2019 14:58:13 +0900

On Fri, Jun 28, 2019 at 1:31 PM Jen Linkova <[email-masked]> wrote:

> have operational experience yet
>

+1.

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?

As an implementer, this really doesn't look like something I would want to
implement at the moment. Adding support for it would require writing a lot
of new code, and it would end up being unused anyway, because our
implementation prefers native IPv4 over 464xlat.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jun 2019 14:55:49 -0400

> of history behind the behaviour.

Mark, thank you for the your reply, because I didn't understand the _dns64
proposal.  Now that you mention that it depends upon search list, I'm very
very much against it.  No sane laptop user or smartphone pays attention to
search lists, and captive portals that depend upon them are really really
broken.

It's taken me a bit of connecting the dots to understand this proposal,
but now that I understand it, I'm pretty happy with it.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jun 2019 15:01:01 -0400

> once we get more support for it and consensus that it is a useful thing to

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.

    > implementation prefers native IPv4 over 464xlat.

I'm not convinced that basic "single" interface smartphones need this.
Where I think it becomes important is in desktops where enterprises try to
move to IPv6-only networks, and wind up with islands of IPv4 legacy
equipement that is internal only.

I think that this mechanism removes a friction point that would prevent
enterprises from going IPv6-only for the majority of their desktop users.
Specifically, the small percentage of non-desktop-only users that might be
attached to other legacy (factory/plant/etc.) equipment.

There are other solutions we could come up with (BCPs), but they would be
harder to manage centrally.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Jun 2019 07:03:46 +1000

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. 

Please go back and re-read the proposal. 

-- 
Mark Andrews

> On 29 Jun 2019, at 04:55, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Jun 2019 17:54:35 -0400

Mark Andrews <[email-masked]> 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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 29 Jun 2019 09:38:21 +0900

> 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.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 30 Jun 2019 07:50:37 +1000

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 <[email-masked]> wrote:
> 
>> On Sat, 29 Jun 2019, 04:01 Michael Richardson, <[email-masked]> wrote:
> 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.
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 1 Jul 2019 13:06:21 +1000

> equipement that is internal only.

I must be stupid. I'm still struggling to understand the scenario it
could be useful.

First I think we need to clarify what  'IPv6-only' means.
If you mean 'IPv6-only hosts' than having the APL does not help as
hosts do not have IPv4 at all. Legacy IPv4 devices will be reachable
via NAT64.

If you mean 'dual-stack hosts on the dual-stack island which is
connected to the IPv6-only backbone -
then I can not understand why anyone would deploy such setup with
DNS64 instead of doing 464xlat.

> enterprises from going IPv6-only for the majority of their desktop users.

In my experience of deploying IPv6-only enterprise networks (IPv6-only
== "hosts w/o IPv4 addresses") the ability to exclude particular
prefixes
from synthesis is not anywhere on the top blockers list. In my reality
the main friction points are:
- applications which fail if they can not detect IPv4 address/send
packet over IPv4;
- applications using IPv4 literals
- remote (outside of the enterprise control) VPN systems which fail if
the client does not have IPv4.
- validating resolvers

> attached to other legacy (factory/plant/etc.) equipment.

Could you draw a diagram? (Or we can have a chat in Montreal, if it's easier).
--
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 1 Jul 2019 12:21:49 +0900

On Sun, Jun 30, 2019 at 6:50 AM Mark Andrews <[email-masked]> wrote:

> 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.
>

It increases the RA overhead only in those environments where it is needed.
I believe we all agree that in the most common deployment scenario (i.e.,
an IPv6-only host with no IPv4) it is not needed?

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.
>

Do you mind going into more detail about this example? What is running
where, and what does and does not work?

---

From: Jen Linkova <[email-masked]>
Date: Mon, 1 Jul 2019 14:08:08 +1000

On Sun, Jun 30, 2019 at 7:50 AM Mark Andrews <[email-masked]> wrote:
>
> Well the information in needed the moment you use the DNS64 prefix anywhere else than in the setup for a virtual interface.

I think the point is that information is needed only of the host has a
dual-stack interface and is using DNS64 (and there is a NAT64
somewhere behind that interface).
What I'm trying to say is that scenario looks very special and I'm
sure people are doing it in real life ex. for some experiments.

>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.

Not sure I understand what you mean.
Let's say there is a node connected to an IPv6-only LAN.
Scenario 1: the node has one route, ::/0 pointing to the router LLA.
Scenario 2: the node has a number of more specific routes, pointing to
some other LLAs.

How does it different for NAT64/DNS64 case with or without APL?

> 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.

I'm not sure there will be an overhead in case of two options.
[Disclaimer: writing this before my first coffee, so please
double-check my math]

If /96 prefix is used (remember, in that case to have the APL the
pref64 option would need to include all 128 bits of the prefix and the
prefix length so we are adding 64 bits of the overhead)

Case 1: the APL name is 24 bits or shorter
if we include it in the pref64 option, then we can keep Len = 3, so 192 bits
Separate options: the new option would have length = 1, and the pref64
option would have length = 2, total length of both options = 3, 192
bits. No overhead.

Case 2:  24 bits < the APL length  < 48 bits
If included in pref64 option: length = 4 (or 256 bits)
Separate option: length = 1, the pref64 option length = 2. Still 192
bits, We are even saving the bits.

Case 3: 48 bits < The APL name < 88 bits
If included into pfe64: len = 4 ( 256 bits)
The separate option would still have the length = 2. Pref64 option
length = 2. No overhead.

Case 4: 88 bits < the APL < 112 bits
If included into pfe64: len = 5
The separate option: len = 2. Pref64 len = 2. Having a separate option
saves bits.

etc.
If we look at random example of an APL name using 20 bytes:
- having it in the pref64 option: the option len = 6
- with two separate options: pref64 len = 2; the APL option len = 3 =>
the total len = 5.
Again, it's better to have a separate one.

> Go try and set up a validating DNS64 server on a tethered host and see if you can.

Tethered like 'tethered to a phone which is connected to v6-only network'?

---

From: Jen Linkova <[email-masked]>
Date: Mon, 1 Jul 2019 14:16:09 +1000

> Why not?  DNS labels go in DHCP configurations all the time. What’s the

I'd rather avoid it as it would be a nightmare to maintain.

> can fetch it.  This allows DNS64 processing to be done in getaddrinfo() and

When you say 'the information' do you mean 'the APL name' or 'the
prefixes from that APL'?

> DNS64 servers are configured with exclusion lists today.  When you

Oh, so you do not just suggest to keep an list of IPv4 prefixes not to
translate, but also explicitly specifying a list of IPv6 addresses
which
should be ignored when checking for AAAA?
Well, I disagree that we need to maintain that list. If someone is
publishing in DNS IPv4-mapped, IPv6-compatible, Link-local,
Site-local, multicast or whatever crap you can imagine -
well, good luck. I do not think clients need to work around it.

> of history behind the behaviour.

OK, got it, thanks for the explanation.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 1 Jul 2019 16:58:09 +1000

> On 1 Jul 2019, at 2:16 pm, Jen Linkova <[email-masked]> wrote:
> 

It’s no harder to maintain than anything else.  It would normally just be
the IPv4 prefixes the site is using.  That doesn’t normally change much.

> prefixes from that APL’?

I would record it as the prefixes with a timer to refetched based on
DNS TTL.  That way the data is available for whatever application wants
it.  RA timers also apply.

> well, good luck. I do not think clients need to work around it.

Well it is specified behaviour of a DNS64 server.  The same list can
return both exclusion lists.

RFC 6147, 5.1.4.  Special Exclusion Set for AAAA Records

   Some IPv6 addresses are not actually usable by IPv6-only hosts.  If
   they are returned to IPv6-only querying agents as AAAA records,
   therefore, the goal of decreasing the number of failure modes will
   not be attained.  Examples include AAAA records with addresses in the
   ::ffff:0:0/96 network, and possibly (depending on the context) AAAA
   records with the site's Pref64::/n or the Well-Known Prefix (see
   below for more about the Well-Known Prefix).  A DNS64 implementation
   SHOULD provide a mechanism to specify IPv6 prefix ranges to be
   treated as though the AAAA containing them were an empty answer.  An
   implementation SHOULD include the ::ffff/96 network in that range by
   default.  Failure to provide this facility will mean that clients
   querying the DNS64 function may not be able to communicate with hosts
   that would be reachable from a dual-stack host.

   When the DNS64 performs its initial AAAA query, if it receives an
   answer with only AAAA records containing addresses in the excluded
   range(s), then it MUST treat the answer as though it were an empty
   answer, and proceed accordingly.  If it receives an answer with at
   least one AAAA record containing an address outside any of the
   excluded range(s), then it by default SHOULD build an answer section
   for a response including only the AAAA record(s) that do not contain
   any of the addresses inside the excluded ranges.  That answer section
   is used in the assembly of a response as detailed in Section 5.4.
   Alternatively, it MAY treat the answer as though it were an empty
   answer, and proceed accordingly.  It MUST NOT return the offending
   AAAA records as part of a response.