RE: turning on comcast v6

["Tony Hain" <alh-ietf () tndh net>]

(Yes this is a top post ... get over it)

Thank you Leo for doing such a great job in this scenario of explaining why
acronym familiarity has much more to do with people's entrenched positions,
than the actual network manageability they claim to be worried about. The
hyperbolic nonsense in  >>> replace every ethernet switch in your entire
network with new hardware that supports "RA Guard", and then deploy new
configuration on every single port of every single device in your network.
Please develop a capital justification plan for Mr MoneyBagsCEO for
replacing every switch in your network so you can safely deploy IPv6. <<< ,
clearly shows that it is the spooky acronym "RA" that is more important to
focus on than reality.    It also does a nice job of wrapping up the point
about why an IPv6 rollout needs a long term plan with appropriate multi-year
budgeting.  ;)

For starters, in the scenario described, you only need 1 port protected, and
that is for the person that would be doing the configuration, so it is
likely pointless. Do you really believe that dhcp messages picked up by the
rogue router wouldn't end up answering with the wrong values and breaking
both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an IPv4
aware switch will do anything when an IPv6 DHCP message goes by? Don't you
have to replace every switch and reconfigure anyway? Or is rogue DHCP
service a problem that goes away with IPv4? Why do people continue to insist
that a cornerstone of their network security model is tied to an inherently
insecure protocol that was never intended to be used as a security tool? ...
but I digress ...

There are two very different models for IPv6 address/information allocation,
and each needs to be fully functional and independent of the other; period.
Unfortunately there have been too many voices demanding a 'one size fits
all' approach within the IETF, and we have gotten to the current situation
where you need to deploy parts of both models to have a functional network.
RFC 6106 is a half-baked concession from the 'dhcp is the only true way'
crowd to allow home networks to be functional, but if you want anything more
than DNS you have to return to the one-true-way, simply because getting
consensus for a more generic dhcp-options container in the RA was not going
to happen. The Routing Information DHCP option has been held hostage by
those that might be described as a 'dhcp is broken by design' crowd, because
many saw that as a bargaining point for consensus around a more feature rich
RA. Both hard line positions preventing utility in the other model are
wrong, but in the presence of a leadership mantra of one-size-fits-all,
neither side was willing to allow complete independent functionality to the
other. 

Making progress on the Routing Information option requires a clear scenario
to justify it, because vast swamp of dhcp options that have ever been used
in IPv4 are not brought forward without some current usage case. Lee was
asking for that input, and while the scenario you paint below might be
helped by that option, it presumes that every device on the network has
additional configuration to ignore an errant RA sent from the router being
configured simply because the network is supposed to using DHCP. The only
devices I know of that attempt to ignore an RA are Samsung's Android image
which do the stupid thing of configuring an address from the RA on the lan,
but refuse to create a routing entry from it if there has ever been a route
via the 4G radio. (that is fundamentally a platform bug because google lets
them set the knobs that way instead of doing the right thing as a metric
bias between the available routes for fall back when one or the other goes
away)   

Ryan's different dhcp answers based on auth state is a use case, and if in
widespread use as a way around 1X, it might get enough support by itself to
carry the day. If there are other use cases which are not self-contradictory
justifications of maintaining acronym familiarity, they will spread the
support base and make it easier to get past the objections. This is not
about which model is 'right', if anything limiting it is about minimizing
the different ways people can hang themselves without realizing the risks
beforehand. At the end of the day, the IETF's job is to document
technologies so vendors can implement for consistent behavior in
independently managed networks. Vendors will build whatever they are paid to
build, but if you want generic COTS, then lots of people need to justify a
specific behavior with some level of consistency to get that documented as
the consensus approach. So far there have not been enough consistent
scenarios to get an RI option passed.

Tony


> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell () ufp org]
> Sent: Monday, December 30, 2013 3:25 PM
> To: Lee Howard
> Cc: Jamie Bowden; North American Network Operators' Group
> Subject: Re: turning on comcast v6
>
>
> On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee () asgard org> wrote:
>
> > I'm not really an advocate for or against DHCP or RAs.  I really just
> > want to understand what feature is missing.
>
> I encourage you to try this simple experiment in your lab, because this
> happens all day long on corporate networks around the world, and
illustrates
> the differences quite nicely.  While not a complete treatment of the
> operational differences, it's an important illustration.
>
> Configure up a simple network topology of three boxes representing a hub
> and spoke network:
>
>                DHCP SVR
>                   |
> --lan--r1--wan--hubrtr--wan--r2--lan
>
> Number it up as expected for both protocols:
>
> wan links: IPv4 /30, IPv6 /64
> lan links: IPv4 /24, IPv6 /64
>
> Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests
to
> it.  Verify a machine plugged into either of the LANs gets a fully
functional
> network for both protocols.
>
> Now, take r1 turn it off, and stick it in a closet.  You see, that office
closed.
> Normal every day thing.
>
> Plug up two PC's to the remaining LAN off r2.  This represents your
desktop,
> and your neighbors desktop.  Think Bob from accounting perhaps.  Open two
> windows on each, one with an IPv4 ping, one with an IPv6 ping running.
>
> Now, boss man comes in and has a new office opening up.  Go grab the r1
> box out of the closet, you need to upgrade the code and reconfigure it.
> Cable it up to your PC with a serial port, open some some sort of terminal
> program so you can catch the boot and password recover it.  Plug it's
> ethernet into your lan, as you're going to need to tftp down new config,
and
> turn it on.
>
> Here's what you will soon find:
>
> 1) The IPv6 pings on both machines cease to work.
>
> 2) The IPv4 network continues to work just fine.
>
> Now, for even more fun, turn on another PC, say Sally from HR just
rebooted
> her machine.  It will come up in the same state, IPv6 not working, while
> IPv4 works just fine.
>
> Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are
> now complaining to him that their network is down, again.  Make sure you
> not only understand the technical nuances of why the problem above
> happened, but also how to explain them to a totally non-technical CEO.
>
> (Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how
> long until the pings start working again.  I think it's 15 minutes, IIRC.
For
> super-extra credit tell me how to make that time shorter for everyone on
> the LAN with Cisco or Juniper commands on r2.)
>
> I'll give you a hint on understanding this issue.  The IETF's grand
solution is to
> replace every ethernet switch in your entire network with new hardware
> that supports "RA Guard", and then deploy new configuration on every
> single port of every single device in your network.  Please develop a
capital
> justification plan for Mr MoneyBagsCEO for replacing every switch in your
> network so you can safely deploy IPv6.
>
> Now do you understand why people just want to put the route in DHCPv6
> and move on?
>
> It's not a "feature" that's different between the two, it's that
operationally
> they have entirely different attack surfaces and failure modes.  And yes,
it
> involves people doing stupid things.  However if the IETF is going to rely
on
> smart people deploying networking devices we might as well give up and go
> home now.
>
> --
>        Leo Bicknell - bicknell () ufp org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/