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

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

Ole,

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

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

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


> 
> cheers,
> Ole
> 
> cheers,
> Ole