Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt

From: Elwyn Davies <[email-masked]>
Date: Thu, 25 Aug 2005 17:13:33 +0100

Hi.

The intention of this draft is excellent - using a single scheme for 
connecting across IPv4 clouds is clearly essential to achieve e2e 
interoperability in the world encapsulated in the diagrams.  The 
question that comes to my mind is just how much does this represent a 
time that has already gone by?

The scenarios do not include situations where the IPv4 cloud is a 
convenient substrate to build a tunnel between an IPv6 enabled stub and 
'the' IPv6 transit backbone (which will be used until such time as 
native IPv6 connectivity arrives at the stub's attachment point(s)).

There are already global IPv6 transit providers, and sitting here in 
front of my home system, my ISP provides me with an IPv6 prefix and 
capability to use an IPv6-in-IPv4 tunnel to an endpoint in their network 
which then connects me onto the IPv6 backbone.

Hence before expending a lot of effort on determining (and 'marketing') 
whatever might be the 'best' solution in the pure IPv4 core case I 
believe we should get some idea of the relative importance of the pure 
IPv4 core case as compared with IPv4 providing a tunnel substrate for 
connecting to the IPv6 transit backbone.

Be that as it may, I suspect I may be lucky in having an 'enlightened' 
ISP and it might be necesssary for less lucky users to connect to a 
gateway onto the IPv6 backbone in some other domain than their own 
ISP's.  In this case the thoughts in the draft probably apply to the 
connection between the "own ISP's" domain and the domain with the IPv6 
backbone gateway.

Regards,
Elwyn

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Aug 2005 19:46:45 +0300 (EEST)

On Thu, 25 Aug 2005, Elwyn Davies wrote:
> whatever might be the 'best' solution in the pure IPv4 core case I believe we 
> should get some idea of the relative importance of the pure IPv4 core case as 
> compared with IPv4 providing a tunnel substrate for connecting to the IPv6 
> transit backbone.

I had a little bit of the same concern.  It seemed as if document was 
discussing solutions for end-to-end IPv6 connectivity mechanisms 
between two or more v4 islands (or vice versa for v4 and v6 islands).

My take was similar to yours: we don't need end-to-end v6 connectivity 
*mechanisms* (provided by one site to another).  We'll just ask the 
sites to connect to the v6 internet.  They might do it via their 
direct upstream or someone else, but which one doesn't matter that 
much as long as the "v6 backbone" doesn't get fragmented.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Fri, 26 Aug 2005 16:34:46 +0100

On Thu, Aug 25, 2005 at 07:46:45PM +0300, Pekka Savola wrote:
> >whatever might be the 'best' solution in the pure IPv4 core case I believe 
> >we should get some idea of the relative importance of the pure IPv4 core 
> >case as compared with IPv4 providing a tunnel substrate for connecting to 
> >the IPv6 transit backbone.
> 

Seems we all got different thoughts from the document, which is probably
a good sign :)   It seemed to me that the less clear scenario was the one
where an IPv6 only backbone is deployed and IPv4 transit still required.

-- 
Tim/::1