2012/3/13 Rémi Després <[email protected]> > > 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). >> > may you have a check on the statement of "all existing protocols" again? i noticed RFC908/RFC1151. sorry if that are not a transport protocol over IP.
- maoke > >> >> 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
