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) > 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. > 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. 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
