Nat

Sat Dec 19 19:32:21 UTC 2015

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” DHCPv6
and
The Business Wisdom of trying to "fix” DHCPv6

which also refer to discussions from 2009.

The pertinent Business View is 
> The security domain for HOST should not overlap the security domain for ROUTER.
> 
> 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.  

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 at consultant.com
PGP keys at http://pgp.mit.edu

> On Dec 19, 2015, at 1:01 PM, Matthew Petach <mpetach at netflight.com> wrote:
> 
> 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