+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 <fib...@gmail.com> > 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 <despres.r...@laposte.net> > >> >> >> 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 > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
