2012/1/30 Rémi Després <[email protected]> > Hi Maoke, > > Good to see you back in technical discussions, of which we had so many > useful ones. > More in line. > > > Le 2012-01-29 à 05:38, Maoke a écrit : > > hi Remi, > > it a little confuses me that the new version introduces 2 variants > > > - what is the technical difference of 4rd-U encapsulation variant vs. > MAP-E? (except written in a single or some separated documents) > > > No difference (as said). > > > on the other hand, it is unfair to state the benefit "Header-mapping > provides more complete transparency to IPv4 packets than solutions using > twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at > least the following two pieces of) > > > cost: 1. > > > Not clear AFAIK. > It can be discussed if you expand, but less subjective issues like those > below are IMHO more important. > > losing the compatibility with single translation; 2. > > > I don't see this because, in my understanding: > - IPv6-only CPEs, in order to work with IPv4 shared addresses processed by > BRs are stateless, MUST be modified anyway. > - Unmodified IPv6-only CPEs don't need to be modified to work with shared > addresses processed by stateful NAT64/DNS64 (with known limitations > NAT-related limitations, but this is understood). > - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 > address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no > operational issue. > >
well, if address spaces (as well as routings) are totally disjoint, it is hard to call it as "coexist", ;-) and definitely there is no compatibility to single translation in RFC6145 at all. as the result, RFC6145 provides a unified solution, while 4rd-U requires ISP (who prefer to use translation) disjointly deploy their networks for single and double translations. > > > If you have a specific configuration that illustrates your concern, it > could be discussed with more details. > > putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP > header nor ICMP header has the address checksum information - this will > disable firewall preventing attacks. > > > > For a site having a customer-provided CPE that integrates a firewall to > take advantage of stateless IPv4-address sharing, its FW MUST be upgraded > anyway. Adding to it 4rd-U support is for this a logical solution. > > the attack preventing should be done everywhere, including in the middle of the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum regarding the original IPv4 addresses and therefore (no matter how the firewall is upgraded) the consistency check is not possible. it should be a big security concern. this is one of the major reasons that i don't think putting ICMPv4 into IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP translation is far better. best, maoke > > If the FW-CPE is not modified, its operation across IPv6-only networks > remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP). > Adding a note on this in the document would be possible, if found useful. > > Cheers, > RD > > > > best regards, > maoke > 2012/1/29 Rémi Després <[email protected]> > >> Hello all, >> >> The new version of the proposed unified 4rd has just ben posted. >> It is available at: >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 >> >> A major evolution since the previous version has been to have in it two >> variants. >> - The Header-mapping variant is as in the previous version >> - The Encapsulation variant is added after comments received, and >> accepted, that some use cases cannot be satisfied if the Header-mapping >> variant is the only one. >> >> Compared to the alternative approach of several MAP documents, the >> single-document approach is expected to avoid duplicate specifications, and >> to facilitate consistency checks of the design. >> Besides: >> - Header-mapping provides more complete transparency to IPv4 packets than >> solutions using twice the IPv6/IPv4 translation of RFC6145. >> - It has also the advantage of a simpler and self-sufficient >> specification. >> - The algorithm which permits BRs to forward datagram fragments without >> datagram reassembly is included. >> - The problem of fragmented datagrams from shared address CEs that must >> have different Identification if they go to common destinations is covered. >> - The design re-introduces the Domain IPv6 suffix which in some earlier >> 4rd designs, and somehow has been lost. >> - The port-set algorithm is without parameter. >> >> All questions and comments will be most welcome. >> >> 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
