hi Remi, 2012/3/12 Rémi Després <[email protected]>
> > 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. A --> B 1. CE's NAT44 module directly say "destination unreachable with port unknown" ICMP message to A. 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? 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? further (#2), what if the packets don't pass through the NAT44 module at all (in the case of non-shared IPv4 addresses)? please clarify if the limitation of (#1) and (#2) are true or false. 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. i worry the CNP is making a situation of "cutting feet to fit the shoes". - maoke > > RD > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
