[ipv6-wg] On deploying IPv6 for consumers..

Hi Geert,

These PMTU issues are a bit strange, as, our entire backbone is based on IPv6 native transits and peers, and we are also delivering two dual-stacked uplinks to the RIPE Meeting, with native IPv6 connectivity.

I am available to investigate this further, also with RIPE OPS.

Feel free to "ping" me at anytime.

regards,
---
Nuno Vieira
nfsi telecom, lda.

[Email]  nuno.vieira at nfsi.pt 
[Phone]  +351 21 114 2315 
[Phone]  +351 21 142 2300 
[Mobile] +351 91 925 5561 
[Fax]    +351 21 114 2301 
[Web]    http://www.nfsi.pt/ 



----- "Geert Jan de Groot" <GeertJan.deGroot at xs4all.nl> wrote:

> Hi,
> 
> By monitoring the stream from Lisbon, I can tell the RIPE meeting is
> going well and lots of resolution is made towards deployment of
> technologies like IPv6, DNSSEC and others.
> It's good to see many faces, even though it's been a few years
> since I attended a meeting myself. 
> I hope people are enjoying the meeting.
> 
> On the topic of IPv6 deployment, I'd like to ask the WG on the
> following
> issue:
> Turns out that, when browsing from www.ripe.net to find the URLs
> of the Lisbon streams, I seem to run into a PMTU blackhole issue,
> and,
> IPv6 doesn't deal with these too well.
> The only way around it, for me, was to switch IPv6 *OFF*.
> (for those curious, it looks like a PMTU blackhole to rosie.ripe.net,
> but I don't want to badmouth the RIPE NCC or the meeting crew - read
> on!)
> 
> Before you think this is another consumer-enduser, I'd like to
> consider
> that a few weeks ago, a few volunteers diagnosed a similar problem
> with a large public FTP server in the Netherlands. I have tcpdump
> logs
> of the PMTU packets entering the FTP server box itself, and the TCP
> stack
> not noticing. Since it's not my box, there is still work-in-progress
> to fix this, but it definitely is not a local problem - the PMTU
> packets
> come from the XS4all IPv6 tunnel broker box!
> 
> My question, to the WG-at-large, is this: I'm just using a
> consumer-grade
> ADSL connection, with consumer-grade helpdesk access, who is unable
> to deal with these issues. When IPv6 is deployed on a larger scale,
> problems like these are bound to happen, and, I fear, these problems
> happen with Joe Common who cannot diagnose these problems.
> 
> My only recourse, and certainly Joe Common's only recourse, is to
> switch IPv6 *OFF*.
> That is, umm, incompatible with the IPv6 outreach the RIPE community 
> is currently doing.
> 
> My questions therefore:
> - Should these problems be discovered before large-scale deployment?
> - Would it be a good idea to do efforts to pro-actively detect 
>   (and correct) these problems on the infrastructure we have now, 
>   and the infrastructure we're soon deploying?
> - What mechanisms do we need to report these issues, so they can be
>   addressed by people who have both clue and enable/root access to
>   fix them?
>   (taking into account the very nasty scaling properties of 
>   "consumer-grade helpdesk support lines" and the quality of the
> reports 
>   one gets from Joe Common-style users)
> 
> Again, this message is not to badmouth RIPE NCC, the Lisbon LOC,
> XS4all, or anybody else, but just a question on how to deal with
> these
> issues, as the current mechanisms ("consumer helpdesk") can't cope,
> and the recourse ("switch IPv6 off") is probably not what we want.
> 
> Comments?
> 
> Geert Jan