Jeroen Massar wrote:
Steven M. Bellovin wrote:
On Sat, 26 May 2007 00:39:19 -0400 Randy Bush <randy@psg.com> wrote:
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...
I would vastly prefer to here people talk about what they are doing rather that hear the same set of usual suspects talk about "what we should be doing". The later is tiresome and we have a decade worth of examples of it to pick through.
From 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 = 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 ;)