moving to IPv6

Mailman List Mirror (Read Only)
1

In the big spam thread, David R. Conrad writes...

>Until IPv6 is widely used

Are any ISPs seriously considering deploying IPv6 in the forseeable future
(e.g., what level of demand are ISPs in the US seeing for IPv6)?

What backbone providers offer it?

The transition to IPv6 is clearly going to have some difficulties. We are
waiting on:

1. Network equipment, with translation

2. End user software

3. Address space assignment

Either everything has to suddenly change to IPv6, or there has to be
translation tools in place. The translation between the IPv4 subblock
of IPv6 will be easy. But how much infrastructure will be ready to
go by the time customers have to use IPv6-only space? Sure, proxy
servers can allow some access, but many people will want full access.

IPv6-only space is of less value than IPv4-private space until IPv6
becomes at least fully routeable over the Internet. So the backbone
networks are going to have to take the lead to make it happen. Even
when it is routeable, it has to work on all the ends, which will thus
have to have translations to make their IPv4 space appear as IPv6sub4
space.

The best workable scenario I can see so far is one where IOS and other
routing software includes translation between IPv4 and IPv6s4 (I'll use
this term for the IPv4 equivalent sub block of IPv6 until someone tells
me there is a preferred term). Backbones need to become IPv6 capable
first, including the MAEs and NAPs, then any IPv6 interfaces can reach
other IPv6.

Step two is to transition the IPv4 services, like major web sites, to
IPv6s4. These services want to be full reachable, so as soon as we can
get users on IPv6, they will want to be on IPv6s4. To get users into
the IPv6 space, it may require a pricing differential. It will require
something. We still have many users running Windows 3.1 and some even
running just DOS.

If ISPs drop the IPv6 price, they lose money. They'd rather their
customers just stay on IPv4 (or IPv6s4) in that case.

If ISPs raise the IPv4 (or IPv6s4) price, they lose customers to some
other ISP that didn't.

Something is thus needed to encourage customers to move into IPv6 even
when it is fully routeable.

Since this is a network operation issue forum, the focus here should be
on how to handle this in the networks. To me, this part doesn't seem
all too technically difficult, once the software is available to handle
it. But just having IOS translating IPv4 <-> IPv6s4 is not enough.
We will need to manage the new IPv6 network. All the various tools we
use will need to understanding IPv6 and how it it configured on the
network. Routing will have to work right even during the transition
to this, which means BGP4v6 has to be there capable of understanding
IPv6 space at some point in time.

Routing issues will become different in IPv6.

If IPv6 allocations will have varying sizes like CIDR, then we might
continue to have issues of size based route filtering. 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.

2

I apologize that the quality of this message will be
somewhat limited by pressures of time and having to use a
really weird Microsoft keyboard that leaves me prone to
speeling mistakes, but I couldn't resist some of the
things being talked about in this thread.

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.)

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
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.

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.

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.

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.

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.

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:

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.

The only attractive (and this is very very very
speculative) aspect of the IPv6 address scheme is that it
may be wide enough to experiment with something like using
a modified IS-IS that works on multiple hierarchical areas
encoded as fields in the IPv6 address, with the thought of
using that to supplant current interdomain routing
protocols. I'm sure this thought will go over well with
the IPv6 crowd...

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.

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.

  Sean.

3

if global name to 'address' resolution is desired, then the directory
mechanism protocols, currently dns, need to be translated at address
and/or name domain boundaries. some nats currently do this.

are there other protocols/data which *must* be translated at boundaries?
should kink such as cuseeme be left to die?

randy

4

Sean M. Doran wrote:

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.

Well, there are two equivalent approaches to the scaling
problem: NAT or dynamic address allocation. I'm not convinced
that NAT is better in long term; though i won't argue that
this is the most practical near-term solution.

The advantage of dynamic addressing is that it preserves the
clean separation between application and transport layers,
which is more kosher architectually, and allows to make a lot
of things much simpler. The disadvantage is, it requires
serious rework of many things, while NAT can be just a "box"
in a middle.

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.

The claim that routing in IPv6 will be magically fixed is
exactly what prompted me to lose interest in IPv6 completely,
and tag the IPv6 crew as clowns.

--vadim

5

randy@psg.com (Randy Bush) writes:

if global name to 'address' resolution is desired, then the directory
mechanism protocols, currently dns, need to be translated at address
and/or name domain boundaries. some nats currently do this.

That is smaller problem compared to translating application protocol
information.

are there other protocols/data which *must* be translated at boundaries?

There are a full bunch of protocols that do include addresses
FTP control information for instance...

For FTP when translating between v4 and v6 the NAT box has to translate
commands as well as addresses...

PORT <-> LPRT
PASV <-> LPSV

etc...

should kink such as cuseeme be left to die?

Newer videoconferencing software does the same mistakes unfortunatly...
H.323 for instance requires snooping of several streams to be able to
translate packets.

  Pedro.