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

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

Reply via email to