Le 2012-03-19 à 11:44, Maoke a écrit : > > > 2012/3/19 Rémi Després <[email protected]> > > Le 2012-03-19 à 10:21, Maoke a écrit : > >> >> >> 2012/3/19 Rémi Després <[email protected]> >> >> Le 2012-03-19 à 09:16, Maoke a écrit : >> >>> >>> >>> 2012/3/16 Rémi Després <[email protected]> >>> Maoke, >>> >>> Let me try a more complete picture than before: >>> >>> >>> A1 -----. >>> RFC6145-host| .-- 4rd BR --. >>> | | | >>> A2 -----:--(v6net)--: :--(v4 Internet)--- B >>> 4rd-CE | | | UDP Lite appli >>> >>> (no IPv4 @) | '-- NAT64+ --' >>> | >>> A3 -----' >>> 4rd-CE >>> (IPv4 @, shared or not) >>> >>> >>> NAT64+ is supposed to have a bindings for UDP Lite, either only for 4rd >>> IPv6 addresses (the minimum), or also for native IPv6 addresses (the >>> complete upgrade, with UDP-Lite checksum adjustment for these addresses) >>> >>> Connectivities I get are: >>> A2 => B (via NAT64+) >>> A3 <=> B (via 4rd BR) >>> (There is no A1-B connectivity) >>> >>> A2 is IPv6-only, right? >> >> There seems to be a misunderstanding on what is IPv6-only. >> a) A2 is dual stack. Being a CE node, it supports IPv4 applications, and >> typically includes a NAT44. >> b) Its IPv6 prefix matches neither a CE nor the BR mapping rule, it has no >> assigned public IPv4 address (even shared). >> c) Because it has received a NAT64+ mapping rule, it knows it can tunnel >> IPv4 packets to the NAT64+. >> >> >>> if so, let me go down. >> >> Not so => doesn't apply. >> (Yet some further comments below) >> >> RD >> >> >>> >>> >>> Anything missed? >>> >>> >>> Other detailed comments follow. >>> >>> Le 2012-03-16 à 01:59, Maoke a écrit : >>> >>>> >>>> >>>> 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? >>> >>> A NAT64 that supports UDP Lite MUST update checksum for hosts that have >>> native IPv6 addresses. >>> That's why A1 => B doesn't work unless the NAT64 recognizes which packets >>> are those of IPv4 applications in DS hosts. >>> >>> A1 -> B doesn't need stateful NAT64 but stateless service is enough. well, >>> stateful is also ok. it is true NAT64 supporting UDP-Lite must update >>> checksum. >>> >>> >>>> 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. >>> >>> Note that an upgrade of RFC6146 isn't needed for A NAT64 (and NAT64+) to >>> support more protocols than the two required by the RFC. It is just an >>> extension which cannot break anything (backward compatible). >>> >>> confusing. upgrade vs. extension?? >>> >>> >>> >>>> >>>> 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. >>> >>> Sec 4.4 (8) says that a CE that targets an off-domain IPv4 address reaches >>> the NAT64+ at this IPv6 address: >>> >>> +-------------------------------+---+---+-------------+------+ >>> | NAT64+ IPv6 prefix |"u"| 0 |DST IPv4 add.| CNP | >>> +-------------------------------+---+---+-------------+------+ >>> : 64 : 8 : 8 : 32 : 16 : >>> >>> In the reverse direction, and for the same IPv4 address, it is the same >>> IPv6 address that must be synthesized by the NAT64+. >>> >>> this address is used for A2 or used for B? if you mean B, then may i >>> conclude that NAT64+ is serving between A2 (native IPv6 address with 4rd-U >>> CNP) and B (synthesized by NAT64+ into another IPv6-converted address >>> having CNP)? if i can, may i further conclude that NAT64+ serves only for >>> the case where A2 has the 4rd-U-style address? >> >> Let me repeat that: >> - NAT64+ works as a NAT64 for addresses that aren't 4rd-u style. >> - The only difference is that NAT64+ has a plus for addresses that are those >> of 4RD-u CEs (better IPv4 transparency). >> >> accepted. but i have pointed out the "better transparency" has some cost and >> uncertaity up to now (see another thread). >> >> >> >>> if the A2 is configured with any IPv6 address, for example, address with >>> the autoconfigured EUI64 IID, it is out of the scope of the NAT64+, right? >>> >>> if so, i do really suggest you call it NAT64- instead of NAT64+ because >>> NAT64 can also serve hosts with any native IPv6 address to connect with an >>> IPv4 peer. >>> >>> your answer below didn't respond my question, sorry. for example (in the >>> use case of NAT64 instead of NAT64-), A2 has native IPv6 address >>> 2001:db8:1234:5678:208:1fff:fe4d:606e while B is 192.32.77.50. the CE might >>> synthesize an IPv6 address for B, with the NAT64+ prefix and the 0xc0204d32 >>> and a CNP embedded, say B', and let A2 connect to B' through IPv6; however, >>> when this packet goes through the NAT64+, >> >>> because only B' is checksum-neutral while A2 is not, >> >> If the /64 of A2 is 2001:db8:1234:5678::/64, its 4rd IPv6 address is, per >> Fig 6, 2001:db8:1234:5678:3000::<CNP> >> It IS checksum neutral. >> >> well, it is saying A2 must have the 4rd address in order to get the benefit >> of NAT64-, right? > > (*) For native IPv6, it has whatever address applies (that of your example is > OK). > Its CE is reached with all destination addresses starting with the site /64 > followed by with the V octet. > > >> i have typed "for example (in the use case of NAT64 instead of NAT64-), ..." >> as the prerequisite of the above discussion. let me have the following >> propositions: >> >> a. NAT64 suitable for any case no matter A2 is assigned with any kind of >> address, but currently only works for TCP and UDP. > > Yes (but with the DF bit transparency limitation that is avoided in case of > NAT64+) > >> b. NAT64+ works for the cases where A2 is assigned with a special type of >> IPv6 address with the CNP, without need to update checksum for any L4 >> protocols.
Seems right. >> >> c. NAT64+ works like: >> if A2 has a V-CNP-address, then it doesn't update the checksum for any L4 >> protocols; >> if A2 has any other kind of native IPv6 address, then NAT64+ works just >> like NAT64, updating the checksum but also currently only works for TCP and >> UDP. Seems right too. >> >> i think we are common that a. is true, right? > > Right, with the caveat above. > >> do you mean c. instead of b. ? > > NAT64+ works like NAT64 in all cases, except for 4rd CEs that: > - received a NAT64+ mapping rule > - have IPv6 prefixes from which no IPv4 address can be derived. > For them, better transparency is achieved by replacing double RFC6145 > translation by a Reversible header mapping. > > not yet cleared. "receives a NAT64+ mapping rule" for what? To know what to do with IPv4 packets if assigned no public IPv4 address. > is the NAT64+ mapping rule stateless or stateful? The rule is neither. It just says what the CE has to do if having no public IPv4 address. What the NAT64+ must be stateful, at least for IPv6 addresses that are not mapped to any public IPv4 address. > what the behavior of NAT64+ in the case of "except"? is there "and" or "or" > between the "received ..." and the "have IPv6 prefixes..." clauses? Not understood. > please answer directly: do you mean c. instead of b.? (or, if either is not > applied, and you may have d.) If pressed to make a choice, c. seems closer to what I described. RD > > thanks, > maoke > > > That's IMHO clear enough, especially with the (*) above which clarifies AFAIK > which native and 4rd IPv6 addresses are used by CEs. > > > Cheers, > RD > > > > >> >> thanks, >> maoke >> >> >> >>> NAT64+ passing it without L4 checksum adjustment will make B receive a >>> packet with wrong checksum, for any L4 protocols. >>> >>> the above example works well for TCP and UDP with today's NAT64, without >>> limitations on A2's address. >>> >>> - maoke >>> >>> This is I suppose implicit, but it can advantageously be made explicit in >>> the draft. >>> Thanks. >>> >>> >>>>> 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. >>> >>> True, but while testing the V octet is sufficient in 4rd, the NAT64 has in >>> MAP to process mapping rules to find for null subnet IDs whose lengths >>> depend on which mapping rule applies. >>> That's IMHO one instance where the V-octet potential is clear. >>> >>> >>>> 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? >>> >>> Yes (see above). >>> >>>> if 2 is true, why you use stateful NAT64+ here for B rather than a >>>> stateless one? >>> >>> Because we consider hosts that are not assigned any public IPv4 address, >>> even shared. >>> >>>> 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. >>> >>> Suggestion not retained ;-). >>> What you call the IPv6 address pool isn't a reserved pool: as explained >>> above, NAT64+ synthesizes its IPv6 source addresses using its unchanged /64 >>> prefix. >>> >>> >>>> 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). >>> >>> Right. >>> >>> RD >>> >>> >>> >>> >>> >>>> >>>> - 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
