[97159] in North American Network Operators' Group
Re: IPv6 transition work was RE: NANOG 40 agenda posted
daemon@ATHENA.MIT.EDU (Igor Gashinsky)
Sun Jun 3 20:25:18 2007
Date: Sun, 3 Jun 2007 19:16:06 -0400 (EDT)
From: Igor Gashinsky <igor@gashinsky.net>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Cc: nanog@merit.edu
In-Reply-To: <C2891F9A.19CB1D%jordi.palet@consulintel.es>
Errors-To: owner-nanog@merit.edu
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---19390912-1512370993-1180912566=:1754
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
What I guess have not been clear on is the fact that loadbalancers for=20
many people are an integral (and required) part of the *architecture*=20
(and not just something u need to distribute load), and as such, are a=20
component that must support v6 for the *service* to then be able to=20
support it (much like basic logging now would need to be v6 capable, etc).=
=20
There is simply no easy way of taking 1 machine and making it=20
mail.ipv6.yahoo.com (as an example), not to mention that nobody is going=20
to invest the time and resources into building a completely different=20
architecture (a single server is a complete one-off) to support a test=20
rollout of v6 (and then having to sync different code trees, etc), when=20
that time and resources could be better invested in coming up with a real=
=20
solution for the long-term.
Again, we are working on it, it is much harder then it seems, my views are=
=20
my own, I'm not in any way speaking for my employer, and in fact, I've=20
said all I can. =20
Thanks,
-igor
On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote:
::=20
:: Agree, and in fact, a quick though is that as you may expect *much less*
:: IPv6 traffic today, not having load balancing may not be an issue, and y=
ou
:: can always actively measure if the traffic is going high, etc.
::=20
:: If the time arrives when the traffic is so high and your preferred vendo=
r
:: doesn't yet support the IPv6 load+IPv4 one, then you have no risk in the
:: sense that you can just delete the AAAA records, but meanwhile you have =
a
:: very realistic test environment and motivation to push your vendors, or
:: considering the traffic, decide if moving to other vendors, etc.
::=20
:: Regards,
:: Jordi
::=20
::=20
::=20
::=20
:: > De: <michael.dillon@bt.com>
:: > Responder a: <owner-nanog@merit.edu>
:: > Fecha: Sun, 3 Jun 2007 23:01:57 +0100
:: > Para: <nanog@nanog.org>
:: > Conversaci=F3n: IPv6 transition work was RE: NANOG 40 agenda posted
:: > Asunto: IPv6 transition work was RE: NANOG 40 agenda posted
:: >=20
:: >=20
:: >=20
:: >> Without naming any vendors, quite a few features that work
:: >> with hardware assist/fast path in v4, don't have the same
:: >> hardware assist in v6 (or that sheer enabling of ipv6 doesn't
:: >> impact v4 performance drasticly).
:: >> Also, quite a few features simply are not supported in v6
:: >> (not to mention that some LB vendors don't support v6 at
:: >> all). Just because it "works", doesn't mean it works
:: >> corrctly, or at the right scale. Again, not naming any vendors...
:: >=20
:: > This just emphasizes the importance of turning on IPv6 today either in
:: > some part of your production networks in order to identify the specifi=
cs
:: > of these issues and get them out in the open where they can be fixed.
:: >=20
:: >> Actually, for me 100% feature parity (for stuff we use per
:: >> vip) is a day-1 requirement.
:: >=20
:: > This doesn't sound like transition as we know it. If you can set up
:: > everything that you need to test in a lab environment and then certify
:: > IPv6 as ready for use, this could work. But I don't believe that the
:: > IPv6 transition can be handled this way. It involves many networks wit=
h
:: > services and end-users of all types which interact in interesting ways=
=2E
:: > We need everybody to get some IPv6 into live Internet production. The
:: > only way this can work is to take lots of baby steps. Turn on a bit of
:: > v6, test, repeat.
:: >=20
:: >> My stance is that simply enabling v6 on a server in "not
:: >> interesting", v6 has to be enabled on the *service*,
:: >=20
:: > I disagree. If a company can offer their service using lots of IPv4
:: > in-house with an IPv6 proxy gateway to the Internet, then this is stil=
l
:: > valuable and useful in order to support OTHER people's testing. Let's
:: > face it, IPv4 is not going away and even when the v4 addresses run out=
,
:: > anybody who has them can keep their services running as long as they
:: > don't need to grow the v4 infrastructure. This is not an issue of
:: > turning on some IPv6 to test it and then evaluate the results. The fac=
t
:: > of IPv4 exhaustion is an imperative that means you and everyone else
:: > must transition to an IPv6 Internet. You turn on some v6, test, adjust=
,
:: > turn on some more, test, adjust and repeat until your infrastructure n=
o
:: > longer has a dependency on new IPv4 addresses. Your end game may still
:: > have lots of IPv4 in use which is OK as long as no new IPv4 addresses
:: > are needed.
:: >=20
:: >> Like you said, different companies have different approaches,
:: >> but if I'm going to invest my (and a lot of other
:: >> engineers/developers/qa) time in enabling v6, it's not going
:: >> to be putting a single server behind the mail.ipv6.yahoo.com
:: >> rotation, it's going to be figuring out how to take
:: >> everything that we use for mail.yahoo.com, and making it work
:: >> in v6 (as that is the only way it would be concidered a valid
:: >> test), so that at some point in the not-too-distant future it
:: >> could become dual-stack...
:: >=20
:: > I don't disagree with the general thrust of your approach, in particul=
ar
:: > related to the investment that you have to make. But as part of your
:: > overall IPv6 transition program, it should not cause you a lot of pain
:: > to make the mail.yahoo.com service available to IPv6 users. By doing
:: > that you help everybody else move along in their transition process an=
d
:: > you cut your costs because you will be able to leverage the lessons th=
at
:: > other people learn. The network effect will help those who actually
:: > deploy stuff in production.
:: >=20
:: > --Michael Dillon
::=20
::=20
::=20
::=20
:: **********************************************
:: The IPv6 Portal: http://www.ipv6tf.org
::=20
:: Bye 6Bone. Hi, IPv6 !
:: http://www.ipv6day.org
::=20
:: This electronic message contains information which may be privileged or =
confidential. The information is intended to be for the use of the individu=
al(s) named above. If you are not the intended recipient be aware that any =
disclosure, copying, distribution or use of the contents of this informatio=
n, including attached files, is prohibited.
::=20
::=20
::=20
---19390912-1512370993-1180912566=:1754--
