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

[Rémi Després <remi.despres@rd-iptech.com>]

Fred Baker wrote:

What I am concerned about is the proliferation of inconsistent  strategies, and the set of cases I can come up with in which they do  not work. That is the issue I am trying to raise.

Hi Fred,

I very much share the concern about end to end connectivity in the complex configurations that are being built for the coexistence of IPv4 and IPv6 (Yref http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.txt).

Indeed this was the main reason for my I-D http://www.ietf.org/internet-drafts/draft-despres-v6ops-transition-v5roadmap-00.txt.

After IETF63 in Paris I received about it this comment from Pekka Nikander:  

" It is  very hard to evaluate its potential technical merit; that would  take far too much time. I would encourage you to write more introduction, trying to  present the ideas without going into too much detail and without  using too much new terminology."

Here is an attempt at introducing the subject better.

• During the v4-v6 coexistence period, there will inevitably be a mix of  hosts, customer routers, and provider services having various mixes of coexistence tools.
• Due to the highly combinatorial nature of the problem, analysing in all cases which connectivities are possible, along which routes, and using which encapsulations, seems  beyond feasibility.
• A simplified model would therefore be welcome if with it, for a well chosen set of standard coexistence functions in some hosts, edge routers and ISP gateways:
• The above analysis would becomes tractable.
• Extensive connectivity would be available, including for legacy v4-only and future v6-only hosts.
• Selected routes and encapsulations would be optimum according to natural criteria.

The purpose of the I-D was to introduce an approach toward such a simplified model, covering in particular, but not only, IPvX networks across IPvY networks (X and Y being v4, v6 or v4 + v6).  

This model as it stands needs no new protocol. It only needs that:

• a particular v6 address format be defined, upward compatible with all existing ones;
• some code be added in those entities (hosts, customer edge routers, ISP gateways) which claim compatibility with the new address format. This code would have to be be carefully specified but, dealing with only a few simple concepts, would not be voluminous. It would maintain upward compatibility with all other existing coexistence tools.

If some edge routers and ISP gateways supporting the address format would be deployed, they would provide powerful v6 capabilities to concerned  customer sites, independently or in association with whatever transition tools other sites and ISPs may have deployed.  

Although the I-D is specific on a number of details (some of which are still bugged - my apologies!), the current proposal is just a tentative example of what could be worth standardizing to tame the beast.

It already appears, after IETF-63 that, STUN and Teredo should be integrated in some way in the model, and that the distinction between mobile and fixed IPv4 services would advantageously be replaced by that between global v4 address- and private v4 address- Wan services. (The latter implies one or several layers of v4 NATs in the ISP infrastructure).

Also, as you pointed out to me, the choice of "v5" to name an intermediate status between v4 and v6 is unfortunate because of various connotations. "vB" for example could be better, meaning (standardized) Bistandard. (Not to be confused with Dual stack, which would refer to v4 and v6 side by side).

Is it appropriate that a discussion on this work starts here ?
I am not sure, but your contribution on the End to End Problem, and some of the points made about  DSTM, suggest it could be productive for IETF, at leat as long as the LRW BOF hasn't led to a WG.

Regards.

 
Rémi Després