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

[Maoke <[e-mail]>]

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

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

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.


>
> 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;
#2.3 address not shared => passes to the end systems.

correct understanding?


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