Subject: "DNS-4to6 automatic mapping" - No more DNS-ALGs & 6then4 DNS queries

From: "despres.remi" <[email-masked]>
Date: Sun, 25 Nov 2007 19:00:46 +0100 (CET)

Currently proposed solutions for IPv6-only to IPv4-only connectivity
include some specific DNS processing, at the application layer, outside
the DNS itself : DNS-ALGs in various NAT-PTs; duplicated DNS queries
(IPv6 and IPv4) in IPv6-capable applications and/or stacks).

The result is significant complexity (with timers in particular),
additional traffic across the network, and potential operational
problems with DNS ALGs.

Also, one can see on the Web recommendations that IPv6 capable
applications, Firefox in particular, should DISABLE IPv6 (!!!).
The reason is that DNS queries to reach IPv4-only hosts are in two steps
instead of one : one for an IPv6 address, failing most of the time, and,
only then, one for an IPv4 address, succeeding most of the time.

All this is UNFORTUNATE but, being avoidable as shown below, IMHO SHOULD BE
AVOIDED in the future).

For this, let's specify that a next release of the DNS sotware (BIND and
others) will have to include a DNS-4to6 AUTOMATIC MAPPING.
With it, an IPv6 RR is automatically created, within the DNS, for each
existing IPv4 RR, using for this the *mapped address format* of RFC 2373.
There is no scalability issue, this being a "one-time" processing.
Deployment of this DNS automatic mapping is simply the deployment of a
new release of the DNS software (a fairly wellknown process).

Then :
- IPv6-only applications on dual stacks will work using IPv4 transport
without knowing about it.(The answer to their IPv6 request is in fact an
IPv4 address, in the format recognized by the lower layer dual stack to select IPv4 transport).
- IPv4-IPv6 applications will no longer need a second DNS query to reach
IPv4-only hosts.

This seems to me as simple and effective as a Columbus egg.
If this is wrong, please describe why.
And if this is right, how could this proceed in Vancouver? (I cannot be
there).

Regards.

Rémi

 Créez votre adresse électronique [email-masked] 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2007 13:46:58 -0800

> existing IPv4 RR, using for this the *mapped address format* of RFC

You can achieve pretty much the same result by placing the A records in the additional section of responses to AAAA queries, without creating a need for mapped addresses. This could be done very simply, but changing DNS implementations for IPv6 capable servers will only solve part of the operational problems encountered today.

The worst case scenario happens when the target domain's server does not know about IPv6, and treat arrival of AAAA requests as some kind of error. Poorly implemented error paths lead can lead to bad behavior. For example, some servers responded with "no such name" instead of "no such record", leading clients to mistakenly abort HTTP queries. This is a much worse problem than simply having to repeat a query!

These operational problems are direct consequences of the current IETF recommendation to always ask first for the AAAA record if the client is IPv6 capable. This is a very aggressive stance, designed to maximize the occurrence of IPv6 connections. If we wanted to smooth transition, we could take a softer stance, e.g. let dual-stack hosts only send AAAA queries if it can reasonably presume that the target server is IPv6 capable.

-- Christian Huitema

---

From: "Erik Kline" <[email-masked]>
Date: Sun, 25 Nov 2007 21:40:06 -0800

> These operational problems are direct consequences of the current IETF recommendation to always ask first for the AAAA record if the client is IPv6 capable. This is a very aggressive stance, design…

Out of curiosity: how would a machine determine what it can
"reasonably presume" to be IPv6 capable?  Some locally administrated
policy directives for the host's resolver?

Separately: I wonder if there was any discussion of creating a DNS rr
query type with the essential meaning "A*", i.e. give me A records,
AAAA, A6 (while they were being tried), hence A*.  (If there already
is such a thing I apologize profusely for my ignorance.)  The host or
application can then decide what to do with the returned results
according to local policy as implemented/implementable by the local
resolver.  Of course the same could be done with a single packet
exchange if the server could be relied upon to place extra records of
the non-queried-for type in the response, but saying that a
multiple-address-family-capable machine makes an A* query (instead of
AAAA) codifies the behaviour.  Random thought, I know.

-Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Nov 2007 10:42:22 +0100

>>> existing IPv4 RR, using for this the *mapped address format* of RFC

The question is: do we really have a problem?

Yes, people recommend turning off IPv6 on forums here and there, but  
this used to be because there were some DNS servers out there that  
would reply with an error when queried for AAAA records. That problem  
has been solved 99.9%, unless I'm mistaken. Also, apparently turning  
off IPv6 helps agains all kinds of problems that are provably IPv6- 
unrelated.

I think any effort would be better spent by making sure OSes don't  
send AAAA queries when there is no IPv6 connectivity.

>> You can achieve pretty much the same result by placing the A  
>> records in the additional section of responses to AAAA queries,  
>> without creating a need for mapped addresses. This could be done  
>> very simply, but changing DNS implementations for IPv6 capable  
>> servers will only solve part of the operational problems  
>> encountered today.

Right.

>> These operational problems are direct consequences of the current  
>> IETF recommendation to always ask first for the AAAA record if the  
>> client is IPv6 capable. This is a very aggressive stance, designed  
>> to maximize the occurrence of IPv6 connections. If we wanted to  
>> smooth transition, we could take a softer stance, e.g. let dual- 
>> stack hosts only send AAAA queries if it can reasonably presume  
>> that the target server is IPv6 capable.

> policy directives for the host's resolver?

Indeed. There is no way to know that without asking for AAAA records.

The problem with implementing new features that aren't actually used  
(which is what happens if you prefer A records - something Windows  
users can do manually using the policy table, by the way) is that over  
time broken behavior grows and then when usage finally occurs it  
doesn't work. Examples:

- HTTP pipelining
- ECN bits
- path MTU discovery

And so on.

If people don't want to use IPv6 they should either disable the  
protocol or set up an appropriate RFC 3484 policy table. If IPv6  
connectivity is available, the only reasonable thing to do is prefer  
that by default.
> AAAA, A6 (while they were being tried), hence A*.

There already is a * query type but I gather that trouble with that is  
that it won't go out and make sure that copies of all possible records  
are available, if there is something in the cache you get that.

The problem with a new query type is that you could end up asking for:

A*
AAAA
A

Which takes longer than:

AAAA
A

But again: do we really have a problem? The first query can take some  
time because the delegation tree must be traversed at least partially,  
but after that the following query(ies) can go directly to the  
authorative server so the delay is minimal.

---

From: Nathan Ward <[email-masked]>
Date: Thu, 29 Nov 2007 16:45:40 +1300

On 26/11/2007, at 10:42 PM, Iljitsch van Beijnum wrote:
> would reply with an error when queried for AAAA records. That  
> problem has been solved 99.9%, unless I'm mistaken. Also, apparently  
> turning off IPv6 helps agains all kinds of problems that are  
> provably IPv6-unrelated.
>

I agree with this.
The major case that I see is Windows firing up 6to4 when it has a non- 
RFC1918 address, when it's connectivity is filtered or NATed.

What other common cases are there, that are not due to  
misconfiguration (i.e. IPv6 `default' route configured on an interface/ 
link without IPv6 transit doesn't count).

--
Nathan Ward

---

From: "Todd T. Fries" <[email-masked]>
Date: Wed, 28 Nov 2007 22:26:21 -0600

I'm sorry, turning off IPv6 routing does not imply the userland should not
and cannot query for v6 addresses.  That's just bogus.  The operating system
can inform the application that the v6 address has no route, and the
application can try the next address, just as if it were a v4 host with
multiple v4 addresses, and the first one is not reachable, only faster,
because no default route means the application will get notified much
sooner.

Thanks,
-- 
Todd Fries .. [email-masked]

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Penned by Nathan Ward on 20071129 16:45.40, we have:
>> Yes, people recommend turning off IPv6 on forums here and there, but this 
>> used to be because there were some DNS servers out there that would reply 
>> with an error when queried for AAAA records. That problem has been solved 
>> 99.9%, unless I'm mistaken. Also, apparently turning off IPv6 helps agains 
>> all kinds of problems that are provably IPv6-unrelated.
>>
>> I think any effort would be better spent by making sure OSes don't send 
>> AAAA queries when there is no IPv6 connectivity.
>
>
> I agree with this.
> The major case that I see is Windows firing up 6to4 when it has a 
> non-RFC1918 address, when it's connectivity is filtered or NATed.
>
> What other common cases are there, that are not due to misconfiguration 
> (i.e. IPv6 `default' route configured on an interface/link without IPv6 
> transit doesn't count).
>
> --
> Nathan Ward
>
>
>
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Nov 2007 08:58:34 +0100

Hi,

On Wed, Nov 28, 2007 at 10:26:21PM -0600, Todd T. Fries wrote:
> and cannot query for v6 addresses.  That's just bogus.  

There's a difference between

 "the application explicitely asks for AAAA records"

and

 "the application wants to connect to a given host, by whatever means"

in the first case, it's clear that the operating system has no reason
to stand in the application's way.

In the second case, querying for AAAA/A6 addresses makes not very much 
sense if the OS *knows* that it has no way to actually reach such an 
address (e.g.: the IPv6 stack is not loaded).

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Remi Denis-Courmont <[email-masked]>
Date: Thu, 29 Nov 2007 12:17:15 +0100

On Wed, 28 Nov 2007 22:26:21 -0600, "Todd T. Fries" <[email-masked]> wrote:

> I'm sorry, turning off IPv6 routing does not imply the userland should

not

> and cannot query for v6 addresses.  That's just bogus.  The operating

> system

> sooner.

Like it or not, just about every major dual-stackable operating system

"fail" to query AAAA RRs if the host has no IPv6 address except for

loopback and link-local ones.

There are simply way too many broken DNS servers and somewhat-DNS-aware

middleboxes in the field that screw up on AAAA queries.

Besides, if an application really wants to resolve a name to an IPv6

address, it can probably request it explicitly (e.g.

hints.ai_family = PF_INET6 with getaddrinfo()). Still, from a

connectivity perspective, you would normally not be using DNS for

loopback (::1). And you simply cannot use DNS for link-local

addressing, since link-local addresses require a host-specific

scope, which DNS cannot provide.

Since this part of the problem is essentially fixed in the field,

I think the main remaining issue is what Nathan describes - lame

automatic 6to4 deployment.

-- 

Rémi

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 29 Nov 2007 06:19:25 -0600

Make all the distinguishing you wish.

The bottom line is that OpenBSD userland unconditionally enables IPv6
regardless if the kernel supports it or not.  If there is no v6 default
route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh, etc)
and behaves sanely.

I do not see why mandating different is productive for a future of v6
deployment.
-- 
Todd Fries .. [email-masked]

| "..in support of free software solutions."  \  1.700.227.9094 (IAXTEL)
|                                             \          250797 (FWD)

Penned by Gert Doering on 20071129  8:58.34, we have:
| Hi,
| 
| On Wed, Nov 28, 2007 at 10:26:21PM -0600, Todd T. Fries wrote:
| > I'm sorry, turning off IPv6 routing does not imply the userland should not
| > and cannot query for v6 addresses.  That's just bogus.  
| 
| There's a difference between
| 
|  "the application explicitely asks for AAAA records"
| 
| and
| 
|  "the application wants to connect to a given host, by whatever means"
| 
| in the first case, it's clear that the operating system has no reason
| to stand in the application's way.
| 
| In the second case, querying for AAAA/A6 addresses makes not very much 
| sense if the OS *knows* that it has no way to actually reach such an 
| address (e.g.: the IPv6 stack is not loaded).
| 
| Gert Doering
|         -- NetMaster
| -- 
| Total number of prefixes smaller than registry allocations:  110584
| 
| SpaceNet AG                        Vorstand: Sebastian v. Bomhard
| Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
| D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
| Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 29 Nov 2007 06:28:46 -0600

fails to query AAAA records unless the application explicitly requests it?

How hard are we trying to make the transition?

*sigh*

Penned by Remi Denis-Courmont on 20071129 12:17.15, we have:
| 
| On Wed, 28 Nov 2007 22:26:21 -0600, "Todd T. Fries" <[email-masked]> wrote:
| > I'm sorry, turning off IPv6 routing does not imply the userland should
| not
| > and cannot query for v6 addresses.  That's just bogus.  The operating
| > system
| > can inform the application that the v6 address has no route, and the
| > application can try the next address, just as if it were a v4 host with
| > multiple v4 addresses, and the first one is not reachable, only faster,
| > because no default route means the application will get notified much
| > sooner.
| 
| Like it or not, just about every major dual-stackable operating system
| "fail" to query AAAA RRs if the host has no IPv6 address except for
| loopback and link-local ones.
| There are simply way too many broken DNS servers and somewhat-DNS-aware
| middleboxes in the field that screw up on AAAA queries.
| 
| Besides, if an application really wants to resolve a name to an IPv6
| address, it can probably request it explicitly (e.g.
| hints.ai_family = PF_INET6 with getaddrinfo()). Still, from a
| connectivity perspective, you would normally not be using DNS for
| loopback (::1). And you simply cannot use DNS for link-local
| addressing, since link-local addresses require a host-specific
| scope, which DNS cannot provide.
| 
| 
| Since this part of the problem is essentially fixed in the field,
| I think the main remaining issue is what Nathan describes - lame
| automatic 6to4 deployment.
| 
| -- 
| R??mi

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Nov 2007 13:51:28 +0100

Hi,

> Make all the distinguishing you wish.

Thanks for your well-reflected views on a one-size-fits-all reality :-)

> route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh, etc)

Aah, OpenBSD.  Now, of course, OpenBSD is always right, and the single
point of reference on how operating systems should work.

The initial topic on this thread was "can we avoid extra DNS queries that
have no value, but may cause operational issues".

What happens *afterward*, whether or not the connection fails "quickly" 
or "slowly", is really of not much interest for the question under
discussion.

Gert Doering
        -- NetMaster

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Nov 2007 14:10:30 +0100

> I do not see why mandating different is productive for a future of v6

I for one am glad that my OS of choice is smart enough to avoid this  
unnecessary extra work. If your users don't mind this "you checked the  
box during installation so now I'm going to waste time for each DNS  
lookup even though a quick look at the routing table could avoid that"  
approach, I agree that the IETF should probably not force you to do  
things differently.

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 29 Nov 2007 07:19:37 -0600

I guess the concept of just working is overrated also.

I do not think we have time to debate the finer points of eeking operational
overhead by asking vendors to not query AAAA just because a v6 stack/default
route is not enabled.... versus telling vendors where dns servers are broken
and fixing things to pave the way for adoption of v6 wholesale.

I am sorry you see me as a one size fits all mentality associated with
OpenBSD.  I simply mention it as one os vendor that does the opposite of
what you suggest.  I would be surprised if there are not others.

To me, removing AAAA queries based upon conditions adds more complexity
and does not provide a consistent user experience and is a step backwards
rather than a step forwards.

You will, however, get no complaints from me regarding BCP of not querying
A6; this was deprecated years ago...

Think about it, you want userland to query the kernel for v6 support and
further for a v6 default route before each potential AAAA query?  This seems
rather complex and fragile and has overhead that to me is worse than
unconditionally sending the AAAA requests.

You want a user to note that a host has no v6 record, on a v4 only node,
yet suddenly discover there is a v6 record on a v6 enabled node?  How insane
is this?  Suddenly starting to pull wool across eyes is what this sounds
like.  I much prefer to verify my dns is sending out v6 results even from a v4
only node than to alter something that I (and I suspect I am not alone)
expect to work today.

How can asking vendors to add more special casing to v6 code to hide v6
rather than enabling it by default be a step forward?

I for one, regardless of my os of choice, see the scenario you propose
to be a giant leap backwards.

Thanks,

Penned by Gert Doering on 20071129 13:51.28, we have:
| Hi,
| 
| On Thu, Nov 29, 2007 at 06:19:25AM -0600, Todd T. Fries wrote:
| > Make all the distinguishing you wish.
| 
| Thanks for your well-reflected views on a one-size-fits-all reality :-)
| 
| > The bottom line is that OpenBSD userland unconditionally enables IPv6
| > regardless if the kernel supports it or not.  If there is no v6 default
| > route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh, etc)
| > and behaves sanely.
| 
| Aah, OpenBSD.  Now, of course, OpenBSD is always right, and the single
| point of reference on how operating systems should work.
| 
| The initial topic on this thread was "can we avoid extra DNS queries that
| have no value, but may cause operational issues".
| 
| What happens *afterward*, whether or not the connection fails "quickly" 
| or "slowly", is really of not much interest for the question under
| discussion.
| 
| Gert Doering
|         -- NetMaster
| -- 
| Total number of prefixes smaller than registry allocations:  110584
| 
| SpaceNet AG                        Vorstand: Sebastian v. Bomhard
| Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
| D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
| Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Todd T. Fries" <[email-masked]>
Date: Thu, 29 Nov 2007 07:24:45 -0600

What box?  There is no box to enable v6 on OpenBSD.  The only place
in OpenBSD that does not have v6 enabled by default is in a few install
media kernels, which do not have space for v6.  The userland ftp utility,
used for retrieving images, fails most gracefully when given a hostname
that has both v4 and v6 addresses, it tries the v6, fails immediately,
and then uses the v4 address.

I guess you have not tried OpenBSD since you seem to think there are
options check boxes that enable/disable v6 entirely during the installation.
-- 
Todd Fries .. [email-masked]

Penned by Iljitsch van Beijnum on 20071129 14:10.30, we have:
| On 29 nov 2007, at 13:19, Todd T. Fries wrote:
| 
| >The bottom line is that OpenBSD userland unconditionally enables IPv6
| >regardless if the kernel supports it or not.  If there is no v6  
| >default
| >route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh,  
| >etc)
| >and behaves sanely.
| 
| >I do not see why mandating different is productive for a future of v6
| >deployment.
| 
| I for one am glad that my OS of choice is smart enough to avoid this  
| unnecessary extra work. If your users don't mind this "you checked the  
| box during installation so now I'm going to waste time for each DNS  
| lookup even though a quick look at the routing table could avoid that"  
| approach, I agree that the IETF should probably not force you to do  
| things differently.

---

From: [email-masked]
Date: Thu, 29 Nov 2007 12:18:59 -0600

So we hack the os to fix the broken dns servers. whee!  Progress!
-- 
Todd Fries .. [email-masked]

Penned by R?mi Denis-Courmont on 20071129 20:17.33, we have:
| Le Thursday 29 November 2007 14:19:25 Todd T. Fries, vous avez ?crit?:
| > The bottom line is that OpenBSD userland unconditionally enables IPv6
| > regardless if the kernel supports it or not.  If there is no v6 default
| > route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh, etc)
| > and behaves sanely.
| 
| Great, so lets put said OpenBSD behind one of many cheap CPE that drops or 
| otherwise screws up DNS AAAA query packets.
| 
| I fail to see how not having a default v6 route saves you from waiting for the 
| DNS query timeout (remember the DNS AAAA request will be sent over IPv4).
| 
| > I do not see why mandating different is productive for a future of v6
| > deployment.
| 
| Because it avoids lengthy time outs when AAAA DNS breaks. Without this hack, 
| more people will be annoyed by the dual stack nature of their OS and learn to 
| disable IPv6 *completely*.
| 
| See also RFC4472.
| 
| -- 
| R?mi Denis-Courmont
| http://www.remlab.net/

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 29 Nov 2007 20:19:56 +0200

> How hard are we trying to make the transition?

How hard are you trying to misrepresent my comment?

I said *IF* there are no IPv6 addresses beyond loopback and link-local ones, 
didn't I? What's the use of querying by *default* if we know IPv6 
connectivity is absent?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 29 Nov 2007 20:17:33 +0200

> route, v6 fails quickly and seamlessly back to v4 (telnet, ftp, ssh, etc)

Great, so lets put said OpenBSD behind one of many cheap CPE that drops or 
otherwise screws up DNS AAAA query packets.

I fail to see how not having a default v6 route saves you from waiting for the 
DNS query timeout (remember the DNS AAAA request will be sent over IPv4).

> I do not see why mandating different is productive for a future of v6

Because it avoids lengthy time outs when AAAA DNS breaks. Without this hack, 
more people will be annoyed by the dual stack nature of their OS and learn to 
disable IPv6 *completely*.

See also RFC4472.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked]
Date: Thu, 29 Nov 2007 12:28:33 -0600

I know exactly what you said.

The use is, if I have some app that is generating reports or doing things
other than connecting to IPv6 addresses where returning IPv6 addresses
would be useful.

Don't presume the only thing dns resolution is for is to connect to the
addresses being resolved.

What if you want to debug the dns output of your dns server from a v4 only
node, but want to verify it's outputing v6 records?

By your semantics, you'd not see the v6 on a v4 only node.

I don't think this is right.
-- 
Todd Fries .. [email-masked]

Penned by R?mi Denis-Courmont on 20071129 20:19.56, we have:
| Le Thursday 29 November 2007 14:28:46 Todd T. Fries, vous avez ?crit?:
| > fails to query AAAA records unless the application explicitly requests it?
| >
| > How hard are we trying to make the transition?
| 
| How hard are you trying to misrepresent my comment?
| 
| I said *IF* there are no IPv6 addresses beyond loopback and link-local ones, 
| didn't I? What's the use of querying by *default* if we know IPv6 
| connectivity is absent?
| 
| -- 
| R?mi Denis-Courmont
| http://www.remlab.net/

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 29 Nov 2007 20:29:48 +0200

> So we hack the os to fix the broken dns servers. whee!  Progress!

Does OpenBSD refuse to work behind a NAT because it is not legal from RFC 
perspective? Silly me, I almost forgot the pf own NAT implementation did not 
even remotely match the IETF BEHAVE specifications.

There is a (rather small) market for OSes that do everything "right" from a 
technical perspective, and there is a (rather large) market for OSes that 
just works. As it happens, OpenBSD can afford to aim only at the first 
market - good for you! Conversely, most computer users cannot afford to use 
OpenBSD.

As such, I don't think we want to limit the relevance of IETF to *only* the 
do-things-right market.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 29 Nov 2007 20:33:09 +0200

> node, but want to verify it's outputing v6 records?

Then you are probably capable of setting up OpenBSD, or alternatively using 
ISC BIND dig to query AAAA, A and ANY RR types explicitly (or both).

> I don't think this is right.

I *know* it's not right. However, I claim it's pragmatic.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked]
Date: Thu, 29 Nov 2007 12:36:34 -0600

So any app that needs to resolve things in a consistent manner must fork and
exec dig?

Nice.

Penned by R?mi Denis-Courmont on 20071129 20:33.09, we have:
| Le Thursday 29 November 2007 20:28:33 [email-masked], vous avez ?crit?:
| > The use is, if I have some app that is generating reports or doing things
| > other than connecting to IPv6 addresses where returning IPv6 addresses
| > would be useful.
| >
| > Don't presume the only thing dns resolution is for is to connect to the
| > addresses being resolved.
| >
| > What if you want to debug the dns output of your dns server from a v4 only
| > node, but want to verify it's outputing v6 records?
| 
| Then you are probably capable of setting up OpenBSD, or alternatively using 
| ISC BIND dig to query AAAA, A and ANY RR types explicitly (or both).
| 
| > By your semantics, you'd not see the v6 on a v4 only node.
| 
| > I don't think this is right.
| 
| I *know* it's not right. However, I claim it's pragmatic.
| 
| -- 
| R?mi Denis-Courmont
| http://www.remlab.net/

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Nov 2007 19:48:14 +0100

Hi,

> other than connecting to IPv6 addresses where returning IPv6 addresses

There is a difference between an app querying *for IPv6 addresses* and
an app querying "give me something to connect to".  Please try to get that
into your head.

Nobody is trying to refuse an app's explicit AAAA queries.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 29 Nov 2007 12:50:24 -0600

Why does an app have to explicitly ask for AAAA queries?

Why can I not write apps that expect that getaddrinfo() when passed a hint
of AF_UNSPEC .. will return all addresses, v6 or v4?
-- 
Todd Fries .. [email-masked]

Penned by Gert Doering on 20071129 19:48.14, we have:
| Hi,
| 
| On Thu, Nov 29, 2007 at 12:28:33PM -0600, [email-masked] wrote:
| > I know exactly what you said.
| > 
| > The use is, if I have some app that is generating reports or doing things
| > other than connecting to IPv6 addresses where returning IPv6 addresses
| > would be useful.
| 
| There is a difference between an app querying *for IPv6 addresses* and
| an app querying "give me something to connect to".  Please try to get that
| into your head.
| 
| Nobody is trying to refuse an app's explicit AAAA queries.
| 
| Gert Doering
|         -- NetMaster
| -- 
| Total number of prefixes smaller than registry allocations:  110584
| 
| SpaceNet AG                        Vorstand: Sebastian v. Bomhard
| Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
| D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
| Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 29 Nov 2007 20:00:45 +0100

> Nobody is trying to refuse an app's explicit AAAA queries.

But from an application perspective there is no such thing.

Applications are nowdays supposed to use getaddrinfo() / getnameinfo(),
the first one is patched in eg glibc to not return AAAA's when the
caller asks for an ANY record, eg "please show me all the records for
example.com", if that is for connecting or not.

Apps that need to connect (the ones we are discussing here) have to
specify AI_ADDRCONFIG. Apps that don't (the ones Todd mention)

As such this is already present, BUT a lot of applications (including
quite a few of mine) don't use it, as it is a relatively new flag.
That flag was also only introduced in glibc 2.3.3.

The real fix to this discussion: fix the apps.

Fixing the DNS would also help of course but that is even more cumbersome.

Greets,
 Jeroen

---

From: Gert Doering <[email-masked]>
Date: Thu, 29 Nov 2007 21:10:58 +0100

Hi,

> of AF_UNSPEC .. will return all addresses, v6 or v4?

Sure you can, but what's the benefit for that application?

Actually this is nitpicking.  The *real* problem is that the systems need a
"connect me to this host*name*" system/library call, that will handle all 
the underlying combinations and do the right thing, depending on system
preferences and capabilities.

Forcing each application to invent its own getaddrinfo()/loop-over-addresses
loop, possibly delaying connections due to IPv6 or IPv4 blackholes "out
there" (because normally this isn't done in parallel, but in sequence),
is just "last century coding".

Gert Doering
        -- NetMaster

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Nov 2007 22:40:48 -0800

> Actually this is nitpicking.  The *real* problem is that the systems
> need a "connect me to this host*name*" system/library call, that will
> handle all the underlying combinations and do the right thing, depending
> on system preferences and capabilities.

Do you mean something like WSAConnectByName (http://msdn2.microsoft.com/en-us/library/ms741557.aspx)? Or maybe "TcpClient.Connect (String, Int32)" (http://msdn2.microsoft.com/en-us/library/system.net.sockets.tcpclient.connect.aspx)?

-- Christian Huitema

---

From: Gert Doering <[email-masked]>
Date: Fri, 30 Nov 2007 08:55:10 +0100

Hi,

On Thu, Nov 29, 2007 at 10:40:48PM -0800, Christian Huitema wrote:
> Do you mean something like WSAConnectByName (http://msdn2.microsoft.com/en-us/library/ms741557.aspx)? Or maybe "TcpClient.Connect (String, Int32)" 
> (http://msdn2.microsoft.com/en-us/library/system.net.sockets.tcpclient.connect.aspx)?

Exactly something like this.

(A bit more generic than "TcpClient.Connect", though.  Why TCP only?  What
about SCTP?)

And not only for windows, but standardized across all platforms in more
widespread use.

Gert Doering
        -- NetMaster

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Nov 2007 10:20:07 -0800

> Do you mean something like WSAConnectByName (http://msdn2.microsoft.com/en-us/library/ms741557.aspx)? Or maybe "TcpClient.Connect (String, Int32)" (http://msdn2.microsoft.com/en-us/library/system.n…

Or something like:
https://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#Socket(java.lang.String,%20int)

TCP is trivial to do.

Providing the same capability for applications that use UDP is harder, 
since one would have to involve the application to get feedback whether 
a particular IP address worked or not; TCP gets this from the SYN|ACK 
without application involvement.

   Erik