NANOG 40 agenda posted
jeroen at unfix.org
Sat May 26 18:51:52 UTC 2007
Steven M. Bellovin wrote:
> On Sat, 26 May 2007 00:39:19 -0400
> Randy Bush <randy at psg.com> wrote:
>> you have something new and interesting about ipv6? if so, did you
> 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
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...
From the top of my head, it starts by upgrading:
- Management Tools
- Monitoring Tools
- 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>
* MIPP = 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 ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 311 bytes
Desc: OpenPGP digital signature
More information about the NANOG