Subject: [BEHAVE] trade-offs handling multiple state-full v4v6 translators

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Apr 2009 18:04:05 +0200

Warning: long email coming

The goal of this email is to get input from the WG on how to support 
multiple v4v6 translators.

We have different level of support of multiple state-full translators 
within a domain and we need to agree on a trade-off in this situation.

The scenario is the following:

+------------------------+
|  v6 site               |
|                        |
|            |   +------+|  +---+
|            |---|NAT64a|---| V4|
|            |   +------+|  | In|
|   +-----+  |           |  |ter|     +------+
|   |H1 v6|--|           |  |net|-----|H2 v4 |
|   +-----+  |   +------+|  |   |     +------+
|            |---|NAT64b|---|   |
|            |   +------+|  |   |
|            |           |  +---+
|                        |
+------------------------+

So, The first question is what do we want to achieve when we have 
multiple translators. There are two obvious goals: load sharing and 
fault tolerance.

Because the different NAT64 boxes are likely to have different pool of 
public IPv4 addresses, then, it seems challenging to preserve 
established communications through the failure of a NAT64 box.

So, preserving established connections through failure of one NAT64 box 
is not a goal for NAT64. Makes sense?

What can be achieved is to allow new communications to be established 
when one of the NAT64 boxes have failed, using the alternative one if it 
is up. So, if we accept the proposed scoping of the goal, fault 
tolerance in this context means exactly that.

--------------------------------------------------------------

So as a first question: Do people agree that the goals for the case of 
multiple translators should be load sharing and fault tolerance (using 
the previous definition of fault tolerance)?

---------------------------------------------------------------

If yes, a key issue to consider is how the Prefix64 is used 
(irrespectively whether the Prefix64 is a WK prefix or a LIR prefix, i 
think this analysis is orthogonal to that decision and applies to both 
of them)

So, a bit of context, cause the discussion is a bit hairy

A NAT64 box needs to be configured with a Prefix64 in order to represent 
IPv4 address in the IPv6 address space. This is usually done by 
concatenating the PRefix64 and the IPv4 address and potentially a suffix.

In addition, the NAT64 needs to inject a route towards the Prefix64 in 
the IPv6 domain so that it sinks all the packets containing that 
destination prefix, so it can translate them into IPv4 packets.

In a setting  with a single NAT64 box, the Prefix64 used to create  IPv6 
representations of IPv4 address and the prefix included in the route 
injected by the NAT64 box are the same, so life is easy. This is not 
necessarily the case in the case with multiple NAT64 boxes, especially, 
if we want to provide the aforementioned features.

-------------- Option 1 --------------------------------------------------

So, one obvious choice is that we assign the same Prefix64 to both NAT64 
boxes and that both NAT64 boxes inject a route towards that prefix in 
the IPv6 routing domain.

The result is that we do have some load sharing, cause IPv6 hosts will 
use the NAT64 box that is closer (according to the IGP) and in case of a 
failure of one of the boxes, new communications will be routed to the 
alternative NAT64 box, since we assume that the route to the former 
NAT64 box disappear when the NAT64 box went down. The limitation of this 
approach is that it may be possible, due to intra site routing 
fluctuations, that packets of a given communication that were originally 
using a NAT64 box end up using a different NAT64 box and the 
communication is interrupted.

Consider the following example:

+-----+    |    +--+          +------+
|Host1|----|----|R1|----+-----|NAT64a|
|IPv6 |    |    +--+    |     +------+
+-----+    |          +---+   
           |          |R2 |  
           |    +--+  +---+   +------+
           |----|R3|    |     |NAT64b|
           |    |  |  +--+    |      |
           |    |  |--|R4|----|      |
                +--+  +--+    +------+

Both NAT64a and NAT64b are injecting a route for the Prefix64 into the IGP
suppose both NAT64 are working.
Host1 initiates a communication, so it will use NAT64a, since it is the 
one with shortest distance from Host1
Suppose that at some point R1 fails. At this point, packets from Host1 
will be delivered to NAT64b, which will translate them using a different 
public IPv4 address and the communication will fail. Please note that 
both NAT64 boxes are working fine, it is just a change in the intra 
domain routing that made the connection to be interrupted.

So, is this acceptable? If not, we can explore other options.

-------------- Option 2 --------------------------------------------------

One possible way to address this problem is for the different NAT64 
boxes to announce a more specific prefix and the less specific prefix. 
Let me expand on this. Suppose (as an example) that the Prefix64 is 48 
bot long. The IPv6 representation of IPv4 address a.b.c.d would then be 
Prefix64:a.b.c.d::. Suppose now that NAT64a injects two routes into the 
IGP one for Prefix64::/49 and another one for PRefix64::/48, while 
NAT64b injects Prefix64:FFFF::/49 and Prefix64::/48.
This setup implies that all packets with IPv4 destination address within 
the prefix 0.0.0.0/1 will be routed to NAT64a and all packets with IPv4 
destination within the prefix 128.0.0.0/1 will be routed to NAT64b (as 
long as both NAT64 boxes are up). In case one of them fail, all packets 
will be routed to the remaining one, thanks to the less specific route. 
This provides the fault tolerance capabilities and also deals with the 
routing fluctuation problem. However, this option is not without 
limitations of its own.

A first limitation is that the resulting load sharing capabilities are 
far from optimal. IPv4 addresses usage is not uniformly distributed 
accross the IPv4 address space, so it is likely that one of the NAT64 
boxes will get more load than the other one with this simple approach 
(this needs to be confirmed, but it seems this can be the case).

A second, probably much more serious limitation, is that this seems to 
break current nat traversal techniques (since it would break endpoint 
independent behaviour)(*). The problem is that when an IPv6 host behind 
two NAT64 boxes announcing different prefixes try to communicate with 
different IPv4 target hosts, the packets can be routed through different 
NAT64 boxes, so the same host will appear to the IPv4 hosts with 
different IPv4 addresses. For example, suppose that in the setup 
previously described an IPv6 hosts sends a packet towards host 1.1.1.1. 
This packet will be processed by NAT64a and will be sent with an IPv4 
source address from the pool of NAT64a. Next the _same_ host sends a 
packet to 130.1.1.1 and the packet is then processed by NAT64b, so, the 
resutling IPv4 packet will include an address from the NAT64b pool as a 
source address. I understand that this is exactly the behaviour that not 
desired and that NAT traversal techniques would not work if this case. 
Is this correct? Is this acceptable?

If not acceptable, we can explore other alternatives.

-------------- Option 3 --------------------------------------------------

A simple alternative option would be for the NAT64 boxes to use a 
different Prefix64. In this case, NAT64a would use Prefix64a and NAT64b 
would use Prefix64b. NAT64a will inject Prefix64a in the routing system 
and NAT64b will inject PRefix64b in the IGP. Let's assume there is no 
relationship whatsoever between the two prefixes for now.

With this approach, we can solve the previous problem, since packets 
containing  destination address with PRefix64a will always be routed 
towards NAT64a as long as the NAT64a box is reachable. Same for NAT64b. 
The problem though is that if one of the boxes fail, packets containing 
a destination address with one of the prefixes will never be delivered 
to the alternative box, beating the fault tolerance purpose.

We consider next some approaches to overcome this limitation.

-------------- Option 4 --------------------------------------------------

One option is to involve the DNS64 at this point. So, if we have two 
Prefix64, the DNS64 can synthesize using any of them.
In order to provide fault tolerance, the DNS64 could actually return two 
synthetic AAAA RR, one with each prefix. In this way, if a NAT64 box is 
down, the initiating host will try with the alternative AAAA RR and will 
use the alternative prefix, hence the alternative NAT64 box. In this 
case, the fault recovery is up to the host. Is this acceptable? (note 
that in this case, each NAT64 box is only announcing a single route with 
its own prefix, so from the NAT64 perspective as well as from the IGP 
perspective, this approach is straightforward)

In order to achieve load balancing properties, the DNS64 should use them 
in a round robin fashion i.e. return a different prefix64 in the first 
AAAA RR included in the answer. The problem here is similar to a 
previous case (*) is that this has the potential to break endpoint 
independent behaviour, since the same host can obtain answers with 
different prefixes and be exposed to the IPv4 hosts with different IPv4 
address, potentially breaking NAT traversal techniques. Is this correct?
It would be possible to overcome this limitation if we always present 
the same prefix in the first AAAA RR contained in the DNS response. This 
basically requires that the DNS64 uses first one prefix or the other 
depending on the source address of the DNS query (please note that this 
does not require a per host state in the DNS64)
This approach seems to work at this point, is this acceptable?

-------------- Option 5 --------------------------------------------------

Finally, another way of dealing with multiple prefixes is for the NAT64 
boxes to be aware of the multiple prefixes.
In this case, both NAT64 boxes announce both prefixes but with different 
distance. So NAT64a announces a route in the IGP to Prefix64a with a 
short distance and also announces a route towards Prefix64b but with a 
high distance. NAT64b does the opposite i.e. announce the two routes 
with the distances interchanged.
DNS64 will behave in the same way as in the previous case. The 
difference, is that both NAT64 boxes can support both prefixes, so in 
case one NAT64 box fails, there is no need for the host to retry with 
the alternative prefix, since the remaining NAT64 box can handle both 
prefixes.
The downside with this is that the NAT64 needs to keep track of which 
IPv6 source address is using which Prefix64, so it requires more state 
in the NAT64 and its processing becomes more complex (and what's more it 
make the state machine more complex, needing to handle different states 
based on the incoming source address and prefix combinations)

----------------------------------------------------------------

My personal preference is Option 4, but if people can comment it would 
be very useful.

Regards, marcelo

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 15 Apr 2009 12:14:21 +0800

Hi,

> is not a goal for NAT64. Makes sense?

IMHO, keeping the established session uninterrupted during the switchover of
NAT64 boxes should be desired, but not required.
 
> 
> -------------- Option 1 
> --------------------------------------------------
> 
<skip some text> 
> So, is this acceptable? If not, we can explore other options.

Not acceptable, IMO.

> 
> -------------- Option 2 
> --------------------------------------------------
> 
<skip some text>
> different IPv4 addresses. ...
>I understand that this is exactly the 
> behaviour that not 

What's the side-effect if the same host will appear to the *different* IPv4
hosts with 
different IPv4 addresses?

> -------------- Option 3 
> --------------------------------------------------
> 
> -------------- Option 4 
> --------------------------------------------------
> 
> case, the fault recovery is up to the host. Is this acceptable? 

Both option 4 and 5 are not acceptable since they require IPv6 hosts to
determine the availability of the prefix64, IMO.
 
> -------------- Option 5 
> --------------------------------------------------
> 

This sounds acceptable. Besides, the distance for the same prefix64 route
set by different NAT64 boxes should be much different so as to overcome the
influence of the route fluctuation mentioned in option 1.

> based on the incoming source address and prefix combinations)

Why should the NAT64 box keep track of which IPv6 source address is using
which Prefix64, Could you explain more? 

Xiaohu

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 14 Apr 2009 21:33:28 -0700

> NAT64 boxes should be desired, but not required.

If it's invisble to the host stack's on either end then no big deal, if
it requires that one or the other of them change that clearly has
implications for cases in which it can be deployed.

If they were deployed with some vrrp like equivalence then it's up the
the implementation to mirror state between the two boxes.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 15 Apr 2009 13:37:02 +0800

> If it's invisble to the host stack's on either end then no 
> big deal, if it requires that one or the other of them change 
> that clearly has implications for cases in which it can be deployed.
> 
> If they were deployed with some vrrp like equivalence then 
> it's up the the implementation to mirror state between the two boxes.

I fully agree. In fact, we can extend the option 5 by running some VRRP like
keepalive mechanism on two NAT64 boxes and selecting one as primary NAT64
for group A (prefix64-A and IPv4 Pool A)and secondary  NAT64 for group B
(prefix64-B, and IPv4 Pool B),  another one as primary  NAT64 for group B
and secondary NAT64 for group A, the primary NAT64 for group A (or group B)
will advertise the route to that prefix64-A (or prefix64-B)on IPv6 side and
the route to IPv4 pool A (or IPv4 Pool B) on IPv4 side , while the secondary
one can either not advertise those routes or advertise them with high cost.
Besides, the primary and the secondary could synchronize the mapping info.
In this way, we could achieve hot standby NAT64.

Xiaohu

> >> So, one obvious choice is that we assign the same Prefix64 to both 
> >> NAT64 boxes and that both NAT64 boxes inject a route towards that 
> >> prefix in the IPv6 routing domain.
> >>
> >> The result is that we do have some load sharing, cause IPv6 hosts 
> >> will use the NAT64 box that is closer (according to the 
> IGP) and in 
> >> case of a failure of one of the boxes, new communications will be 
> >> routed to the alternative NAT64 box, since we assume that 
> the route 
> >> to the former
> >> NAT64 box disappear when the NAT64 box went down. The 
> limitation of 
> >> this approach is that it may be possible, due to intra 
> site routing 
> >> fluctuations, that packets of a given communication that were 
> >> originally using a NAT64 box end up using a different 
> NAT64 box and 
> >> the communication is interrupted.
> > <skip some text>
> >> A first limitation is that the resulting load sharing capabilities 
> >> are far from optimal. IPv4 addresses usage is not uniformly 
> >> distributed accross the IPv4 address space, so it is 
> likely that one 
> >> of the NAT64 boxes will get more load than the other one with this 
> >> simple approach (this needs to be confirmed, but it seems 
> this can be 
> >> the case).
> >>
> >> A second, probably much more serious limitation, is that 
> this seems 
> >> to break current nat traversal techniques (since it would break 
> >> endpoint independent behaviour)(*). The problem is that 
> when an IPv6 
> >> host behind two NAT64 boxes announcing different prefixes try to 
> >> communicate with different IPv4 target hosts, the packets can be 
> >> routed through different
> >> I understand that this is exactly the behaviour that not 
> desired and 
> >> that NAT traversal techniques would not work if this case.
> > What's the side-effect if the same host will appear to the 
> *different* 
> > IPv4 hosts with different IPv4 addresses?
> > 
> >> different Prefix64. In this case, NAT64a would use Prefix64a and 
> >> NAT64b would use Prefix64b. NAT64a will inject Prefix64a in the 
> >> routing system and NAT64b will inject PRefix64b in the IGP. Let's 
> >> assume there is no relationship whatsoever between the two 
> prefixes 
> >> for now.
> >>
> >> The problem though is that if one of the boxes fail, packets 
> >> containing a destination address with one of the prefixes 
> will never 
> >> be delivered to the alternative box, beating the fault tolerance 
> >> purpose.
> >>
> >> In order to provide fault tolerance, the DNS64 could 
> actually return 
> >> two synthetic AAAA RR, one with each prefix. In this way, if a
> >> NAT64 box is
> >> down, the initiating host will try with the alternative 
> AAAA RR and 
> >> will use the alternative prefix, hence the alternative 
> NAT64 box. In 
> >> this case, the fault recovery is up to the host. Is this 
> acceptable?
> > 
> > Both option 4 and 5 are not acceptable since they require 
> IPv6 hosts 
> > to determine the availability of the prefix64, IMO.
> >  
> >> -------------- Option 5
> >> Finally, another way of dealing with multiple prefixes is for the 
> >> NAT64 boxes to be aware of the multiple prefixes.
> >> In this case, both NAT64 boxes announce both prefixes but with 
> >> different distance. So NAT64a announces a route in the IGP to 
> >> Prefix64a with a short distance and also announces a route towards 
> >> Prefix64b but with a high distance. NAT64b does the opposite i.e. 
> >> announce the two routes with the distances interchanged.
> > This sounds acceptable. Besides, the distance for the same prefix64 
> > route set by different NAT64 boxes should be much different 
> so as to 
> > overcome the influence of the route fluctuation mentioned 
> in option 1.
> > 
> >> IPv6 source address is using which Prefix64, so it requires more 
> >> state in the NAT64 and its processing becomes more complex (and 
> >> what's more it make the state machine more complex, 
> needing to handle 
> >> different states based on the incoming source address and prefix 
> >> combinations)
> > 
> > Why should the NAT64 box keep track of which IPv6 source address is 
> > using which Prefix64, Could you explain more?
> > 
> > Xiaohu
> >

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 10:51:15 +0200

> NAT64 boxes should be desired, but not required.

makes sense
so, this basically means that in the base NAT64 spec we don't provide 
this feature, but another draft can provide it

> different IPv4 addresses?
this basically would break endpoint independent behaviour
Endpoint independent behaviour means exactly that, that the same 
transport address is used when contacting different external hosts
(the definition of endpoint independence actually applies to the 
behaviour of a single nat box. but sending packets from the same node to 
different destinations through different nat boxes would actually have 
the same external behaviour of a nat box without endpoint independent 
behaviour AFAICT)

I understand that current NAT traversal techniques work better if 
endpoint independent behaviour is used, but i am no NAT traversal 
expert, maybe someone else can confirm that (this was actually the goal 
of a my email)

>> containing 

Not really
Option 5 would actually be compliant with current host behaviour i.e. 
does not need changes to current hosts
Option 5 basically works as follows. The DNS64 returns two AAAA RR with 
different prefixes on it. the host will try with the first one. If 
doesn't work it will try with the second one. This is exactly what hosts 
do today when they receive multiple RR for a DNS query.
So, it would work just fine and it ia actually a commonly used method to 
provide redundancy for servers i.e. multiple RR in the DNS corresponding 
to differnet redundant servers

> which Prefix64, Could you explain more? 
because when it receives packets in the reverse direction, it needs to 
know which prefix to use in IPv6 packet (as a source prefix)
when the NAT64 box can use more than one prefix, then it needs to keep 
track of which prefix has used for every flow it is processing. this is 
considerable additional complexity imho and i am not sure it is worth 
the advantages.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 10:55:15 +0200

> the implementation to mirror state between the two boxes.

right
but you can only do that if both NAT boxes can use the same pool of 
public addresses.

I mean, this really depends on the topology
If you are using, different NAT64 noxes to connect to different ISP and 
you are using PA addressing, then this does not work
If you are using PI addresses, then you are in business
If you are using a DMZ kind of topology, where all NAT64 are in the same 
link and all the access routers to all you ISPs are connected so all 
nats can use any address, then you are in business (with PA or PI 
addressing)

Clearly in the last two cases, you need a protocol between the NAT64 
boxes to keep track of the state.

but i guess we are on the same page

Regards, marcelo

>>> limitation of this 
>>> originally

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 10:57:21 +0200

> In this way, we could achieve hot standby NAT64.

I think you are mixing the two problems here
the options presented above are only for establishing new connection
If you want to preserve estbalished connection, itis a completelly 
different problem and i would suggest we keep them separated.

Regards, marcelo

>>>> One possible way to address this problem is for the 
>>>>         
>> different NAT64 
>>     
>>>> With this approach, we can solve the previous problem, 
>>>>         
>> since packets 
>>     
>>>> containing  destination address with PRefix64a will always 
>>>>         
>> be routed 
>>     
>>>> One option is to involve the DNS64 at this point. So, if 
>>>>         
>> we have two 
>>     
>>>> difference, is that both NAT64 boxes can support both 
>>>>         
>> prefixes, so in 
>>     
>>>> case one NAT64 box fails, there is no need for the host to 
>>>>         
>> retry with 
>>     
>>>> the alternative prefix, since the remaining NAT64 box can 
>>>>         
>> handle both 
>>     
>>>> prefixes.
>>>>         
>>>> The downside with this is that the NAT64 needs to keep 
>>>>         
>> track of which
>>

---

From: Xuewei Wang <[email-masked]>
Date: Wed, 15 Apr 2009 18:41:15 +0800

Xuewei Wang
----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Joel Jaeggli" <[email-masked]>
Cc: "'Behave WG'" <[email-masked]>; "Xu Xiaohu" <[email-masked]>
Sent: Wednesday, April 15, 2009 4:55 PM
Subject: Re: [BEHAVE] trade-offs handling multiple state-full v4v6 translators

> but you can only do that if both NAT boxes can use the same pool of 

I think the same pool can't be used by two different NAT64 devices. Because if so, assuming there are two different IPv6 hosts want to  communicate with the same IPv4 host, when  transversing the different NAT64 devices, they may be assigned the same IPv4 address by the different NAT64, and the two communication will have the same source address and the same destination address. Unless there are some intercommunion between the two NAT64 devices, and enable the addresses in the pool used by one NAT64 can't be used by another NAT64, which is not practical.

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 16 Apr 2009 10:41:31 +0800

> this feature, but another draft can provide it

The requirement of fault tolerance depends heavily on the serving scope of
the NAT64 box. If the NAT64 box is serving a huge amount of IPv6 hosts, the
hot standby mechanism should be strongly desired.

> IPv6 hosts to

If the session (e.g. TCP connection) over the first one was established
successfully and later interrupted due to the failure of the first one,
will the session automatically try the second one? I'm not sure whether this
feature can be supported by all current applications. Could anyone
expertised in this field confirm it?

> considerable additional complexity imho and i am not sure it is worth 

If one IPv6 host uses only one prefix64 for all connections, that's not a
big problem. However, if the IPv6 host (e.g. attacker) is allowed to use
different prefix64 for different connection, that will become a nightmare
since the NAT64 will need to maintain one state per connection.

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 16 Apr 2009 10:57:46 +0800

> -----邮件原件-----
> 发件人: marcelo bagnulo braun [mailto:[email-masked]] 
> 发送时间: 2009年4月15日 16:57
> 收件人: Xu Xiaohu
> 抄送: 'Joel Jaeggli'; 'Behave WG'
> 主题: Re: [BEHAVE] trade-offs handling multiple state-full v4v6 
> translators
> 
> Xu Xiaohu escribió:
> big deal, 
> >> if it requires that one or the other of them change that 
> clearly has 
> >> If they were deployed with some vrrp like equivalence then it's up 
> >> the the implementation to mirror state between the two boxes.
> >>     
> >
> > I fully agree. In fact, we can extend the option 5 by running some 
> > VRRP like keepalive mechanism on two NAT64 boxes and 
> selecting one as 
> > primary NAT64 for group A (prefix64-A and IPv4 Pool A)and 
> secondary  
> > NAT64 for group B (prefix64-B, and IPv4 Pool B),  another one as 
> > primary  NAT64 for group B and secondary NAT64 for group A, the 
> > primary NAT64 for group A (or group B) will advertise the route to 
> > that prefix64-A (or prefix64-B)on IPv6 side and the route 
> to IPv4 pool 
> > A (or IPv4 Pool B) on IPv4 side , while the secondary one 
> can either not advertise those routes or advertise them with 
> high cost.
> I think you are mixing the two problems here the options 
> presented above are only for establishing new connection If 
> you want to preserve estbalished connection, itis a 
> completelly different problem and i would suggest we keep 
> them separated.

Yes, the options you mentioned are about cold standby, while the above
approach I mentioned is about  hot standby. 

Xiaohu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 18:03:32 +0200

Xu Xiaohu escribió:
>>> IMHO, keeping the established session uninterrupted during 
>>>       
>> the switchover of
>>     

makes sense to me
this is not against we do this in a sperate document
> expertised in this field confirm it?

No, what i am saying is that for initial contact, if the first address
fails the apps should retru witht he next one as per rfc3484
Preserving a connection or inmediatelly re establishing a connection
after a failure is a different problem (that we are disucssing above)

To me the scope of the fault tolerance that makes sense to require for
the base spec is that a new connection can get estbalished after a fialure
This does not imply that a ongoing communication must be preserved or
reestablished automatically after a failure
>>> Why should the NAT64 box keep track of which IPv6 source 
>>>       
>> address is using
>>     
that's exactly the case, if the nat64 handles more than one prefix645,
then we need to maintain the destiantion address in the binding state

Regards, marcelo

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 17 Apr 2009 12:21:04 +0800

> > If the session (e.g. TCP connection) over the first one was 
> > established successfully and later interrupted due to the 
> failure of 
> > the first one, will the session automatically try the 
> second one? I'm 
> > not sure whether this feature can be supported by all current 
> > applications. Could anyone expertised in this field confirm it?
> >
> >
> >   
> 
> No, what i am saying is that for initial contact, if the 
> first address fails the apps should retru witht he next one 
> as per rfc3484 Preserving a connection or inmediatelly re 
> establishing a connection after a failure is a different 
> problem (that we are disucssing above)

I did know what you mean in the prevous email. I just want to explore it
further:)
 
> To me the scope of the fault tolerance that makes sense to 
> require for the base spec is that a new connection can get 
> estbalished after a fialure This does not imply that a 
> ongoing communication must be preserved or reestablished 
> automatically after a failure

To me,  The interruption of ongoing connection due to NAT64 switchover is
better to be avoided, and the re-establishment after NAT64 switchover much
be supported. That's to say, the former is a strong DESIRE, and the latter
is a MUST.

> > If one IPv6 host uses only one prefix64 for all connections, that's 
> > not a big problem. However, if the IPv6 host (e.g. attacker) is 
> > allowed to use different prefix64 for different connection, 
> that will 
> > become a nightmare since the NAT64 will need to maintain 
> one state per connection.
> >
> >   
> that's exactly the case, if the nat64 handles more than one 
> prefix645, then we need to maintain the destiantion address 
> in the binding state

Exactly. BTW, if we could assign different IPv4 pool corresponding to
different prefix64, (e.g. if an IPv6 host uses perfix64_A in the synthetical
IPv6 address, then the NAT64 assigns an IPv4 address from IPv4 address
Pool_A to this IPv6 host ,  if uses prefix64_B, allocates an IPv4 address
from Pool_B). In addition, if there is no mapping state synchronization
among multiple NAT64 boxes, the IPv4 address pools on each NAT64 should be
different from those on others. Is that works?

Xiaohu