Subject: RE: (ngtrans) questions about 6to4

From: Brian Zill <[email-masked]>
Date: Fri, 21 Jul 2000 17:34:48 -0700

Hi Paul,

> > You're assuming you want one :-)
> 
> Please believe me, I was never assuming such a thing!

I was just joking.

> I had merely observed that native IPv6 addresses is
> the end-goal for IPv6, and so wondered why one wouldn't
> want to move towards that goal a bit quicker given the
> opportunity.

Yes, it was a good question.  But, more specifically, I think the goal is
getting everyone _connected_ natively.  Using "native" addresses over
configured tunnels isn't preferable to using "6to4" addresses over 6to4
automatic tunnels.  And note, you can route 6to4 addresses in native
v6-space as well as dropping them down to v4.  The use of "native" when used
with addresses means something different than the use of "native" when used
with transmission media.

> So, why would anybody ever move to native IPv6 addresses
> once they are happily using 6to4?

To save encapsulation overhead.  Both on the wire, and it terms of
processing power at the en/de/capsulation point.

> More to the point, why would an ISP ever start offering
> IPv6 services if all of their customers are happily
> tunneling their IPv6 over IPv4?

To recover the "wasted" bandwidth of the encapsulation overhead.  ISP's will
realize that their customer's only care about the IPv6 data going through,
so if they can carry IPv6 natively, they "get back" the amount of bandwidth
being used on IPv4 encapsulation.

There are also all the other good points about IPv6 that we've beaten to
death: ease of configuration, routing aggregation, etc. etc.

I suspect that a moderate amount of 6to4 use will be enough to demonstrate
to the ISPs that there is customer demand for IPv6.  And then they'll start
offering it natively.

--Brian

---

From: Paul Francis <[email-masked]>
Date: Mon, 24 Jul 2000 11:26:15 -0700

> being used on IPv4 encapsulation.

I cannot take seriously the idea that an ISP would go through the
tremendous expense of putting in an IPv6 infrastructure for the purpose
of saving 20 bytes per packet.

> death: ease of configuration, routing aggregation, etc. etc.

Ease of (host) configuration has nothing to do with 6to4.  An IPv6 site
operates the same whether it has 6to4 prefixes or native prefixes.  

At the risk of a little hand-waving---routing aggregation could still be
achieved in IPv4...once the IPv6 sites have renumbering running, ISPs
could change a customer's 6to4 prefix as easily as it could change the
customer's native prefix.  Or, looked at another way, we could allocate
a block of IPv4 addresses for use *only* with 6to4 prefixes.  We could
allocate the same number of these as we have top level native prefixes
now.  These would therefore have the same aggregation characteristics as
native v6 is supposed to have.  So I see no fundamental difference in
getting aggregation from 6to4 versus native.

Brad Huntting wrote:
> 
> > So, why would anybody ever move to native IPv6 addresses once they are
> > happily using 6to4? [....]
> 
> Because eventually they will want multicast.
> 

First of all, I doubt it...I see the global multicast world solidly
moving in the direction of unicast overlays.

But this is an arguable view, so lets assume for the sake of argument
that there is a demand for IPv6 global multicast.  Fine...do IPv6
multicast using IPv6 routers (that run multicast, not necessarily
unicast) with 6to4 prefixes... 

Bottom line, I still have yet to see a solid argument for why we need
native IPv6 prefixes at all...

PF

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Jul 2000 15:27:45 -0400

> of saving 20 bytes per packet.

I don't know about "tremendous expense"...I expect that ISPs will
evaluate IPv6 requirements as part of their normal facilities planning
and that they will upgrade their existing infrastructures to support
native IPv6 as part of their normal infrastructure improvement.  
The ability to save 20 bytes per packet might have a slight effect
on when an ISP decides to upgrade -- as might other economic 
considerations such as the ability to route v6 traffic more 
efficiently than is feasible with 6to4. 

> Ease of (host) configuration has nothing to do with 6to4.  

but ease of site configuration - especially in not needing to get 
a separate prefix - certainly is part of the incentive to use 6to4.

> customer's native prefix.  

yes.

> Or, looked at another way, we could allocate
> a block of IPv4 addresses for use *only* with 6to4 prefixes.  

we could, but insisting that 6to4 use such prefixes (which you would
need to get any benefit from this strategy) would make 6to4 
much less attractive and much less likely to be deployed.

> native IPv6 prefixes at all...

I don't know how soon we will need them - 6to4 provides a bit of
growing room.  but it seems unwise to assume that 6to4 prefixes
will always be sufficient forever.  I can certainly think of
potential IPv6 applications for which the existing number of 
unused IPv4 prefixes would not be sufficient - not that we
have the luxury of using all of the remaining prefixes v4 for 
6to4 anyway.    Even if 6to4 is wildly successful, we can expect 
the v4 net to be around for another decade or two, during which 
time those prefixes will likely be needed for native v4.

but 6to4 buys flexibility - it allows near-term deployment of v6 
along with an easy transition to native v6.  it lets the ISPs and 
the users decide when that transition should be made, and lets them
make that transition away from 6to4 (like the transition *to* 6to4)
if and when it makes sense to do so.

Keith