DHCPv6, was: Re: IPv6 Finally gets off the ground

If you turn on IPv6 on an XP machine (or have it turned on for you
by a "helpful" application or MCP-enabled IT staff) be aware
that there can be unexpected consequences.

In my case it was discovering the nooks and crannies of Teredo,
Microsoft's IPv6 tunnelling protocol.

http://en.wikipedia.org/wiki/Teredo_tunneling

I spent a couple hours in a hotel recently trying to untangle why
using the DSL system I could see the net but couldn't get to any
sites other than a few I tried at random like the BBC, Yahoo
and Google.

That's because they are among the few that apparently have
IPv6 enabled web systems.

Once the reason became apparent, I found another terminal and
figured out how to disable Teredo and IPv6 on my laptop and all
was well for the duration.

Lesson learned.

I was once, circa 1995 or so, fairly enamored of IPv6. Now it
makes me wonder just exactly what problem it is good at solving.

Don't get me wrong -- it's not the fault of IPv6 and its designers
and advocates, it's that the world has moved on and other
methods have been found for the questions it was designed to
address. There is certainly room for concern about how well
those work, but the conversion effort to IPv6 -- well, the market
has voted with its pocketbook, or not. Present company included.

fh

[hmmmm how come I didn't parse any operational content in this post...]

Fred Heutte wrote:
[..]

I spent a couple hours in a hotel recently trying to untangle why
using the DSL system I could see the net but couldn't get to any
sites other than a few I tried at random like the BBC, Yahoo
and Google.

That's because they are among the few that apparently have
IPv6 enabled web systems.

They don't have "IPv6 enabled web systems", a lot of people wished that
they did. What your problem most likely was, was a broken DNS server,
which, when queried for an AAAA simply doesn't respond.

Most Network Operators (to keep it a bit on topic for this mailinglist)
can't do anything about broken DNS servers at End User sites.

Note that this has *nothing* to do with Teredo, which even doesn't
activate itself when it can't get packets to be relayed. You can't thus
blame Microsoft for this. The DNS server is broken, not them. I know it
is always fun to blame M$ but really it isn't true.

Note also that the BBC once did have a AAAA related DNS problem, that
was in 2002 though and was quickly resolved:

These had another kind of problem, they returned NXDOMAIN, so that it
looked like the requested label was not there; much better still than
the simple ignore and forget of the End User DNS problems.

I was once, circa 1995 or so, fairly enamored of IPv6. Now it
makes me wonder just exactly what problem it is good at solving.

Primarily only one: a *lot* more address space. Enough to provide our
children's children children and the rest of the world with unique
addressable address space. Nothing more nothing less.

Don't get me wrong -- it's not the fault of IPv6 and its designers
and advocates, it's that the world has moved on and other
methods have been found for the questions it was designed to
address.

As it primarily resolves the address space problem and it solves this
perfectly well, how exactly did your world move on by staying limited to
32bits and only 4 million addresses while there are many more people on
this planet, not even thinking of subnets or having multiple addresses
per person?

Greets,
Jeroen

Thus spake "Jeroen Massar" <jeroen@unfix.org>

Fred Heutte wrote:
> I spent a couple hours in a hotel recently trying to untangle why
> using the DSL system I could see the net but couldn't get to any
> sites other than a few I tried at random like the BBC, Yahoo
> and Google.
>
> That's because they are among the few that apparently have
> IPv6 enabled web systems.

They don't have "IPv6 enabled web systems", a lot of people
wished that they did. What your problem most likely was, was
a broken DNS server, which, when queried for an AAAA simply
doesn't respond.

In fact, it's one particular vendor (whose name I haven't been able to discover) of pay-for-Internet transparent proxy/NAT devices, such as those commonly used in hotels and at hotspots, that's messing the whole thing up. They return an address of 0.0.0.1 in response to any DNS query from an IPv6-capable client, and they've decided to train their service providers' tech support departments to tell customers to turn off v6 rather than fix what should be a very simple bug.

(Granted that's a passable workaround for a few months while a vendor prepares a patch, but this issue has been around for _years_.)

I know it is always fun to blame M$ but really it isn't true.

Agreed. MS is sending a proper query, and every other DNS server on the face of the planet responds correctly. There are a few random apps that still bomb when both ends have IPv6 and there's only a v4 path between them (though most have been fixed over the last few years), but the OS is working correctly.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

the STSN devices? or 'ibahn' ? One thing to keep in mind is that the
DNS-LB used by Google/yahoo (in the examples above) seems to be returning
a CNAME for AAAA queries, then nothing for the follow-up resolution
request for a AAAA for the CNAME... So, ipv6 things may look 'broken'
because they are also 'slow' (waiting to re-do much of the lookup path to
get the A version)

Chris L. Morrow wrote:
[..]

the STSN devices? or 'ibahn' ? One thing to keep in mind is that the
DNS-LB used by Google/yahoo (in the examples above) seems to be returning
a CNAME for AAAA queries, then nothing for the follow-up resolution
request for a AAAA for the CNAME... So, ipv6 things may look 'broken'
because they are also 'slow' (waiting to re-do much of the lookup path to
get the A version)

(snipped for brevity)

8<-------------------------------------------------------------------
$ dig @ns1.google.com www.google.com aaaa

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41689
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7

;; ANSWER SECTION:
www.google.com. 604800 IN CNAME www.l.google.com.

$ dig @ns1.google.com www.l.google.com aaaa

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44383
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 7
------------------------------------------------------------------->8

8<-------------------------------------------------------------------
$ dig @ns5.yahoo.com www.yahoo.com. aaaa

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3095
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; ANSWER SECTION:
www.yahoo.com. 300 IN CNAME www.yahoo-ht3.akadns.net.

$ dig @eur1.akadns.net www.yahoo-ht3.akadns.net. aaaa

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15024
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
------------------------------------------------------------------->8

The Yahoo redirect is out of bailiwick and thus requires a full lookup
again, the google one at least can be served by the same box.

But for the rest it all seems pretty fine to me...

or do you mean that those ibahn things see "NOERROR" and then no
answers, thus wrongly cache that as label has 0 answers at all?
or what I mention above with the redirect?

Greets,
Jeroen

Thus spake "Jeroen Massar" <jeroen@unfix.org>

But for the rest it all seems pretty fine to me...

or do you mean that those ibahn things see "NOERROR" and
then no answers, thus wrongly cache that as label has 0 answers
at all? or what I mention above with the redirect?

They do the same thing for requests that don't involve a CNAME, so they're either choking on the AAAA query or a NOERROR response in general; it's hard to tell which since I can only see one side of their box. I also don't know how they react when you try to contact a site that _does_ have AAAA records, since no major content site has them (which is a whole 'nother discussion).

What's weird is that they don't just return a 0-record NOERROR when you do the follow-up A query, which would be the most logical failure mode -- they return an authoritative answer of 0.0.0.1 instead.

Of course, dealing with idiot consumers on a regular basis, their tech support folks insist the problem is on the user's machine and that it's a bug in their v6 stack, despite Ethereal captures showing the bad DNS response packets coming from their box...

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Stephen Sprunk wrote:

Thus spake "Jeroen Massar" <jeroen@unfix.org>

But for the rest it all seems pretty fine to me...

or do you mean that those ibahn things see "NOERROR" and
then no answers, thus wrongly cache that as label has 0 answers
at all? or what I mention above with the redirect?

They do the same thing for requests that don't involve a CNAME, so
they're either choking on the AAAA query or a NOERROR response in
general; it's hard to tell which since I can only see one side of their
box. I also don't know how they react when you try to contact a site
that _does_ have AAAA records, since no major content site has them
(which is a whole 'nother discussion).

Wellps, we have www.ipv6experiment.com of course where the actual
content site soon will point to 2001:4978:0:0:0:0:B00:B1E5 :slight_smile:

/me wonders how many spam/corpfirewalls etc will like that sentence, but
hotels won't have much of an issue with that I guess, it's one of the
reasons for their existence...

What's weird is that they don't just return a 0-record NOERROR when you
do the follow-up A query, which would be the most logical failure mode
-- they return an authoritative answer of 0.0.0.1 instead.

Ick. These folks really need a clue batting don't they?

Of course, dealing with idiot consumers on a regular basis, their tech
support folks insist the problem is on the user's machine and that it's
a bug in their v6 stack, despite Ethereal captures showing the bad DNS
response packets coming from their box...

Argh, I can sort-of understand their way of handling it, but still, they
should have fixed this by now, and their clear broken DNS is simply a
real reason to avoid those hotels at all.

Can somebody please sponsor a trip to any of these hotels for either two
or both of the Pauls, that is Mockapetris or Vixie, and let THEM call
techsupport on this!? :slight_smile: At least the "eh dude, I kinda like (invented
DNS>coded BIND) and I really do think I sort of know what I am talking
about" discussion would be worth a "extremely priceless" rating and a
good laugh for the coming years for most of the Ops community :slight_smile:

Remember kids: never leave home without a well known IP address where
all kinds of obvious ports run your favorite tunneling mechanism :slight_smile:
[443 seems to be very popular for that nowadays it seems...]

Long live tunnels and own infra!

Greets,
Jeroen

since somebody made the mistake of cc'ing me, i actually saw this message even
though i long ago killed-by-thread the offtopic noise it's part of. hereis:

> What's weird is that they don't just return a 0-record NOERROR when you
> do the follow-up A query, which would be the most logical failure mode
> -- they return an authoritative answer of 0.0.0.1 instead.

Ick. These folks really need a clue batting don't they?

this kind of outrageous behaviour has made the introduction of new RR types
almost pointless, which is in turn the reason most often cited for "just use
TXT" (as in SPF for example). AAAA is just a current example. some of these
boxes only handle A RR's (by redirecting folks to a proxy) and answer with
NOERROR/ANCOUNT=0, or just don't answer at all, for everything else.

> Of course, dealing with idiot consumers on a regular basis, their tech
> support folks insist the problem is on the user's machine and that it's
> a bug in their v6 stack, despite Ethereal captures showing the bad DNS
> response packets coming from their box...

Argh, I can sort-of understand their way of handling it, but still, they
should have fixed this by now, and their clear broken DNS is simply a
real reason to avoid those hotels at all.

lack of "clear channel DNS" has also made the introduction of DNSSEC take
at least five of its thirteen years-too-long. ultimately we'll have to make
an HTTPS transport for DNS or tunnel all of our hotel queries back to our
home networks over VPN's. anything left in the clear is a target, not just
for phishers and identity thieves, but for startup CEO's and their VC's.

Can somebody please sponsor a trip to any of these hotels for either two
or both of the Pauls, that is Mockapetris or Vixie, and let THEM call
techsupport on this!? :slight_smile: At least the "eh dude, I kinda like (invented
DNS>coded BIND) and I really do think I sort of know what I am talking
about" discussion would be worth a "extremely priceless" rating and a
good laugh for the coming years for most of the Ops community :slight_smile:

been there, done that, trust me it wasn't even mildly amusing for anybody.
what i'm wondering now is, if a 501(c)(3) patented something that was to be
used on the internet, and granted an free/unlimited use/distribute license on
sole condition that users/distributors actually implement it correctly, then
(a) would it hold up in court, and (b) would the 501(c)(3) CEO get lynched?

Not "major content sites", but these are some web sites with AAAA records that people may be visiting for other reasons than just IPv6 tourism:

www.apnic.net
www.arin.net
www.lacnic.net
www.ripe.net
www.ietf.org
www.ams-ix.net
www.isc.org
www.netbsd.org
www.hitachi.co.jp
www.surfnet.nl
www.janet.ac.uk
www.dante.net
www.geant.net

Hi,

I also don't know how they react when you try to contact a site that _does_ have AAAA records, since no major content site has them (which is a whole 'nother discussion).

Not "major content sites", but these are some web sites with AAAA records that people may be visiting for other reasons than just IPv6 tourism:

That's an interesting concept, IPv6 tourism :wink:

www.apnic.net
www.arin.net
www.lacnic.net
www.ripe.net

RIRs, frequent IPv6 promoters.
they know available IPv4 space is going to end.
yes, afrinic is missing...... :frowning:

www.ietf.org
www.ams-ix.net

internet exchanges. those which see IPv6 as an "easy thing" :slight_smile:
some more AAAAs to add:

czech republic - info.nix.cz has IPv6 address 2001:ae8:4:0:230:48ff:fe42:48c5
ireland - www.inex.ie has IPv6 address 2001:7f8:18:2::4
malta - www.mix.net.mt has IPv6 address 2001:1a70:1:1::32
portugal - www.gigapix.pt has IPv6 address 2001:690:a00:40aa:2c0:9fff:fe20:e261
sweden - www.netnod.se has IPv6 address 2001:698:9:404:202:b3ff:fe89:f49b
switzerland - pollux.swissix.net has IPv6 address 2001:7f8:24::7e

www.isc.org
www.netbsd.org
www.hitachi.co.jp

this one is very interesting! :slight_smile:
does anybody know more from Japan, regarding largely known brands?

www.surfnet.nl
www.janet.ac.uk
www.dante.net
www.geant.net

last two are the same server.
from the european NREN folder the following could be added:
(some www.<NREN>.<country> are aliases...)

CZ - www.cesnet.cz has IPv6 address 2001:718:1:101:204:23ff:fe52:221a
FR - www.renater.fr has IPv6 address 2001:660:3001:4002::10
GR - www.grnet.gr has IPv6 address 2001:648:2ffc:200::2037
IE - heanet.webhost.heanet.ie has IPv6 address 2001:770:18:2::c101:db4f
MT - www.um.edu.mt has IPv6 address 2001:1a70:1:1::40
PT - www.fccn.pt has IPv6 address 2001:690:a00:40aa:2c0:9fff:fe20:e261
SE - www.sunet.se has IPv6 address 2001:6b0:e:1::f:1
CH - aslan.switch.ch has IPv6 address 2001:620:0:14::c
NO - uninett.no has IPv6 address 2001:700:0:513::80
HR - www.carnet.hr has IPv6 address 2001:b68:e160:0:20b:dbff:fee6:a4f0
IS - frosti.rhnet.is has IPv6 address 2001:948:10:16::23

Cheers,
Carlos

> www.hitachi.co.jp

this one is very interesting! :slight_smile:
does anybody know more from Japan, regarding largely known brands?

They developed IPv6 shims for their Windows 95 network drivers to all
PCs using their network cards to use IPv6.

--Michael Dillon

* cfriacas@fccn.pt (Carlos Friacas) [Tue 17 Apr 2007, 10:38 CEST]:

Not "major content sites", but these are some web sites with AAAA records that people may be visiting for other reasons than just IPv6 tourism:

[..]

www.ams-ix.net

internet exchanges. those which see IPv6 as an "easy thing" :slight_smile:

Why would they see that any differently than any ISP? The issues they run into are exactly the same as those on other networks. IOS version dances, DNS has to be updated, the occasional timeouts when e.g. a wireless access point stops forwarding IPv6 ethertype frames, &c.

  -- Niels.

There are some of us that have had enough v6 kool-aid that
we've put our website on v6.. eg: www.us.ntt.net (as2914)

  Without adoption, some of these issues won't get
resolved, like broken consumer electronics devices, etc..

  I wonder what my Wii does with those v6 frames on the
wireless network.

  - Jared

Hi,

What i meant is that when IXPs/NAPs allow v4 bgp sessions or v6 bgp sessions over their infrastructure they are doing pretty much the same stuff. Lower Layer = No Issue.

Even if they're using/providing a route server-based service, enabling IPv6 should be very easy.

Of course that when IXPs/NAPs place AAAAs and enable services (Web, ...) they run into the same *mostly solvable* problems other people do. :slight_smile:

Best Regards,