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

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

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

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


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