Re: The renumbering problem [Re: [BEHAVE] Comments on the NAT66 draft]

[james woodyatt <[e-mail]>]

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 <[e-mail]>
member of technical staff, communications engineering