Le 2012-03-13 à 03:18, Maoke a écrit : > 2012/3/12 Rémi Després <[email protected]> > Le 2012-03-12 à 10:21, Maoke a écrit : > >> 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. > > 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.
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 >> >> >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
