[email protected] writes:
> Hi,
> 
> Very sorry for the late reply.
> 
> We have considered roaming VPN client scenario where MOBIKE may not
> be required,  

So you do not want to implement already standardized protocol to solve
the issue, and want to create new extension to solve partial issue? 

> NAT can be enabled or disabled any time due to administrative
> reasons. 

And how is that supposed to work.

If I have network described in the draft:

   +-+-+-+-+     +-+-+-+-+ IPsec    +-+-+-+-+
   |Roaming|     |Edge   | tunnel   |Corp   |     Protected
   | User  |<--->|Router |<========>|Gateway|<--> network
   +-+-+-+-+     +-+-+-+-+          +-+-+-+-+
         198.    198.   130.        133.
         51.     51.    233.        42.
         100.    100.   208.        11.
         22      1      1           1

I.e. Roaming user has public IP-address of 192.51.100.22, and its
default gateway is 192.51.100.1, and it uses that to connect to the
corporate gateway at ip-address 133.42.11.1.

The roaming user already has public routable IP-address which it can
use to connect to internet. What benefits you get by suddenly NAT:ing
it to some other public routable IP-address? The normal reason for NAT
is to provide ability to have multiple user sharing the same IP
address, but if roaming user already has public routable IP-address,
there is no need for that.

I do not really see what you are trying to do here, what is the reason
for this, and why it would ever be useful to add NAT for public
routable IP-address because of some adminstrative reasons? I.e. what
are those adminstrative reasons?

In normal case when you add NAT there in the middle, the roaming user
will loose its public IP-address, and then network will then be:


   +-+-+-+-+     +-+-+-+-+ IPsec    +-+-+-+-+
   |Roaming|     |Edge   | tunnel   |Corp   |     Protected
   | User  |<--->|Router |<========>|Gateway|<--> network
   +-+-+-+-+     +-+-+-+-+          +-+-+-+-+
         10.     10.    130.        133.
         1.      1.     233.        42.
         1.      1.     208.        11.
         22      1      1           1

and that is again the case which MOBIKE was specified to solve. 
-- 
[email protected]

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to