Subject: Re: [BEHAVE] NAT64 and MIPv6

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Sep 2009 09:26:22 +0200

Dave Thaler escribió:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of marcelo bagnulo braun
>> Sent: Saturday, August 29, 2009 1:10 AM
>> To: Hui Deng
>> Cc: Wassim Haddad; [email-masked]
>> Subject: Re: [BEHAVE] NAT64 and MIPv6
>>
>> Hui Deng escribió:
>>     
>>> I am doubting that NAT64 doesn't change the host,
>>> 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.
>>     
>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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).
>   

right,
also that it needs to learn the prefix to support a validating stub 
resolver.

Regards, marcelo

> -Dave
>
>   
>> Regards, marcelo
>>
>>     
>>> -Hui
>>>
>>> 2009/8/28 Simon Perreault <[email-masked]>:
>>>
>>>       
>>>> 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.
>>>>>
>>>>> => Your comment does not help solve/avoid the problem!
>>>>>
>>>>>           
>>>> 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
>>>> --
>>>> DNS64 open-source   --> http://ecdysis.viagenie.ca
>>>> STUN/TURN server    --> http://numb.viagenie.ca
>>>> vCard 4.0           --> http://www.vcarddav.org
>>>>
>>>>
>>>>
>>>>         
>>> _______________________________________________
>>> Behave mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>>
>>>       
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>     
>
>
>

---

From: liu dapeng <[email-masked]>
Date: Wed, 2 Sep 2009 01:32:11 +0800

Thanks Wassim,

2009/9/1, Wassim Haddad <[email-masked]>:
> 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?

Then you mean the HA is located in the IPv6 netowrk if I understood it
correctly, right?

BR,
Dapeng Liu
> Regards,
> Wassim H.

---

From: liu dapeng <[email-masked]>
Date: Wed, 2 Sep 2009 01:35:46 +0800

2009/9/1, marcelo bagnulo braun <[email-masked]>:
> Wassim Haddad escribió:
>> Hi Marcelo,
>>
>> Thanks for the notes. Please see mine inline.
>>
>>
>>> 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.
>>>
>>
>> => OK
>>
>>
>>> 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.
>>>
>>
>> => 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.
>>
>>
>>> 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?
>>
>> => 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).
>>
>
> 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)
Hi marcelo,

You mean WKP prfix?

BR,
Dapeng Liu

> 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)
>
>>
>>> 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?
>>
>
> 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
>
>>
>> Regards,
>>
>> Wassim H.
>>
>>
>>
>

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 1 Sep 2009 13:48:43 -0400

Hi,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of liu dapeng
Sent: Tuesday, September 01, 2009 11:32 AM
To: Wassim Haddad
Cc: [email-masked]
Subject: Re: [BEHAVE] NAT64 and MIPv6

> Did I answer your question?

Then you mean the HA is located in the IPv6 netowrk

=> Which has its own NAT64 and DNS64.

if I understood it correctly, right?

=> That's correct.

Regards,

Wassim H.

---

From: liu dapeng <[email-masked]>
Date: Wed, 2 Sep 2009 02:20:13 +0800

Hi Wassim,

> if I understood it correctly, right?

Do you consider the scenario that the HA is located in the IPv4
network that behind NAT64 which may be DSMIP case?

Best Regards,
Dapeng Liu

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Sep 2009 20:21:16 +0200

>> home networks, things may break (if the WK prefix is not used)

i mean the WK prefix

---

From: liu dapeng <[email-masked]>
Date: Wed, 2 Sep 2009 02:40:14 +0800

>>> home networks, things may break (if the WK prefix is not used)

thanks marcelo, I think we mean the same thing here:)

---

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

Hi, 

> if I understood it correctly, right?

Do you consider the scenario that the HA is located in the IPv4 network that behind NAT64 which may be DSMIP case?

=> No actually, I did not consider this one. Can you explain more about it and where you see the problem?

Regards,

Wassim H.

---

From: liu dapeng <[email-masked]>
Date: Thu, 3 Sep 2009 02:31:51 +0800

> and where you see the problem?

Hi, Wassim,

The problem here is that if the HA is located in the IPv4 network
which is behind NAT64, The BU message will traverse NAT64, but NAT64
will not translate the IPv6 BU message to the corresponding DSMIP BU
message. this may cause a problem.

BR,
Dapeng Liu

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Sep 2009 12:45:34 +0200

On 31 Aug 2009, at 18:04 , Hui Deng wrote:

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

(Sorry for the delay.)

In my opinion, the thing that makes all the difference is a default  
route.

When we were doing the "IPv6 experiment" during the Philadelphia  
meeting, we had to find a workaround to make Windows XP hosts do DNS  
requests because they can't do those over IPv6. A good way to fix this  
is to give the host an IPv4 address on a subnet where there is a  
nameserver, so the machine can query the nameserver over IPv4.  
However, as there is no IPv4 default route, the system still tries to  
connect to non-local systems only over IPv6.

I know this is not the way all operating systems work with regard to  
IPv6. Because RAs themselves and prefixes in RAs have their own valid  
timers, you can either have an IPv6 address but no default route or an  
IPv6 default route and no address. I believe Windows (XP, at least)  
and Linux take the presence of the address to mean there is working  
IPv6, possibly because of the on-link assuption. (If you have no  
default you're supposed to treat the entire IPv6 space as on-link.  
This is a pretty bad idea, though.) However MacOS and BSD take the  
presence of a default route to mean that IPv6 is available.