Subject: tiny v6 operational issue

From: Harald Koch <[email-masked]>
Date: Thu, 26 Sep 2002 11:30:22 -0400

The nameservers for 'ops.ietf.org' (the host for this list) are listed
as:

	DOKKA.MAXWARE.NO.
	NN.UNINETT.NO.
	PSG.COM.

PSG.COM tells me that its addresses are:

	A	147.28.0.62
	AAAA	2001:418:1::62

DNS lookups to 2001:418:1::62 give me "udp port domain unreachable".

Conclusions left as an exercise to the reader.

-- 
Harald Koch     <[email-masked]>

"It takes a child to raze a village."
		-Michael T. Fry

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Sep 2002 10:08:12 -0700

> DNS lookups to 2001:418:1::62 give me "udp port domain unreachable".

hmmm.  not sure why.  server does have

    options { ...
	listen-on { 127.0.0.1; 
                    147.28.0.62; 
		    147.28.0.34; 
		    2001:418:1::62; } ;

but thanks for bug report, despite the rather strange list to which you
chose to report it.  i guess it was more a political than technical
statement.  but i will be looking.

randy

---

From: Harald Koch <[email-masked]>
Date: Thu, 26 Sep 2002 14:02:59 -0400

> statement.  but i will be looking.

Well, my only dealings with 'ops.ietf.org' are through the mailing list;
I found it particularly amusing in that context. Not a political
statement at all, but I guess people will read almost anything between
the lines these days.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Sep 2002 11:58:51 -0700

> 	listen-on { 127.0.0.1; 

so, pekka pointed out that bind is a bit convoluted here, and that won't
work.

    	listen-on-v6 { any; };

did.  thanks pekka.

randy

---

From: [email-masked]
Date: Fri, 27 Sep 2002 13:03:38 +0900

>Conclusions left as an exercise to the reader.

	it's not a problem, an FQDN identifies a host (or interface in IPv6
	case) and not services.

itojun

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 00:54:57 -0400

>         it's not a problem, an FQDN identifies a host (or interface in IPv6

not in the last 10 or so years it doesn't.

---

From: Atsushi Onoe <[email-masked]>
Date: Fri, 27 Sep 2002 14:04:41 +0900 (JST)

> 	it's not a problem, an FQDN identifies a host (or interface in IPv6

It _IS_ a problem.  It is effectively same condition as that the NS records
point to a server where name server is not running.  Of course, there is
a chance to resolve by next available address or NS.  But it IS a bogus
configuration anyway, since it forces unneeded traffic and delay.

Atsushi Onoe

---

From: Harald Koch <[email-masked]>
Date: Fri, 27 Sep 2002 09:50:05 -0400

> configuration anyway, since it forces unneeded traffic and delay.

The resolver(s) on my hosts (RH 7.2) do not fall back to the IPv4
address if the IPv6 address is unreachable. This is definitely a bug on
the client side, but still aggravated the problem.

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Sep 2002 07:16:34 -0700

> the client side, but still aggravated the problem.

hey, it discovered my bug!

i wonder if doc needs to be updated to check this.

randy

---

From: [email-masked]
Date: Fri, 27 Sep 2002 23:36:08 +0900

>> the client side, but still aggravated the problem.

	could you name the implementation?  i bet it is not the resolver in
	libc, as it won't traverse NS tree.

itojun

---

From: Atsushi Onoe <[email-masked]>
Date: Fri, 27 Sep 2002 23:53:18 +0900 (JST)

> i wonder if doc needs to be updated to check this.

It should be documented here in v6ops since it is not a dns problem but
general problems among services.  I.e. if you put AAAA record to a node,
all the services at the node should be served also via IPv6.  Otherwise,
the FQDN should be splitted between the services which served only via
IPv4 and served via IPv6/IPv4.

Again, a client should be robust against such environment by trying all
the addresses available.  But the configuration for servers should avoid
such inefficiency.

Atsushi Onoe

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Sep 2002 08:05:44 -0700

> IPv4 and served via IPv6/IPv4.

it is obvious to me that one must provide all services on all
addresses.  given

   foo.bar.  A    1.2.3.4
	     A	  5.6.7.8
	     AAAA 2001:666:777::42

we do not currently require that all services provided on 1.2.3.4
also be provided on 5.6.7.8.  so how can we explain doing so for
2001:666:777::42?

and the splitting suggestion seems to put more semantics in names
than the dns folk may feel appropriate.

i suspect you are trying to bind more semantics to the dns than are
generally expected there.

randy

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 28 Sep 2002 03:18:45 +0200

> also be provided on 5.6.7.8.  so how can we explain doing so for

"We" don't have too. IPv6 capable software _should_ use getaddrinfo()
This call nicely returns a set of host/port combo's to connect to and
the software should walk this list till it is able to fulfill it's job.
Check out, the 4 year old doc: http://www.kame.net/newsletter/19980604/
And one can instruct getaddrinfo() to only return say AF_INET6 etc.

Greets,
 Jeroen

PS: Yeah yeah I know PuTTY doesn't fall back to IPv4 if the IPv6
connection fails, don't kick me now I am down, I admit, I admit :)