quietly....

Wed Feb 2 21:49:15 UTC 2011

On Wed, Feb 2, 2011 at 1:13 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote:
>> Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
>
> I love this question, because it basically admits the protocol is
> broken.  To make RA's even remotely palitable, you need "RA Guard" on
> the switches.  This feature does not exist, but if we bring features
> like DHCP guard forward into the IPv6 world, it's the logical solution
> and solves the problem.
>
> However, to the IETF people who think this, they just don't understand
> how many networks are built and run.
>
> Let's split the problem space.  Ther are folks who say run hotel or dorm
> networks and need to protect from bad, bad users.  For them DHCP guard,
> RA guard, BotNet guard, and all sorts of other features need to be in
> the switches.
>
> However, there are a lot of corporate network users where there really
> is no rogue DHCP server.  Perhaps they are even using 802.1x on end user
> ports, so there are no rogue users at all.  However, they do need a
> robust networking configuration.
>
> I'll give the simple scenario I've done to myself twice.  Went to a
> remote site.  Replaced the router with a new router.  Took the old
> router back to the office and plugged it in so I could upgrade the code.
>
> IPv6 stopped working instantly.
> IPv4 kept working just fine, forever.
>
> Why?  Well, the router from the other site sends out RA's as soon as it
> is plugged in, and all the hosts believe it and sink traffic to it.  On
> the IPv4 side it was a DHCP HELPER.
>
> Let me repeat that, it's the part the IETF folks always miss.
>
> IT WAS A DHCP HELPER.
>
> A box on the network goes to do a DHCP request.  It goes to the
> actual router, and to this "rogue" remote office router.  However, being
> not configured correctly the rogue router's DHCP helper points to a
> default route out a WAN interface that is down, and the packet is
> dropped.  No response, the host gets a response from the real router and
> all is well.
>
> The mere act of plugging in a old router takes down IPv6, but leaves
> IPv4 working just fine.  I'd say that's a LOT less robust.  Rather than
> give me IPv6 DHCP that works like IPv4, and thus would be just as
> robust, the IVTF, the vendors making the decisions, want me to deploy RA
> guard, which ooops, isn't on any of the old switches so you'll have to
> replace all of them.
>
> Basically, as an operator, the vendors got together, developed a
> broken protocol, figured out a work-around that requires me to replace
> everything.  Or in short, the vendors figured out how to make me replace
> everything.

+1

Owen DeLong wrote, in response to the same query:
>The lack of default router capabilities in DHCPv6 is a major disappointment.
>Yes, there are ways to work around this limitation in most environments, but, it is problematic to have this limitation.

+1

These seemingly minor features being absent caused 2 enterprises I
consulted with in the medium-large size range (5,000-ish servers) to
reject IPv6 for the time being.  I could not figure out how to glue
around the deficiency without fundamentally modifying how they manage
and build and operate their server networks.  They have several
million end users of their services, probably approaching 10 million.

-- 
-george william herbert
george.herbert at gmail.com