[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multihoming requirement and NAT64

Iljitsch van Beijnum escribió:

On 26 mrt 2008, at 21:53, Brian E Carpenter wrote:


during the v6ops meeting in Philadelphia, Michael brought up the issue
about multihoming support for NAT64 boxes. As we know, current NAT boxes 
interact poorly with multihioming configurations. the question i guess
whether we should impose some requirements of multihoming support for
new NAT64 boxes.



I don't see how we can, since there is no single, agreed technique
for IPv6 multihoming, and I don't see why we would impose any constraint
to do better than regular v4 NAT on the v4 side.


What kind of multihoming are we talking about?
My understanding is that we are talking about the possibility of having multiple NAT64, possible located in different ISPs 

Regards, marcelo
In the NAT64 model there are three entities: the IPv6 source host, the translator and the IPv4 destination host. There are three things that can go down: 

1. The link between the source and the translator
2. The translator
3. The link between the translator and the destination
For MNAT-PT, we are currently not considering any security mechanisms, which means that the translator pretty much has to be located in the service provider network. In that case, 1. can be addressed by regular customer-to-the-same-ISP multihoming techniques which don't impact global routing. If we assume that the translator is run by a third party this requires some form of IPv6 multihoming, so either PI space or shim6. Obviously it's impossible to do HBA for any IPv6 addresses that embed IPv4 addresses so shim6 is a problem.
Alternatively, an outage in 1. or 2. can be addressed by switching to another translator, likely located at another ISP. This means that sessions break.
It should be possible to deploy translators in clusters, but the state replication thta's required to perform a failover without breaking sessions seems prohibitive. 

For 3., standard IPv4 multihoming techniques would have to apply.
It seems to me that not having any session preserving multihoming support isn't worse than NAT44, so there is no need to make this a requirement - with one small exception: in order to successfully fail over to a different translator, the entity that creates the full IPv6 address from the IPv4 address and the translator prefix MUST be able to discover a /96 prefix for a working translator fairly quickly after the failure of a previously used translator. I'm not sure what "fairly quickly" would mean in this context, though. Certainly not days or hours. Minutes? Seconds, even?