Re: [v6ops] [GROW] Deaggregation by large organizations

[Matthew Petach <[e-mail]>]

On Thu, Oct 16, 2014 at 6:05 PM, Mark Andrews <[e-mail]> wrote:

>
> In message <CAEmG1=
> [e-mail]>, Matthew
> Petach writes:
> > --089e013a14fa48fd43050593df5a
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Thu, Oct 16, 2014 at 4:35 PM, Mark Andrews <[e-mail]> wrote:
> >
> > >
> > > In message <[e-mail]>, Owen
> DeLong
> > > writes:
> > > >
> > > > On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <[e-mail]
> >
> > > wrote:
> > > >
> > > > > Let me address a few points that were brought up by different
> people.
> > > > >
> > > > > Renumbering:
> > > > >
> > > > > We had great plans for making renumbering easy in the early days of
> > > IPv6. Remember A6 records and bit
> > > > labels in the DNS? But none of that went anywhere. The problem isn't
> so
> > > much that we can't push a prefi
> > > > x down the network or update the DNS (although both of these still
> have
> > > challenges associated with them
> > > > ), but that addresses tend to get hardcoded all over the place,
> starting
> > > with firewalls all the way up
> > > > to homegrown applications. I don't think renumbering addresses this
> > > issue, although it could help steer
> > > >  some smaller organizations away from PI.
> > > >
> > > > They never went anywhere because they focused on solving the easy
> part
> > > of the renumbering problem while
> > > >  utterly and completely ignoring the hard part.
> > > >
> > > > Easy part: Changing your stuff.
> > > > Hard part: Updating all of the prefix lists, filters, firewall rules,
> > > VPN configurations, and other con
> > > > figuration elements in systems not under your control that contain
> your
> > > prefixes (partner VPNs, peer ro
> > > > uters, etc.).
> > >
> > > Owen this a collective response to the list.
> > >
> > > Not all that hard at all.  Just send signed update requests.  I did
> > > that with email over a decade ago.  You just have to have something
> > > listening for them that verifies the signature and updates the
> > > system.
> > >
> > > Write a draft "Remote Firewall Update Request Protocol" and submit
> > > it.
> > >
> > > The alternative is stop worrying about the remote address and use
> > > security at the application layer.
> > >
> > > Or complain to your vendor that you can't use a hostname in the
> > > configuration file element.  In many cases it doesn't require
> > > anything more than looking up a address in the DNS before the
> > > operation.  Yes, I need to fix the masters clause in named to support
> > > this.  We already do something similar for NOTIFY messages so it
> > > is possible to do this.
> > >
> > > For masters clauses there is a bootstrap problem to deal with but
> > > it is not impossible.  Just sending periodic NOTIFY messages will
> > > work.  Named has had support to do this for 1 1/2 decades now to
> > > allow for a a stealth master behind a dial on demand link.  It would
> > > send a notify periodically.  That would bring up the line.  The
> > > slave would refresh and transfer if required.  When that was complete
> > > the idle timer on link would drop it.
> > >
> > > This just used standard signalling designed by the IETF in a different
> > > way.
> > >
> > > Stop expecting someone else to *find* and fix these issues for you.
> > > You know what the issues are.  Ask your vendors to fix them.  If
> > > they need to co-ordinate they should know where to go to do it.
> > >
> >
> > Or, y'know, we could just get PI space,
> > multihome via BGP, and save ourselves
> > all that headache...
> >
> > ...just sayin'...
> >
> > Matt
>
> And when we can support 40 billion routes, PI becomes a viable
> solution.  Yes, this is the level that PI needs to be able to scale
> to for it to be a actual solution.  Yes, mutiple routes for every
> single person on the planet.
>
> Until then we need to work towards making renumbering work so PI
> isn't needed.
>


The probability of us figuring out how to scale
the routing table to handle 40 billion prefixes
is orders of magnitude more likely than solving
the headaches associated with dynamic host
renumbering.  That ship has done gone and
sailed, hit the proverbial iceberg, and is gathering
barnacles at the bottom of the ocean.
It is an ex-solution.
It is pushing up the daisies.
It has gone to meet its working group.
It is no more.

(with apologies to Monty Python)

Matt



>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
>
>