[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The renumbering problem [Re: [BEHAVE] Comments on the NAT66 draft]
On Nov 19, 2008, at 03:22, Gert Doering wrote:
On Tue, Nov 18, 2008 at 06:29:54PM -0600, james woodyatt wrote:
Please, help me understand why solving this problem requires
storing IP addresses in persistent storage without a coherent
caching protocol. I'm not seeing it-- probably because I'm not
sure I understand the nature and scope of the problem very well.
Uh, well, people usually configure their VPN endpoints (site-to-site,
not roadwarrior-to-home) with IP addresses.
Ah. I've given this more thought now, and I'm going to assume that
we're talking about L3 VPN's and not L2VPN's (but I'm not sure that's
warranted here).
For the sake of argument, I'll accept that reasonable people
currently
perceive it to be necessary. My hunch is that those folks should
probably be using DNS-SD instead of the fragile cruftiness they're
struggling against now. Maybe if I understood the problem better, I
could suggest a more detailed alternative to their current solution.
Well. Yes. I've spent some time after my e-mail yesterday to think
about
this, and actually using DNS (plus some sort of "not completely
braindead
IPSEC implementation") might just work, provided one can get old+new
addresses working for long enough to DNS to propagate.
Which is not instantaneous, as soon as it leaves the local domain.
Now *this* aspect reduces itself to "educated people that DNS is good"
and "educate firewall vendors to write useful IPSEC code".
Now that I've had a chance to think about this more carefully, I'm
reminded of the old, old days when I used to work in an enterprise
that managed its routing table by copying static routes around with /
usr/bin/rcp. This eventually became painful enough that some bright
soul noticed that networked computers can executed distributed route-
computation algorithms, e.g. Bellman-Ford, link-state, etc.
I suspect that large enterprise sites with massive collections of
static VPN tunnel configurations, which need their tunnel endpoint
addresses renumbered when adding or dropping a PA allocation, would do
well to think about how such distributed algorithms could be used to
ease the pain of renumbering.
I would imagine that enterprises with this problem would have an
incentive to develop a standard protocol for automatically managing
the routes for complicated VPN topologies. (I'll even go so far to
say that something like BGP might be easily adapted to serve in this
capacity, but I'm not sure.) I do feel pretty certain about this
point: before we set about systematically dismantling the utility of
the provider aggregated addressing architecture in IPv6 as it relates
to our problems maintaining the scalability of the default-free zone,
I'd like to see an explanation for why enterprises view automating VPN
tunnel management as a non-viable alternative solution.
Another thing that is regularily mentioned regarding "why
renumbering is
hard" is access-lists (aka "firewall rules"). DNS as well?
Sigh. It's probably a good idea for large sites to use network
operations and management systems that recognize the distinction
between the network prefix and the host identifier parts of IPv6
address.
I recognize that not all IPv6 addresses have such a distinction, but
enterprises worried about this could conceivably choose IPv6
deployments where the distinction is significant-- because they can
use [or build] tools that easily allow access-lists to be composed
automagickally by combining the host identifiers (don't need
renumbering) with network identifiers (do need renumbering) without
requiring a human person to have to sweat all that tedious arithmetic
and typing.
I anticipate a rebuttal to my arguments above along the lines of this:
"That's nice, James... but those routing protocols and network
management tools don't exist today, and we need them!" My response is
quite simple: "True, but those are problems worth solving, and I don't
see how it's a good idea to *avoid* the work of solving them at the
cost of A) introducing NAT66 into the Internet architecture and/or B)
exploding the routing tables in the default-free zone."
I could be wrong about that, but I remain unconvinced.
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering