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

From: Rémi Després <[email-masked]>
Date: Tue, 29 Nov 2011 16:31:07 +0100

Hi all,

 Some IETF-82 participants have expressed wishes to pursue the work on 4rd-U. Alain mentioned to me he would be interested, as Softwire chair, he would be interested in having at IETF 83 not only the MAP proposal (with its Encapsulation and Translation variants), but also a 4rd-U proposal. He also said I would be welcome to lead the effort. 

 To start the work, I therefore plan to edit in December a new version of the 4rd-U draft. It will be in particular updated  to delete the Max-PSID/Max-EA-bits mechanism.
 For the discussion starting from it, the plan is to have a 4rd-U mailing list on the IETF site.
 On this list, all those wishing to contribute to the 4rd-U proposal will be invited to participate (including, of course, those who are already interested in MAP, both approaches remaining open at this stage).
 
Please le me know if you plan to contribute.

 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. 

Best regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Nov 2011 17:15:01 +0100

Remi,

> 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.
the main objection to 4rd-u is that it is 'just another translation' solution. how many do we need? it doesn't appear to offer any benefits compared to the already specified solution. as it stands it will just result in 3 ways of doing the same thing, instead of 2.

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. every node doing this will have to look into the L4 header anyway.

cheers,
Ole

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Nov 2011 09:33:38 -0800

Remi,

Thank you for starting this discussion on the mailing list.
Let me clarify my chair perspective on 4rd-u

You brought this to the Taipei meeting as an attempt to 'unify' encapsulation and translation.
I have always been of the opinion that fewer options are better, so I support attempts at converging the solution space.

The caveat is, if the proponents of the other solutions are not inclined to adopt the new 'unified' scheme,
we end up with just one more incompatible solution.

Now, I have observed during the Taipei meeting a certain level of interest to understand better the 4rd-u proposal,
as some of technical characteristics were not clear to the majority of the working group.

WIth that and the previous point in mind, I'd like to encourage you to keep working on 4rd-u and come back next meeting
in Paris. I hope by them those technical characteristics will be clearly understood by the working group and we could
form a wg consensus  as to whether this work is useful or distracting.

Alain.

On Nov 29, 2011, at 10:31 AM, Rémi Després wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Nov 2011 18:44:25 +0100

> form a wg consensus  as to whether this work is useful or distracting.

I don't think we need 4 months to make this decision. Further, it seems very inconsistent to call an Interim meeting on this general solution space in order to speed convergence, and then turn around and give a very long meeting cycle as a deadline for what amounts to a relatively small piece of the overall solution space. 

- Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 Nov 2011 19:11:35 +0100

> 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

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Nov 2011 19:47:33 +0100

Remi,

to summarize my view:
 - the 4rd-u proposal (including the changes you plan) are well understood
 - the main ideas from 4rd-* are already incorporated into MAP
 - 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.
 - I think it is the wrong thing for this working group to encourage development of yet another solution, when we already
   have many.
 - I would also like to see one solution, my choice is encapsulation. given that all the building blocks already exist, I
   would expect we'll see translation in the wild too, whatever we choose to do in the IETF. ref: NAT464.

I really hope this is the last I'll ever write on this topic.

cheers,
Ole

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 29 Nov 2011 20:08:28 +0100

On 11/29/11 7:47 PM, Ole Troan wrote:
> Remi,
>
> to summarize my view: - the 4rd-u proposal (including the changes you
> plan) are well understood - the main ideas from 4rd-* are already
> incorporated into MAP - 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. - I think
> it is the wrong thing for this working group to encourage development
> of yet another solution, when we already have many. - I would also
> like to see one solution, my choice is encapsulation. given that all
> the building blocks already exist, I would expect we'll see
> translation in the wild too, whatever we choose to do in the IETF.
> ref: NAT464.

+1

You nailed it.

Best, Jan Zorz

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Nov 2011 22:55:26 +0100

My *principle* objection to anything other than basic encapsulation is that it is not basic encapsulation. Plain and simple. 

I did say in the meeting that I didn't like anything that caused "destination spray" but that wasn't my principle concern. It's great to know that 4rd-U is actually immune to that concern. It's a very clever mechanism. 

But to the point of what I tried to convey in the meeting - my point was that  *if*  the world would agree to move to 4rd-U and leave both basic encap and NAT64 behind, then it would be to the good of all. One standard is better than two or three in this case. Failing that, I'd personally like to see basic encap as a MUST and anything else as an alternative, though I admit that there are some that would like to see NAT64 as the MUST and everything else as the alternative. From my point of view (and now I think I am repeating what I said at the microphone) is that when tunneling, basic encapsulation is very well understood, consistent with RFC 6333 already defined in the softwires WG, and that I could go to any operator in the world and say "tunneling via IP in IP encapsulation" and they immediately understand what it means, pros as well as cons. Anything beyond this is an optimization. Perhaps a very worthy optimization, but an optimization nonetheless. If the optimization is important enough to override the ubiquity of simple encapsulation, fantastic, let's do that. If not, let's keep it as an alternative. 

- Mark

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Nov 2011 09:35:02 +0100

> - 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.

>   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

  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

 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

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Nov 2011 10:13:37 +0100

Le 29 nov. 2011 à 22:55, Mark Townsley a écrit :

> But to the point of what I tried to convey in the meeting - my point was that  *if*  the world would agree to move to 4rd-U and leave both basic encap and NAT64 behind, then it would be to the good of all. One standard is better than two or three in this case.

On this, we agree (supposing that it is the stateless double translation that may be "left behind" if 4rd-U is adopted, not the NAT64 of behave which won't disappear) 

> Failing that, I'd personally like to see basic encap as a MUST and anything else as an alternative, though I admit that there are some that would like to see NAT64 as the MUST and everything else as the alternative.

> From my point of view (and now I think I am repeating what I said at the microphone) is that when tunneling, basic encapsulation is very well understood, consistent with RFC 6333 already defined in the softwires WG, and that I could go to any operator in the world and say "tunneling via IP in IP encapsulation" and they immediately understand what it means, pros as well as cons.

AFAIK, it is also easy to immediately understand that, for IPv4-across-IPv6 tunnels, IPv4 headers can be reversibly mapped into IPv6 headers having their fragmentation extension.  
This is just a tunneling variant.

For 6rd, the same simple idea couldn't apply because IPv6 headers are too large to be be reversibly mapped into IPv4 headers. Encapsulation was then the obvious solution. But here we deal with IPv4 in IPv6, a simpler case.

> Anything beyond this is an optimization. Perhaps a very worthy optimization, but an optimization nonetheless. If the optimization is important enough to override the ubiquity of simple encapsulation, fantastic, let's do that. If not, let's keep it as an alternative.

No, it isn't just "optimization" of the encapsulation solution: it satisfies operational requirements of double translation proponents, the only chance to have a single standard without forcefully ignoring these requirements. 

At this stage, the best is I believe to complete specifications of double translation, of encapsulation, and of unified, and THEN to compare and decide.

Regards,
RD