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