ietf
[Top] [All Lists]

Re: A follow up question

2003-04-25 21:06:38
I've been following this thread with great interest for weeks, and only now do I think I have useful contribution to make to the discussion. It's long. Sorry about that. Cope.

On Thursday, Apr 24, 2003, at 12:55 US/Pacific, Tony Hain wrote:
[...]
Leading people away from something comfortable requires providing
something that meets the same basic need and is easier/cheaper/more
comfortable. Many use NAT because they can't get STABLE addresses
otherwise, and NAT is simply the cost of getting that. Providing STABLE
local use prefixes simultaneously with global prefixes that may change
over time is a cheaper way to meet the need for STABLE addresses.

* I emphasize STABLE because that is a invariant requirement by many
managers of large networks.
[...]

I don't know whether to laugh or cry. Using a NAT doesn't give you address stability. It's a total illusion.

Sure, your hosts all get RFC 1918 addresses that you assign yourself, but your NAT has to have at least one public realm address or the whole drill is pointless. Without the NAT, you might as well set yourself up as your own private IANA-- you can be the King of Jellybeanland, if you like.

If you really want stable addresses, it seems to me (and correct me if I'm technically wrong about this) the only way you get that is to get yourself an AS number and a collection of prefixes and go into a BGP peering relationship. Otherwise, you have to renumber every time your default route provider tells you it's your turn.

What the NAT really does for you is reduce the complexity of your renumbering events. When the provider for your default route tells you it's your turn to renumber this week, you just renumber the NAT-- no manual editing of /etc/hosts with /usr/bin/vi is required on every Sun-3 on your network, isn't that nice?

Coping with the termination of application flows through the NAT when it gets renumbered is the main problem that has to be managed here. Note: site-local addresses and NAT do not solve this problem, and they were never intended for that purpose. It's a problem that has to be managed in *any* renumbering, and the only way to avoid it is to avoid renumbering events entirely. Good luck on that; write if you get funding.

If we're going to have a useful discussion about "the renumbering problem," we need to start by recognizing that it's more than simply reconfiguring routers and the bestiary of other middleboxen that seem to be inserting themselves into the network everywhere.

Applications have bad habits.

They cache network addresses when they should be caching names. There is never a decent mechanism for keeping the cache coherent with the actual topology of the network. Frequent renumbering exposes these bad habits. Network administrators quickly learn that there is no pain more exquisite than explaining to the CFO that the reason the payroll isn't getting processed is that the ISP forced a renumbering and there's no good way to fix the application databases in the data center that have the wrong IP addresses stored in them. Worse, you probably can't even sue the vendor for selling shoddy code because of the "as-is" "unwarranted" foo in the contract language.

And you might have written the code yourself.  Now *there's* pain.

So with IPv4, everyone uses a NAT, and they don't have this hassle. They have other huge hassles as a result, but at least they don't have *this* one. And they love it.

Applications can continue to be written by code monkeys with no clear concept of how the network really works, they can cache network addresses in labels with permanent adhesive glue affixed to the rack where the equipment is mounted, they can treat network addresses like they map one-for-one with nodes (even nodes with multiple interfaces), they can even force lowly users to memorize them and transcribe them by hand, and the network administrators can still keep the business logic from crashing and staying down for a week when the public addresses of the site have to be renumbered.

Sometimes I think the biggest mistake we ever made was letting the application coders set their eyes on the bits in the network address. Giving them a human-readable representation was a mistake. Even letting them know how many bits are in an address was ill-advised. I know better of course, but then... *I'm* one of those poor souls with the dubious honor of having written an ALG for IPsec VPN applications. It's personal with me.

The really bad news-- I hate to break this-- is that IPv6 won't magickally make applications developers smarter. When existing applications are extended to IPv6 and new applications are developed with IPv6 in mind, they will be developed by the same people with the same misconceptions about how the network works. Our API's for using IPv6 look too much like the ones for IPv4 to break those misconceptions.

People will continue to cache network addresses on printed labels glued to the rack and they will continue to expect users to memorize and transcribe them by hand. We can keep telling them not to do it, *but*... why should we expect them to start listening to us? They never have done before, and we've been droning on about it for more years than I can count.

It would be just peachy if there was an architecture available that would preserve the E2E principle while still permitting organizations to shield their private applications from having to be just barely smart enough to respond well to their nodes experiencing the renumbering of their global unicast node addresses. I don't think there is one.

I'm reminded of Oscar Wilde's reported last words. Maybe we need to learn how to make the drapes match the rest of the decor.

If the problem with site-local addresses is that they cause more problems than they solve-- and I believe that to be true-- then, maybe solving the problems they cause is a good idea. I have a radical proposal to that effect: deprecate the site-local prefix (on the grounds that it is overkill); disallow the propagation of routes for all V4MAPPED addresses; disallow the forwarding of packets with V4MAPPED addresses anywhere in the header; *except*, allow interior routing protocols, as a transition mechanism, to propagate routes for V4MAPPED addresses in prefixes that correspond to the RFC 1918 addresses, and allow such packets to be forwarded on interior links.

This will permit impolite applications to move to IPv6 without having to learn better manners, while allowing network administrators a transition path for supporting their applications until they get versions that can handle renumbering events without bursting into flames.

And plusplusgood: it contains the disease within the quarantine wire of the IPv4 transition foo. The addresses are all still about as memorizable as the ones we are all using now. Even better, the function for getting the IPv6 address for a host from the IPv4 address that is printed on the label glued to the rack is to prepend the "::FFFF:" string to it and you're off to breakfast. Still better: if you're clever, you can even forbid V4MAPPED addresses of every stripe from showing up in AAAA records by requiring applications that depend on this transition mechanism to work to convert IPv4 addresses into V4MAPPED addresses explicitly.

There.  I'm done.  Back to lurk mode.


--
j h woodyatt <jhw(_at_)wetware(_dot_)com>
that's my village calling... no doubt, they want their idiot back.




<Prev in Thread] Current Thread [Next in Thread>