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