[ppml] IPv6, thread diverging from 'policy' to 'background info'...

[Phil Howard]

On Wed, Jan 08, 2003 at 06:20:22PM -0500, Dave Diller wrote:

| > The problems I see are:
| > Currently I am getting service from 2 ISPs (multi-homed), and 
| > for me to use V6, both of them will have to be
| > properly setup.
| 
| 
| This seems to be the chicken-and-egg thing again... Maybe I'm missing
| something, but I'm not clear on why everyone thinks "I can't *possibly* do it
| till my provider does it".  With that kind of viewpoint, nothing'll ever get
| done as everyone is waiting for everyone "one step up" to do it, and the larger
| providers are naturally going to be moving much more slowly on deployment than
| some of the smaller ones.... larger, more complex network means more layers of
| formality to major network changes, as well as more things to test, yadda yadda
| yadda.

I would dare say it we depended on those very companies to build an internet,
we would not be anywhere near where we are today (and IPv4 would still appear
to have decades of capacity remaining).


| As I understand it [see OReilly quotes below], an ISP can receive a /32 from
| ARIN, and then said ISP can use 6to4 to get native v6 working in their own
| network, and encapsulate traffic onto the existing v4 network to get to other
| v6 sites - which means their upstream IS NOT REQUIRED to run IPv6.  Does this
| not work in practice?  
| 
| I'm certain it would be CLEANER if your upstream could give you a native V6
| pipe, but this would at least get YOU empowered and running on YOUR network in
| the interim.  What am I missing?  What is the source of the seemingly common
| perception of "I must wait for my upstream to do it first!"?

What appears to me to be the case is that the policies are written not so much
in terms of the transition, but in terms of the final deployment.  It's more like
this is how it will be when things are rolling.

It's already enough that IPv6 doesn't really buy me anything.  But maybe I can't
even get it in the first place, so it might be moot, anyway.


| Page 229, Tunnelling Techniques:
| 
| Tunnelling mechanisms can be used to deploy an IPv6 fowarding infrastructure
| while the overall IPv4 infrastructure is still the basis.  Tunnelling can be
| used to carry IPv6 packets by encapsulating it in IPv4 packets and tunnelling
| it over the IPv4 infrastructure.  For instance, if your provider still has an
| IPv4-only infrastructure, tunnelling allows youto have a corporate IPv6 network
| and tunnel through your ISP's IPv4 network to reach other IPv6 hosts or
| networks.
| 
| It then refers the reader to RFCs 2473 (Encapsulation with IPv6), 2893
| (Automatic and Configured Tunnelling), and 3056 (6to4).

Hmmm, no proxy tunneling.  I don't see why you can't do 6to4 proxying (besides
not finding any RFC for it).  It would certainly avoid issues like MTU.

-- 
Phil Howard
phil at ipal.net