Steven M. Bellovin wrote: > On Sat, 26 May 2007 00:39:19 -0400 > Randy Bush <[EMAIL PROTECTED]> 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... 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 ;)
signature.asc
Description: OpenPGP digital signature
