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

["Sofia, Rute" <rute.sofia@siemens.com>]

Hello,

While I have to agree that the intention of pin-pointing failures in
IPv4/IPv6 transition from an e2e perspective, this document falls short
in doing so...

What is currently missing in terms of e2e transition analysis is a doc
which not only points out problems but also provides some guidelines in
what concerns e2e transition, namely:

- current mechanisms and onto which e2e scenarios they apply best;
- approach multihoming scenarios 
- approach multicast and current support for it in the transition (done
in section 2.4 but in a very light way)
- bi-directional transition (which is still weak even though some
support is provided, e.g., by NAT64-46 or 6to4)
- interworking between the different solutions, given that it is highly
unlikely that a single transition mechanism is pursued by different
operators, as we are currently seeing.


Regards,
Rute Sofia

 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Elwyn Davies
> Sent: Thursday, August 25, 2005 6:14 PM
> To: Fred Baker
> Cc: 'v6ops@ops.ietf.org '
> Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> 
> 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
> 
> 
> 
>