NANOG 40 agenda posted

Tue May 29 16:09:17 UTC 2007

What I'm saying, across different postings, is that I'm not advocating for
dual-stacking existing services immediately (there is no need for that, no
new advantages at this point). It is nice to have, but I agree that we must
go step by step and time will tell us when moving on or even retiring IPv4
in some cases (which will happen in a much longer term in most of the

The reasons why your connectivity, being dual-stacked at the client and
server side fail, are typically:
1) Server side not well connected to IPv6, or not connected at all and
having an AAAA. Blame the server operator !
2) Client side connected to a network that indicates "I've an IPv6 router
and this is your prefix", but it is not the case. Blame the network
administrator !
3) Client side/network correctly configured but poor connectivity due to
lack of good native connectivity, a stable tunnel, or using 6to4 or Teredo
and relays not correctly/enough deployed. Blame operators for not operating
correctly IPv6 transition !

We can compare 1, 2 and 3 to the same situation if, in the IPv4 world, the
IPv4 connectivity gets broken. So let's stop blaming IPv6. Blame ourselves.
We didn't our work very well, not yet up to now.

Obviously, networks route IPv6 today, so resilience is not the same as if
there is an improper configuration in IPv4, but again, this is what *we*
operators, need to sort out soon.

We need to deploy more relays while we are unable to deploy more native
connectivity (of course this one preferred).

We need to be exactly the same of serious with IPv6 routing as we do with

Then, with a very small effort from our side, automatic transition traffic
will not be black holed, and there will be a reason to start moving on
faster on configuring AAAA in all the content providers.

By the way as I indicated a few postings ago, 3) can be sorted out very
easily at each ISP network with a very low cost and no impact at all. You
don't need to deploy, in case you can't, IPv6 at all across the rest of your
network, just a static tunnel/s from the 6to4/Teredo Relay to any upstream
or set of them. And this warrantees your customers IPv6 connectivity and
improve their peer-to-peer experience even if different transitions
mechanisms are being used among the peers.

Can we do that ?

By the way, even if we don't do that, peer-to-peer traffic is already taking
advantage of IPv6, even only with transition mechanism such as 6to4 and


> De: David Conrad <drc at>
> Responder a: <drc at>
> Fecha: Tue, 29 May 2007 08:22:35 -0700
> Para: <jordi.palet at>
> CC: Nanog <nanog at>
> Asunto: Re: NANOG 40 agenda posted
> Jordi,
> On May 29, 2007, at 6:50 AM, JORDI PALET MARTINEZ wrote:
>> This is useless. Users need to use the same name for both IPv4 and
>> IPv6,
> Why?
> The IETF chose to create a new protocol instead of extending the old
> protocol.  Even the way you ask for names is different (A vs. AAAA).
> Why should anyone assume a one-to-one mapping between the two
> Internets based on those protocols?
>> they should not notice it.
> They shouldn't, but they will.  Having had the fun of trying to
> figure out why I lost connectivity to a site (then realizing it was
> because I had connected via IPv6 instead of IPv4 and IPv6 routing ...
> changed), the current IPv6 infrastructure is, shall we say, not quite
> production ready.
>> And if there are issues (my experience is not that one), we need to
>> know
>> them ASAP. Any transition means some pain, but as sooner as we
>> start, sooner
>> we can sort it out, if required.
> Forcing end users to be exposed to the pain of transition?  This is
> the techno-geek mindset, not the critical communications
> infrastructure-geek mindset.  Guess which one is more appropriate to
> the Internet today?
> Rgds,
> -drc

The IPv6 Portal:

Bye 6Bone. Hi, IPv6 !

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

More information about the NANOG mailing list