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

From: Fred Baker <[email-masked]>
Date: Mon, 1 Jul 2019 17:29:18 -0700

On Jun 30, 2019, at 8:06 PM, Jen Linkova <[email-masked]> wrote:
> First I think we need to clarify what  'IPv6-only' means.

To my mind, that is mostly complex because people make it complex, or because we allow them to.

Imagine I have two hosts, each of which can only communicate using IPv6. They only have IPv6 addresses, and they possibly only have IPv6 stacks, but they don't have anything else. If they can communicate in a domain, from their perspective it is a domain that will support end to end IPv6 communication. If they have to do something in addition, the domain doesn't work for IPv6-only hosts.

Now, it could be that the communications are translated to IPv4, X.25, or SNA in between. Yup, could happen. But we can communicate end to end using only IPv6, right?

And, oh yes, someone using IPv4 (or X.25, or SNA) could go through a translator and communicate with an IPv6-only host in such a domain. It's IPv6-only up to that translator.

The question boils down to - imagine I had only IPv6 to work with. Could we communicate? An IPv6-only host, or IPv6-only network, could communicate with that restriction. Everything else is noise - and if I have to deal with noise, it's not IPv6-only.
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 10:47:49 +1000

> The question boils down to - imagine I had only IPv6 to work with. Could we communicate? An IPv6-only host, or IPv6-only network, could communicate with that restriction. Everything else is noise -…

I totally agree. it was my understanding of IPv6-only as well.
So - back to the original problem of excluding some addresses from
DNS64 synthesis/NAT64 translation - I've been told that an IPv6-only
host might want to exclude some addresses from synthesis and use IPv4
to reach them, so I'm trying to understand how *an IPv6-only* host
(which, IMHO, can only use IPv6) reach anything using IPv4.

-- 
SY, Jen Linkova aka Furry

---

From: Erik Kline <[email-masked]>
Date: Mon, 1 Jul 2019 17:48:02 -0700

On Fri, 28 Jun 2019 at 14:54, Michael Richardson <[email-masked]>
wrote:

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

Am I right in reading that https://tools.ietf.org/html/rfc3123 is
Experimental?  Did another doc change the status of APL RRs?

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)?

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 2 Jul 2019 14:40:45 +1000

> On 2 Jul 2019, at 10:48 am, Erik Kline <[email-masked]> wrote:
> 
> 
> 
> On Fri, 28 Jun 2019 at 14:54, Michael Richardson <[email-masked]> wrote:
> 
>     > Except it DOES NOT depend on search lists. The name is absolute. I was
> 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.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Jul 2019 19:53:26 +0900

On Tue, Jul 2, 2019 at 9:49 AM Jen Linkova <[email-masked]> wrote:

> > The question boils down to - imagine I had only IPv6 to work with. Could
> we communicate? An IPv6-only host, or IPv6-only network, could communicate
> with that restriction. Everything else is noise - and if I have to deal
> with noise, it's not IPv6-only.
>

Right. That was the gist of my earlier comment. I believe we all agree that
in the most common deployment scenario (i.e., an IPv6-only host with no
IPv4), an exclusion list is not useful, because the host really can't reach
anything that's not reachable via IPv6.

If so, then I really think that an exclusion list should be a separate
option.

---

From: David Farmer <[email-masked]>
Date: Tue, 2 Jul 2019 07:09:08 -0500

On Tue, Jul 2, 2019 at 5:53 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>> > The question boils down to - imagine I had only IPv6 to work with.
>> Could we communicate? An IPv6-only host, or IPv6-only network, could
>> communicate with that restriction. Everything else is noise - and if I have
>> to deal with noise, it's not IPv6-only.
>>
> Right. That was the gist of my earlier comment. I believe we all agree
> that in the most common deployment scenario (i.e., an IPv6-only host with
> no IPv4), an exclusion list is not useful, because the host really can't
> reach anything that's not reachable via IPv6.
>

I mostly agree, but there is a scenario I've been thinking about;

What if the network operator doesn't want RFC1918 and RFC 6598 IPv4
addresses synthesized at all? I suppose the NAT64 function could block
these addresses. However, for a large enough population that could be a lot
of useless traffic going to the NAT64 function. While on the other hand
some network operators, especially enterprise operators, will probably want
these addresses synthesized.

Now a complicated APL capability isn't probably needed to handle this, a
simple one-bit option flag or two would suffice, I believe.

> If so, then I really think that an exclusion list should be a separate

I agree that a generalized highly configurable exclusion list should be a
separate option, but I can see the need to exclude or not synthesis for
RFC1918 and RFC 6598 IPv4 addresses being part of this option.

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Jul 2019 21:50:49 +0900

> these addresses synthesized.

Hmm... but why will hosts want to send traffic to those addresses? Hosts
(especially IPv6-only hosts) won't just arbitrarily decide to connect to
RFC1918 addresses of their own accord. They will only do that if there is a
reason to do so - for example, if there is an A record in the DNS pointing
at such addresses. But why would the network operator publish A records in
the DNS for IP addresses that it intentionally wants to make unreachable
from some hosts? What is the reason for doing so compared to obvious
alternatives such as a) don't publish said A records, or b) publish said A
records together with corresponding AAAA records?

Also, this problem already exists today in IPv4. Any IPv4-only or
dual-stack host asked to connect to an RFC1918 address will send packets to
it, regardless of whether the address is reachable and of whether it's in
the same NAT domain as the host. For example, applications using STUN, such
as video chat applications, will often try all addresses advertised by the
remote host, even in the common case that the remote host is in a different
NAT domain (e.g. video chat between two residential users each of whom is
behind their own NAT).

> simple one-bit option flag or two would suffice, I believe.

In the common case of a /96 prefix I don't think there are any bits left in
the current packet format without increasing the size of the option from 16
to 24 bytes.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 23:11:17 +1000

On Tue, Jul 2, 2019 at 10:09 PM David Farmer <[email-masked]> wrote:
> What if the network operator doesn't want RFC1918 and RFC 6598 IPv4 addresses synthesized at all? I suppose the NAT64 function could block these addresses. However, for a large enough population that could be a lot of useless traffic going to the NAT64 function. While on the other hand some network operators, especially enterprise operators, will probably want these addresses synthesized.

Oh funny you should mention that..I've been thinking about it but have
not managed to untangle the chain of RFCs yet...

So, https://tools.ietf.org/html/rfc6052 explicitly states that
"The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets."

So I'd expect that if I run an internal network which has some
Ipv4-only segments and would like to ensure they are not translated,
all should work fine if those segments are using RFC1918 address space
and WKP is used for translation.

However DNS64 RFC does not explicitly mention that.
https://tools.ietf.org/html/rfc6147#section-5.1.4 talks about
Exclusion Set for AAAA Records but it only recommends including
::ffff/96 by default.
Does it mean that if I do not explicitly configure the exclusion set
for the DNS64 *somehow*, the DNS64 is going to synthesise AAAA for
RFC1918 space using the WKP while the translators would drop those
packets?

RFC6146 does not mention RFC1918 or WKP but it refers to RFC6052 so
I'd expect it to inherit the requirement of not using the WKP with
RFC1918 addresses...But I could not find the explicit confirmation.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Jul 2019 23:30:27 +1000

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?

---

From: David Farmer <[email-masked]>
Date: Tue, 2 Jul 2019 09:05:30 -0500

On Tue, Jul 2, 2019 at 7:51 AM Lorenzo Colitti <[email-masked]> wrote:

> at such addresses.

You partly answer this below, it happens all the time in IPv4 today. There
is a reason we have AS112, there is a ton of junk out there. Yes, AS112 is
a different problem, but I still think it illustrates the scale of the
problem. RFC1918 addresses are everywhere and they leak everywhere too.

> But why would the network operator publish A records in the DNS for IP
> addresses that it intentionally wants to make unreachable from some hosts?
> What is the reason for doing so compared to obvious alternatives such as a)
> don't publish said A records, or b) publish said A records together with
> corresponding AAAA records?
>

One of the reasons we want this RA option is that clients are configured
with DNS servers not provided by the network operator. So even if the
network operator doesn't put these addresses in their DNS, the client could
be using a DNS server serving these addresses to it. For example, what if
the client is hard configured with an enterprise DNS server? Then there are
all the DNS games VPN clients play.  As I said, the NAT64 function can
block this but then it has to receive the traffic just to drop it. Maybe
it's just the price we have to pay for all the brokenness in IPv4.

> In the common case of a /96 prefix I don't think there are any bits left
> in the current packet format without increasing the size of the option from
> 16 to 24 bytes.
>
>>
If we don't provide a mechanism to configure this, then clients
implementing this feature MUST synthesize DNS entries for RFC1918 and
RFC6598 IPv4 addresses received in A records, and it is up to the NAT64
function to apply an appropriate local policy for these addresses. I think
other special purpose IPv4 addresses MAY be safely excluded from DNS
synthesize.

Thanks

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 03 Jul 2019 12:37:59 +0200

Hi all,

El 2/7/19 2:30, "ipv6 en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

    

-> I tried to fix this some time ago, but my draft expired. I've updated it now and just posted it:

https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/?include_text=1

-> by the way, I'm actually not sure if this is in scope of 6man or v6ops ... I tend to think v6ops, but just in case !

    

**********************************************
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: David Farmer <[email-masked]>
Date: Fri, 26 Jul 2019 16:57:47 -0500

> not managed to untangle the chain of RFCs yet...

Actually, I was rereading the draft and found a possible answer for my
scenario already partially discussed in the draft.

Section 4, paragraph 2, says;

   This option specifies exactly one NAT64 prefix for all IPv4
   destinations.  If the network operator desires to route different
   parts of the IPv4 address space to different NAT64 devices, this can
   be accomplished by routing more specifics of the NAT64 prefix to
   those devices.  For example, if the operator would like to route
   10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space
   through NAT64 device B, and the operator's NAT64 prefix is
   2001:db8:a:b::/96, then the operator can route
   2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B.

One answer for my scenario is if the NAT64 prefix is 2001:db8:a:b::/96,
then null route or filter traffic for 2001:db8:a:b::a00:0/104 and the other
RFC1918 blocks in the network ahead of the NAT64 function, then it won't
see the traffic.

Maybe add something about filtering or null routing as well as routing to
an alternate NAT64 function to the above paragraph.

Thanks.