2012/3/15 Rémi Després <[email protected]> > > Le 2012-03-15 à 14:47, Maoke a écrit : > > > > 2012/3/15 Rémi Després <[email protected]> > >> >> Le 2012-03-15 à 11:45, Maoke a écrit : >> >> i understand NAT64 makes translation between arbitrary IPv6 address to >> arbitrary IPv4 address. i don't understand how you make CNP in any IPv6 >> address. >> >> >> >> in other words, we cannot limit NAT64 stateful service only serve those >> IPv6 addresses with CNP. >> >> >> That's no the case at all(!). >> A NAT64+ is a *backward compatible* extension of NAT64 (everything that >> worked before still works completely unchanged). >> >> The draft says: >> "NAT64+: An ISP NAT64 of [RFC6146] that is upgraded to support >> 4rd tunneling when IPv6 addresses it deals with have the 4rd-IPv6-address >> format." >> >> > > this phrase is not understood yet. do you mean using 4rd-IPv6-address > format for stateful translation service? > > > Yes (but, &s said, only for CE nodes that are 4rd capable (with the > advantage of better IPv4 transparency between CEs and NAT64+ than between > RFC6145 and NAT64). > > please draw an example of A <---> B communication as i did for > clarification. > > > Here is an example scenario: > > v4appli-BIH ----. => A>B NOK (because, according to RFC6535, BIH uses > RFC6145) > A1 | > :----(v6net)----- NAT64+ ---(IPv4 Internet)--- Server > | UDP-lite UDP-lite > v4Appli-4rdCE --' capable B > A2 => A-B OK > > yes, BIH uses RFC6145 that doesn't claim supporting UDP-Lite. but exactly speaking, if the "not support" means passing-it-through without checksum adjustment, A --> B is fine because neither BIH nor NAT64+ does nothing with the L4, right? B --> A is a question mark, if we use the NAT64+ which does nothing with the L4 checksum, it is also not a problem. however, if we use, as you mentioned before, an UDP-Lite-aware update of RFC6146, that may updates the checksum while the BIH doesn't know that.
my point here is: what is the use case with the details of addressing? if and only if A1 or A2 is configured with an RFC6052 or a MAP or a 4rd-U address while NAT64+ has a pool of checksum-neutral IPv6 address to serve B for the communications, A1 BIH or A2 CE may do the stateless processing successfuly. if NAT64+ hasn't such a address pool for B, things will fail because only one among src and dst is checksum-neutral. > > > Because 4rd IPv6 addresses of CEs are distinguishable from all other IPv6 >> addresses (due to the V octet), NAT64s are concerned with CNPs ONLY for >> addresses that actually are 4rd CE addresses. >> >> > > we need to make sure if the NAT64s make both src and dst addresses > checksum-neutral. > > Correct, iff the host address has the V octet. > 1. without the V-octet, CE and NAT64 can also distinguish the 4rd-CE addresses from others. 2. even with the V-octet, do you mean B's IPv4 address also translated (by the NAT64+) to a CNP-and-V-containing IPv6 address? if 2 is true, why you use stateful NAT64+ here for B rather than a stateless one? if 2 is not true, then the NAT64 can use any arbitrary IPv6 address for B's communications, and such a case results only A's mapped address is checksum-neutral, and thus anyway L4 adjustment is needed. if 2 is true, i do suggest you naming NAT64+ as NAT64- instead, because NAT64 doesn't have the limitation on the IPv6 address pool in use. 3. RFC6535 states, explicitly, "Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]" (but the above technical discussion can omit this for the time being). - maoke > > i cannot imagine what the use case is. please specify! > > > Hope the picture above helps. > > RD > > > > > - maoke > > >> >> >> RD >> >> >> - maoke >> >> 2012/3/15 Rémi Després <[email protected]> >> >>> >>> Le 2012-03-15 à 10:59, Rémi Després a écrit : >>> >>> > Maoke, >>> > >>> > Thanks for this question. >>> > This subject being new, I take it on a new thread. >>> > >>> > 2012-03-15 10:38, Maoke: >>> > ... >>> >> i didn't understand the how the stateful NAT64 benefits from CNP. >>> > >>> > The point is that if a NAT64 is upgraded to support 4rd-u tunnels >>> (thus becoming a NAT64+) it can take IPv6 payloads as valid IPv4 payloads. >>> > Any protocol that this NAT64 supports is then supported e2e for 4rd-u >>> CEs >>> > These CEs need not being dependent on which NAT64 supports which >>> protocols. >>> > >>> > Note that the NAT64 doesn't need to have CNP code. It just happens >>> that host IPv6 addresses it sees are checksum neutral. (Thus, IPv6 and IPv4 >>> payloads are the same for all protocols that have ports at the same place >>> as TCP/UDP/..., and the same checksum algorithm) >>> >>> Oops. >>> This is only true for the IPv6 host address. To construct an IPv6 >>> address when transmitting to a 4rd-u CE, the NAT64 should compute a CNP. >>> (This is to maintain the property that that middleboxes can treat tunnel >>> packets as valid IPv6 packets. Not a big deal, but necessary). >>> Sorry for having hastily added this sentence. >>> >>> RD >>> >>> > >>> > 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
