Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Gert Doering <[e-mail]>]

Hi,

On Wed, Feb 20, 2019 at 01:02:45PM +0100, [e-mail] wrote:
> >> What a sacrilege!
> > 
> > There's so much wrong with current IPv6 standards and implementations
> > and processes that "just go with NPT" would save a lot of pain.
> 
> Would you be interesting in making a list of what you think is wrong?
> (I'm not disagreeing, I'm just curious...)

Oh, that list will be long, so doing it in a useful way will take some
time.  Just a quick list of things that come to my mind right away

There's "protocol inherent" issues that turn out to be amazingly stupid
in retrospective

 - using IPv6 for ND/NA
    - "you cannot attack something from remote which is not IP"
    - usiing a mix of local and global addresses for ND/NA source/dest
      (so filtering "only accept those ND/NA packets that can correctly
      happen on *this link* and drop all else" is fairly tedious)

 - using multicast for core functionality
    - little benefit compared to broadcast in today's networks
    - lots of extra complexity in network drivers, switch forwarding planes,
      Wifi, ...
      -> lots of bugs and problems

 - replicating the ARP model of "neighbor solicitation when a packet comes
   in" instead of trying something akin to LANE, where you just register
   with "someone" who knows all the L2/L3 mappings for a given LAN segment
   on connection, and nobody has to probe -> "scan /64, exhaust ND" attacks
   totally defused

 - unbound chain of extention headers 

 - carrying link-local next-hop addresses in IPv6 BGP sessions that are
   connecting peers on the same LAN using their GUAs (so at least one
   major vendor installs a next-hop in the FIB that is different from 
   the BGP peer it is talking to - combine that with ND bugs galore, and
   you get blackholing due to LLA next-hop unreachability, while BGP
   thinks "all is good")



Then, there's market and IETF process fails

 - homenet protocol suite - this is something that could have been 
   insanely great, with "just plug in a second ISP into your home
   network, all machines understand that they have two options for
   'connect to the Internet' now, and users have full control"

   IETF process fail: stall this by haggling two years over "what sort
   of routing protocols should we have in the homenet protocol suite?
   we must have negotiations! options! flexibility!"

   market fail: CPEs have their implementations done.  Nobody (but OpenWRT)
   seems to be working on homenet implementations.

   double market fail: ISPs have no interest in requesting this from 
   their vendors (so, IETF fail again, because that way it never made it
   into the CPE requirements list...) - because it would empower their
   customers to more easily switch ISPs, while they would have to pay
   the development costs.


 - source address *failover* in case a machine has multiple source 
   addresses and one of them is broken.  We have happy eyeballs for 
   "multiple destinations", but as far as I'm aware (maybe I have 
   missed something) still no "we might want to probe multiple sources
   if the preferred best source seems to be non-working".  

   Actually this thread is fixing one of scenarios when this can happen
   (because your router went belly-up), but there's "you have two /64
   from two ISPs on your LAN, with two routers happily announcing their
   RAs, but one of them just cannot reach your preferred destination due
   to external breakage" - in which case you want to try the other source.


 - the whole "multiple /48 multihoming" debacle - combined with homenet, 
   this is a really great idea for SoHo environments, especially if you
   combine it with application smartness, so you can tell your web
   browser "I want to surf via MyCableNet now!" while your torrent client
   is filling YourDSL.ISP link...

   Instead of having nice things, what we *do* get is RFCs that explain
   "if your primary ISP goes belly-up, withdraw primary RA, send RA for
   secondary ISP"...  (sorry, Jen, but I think this is a bandaid for a
   much more fundamental flaw).


 - Firewalls on home routers - so, what do I need global IPv6 addresses
   in my home network if IETF keeps telling people "you better should not
   have these addresses reachable from the world!! because, security!!!"?

   Combined with "CPE market fails" I can now have native IPv6 at home
   (great), combined with a CPE that has severe limitations on what can
   be permitted in its ACL handling.  Well, after some 5 years, AVM *did*
   manage to permit IPv6 traffic to DHCPv6-PD-delegated prefixes, but 
   this is still unsatisfactory.


 - did I mention CPEs?  Like, AVM, which claims that there is no way
   to transport IPv4 over an IPv6-transported VPN, so their CPEs will not
   implement VPN over IPv6.  Great combination if you're sitting behind
   a ds-lite ISP and have no public v4 address at all...

   (bashing AVM is actually somewhat unfair, since most other CPE vendors
   are 10 years behind)


 - did I mention VPNs?  Like, Fortinet, who do support VPN over IPv6, and
   IPv6 over VPN.  And VPN over IPv4, and IPv4 over VPN.  But they do not
   support "IPv4 payload over IPv6 VPN", because, "where is the business
   case for that?" - like "I'm sitting behind a carrier-grade NAT IPv4 
   at home, but I have proper IPv6, and I want to reach my IPv4-only
   backend servers in the datacenter over your VPN"...


 - I *did* mention the dual-stack IPv6 socket API, did I, with lots of
   extra code paths everywhere and the amount of bugs this introduces?
   (in retrospective I can only applaud OpenBSD for refusing to implement
   it - I did not understand it back then, "because it is so much more
   convenient!", but I was wrong)


 - another market fail: 3GPP mandates IPv6 for UMTS.  3 out of 4 mobile
   ISPs in DE do not offer IPv6 at all... (nowadays it's no longer "3"
   since Telefonica bought E-Plus, but when 3G was rolled out, none of
   the 3 had any interest in v6...)


 - and of course, having to deploy IPv4 in 2019, because "The Internet"
   took over 20 years to not-deploy IPv6 widely enough that we could 
   finally start shutting down IPv4...  instead we have haggling and
   arguments galore over the last scraps of IPv4...


So, that was the unsorted "things that came to my mind" list - it might
be factually not correct if I missed interesting new developments, and
it might be unfair to people that had the best of intentions, but this
is where we are: in an annoying mess of half-done half-working things.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: [phone]         USt-IdNr.: DE813185279