/27 the new /24

Mon Oct 12 21:31:31 UTC 2015

On 10/12/15, 1:49 PM, "NANOG on behalf of Mike" <nanog-bounces at nanog.org
on behalf of mike-nanog at tiedyenetworks.com> wrote:

>
>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.

You have my sympathies. Which gets you nothing but consolation.

>
>> 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.

That statement is too broad. Lots of companies are using IPv6 in prime
time.

There may be some features with some bugs. I don’t know how we shake those
out if people don’t try those features and report the bugs.

>
>>>> 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.

IPv4 malfunctions, too. I haven’t seen anything to suggest that IPv6 is
less robust than IPv4. One does have to climb the learning curve and
develop support processes, but that’s true with anything, including IPv4.

>>>>> 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.

So, CPE is buggy and sucks. I wish there was money to be made in
delivering quality CPE code.

>>
>> 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.

You said above that you thought that CPE reliability is as good as IPv6.
There are quite a few models that work as well with IPv6 as IPv4. But not
all.

But I didn’t ask you to be a developer here, I suggested you be a planner.
If you think you’ll want to provide your users with IPv6 within 5 years,
you should be providing IPv6-capable equipment now, even if you don’t
enable IPv6 yet. Otherwise, when you do start, you’ll have to make up the
difference.

And do report those bugs, or they’ll never get fixed!

Lee