ietf
[Top] [All Lists]

Re: A Good Schism Brightens Anyone's Day (was: A Simple Question)

2003-04-29 16:41:43
g'day,

Iljitsch van Beijnum wrote:

On dinsdag, apr 29, 2003, at 20:24 Europe/Amsterdam, Peter Deutsch
wrote:
...
How is answering any of these questions going to help us? "Oh, NATed
traffic is 7% and not 5%! You are right we should have site local
addresses then!"

Well, I've a couple of responses to that.

One, of course is that if NAT traffic is really only 5%, and it happens
to be falling over time, then we should maybe stop spending so much time
arguing about it. :-)

(Note, if I really wanted to be excommunicated from this list, I could
have done a s/NAT/IPv6/ on the above paragraph ;-)


More to the point, folks are throwing around quite a few categoric
statements of fact and I assume they do this to help persuade others to
their point of view.

Here's a quick sampling of statements presented over the past few days
to support the two sides of the debate (Note, Please don't take offense
if you recognize your own words in this list - I'm not criticizing the
authors or disputing the facts, just assuming that the authors are
expecting folks to make decisions based upon these claims, and so was
thinking it could be useful if at least some of these claims could be
substantiated or disproved):

    - "there are more rfc1918 end hosts than there are non-rfc1918
       end hosts, and the uses being made of rfc1918 aren't limited
       to "couldn't get enough unique address space" situations."

     - "NAT is most often used to extend a single address to
        cover multiple systems in a home or small office 
        environment. For that environment, an IPv6 /48 
        (without site-locals) would suffice to replace NAT."

     - "NAT is used almost everywhere (perhaps outside the US)
        - almost everywhere."

     - "When you are talking about tens of millions of customers,
        it's not feasible to give each a subnet even if you have
        the space to do it.  IMHO, most customers will be placed
        on a /64 that's shared across hundreds of customers, similar
        to IPv4 common practice."

     - "While it is true that address conservation isn't that
        significant an issue, the whole issue of provider
        independence (or lack thereof) continues to exist."

     - "One of the biggest costs in renumbering is the 
        disruption it causes. The actual cost of editing
        the files, etc, is trivial by comparison."

     - "Even RFC1918 addresses get connected sometimes through
        corporate mergers. It would work better if organizations
        would choose a random set of subnets from 10/8, so the
        chance of overlap is minimized."

     - "They [ISPs] charge extra for two hosts because it 
        is assumed two hosts consume more bits than one, not
        because a second IPv4 address is hard to come by."

Now, it may be true that *all* of the above statements are true, but
they don't help me because I can't tell, from the statements alone,
which ones are actually *relevant* to the debate. So, just as in your
somewhat offhand use of "7% versus 5%" above, it all seems a little bit
like the statement that "46 percent of all statistics are made up". So,
which is it - seven percent, or over half?? For a bunch of architects,
folks around here don't seem as concerned about the foundations as I'd
have expected... ;-)


The current state of IPv6 deployment has very little bearing on future
IPv6 deployment. Just look back 20 years in IPv4. I don't think any of
the problems we have today could have been predicted by looking at the
network then.

Well, this is a good example where something may be true, but not
relevant. If, after all this "Sturm und Drang", IPv6 is not yet growing
faster than overall network traffic, those of us who remember X.500 may
conclude that it's not going to be relevant to me within an event
horizon that I need to care about, so I might conclude that I can ignore
it (and by extension, arguments predicated on its success). Now, this
may get me excommunicated from this list, but it may be the right thing
for me to do. How can I tell from this thread? I could be persuaded to
pay attention to such arguments by some numbers.


Another observation, there appears to be at least two major schools of
philosophy at work here (time for another random analogy for you Science
majors to go look up on Google... ;-)

One school appears to be focused on the problems of the locally Self
Sufficient Network User, with his own clsuter of simple machines behind
a NAT box (Sort of a Network Thoreau, in which we are each building our
own local "Walden Puddle". We learn to adapt to scarcity by making
frugality and reuse a virture, etc).  The big issues are whether certain
applications can work behind NATs, will I interfere with others, and so
on. 

The other school appears to be focused on the needs of large corporate
Networks. Here the focus is on renumbering issues, folks assume network
admins are in charge of and care about routing issues, etc. The Super
Administrator is assumed to have more intelligence and Power than the
average user here (Sort of Nietzsche's UberMensch, running his UberNet,
if I may be so bold);


Now, if "there are more rfc1918 end hosts than there are non-rfc1918 end
hosts" and "NAT is most often used to extend a single address to cover
multiple systems in a home or small office" then I might be inclined to
give more weight to arguments which make the network a better place for
the Thoreaus of the world (or is that "Bllom County"?), but if the most
important issues for our future are really going to be about supporting
large campus installations, it might drive the trade-offs in a different
direction. There Are No Free Lunches, so knowing what the target is
might help us all collectively take better aim....



...
As I read this my first reaction was "great observation, it's good to
see a new idea enter this debate". Then, a milliblip later my brain
fired a neuron that yelled out "Hey, aren't NATs just a means for users
to provide themselves with a topologically independent addresses to
divorce them from the topologically oriented address space imposed on
them by their ISPs?"

No, of course not. That's like saying English is the official language
of China because when you read about something said in China it is
translated in English.


But then you state:
...
I wouldn't presume to know why people use NAT because I'm not one of
them. (Beginning to feel like a minority.) 

Well, if anyone's going to argue against them, shouldn't they at least
understand why they're being deployed?? ;-)



But let me make some
observations:

- If we don't give people any sort of private address space, many will
just take something and at some point some of this will clash with
something else.

- If we set aside a small range of addresses for private use, many
people will use the same addresses so when networks merge there will be
trouble. In IPv4, this is often solved with NAT. So in IPv6 the same
will happen OR people will have spend a lot of time and money
renumbering.

Again, just to illustrate my thesis, in the above response you seem to
assume:

        - network merging happens often enough that it is a significant
          problem that must be addressed at the architectural level
          (that is, here at the IETF);
        - it costs a lot of time and money to renumber.

If either of these assertions is not true, you have to go back to the
beginning and start again. Ergo, knowing whether such
assumptions/assertions/axioms are true would be useful for those of us
trying to follow along without a program...  QED



                                - peterd

-- 

---------------------------------------------------------------------
    Peter Deutsch                       pdeutsch(_at_)gydig(_dot_)com
    Gydig Software


  "It is inhumane, in my opinion, to force people who have a
   genuine medical need for coffee to wait in line behind people
   who apparently view it as some kind of recreational activity."

                                        -- Dave Barry

---------------------------------------------------------------------



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