Subject: [Softwires] Unifying Double Translation and Encapsulation for 4rd (4rd-U)

From: Rémi Després <[email-masked]>
Date: Wed, 12 Oct 2011 11:56:57 +0200

Hello all,

The following draft has just been posted:
tools.ietf.org/html/draft-despres-softwire-4rd-u-00.

Hope it will be useful for your continuing work on stateless solutions in Softwire.

Clarification questions are most welcome.

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 12 Oct 2011 12:03:12 -0500

This is interesting proposal in favor of double translation.

Regards,

Behcet

On Wed, Oct 12, 2011 at 4:56 AM, Rémi Després <[email-masked]>wrote:

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

---

From: Jacni Qin <[email-masked]>
Date: Thu, 13 Oct 2011 10:09:39 +0800

Re-,

Yes maybe, to some extent. If accepted, the address format, even for 
CE-BR is unified as well.

Cheers,
Jacni

On 10/13/2011 1:03 AM, Behcet Sarikaya wrote:
> On Wed, Oct 12, 2011 at 4:56 AM, Rémi Després 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello all,
>
>     tools.ietf.org/html/draft-despres-softwire-4rd-u-00
>     <http://tools.ietf.org/html/draft-despres-softwire-4rd-u-00>.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 13 Oct 2011 14:43:00 +0900

Hi Remi,

It seems far from to be unified _packet_ format. it doesn't support diff-serv tunneling model, pipe and short-pipe.

cheers,
--satoru

---

From: Jacni Qin <[email-masked]>
Date: Thu, 13 Oct 2011 17:08:49 +0800

Hi,

> It seems far from to be unified _packet_ format. it doesn't support diff-serv tunneling model, pipe and short-pipe.
The type of service can be copied to the IPv6 header. Sorry, what are 
the pipe and short-pipe?

Cheers,
Jacni

---

From: Maoke <[email-masked]>
Date: Mon, 17 Oct 2011 14:27:10 +0900

hi Remi,

i would like to follow your idea of keeping end-to-end transparency of DF
bit in double translation.

1. keeping DF transparency might be really significant

we noticed that the fragment in IPv4 is rare but it doesn't mean the DF is
fairly useless. in contrast, today's IPv4 has very small percentage of
fragment just because we are favored by the DF bit and the path MTU
discovery functionality based on it. if we observe the percentage of DF=1
and DF=0 packets, we would see DF is not trivial. forcing DF = 0 at the
boundary from IPv6 to IPv4 may disable the PMTU discovery in the destination
IPv4 domain; forcing DF = 1, though, may bring worse performance for the
applications that do not care of being fragmented but wouldn't like to be
dropped due to packet-too-big.

2. define a reserved bit in IPv6 fragment header for the DF bit of the
IPv4-translated packets

putting is the DF and IPv4 identifier into the fragment header is a good
idea. however, considering the double translation is a case of translation.
it is possible that a src host with an IPv4-translatable IPv6 address
generates a fragment header with a 32-bit identifier happening to have the
first 16 bit as either 0x8000 or 0x0000, making a fake D bit in your current
proposal. i'd prefer to use one of the reserved bits in the fragment header
for the DF.

how do you and others think?

thanks,
maoke

2011/10/12 Rémi Després <[email-masked]>