Re: [Softwires] Unified proposal for stateless IPv4 Residual Deployments (4rd-U) - Contributors?

[Rémi Després <[e-mail]>]

Le 29 nov. 2011 à 19:47, Ole Troan a écrit :

> Remi,
> 
> to summarize my view:
> - the 4rd-u proposal (including the changes you plan) are well understood

   Except that you believe it is a translation solution (which means AFAIK RFC6145 based), while it isn't.

> - the main ideas from 4rd-* are already incorporated into MAP

   Except the fact that, with the two variants of MAP, IPv6 ACLs, web caches, DCCP transparency, and DF-bit transparency cannot be
 simultaneously available.

> - 4rd-u is a slightly different way of doing translation (calling mapping doesn't change that fact)
>   go to behave to argue if yours is better than what was specified there.

  Let us ask Dan Wing whether he believes it would fit in Behave.

> - I think it is the wrong thing for this working group to encourage development of yet another solution, when we already
>   have many.

  Are you missing that it is proposed two replace two standards by just one? 
 
> - I would also like to see one solution, my choice is encapsulation.

  Well understood.
  But this is AFAIK ignoring arguments of double-translation proponents.

> given that all the building blocks already exist,

  4rd-u has large building blocks that are common with encapsulation, and small differences that are AFAIK simple to implement and easy to deploy. 

> I
>   would expect we'll see translation in the wild too, whatever we choose to do in the IETF. ref: NAT464.

 We will see deployments of NAT64/DNS64, as standardized by Behave, I agree.
 But stateless NAT464 doesn't need to be standardized if both DS-lite and 4rd-U exist.
 
> I really hope this is the last I'll ever write on this topic.

 This depends on you more than on anything else. 

RD





> cheers,
> Ole
> 
> 
> On Nov 29, 2011, at 19:11 , Rémi Després wrote:
> 
>> Le 29 nov. 2011 à 17:15, Ole Troan a écrit :
>> 
>>> Remi,
>>> 
>>>> For those who attended the Softwire session in Taipei, please note that the serious objection against 4rd-U expressed by several participants during the meeting has been, soon after, acknowledged to be invalid (www.ietf.org/mail-archive/web/softwires/current/msg03281.html).
>>>> Also, other (less important) objections have been answered in www.ietf.org/mail-archive/web/softwires/current/msg03284.html, without reaction so far. 
>>> 
>>> I do not think that's a fair representation.
>> 
>> It was intended to be one, and is still believed to be so (see below)
>> 
>>> the main objection to 4rd-u is that it is 'just another translation' solution.
>> 
>> a)
>> That's not what I heard during the meeting.
>> Both Mark Townsley and Dave Thaler, taking for granted your statement that checksum-neutral addresses of 4rd-U would cause "address spray", said firmly that 4rd-U should be rejected because it wouldn't work.
>> 
>> In my understanding, not working is a show stopper, which I call a "main objection".
>> 
>> b) If your main objection is that 4rd-U would be 'just another translation', it is ALSO invalid. 
>> If you have read my answer to your list of objections, you should know that 4rd-U is a reversible-header-mapping solution, and as such is based on neither translation nor encapsulation. (actually a tunnel closer to encapsulation in my understanding).
>> 
>> 
>>> how many do we need?
>> 
>> Many consider that, if there is the choice, ONE standard is better than several.
>> 
>> The point is that 4rd-U combines advantages of double translation and encapsulation with only a slightly different tradeoff between optimizations of header-length and processing time.
>> 
>> Doubts are legitimate as long as the specification is incomplete, but that's why more work is needed.
>> 
>> 
>>> it doesn't appear to offer any benefits compared to the already specified solution.
>> 
>> Which solution? (So far, there are two in the pipe - translation and encapsulation.)
>> Meeting requirements of both solutions is AFAIK a benefit.
>> 
>> 
>>> as it stands it will just result in 3 ways of doing the same thing, instead of 2.
>> 
>> Different view on this.
>> Three standards would make no sense.
>> 
>> 
>>> the topic discussed in softwires, wasn't the main objection. as far as I can see, "checksum neutrality" does not offer any advantages over incrementally updating the L4 checksum.
>> 
>> Again, commenting my previous answer to your list of objections would be be more constructive than repeating that 4rd-U doesn't do anything without arguing on substance.
>> 
>> Since there is no obligation to comment, please refrain from criticizing a solution without commenting previous answers made for you.
>> 
>> 
>>> every node doing this will have to look into the L4 header anyway.
>> 
>> Sure. IPv4 address sharing implies _looking_ at port fields (true also for encapsulation).
>> 
>> But this doesn't imply that L4 data need to be  modified, especially if these modifications need to depend on whether the protocol is TCP UDP, DCCP, etc. 
>> Encapsulation and reversible header mapping don't care about this, which is one of their virtues.
>> 
>> Cheers,
>> RD
>> 
>