Re: moving to IPv6

[Phil Howard <phil () charon milepost com>]

Sean M. Doran writes...

> Phil Howard <phil () charon milepost com> writes:
>
> > The transition to IPv6 is clearly going to have some difficulties.  We are
> > waiting on:
> >
> > 1.  Network equipment, with translation
> > translation 
> > have to have translations
> > routing software includes translation 
>
> Bingo!
>
> The thing that amazes me about people who are fans of IPv6
> is that they have realized that NAT is THE fundamental
> scaling technology for the Internet.
>
> Translation of addresses, whether it is between IPv4 and
> IPv4 or involves protocol translations as well (as is the
> case in IPv4->IPv6->IPv4, or IPv6->IPv4->IPv6), is simply
> the most practical and effective way of overcoming the two
> principal scaling problems of the Internet, namely the
> narrowness of the IPv4 address and the fact that deployed
> routing protocols simply suck.
>
> Observe that so long as a translatable subset of transport
> layer options are used, there is absolutely no difference
> between NAT between IPv4 addresses and protocol
> translation between IPv4 and IPv6.   Moreover, in the
> latter case, you are not restricted to IPv6s4 (who comes
> up with these acronyms anyway?  Does anyone mind if I call
> IPv4 IP?  If you do, well, tough.)

I came up with "IPv6s4" when I wrote that, lacking a concise
reference to the subset of IPv6 space that is supposed to be
the equivalent to the puny IPv4 space.

I notice in your response that your meaning of translate and
my meaning of translate are entirely different things.  What
I mean by translate is something that will not change the
address, but only the packet format.

Translating addresses does solve some problems, but it is not
the ultimate solution for anything.  It's just a quick fix.
It's like chopping off "19" to save a couple bytes back when
storage space was a premium and managers were sure they would
be able to come back and fix everything at no cost in the year
2000.



> The technical goal is that end to end services will work,
> period, in all cases.  This is possible provided that the
> higher order protocols do not make invalid assumptions
> about the transport layer.  Most importantly, just as CIDR

What kinds of assumptions do you think might be made that would
cause NAT to fail?


> requires that protocol implementations respect that IP
> addresses may change over time, NAT as THE new fundamental
> scaling technology requires that protocol implementations
> respect that IP addresses may change over space as well.

There are some assumptions that are valid to make, that fail
with NAT.  For example the assumption that 2 or more packets
or connections using the same IP address will be the very
same interface.  While that is usually the case, NAT does
not make it so, and there are now boxes on the market that
specifically offer to make multiple machines appear a one.
That has advantages in certain cases, but it shouldn't be
applied in others.


> That is, so long as protocols do not assume that an IP
> address is the same from the point of view of all
> locations throughout the concatenated Internet, they will
> do just fine with either NAT or protocol translation or
> both.

You would have to be sure that there is no translation
taking place other than at the end points.  Paths do change
in time, and if those changes switch NATs, then either some
new thing has to pass along those changes to the new NAT
to preserve consistency, or else the IP does change.


> Returning to the observation that NAT and protocol
> translation are semantically equivalent from an end-to-end
> perspective, we now need to consider whether simple
> address translation or protocol translation is a better
> idea.


> > But just having [network routing software] translating IPv4 <-> IPv6s4 is not enough.
> > We will need to manage the new IPv6 network. 
>
> Deployed base is a strong engineering consderation in an
> industry which is experiencing enormous growth.  NAT has
> the advantage that reasonably designed existing
> technologies ought not even notice that NAT is happening.

You've switched your terms and are now using "reasonably designed"
to mean "assuming NAT might be in effect".  Many protocols break
with NAT.  NAT contrains the flexibility in protocol design that
TCP/IP was supposed to give us.

With NAT, it really isn't the principle of TCP/IP anymore.


> Protocol translation, on the other hand, requires, as you
> say, new management techniques, which will generally
> involve lots of learning time on the part of lots of
> engineers and operators, wherever the new protocol is
> deployed.

I'm not sure what protocol translation you are referring to.
I referred to IPv4 <-> IPv6s4 (meaning to a specific space)
in my original post.  The translation itself is trivial and
doesn't require massive memory state.  The tools needed are
only some of the tools needed for IPv6.


> The fact is, that there may be a reason to deploy a new
> protocol that makes this worthwhile, however, you should
> also note that so long as a translation between transport
> layers is straightforward, there is no reason why the new
> protocol needs to be IPv6.

What should it be?  IPv7?


> In fact, I welcome IPv6's fan base working on protocol
> translation because there are also some more interesting
> experimental protocols which could be deployed in
> precisely the same fashion that do not suffer some of the
> brokenesses of IPv6.  Most notably:

Be sure I become clear about what specific kind of protocol
translation you are referring to.


> > Routing issues will become different in IPv6.
>
> This is simply untrue.  Routing issues are EXACTLY the
> same in IP and IPv6, the only difference is the width of
> the addresses, which worsens the poor scaling properties
> of IP with current routing protocols. 

It changes the impact of address space vs. route space.
If by snapping my fingers, everything were running IPv6
with every AS having exactly one IPv6 block, the size of
the route tables would shrink in number.  If the blocks
are assigned with only fixed sizes, then it is not even
needed to store the whole IP address for routing.


> > If IPv6 allocations will have varying sizes like CIDR, then we might
> > continue to have issues of size based route filtering.  
>
> Please understand that the size-based filtering is done to
> limit the number of prefixes carried, and that this is
> completely independent of IP vs IPv6.  If the number of
> prefixes must be kept to some maximum by filtering at,
> say, the 19 bit mark, the same maximum will be maintained
> even if the address space is much wider, and the
> straightforward way of doing that is to retain filters at
> the 19 bit mark.

I doubt if a /19 gets assigned to anyone.  I favor fixed sized IPv6
allocations.  It can work because there is enough space to give the
largest entity all they could ever use, and enough of those spaces
to give to each entity.

Then no one need be filtered.

Right now filtering favors the big guys, who are also the major
culprits in polluting the route space with too many prefixes.
The little guys can't (and often simply don't need) large enough
spaces to be routed.

Route table sizes need to be controlled, to be sure.  But with
the way space is handed out in IPv4 (I call it "dribble mode")
the route tables have grown for more than they need to be.  IPv6,
along with careful handling of it, can eliminate excess route
prefixes.  There won't be any need for more than 1 prefix per AS.
The AS probably should become part of the IPv6 space, but I'll
hold off on making that suggestion seriously until I see what
kinds of new routing might come along.


> > OTOH, with the
> > right methods of allocating IPv6 space, no one should ever have to come
> > back to get more space.  Eventually that should mean fewer routes as
> > IPv4/IPv6s4 closes down.  Route filtering should be encouraged on IPv4
> > space and prohibited on IPv6 space, at that point, IMHO.
>
>
> Could you pleace elaborate?  I am completely lost by your
> logic here.

In IPv4, one AS can have many prefixes, and there are lots of them out
there right now.  That's because as space fills up, administrators go
back for more.  They are not given all they think they might ever need
because there isn't enough of that to go around.

In IPv6 outside of IPv6s4, every AS can, and should, be given one and
only one prefix.  When do you think someone will come back for more space
if they originally got IPv6/64?  That's 18446744073709551616 addresses.
We might well be giving out even larger blocks.

And everyone can get the same size block, so the discrimination by size
can be eliminated (along with the excess prefixes that caused it in the
first place).

-- 
Phil Howard | no8spam1 () dumbads6 org suck4it2 () noplace9 edu stop0006 () anyplace net
  phil      | stop9it4 () nowhere7 edu eat4this () anywhere edu no5spam9 () no67ads7 com
    at      | crash343 () nowhere0 org end4ads5 () anyplace edu eat94me5 () anyplace net
  milepost  | end9it62 () anywhere net a9b4c5d7 () anywhere edu w7x2y0z2 () no4where net
    dot     | suck6it1 () nowhere0 edu eat33me7 () anywhere net crash530 () dumbads9 net
  com       | no6way53 () nowhere9 net stop2983 () lame9ads net die9spam () dumbads9 edu