NANOG 40 agenda posted

Sat May 26 19:59:16 UTC 2007

Jeroen Massar wrote:
> 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
>>> 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 ;)
> 