Subject: multihoming requirement and NAT64

From: marcelo bagnulo <[email-masked]>
Date: Wed, 26 Mar 2008 19:38:10 +0100

Hi,

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.

comments?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2008 09:53:35 +1300

> whether we should impose some requirements of multihoming support for

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.

It might be worth asking solutions to describe how they
interact with various multihoming techniques.

    Brian

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 27 Mar 2008 19:34:49 +0900

Marcelo,

I don't have concrete idea, but it may not impossible with current or  
future
technologies.
If it is not classified as a MUST, and if it is really required, we  
can add to
requirement document, since it is Requirement.

On the other hand, I have a concern.
So, let me confirm some fundamental points.

Does the requirement document have clear criteria to add a item to the  
list?
Will the requirement document list all the features of IPv6?

I think NAT64 environment is not conformable as native ipv6 environment.
So, there may be some restrictions in somewhere.

I think we should list only the items which have realistic use case.
# This is generic proposal, and not directly related to multihoming  
issue.

Best Regards,

...miyata

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 27 Mar 2008 12:23:29 +0000

Marcelo,

Just to be clear, are you talking about the NAT64 box being
multi-homed, or are you talking about multiple NAT64 boxes serving the
same stab network?

George

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Mar 2008 14:56:46 +0100

> to do better than regular v4 NAT on the v4 side.

What kind of multihoming are we talking about?

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?

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:07:08 +0100

> 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

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:05:56 +0100

George Tsirtsis escribió:
> multi-homed, 
i don't think so, but this issue was brought up by Michael during the 
meeting (i was merely trying to address and generate discussion for 
every item that was was raised during the meeting)

> or are you talking about multiple NAT64 boxes serving the
> same stab network?
>
>   
that is what i understood Michael was talking about

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:13:54 +0100

> requirement document, since it is Requirement.
we can include in the should list, meaning that is a nice to have 
feature and that can be used to compare different solutions?

> Does the requirement document have clear criteria to add a item to the 
that the WG feels it is imporntant

> Will the requirement document list all the features of IPv6?
i hope not

> # This is generic proposal, and not directly related to multihoming 
agree

regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: Fri, 28 Mar 2008 18:14:28 +0100

agree

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Mar 2008 21:12:26 +0100

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

Ok. I think this SHOULD go into the requirements:

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

---

From: "George Tsirtsis" <[email-masked]>
Date: Sat, 29 Mar 2008 10:32:22 +0000

>  Ok. I think this SHOULD go into the requirements:

GT> Sorry, I am slow this morning but what does this mean exactly? Are
you talking about one NAT64 box connected to two ISPs? or are you
talking about two NAT64 boxes serving the same IPv6-stab, connected to
two different ISPs? I assume the latter? In which case what would we
expect to add to each NAT64 box to allow a second NAT64 box to exist?
I would expect that such support would require something by the end
nodes e.g., being able to discover the different NAT64 prefixes etc.
or are you thinking something else?

Thanks
George

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 29 Mar 2008 14:46:47 +0100

On 29 mrt 2008, at 11:32, George Tsirtsis wrote:

> talking about two NAT64 boxes serving the same IPv6-stab,

What's an IPv6-stab?

What I'm talking about is the situation where a user is using one  
translator, the translator fails and the user needs to switch to  
another translator.

In order for this to work, the user needs to see a new /96 for the  
other translator relatively fast. So either the user needs to switch  
to a different DNS resolver for existing NAT-PT, which I don't think  
can happen quickly as a reaction to a failure beyond the local link,  
or the DNS ALG / host itself needs to see a new /96 prefix though some  
TBD mechanism fairly quickly.

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 31 Mar 2008 13:29:45 +0000

>  > talking about two NAT64 boxes serving the same IPv6-stab,

GT> hmmm IPv6-stub(?) maybe. I mean an IPv6 only network that does not
offer any transit routing services even if it has more than one
interfaces to other networks.

>  TBD mechanism fairly quickly.

GT> OK, this is clear. This then is not going to be a seamless event,
but at least communications can be restarted.

Thanks
George