Re: (ngtrans) Dualstack Mobility

[Shiao-Li Charles Tsao <[e-mail]>]

Hi Paal, 

Thanks very much for your comments. Please see some comment below...

----- Original Message ----- 
  From: [e-mail] 
  To: [e-mail] ; [e-mail] 
  Cc: [e-mail] ; [e-mail] 
  Sent: Wednesday, August 15, 2001 11:08 PM
  Subject: (ngtrans) Dualstack Mobility


  Hi George and Charles,


  Thanks for valuable discussions in London. I appreciated reading your dualstack-moving draft (draft-ietf-ngtrans-moving-00.txt) which gives a good analysis of the transition-mobility interaction problem. However, I have some comments that I hope you can clarify. Here are the most important ones:

  1) In the introduction you say that the document does not introduce new protocols or mechanisms. Later in the document you require to change existing Mobile IPv4 and Mobile IPv6 functionality: The home agents must me dual stack, must have globally routable IPv4 and IPv6 addresses, must advertise both IPv4 and IPv6 addresses etc. 

  Charles > We believe it is nature to assume IPv6 node with dual stack during IPv4 to IPv6 transition phase. That is why we assume our IPv6 home agent is dual stack. If one wishes to have dual stack MNv6 with IPv4/IPv6 mobility, the IPv6 home agent is required to have one more globally routable IPv4 address and has to advertise it. We don't change any protocols and mechanisms in existing IPv4, IPv6, MIPv4 and MIPv6. We just utilize what we already have in MIPv4 and MIPV6. 


  Generally, I don’t like the idea of changing existing IPv4 and IPv6 protocols for the sake of transition. First of all, if you require changes to existing IPv4 protocols it is probably going to hinder the transition process because it takes time to develop, implement, test and get deployed such changes. Secondly, if you require changes to IPv6 protocols, artifacts of the transition period is going to continue to live in IPv6 protocols even after the transition process has been completed.

  Charles > Yes, I agree. That is why we do not change or modify protocols or mechanisms in IPv4, IPv6, MIPv4 and MIPv6 in dual stack moving draft. Requirements defined in the draft are cofiguration or management changes. 

  2) I can see some problems with running MIPv4 together with DSTM TEP, as you suggest (2nd paragraph on page 8).  

  Charles > As George and I mentioned in Minneapolis meeting, this scenario (Dual Stack IPv4 roaming to IPv6 domain) is less important than the other case (Dual Stack IPv6 roaming to IPv4 domain). Dual Stack IPv6 roaming to IPv4 domain is more important and practical scenario . 

  a) First of all, the incoming IPv4 flow consumes two globally routable IPv4 addresses - both the permanent IPv4 home address by the home agent and a temporarily assigned IPv4 addresses by the TEP. (The scarcity of IPv4 address space is the main reason for converting to IPv6 in the first place.) 

  Charles > Yes. We regard this as one permanent IPv4 and one temporarily IPv4 CCoA. In this case, we have to use CCoA instead of using CoA via FA. Yes, we have to consume two IPv4 address in this case if you want to support duak stack IPv4 roaming to IPv6 domain. 

  b) Secondly, if the TEP multiplexes the flows on one global IPv4 address, on the other hand, as proposed in <draft-shin-dstm-single-ipv4-00.txt> you wont have this problem. However, then the mobile node is not permitted to move freely between two DSTM domains, because the port ranges might be different. (I guess the TEP must also read the port numbers from the IPv4-in-IPv4 packets that are tunneled from the home agent.)

  c) I think that the best solution is to skip the MIPv4 home agent in DSTM domains, and instead use the mechanism described in <draft-ietf-ngtrans-dstmext1-aiih-00.txt> together with some binding update scheme (as George initially suggested?)

  Charles > I am not quite sure about this point. Could you explain more ? If we skip MIPv4 HA, we can not have MIPv4 mobility. Of course, if we have MIPv6, we can offer MIPv6 mobility. 

  3) When the mobile node is in an IPv6 domain that does not support DSTM, you suggest to tunnel a MIPv4 registration request over IPv6 to the MIPv4 home agent (which is dual stack):

  Why should the home agent tunnel the packet back to your IPv4 CoA? If you have taken the step to make your home agent dual stack and have native IPv6 connectivity, why does not the home agent tunnel the packet back the same way. (draft-engelstad-mipv4-over-mipv6-01.txt treats this problem.)

  Charles > This is because HA is IPv4 HA not IPv6 HA. In this case, HA is dual stack but only implements MIPv4 HA functions. (If you assume HA is dual stack with both MIPv4 and MIPv6 functions. That will be another story). So, what MIPv4 HA has is the IPv4 CoA of the dual stack MNv4 (actually, MNv4 sent Reg. Req. to HA with this IPv4 CoA. MNv4 can not send IPv6 CoA to HAv4). So by definiation, HA has to tunnel the packet to IPv4 CoA, not IPv6 address(of course, HA can encapsulate the packets into IPv6 packets). It seems that I did not describe this scenario clearly, I will improve it in the next version. Thanks. 

  Thanks for your comments. 

  Charles