|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NANOG 40 agenda posted
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 networks). 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 IPv4. 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 Teredo. Regards, Jordi > De: David Conrad <[email protected]> > Responder a: <[email protected]> > Fecha: Tue, 29 May 2007 08:22:35 -0700 > Para: <[email protected]> > CC: Nanog <[email protected]> > 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: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org 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.
|