[186489] in North American Network Operators' Group
Re: Nat
daemon@ATHENA.MIT.EDU (James R Cutler)
Sat Dec 19 14:32:28 2015
X-Original-To: nanog@nanog.org
From: James R Cutler <james.cutler@consultant.com>
In-Reply-To: <CAEmG1=pCB71kYrn_Nyht7cMMPd06s3GL_LqsR_F=i2Lbpy37jw@mail.gmail.com>
Date: Sat, 19 Dec 2015 14:32:21 -0500
To: Matthew Petach <mpetach@netflight.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
This is OT of NAT, but follows the existing discussion.
Since discussion has warped around to host configuration DHCP (again), =
it might be useful to review discussions dating from 2011:
The stupidity of trying to "fix=E2=80=9D DHCPv6
and
The Business Wisdom of trying to "fix=E2=80=9D DHCPv6
which also refer to discussions from 2009.
The pertinent Business View is=20
> The security domain for HOST should not overlap the security domain =
for ROUTER.
>=20
> That is the primary driver of the separate administration of HOST and =
ROUTER. Heaven help us if the latest M$ virus, or even =
social-engineering distributed malware began to affect BGP!
It is imperative to supply the features that End System Operators find =
useful for their business. This simple position is independent of =
IPv4/IPv6 differences. =20
Since DHCP is a Host Configuration tool and is quite independent of =
router configurations except for DHCP forwarding entries, we must quit =
requiring ongoing fiddly network router configuration changes to make =
End System configuration changes. These can be centrally managed by DHCP =
run to meet End System configuration requirement, even including =
providing default routes. This simple position is independent of =
IPv4/IPv6 differences.
All that is necessary is for us to end the years of religious debate of =
DHCP vs RA and to start providing solutions that meet business =
management needs.
James R. Cutler
James.cutler@consultant.com
PGP keys at http://pgp.mit.edu
> On Dec 19, 2015, at 1:01 PM, Matthew Petach <mpetach@netflight.com> =
wrote:
>=20
> On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee@asgard.org> wrote:
>>=20
>>=20
>> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>>=20
>>> 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.
>>=20
>>=20
>> Tell me again why you want this, and not routing information from the
>> router?
>=20
> Apologies for the delay in replying, work has
> been insanely busy as we come to the end
> of the quarter.
>=20
> 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.
>=20
> 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?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
>>> 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.
>>=20
>> There=C2=B9s 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 =
=C2=B3we=C2=B9d
>> rather delay IPv6 than do it wrong=C2=B2 and =C2=B3be realistic about =
how people
>> will deploy it."
>>=20
>> Lee
>=20
> 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.
>=20
> 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?
>=20
> 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.
>=20
> Such hubris! Is it any wonder people avoid
> dealing with the IETF?
>=20
> OK. Taking some deep breaths and calming
> back down now...
>=20
> 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?
>=20
> Thanks!
>=20
> Matt
