[96819] in North American Network Operators' Group
Re: NANOG 40 agenda posted
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Sat May 26 14:52:46 2007
Date: Sat, 26 May 2007 19:51:52 +0100
From: Jeroen Massar <jeroen@unfix.org>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: Randy Bush <randy@psg.com>, Martin Hannigan <hannigan@gmail.com>,
nanog@nanog.org
In-Reply-To: <20070526153128.4B16D7666B1@berkshire.machshav.com>
Errors-To: owner-nanog@merit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB1C405C5269256E2E55B2A16
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Steven M. Bellovin wrote:
> On Sat, 26 May 2007 00:39:19 -0400
> Randy Bush <randy@psg.com> wrote:
>=20
>> you have something new and interesting about ipv6? if so, did you
>> submit?
>>
> Given the ARIN statement, I think it's time for more discussion of v6
> migration, transition, and operations issues. No, I'm not volunteering=
;
> I'm not running a v6 network. I suspect that Martin is right -- the
> program committee should be proactive on this topic and seek out
> presenters.
If you want somebody to 'present' something about IPv6 transition, then
probably the first step is to start indexing what the current problems
are for ISP's and then kick the people who can explain that...
=46rom the top of my head, it starts by upgrading:
- Routers
- Management Tools
- Monitoring Tools
- CPEs
- Getting proper transit
- Loadbalancers and other net infra
- and other things I forget here
For core links it should IMHO be mostly possible to keep them IPv4/IPv6
dual-stack. When that is not the case one can always do minimal tunnels
inside the AS. Same for getting transit, it doesn't have to be directly
native, but when getting it try to keep the AS's crossed with a tunnel
for getting connectivity to a minimum (See also MIPP*).
Towards endusers it can become nasty, eg it would require upgrades of
the CPE and also the infrastructure might need to be upgraded. For Cable
systems only recently the Docsis 3.0 standard was released and that
would still require a lot of upgrades. Tunneling those users might be a
way to provide IPv6 connectivity to these users without much ado. There
are of course a lot of transition mechanisms, each with their pro's and
con's and all depending on what one wants to achieve.
When there is connectivity, the next step is to start upgrading
services. First upgrading the actual servers that these services run on,
then enabling the services to support IPv6 and starting to stick them in
DNS. The latter point of course can become nasty. When a customer's
client (eg Internet Explorer/Firefox) has IPv6 support and it thinks it
can connect to the service as it sees a AAAA record, but the link in
between doesn't work. Resulting in a unhappy customer as "it is broken"
and they really can't care what is broken and they should not. Care is
thus to be taken when upgrading these services, as it might cause a lot
of helpdesk calls.
Probably doing a trial on the customer base, especially having a group
of people who will give good bugreports and enabling them to use it, is
a good idea. A trick that might work there is to provide those people
with alternate caching DNS servers which do return AAAAs. This can thus
automatically be done using DHCP, when you have a user who is IPv6
enabled, steer them to the DNS servers that return AAAAs and presto,
they start using it. And when you are lucky it also actually works.
And of course that is not all, reading a good book and other materials
on this subject and doing trials and testing is of course a good thing
to do, but one should have done that in the last 5 years already...
<spam>Lastly, don't forget to signup to GRH so that you can see how the
status of your BGP is holding out :)</spam>
Greets,
Jeroen
* MIPP =3D http://ip6.de.easynet.net/ipv6-minimum-peering.txt
Yes that document is already 5 years old by now, there where people
already then who where thinking about those things ;)
--------------enigB1C405C5269256E2E55B2A16
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iHUEARECADUFAkZYgcguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I4bxAJ4pc8ao0+ctase5WltB9qYWvK4e
hQCeK5R1E/NbX5IwEYQ0oJddq2pkLU0=
=z9n7
-----END PGP SIGNATURE-----
--------------enigB1C405C5269256E2E55B2A16--
