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

[Ole Troan <[e-mail]>]

Remi,

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

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