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. 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.
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".
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.
maoke
> Thanks for this info.
>
> RD
>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
