2012-02-15 à 03:15, Maoke a écrit : > > > 2012/2/15 Rémi Després <[email protected]> > > Le 2012-02-14 à 16:21, Maoke a écrit : > >> >> >> 2012/2/14 Rémi Després [email protected] >> >>> 2) in the environment where single translation is also envolved (either >>> stateless or stateful), L4 checksum rewriting is a MUST because sometimes >>> there is only one address of the (src, dst)-pair following the >>> checksum-neutral address scheme. (this is mentioned in RFC6052, giving up >>> to enforce the checksum-neutrality in the address format, to my knowledge). >> >> I have aways acknowledged that L4 update is necessary for single >> translation, no disagreement. >> But here the problem is stateless IPv4 service across IPv6, a different >> problem where there is no such necessity. >> >> >> RFC6052 includes also the double-translation case. i guess operators >> wouldn't like to deploy different translators here for single translation >> while there for double. >> >> >> The point is that, where it can be used, checksum neutrality is MORE GENERAL >> than L4 update. >> >> >> how do you define the "generality"? doing L4 update is a safe choice no >> matter if the addresses are checksum-neutral or not. >> >> >> Besides, but less important, it is simpler as far as the number of >> specifications it depends on is concerned (no need to know where checksum >> fields are for different protocols). >> >> >>> i understand Ole has the same opinion: as we anyway have it, >> >> There can be implementations of BRs that are independent of single >> translation. >> They don't need to know where checksums are placed in various protocols. >> >> >>> we don't need it in the address scheme standard >> >> One can live with a standard less good than it could be but, since we are >> working for the future, let's make them as good as we can now. >> In any case, this is no excuse to claim that, with checksum neutrality the >> following is not correct "BRs need no change for any new protocol having >> ports at their usual place and TCP-like checksum" (DCCP, SCTP if it would >> acce^t TCP-like checksum, any other.) >> >> >> >> i think making L4 checksum update is a safe choice for standard. once we >> have a new L4 protocol, >> the BR surely need a change to check if this new protocol is a >> TCP-checksumed one. > > 1. A key, that probably hasn't been clarified enough so far (thanks for in > fact raising it), is the following: > - With checksum neutrality, the BR DOESN'T NEED to know about UDP, TCP etc. > (see R-22 (3) of the 4rd-U draft). > > If, by mistake a remote host sends to a shared IPv4 address a packet whose L4 > payload has no ports at their usual places, the packet, if it reaches a CE, > will ALWAYS be discarded there (protocol unknown by the NAT44) => no > operational problem. > > MAP should also works for the case where IPv4 addresses are not shared and > there is no NAT44.
Indeed, in particular for CEs that are assigned IPv4 prefixes. So does 4rd-H, without identified problem. > "protocol unknown" should be detected and discarded at both CE and BR in > their major module instead of the NAT44 part. I don't think so: - If a CE has a non-shared address, or an IPv4 prefix, BRs shouldn't exclude any protocol in packets sent to this CE. - If a CE has a shared address, it needs a NAT that the CE informs it the restricted port set. This NAT already has all what is needed to refuse protocols it doesn't understand. > This is one more instance where it isn't useful to try and guess what > mistakes people might make, and to add specific software for them while tools > already exist to detect and signal them. (Keep it simple) > > 1. as the above, MAP should not depend upon NAT44. > > 2. on the other hand, even the NAT44 works in front of CE, there is no NAT44 > works between BR and a remote host (not belonging to the MAP domain). the > assumption of "NAT44 discards unknown protocol" only available in the case > where communication is initialized by a client in the CE-delegated network. > be more clarified: > > host.A --- NAT44 --- CE ---- IPv6 domain ---- BR --- IPv4 Internet --- > host.B > > (a) A initiates connection to B => ok, that the NAT44 checks protocol > unknown. > (b) B initiates connection to A => BR has to check if L4 protocol is > supported or not. > (c) A initiates communication to B through a UDP or TCP signaling channel > while B reply a connection request on another channel over a new L4 protocol > => BR has to check if the new L4 protocol is supported or not. > > and in the case of (c), R-22 (3)'s processing looks dangerous -- blindly > deciding where the port is located without looking at the L4 protocol layout > narrows the applicability of the proposal. Which danger? On the contrary, avoiding that BRs depend on a list of L4 protocols enlarges their applicability. > however, surely it is not a problem if you state the scope of applicability > of 4rd-U is LIMITED to UDP, TCP and L4 protocols which HAS BEEN KNOWN (known > by the BR/CE rather than human) as having the same header layout as well as > the same checksum algorithm (without variation). I just say (and repeat) that, for shared-address CEs, 4rd-U BRs support WITHOUT MODIFICATION any L4 protocol that has ports at their usual place and a TCP-like checksum. > i don't think MAP standard have nor should have such a limitation. Which limitation? On the contrary, checksum neutrality eliminates the need for a BR upgrade if a new protocol using conventional ports and TCP-like checksum is introduced. > A MAP-compliant device supports UDP, TCP, DCCP, SCTP today, Not SCTP today, for sure. Also, as I think you know, there is uncertainty concerning DCCP because RFC6145 sec 4.5 says: "Other transport protocols (e.g., DCCP) are OPTIONAL to support". > with the same logic, and will support any emerging L4 protocol in the future, > again with the same logic. requiring L4 checksum update for any supported > protocol makes it a stable standard, and the checksum update logic is stable > for any protocol. in 4rd-U, however, with the R-22 (3), today it can support > UDP, TCP, DCCP and SCTP-variant(? not sure due to lack of personal > knowledge), while if tomorrow we have a new protocol XXXP: > a) XXXP has the same layout and same checksum logic, then the 4rd-U > compliant BR should be changed in order it knows that XXXP is also supported > and the logic R-22 (3) is still available; Not AFAIK. You can check that R-22 (3) does not depend on any L4 protocol (the only protocol that needs to be recognized is ICMP (a layer-3 protocol). > b) XXXP is different, then 4rd-U compliant BR should be changed in order > it knows that XXXP is now supported but different logic should be applied. > > in either a) and b), the BR should be changed otherwise the XXXP will be not > supported. therefore i still think Ole's argument is not unfair here. Let me repeat once more: If XXXP has (1) the same checksum algorithm, (2) the same port layout (like UDP, TCP, DCCP and SCTP do have), (3) a different layout for the checksum field (as is the case for UDP, TCP, DCCP, SCTP), THEN no new logic is needed in 4rd-H (because of its checksum neutrality). I do hope this point will eventually be understood in the WG, rather repeatedly negated. > btw, regarding the below "new standard for a new problem", i'd like to > emphasize it is not a new problem as RFC6052 has discussed it. it is an > incorrect understanding to think RFC6052/RFC6145 is designed only for single > translation. since the very beginning of the stateless address > mapping/translation design, the single and double translations have being > considered. I have no intention to negate anything about what designers of RFC6052/6145 considered (I wasn't there ;-)). The problem which IS NEW is how to design a stateless v4/v6 solution that: - is AS TRANSPARENT to IPv4 as encapsulation, without any restriction or doubt - yet works with IPv6-only port-based ACLs and IPv6 Web caches. In my understanding, 4rd-H is indeed such a solution (and is the only one on the table). Regards, RD PS: Relationship of 4rd-U with single translation XLATs of RFC6145 is a different subject which deserves a discussion thread with another title. > ...
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
