/27 the new /24

Mon Oct 12 17:49:52 UTC 2015

On 10/09/2015 05:22 AM, Lee Howard wrote:
> NO, THERE IS NOT. We operate in rural and underserved areas and WE DO
> NOT HAVE realistic choices. Can you see me from your ivory tower?
> I looked up tiedyenetworks.com, and I think he¹s 100 miles from Sacramento.
> I hope some sales person from a transit provider is giving him a call right
> now, but it¹s entirely possible that there are no big providers in his
> neighborhood. Sorry, Mike, wish I could help you there.

Thats not even the half of it.

My personal heroics in solving the connectivity problem here, is that we 
became a CLEC in order to take the bull on by the short and curlys and 
build facilities. But the problem is even bigger than just getting dark 
fiber strands and collocating in a few select telco offices; My entire 
county is woefully underserved. Connectivity here is expensive as all 
hell. So on top of the nearly $1mln now sunk in this part of the 
venture, I am STILL looking at several more $$mln to build out of this 
dank hole and connect up at those carrier hotels in the far off fantasy 
world where connectivity options abound.

> It sounds like you do have some concern about the transition, and you 
> know there¹s a bug, at least with OS downloads. Please do report those 
> issues you know about. Usually, Happy Eyeballs masks problems in dual 
> stack, whether that¹s good or bad. If we can get your upstream(s) to 
> support IPv6, then maybe we can leverage them to help troubleshoot MTU 
> problems, so you don¹t have to spend a lot of time on them. Or maybe 
> they go away when you¹re no longer tunnelling.

No, the problem is that v6 isn't ready for prime time. Period.

>>> I can't remember the last time I saw a site stall due to reaching it
>>> over IPv6 it is that long ago.
>> It happens every day for me, which only amplifies my perception that v6
>> IS NOT READY FOR PRIME TIME.
> Would you at least keep a list of places you have these problems, even if
> you never follow up on it? Again, I¹m wondering if tunnelling is the
> problem, and once you have native dual-stack, you could refer to the list
> and see if problems just dry up.

No, the problem is that v6 isn't ready for prime time, period. Im not 
going to consider rolling it out to my customers until the point comes 
where it stops going down and stops malfunctioning and stops being 'a 
problem' that has to be dealt with by disabling the v6 stack on the 
afflicted host. Until then, it's going to continue to be treated as 
academic masturbation likely to be replaced with something competently 
designed based on technical merits alone.
>>>> Damm maddening. Can't imagine the screaming I'll
>>>> hear if a home user ever ran into similar so I am quite gun shy about
>>>> the prospect. Secondly, the the dodgy nature of the CPE connected to
>>>> our
>>>> network and the terminally buggy fw they all run is sure to be a never
>>>> ending source of stupidity.
>>> CPE devices are buggy for IPv4 as well.  Bugs in CPE devices are
>>> only found and fixed if the code paths are exercised.
>> Not my job. v4 works, v6 does not. I am a provider not a developer.
> I would guess it is your job in IPv4.
> I would also guess, based on gateways I¹ve seen, than 10% of CPE
> has critical IPv4 bugs, and 25% of CPE has critical Ipv6 bugs. I agree with
> you that the difference is too high, and maybe waiting a year helps get
> those ratios aligned.
>
> CPE vendors: step it up!

I think the major pain points in CPE gear is really less than 'ipv4' 
bugs and more just bad design in general. They 'lock up' and stop 
forwarding, requiring end users to 'power cycle' the equipment in order 
to attain functionality again. And, they still stupidly have a 'reset' 
button, which users still think will help them when it's "locked up" but 
in fact simply "wipes out required settings", causing further problems 
for the poor hapless user. They are quite big on shiny flashing lights 
and starship or battle ship shaped plastic housings, but long term 
reliability is about as good as trusting v6 for anything, which is to 
say they are not trustworthy at all.

>
>
> Figure out how long until you think you really need all of your customers
> to have IPv6. Subtract your CPE replacement time. Start replacing CPE then.
> e.g., if users need IPv6 in 2018, and you replace all CPE on a 5 year
> schedule, you should begin providing IPv6-capable CPE in 2013.
>

Again, requires me to be a developer and not a provider. Working CPE do 
not exist yet.

>>>> Thirdly, some parts of my network are
>>>> wireless, and multicast is a huge, huge problem on wireless (the 802.11
>>>> varities anyways). The forwarding rates for multicast are sickeningly
>>>> low for many brand of gear - yes, it's at the bottom of the barrel no
>>>> matter how good or hot your signal is - and I honestly expect v6 to
>>>> experience enough disruption over wireless as to render it unusable for
>>>> exactly this reason alone.
>>> You expect but haven't tested.
>> Based on observation and experience, I think v6 will wipe out the 802.11
>> portion of my network and no, Im not going to 'test' it, recovery would
>> be near impossible and in any event I don't experiment with paying
>> customers. I won't move until the underlaying issues are resolved, and
>> that means fixing multicast in wireless, which won't be done by me again
>> because, you guessed it, I am a provider and not a developer.
> This might help:
> https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption
> -02
> Cisco has done some presentations on their use of IPv6 over WiFi at Cisco
> Live
> and other venues. For instance,
> http://www.rmv6tf.org/wp-content/uploads/2013/04/5-2013-04-17-RMv6TF-kreddy
> -02.pdf
>
> Might be able to mitigate with configuration.
>

No, it's not going to help. v6 over current wireless doesn't work for 
the reasons that multicast is a gaping hole. I've previously counseled 
others on why OSPF over wireless doesn't work reliably and it comes also 
down to multicast (It CAN work, if you use NBMA however). And thats with 
just two speakers trying to use multicast. Imagine 30+ end user stations 
all using multicast, I know it's certain death. So again, we would have 
to treat the wireless subscriber portion differently than we treat the 
wired. I don't want to be a developer and I have no interest in fixing 
this situation; I want the developers of this gear to fix it and later, 
when I see the problems are all gone, then I will think about v6 for 
those users.

> It makes sense to me that you would want to wait another year. An ISP 
> of your size doesn¹t have the support staff to troubleshoot new 
> problems. I do hope you¹ll keep an eye on deployments, and at least be 
> thinking in terms of deploying next year (e.g., by buying gear that at 
> least claims IPv6 support, thinking about what monitoring you need to 
> keep an eye on it as you deploy), so that when you do start, you have 
> an easier time of it. Lee 

Right, you understand exactly. I want to only deploy to my end users 
what I know works. Internally yes I am experamenting but there will not 
be v6 reacing my customers until these and other problems are solved by 
the manufacturers.

Mike