(ngtrans) Dualstack Mobility

[[e-mail]]

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. 

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.


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

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.) 

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


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.)



Best regards,
Paal