Thanks Maoke for the opportunity to clarify some of the points below.
2012-03-09 03:14, Maoke: > hi Remi, > > sorry but i follow this late. something not clear to me, according to our > earlier discussions. > > 2012/3/8 Rémi Després <[email protected]> > > Le 2012-03-08 à 03:47, Washam Fan a écrit : > > > Hi Remi, > > > >>>>> Secondly, -04 added NAT64+ parts. > >>>>> If I understood correctly, there are no additional requirements for > >>>>> NAT64 > >>>>> boxes. > >>>> > >>>> Well, NAT64 boxes remain what they are. > >>>> Any host can use BIH to look like an IPv6-only host in the NAT64 > >>>> although it > >>>> has a dual stack. > >>>> > >>>> But the advantage of 4rd tunneling over RFC6145 double translation is > >>>> better > >>>> IPv4 transparency (DF, ICMPv4, DCCP, UDP-Lite, and future protocols that > >>>> may > >>>> use the TCP checksum algorithms) > > to clarify my understanding: > 1. DF transparency is kept totally in 4rd-U but RFC6145 sacrificies the > DF=1/MF=1 cases > 2. ICMPv4 is somehow subtle. i still cannot agree taking ICMPv4 message > directly as IPv6 payload is a wise idea. lack of address consistency > ensurance mechanism (i.e. no header checksum in IPv6 header no pseudo-header > checksum in ICMPv4 message) The 4rd ICMPv4 error message has as only purpose to be delivered to a 4rd-aware node. There, it will be treated as an ICMPv4 error. It is assumed that no DPI in some middle box will need to interpret ICMPv4 error messages. > 3. for the "future protocols", i remember our earlier discussion concluded > that CNP can free the code change with ALREADY KNOWN tcp-checksumed > protocols. am i wrong here? I think you are. As the 4rd-u-04 says (sec 4.4): "NOTE: This guarantees that, for all protocols that use the same checksum algorithm as TCP, Tunnel packets are valid IPv6 packets, and this independently from where the checksum field is placed for each protocol. Today, such protocols are UDP [RFC0768], TCP [RFC0793], UDP-Lite [RFC3828], and DCCP [RFC5595]. Should new ones be specified, BRs will support them without needing an update." > >>>> For an ISP to extend this advantage to its stateful NAT64, it need to be > >>>> 4rd > >>>> aware (become a NAT64+). > >>>> NAT64+, when its sees that an IPv6 address is a 4rd IPv6 address (with a > >>>> V > >>>> octet instead of a "u" octet), use the 4rd header mapping instead of > >>>> RFC6145 > >>>> translation. > > questions: 1. NAT64+ here refers to stateful case only, right? > 2. for the IPv4-to-IPv6 directly, how does the 4rd-aware box make decision > between 4rd-U pseudo-encapsulation (let me use this term because i argue it > does not conform to the behavior of encapsulation) and NAT64 translation? (as > we have neither V nor U in the IPv4 addresses). a) Note that there is no claim that 4rd-u would be an encapsulation solution (it isn't!). What is claimed is that it is a transparent-tunnel solution (same IPv4 packet received by destinations as sent by sources, except for TTL which progress, and for ECNs that may be changed if congestion is met between source and destination). b) In draft -04, R-7 (8) says: "CEs that are assigned unspecified IPv4 addresses (Section 4.3), MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses as follows (Figure 6): take the Rule IPv6 prefix of the NAT64+ mapping rue; append the IPv4 address; append the CNP. <----------- Rule IPv6 prefix --------->: +-------------------------------+---+---+-------------+------+ | NAT64+ IPv6 prefix |"u"| 0 | IPv4 address| CNP | +-------------------------------+---+---+-------------+------+ : 64 : 8 : 8 : 32 : 16 : Figure 6 " > >>> > >>> I perfer to leave NAT64 out of scope. > >> > >> NAT64 as is remains out of scope. > >> What is in scope is only the possibility to improve IPv4 transparency of > >> NAT64 nodes by using transparent tunneling, instead of double translation, > >> when reached by 4rd CEs (making them NAT64+ nodes). > > > > Can I interpret NAT64+ as 4rd BR co-located with NAT64? What justify a > > new term NAT64+ invented? > > > NAT64+ is more than just coexistence of 4rd BR and NAT64: the NAT64 needs to > be upgraded to replace RFC5145 translation by header mapping when IPv6 > addresses it deals with are 4rd addresses (have the V octet). > > > > > >> This new capability, introduced in -04, is derived from the 464XLAT > >> proposal. > >> With 464XLAT, IPv4 applications in hosts attached to IPv6-only networks > >> can communicate via NAT64s, but IPv4 transparency has limitations which > >> can be eliminated by upgrading NAT64s to NAT64+ status (a backward > >> compatible evolution). > >> > > > > In 464XLAT, they keep NAT64 as it is. Does 4rd keep NAT64 as it is? > > To take advantage, for customers that are 4rd capable, of better IPv4 > transparency than with double translation, the NAT64 MUST be upgraded. > > may i add that it (4rd-U) provides better IPv4 transparency than double > translation but less simplicity in the term of layering architecture than > encapsulation? (here i avoid sticking things on my understanding to > "transparency"). personally i don't think transparency is the most important > reason that generally operators prefer encapsulation rather than translation. > simplicity and clear concept in architecture is the reason. no matter how > much we keep IPv4 information unchanged across the IPv6 domain, as long as > the IPv4 header is destroyed, it is a solution of "translation" rather than > of "encapsulation". Different view here. a) Ole had a nice slide in the interim meeting about how double translation tends to break transparency. I use "reversible header mapping" which I find intuitive, or just "header mapping", but "reversible header translation" could be OK. A key difference, is that payloads are transparently tunneled in 4rd while they are processed, with dependence of upper layer protocols in double translation. This is AFAIK an important difference. (To take an example, RFC6145 requires to discard UDP-lite packets (RFC3828) while they are tunneled with 4rd) b) As said in Sec 1 of draft -04: " While IPv6 headers are too long to be mapped into IPv4 headers, so that 6rd requires encapsulation of full IPv6 packets in IPv4 packets, IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd tunnel packets can be designed to be valid IPv6 packets, thus ensuring compatibility with IPv6-only middle boxes that perform deep-packet-inspection." I see no real complexity in noting that IPv4 headers are small enough to be reversibly mapped in IPv6 headers. Of course this still requires careful technical verification, but once done, it's done once and for all. > i don't incline to use the term "tunneling" since tunnel could have a variety > of forms, among which encapsulation is one but not the only one. Exactly: 4rd uses header-mapping tunnels, and MAP-E uses encapsulation tunnels. Cheers, RD > > cheers, > maoke > > Naturally, this has no impact on other NAT64 users (e.g. IPv6-only hosts, or > dual-stack hosts supporting BIH of RFC6535): they can continue to use the > NAT64+ as an ordinary NAT64. > > Regards, > RD > > > > > Thanks, > > washam > >>> Such transparency could be achieved by whther to add fragmentation header. > >>> Anyway, let's hear some comments from the group > >> > >> OK > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
