Subject: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 14:36:27 +0200

Hi Satoru-san,

Thank you for identifying a limitation of the 4rd-U  
You are right, as currently specified, "it doesn't support diff-serv tunneling model, pipe and short-pipe".
All these need e2e transparency to the IPv4 Type of Service.

Fortunately, this is easy to fix: in the Identification field of the IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.
  
The proposed 4r-U packet format becomes:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vers=6 |   TrafClass   |            Flow Label                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |Next Header=44 |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                  IPv6 Source Address                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                IPv6 Destination Address                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |    Reserved   | IPv6  Fragment Offset   | 0 |M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|      0      |    IPv4 TOS   |       IPv4 Identification     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        IPv4 Payload                           |
   |                                                               | 

With this added, I believe that 4rd-U is a real progress over previously proposed Double translation and Encapsulation.
It can make IMHO a valuable unified standard.

Yet, I may have missed something else. 
New justified objections are therefore most welcome..

Regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 17 Oct 2011 22:17:15 +0900

Hi Remi-san,

> It can make IMHO a valuable unified standard.

Not enough. The original TTL value in IPv4 header must be carried.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Mon, 17 Oct 2011 22:30:17 +0900

hi Satoru-san,

may i understand that, as Remi's proposal is applied for the double
translation case, TTL being translated to IPv6 Hop Limit is enough? as is
stated in RFC6145, translator is a "router" and therefore the behavior
should not be as same as the virtual link. right?
regards,
maoke
2011/10/17 Satoru Matsushima <[email-masked]>

> Hi Remi-san,
>
> > With this added, I believe that 4rd-U is a real progress over previously
> proposed Double translation and Encapsulation.
> > Fortunately, this is easy to fix: in the Identification field of the IPv6
> Fragment header, copy not only the DF bits but also the IPv4 TOS.
> >
> > With this added, I believe that 4rd-U is a real progress over previously
> proposed Double translation and Encapsulation.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 17 Oct 2011 22:48:42 +0900

Hi Maoke-san,

On 2011/10/17, at 22:30, Maoke wrote:

> hi Satoru-san,
>  
> may i understand that, as Remi's proposal is applied for the double translation case, TTL being translated to IPv6 Hop Limit is enough? as is stated in RFC6145, translator is a "router" and therefore the behavior should not be as same as the virtual link. right?

If so, just double translation is enough for that.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Mon, 17 Oct 2011 23:46:41 +0900

hi Satoru-san,

> If so, just double translation is enough for that.

it sounds nice. what i would like to have is a consistent header processing
for single/double translations and encapsulation.

can we keep the TTL of IPv4 in the IPv6 header (plus fragment header but not
anything more unless really necessary)?

can i understand that the following requirements are exclusive to each
other: (a) we want to keep TTL changed in the IPv6 domain as the behavior of
translation; (b) we want to keep TTL not changed until leaving the IPv6
domain as the behavior of encapsulation (4rd-U)?

RFC6145 has defined TTL<->HopLimit translation. then how about using another
reserved bit, say EF, in the fragment header for indicating the mode? if EF
= 1, it is encapsulation mode, and therefore the HopLimit in the base header
keeps unchanged untile being translated back to IPv4; if EF = 0, it is
translation mode, and the HopLimit in the base header will decrease 1 for
each hop. btw, previously i suggest using one of the reserved bits for the
DF (e.g., the one before MF) instead of the first bit of the identification
in the ipv6 fragement header, in order to avoid ambiguity caused by an IPv6
host in the single translation.

thus i'd like to suggest that one as follows, based on Remi's complement,
where E is the indicator of encapsulation mode. copying TOS in the fragment
header is fine because it doesn't impact the IPv6 dst (of single
translation) getting the original IPv4 src's relative identification.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Vers=6 |   TrafClass   |            Flow Label                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Payload Length        |Next Header=44 |   Hop Limit   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                  IPv6 Source Address                          +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                IPv6 Destination Address                       +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |   Reserved    | IPv6  Fragment Offset   |E|D|M|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |     TOS       |       IPv4 Identification     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        IPv4 Payload                           |
       |                                                               |
unfortunately, however, even we free the first bit of IPv6 identification in
the fragment header, we cannot put the TTL here (before the TOS) because
traversing different paths may cause inconsistant IPv6 identification values
in fragments of the same datagram and disable reassemble at the IPv6 dst (in
the single translation mode).

the problem of EF in fragment header is, it requires that the implementation
process fragment header before descreasing the HopLimit. is it feasible?

how do you think?

cheers,
maoke

> > > With this added, I believe that 4rd-U is a real progress over
> previously proposed Double translation and Encapsulation.
> > > Fortunately, this is easy to fix: in the Identification field of the
> IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.
> > >
> > > With this added, I believe that 4rd-U is a real progress over
> previously proposed Double translation and Encapsulation.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 18 Oct 2011 00:27:45 +0900

On 2011/10/17, at 23:46, Maoke wrote:

> it sounds nice. what i would like to have is a consistent header processing for single/double translations and encapsulation.

I think that encapsulation and double translation can't be consistent to processing packet at all.

>  
> can we keep the TTL of IPv4 in the IPv6 header (plus fragment header but not anything more unless really necessary)?
>  
> can i understand that the following requirements are exclusive to each other: (a) we want to keep TTL changed in the IPv6 domain as the behavior of translation; (b) we want to keep TTL not changed until leaving the IPv6 domain as the behavior of encapsulation (4rd-U)? 

I think that these are exclusive.

>  
> RFC6145 has defined TTL<->HopLimit translation. then how about using another reserved bit, say EF, in the fragment header for indicating the mode? if EF = 1, it is encapsulation mode, and therefore the HopLimit in the base header keeps unchanged untile being translated back to IPv4; if EF = 0, it is translation mode, and the HopLimit in the base header will decrease 1 for each hop. btw, previously i suggest using one of the reserved bits for the DF (e.g., the one before MF) instead of the first bit of the identification in the ipv6 fragement header, in order to avoid ambiguity caused by an IPv6 host in the single translation.

It seems that adding new semantics more. Very creative, but is it really needed even we already have both encaps and translation? When you want to define more new semantics, it would be better you define new protocol number for 4rd-U.

>  
> thus i'd like to suggest that one as follows, based on Remi's complement, where E is the indicator of encapsulation mode. copying TOS in the fragment header is fine because it doesn't impact the IPv6 dst (of single translation) getting the original IPv4 src's relative identification.
>  
> unfortunately, however, even we free the first bit of IPv6 identification in the fragment header, we cannot put the TTL here (before the TOS) because traversing different paths may cause inconsistant IPv6 identification values in fragments of the same datagram and disable reassemble at the IPv6 dst (in the single translation mode).
>  
> the problem of EF in fragment header is, it requires that the implementation process fragment header before descreasing the HopLimit. is it feasible?
>  
> how do you think?

IMHO, I'm not sure it is good idea to change the semantics of the IPv6 fragment. If a router receives 4rd-U packets, which router doesn't understand 4rd-U, processing these packets as fragmented packets could cause problem that sounds buffer exhaust attack. And I also think that if we need to add new semantics even we can utilize IPv6 fragment, it would be better to define new protocol number for 4rd-U. However, I don't think that we need to request to define it, because existing encapsulation and translation can be utilized for each appropriate situation.

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Tue, 18 Oct 2011 00:50:49 +0900

hi Satoru-san,

2011/10/18 Satoru Matsushima <[email-masked]>

> > it sounds nice. what i would like to have is a consistent header
> processing for single/double translations and encapsulation.
>

thanks for the correction. i meant the behavior similar to encapsulation but
implemented as double translation, but the wording was  wrong. :P

>
> >
> > can we keep the TTL of IPv4 in the IPv6 header (plus fragment header but
> not anything more unless really necessary)?
> >
> > RFC6145 has defined TTL<->HopLimit translation. then how about using
> another reserved bit, say EF, in the fragment header for indicating the
> mode? if EF = 1, it is encapsulation mode, and therefore the HopLimit in the
> base header keeps unchanged untile being translated back to IPv4; if EF = 0,
> it is translation mode, and the HopLimit in the base header will decrease 1
> for each hop. btw, previously i suggest using one of the reserved bits for
> the DF (e.g., the one before MF) instead of the first bit of the
> identification in the ipv6 fragement header, in order to avoid ambiguity
> caused by an IPv6 host in the single translation.
>
> It seems that adding new semantics more. Very creative, but is it really
> needed even we already have both encaps and translation? When you want to
> define more new semantics, it would be better you define new protocol number
> for 4rd-U.

> ...

>
> > the problem of EF in fragment header is, it requires that the
> implementation process fragment header before descreasing the HopLimit. is
> it feasible?
> >
> > how do you think?
>
> IMHO, I'm not sure it is good idea to change the semantics of the IPv6
> fragment. If a router receives 4rd-U packets, which router doesn't
> understand 4rd-U, processing these packets as fragmented packets could cause
> problem that sounds buffer exhaust attack. And I also think that if we need
> to add new semantics even we can utilize IPv6 fragment, it would be better
> to define new protocol number for 4rd-U. However, I don't think that we need
> to request to define it, because existing encapsulation and translation can
> be utilized for each appropriate situation.
>
>
good point. however, Remi's proposed problem is a real concern. the solution
putting DF as the first bit at IPv6 identification doesn't cause the trouble
on routers but may hurt the single translation behavior. the translator
should not know if the packet will be translated back to IPv4 later or not.

cheers,
maoke

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 18:09:03 +0200

> I think that encapsulation and double translation can't be consistent to processing packet at all.

4rd-u (duly completed with TOS transparency) is neither Double RFC6145 translation nor Encapsulation.
It is believed to have advantages over both of them.
Disadvantages has AFAIK still to be identified.

> I think that these are exclusive.

Indeed, one cant't do both simultaneously, but AFAIK either choice is acceptable. 
Is there one you prefer, for which reason?

> It seems that adding new semantics more. Very creative, but is it really needed even we already have both encaps and translation? When you want to define more new semantics, it would be better you…

The idea is to avoid having two designs, each one with its own limitations, while a third design exists that has none of these limitations.

A key advantage of Double translation over Encapsulation, is that the IPv6 next header is the same as the Protocol of the conveyed IPv4 packet. Having a new protocol number would therefore defeat the objective of having advantages of both Double translation and encapsulations.

> IMHO, I'm not sure it is good idea to change the semantics of the IPv6 fragment. If a router receives 4rd-U packets, which router doesn't understand 4rd-U, processing these packets as fragmented packets could cause problem that sounds buffer exhaust attack.

I don't see that:
- IPv6 routers are not concerned with fragmentation.
- the 4rd-U endpoint doesn't need to keep anything in a reassembly buffer if a conveyed IPv4 packet is completely contained in a single IPv6 packet.

> And I also think that if we need to add new semantics even we can utilize IPv6 fragment, it would be better to define new protocol number for 4rd-U.

See above why a new protocol number wouldn't be workable.

> However, I don't think that we need to request to define it, because existing encapsulation and translation can be utilized for each appropriate situation.

The point isn't to prevent any ISP from deploy for its own use any design that works.

Yet, having only ONE STANDARD for a given need is better than several. 
I hope you can agree with that.
(In this case, the need is stateless support of residual IPv4 across IPv6-only networks.)

AFAIK, 4rd-U is better for this than double translation (say 4rd-T), and better than encapsulation (say 4rd-E), because it combines advantages of both (applicability of IPv6 O&M tools (a feature of 4rd-T), AND e2e transparency to IPv4 semantics (a feature of 4rd-E).  
If you still believe this is not right, an explanation will of course be welcome.

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Oct 2011 18:15:43 +0200

Remi,

how is 4rd-U different from translation?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 18:26:25 +0200

> how is 4rd-U different from translation?

Functionally, full network transparency to DF bit (and TOS with the complement that was missing).
Technically, see for instance Figure 1 of the draft.

Cheers,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Oct 2011 11:41:12 -0500

the idea of 4rd-U is to map IPv4 headers into IPv6 headers

address translation is called address derivation.

Isn't this translation?

regards,

Behcet

On Mon, Oct 17, 2011 at 11:26 AM, Rémi Després <[email-masked]>wrote:

> >>>> can we keep the TTL of IPv4 in the IPv6 header (plus fragment header
> but not anything more unless really necessary)?
> >>>>
> >>> It seems that adding new semantics more. Very creative, but is it
> really needed even we already have both encaps and translation? When you
> want to define more new semantics, it would be better you define new
> protocol number for 4rd-U.
> >>
> >> The idea is to avoid having two designs, each one with its own
> limitations, while a third design exists that has none of these limitations.
> >>
> >> A key advantage of Double translation over Encapsulation, is that the
> IPv6 next header is the same as the Protocol of the conveyed IPv4 packet.
> Having a new protocol number would therefore defeat the objective of having
> advantages of both Double translation and encapsulations.
> >>
> >>>> thus i'd like to suggest that one as follows, based on Remi's
> complement, where E is the indicator of encapsulation mode. copying TOS in
> the fragment header is fine because it doesn't impact the IPv6 dst (of
> single translation) getting the original IPv4 src's relative identification.
> >>>>
> >>>> unfortunately, however, even we free the first bit of IPv6
> identification in the fragment header, we cannot put the TTL here (before
> the TOS) because traversing different paths may cause inconsistant IPv6
> identification values in fragments of the same datagram and disable
> reassemble at the IPv6 dst (in the single translation mode).
> >>>>
> problem that sounds buffer exhaust attack.
> >>
> >> I don't see that:
> >> - the 4rd-U endpoint doesn't need to keep anything in a reassembly
> buffer if a conveyed IPv4 packet is completely contained in a single IPv6
> packet.
> >>
> >>> And I also think that if we need to add new semantics even we can
> utilize IPv6 fragment, it would be better to define new protocol number for
> 4rd-U.
> >>
> >>> However, I don't think that we need to request to define it, because
> existing encapsulation and translation can be utilized for each appropriate
> situation.
> >>
> >>
> >>
> >> AFAIK, 4rd-U is better for this than double translation (say 4rd-T), and
> better than encapsulation (say 4rd-E), because it combines advantages of
> both (applicability of IPv6 O&M tools (a feature of 4rd-T), AND e2e
> transparency to IPv4 semantics (a feature of 4rd-E).

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Oct 2011 18:54:29 +0200

Remi,

> Technically, see for instance Figure 1 of the draft.

I thought the dIVI guys presented the DF bit transparency during the Beijing meeting?
I don't understand what the difference between "IP data" and Transport is in figure 1.
consider me slow, but don't you still either have to update the transport checksum, or adjust the checksum with other changes in the IPv6 header, e.g. flow.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 19:10:59 +0200

Hi Behcet,

4rd-U translates addresses, but:
- isn't concerned with anything above the IP layer;
- has a way to convey fields of IPv4 that would be lost in IPv6 (DF and, for "pipe and short pipe" as discussed by Satoru-san, the TOS). 
4rd-T translates addresses, AND:
- is concerned with the IPv4 payload (possible checksum adjustment)
- isn't fully transparent to DF, and to the TOS if a specific IPv6 Traffic class is needed for IPv6-domain traversal.

Hope it clarifies why, IMHO, calling 4rd-u a double-translation solution, like the RFC6145-based double translation, would create confusion.
If you look for a name, what about "header mapping" 

Regards,
RD

Le 17 oct. 2011 à 18:41, Behcet Sarikaya a écrit :

> On Mon, Oct 17, 2011 at 11:26 AM, Rémi Després <[email-masked]> wrote:
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Oct 2011 19:25:41 +0200

> I thought the dIVI guys presented the DF bit transparency during the Beijing meeting?

They did, but AFAIK not as completely as section 1 of my draft.

> I don't understand what the difference between "IP data" and Transport is in figure 1.

IP data is, as shown in my Figure 1, everything after the IPv4 header:
             +----------------+   
             |   IPv4 Header  |    
             +----------------+         
             |    IP Data     |         
             +----------------+          

Transport header is as in Figure 2 of RFC 6145:

              +-------------+                 +-------------+
              |    IPv4     |                 |    IPv6     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |  Transport- |                 |  Fragment   |
              |   Layer     |      ===>       |   Header    |
              |   Header    |                 | (if needed) |
              +-------------+                 +-------------+
              |             |                 |  Transport- |
              ~    Data     ~                 |   Layer     |
              |             |                 |   Header    |
              +-------------+                 +-------------+
                                              |             |
                                              ~    Data     ~
                                              |             |
                                              +-------------+                                            

May I suggest that you re-read RFC 6145, and thus understand all what becomes unnecessary with 4rd-U :-).

> consider me slow, but don't you still either have to update the transport checksum, or adjust the checksum with other changes in the IPv6 header, e.g. flow.

None of this is needed (this is where 4rd-U has in common with 4rd-Encap).

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Oct 2011 19:34:11 +0200

Remi,

> IP data is, as shown in my Figure 1, everything after the IPv4 header:

I thought we agreed that we didn't want to create packets with invalid checksums. this could trivially be made checksum neutral though.
in any case I thought this was exactly what dIVI did already...

cheers,
Ole

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Oct 2011 09:17:32 +1300

> Fortunately, this is easy to fix: in the Identification field of the IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.

Will this cause any difficulties for ECN, if ECN is supported on the IPv6
leg of the journey?

Apart from that, please remember that the DSCP part of the DS Field is not an
end-to-end field; it is mutable. I advise applying the relevant considerations
from Sections 4.1 and 5.1 of RFC 6145.

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 08:55:24 +0200

Le 17 oct. 2011 à 22:17, Brian E Carpenter a écrit :

>> Fortunately, this is easy to fix:

*
>> in the Identification field of the IPv6 Fragment header, copy not only the DF bits but also the IPv4 TOS.
*

> Will this cause any difficulties for ECN, if ECN is supported on the IPv6

Not in my understanding.
Since the IPv4 TOS is copied in the Identification field of the IPv6 Fragment header, it will be restored at exit of the IPv6 leg independently of any MPLS and ECN that may be used in that leg.
 
> end-to-end field; it is mutable.

> I advise applying the relevant considerations

This isn't necessary because RFC 6145 is about Translation, while 4rd-U, with the above between asterisks, precisely avoids translations between IPv4 TOS and IPv6 Traffic. 
In this respect, is more like 4rd Encapsulation than like 4rd Translation.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 09:15:38 +0200

Ole,

Le 17 oct. 2011 à 19:34, Ole Troan a écrit :

> I thought we agreed that we didn't want to create packets with invalid checksums.

Which agreement, reported where?
In any case, for traversing an IPv6-only ISP network, I can't see why it would be a useful constraint.

> this could trivially be made checksum neutral though.

If one more proposal would be documented, we would see what you mean but, IMHO, the three approaches on the table are sufficient.

> in any case I thought this was exactly what dIVI did already...

Reality is different from what you thought because dIVI-pd is based on RFC 6145 and RFC 6052, and:
- RFC 6052 address formats ar NOT checksum neutral (sec 4.1)
- Sec 4.5 of RFC 6145 says:
"If the address translation algorithm is not checksum neutral (see Section 4.1 of [RFC6052]), the recalculation and updating of the transport-layer headers that contain pseudo-headers need to be performed." 

Let me now ask whether you challenge any of the following:
a) One standard is better than two.
b) Maintaining network transparency to IPv4 packets is a useful feature
c) Being able to apply IPv6 O&M tools to IPv4 traffic, e.g. with ACLs, is a useful feature
d) Encapsulation has b) but not c)
e) Double translation has c) but not b)
f) 4rd-U has both b) and c)

- If you challenge one or several of these, our debate can continue on well identified subjects.
- If you don't challenge any of a) to f), we are IMHO on the right track to make progress.

Please do answer these questions so that questions you ask me can be answered in a clarified context.

Cheers,
RD

RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Oct 2011 09:42:40 +0200

Remi,

> c) Being able to apply IPv6 O&M tools to IPv4 traffic, e.g. with ACLs, is a useful feature

I think we need to detail this point more:

c1) apply IPv6 features on the traffic as if it is IPv6. use of 5 tuple etc.
c2) apply IPv4 features on the traffic as if it is IPv4.
c3) be able to redirect traffic or communicate with native IPv6 only hosts. e.g. web cache, web authentication

if this is useful or not, depends on your world view...
traditionally the whole purpose of a tunnel was to bypass devices in the middle mingling with your packets.

_iff_ one wishes that a "legacy" router in the middle of the traffic path should be able to apply features and classifiers
based on 5 tuple, then translation supports c1 and c3.
encapsulation supports none.
what I hear on the list is that one don't want to treat this as IPv6 traffic, but want to be able to identify it as IPv4 traffic. and presumably apply IPv4 features and classifiers on that traffic. if that's the case, you need to modify the box in the middle anyway, and I would claim it is a lot easier to move a pointer 40 bytes, than to recreate the IPv4 header on the fly.

> f) 4rd-U has both b) and c)

I disagree. double translation has just as much of b) as 4rd-U has. but I will claim that double translation offers less
transparency than encapsulation.

> Please do answer these questions so that questions you ask me can be answered in a clarified context.

in my view this doesn't change the encapsulation versus translation debate.
would an option be to merge your ideas with the new dIVI-pd document that will reference the new mapping document?

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 18 Oct 2011 10:21:54 +0200

While it is interesting to explore the various design spaces, we do not need more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4 packet. Any alternative beyond the simple and obvious encap/decap that routers have used for decades is already too much IMHO, we certainly don't need a 3rd or 4th method. Let's please curtail new the inventions, and get back to the standardization.  

- Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 10:29:35 +0200

Olde,

Thanks for the quick answer.
More below.

> if this is useful or not, depends on your world view...

I see that, but aren't solutions that are compatible with both world views better than those that satisfy only one?

> what I hear on the list is that one don't want to treat this as IPv6 traffic, but want to be able to identify it as IPv4 traffic. and presumably apply IPv4 features and classifiers on that traffic.

> if that's the case, you need to modify the box in the middle anyway,

The point is that you only need to configure the box, without depending on a new product release that hasn't been announced yet.
I think promoters of double translation made clearly this point, and it is AFAIK a valid one.
  
> and I would claim it is a lot easier to move a pointer 40 bytes, than to recreate the IPv4 header on the fly.

Recreating an IPv4 header at domain exit isn't a big deal. IMHO, since it is the key to combine valuable features of both double translation and encapsulation, and to thus have a single standard, it is worth doing.

> I disagree. double translation has just as much of b) as 4rd-U has.

In clear, you claim that 4rd-U isn't more transparent to IPv4 than double translation! 
With its DF+TOS copied in the IPv6 fragment header, 4rd-U is fully transparent to the TOS and the DF bit of IPv4, which isn't always the case with double translation.
Could you explain your understanding?

> but I will claim that double translation offers less

Indeed (and less than 4rd-U by the same token, see above).

> would an option be to merge your ideas with the new dIVI-pd document that will reference the new mapping document?

It is up to you, as leader of the unified-format effort, to see how you would like documents to be merged and/or re-written.

My own understanding is that:
- a unified address mapping is possible, e.g. by modifying the 4rd-addmapping to incorporate the proposed format with the V octet.
- a unified header format is also possible, based on 4rd-U which has been designed for that. 

I hope others will express their view on this.

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 10:59:20 +0200

Le 18 oct. 2011 à 10:21, Mark Townsley a écrit :

> 
> While it is interesting to explore the various design spaces, we do not need more ways to munge an IPv4 packet into an IPv6 packet and back to an IPv4 packet. Any alternative beyond the simple and obvious encap/decap that routers have used for decades is already too much IMHO, we certainly don't need a 3rd or 4th method.

> Let's please curtail new the inventions, and get back to the standardization.

Sorry that you see it that way.

The interim meeting has been useful in that objectives of present parties were clarified better than ever before.
Standardization is, and has always been, a process in which understanding each other, and finding ways to accommodate all valid concerns, are been key to success.
That's what I have been working for: good standardization. 

Would you please indicate what you personally challenge in this:
  
Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 18 Oct 2011 11:11:43 +0200

(resending as this was bounced from softwires due to the message being too long - I removed the thread cc'd at the end)

Begin forwarded message:

> From: Mark Townsley <[email-masked]>
> Date: October 18, 2011 11:07:34 AM GMT+02:00
> To: Rémi Després <[email-masked]>
> Cc: [email-masked], Softwires WG <[email-masked]>
> Subject: Re: [Softwires] 4rd-U complement - e2e transparency to IPv4 TOS
> 
> 
> On Oct 18, 2011, at 10:38 AM, Rémi Després wrote:
> 
>> 
> Yes. 
> IPv6 packets with incorrect checksums may be incompatible with firewalls, website redirects (e.g. I don't see why the web server will not just drop the packet if the checksum fails), etc. 
> 
> The translation (or header mapping) cases all purport to be helpful to various processing or operations along the path between the router endpoints. By definition, it is more complicated to weigh relative value of the various options in this space as we have to start weaving our way through sometimes unknown and certainly non-standard DPI, ACL, redirection, O&M, etc. features at multiple places in the network. In some cases, I'm afraid that we are optimizing based on speculative properties of IPv6 networks that are still in their infancy in terms of mainstream deployment. Experience tells me convergence here will be difficult, and getting it right will be even more difficult. 
> 
> I think we need to get the base case of stateless encap/decap out the door so that it can be built into CPE alongside the stateful ds-lite encap/decap option that is being built already. Then we can continue in the search for the best translation method (which, if we are still coming up with new clever alternatives right now, we are not converging nearly as fast as we might think we are).
> 
> - Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 14:31:00 +0200

Thanks, Mark, for the quick and detailed response.
More below.

>> a) One standard is better than two.

Clearly an important point for this discussion.

> IPv6 packets with incorrect checksums may be incompatible with firewalls, website redirects (e.g. I don't see why the web server will not just drop the packet if the checksum fails), etc. 

Thanks for rising the website-redirect issue.
With 4rd-U, some functions that exploit IPv6 packets above the A+P layer are not readily possible, but:
- Some other important functions, like ACLs, are readily made possible with existing tools.
- Complementing web redirectors so that they recognize 4rd addresses and adapt their checksum processing isn't technically difficult. It can be done later on.
- With encapsulation, web redirectors need a CE-like decapsulation function before processing IPv4 packets. The same can be done with 4rd-U, with decapsulation replaced by the v6-to-v4 header mapping. 

> The translation (or header mapping) cases all purport to be helpful to various processing or operations along the path between the router endpoints. By definition, it is more complicated to weigh relative value of the various options in this space as we have to start weaving our way through sometimes unknown and certainly non-standard DPI, ACL, redirection, O&M, etc. features at multiple places in the network.

Each ISP will decide which functions it can use, depending on its deployed tools, as it does for encapsulation.

> In some cases, I'm afraid that we are optimizing based on speculative properties of IPv6 networks that are still in their infancy in terms of mainstream deployment.

> Experience tells me convergence here will be difficult, and getting it right will be even more difficult. 

In the particular instance of 4rd-U, I don't see that, because its consequences are easily understood.
If I may, it's somewhat like 6rd whose implications were quickly understood by Free, in less than one hour, because the specification is short and self contained.
(This is unlike double translation, which depends on the the sophisticated RFC 6145, and on its operational variants to configured.)

> I think we need to get the base case of stateless encap/decap out the door so that it can be built into CPE alongside the stateful ds-lite encap/decap option that is being built already.

That's a respectable view, but one that, IMHO, would lead to a missed opportunity to have a single standard.

I do understand the inconvenience of having to adapt running codes based on encapsulation to a header mapping such as that of 4rd-U. 
However, I have no doubt that this is technically easy.
That's AFAIK the price to be paid to get a unique standard, with the nice bonus that existing IPv6-ACL tools, which weren't usable with encapsulation, become usable. 

> Then we can continue in the search for the best translation method (which, if we are still coming up with new clever alternatives right now, we are not converging nearly as fast as we might think we are).

It is clear, I hope, that 4rd-U is NOT a double translation technique between IPv4 and IPv6 packets. 
It is a simple header mapping technique that, like encapsulation, preserves network transparency to IPv4 packets across IPv6 domains.

Regards,
RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 18 Oct 2011 15:35:57 +0200

> Each ISP will decide which functions it can use, depending on its deployed tools, as it does for encapsulation.

But collectively, the ISPs will ask for fewer alternatives, particularly when the CPE vendor is wrestling with all the variations, and the interop lab is multiplying the size of its test matrix. 

> It is a simple header mapping technique that, like encapsulation, preserves network transparency to IPv4 packets across IPv6 domains.

It's clear to me that 4rd-U is not 4rd-T and not 4rd-E. Bravo, your ingenuity has led you to something that lies perfectly in the middle of the two warring parties. The problem of course is that the solution has the full advantages of neither side, even if it clearly has some of both.

Sort of reminds me of a certain 53 byte cell.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 18 Oct 2011 16:31:36 +0200

...

...

> Bravo, your ingenuity has led you to something that lies perfectly in the middle of the two warring parties. The problem of course is that the solution has the full advantages of neither side,

It's not because a design has positive features of two other designs that it "lies in the middle".

Could you explain the important advantage of encapsulation that is missing in 4rd-U?

RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 18 Oct 2011 11:07:34 +0200

Yes. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 18 Oct 2011 19:44:14 +0200

> Could you explain the important advantage of encapsulation that is missing in 4rd-U?

It's been specified and implemented for years, it is part of other softwires specifications, it is being implemented in CPE equipment today as part of ds-lite, it doesn't put payloads on the wire with mis-matching checksums.... Sure, tunneling doesn't play nice with some ACLs that only look at native IPv6, but at least this is a very well-understood attribute of tunneling that operators expect and in many cases are able to design around. FWIW, my crystal ball says that these limitations will will become less and less relevant if and when 4-in-6 operation becomes more and more prevalent, but that's just me.

Translation based on what's already defined in the behave WG is less conservative than simple encapsulation, but at least it is building on something that already exists, is well-specified and deployed, etc. We can expect to see IPv4 payloads with IPv6 headers on the network because of translators, but at least the checksums will be correct and there is a decent chance that a host will be able to digest the packet and get it to a working application after passing through one level of translation (or being redirected, subjected to DPI, etc). 

Again, no offense at all to the ingenuity of -U, but I simply have a hard time justifying that we need to cast a balance between these relatively well-known, specified, and implemented building-blocks with something new. 

If I believed for a microsecond that -U would wipe both encapsulation and translation from the planet so that we would have only one mechanism here, I would be more supportive. The problem is that the other two already exist in other closely related contexts such that there is no way that this doesn't become a 3rd method in the network without turning back time itself.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Oct 2011 09:01:38 +1300

> Since the IPv4 TOS is copied in the Identification field of the IPv6 Fragment header, it will be restored at exit of the IPv6 leg independently of any MPLS and ECN that may be used in that leg.

That's my problem. If the IPv6 leg supports ECN, any change to the ECN bits
during the IPv6 journey will be lost, so the end systems will not be informed
about congestion. I think the ECN bits need to be copied to and from the IPv6
Traffic Class.

> In this respect, is more like 4rd Encapsulation than like 4rd Translation.

Firstly, that means that any diffserv treatment specified for the IPv4 packet is
missed during the IPv6 journey. So as for ECN, the IPv4 DSCP value should probably
be copied into the the IPv6 traffic class. Second, as discussed in RFC 6145 section 5.1,
the diffserv code point might be rewritten at the exit from IPv6.

Please also see the extensive discussion about diffserv and tunnels in RFC 2983.
Actually the treatment in RFC 6145 was supposed to be roughly equivalent to RFC 2983.

Regards
   Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Oct 2011 09:50:56 +0200

> about congestion. I think the ECN bits need to be copied to and from the IPv6

Thanks for the clarification.
Whether ECN is deployed or not is beyond my current knowledge, but I now understand that this issue exists, and is applicable to 4rd-U as it is to encapsulation. 

> be copied into the the IPv6 traffic class.

Using the same field for ECN and for QoS differentiation seems to me a source of difficulty.
A minimal approach seems to be treating IPv6-domain traversal as just one link traversal.   

> Second, as discussed in RFC 6145 section 5.1,

> Actually the treatment in RFC 6145 was supposed to be roughly equivalent to RFC 2983.

Thanks for the reference.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 19 Oct 2011 10:07:12 +0200

Mark,
More on this debate below.

...

> Translation based on what's already defined in the behave WG is less conservative than simple encapsulation, but at least it is building on something that already exists, is well-specified and deployed, etc.

Successfully deployed in production, not so sure. (Even IPv6 isn't that largely deployed today).
In any case, it has the side effect that it damages network transparency to IPv4 packets.

> We can expect to see IPv4 payloads with IPv6 headers on the network because of translators, but at least the checksums will be correct

For ISP networks where web redirection with existing IPv6 tools is needed, 4rd-U could be completed so that checksums are correct.
This can be done like in dIVI by checksum adjustments at IPv6-domain entrance and exit, or (better IMHO) by revising the unified address-mapping to make it checksum neutral (something Ole has in my understanding suggested). 

Thanks for pointing out that something was missing to get the best of both worlds.

> and there is a decent chance that a host will be able to digest the packet and get it to a working application after passing through one level of translation (or being redirected, subjected to DPI, etc). 
> 

New, yes, but quite simple, and with an immediate operational advantage.
 
> If I believed for a microsecond that -U would wipe both encapsulation and translation from the planet so that we would have only one mechanism here, I would be more supportive. The problem is that…

Assuming that the three solutions would be available in products, I don't see why an ISP would prefer to keep double translation or encapsulation:
- The fact that translations and encapsulations were first to exist IS NOT an operational advantage
- Having both of network transparency to IPv4 AND applicability of IPv6 O&M tools IS an operational advantage. 

I still hope that, with more thoughts on the subject, you can become more open.  

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Oct 2011 15:05:26 -0500

I would like to see more details on 4rd-u before. Why is it informational? A
-01 would help.

Regards,

Behcet

On Wed, Oct 19, 2011 at 3:07 AM, Rémi Després <[email-masked]>wrote:

> > It's been specified and implemented for years, it is part of other
> softwires specifications, it is being implemented in CPE equipment today as
> part of ds-lite, it doesn't put payloads on the wire with mis-matching
> checksums.... Sure, tunneling doesn't play nice with some ACLs that only
> look at native IPv6, but at least this is a very well-understood attribute
> of tunneling that operators expect and in many cases are able to design
> around. FWIW, my crystal ball says that these limitations will will become
> less and less relevant if and when 4-in-6 operation becomes more and more
> prevalent, but that's just me.
>
>
> > Translation based on what's already defined in the behave WG is less
> conservative than simple encapsulation, but at least it is building on
> something that already exists, is well-specified and deployed, etc.
>
> > We can expect to see IPv4 payloads with IPv6 headers on the network
> because of translators, but at least the checksums will be correct
>
> For ISP networks where web redirection with existing IPv6 tools is needed,
> 4rd-U could be completed so that checksums are correct.
> This can be done like in dIVI by checksum adjustments at IPv6-domain
> entrance and exit, or (better IMHO) by revising the unified address-mapping
> to make it checksum neutral (something Ole has in my understanding
> suggested).
>
> > and there is a decent chance that a host will be able to digest the
> packet and get it to a working application after passing through one level
> of translation (or being redirected, subjected to DPI, etc).
> >
> > Again, no offense at all to the ingenuity of -U, but I simply have a hard
> time justifying that we need to cast a balance between these relatively
> well-known, specified, and implemented building-blocks with something new.
>
> > If I believed for a microsecond that -U would wipe both encapsulation and
> translation from the planet so that we would have only one mechanism here, I
> would be more supportive. The problem is that the other two already exist in
> other closely related contexts such that there is no way that this doesn't
> become a 3rd method in the network without turning back time itself.
>
> Assuming that the three solutions would be available in products, I don't
> see why an ISP would prefer to keep double translation or encapsulation:

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Oct 2011 10:57:36 +0200

Hi Behcet,

Thank you for your interest in understanding 4rd-U.

- The draft is informational because it is, at this stage, just a design proposal. The expectation is that it will eventually be included in a standard-track document whose form has to be decided in the WG.

- Despite my current attempt to spend less time for IETF, I will try to have soon a -01.
It will incorporate what I see as significant improvements resulting from the WG debate:
  . TOS copied in the IPv6 fragment header (pipe & short-pipe compatibility) 
  . Use of a checksum-neutral IPv6 addresses (compatibility with web redirection in IPv6 domains)  

Regards,
RD

Le 19 oct. 2011 à 22:05, Behcet Sarikaya a écrit :

> I would like to see more details on 4rd-u before. Why is it informational? A -01 would help.
> 
> Regards,
> 
> Behcet
> 
> On Wed, Oct 19, 2011 at 3:07 AM, Rémi Després <[email-masked]> wrote:
> Mark,

---

From: Rémi Després <[email-masked]>
Date: Thu, 20 Oct 2011 11:32:54 +0200

Satoru-san,
Sorry for the late answer.

> Not enough. The original TTL value in IPv4 header must be carried.

It isn't clear to me that mapping the IPv4 TTL into the IPv6 Hop limit isn't sufficient.
Have you a reference to suggest about this requirement?

Thanks,
RD

---

From: Tetsuya Murakami <[email-masked]>
Date: Thu, 20 Oct 2011 16:26:48 -0700

Hi Remi,

I am not sure if this proposal is good or not... But I think you are trying to introduce a new semantics for IPv6 fragmentation header. For this, I think the implementation of IPv6 stack must be changed to process your new fragmentation header. But I am not sure how to decide if the fragmentation header in the packet should be processed as either the normal fragmentation header or your new fragmentation header. Usually, IPv6 stack decides the processing for the following extension header based on the next header type. But you are using the same number of the existing fragmentation header for your new fragmentation header. If requiring any other information in the packet except the next header type, it might be a little bit painful from the implementation point of view.

Thanks,
Tetsuya Murakami

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Oct 2011 12:11:43 +0200

Hi Tetsuya-san,
Please see below.

Le 21 oct. 2011 à 01:26, Tetsuya Murakami a écrit :

> Hi Remi,
> 
> I am not sure if this proposal is good or not... But I think you are trying to introduce a new semantics for IPv6 fragmentation header. For this, I think the implementation of IPv6 stack must be changed to process your new fragmentation header. But I am not sure how to decide if the fragmentation header in the packet should be processed as either the normal fragmentation header or your new fragmentation header.

AFAIK, the proposal is a new use of the IPv6 fragmentation function which remains compatible with its current specification:
- 4rd sources select Identification-field values in a 4rd-specific way which does comply with existing constraints on these values. 
- 4rd-capable destinations do IPv6 reassembly as usual, with only the additional feature that, when addresses are recognized as being 4rd, IPv4 specific information is extracted and  passed to the 4rd function.  
- 4rd-unable destinations won't receive any 4rd packets because 4rd destination addresses are different from others, e.g. with the recently proposed 4rd-specific V octet in address bit 64-71. (And even if they would receive 4rd packets, their reassembly function could work as usual.)

> Usually, IPv6 stack decides the processing for the following extension header based on the next header type. But you are using the same number of the existing fragmentation header for your new fragmentation header. If requiring any other information in the packet except the next header type, it might be a little bit painful from the implementation point of view.

Having a new header type would defeat the ability to use existing IPv6 O&M tools, a key objective of the proposal.
Fortunately, and as explained above, we have here a _new use_ of the existing fragmentation header, not a "new fragmentation header".

Regards,
RD