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