Le 2012-04-03 à 15:41, Guoliang a écrit : > Hi, Remi: > > Pls read my comments below. > > 2012/4/3 Rémi Després <[email protected]> > > Le 2012-04-03 à 14:43, guoliang han a écrit : > >> Hi, Remi: >> >> I don't think my case illustrates MAP-T needs to remain experimental, my >> comments are below: >> >> >> 2012/4/3 Rémi Després <[email protected]> >> Hi, Guoliang, >> >> Interesting enough, the example you give illustrates that MAP-T needs to >> remain experimental, more than any other solution. >> >> 1. >> RFC6145 doesn't say that a PTB<1280 WILL BE changed to PTB=1280. It >> specifies two behaviors, one that does this, and one that doesn't. Which one >> to choose isn't AFAIK specified in the MAP-T draft. >> >> >> RFC6145 says in Section 6: "It SHOULD be possible to configure a translator >> for either of the two approaches", the first approach is that "IPv6 hosts, >> IPv6-host-based firewalls, and IPv6 network firewalls can be administered in >> compliance with Section 4.3.1 of [RFC4890]", the second approach is to >> change PTB MTU value to 1280 in case PTB<1280 and set DF bit to 0 in case >> the packet is less than or equal to 1280 bytes, if the requirements of the >> first approach can't be met. It doesn't mean the administrator can refuse to >> take the second approach according to his will. >> >> >> 2. >> With 4rd-U, an ICMPv4 PTB<1280 always goes to its destination unchanged. >> This is exactly what is necessary for PMTU discovery to work. >> >> Actually, what I worry about is whether IPv6 packets of 4rd-U embedding >> ICMPv4 packets could traverse current IPv6 firewalls successfully. > > Typical use cases of 4rd-U have no firewall between BRs and CEs. > If some would exist, they should be configured to let ICMPv4 payloads go > through (Protocol = 1) > This is like configuring them to accept IPv4 headers in IPv6 payloads > (Protocol = 4) > > Hope so. Still anticipating experimental results proving that yet. > > > >> 3. >> Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from >> RFC6145, and therefore from MAP-T. >> >> See Section 6 of RFC6145. > > This isn't in RFC6145, simply a reference to (*) below. > If I misunderstood, please explain what. > > You surely misunderstood that. I mentioned "in that case", instead of > replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the case > that incoming packet size is less that 1280 bytes, which is exactly the > requirement of RFC6145.
The so called "corner case" where RFC6145 looses the DF=1 is when a packet with DF=1 is already fragmented by its source. In this case, because there are several fragments, translates back to IPv4 with DF=0. In the example you give, RFC6145 doesn't add a fragment header, in the IPv4 to IPv6 translation because the packet has DF=1 and isn't fragmented (sec 4). The inverse translation, seeing no fragment header, the DF bit is normally set to 1 (sec 5.1). (A configuration option is mentioned so that the node MAY set it to 0 in some conditions, but MAP-T makes clear this must not be the case: "the IPv4 packets with DF=1 will be translated to IPv6 packets without fragmentation header and will be translated back to IPv4 packets with DF=1".) >> When we have a detailed report on which parts of MAP-T have been validated, >> with which options of RFC6145, it will be easier to analyze scenarios like >> the one you propose. >> >> >> In any case, thanks for providing one more evidence that the MAP-T >> specification isn't as clear as claimed to all those who support it, and in >> particular to some also criticize 4rd-U with invalid arguments. >> >> Regards, >> RD >> >> In fact, MAP-T is clear enough to be deployed without any problems, if you >> read RFC6145 carefully. > > Replacing IPv4 PTB<1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 > PMTU discovery to work. > Still waiting for a clarification on this issue. > > If the translator set DF bit to 0 in case the packet is less than or equal to > 1280 bytes, and replace PTB<1280 by PTB=1280, there are no problems on the > data path, whether in single/double translation. In any case, not a MAP-T feature. RD > > Regards, > Guoliang > > > Regards, > RD > > > > >> >> regards, >> Guoliang >> >> >> >> >> Le 2012-04-03 à 05:26, 韩国梁 a écrit : >> >>> +1. >>> >>> As a follower of MAP team, I participated much in developing and deploying >>> double-translation in CERNET. As far as I am concerned, in the translation >>> scenario, >>> 4rd-U only solved some corner cases but missed some other cases >>> simultaneously. >>> >>> As an example, I suppose one fragmentation case as following: >>> >>> (IPv4 customer network)--CE---(IPv6 access network)--BR(Core >>> Translator)--(IPv4 network)---IPv4 host >>> >>> The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 >>> network on the right side is 800. Now an IPv4 host on the left side sends a >>> packet >>> with length set to 1200 and MTU set to 1, to the IPv4 host in the right >>> side. The packet >>> could traverse the IPv6 access network, but will be blocked in the IPv4 >>> network. > > (*) > >>> In this case, BR(Core Translator) must set DF to 0 when translating from >>> IPv6 back to IPv4, >>> instead of preserving the original IPv4 DF bit. > > >>> >>> In fact, according to RFC6145, if BR(Core Translator) receives an ICMP >>> Packet Too Big packet >>> whose indicating MTU is less than 1280 bytes, it will change it to 1280. So >>> if the BR preserve >>> the DF bit, the sender will always believe the path MTU is 1280, which will >>> certainly lead to >>> a black hole. >>> >>> This is only one deployment problem, and we don't know how many issues will >>> be encountered >>> in the future. So my point is that 4rd-U still needs examination in the >>> actual deployment, and >>> it's a bit early to propose it as an Informational/Standards Track Document. >>> >>> The mail sent yesterday seemed to encounter some problems. So if you see >>> this mail twice, sorry for that. >>> >>> regards, >>> Guoliang >>> >>> >>> 2012/3/26 Maoke <[email protected]> >>> hi Remi, >>> >>> let me remove those you have marked as "end". they are fine to me too. only >>> one point: no implementation nor operation trouble != it is safe to say it >>> an architectural building block of tunnel. if we both say 4rd-u is an >>> alternative for translation, it would be much clear. (i don't think it is a >>> tunnel variant at all, due to not providing virtual links; while you insist >>> it not a translation at all). >>> >>> 2012/3/25 Rémi Després <[email protected]> >>> >>> >>>>> c) MAP-A+P says "Each MAP node in the domain has the same set of rules" >>>>> while MAP-T says "if a CE knows only a subset of the mapping rules ..." >>>>> >>>>> >>>>> first of all, they are not conflicting logically. >>>> >>>> ??? >>>> >>>>> second, if you mean one doc is superior than multiple with better >>>>> consistency in writing, i could agree. >>>> >>>> This is not the point. >>>> Separate documents can be consistent, but they aren't on this point. >>>> >>>> One of the two assertions must be changed. >>>> Remaining question: which one? >>>> >>>> >>>> well. this is why i said they are not conflict in logic. as a definition >>>> of the MAP rule, right, each MAP node in the domain SHOULD have the same >>>> set of rules. however, in practice of operation, it is possible that this >>>> MAY not strictly achieved due to some information losses (which is often >>>> happens in the Internet environment), MAP-T defines the CE working as it >>>> were in hub&spokes mode for an unknown destination CE. >>> >>> I am not aware that a CE might receive some of the MAP DHCPv6 parameters >>> but not all due to lost packets. >>> Clarification on this will be welcome. >>> >>> my understanding is: DHCPv6 is not running on a reliable protocol, while >>> MAP DHCPv6 does not yet determine if all FMR would be carried in a single >>> or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has >>> done with this, please teach me, thanks!) >>> >>> if you assume Internet is always reliable for everything, we must change >>> our discussion on a lot of issues. >>> >>> >>>> if you mean the single mapping rule in IVI case, the answer is NONE, >>>> surely. IVI uses RFC6052 address format rather than the MAP, without the >>>> business of MAP. >>> >>> OK >>> (In this respect at least, IVI significantly differs from a running version >>> of MAP-T). >>> >>> well, here i don't know how "significantly" you mean. IVI/dIVI/MAP-T(or >>> dIVI-pd) are same in header processing but different in address mapping and >>> operation. the context of "IVI" above mentioned the original IVI/dIVI that >>> applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules. >>> >>> >>>> >>>> if you mean using the MAP for the single translation as we did in IVI >>>> (though actually we have IVI working for both single and double >>>> translations simultaneously), MAP-T Sec 8.3 has answered your question. >>> >>> Saying that there is no mapping rule in IVI is sufficient an answer. >>> >>> then there is no more "not reaching collective understanding" for this >>> point. End of this topic for me. >>> >>> >>>> None? >>>> If one, is it a DMR or a BMR? >>>> If two, what are they? >>>> ... >>>> OK, could have been clearer. >>>> Yet, I think you understand that with U, one has SIMULTANEOUSLY, >>>> transparency to DF=MF=1 and applicability of IPv6-only middle boxes that >>>> look at TCP ports. >>>> >>>> >>>> ok. then may i conclude, for the major part of U, that 1) U, as a stated >>>> enhancement for double translation, gain the transparency for DF=MF=1 (the >>>> 10^-6 minor cases, commonly thought abnormal); >>> >>> 1) A statistic at a given time, and in a given place, isn't a proof that >>> the same ratio will be found later and somewhere else. >>> 2) Those that happen to be in the sacrificed minority, be it small, may not >>> like their situation. Solving the problem, be it only for them, is progress. >>> >>> 1) not only one statistics. i did it at Tsinghua University. prof. Bao and >>> others did it at CERNET. other guys did it in Europe and published in >>> IMC'07. and if you carefully read that paper, you may found that case was >>> very abnormal. >>> 2) well, it is good if we can take care of the minority without putting the >>> majority into potential trouble and uncertainty. >>> >>> >>>> 2) with introducing #1. weird definition of the fragment header of IPv6; >>>> #2 weird packet of IPv6 carrying ICMPv4 messages? >>> >>> AFAIK, not weird to those who are open to accept that it is very simple. >>> >>> AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2 >>> well discussed with the ICMP designers before concluding they are "not >>> weird"! i am not so open. to those who are open to accept this, i think >>> they should be also open to the following propositions (that are wrong to >>> me): >>> >>> *1. IPv6 option header, as long as there are reverved or not-yet-used or >>> padding bits, could be redefined as we like. >>> *2. it is a useless design that ICMP(v4 or v6) error message body contains >>> part of the original IP(v4 or v6) packet, where the source address is >>> identical to the destination of the IP(v4 or v6) header carrying the >>> ICMP(v4 or v6) message. >>> *3. it is a useless design that ICMPv6 header checksum contains >>> pseudo-header of the IPv6 header carrying it. >>> *4. IPv4 header checksum is actually useless. >>> >>> if the community would accept these *1 ~ *4 as true statements, i would be >>> also open to accept the above 2). but don't conclude before we get the >>> feedback from the community! >>> >>>> ... >>>> well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are >>>> major flaws (as we discussed so much, i was not convinced at all). i don't >>>> think others who read the specification don't see them and other issues. >>> >>> ICMPv4 payloads in IPv6 packets appear only during domain traversal, where >>> they don't hurt anyone. >>> >>> see above. >>> >>> >>> If a host is IPv6 only, it isn't a 4rd-U host. >>> For communication between IPv4-only applications of DS hosts and IPv6-only >>> hosts, there are already workable RFCs. >>> >>> common understanding, including RFC6052/RFC6145/RFC6146 but surely not >>> limited to these. >>> >>> BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. >>> A new solution for this isn't needed. >>> >>> BIH serves DS hosts connected to DS networks. the use case does not cover >>> the all cases of IPv4-IPv6 mutual communciations. >>> >>> >>>> an operator definitely needs the encapsulation as a fully featured virtual >>>> link (underlay infrastructure) in real O&A for IPv4 communications over >>>> IPv6 infrastructure. U cannot replace E at all. >>> >>> Different understanding. >>> An detailed E use case that cannot be supported by U (if it exists) would >>> give substance to this claim. >>> Open to look at it. >>> >>> in my personal experience i could give you at least three quick examples of >>> the use case for the building block of "virtual link": >>> >>> first example, if the IPv4 customer network plays BGP over IPv4 with the >>> provider, through the BGP session between CE and BR, a virtual link is >>> desired. >>> >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 >>> world) >>> >>> second example, there are dynamic routing protocols like RIP running in the >>> following (multihoming) topology for IPv4 routing. the operator may want to >>> treat the CE-BR as a single hop in order the virtual link is considered the >>> distance vector calculation. >>> >>> (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 >>> world) >>> \ / >>> \ / >>> +------------ CE ----(Another, IPv4 domain)----------+ >>> >>> third example, same topology as above but OSPF are applied, and OSPF >>> TTL-security check are enabled to ensure hop-passings less than a specified >>> threshold. if the operator would like to treat CE---(IPv6-only domain)---BR >>> as one hop because it is considered as virtual link, 4rd-u's rudiness in >>> decreasing TTL will hurt. >>> >>> MAP-E (and other E) surely has no limitation in supporting any features of >>> existing routing protocols. with at least the above three examples, i >>> conclude "U cannot replace E at all"! (btw, surely the translation has the >>> same limitation not to support the above features but, e.g., as you also >>> said, it opens transport-layer stuff to the middle boxes). therefore i said >>> operators may use either encapsulation or translation according to what >>> they attach importance to.) >>> >>> >>> >>>> but U needs still discussion >>> >>> T too. >>> See, for example, (*) above. >>> >>> you have ended that subject. fine to me. people have known the difference >>> between the "needs discussions" for the both. >>> >>> >>>> and running code approval. it cannot replace T at least this moment. >>> >>> Understanding how U's header mapping works doesn't need great expertise. >>> Co-autors readily understood it, with origins as varied as router-and-host >>> vendor, software vendor, broadband operator, mobile operator. >>> >>> well, it works just like another translator, surely it doesn't need great >>> expertise. >>> >>> >>> Running code as soon couldn't be done yet, but isn't a big deal at all (see >>> (**) below) >>> >>> ... >>> >>>> MAP can work even without the V-octet and CNP, at least in significant >>>> cases. >>> >>> Not a valid reason to stop progress, especially if easy to understand. >>> At least Med suggested to look at V octet even in the context of MAP (if >>> chosen for standard track). >>> >>> no problem if you keep debate in/with the MAP design team. just our current >>> understanding is: it is not necessary. >>> >>> >>>> if we have the standard of MAP, we can immediately deploy it into >>>> practice through applying MAP rules into the already well understood, well >>>> approved, well standardized encapsulation and translation modules, >>>> without waiting for the approval of the new features in the address >>>> format, and the approval of the reversible header mapping tightly coupled >>>> with the address format. >>> >>> (**) >>> When we discussed in Taipei, you first said you might code 4rd-U so that it >>> could be tested for real. You didn't do it for reasons that I perfectly >>> respect. >>> >>> yes but i also mentioned the prerequisite: "when i fully understand it and >>> see it qualified". i also talked with some others that i was interested in >>> that and, if possible and necessary, i would try to code it out and test >>> it, but again the prerequisite was attached. i have no reason to do a code >>> for a stuff even suspected by myself. you should remember that, after a >>> large amount of discussion, i told you i wouldn't code it when we reached >>> the problem of IPv6 carrying ICMPv4. this made me re-think the issue in the >>> aspect of architectural building block. sure the company's resource >>> allocation was a reason but this reason was tightly correlated to my own >>> academic judgement on the necessity. >>> >>> thanks, >>> - maoke >>> >>> Yet, modifying T code to support header mapping remains quite simple (you >>> even call it a translation variant). Starting from E code, it's simple too. >>> When this is done, all verifications can be easily done that what analysis >>> says is right is also right with running code. >>> >>> >>> Regards, >>> RD >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >> >> > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
