|
Re: US DoD and IPv6
2010-10-08 17:49:27
On Fri Oct 8 17:49:28 2010, Keith Moore wrote:
On Oct 8, 2010, at 12:31 PM, Dave Cridland wrote:
> On Fri Oct 8 17:10:56 2010, Keith Moore wrote:
>> Except that neither middleboxes in general nor NATs in
particular were a direct result of the decision to adopt IPv6.
NATs were not originally driven by a shortage of IPv4 addresses.
In the consumer market they were driven by what came to be a de
facto standard of one IP address per customer, due partially to
this assumption being widespread within IETF itself. In the
enterprise network space they were initially driven by a misguided
notion that having private addresses would produce better network
security. In both cases the adoption of NATs was largely a
consequence of IETF's failure to produce and adhere to a
comprehensive plug-and-ping autoconfiguration architecture.
>
> Oh, I think there's rather more than that.
Of course there is, but I was trying to be brief.
Oh, sure, but I think the points you glossed over in that effort were
more significant that the points you retained.
> Initially, NATs came about because enthusiasts found that it was
prohibitively expensive to get a routed block down a modem - the
ISPs treated you like a business customer, and charged accordingly.
But part of that was because single-address-per-customer (or dialin
session) was naturally a commodity service, while routing a block
down a modem was something that required special-case handling at
the ISP. And I think it's fair to say that that was the
assumption in IETF also. I don't recall any efforts toward
autoconfiguration of networks then, particularly not for those
connected via point-to-point links. It's hard to not blame the
ISPs for wanting to charge differently for one-address dialin vs.
other accounts that required more customization, setup, and support
on their part.
Absolutely, and I basically stated that later - that's why the ISPs
changed from actively trying to supress such usage into actively
supporting it, because it meant that network setups became, from
their viewpoints, "free".
> As NATs drifted into the enterprise, there was a security angle,
but there was also a renumbering angle that still hasn't gone away.
This is, in no small part, because the only way to refer to an
arbitary network is via the addressing - actual hosts are largely
dealt with by a combination of DHCP and DNS. (As a random thought,
if there was a CIDR DNS RR, I wonder if this may help?)
Not sure what you mean by a CIDR DNS RR, but I hope it's nothing
like A6 / DPTR was.
In IPv4 terms a DNS RR that meant I could lookup what
dave.cridland.net's network was, and get back 217.155.137.156/29, and
therefore use the network name instead of the IP addresses in
configuration, such as firewalling rules, DHCP server config, etc.
I vaguely recall the A6/DPTR combination as being rather more
ambitious than that, but really, a search/replace on a zonefile
during a renumber is pretty easy. It's the hunting down the network
references in router configs and firewall rules that's the pain.
> There is occasional rumblings within the IETF to address this,
but given NATs have to some extent removed the bulk of the pain,
I'm not sure there's sufficient motivation to solve all the issues.
And there's always considerable pressure on and within IETF to
"just embrace NAT" for this.
Right - it's a vicious circle, too, because we must embrace NAT
because no other solution exists, but there's no point developing a
better solution because NAT exists. Unfortunately, renumbering still
happens even when you're using 10/8, so NAT doesn't answer all the
cases.
> So currently, a NAT provides:
>
> - A degree of de-facto firewalling for everyone.
> - An immunity to renumbering for enterprises.
> - Fully automated network routing for ISPs.
>
> If technologies could be introduced to tackle especially the last
two, I think the advantages of NATs would vanish.
But the "NATs are good" mentality would still be widespread. Old
timers hate to learn how to use new tools, even if the old tools
are crap.
Right, and we need to work around that damage with stuff like BEHAVE,
and careful application design.
Still, to my mind, I have the feeling that end-to-end addressing
could actually be a security and reliability benefit to many
peer-to-peer applications (VOIP and IM file transfer being just two
that spring to mind), so there could be interest in getting there
from here.
Moreover, if we tackle the renumbering and automated routing case
(and I think the latter is largely done - not my area though) then
we've provided the tools for home and enterprise alike to ween
themselves off NAT quite effectively.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|