2012/3/14 Rémi Després <[email protected]>
>
> Le 2012-03-14 à 06:51, Maoke a écrit :
>
>
>
> 2012/3/13 Rémi Després <[email protected]>
>
>> 2012-03-13 12:02, Maoke :
>>
>> 2012/3/13 Rémi Després <[email protected]>
>>
>> ...
>>
>> The 4rd mechanism is for protocols that have ports at their usual place
>>>> (all existing protocols that have ports have them at the same place, even
>>>> if using another checksum algorithm like SCTP).
>>>>
>>>
>> may you have a check on the statement of "all existing protocols"
>> again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol
>> over IP.
>>
>>
>> I missed this one.
>> None of the proposed stateless solutions supports it, but it remains that
>> you are right: it has ports at a different place.
>>
>
> alright. so 4rd-U doesn't not support "all existing transport protocol"
> either.
>
>
> Never said that without qualifying which protocols.
>
> but i suppose you may make an update in the 4rd-u-06 so that a new
> "if...else..." is added the port pick-up logic, and surely the CNP is not a
> problem for RDP because the old version (RFC908) has 32bit checksum but not
> involving pseudo-header while the newer version (RFC1151) changed to use
> TCP-checksum. no big deal but only needs a new patch to the draft.
>
>
> In the Note in 4.4 (7), the first sentence is:
> "This guarantees that, for all protocols that use the same checksum
> algorithm as TCP, Tunnel packets are valid IPv6 packets, and this
> independently from where the checksum field is placed for each protocol."
> It can become:
> "This guarantees that, for all protocols that use the same checksum
> algorithm as TCP and have ports at the same place, Tunnel packets are
> valid IPv6 packets, and this independently from where the checksum field is
> placed for each protocol."
>
> Similarly, in the comparison table, H6 is:
> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well as
> future protocols using the TCP checksum algorithm"
> It can become:
> "For shared IPv4 addresses, DCCP and UDP-Lite supported, as well any
> future protocol that might use the TCP checksum algorithm and ports at the
> same place"
>
then it is fine. with these statement, 4rd-U can support
- TCP
- UDP
- DCCP
- any future or less well-known protocol as long as it uses TCP checksum
and port at the same place
as a counterpart, we may suggest MAP-T to state it supports
- TCP
- UDP
- DCCP (with enforcing it rather than RFC6145's "optional")
- any future or less well-known protocol, no matter what layout it is nor
how the checksum is defined, with the similar logic of L4 checksum
recalculation
;-)
maoke
>
> but this is not my point. my point is: there must be something we don't
> know ("non omnia possumus omnes"). even we have gone through the RFCs,
> there might be some other proprietary L4 protocols, or experimental
> protocols. even they are minority, i don't think ignoring their existance
> in our solution fits the spirit of the Internet. it might be argued that
> NAT44 doesn't support such L4 protocols now, but an L4 protocol owner may
> makes his own NAT44, either attached to the CE or separated. if 4rd-U
> respects such an effort, it should state "currently blahblabla L4 protocols
> are supported". the similar statement applies to the RFC6145 or MAP as well.
>
>
> i somehow am hard to accept words like "far fetched theoretical problem".
>
>
> If I had thought it might be so, I would have avoided the word.
>
>
> the L4-recalculate is a generic, architectural solution, surely needing
> codes for every L4 protocol. but this generality in architecture makes
> RFC6145 or MAP-T equipment be easily enhanced to support anything new with
> the same logic. but for the 4rd-U BR, it looks to me we cannot have the
> unified logic for all (even limited to existing and well-known) L4
> protocols.
>
> only my 2 cents.
>
>
> With amendments above, the point is AFAIK completely covered: everything
> is rigorously true, and worth noting.
> Thanks for the useful reference to the RDP of RFC1151.
>
> RD
>
>
>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
