/27 the new /24

Thu Oct 8 21:41:23 UTC 2015

In message <561699F3.1070600 at tiedyenetworks.com>, Mike writes:
> On 10/08/2015 06:14 AM, Matthew Kaufman wrote:
> >
> >
> > On 10/7/15 7:00 AM, Mark Andrews wrote:
> >> I don't see anyone wishing it went differnetly. I see someone 
> >> pointing out the reality that lots of ISP's are way too late to 
> >> delivering IPv6. *Every* ISP should have been planning to deliver 
> >> IPv6 by the time the first RIR ran out of IPv4 addresses. 
> >
> > Look, I'm as much a supporter of delivering IPv6 as anyone. I've had 
> > IPv6 enabled on my home network (and the small data center I run in my 
> > garage) for over a decade now. In 2004, I made sure that IPv6 was 
> > fully supported in the peer-to-peer stack I developed and that 
> > eventually became RFC 7016. And for the last 5 years I've been pushing 
> > for IPv6 support in the product I work on for my employer.
> >
> > But the reality is that there's a whole lot of small and medium-sized 
> > ISPs run by fine, upstanding individuals serving their communities -- 
> > even in and around the San Francisco Bay Area -- that have either no 
> > or very limited (tunnels only) support for IPv6. That's the reality of 
> > the transition. And threatening these folks with the attorney general 
> > isn't the way to get them to adopt IPv6, nor is shaming them. They 
> > will add IPv6 support when it is easy to do, when their staff has the 
> > time, and when the economics make sense.
> >
> 
> 
> Plus one to that. We are such a provider, and IPv6 is on my list of 
> things to implement, but the barriers are still plenty high. Firstly, I 
> do have an Ipv6 assignmnt and bgp (v4) and an asn, but until I can get 
> IPv6 transit,

There are lots of transit providers that provide IPv6.  It really is
time to name and shame transit providers that don't provide IPv6.

> there is not much point in my putting a lot of effort into 
> enabling IPv6 for my subscribers. Yes I have a HE tunnel and yes it's 
> working, but it's not the same as running native v6 and with my own 
> address space. Second, on the group of servers that have v6 thru the HE 
> tunnel, I still run into problems all the time where some operations 
> over v6 simply fail inexplictly, requireing me to turn off v6 on that 
> host so whatever it is I'm doing can proceed over v4.

> Stuff like OS updates for example.

Then complain to the OS vendor.  It is most probably someone breaking
PMTU discover by filtering PTB.  Going native will hide these
problems until the MTU between the DC and the rest of the net
increases.  You could also just lower the advertised MTU internally
to match the tunnel MTU which would let you simulate better what a
native experience would be.

I can't remember the last time I saw a site stall due to reaching
it over IPv6 it is that long ago.

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

That said IPv6 worked fine for me with the shipped image (old version
of OpenWRT) using 6to4 before I reflashed it to a modern version
of OpenWRT as I wanted to use the HE tunnel rather than 6to4.  I
know that is only one CPE device.

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

> The wired portion of my subscriber network is only slightly better, im 
> pretty sure it can deal with v6 in the middle, but the question is still 
> wether specfic CPE models can and which set of bugs I'll hit on my 
> access concentrators passing our v6 over PPPoE. I just read about a 
> cisco bug where enabling rp-filtering on v6 causes a router reload, 
> which I would hit immediately since rp-filtering is a standard 
> subscriber profile option here (trying to be a good netizen). How many 
> other network destroying bugs await? The longer I wait on v6, the less 
> work I will have to do dealing with bugs. So, as the original posted 
> said, we'll do v6 when it's easy, when we have time, and when the 
> economics make sense.

And is there a fix available yet?  All code has bugs in it.  They
exist in both the IPv4 code paths and the IPv6 code paths.  There
are lots of places that are going IPv6 only internally and only
having IPv4 at the fringe.  You can't do that if routers are flakey
when pushing IPv6 packets.  This is basically just fear overriding
rational decisions.

> Mike-
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org