What to do about broken IPv6 sites

For example, http://www.ntp.org.

NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't answer
to SYNs. I have no problem with other IPv6 sites, but maybe I'll find
some in the future.

Since RFC-compliant behavior is to try the IPv6 address first, I have to
timeout on every page element before switching to IPv4.

I was wondering what the options are to deal with the situation. I
don't have control of the ntp.org DNS domain (or any other broken
domains I might find). Keeping a list in iptables for special behaviors
for specific IPv6 addresses really isn't attractive.

As more sites put up IPv6 versions, I expect there to be a lot of
brokenness that won't be a high priority to fix as long as 99% of
everybody is still on IPv4. What's the most manageable way to deal with
this?

Allen Kistler <(E-Mail Removed)> wrote:
> For example, http://www.ntp.org.

> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't
> answer to SYNs. I have no problem with other IPv6 sites, but maybe
> I'll find some in the future.

> Since RFC-compliant behavior is to try the IPv6 address first, I
> have to timeout on every page element before switching to IPv4.

> I was wondering what the options are to deal with the situation. I
> don't have control of the ntp.org DNS domain (or any other broken
> domains I might find). Keeping a list in iptables for special
> behaviors for specific IPv6 addresses really isn't attractive.

> As more sites put up IPv6 versions, I expect there to be a lot of
> brokenness that won't be a high priority to fix as long as 99% of
> everybody is still on IPv4. What's the most manageable way to deal
> with this?

I don't know about the general question, but there are likely folks in
comp.protocols.time.ntp who know about the www.ntp.org site and its
IPv6 status, so lets redirect the specific issue there. (I've set the
Followup-to: header on this post to that end)

rick jones
--
I don't interest myself in "why". I think more often in terms of
"when", sometimes "where"; always "how much." - Joubert
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Allen Kistler <(E-Mail Removed)> wrote:
> For example, http://www.ntp.org.

> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't
> answer to SYNs. I have no problem with other IPv6 sites, but maybe
> I'll find some in the future.

> Since RFC-compliant behavior is to try the IPv6 address first, I
> have to timeout on every page element before switching to IPv4.

Specifically which RFC(s)? And is it stated as a MUST or as a SHOULD
in the text?

rick jones
--
portable adj, code that compiles under more than one compiler
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Hello,

Allen Kistler a écrit :
> For example, http://www.ntp.org.
>
> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't answer
> to SYNs.

Weird. I can browse it through IPv6, and get answers to my IPv6 SYNs :

$ nmap -6 -p 22,25,80,110 www.ntp.org

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-06-19 20:50
CEST
Interesting ports on ntp2.ntp.isc.org (2001:4f8:0:2::23):
PORT STATE SERVICE
22/tcp filtered ssh
25/tcp open smtp
80/tcp open http
110/tcp filtered pop3

"filtered" here means that it (actually the firewall/router just before
it) replies with an ICMPv6 "communication prohibited".

> Since RFC-compliant behavior is to try the IPv6 address first, I have to
> timeout on every page element before switching to IPv4.
>
> I was wondering what the options are to deal with the situation. I
> don't have control of the ntp.org DNS domain (or any other broken
> domains I might find). Keeping a list in iptables for special behaviors
> for specific IPv6 addresses really isn't attractive.

RFC 3484 describes an address selection mechanism for IPv6. It is
implemented in recent versions (don't ask me numbers) of the glibc
through /etc/gai.conf (GetAddressInfo configuration file). By default
the IPv4 address space (in its IPv6 mapped form of ::ffff:0:0/96) has
the lowest precedence. You could increase its precedence above the
precedence of other IPv6 prefixes so IPv4 addresses are sorted first.

Rick Jones wrote:
> Allen Kistler <(E-Mail Removed)> wrote:
>> For example, http://www.ntp.org.
>
>> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't
>> answer to SYNs. I have no problem with other IPv6 sites, but maybe
>> I'll find some in the future.
>
>> Since RFC-compliant behavior is to try the IPv6 address first, I
>> have to timeout on every page element before switching to IPv4.
>
> Specifically which RFC(s)? And is it stated as a MUST or as a SHOULD
> in the text?

RFC 3484 - Default Address Selection for Internet Protocol version 6
RFC 5220 - Problem Statement for Default Address Selection in
Multi-Prefix Environments: Operational Issues of RFC 3484
Default Rules

3484 is the main one. It's light on the use of MUST and SHOULD.
Instead it uses words like "default" and "preferred."

Pascal Hambourg wrote:
> Allen Kistler a écrit :
>> For example, http://www.ntp.org.
>>
>> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't
>> answer to SYNs.
>
> Weird. I can browse it through IPv6, and get answers to my IPv6 SYNs :
>
> $ nmap -6 -p 22,25,80,110 www.ntp.org
>
> Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-06-19 20:50
> CEST
> Interesting ports on ntp2.ntp.isc.org (2001:4f8:0:2::23):
> PORT STATE SERVICE
> 22/tcp filtered ssh
> 25/tcp open smtp
> 80/tcp open http
> 110/tcp filtered pop3

For me, I need -P0 because it won't even ping:

# nmap -6 -p 22,25,80,110 -P0 www.ntp.org

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-06-20 00:15 CDT
Interesting ports on ntp2.ntp.isc.org (2001:4f8:0:2::23):
PORT STATE SERVICE
22/tcp filtered ssh
25/tcp filtered smtp
80/tcp filtered http
110/tcp filtered pop3


Compare to www.kame.net:

# nmap -6 -p 22,25,80,110 www.kame.net

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-06-20 00:19 CDT
Interesting ports on orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085):
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3

> "filtered" here means that it (actually the firewall/router just before
> it) replies with an ICMPv6 "communication prohibited".

"filtered" means the packet is dropped.
"closed" is what you get when there's an ICMP error response.

>> Since RFC-compliant behavior is to try the IPv6 address first, I have
>> to timeout on every page element before switching to IPv4.
>>
>> I was wondering what the options are to deal with the situation. I
>> don't have control of the ntp.org DNS domain (or any other broken
>> domains I might find). Keeping a list in iptables for special
>> behaviors for specific IPv6 addresses really isn't attractive.
>
> RFC 3484 describes an address selection mechanism for IPv6. It is
> implemented in recent versions (don't ask me numbers) of the glibc
> through /etc/gai.conf (GetAddressInfo configuration file). By default
> the IPv4 address space (in its IPv6 mapped form of ::ffff:0:0/96) has
> the lowest precedence. You could increase its precedence above the
> precedence of other IPv6 prefixes so IPv4 addresses are sorted first.

gai.conf is good info. There's even a man page on it, although the
distinction between label and precedence is lost on me. It says if any
label directive is present, the default table is not used. Then it says
precedence is different from label, because if any precedence directive
is present, the default table is not used. So ... it's different
because it's the same? Whatever.

Closer to what I was asking, though, would be to put
2001:4f8:0:2::23/128 in gai.conf and to give it a really low precedence.
That way I'm not turning IPv6 into IPv4 for everything.

I put www.ntp.org's IPv6 address as the lowest precedence ...

label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label 2001:4f8:0:2::23/128 5
precendence ::1/128 60
precendence ::/0 50
precendence 2002::/16 40
precendence ::/96 30
precendence ::ffff:0:0/96 20
precendence 2001:4f8:0:2::23/128 10

.... but it didn't seem to work. tcpdump reports I'm still trying to
contact the IPv6 address. I also tried putting ::ffff:0:0/96 as the
highest precedence (temporarily). That didn't work, either. Reboot
doesn't help. I didn't expect reboot to help, anyway.

If it worked, this is exactly the kind of thing I wanted. Maybe I just
need to beat on it some more.

Allen Kistler a écrit :
> Pascal Hambourg wrote:
>> Allen Kistler a écrit :
>>> For example, http://www.ntp.org.
>>>
>>> NTP.org has a perfectly good IPv4 site, but the IPv6 site doesn't
>>> answer to SYNs.
>>
>> Weird. I can browse it through IPv6, and get answers to my IPv6 SYNs :
>>
>> $ nmap -6 -p 22,25,80,110 www.ntp.org
>>
>> Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-06-19
>> 20:50 CEST
>> Interesting ports on ntp2.ntp.isc.org (2001:4f8:0:2::23):
>> PORT STATE SERVICE
>> 22/tcp filtered ssh
>> 25/tcp open smtp
>> 80/tcp open http
>> 110/tcp filtered pop3
>
> For me, I need -P0 because it won't even ping:

This sounds really really weird. Maybe it is an IPv6 routing or
filtering issue between you and www.ntp.org.

>> "filtered" here means that it (actually the firewall/router just
>> before it) replies with an ICMPv6 "communication prohibited".
>
> "filtered" means the packet is dropped.

Do you mean "silently dropped" ? According to the nmap manpage,
"filtered" can have different meanings. When I wrote "here", I meant
that I checked with tcpdump in that particular situation.

> "closed" is what you get when there's an ICMP error response.

No, this is what you get when there is a TCP RST response, i.e. the
normal response for a closed TCP port.

>> RFC 3484 describes an address selection mechanism for IPv6. It is
>> implemented in recent versions (don't ask me numbers) of the glibc
>> through /etc/gai.conf (GetAddressInfo configuration file). By default
>> the IPv4 address space (in its IPv6 mapped form of ::ffff:0:0/96) has
>> the lowest precedence. You could increase its precedence above the
>> precedence of other IPv6 prefixes so IPv4 addresses are sorted first.
>
> gai.conf is good info. There's even a man page on it, although the
> distinction between label and precedence is lost on me.

I agree the man page is a bit laconic. "label" and "precedence" are
defined in RFC 3484. IIUC they are completely independent. "label" is
used to put prefixes in groups so the source address can be selected in
the same group as the destination address. What you are interested in is
"precedence", which says exactly what it means : higher value gives
higher precedence in the selection process.

> It says if any
> label directive is present, the default table is not used. Then it says
> precedence is different from label, because if any precedence directive
> is present, the default table is not used. So ... it's different
> because it's the same? Whatever.

"label" and "precedence" are independant and have each a separate table.
This paragraph just says that the resolver has a default label table
which is not use if a "label" directive is present in gai.conf, and a
default precedence table which is not use if a "precedence" directive is
present.

> I put www.ntp.org's IPv6 address as the lowest precedence ...
[...]
> label 2001:4f8:0:2::23/128 5

You don't need that directive.

> precendence ::1/128 60
> precendence ::/0 50
> precendence 2002::/16 40
> precendence ::/96 30
> precendence ::ffff:0:0/96 20
> precendence 2001:4f8:0:2::23/128 10

Isn't there a typo in "precendence" instead of "precedence" ? I have
seen the same typo in the manpage example.

> ... but it didn't seem to work. tcpdump reports I'm still trying to
> contact the IPv6 address. I also tried putting ::ffff:0:0/96 as the
> highest precedence (temporarily). That didn't work, either. Reboot
> doesn't help. I didn't expect reboot to help, anyway.

Sorry I cannot help you more on this. I don't think that my Debian etch
supports gai.conf yet, so I didn't test it myself.

Pascal Hambourg wrote:
> Allen Kistler a écrit :
>>
>> [snip]
>>
>> I put www.ntp.org's IPv6 address as the lowest precedence ...
> [...]
>> label 2001:4f8:0:2::23/128 5
>
> You don't need that directive.

Possibly not, although it should work as well. I read the RFC more
carefully today. Preferred source/destination address pairs are ones
that have the same label. If I assign a label to the destination
address that none of my source addresses could possibly have, then that
destination address becomes non-preferred.

>> precendence ::1/128 60
>> precendence ::/0 50
>> precendence 2002::/16 40
>> precendence ::/96 30
>> precendence ::ffff:0:0/96 20
>> precendence 2001:4f8:0:2::23/128 10
>
> Isn't there a typo in "precendence" instead of "precedence" ? I have
> seen the same typo in the manpage example.

Yes. I just copied/pasted from the man page as my starting point. I
corrected the spelling and also made some other tweaks. The glibc
maintainer has a decent page here:
http://people.redhat.com/drepper/linux-rfc3484.html

Although I don't necessarily agree with all the changes he suggests,
it's a good read.

>> ... but it didn't seem to work. tcpdump reports I'm still trying to
>> contact the IPv6 address. I also tried putting ::ffff:0:0/96 as the
>> highest precedence (temporarily). That didn't work, either. Reboot
>> doesn't help. I didn't expect reboot to help, anyway.
>
> Sorry I cannot help you more on this. I don't think that my Debian etch
> supports gai.conf yet, so I didn't test it myself.

From what I found, glibc-2.6 and better should support gai.conf. I've
got 2.10, and I still can't make it work. I think the trick is that the
glibc-implemented algorithm only works if the application _asks_ glibc
to pick the destination address. If the app picks the dest itself,
glibc doesn't override it. At this point I'd bet that Apache (my web
proxy) is picking the address without regard to gai.conf.

Allen Kistler wrote:
>
> [snip]
>
> From what I found, glibc-2.6 and better should support gai.conf. I've
> got 2.10, and I still can't make it work. I think the trick is that the
> glibc-implemented algorithm only works if the application _asks_ glibc
> to pick the destination address. If the app picks the dest itself,
> glibc doesn't override it. At this point I'd bet that Apache (my web
> proxy) is picking the address without regard to gai.conf.

As long as I have to keep a list of names and numbers, /etc/hosts seems
to be the low-tech approach that works. Enter the IPv4 address in
/etc/hosts and DNS lookups don't happen. It doesn't scale well, but it
works on the proxy.