Subject: [BEHAVE] NAT64 and MIPv6

From: Wassim Haddad <[email-masked]>
Date: Thu, 27 Aug 2009 11:25:48 -0400

Dear all,

Please find attached a note on NAT64 and MIPv6.

Regards,

Wassim H.

---

From: Hui Deng <[email-masked]>
Date: Fri, 28 Aug 2009 10:48:38 +0800

Hi, Wassim,

The problem in your draft has been elaborated inside us before.
this is one driving force for us to design PNAT
http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01
we guess that identify the peer side IP family type is important for
the communication.

Current NAT64 assume host is IPv6 only, and network is IPv6 only connection.
but PNAT64 assume host is dual stack, and network is IPv6only connection.

and NAT64 need DNS64, and PNAT64 don't need DNS64.
furthermore PNAT host understand peer side whether it is IPv4 or IPv6
which could remove your concern in this draft.

PNAT assume host will rely on PNAT64 for its IPv4 application,
will rely on NAT64 for its IPv6 application.

thanks for the discussion.

-Hui

2009/8/27 Wassim Haddad <[email-masked]>:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Aug 2009 07:43:17 -0400

On Thursday 27 August 2009 22:48:38 Hui Deng wrote:
> Current NAT64 assume host is IPv6 only, and network is IPv6 only
> connection. but PNAT64 assume host is dual stack, and network is IPv6only
> connection.

This is not true. NAT64 doesn't assume anything about the host, while PNAT64 
assumes that the host implements PNAT64.

This is one of the assumptions driving NAT64: we cannot modify the hosts at 
this point. If this assumption does not hold for your network, fine, you can 
use something else. But for many, it does.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Wassim Haddad <[email-masked]>
Date: Fri, 28 Aug 2009 11:31:34 -0400

=> Your comment does not help solve/avoid the problem!

Wassim H.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Aug 2009 11:41:28 -0400

On Friday 28 August 2009 11:31:34 Wassim Haddad wrote:
> NAT64 doesn't assume anything about the host, while
> PNAT64 assumes that the host implements PNAT64.
>

My apologies. Here's something more constructive:

It is pointless to try to solve the problem you pointed out by changing the 
networking stack in hosts. If this is done, then the major driver for NAT64 
goes away, and there is a plethora of solutions that become possible.

Therefore, it is better to ask this question: is it possible to fix the NAT64 
box (and/or DNS64) so that the problem you pointed out is solved?

Simon

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Aug 2009 11:29:44 +0800

> assumes that the host implements PNAT64.
If you look at section 1.1 of NAT64, it says clearly about IPv6 only,
you can also take a look at definition of it in the framework draft

but today, please kindly help to let me know whose laptop, mobile, et
al. today are IPv6 only,
isn't this a strong assumption?

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Aug 2009 11:33:19 +0800

I am doubting that NAT64 doesn't change the host,
how it learn translator prefix?

-Hui

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 28 Aug 2009 20:50:01 -0700

> isn't this a strong assumption?

Hui, we have had this conversation before, right?

http://www.ietf.org/mail-archive/web/behave/current/msg06256.html

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 28 Aug 2009 22:11:29 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hui Deng
> Sent: Friday, August 28, 2009 8:33 PM
> To: Simon Perreault
> Cc: Wassim Haddad; [email-masked]
> Subject: Re: [BEHAVE] NAT64 and MIPv6
> 

With 6/4 translation and DNS64, the host does not need to learn the
translator's prefix, except in special situations such as when the host
obtains an IPv4 address literal (instead of a DNS name), such as due to a
referral to an IPv4 address literal or a protocol that only carries IPv4
address literals (e.g., deployments of protocols that use SDP).

In typical situations with 6/4 translation and DNS64 -- such as HTTP with
domain names, IMAP with domain names, SMTP submission, or nearly anything else
that uses DNS -- IPv6 hosts and their applications do not need to learn the
translator's prefix.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Aug 2009 10:58:23 +0200

> we guess that identify the peer side IP family type is important for

I fail to see how this is the case for the particular problem Wassim is 
describing in his draft.
If you have a node that is IPv4 and another is IPv6 and running MIPv6, 
then RO mode will fail
> but PNAT64 assume host is dual stack, and network is IPv6only connection.
so, how this will help MIPv6 RO mode to work?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Aug 2009 10:47:40 +0200

Hi Wassim,

I understand that the first point being made in the draft is that RO 
mode doesn't work through NAT64. I certainly agree with that and this 
was identified RFC 4966.
During the requirement discussion, the input from the mobility community 
was that the support for the RO mode in nat64 was not critical and that 
it was acceptable to fall back to BT mode in case there is a NAT64 along 
the path. I am not sure if you agree with that. In case you don't, it 
would be possible to overcome this by having the NAT64 to terminate the 
RO procedure (i.e. that the NAT64 replies the RR signalling so that the 
path is optimized to the nat64, sicne it cannot be optimized to the CN). 
I think it would be possible to define the nat64 extensions needed for that.

Then in your draft, you state that:

   In this case, the
   MN tunnels first its data packets to its HA without having them being
   intercepted by the foreign NAT64.  However, after reaching the HA,
   the data packets will most likely be dropped at some point.  This is
   due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6
   address.

I am not sure i understand that part. Are you saying that in case the MN 
decides to move to RO mode things won't work anymore or are you saying 
that data packets will be lost in BT mode?
If you are saying that the RO mode doesn't work, i agree with you as i 
mentioned above. If you are saying that data packets are lost in BT mode 
(when RO mode is not used at all), that i don't understnad the scenario, 
and i would appreciate a figure to understand it better.

Regards, marcelo

Wassim Haddad escribió:
> ------------------------------------------------------------------------
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 29 Aug 2009 10:07:24 +0200

> box (and/or DNS64) so that the problem you pointed out is solved?
I think it is (at least if the problem is the lack of RO support which 
is what i understood from the draft)
It basically implies that the nat64 terminates the RO RR signaling on 
behalf of the IPv4 node. I think this can be done.
But, when i raised this question in v6ops during the requirements, 
several people from the mobility community deemed it was not needed.
Maybe we can ask this again and see if they still think the same thing. 
Maybe it would be more constructive doing it by writing a draft 
describing the changes needed to nat64.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 29 Aug 2009 10:09:40 +0200

> how it learn translator prefix?

the host behind a nat64 doesn't need to learn the prefix for the basic 
support i.e. to support basic applications (such as any application that 
works through nat today) and to support a validating stub resolver.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 29 Aug 2009 10:12:34 +0200

> you can also take a look at definition of it in the framework draft

IPv6 only means that the the host doesn't have IPv4 connectivity, either 
cause it doesn't have the ipv4 stack or because it does have the stack 
but it doens't have an ipv6 that it can use for the communication (in 
general it doens't have a global ipv6 address)
> but today, please kindly help to let me know whose laptop, mobile, et
if they are connected to an netwrok that doesn't provide an IPv4 
address, they are

Regards, marcerlo

---

From: Dong Zhang <[email-masked]>
Date: Sat, 29 Aug 2009 17:18:28 +0800

Hi,

marcelo bagnulo braun 2009-08-29 Wrote:
>Hui Deng escribi?
IMHO, I guess the last two word "IPv6" in the sentence should be "IPv4", 
if I do not misunderstand.

>>> use something else. But for many, it does.

------------------				 
Dong Zhang
2009-08-29

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Aug 2009 17:42:23 +0800

but the host know he is talking with IPv4 node, he will not initate RO
then RO will not fail consequently.

but I guess for dual stack, RO may need a new solution.

-Hui

2009/8/28 marcelo bagnulo braun <[email-masked]>:
> If you have a node that is IPv4 and another is IPv6 and running MIPv6, then
> RO mode will fail
>>

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Aug 2009 17:52:32 +0800

firstly, I personally think that NAT64 should support IP mobility.

Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message.

Regards,

-Hui

2009/8/28 marcelo bagnulo braun <[email-masked]>:
> Hi Wassim,
>
> I understand that the first point being made in the draft is that RO mode
> doesn't work through NAT64. I certainly agree with that and this was
> identified RFC 4966.
> During the requirement discussion, the input from the mobility community was
> that the support for the RO mode in nat64 was not critical and that it was
> acceptable to fall back to BT mode in case there is a NAT64 along the path.
> I am not sure if you agree with that. In case you don't, it would be
> possible to overcome this by having the NAT64 to terminate the RO procedure
> (i.e. that the NAT64 replies the RR signalling so that the path is optimized
> to the nat64, sicne it cannot be optimized to the CN). I think it would be
> possible to define the nat64 extensions needed for that.
>
> decides to move to RO mode things won't work anymore or are you saying that
> data packets will be lost in BT mode?
> (when RO mode is not used at all), that i don't understnad the scenario, and
> i would appreciate a figure to understand it better.
>
> Regards, marcelo
>
> Wassim Haddad escribió:
>>
>> Dear all,
>>

---

From: Hui Deng <[email-masked]>
Date: Sat, 29 Aug 2009 18:00:54 +0800

so many people arguing me before said IPv6 only means that, and now
you said differently.
I am tired to find those post again,

let me try to bring the definition from the framework draft
   IPv6-only:  An IPv6-only implementation, in this context, comprises
      an IPv6 enabled end system stack plus routing in the network.  It
      implies that two application instances are capable of
      communicating using IPv6, but not IPv4 - they have an IPv6 stack,
      addresses, and network support including routing in IPv6, but some
      element is missing that prevents communication with IPv4 hosts.

I guess majority of the list have totally different understanding of IPv6 only
and would like to suggest to re-discuss it again, I saw one post to
suggest re-wording.

thanks

-Hui

2009/8/29 marcelo bagnulo braun <[email-masked]>:
> cause it doesn't have the ipv4 stack or because it does have the stack but
> it doens't have an ipv6 that it can use for the communication (in general it
> doens't have a global ipv6 address)
>>
> if they are connected to an netwrok that doesn't provide an IPv4 address,
> they are
>
> Regards, marcerlo
>

---

From: bo zhou <[email-masked]>
Date: Sat, 29 Aug 2009 22:15:41 +0800

Well, I think hui mentioned the "re-wording" means the comments for the v4v6
framework we posted couple days ago.
Related to definition of IPv6 only in the v4v6 framework draft, we think we
should carefully understand the meanings of “IPv6 only".
The original comments I posted as follows:

  Existing “IPv6-only” and “IPv4-only” definitions are targeting to IP host
capabilities, but there are unclear descriptions of “application instances”
IP family host shall be defined combining with four aspects

   - the application type installed on the host
   - the IP family stack supported by a host
   - the IP family routing assigned by a network
   - available IP family connectivity

According to the principles, following IP family host definitions are
suggested to replace current “IPv6-only” and “IPv4-only” definitions and
propose a new definition for supplement
IPv4 only host comprises an IPv4 enabled end system stack plus routing in
the network, IPv4 applications installed on the host. It implies two
application instances with installed IPv4 applications are capable of
communication using IPv4, but not IPv6 ……
IPv6 only host comprises an IPv6 enabled end system stack plus routing in
the network, IPv6 applications installed on the host. It implies two
application instances with installed IPv6 applications are capable of
communication using IPv6, but not IPv4 ……
IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system
dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications
installed on the host. It implies two application instances with installed
IPv4/IPv6 applications are capable of communication using IPv6 – they have
IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IPv6
applications can communicate with IPv4/IPv6 hosts respectively.
Furthermore, the “An IPv6 network” are proposed to redefined as:
A specific network that has IPv6-only and IPv4-inherited IPv6implementation.
 Regards,

Bo Zhou

On Sat, Aug 29, 2009 at 6:00 PM, Hui Deng <[email-masked]> wrote:

> but
> >>> This is one of the assumptions driving NAT64: we cannot modify the
> hosts
> >>> at
> >>> this point. If this assumption does not hold for your network, fine,
> you
> >>> can

-- 
Regards,

Bo Zhou
China Mobile

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 29 Aug 2009 07:48:15 -0700

> Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message.

I do not see a need to support MIPv6.  Just like, in IPv4, i see MIPv6
as exotic.  I do not believe any of the major latest and forthcoming
operating systems support it out of the box.  Also, if you are talking
about mobility from 3GPP (2G/3G/4G) cellular mobile wireless network
provider perspective, it is not required or used in any way  The
mobile network guys (like me) use PMIPv6 and / or GTP based mobility,
both do not have any dependency on the end-host and provide all the
functionality in the network without the need for MIPv6.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Aug 2009 09:19:14 +0200

right, sorry for the confusion.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Aug 2009 09:20:48 +0200

> then RO will not fail consequently.
ok, so you are not considering the MN being an IPv6 only node, but a 
dual stack node, correct?

in this case, you should be looking at dsmip

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Aug 2009 09:21:39 +0200

> firstly, I personally think that NAT64 should support IP mobility.

define what do you mean by that
> Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message.
of course

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 30 Aug 2009 09:25:31 +0200

>       element is missing that prevents communication with IPv4 hosts.
that seems perfectly fine to me

so, below you stated that

"but today, please kindly help to let me know whose laptop, mobile, et 
al. today are IPv6 only,"

So, if you apply the definition you quoted above and you plug your 
laptop in a network that is not providing IPv4 connectivity i.e. the 
network does not provides your laptop an ipv4 address, then your laptop 
is an ipv6 only node according to the definition above.

> and would like to suggest to re-discuss it again, I saw one post to
no, i think almost everyone has the same defintion

Regards, marcelo

---

From: Zhen Cao <[email-masked]>
Date: Sun, 30 Aug 2009 17:32:30 +0800

>>> if they are connected to an netwrok that doesn't provide an IPv4 address,

This is somewhat confusing. When we are saying that a host is
IPv6-only, I guess we are expressing one of its static property. But
here you mean that its property is changing according to different
environments. I think what you are saying here more appropriately
refers to a specific scenario. But we cannot confuse a scenario with a
definition. From the definition, few hosts are IPv6 only implemented.

Thanks and regards,
Zhen

---

From: [email-masked]
Date: Sun, 30 Aug 2009 15:20:11 +0000

> definition. From the definition, few hosts are IPv6 only implemented.

Zhen, i agree that this can be confusing, but my understanding is the same  
as Marcelo. Here is an example scenario: I want it to act as an IPv6 only  
node on the my 3G UMTS carrier's network because my wireless carrier is  
only giving me IPv6 with NAT64 / DNS64 to bridge Internet v4 content. When  
i am at home on WiFi and my home gateway (cable company ds-lite on the wifi  
router) gives me IPv4 and IPv6 on my home WLAN, i want my laptop to act as  
a dual stack. When i am at work, my corporate LAN only supports IPv4, so my  
laptop must act as an IPv4 node only. All of these scenarios will  
automatically work today given current major operating systems, assuming we  
have a NAT64/DNS64 deployment.

If your laptop is dual stack capable / enabled today, it will work in these  
3 modes (v6 only, v4 only, dual stack) without any user intervention.

Regards,

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Zhen Cao <[email-masked]>
Date: Sun, 30 Aug 2009 23:37:08 +0800

Hi Wassim,

One comment is, even if the HoTI message can traverse the NAT64, the
IPv4 host cannot understand and handle it accordingly.

Thanks,
Zhen

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Aug 2009 23:16:44 -0400

=> Just by curiosity: can you explain why? Is it that harmful if the endpoint
is kept aware of what's going on and "somehow" assist the NAT64 in its role? 

=> This is *your* question! :)
My question/task is to try to highlight a potential problem in the current design 
when used by a mobile host. If the "behave community" agrees that there is 
indeed a problem then we'll start looking into how to solve it.

Regards,

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Aug 2009 23:27:13 -0400

Hi Dan,

=> Just a quick question please: if I take the definitions of "referral" and 
"callback" as mentioned in Erik's draft (draft-nordmark-multi6dt-refer-00), 
wouldn't be a problem in some scenarios if the referral is a DNS64-made 
v6 address or if the stored peer's address is also a DNS64-made v6 address? 

Regards,

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Aug 2009 23:45:35 -0400

Hi Marcelo,

Thanks for the notes. Please see mine inline.

>mode doesn't work through NAT64. I certainly agree with that and this

=> OK

>the path. I am not sure if you agree with that. 

=> I don't think we have much choices here. The CN is an IPv4 node only so
it does not understand RO mode...

> In case you don't, it would be possible to overcome this by having the NAT64 
> to terminate the RO procedure (i.e. that the NAT64 replies the RR signalling 
> so that the path is optimized to the nat64, sicne it cannot be optimized to the 
CN).

=> I see no problem with that. It should work fine if a MN starts a session with a 
CN while at home then moves to a foreign network (equipped with NAT64), tries 
RR and fails then stays with the BT mode. 

>I think it would be possible to define the nat64 extensions needed for that.

=> Agree. 

=> First, am sorry for a possible confusion! But you cut the first part of the
text! :)
What I meant is that when the MN moves to a foreign network and decides to 
initiate a new session with a v4 CN then:

a) we can forget about RO mode here BUT this is not the problem.
b) the MN will try to reach the CN via BT mode but even in this case, it will 
ultimately fail because the packet won't reach the home NAT64 in order to get 
translated (as it is using a different prefix).

> and i would appreciate a figure to understand it better.

=> Hope the above helps?

Regards,

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Sun, 30 Aug 2009 23:51:51 -0400

Hi Hui,

>Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message.

=> I think am lost here! Can you please explain what you mean by "NAT64 replies
to RR messages"?

Regards,

Wassim H.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 31 Aug 2009 07:20:45 -0400

On Sunday 30 August 2009 23:16:44 Wassim Haddad wrote:
> => Just by curiosity: can you explain why?

It's just a question of meeting the deadline. Changing what is widely deployed 
takes time and we need a solution to IPv6 transition yesterday.

> Is it that harmful if the
> endpoint is kept aware of what's going on and "somehow" assist the NAT64 in
> its role?

Are you suggesting that basic networking would work without changes on the 
host, but mobility would require a fix on the host? If so, I would think 
that's acceptable. But that's only my opinion.

> My question/task is to try to highlight a potential problem in the current
> design when used by a mobile host. If the "behave community" agrees that
> there is indeed a problem then we'll start looking into how to solve it.

I think you can pretty much take for granted that it will agree that there is 
a problem. Just how big of a problem depends on who you're asking... ;-)

Simon

---

From: Hui Deng <[email-masked]>
Date: Mon, 31 Aug 2009 23:34:03 +0800

we are considering MN has IPv6 only connections, this is not for DSMIP.

-Hui

2009/8/30 marcelo bagnulo braun <[email-masked]>:
> ok, so you are not considering the MN being an IPv6 only node, but a dual
> stack node, correct?
>
>>> then

---

From: Hui Deng <[email-masked]>
Date: Mon, 31 Aug 2009 23:35:08 +0800

> define what do you mean by that
I mean Mobile IPv6/DSMIP6/PMIP6 could behave normally without any problem.

-Hui

>>> was
>>> and

---

From: Hui Deng <[email-masked]>
Date: Tue, 1 Sep 2009 00:04:31 +0800

inline please

2009/8/30 marcelo bagnulo braun <[email-masked]>:
> "but today, please kindly help to let me know whose laptop, mobile, et al.
> today are IPv6 only,"
>
> So, if you apply the definition you quoted above and you plug your laptop in
> a network that is not providing IPv4 connectivity i.e. the network does not
> provides your laptop an ipv4 address, then your laptop is an ipv6 only node
> according to the definition above.
Here you state without IPv4 address is IPv6 only, then sometime it get Ipv4
address but without IPv4 connection is another kind of IPv6 only?
Anyhow, you are assuming that host is dual stack, but don't use it, then I would
like to question, why not use it?

> no, i think almost everyone has the same defintion
let me summary everybody said in the list.

http://www.ietf.org/id/draft-ietf-behave-v6v4-framework-00.txt
>     element is missing that prevents communication with IPv4 hosts.

http://www.ietf.org/id/draft-ietf-behave-dns64-00.txt
The dns64 draft also contains this statement in section 2:
> By
> IPv6-only hosts we mean hosts running IPv6-only applications, IPv6-
> only hosts, as well as the cases where only IPv6-only connectivity is
> available to the client.

Iljitsch van Beijnum
http://www.ietf.org/mail-archive/web/behave/current/msg06202.html

Cameron Byrne
http://www.ietf.org/mail-archive/web/behave/current/msg06279.html

if include what you said here, I don't see they have common.

Best regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Tue, 1 Sep 2009 00:05:48 +0800

some people suggest here NAT64 could understand RR message, and give
some response based on it.
then I assume they are putting mobilty agent inside NAT64.

thanks

-Hui

---

From: liu dapeng <[email-masked]>
Date: Tue, 1 Sep 2009 00:56:39 +0800

Hi Wassim,

I am wondering where does the HA locate?   it locate in the IPv6
network or in the IPv4 network? if it locates in the IPv4 network,
maybe the mobility protocol should be DSMIP instead of MIPv6, since
MIPv6 requries that HA is IPv6 capable.

BR,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Tue, 1 Sep 2009 01:00:27 +0800

> 3 modes (v6 only, v4 only, dual stack) without any user intervention.

If you called the laptop dual stack, why then saying that it is v6
only or v4 only, is't it confusing?

---

From: liu dapeng <[email-masked]>
Date: Tue, 1 Sep 2009 01:22:48 +0800

> in this case, you should be looking at dsmip

Hi maclelo,

According to your definition of IPv6 only host, my understanding is
that the host talked here is still  "IPv6 only", since it does not
have IPv4 connectivity.

dsmip solves the problems that the MN has IPv4 only access network, it
seems the scenario we discuss here is that the MN has IPv6 only access
network,right?

So in essence, it is the DNS64 that prevent the MN to know that
actually the CN is not an IPv6 host, which lead to the MIPv6 can not
work properly.

BR,
Dapeng Liu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 31 Aug 2009 22:30:11 +0200

> translated (as it is using a different prefix).

ah!
i think i understand what you mean.

If the MN uses the dns64 from the visited network and the NAT64 from the 
home networks, things may break (if the WK prefix is not used)

please note that this is not a problem only in mip. for instance, if you 
are connected to the IETF network but you still use the DNS server at 
you work, then if there is a nat64 in the ietf meeting wifi, it would 
fail in the same way (this is actually the reverse situation, you are 
using the local nat64 and the remot dns64)

The point is that you need to use the dns64 (i.e. the dns server) of the 
network that is running the nat64.

Now, there are several ways to address this problem if you use the LIR 
prefix

either you configure the MN to use the dns server from the home network,
either you use the dns64 in stub resolver mode (i.e. in the MN)

>> and i would appreciate a figure to understand it better.

It does, if what i understood is correct

As you say in the draft, NAT64 is a NAT, so we shouldn't be surprised if 
somethings break.
This seems to be one of these cases.

Maybe it would be important to explain this limitation in some of the 
the documents, not sure where though... suggestions?

Regards, marcelo

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 31 Aug 2009 16:40:39 -0400

Hi,

I am wondering where does the HA locate?   it locate in the IPv6
network or in the IPv4 network?

=> the home network is an IPv6 network which has its own NAT64 and DNS64.
Did I answer your question?

Regards,

Wassim H.

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 31 Aug 2009 16:56:49 -0400

Hi Marcelo,

> => First, am sorry for a possible confusion! But you cut the first
> part of the text! :) What I meant is that when the MN moves to a
> foreign network and decides to initiate a new session with a v4 CN
> then:
>
> b) the MN will try to reach the CN via BT mode but even in this case,
> it will ultimately fail because the packet won't reach the home NAT64
> in order to get translated (as it is using a different prefix).
>

ah!

If the MN uses the dns64 from the visited network and the NAT64 from the home networks, things may break (if the WK prefix is not used)

=> That's correct!

please note that this is not a problem only in mip.
for instance, if you are connected to the IETF network but you still use the DNS server at you work, then if there is a nat64 in the ietf meeting wifi, it would fail in the same way (this is actually the reverse situation, you are using the local nat64 and the remot dns64)

=> Sure. Am also suspicious about two other scenarios where things would break. Please correct me if am wrong:
- case of referral when the IPv6 address is a DNS64 reply and then the peer tries to connect using another interface, i.e., a different NAT64.
- case of callback when the IPv6 address is also a DNS64 reply and the peer decides to connect via another interface, i.e., a different NAT64.

The point is that you need to use the dns64 (i.e. the dns server) of the network that is running the nat64.

=> Agree.

Now, there are several ways to address this problem if you use the LIR prefix

=> Am not sure this approach is optimal.

=> IMHO, this is one way to tackle it.
>
>> If you are saying that the RO mode doesn't work, i agree with you as
>> i mentioned above. If you are saying that data packets are lost in BT
>> mode (when RO mode is not used at all), that i don't understnad the
>> scenario, and i would appreciate a figure to understand it better.
>>
>
> => Hope the above helps?
>

=> Yes you did! :)

As you say in the draft, NAT64 is a NAT, so we shouldn't be surprised if somethings break.
This seems to be one of these cases.

=> My point was/is that it *may* make sense to avoid re-defining "insanity" in behave WG! :)

Maybe it would be important to explain this limitation in some of the the documents, not sure where though... suggestions?

=> As you mentioned above, there are definitely other things that we'll break but we have thought enough about them. So IMHO, this one should be "at least" documented somewhere.

Regards,

Wassim H.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Aug 2009 22:34:38 +0000

Marcelo wrote:
[...]
> If the MN uses the dns64 from the visited network and the NAT64 from
> the home networks, things may break (if the WK prefix is not used)
>
[...]

+1

(I said the same thing to someone at IETF, but I forget who)

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Aug 2009 22:36:20 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Saturday, August 29, 2009 1:10 AM
> To: Hui Deng
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think there's a typo above.  I think you meant to say it doesn't
need to learn the prefix to support a non-validating security-aware
stub resolver (which is what Windows 7 supports, BTW).

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 31 Aug 2009 22:54:42 +0000

[quote below with typos mentioned in subsequent email corrected]
> but it doesn't have an ipv4 that it can use for the communication (in
> general it doesn't have a global ipv4 address)
[...]

"IPv6-only" is an adjective and can be used to describe a network,
a host, or an application.

The text in the framework doc says:

One problem with the above is that it confuses whether it's an adjective,
or a term "IPv6-only implementation" or an "IPv6-only end system" or
an "IPv6-only application".

One confusing property of the definitions is that it doesn't match
what a new person would expect.  In other words, if I have an
IP-version agnostic application, running on a dual-stack host,
which only gets an IPv6 address, then I would probably be surprised
to hear I have an "IPv6-only application", since this term is usually
taken to talk about capability, not how it's deployed.

Someone (Alain perhaps?) had terms "IPvX-capable" and "IPvX-enabled"
(or perhaps better "IPvX-connected") to distinguish between these
concepts, and I think part of the confusion is due to the loss of
this distinction.  I think people would expect that an IP-version
agnostic application would be "IPv4-capable" but not necessarily
"IPv4-connected".

Another confusing property is that the "connected" part may vary
by destination.  For example, if I have IPv4 connectivity to
those within the same net-10 as me, but no one else, am I
IPv6-only or not?  It depends on who you're trying to talk to,
and that concept is lost in the definitions as well.

-Dave

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 31 Aug 2009 18:37:16 -0600

> > the network that is running the nat64.

=> You mean if my home network is in Sydney and am in the US then I have
to use the cache server in Sydney instead of the local one so that I don't
break
NAT64 design?!

BTW, do you think you'll get the same DNS reply for any service than if you
query the local cache?

Wassim H.

_________________

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Sep 2009 11:28:31 +1000

> agnostic application would be "IPv4-capable" but not necessarily

=> It was all defined a million years ago in SIIT :) we should reuse these
definitions but we don't.

Hesham

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Sep 2009 01:49:51 +0000

Wassim Haddad wrote:
> Dave Thaler <[email-masked]> wrote:
>> Marcelo wrote:
>> [...]
> You mean if my home network is in Sydney and am in the US then I have
> to use the cache server in Sydney instead of the local one so that I don't break
> NAT64 design?!

No.  I mean you have two choices:
a) use the DNS in Sydney if you want to use your home address with
   the result,
b) use the DNS in the US if you _don't_ want to use your home address
   with the result (i.e. don't use MIP)

You can't mix them and expect anything to work.  DNS64/NAT64 doesn't
change this fact in any way.

> BTW, do you think you'll get the same DNS reply for any service than if you

I'm not sure which question you're asking, but the point is that
you can't use a DNS server on one network and then communicate on
a different network and expect it to work, unless you can guarantee
that both are using the public DNS namespace, since enterprises
and even homes often use private name spaces.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 31 Aug 2009 18:58:55 -0700

> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Sunday, August 30, 2009 8:27 PM
> To: Dan Wing; 'Hui Deng'; 'Simon Perreault'
> Cc: [email-masked]; Wassim Haddad
> Subject: RE: [BEHAVE] NAT64 and MIPv6
> 
> Hi Dan,
> 

Yes, referrals of IPv6 address literals will fail if the
referrals are between hosts on different networks and
those networks have different IPv6 prefixes for the 
two networks' IPv6/IPv4 translators.  However, those
applications are referring to IPv4 hosts (not IPv6
hosts) and based on my analysis in 
draft-wing-behave-nat64-referrals-00, existing applications
will do IPv4 referrals for three reasons:

  * IPv4 referrals to IPv4 hosts always work (as long
    as the IPv4 address is public!  See below).
  * IPv6 referrals to IPv6 hosts may fail (due to 
    different IPv6 prefix of the translator, as you
    pointed out).
  * IPv6 referrals to IPv4 hosts always fail (because
    IPv4 hosts can't speak IPv6.  Yes, we could imagine
    they can speak Teredo or 6to4, but then they aren't
    IPv4 hosts -- rather, they are dual-stack hosts.  
    This would mean adding IPv6 support to all of those
    IPv4 applications and hosts which won't happen on the
    Internet; maybe it could happen in a walled garden).
  * IPv4 referrals to IPv6 hosts can be made to work,
    *if* the IPv6 host can learn the prefix of the
    6/4 translator.  This is the case where 
    draft-wing-behave-learn-prefix is useful to help
    referrals.

Note that a similar problem occurs, today, on IPv4 networks 
when NATted IPv4 addresses are referred.  For example, if I 
refer you to 192.168.1.1 (which is behind my NAT) you 
won't be able to connect to that IPv4 address; you might
even connect to a host with that IPv4 address that is 
behind your NAT, and might even mistakenly think it is
my host.

On IPv4, applications such as BitTorrent and Skype have 
long resolved such IPv4 referral problems.  The IETF has 
created a standard ("ICE", draft-ietf-mmusic-ice) which supports 
smarter referrals in SIP.  The concepts in ICE have been used,
to varying degrees, by other protocols:
  * XMPP <http://xmpp.org/extensions/xep-0176.html>
  * HIP <http://tools.ietf.org/html/draft-ietf-hip-nat-traversal>
  * RTSP <http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08>

Going forward, Generic Referral Object (GRO) 
<http://tools.ietf.org/html/draft-carpenter-behave-referral-object-00> 
has been proposed to generalize how to do smarter 
referrals in various applications, and we have asked for 
a BoF in Hiroshima, 
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart, "GROBJ".

-d

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 31 Aug 2009 22:12:54 -0400

=> OK. This is what I meant.

=> As far as IP mobility is concerned, let's keep this one aside.

> BTW, do you think you'll get the same DNS reply for any service than if you

I'm not sure which question you're asking, but the point is that you can't use a DNS 
server on one network and then communicate on a different network and expect it 
to work, 

=> IMHO, if DNS64 and NAT64 were designed in a different way then none of the 
"new" rules you mentioned for mobility to work would have been needed! This of 
course would involve a "smarter" end host. OTOS, applying what you're suggesting 
does not mean necessarily that you won't need to modify the host!

Wassim H.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Sep 2009 12:25:06 +1000

> change this fact in any way.

=> An average user who wants to type youtube.com and get there would be able
to do that with MIPv6 and IPv6 only if youtube.com had a AAAA record
regardless of which DNS she queries. Furthermore, the same scenario would
work in a dual stack environment with DSMIPv6 regardless of whether a v4 NAT
is used or not, and it won't matter which DNS you query. So I think the
additional problem is in fact caused by NAT64.

Of course if I query a local name for my company's machine from another DNS
it won't work, but this is not the reference scenario to compare with IMHO.

At the very least any solution should highlight this as a requirement for
MNs because 3775 doesn't limit the DNS queries to the home DNS. But I don't
know how to do that if the presence of a NAT is not known to the host.

Hesham

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 31 Aug 2009 21:24:36 -0700

> additional problem is in fact caused by NAT64.

Regardless, NAT64 is an interim solution and anything that requires a
change to MN / end-host should be out of scope.  Other things that
should be out of scope include exotic protocols that are not
implemented in any major operating system (MIPv6).   If a user would
like to have  MIPv6 work, they should conspire through non-technical
means to communicate using IPv6 (i know paying for v6 is a novel
idea), because that is the end-state the MIPv6 designers had in mind.
If we make the middle-box so smart, we will never get rid of it.  Or,
it will never be done.

I want NAT64 in my network because it is a needed interim step, but i
don't want to stop the network evolution there.  I need IPv6
end-to-end to be realized (NAT64 does have an exit strategy), then
MIPv6 will work great (if your firewall does not break it).

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 01 Sep 2009 14:35:59 +1000

On 1/09/09 2:24 PM, "Cameron Byrne" <[email-masked]> wrote:

> change to MN / end-host should be out of scope.

=> Please read my text above, I didn't suggest host changes. First we need
to acknowledge an issue then figure out what to do about it.

  Other things that
> implemented in any major operating system (MIPv6).

=> Hmm, I think linux, BSD  and Symbian are pretty major but I guess you
disagree. 

  If a user would
> If we make the middle-box so smart, we will never get rid of it.  Or,

=> I have no idea what you're talking about or what you think MIPv6
desginers conspired to do. The point is there is a problem that first need
to be acknowledged instead of delving into irrelevant discussions.

> MIPv6 will work great (if your firewall does not break it).

=> That's fine, but you can't force everyone in the world to be in lock step
with your vision so things that break existing protocols should be
documented with a pointer on what IETF concensus is for the solution, or
lack of. 

Hesham

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Sep 2009 00:35:25 -0400

=> Your second paragraph is in violent contradiction with the first one regarding
MIPv6 and with your previous comments...

Regards,

Wassim H.