Re: [Softwires] IPv4 Residual Deployment - Unified-standard proposal 4rd

[Maoke <[e-mail]>]

2012/3/13 Rémi Després <[e-mail]>

>
> Le 2012-03-13 à 03:18, Maoke a écrit :
>
> 2012/3/12 Rémi Després <[e-mail]>
>
>> Le 2012-03-12 à 10:21, Maoke a écrit :
>>
>> hi Remi,
>>
>> 2012/3/12 Rémi Després <[e-mail]>
>>
>>>
>>> 2012-03-12 04:09, Maoke:
>>> ...
>>> > btw, BR also depends upon NAT44 to deal with the unknown protocol,
>>> right? if so, may i say your statement "BR will support them without
>>> needing an update" is a proposition actually not existing? because NAT44
>>> won't support them without any update. right?
>>>
>>> Not right. Only CEs that need to support a new protocol are concerned:
>>> - If a shared address server supports a new protocol, it can be reached
>>> via an unchanged BR.
>>> - If a client using a new protocol tries to reach a shared-address CE
>>> that doesn't support this protocol, the client will be returned an error
>>> message by the destination NAT44.
>>>
>>
>> thanks a lot for the clarification! take an example:
>>
>>  A --- NAT44/CE ---(IPv6 backbone of 4rd domain)--- BR ---(IPv4
>> Internet)--- B
>>
>> now A and B are supposed to use a new protocol other than known
>> TCP/UDP/etc. my understanding:
>> B --> A
>> 1. BR just passes the new protocol without any concern.
>> 2. CE's NAT44 module would say "this is not supported and a 'destination
>> unreachable with port unknown' ICMP message is returned to B.
>>
>>
>> As now documented in 4rd-u-05 in the NOTE of 4.4 (3), the error message
>> should be, more precisely, "protocol unreachable".
>>
>
> thanks for the precise description.
>
>
>> Everything OK.
>>
>>
>>
>>  A --> B
>> 1. CE's NAT44 module directly say "destination unreachable with port
>> unknown" ICMP message to A.
>>
>>
>> Presumably also "protocol unreachable", but this remains a NAT44 matter.
>> 4rd isn't involved.
>>
>> is the above what you mean? when NAT44 module DOESN'T support the new
>> protocol, things are working while we have no the problem about the
>> "change" at all for the time being.
>>
>> then let's consider the case where the NAT44 module has been updated to
>> support the new protocol. i understand BR passing all protocols can be
>> survived if and only if the new protocol follows the TCP-layout for the
>> destination port and the TCP-checksum, right?
>>
>>
>> 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.

- maoke

>
>>
>> then you made a limitation (#1) to the NAT44 module of the CE: even if
>> the NAT44 has supported a new protocol not following TCP layout/checksum,
>> this support MUST be disabled in the 4rd-U environment; otherwise, BR may
>> behave wrong when making the mapped IPv6 addresses while the NAT44 would
>> still try to translate with the new protocol rather than dropping an error
>> message because it has known it. right?
>>
>>
>> To me this looks like a far fetched theoretical problem, with no
>> consequence in practice.
>>
>
> I said far fetched because:
> - For shared-address CEs, only protocols that use ports at their usual
> place and the TCP checksum algorithm are in scope (H6 of comparison
> tables). With them, there is never anything to "disable".
> - For non-shared address CEs, MAP-T needs updates for all newly supported
> protocols (including an existing one such as UDP Lite). Like MAP-E, 4rd
> works for all layer-4 protocols, never needing any update.
>
> to me, new protocols following TCP-layout and checksum are a far fetched
> theoretical problem too, with no consequen in today's practice. i mean, it
> is unfair when you state the 4rd-U pros you emphasize that BR needs no
> change with some new protocols, but when we say some other new protocols
> you say that's far fetched theoretical problem!
>
>
>> OTOH, the fact that RFC6145 doesn't tell you whether you MUST translate
>> DCCP or not is a real problem, and so is the fact that it doesn't support
>> UDP Lite, another already existing protocol.
>>
>
> i understand RFC6145 said OPTIONAL supporting DCCP just because it was
> considered less critical at that point of writing (may the authors give an
> explanation?). UDP-Lite was not mentioned in RFC6145 then, i think, with
> the same reason. implementation and operation can follow the RFC6145 logic
> to deal with any L4 protocols.
>
>
> Non-documented reasons were what they were, but consequences should not
> depend on them.
>
>
> on the other hand, it is easy to update RFC6145 or just making a
> suggestion anywhere, like a FYI on double-translation behavior of RFC6145,
> with clarifying DCCP *optional* support should be consistent throughout the
> domain and clarifying other unmentioned L4 protocol processing should
> follow the protocol's checksum logic that is specified.
>
> i don't see it is necessary to enforcing the address-level checksum
> neutrality rather than such a simple update or implementation/deployment
> guidance.
>
>
> Different view on practical consequences of the TBD "update
> or implementation/deployment guidance" you propose.
> Accepting an NIH feature that solves the problem without this TBD would
> IMHO be a step forward.
>
>
> it is surely fine technically that we enforce that. no problem. but if it
> is so necessary? here i have a point regarding the
> implementation/deployment: if the address mapping and header processing are
> decoupled, the things would be happier than a solution making them tightly
> coupled. MAP is made in such a fashion, where header processing could
> follow either encapsulation standard or translation standard. RFC6145 is
> made in such a way, where addresses could follow stateless mapping in
> RFC6052 or processed with state as in RFC6146, and now it is also fine with
> MAP. such a decoupling property makes implementation modularized and the
> operators may have better flexibility of choice.
>
>
>
> in the term of decoupling, surely we have two choices:
> 1) making address format checksum-neutral, suitable for either with L4
> recalculation or without.
> 2) making L4 recalculation, suitable for either addresses are
> checksum-neutral or aren't.
>
> RFC6052 explains why the authors gave up the CNP in the address and choose
> 2). i also have an understanding that 2) is a solution in implementation,
> once distributed, not easy to modify; while 1) is a solution in deployment,
> easy to change at any time. for example, if our equipment is made with
> RFC6145, the same equipment can be used in either RFC6052, or MAP, or 4rd-U
> address-mapping environment, but if our equipment is made with 4rd-U, we
> must only use it in 4rd-U environment. once we find we need to try
> something others, we have to buy new equipment, which means cost.
>
>
> In RFC6052, checksum neutrality was abandoned "because it would not help with stateful translation and because checksum neutrality can also be achieved by an appropriate choice of the Network-Specific Prefix, i.e., selecting a prefix whose one's complement checksum equals either 0 or 0xffff."
> - Stateful translation is off scope
> - MAP-T cannot select for each CE "a prefix whose one's complement checksum equals either 0 or 0xffff".
>
>
> further (#2), what if the packets don't pass through the NAT44 module at
>> all (in the case of non-shared IPv4 addresses)?
>>
>>
>> In case of non shared addresses, neither BRs nor CEs look at any port
>> field (there in no PSID to be found).
>>
>
> thanks. then (#2) is not a limitation. my mis.
>
> then the behavior of a new protocol (of the far fetched theoretical case,
> where non-tcp-layout/checksum is applied) would be very tricky:
> #2.1 address shared while NAT doesn't support the new protocol => dropped
> at NAT44,
>
>
> possibly not the correct NAT44 though;
>
>
> ???
>
> #2.2 address shared while NAT does support the new protocol => not dropped
> but it is possible to be incorrectly delivered because BR may take wrong
> value for the port;
>
>
> As stated many times, 4rd only deals, for shared-address CEs, with
> protocols, existing or future, that have ports their usual place and the
> TCP checksum algorithm.
> With these, no problem.
>
> Since this seems to be misunderstood, H6 of the comparison tables ca
> clarify, in a next version, that future protocols that are considered are
> supposed to have ports at their usual place (that of all existing
> port-based protocols, be they or not with the TCP checksum algorithm).
>
> #2.3 address not shared => passes to the end systems.
>
> correct understanding?
>
>
> See just above.
>
> Cheers,
> RD
>
>
>
>
>
>
>>
>> please clarify if the limitation of (#1) and (#2) are true or false.
>>
>>
>> Answered above.
>>
>>
>> i believe with requiring L4 modification, either MAP or RFC6145 has no
>> such two limitations: enforcing the checksum update at L4, their framework
>> is safe for either TCP-layout/checksum or alien-layout/checksum, either
>> shared or exclusive IPv4 addresses.
>>
>>
>> This remains AFAIK a belief that ignores DCCP and UDP Lite limitations of
>> RFC6145.
>>
>>
> see above.
>
> cheers,
> maoke
>
>
>>
>> i worry the CNP is making a situation of "cutting feet to fit the shoes".
>>
>>
>> Hopefully, you will see that no such worry is justified.
>>
>>
>> Cheers,
>> RD
>>
>>
>>
>>
>>
>> - maoke
>>
>>
>>>
>>> RD
>>>
>>>
>>>
>>
>>
>
>