Subject: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt

From: <[email-masked]>
Date: Mon, 30 May 2011 11:56:04 +0000

Hi,

The -00 revision was uploaded pretty much as is. I'm looking forward to next updates to the draft, and I thought those might be as follows: 

1) Clarify that the well-known FQDN is to be specified and hosted by IANA

2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN

3) Define long TTL for the well-known name entry so that it can be cached efficiently

4) Define that the synthesizing DNS64 must handle AAAA query for the well-known FQDN as for any other FQDN that does not have AAAA record (=synthesize response normally). However, A DNS server that does not implement AAAA synthesis (DNS64 function) could directly respond NXDOMAIN for the query instead of forwarding the (in that case pointless) query towards root? 

5) Possibly connectivity test conducted after synthesis is to be made to applications' own servers, if required.

6) The name shall be queried again when the lifetime of previous response expires (as was set by DNS64) or if interface changes.

Feedback welcome, as always. I plan to make an updated version by mid-June latest.

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext [email-masked]
> Sent: 25. toukokuuta 2011 20:54
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat64-discovery-heuristic-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance Avoidance
> Working Group of the IETF.
> 
> 	Title           : Discovery of a Network-Specific NAT64 Prefix using a Well-
> Known Name
> 	Author(s)       : Teemu Savolainen
>                           Jouni Korhonen
> 	Filename        : draft-ietf-behave-nat64-discovery-heuristic-00.txt
> 	Pages           : 7
> 	Date            : 2011-05-25
> 
>    This document describes a method for detecting presence of DNS64 and
>    for learning IPv6 prefix used for protocol translation on an access
>    network without explicit support from the access network.  The method
>    depends on existence of a known IPv4-only domain name.  The
>    information learned enables applications and hosts to perform local
>    IPv6 address synthesis and on dual-stack accesses avoid traversal
>    through NAT64.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> 00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-behave-nat64-discovery-heuristic-
> 00.txt
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 May 2011 08:04:55 -0400

On Mon, May 30, 2011 at 11:56:04AM +0000, [email-masked] wrote: 

> 4) Define that the synthesizing DNS64 must handle AAAA query for the
> well-known FQDN as for any other FQDN that does not have AAAA record
> (=synthesize response normally). However, A DNS server that does not
> implement AAAA synthesis (DNS64 function) could directly respond
> NXDOMAIN for the query instead of forwarding the (in that case
> pointless) query towards root?

That would be nice.  See
http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones-15
(which is, I think, about to be published).

(Just for the record, any contribution I make to this effort doesn't
mean I think it's a good idea.  I think it's a bad idea, but it's
apparently the bad idea that people are going to implement anyway.  So
I'd like it to be least bad.  It's still a bad idea.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Mon, 30 May 2011 12:58:47 +0000

Thank you, we shall reference that document.

On the query frequency, we could state also that the DNS64 discovery is to be performed only on-demand, e.g. as result of API call and not pre-emptively.

	Teemu

> Of ext Andrew Sullivan
> Sent: 30. toukokuuta 2011 15:05
> To: [email-masked]
> Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-
> 00.txt
> 
> (Just for the record, any contribution I make to this effort doesn't mean I think
> it's a good idea.  I think it's a bad idea, but it's apparently the bad idea that
> people are going to implement anyway.  So I'd like it to be least bad.  It's still a
> bad idea.)
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 May 2011 09:32:39 -0400

> On the query frequency, we could state also that the DNS64 discovery is to be performed only on-demand, e.g. as result of API call and not pre-emptively.

I'm not sure that's actually the best advice.  It strikes me that the
system resolver subsystem might want to do this one time, whenever the
network topology changes (cf. the mif DNS work).

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Mon, 30 May 2011 13:57:00 +0000

Maybe implementation detail then..

Sent from my Windows Phone

-----Original Message-----
From: ext Andrew Sullivan
Sent: 30 May 2011 16:32
To: [email-masked]
Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt

A

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 May 2011 07:59:34 -0700

On May 30, 2011 4:56 AM, <[email-masked]> wrote:
>
> Hi,
>
> The -00 revision was uploaded pretty much as is. I'm looking forward to
well-known FQDN as for any other FQDN that does not have AAAA record
(=synthesize response normally). However, A DNS server that does not
implement AAAA synthesis (DNS64 function) could directly respond NXDOMAIN
for the query instead of forwarding the (in that case pointless) query
towards root?

I don't think this will be an impact, but I would like to caution that many
service providers sends redirects to ad pages and do not send NXDOMAIN to
customers.  My cable company does this. As worded, this should not be an
impact, I just want to avoid people writing code here that depend on seeing
NXDOMAIN that will never come.

Cb

> 6) The name shall be queried again when the lifetime of previous response
expires (as was set by DNS64) or if interface changes.
> > Subject: [BEHAVE] I-D Action:
draft-ietf-behave-nat64-discovery-heuristic-00.txt
> >       Filename        :
draft-ietf-behave-nat64-discovery-heuristic-00.txt

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 May 2011 13:01:23 -0400

> NXDOMAIN that will never come.

Service providers who are doing this are doing all sorts of other dumb
things too.  This heuristic is not going to work reliably (for
instance, it is all but guaranteed to give you the wrong answer in
most hotel networks).  That's part of why I think it's a bad idea:
people have been abusing the DNS for a long time, and so registering
something global like this is in effect depending on conditions that
do not actually obtain all the time.

Nevertheless, we were assured at the mic in Prague that people are
going to implement this sort of probing anyway, not because it's the
most robust nor the best idea but because it was what they know how to
do immediately.  From my point of view, that means that we should
document one way to do such probing so that everyone probes for the
same name; that is less awful only because at least we get some
benefit from caches and so on.  That doesn't mean we should try to
work around all the stupid DNS tricks anyone has ever invented, in a
doomed effort to make this probing (and the entire NAT64/DNS64
mostly-works hack) completely reliable.

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Mon, 30 May 2011 17:18:28 +0000

True. So apps should not assume NXDOMAIN, but sending one could be possible action for DNS servers.

In the ad redirect case the well-known IPv4 address is unlikely inside the returned ad server's IPv6 address (though could, in which case connectivity test would help).

Will write something about this.

________________________________
From: ext Cameron Byrne
Sent: 30 May 2011 17:59
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: [email-masked]
Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt

> 4) Define that the synthesizing DNS64 must handle AAAA query for the well-known FQDN as for any other FQDN that does not have AAAA record (=synthesize response normally). However, A DNS server that…

I don't think this will be an impact, but I would like to caution that many service providers sends redirects to ad pages and do not send NXDOMAIN to customers.  My cable company does this. As worded, this should not be an impact, I just want to avoid people writing code here that depend on seeing NXDOMAIN that will never come.

Cb

> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of ext [email-masked]<mailto:[email-masked]>
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 May 2011 10:32:51 -0700

On May 30, 2011 10:18 AM, <[email-masked]> wrote:
> In the ad redirect case the well-known IPv4 address is unlikely inside the
returned ad server's IPv6 address (though could, in which case connectivity
test would help).
> Will write something about this.
As fyi,

I would assume the ad server is possibly native ipv6 and therefore would not
have any info to gleen from. If an sp has nat64 they like drive their own
infrastructure to be native v6, especially revenue generation ads.

Cb

> Subject: Re: [BEHAVE] Next for
> >
>
> I don't think this will be an impact, but I would like to caution that
many service providers sends redirects to ad pages and do not send NXDOMAIN
to customers.  My cable company does this. As worded, this should not be an
impact, I just want to avoid people writing code here that depend on seeing
NXDOMAIN that will never come.
> > 6) The name shall be queried again when the lifetime of previous
response expires (as was set by DNS64) or if interface changes.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 30 May 2011 19:52:00 +0000

> 1) Clarify that the well-known FQDN is to be specified and hosted by IANA

Can you estimate how much traffic that will generate to the IANA internet servers? Each transaction may be small, but if every host on the Internet does resolve this name each time they get powered up or move to a new network, we may be facing some large traffic. Do we have estimates on the efficiency of DNS caching? Is someone measuring that, maybe CAIDA?

> 2) Ask for a dedicated non-routable IPv4 address for the well-known FQDN

The examples there are problematic -- they belong to reserved range 127.0.0.0/8 (local host) and 192.168.0.0/16 (RFC 1918). There two issues:

 - IANA does not control allocation in these ranges, which means it cannot guarantee that they are not somehow reachable in the local environment;
- RFC 6052 specifically 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]," which means that the proposed algorithm will never be able to detect use of the WKP.

>From an operational point of view, it may be better to make the FQDN and addresses configurable. I can see for example how these could be configured simultaneously with STUN/TURN servers.

-- Christian Huitema

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 May 2011 16:41:51 -0400

> Can you estimate how much traffic that will generate to the IANA internet servers? Each transaction may be small, but if every host on the Internet does resolve this name each time they get powered…

The closest measurement you'd likely get is from the AS112 project.
We might look at the DITL data or something like that.
https://www.dns-oarc.net/oarc/data/ditl.

But yes, this is a fairly large data load.

> >From an operational point of view, it may be better to make the FQDN and addresses configurable. I can see for example how these could be configured simultaneously with STUN/TURN servers.

This would be much worse from the POV of caches: if everyone is always
asking for the same thing, then the NS set for that domain is mostly
cached in recursive resolvers.  If people ask all sorts of different
things, then they're all effectively just brand new lookups.

Moreover, the only reason for this WG to do anything at all in this
area is to get everyone to use the same name when doing this lookup.
If everyone is going to do their own thing, why standardize anything
at all? 

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Mon, 30 May 2011 22:01:04 +0000

> Can you estimate how much traffic that will generate to the IANA internet
> servers? Each transaction may be small, but if every host on the Internet does
> resolve this name each time they get powered up or move to a new network,
> we may be facing some large traffic. Do we have estimates on the efficiency of
> DNS caching? Is someone measuring that, maybe CAIDA?

Unfortunately I do not have such data, but Andrew seemed to have something.

Related to this I was asking couple of emails back if the prefix discovery should be performed only on-demand, i.e. if an application requires the information or e.g. if a host happens to implement DNSSEC recursive resolver - which I guess could be considered as an "application" as well in this regard (this btw relates to earlier email from Michael Richardson we did not yet reply - will reply later - why recursive resolver couldn't send one recursive query to find out the prefix?). 

> The examples there are problematic -- they belong to reserved range
> 127.0.0.0/8 (local host) and 192.168.0.0/16 (RFC 1918). There two issues:
> 
>  - IANA does not control allocation in these ranges, which means it cannot
> guarantee that they are not somehow reachable in the local environment;
> - RFC 6052 specifically 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]," which means that the proposed algorithm will
> never be able to detect use of the WKP.

I had missed that part of RFC6052. Good point.

How bad thing is that actually? 

Let's say that in an IPv6-only access network an application has IPv4 literal at hand. Application does NSP discovery for a well-known name having let's say RFC5736 address. However, the access network happens to be using WKP, in which case probably an empty AAAA response is returned. As the application still does not have IPv4 access, and no NSP is in use, application should perhaps just make a connectivity attempt/test by using WKP on synthesis? If WKP based address does not work out either, then host is on strictly IPv6-only access. 

In the dual-stack case an application may receive IPv6 address (from DNS) and it needs to know whether the address is synthetic or not (e.g. whether to prefer native IPv4 instead of IPv6 (say application has serious NAT64 traversal issues)), and if the application does not immediately spot WKP in the IPv6 address it received, it can check if the network happens to utilize NSP by doing a query to the well-known name. If no WKP, and no NSP, application should have a real IPv6 address.

Or would you recommend using a global IPv4 address instead to simplify logic? Personally I was afraid that it would attract unwanted traffic to selected address and I'm not sure if that is ok?

Best regards,

	Teemu

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 May 2011 19:47:14 +0000

> How bad thing is that actually? 

I would expect implementers of NPT to check the validity of addresses. If they don't, they make the networks vulnerable to all kinds of interesting attacks. So I expect that if a DNS record returns "invalid" addresses, these addresses will not be mapped. That means the very idea of "well known invalid address" is probably problematic.

> Or would you recommend using a global IPv4 address instead to simplify logic? Personally I was afraid that it would attract unwanted traffic to selected address and I'm not sure if that is ok?

I would recommend doing away with the idea of "well known FQDN and addresses" and make that a configuration parameter.

-- Christian Huitema

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 May 2011 16:18:01 -0400

> I would recommend doing away with the idea of "well known FQDN and addresses" and make that a configuration parameter.

The lookup _has to_ be a well-known name in order for this filthy hack
to be any use at all.  Either it will be one well-known name per
application (for everyone in the world using that application), or it
will be one well-known name that everyone shares.  The cache
implications are obviously in favour of the latter.

The reason it needs to be a well-known name is because otherwise,
you'd need to have some other way of learning the name you need to
query.  But if there were some mechanism by which you could learn this
name, we wouldn't need to have the name in the first place, because we
could just tell you, "Dude, you're behind a NAT64," and all would be
right with the world.

So, a configuration parameter does not help.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 May 2011 21:36:35 +0000

> The reason it needs to be a well-known name is because otherwise, you'd need to have some other way of learning the 
> name you need to query.  But if there were some mechanism by which you could learn this name, we wouldn't need to 
> have the name in the first place, because we could just tell you, "Dude, you're behind a NAT64," and all would be right 
> with the world.

I am clearly not looking at something configured via DHCP. There are plenty of configuration parameters that are not dependent on the local network. For example, my laptop is configured with the domain name of my mail server. That name will not change as the laptop moves from a coffee shop to the airport. Similarly, my SIP client is configured with the domain name of the STUN/TURN server that is uses for NAT traversal. The same SIP client could actually easily be configured with the name of the "NAT 64 discovery server."

-- Christian Huitema

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 31 May 2011 14:37:53 -0700

> So, a configuration parameter does not help.

Agreed that well known FQDN is needed and Andrew's logic.

Cameron

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 May 2011 18:06:22 -0400

On Tue, May 31, 2011 at 09:36:35PM +0000, Christian Huitema wrote:
> 
> I am clearly not looking at something configured via DHCP. There are
> plenty of configuration parameters that are not dependent on the
> local network. For example, my laptop is configured with the domain
> name of my mail server. That name will not change as the laptop
> moves from a coffee shop to the airport. Similarly, my SIP client is
> configured with the domain name of the STUN/TURN server that is uses
> for NAT traversal. The same SIP client could actually easily be
> configured with the name of the "NAT 64 discovery server."

You seem to be arguing, then, that instead of applications themselves
having a global well-known value that they know how to interpret
(which is, from a DNS point of view, already worse than a single
global one), we'll just have everyone set up their own?

I guess this has the advantage that it's easier on the DNS (it's just
one more of the usual lookups everyone is already doing), but it has
the conspicuous disadvantage that if you don't already have this
configured, you need to learn how.  I thought the point of this was
supposed to be that it would work for the most naive user?  (I'm not
trying to be argumentative.  I'm just trying to understand the use
here, since I thought something more elegant than a well-known name
was what we were going to use until I learned otherwise in Prague.)

A

-- 
Andrew Sullivan
[email-masked]