Re: [Softwires] 4rd-u tunnels and stateful NAT64s

Le 2012-03-15 à 14:47, Maoke a écrit :

> 
> 
> 2012/3/15 Rémi Després <despres.remi@laposte.net>
> 
> 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

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

> 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 <despres.remi@laposte.net>
>> 
>> 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
>> > Softwires@ietf.org
>> > https://www.ietf.org/mailman/listinfo/softwires
>> 
>> 
> 
> 