Nat

Sat Dec 19 18:01:54 UTC 2015

On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee at asgard.org> wrote:
>
>
> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>
>>I'm still waiting for the IETF to come around
>>to allowing feature parity between IPv4 and IPv6
>>when it comes to DHCP.  The stance of not
>>allowing the DHCP server to assign a default
>>gateway to the host in IPv6 is a big stumbling
>>point for at least one large enterprise I'm aware
>>of.
>
>
> Tell me again why you want this, and not routing information from the
> router?

Apologies for the delay in replying, work has
been insanely busy as we come to the end
of the quarter.

The problem is when you have multiple routers
in a common arena, there's no way to associate
a given client with a given router unless the DHCP
server can give out that information.

In an enterprise wireless environment,
you have many different subnets
for different sets of employees.  Unfortunately,
the reality of common RF spectrum dictates
you can't do separate SSIDs for every subnet
your employees belong to; so, you have one
SSID for the company that employees associate
with, and then the DHCP server issues an appropriate
IP to the laptop based on the certificate/credentials
presented.  In the v4 world, you get your IP address
and your router information all from the DHCP server,
you end up on the right subnet in the right building
for your job classification, and all is good.
In the v6 world, your DHCP server hands you an IP
address, but the client sees an entire spectrum of
routers to choose from, with no idea of which one
would be most appropriate to make use of.  Do I
use the one that's here in the same building as me,
or do I use one that's several blocks away in an
entirely different part of the campus?

The wonderful thing about modern wireless setups
for enterprises is that you can allow your employees
to all have their laptops configured to associate with
the same SSID, and handle all the issues of assigning
them to a particular subnet and vlan at the RADIUS/DHCPv4
level; you don't have to have different employees on
different SSIDs for finance vs engineering vs HR
vs sales.  In v4, you can segment the employees
very nicely after they've associated with the AP
and give them all the necessary information for
building in which they're in.  V6 doesn't provide that
ability; so, I associate with the AP, I get my IPv6 address,
and then I look at which possible routers are announcing
information about my subnet, and I see there's one in
building B, one in building F, and one in building W, and
I just randomly pick one, which may be nearby, or may
be across the other side of campus.  Furthermore, I also
see all the announcements from routers for subnets
I'm *not* a part of, cluttering up the spectrum.  Rather
than have routers spewing out "here I am" messages
and taking up RF spectrum, I'd much prefer to explicitly
tell clients "you're in sales, you're in building W, here's
your IP address, and use the upstream router located
in your building."  No extra RF spectrum used up by
routers all over the place saying "here I am", no issues
of clients choosing a less-optimal upstream router and
then complaining about latency and performance.

I can see where in some environments, routers
using RAs to announce their presence to clients
makes sense.  Large-scale enterprise wireless
isn't one of those; so, give us the *ability* to
choose to explicitly give out router information
via DHCPv6 in those situations.  I'm not saying
RAs are bad; I'm simply saying that the IETF
plugging its ears to the needs of enterprises
and claiming that we just don't 'get' how IPv6
is supposed to work and therefore they won't
support assigning router information via DHCPv6
is an impediment to more rapid adoption.

And for those of you who say "but just use
different SSIDs for every subnet in the company",
please go do some reading on how SSIDs
are beaconed, and what the effective limit
is on how many SSIDs you can have within
a given region of RF coverage.  It's generally
best to keep your SSID count in the single
digits; by the time you get more than a dozen
SSIDs, you're using up nearly half of your
RF spectrum just beaconing the SSIDs.

>> Right now, the biggest obstacle to IPv6
>>deployment seems to be the ivory-tower types
>>in the IETF that want to keep it pristine, vs
>>allowing it to work in the real world.
>
> There¹s a mix of people at IETF, but more operator input there would be
> helpful. I have a particular draft in mind that is stuck between ³we¹d
> rather delay IPv6 than do it wrong² and ³be realistic about how people
> will deploy it."
>
> Lee

I agree more operator input would be good;
unfortunately, it's easier for management to
say "let's just delay IPv6 until they get it
working" than it is to justify sending employees
to IETF meetings all over the place to explain
why their model of how IPv6 should work isn't
working out for the enterprise.

In effect, the IETF's stance is making it more
expensive for companies to deploy IPv6 than
simply stay on IPv4--so is it any wonder that
people aren't moving faster?

Reduce the friction preventing companies
from being able to do parallel, homologous
IPv6 deployments, and you'll see faster
movements.  Right now, the insistence that
IPv6 *must* be done differently, and *must*
be done with an orthogonal network design
and topology is an increased cost companies
are unwilling to bear.  And there is *NO* technical
reason that DHCPv6 could not be allowed to
provide identical information as DHCPv4; it
is purely human stubbornness on the part
of IETF members who insist that *their*
model of how IPv6 should be deployed is
better, and therefore they won't even allow
the *option* to do it a different way.

Such hubris!  Is it any wonder people avoid
dealing with the IETF?

OK.  Taking some deep breaths and calming
back down now...

Fundamentally, Lee, the challenge is when you
have multiple routers for a given subnet, how do
you put some set of clients pointing to one router,
and a different set of clients pointing to another
router using RAs?

Thanks!

Matt