Just as note thus far with mipv6 testing and technology interoperation with other mipv6 vendors not one application has had to be altered to support mipv6 (e.g. ftp, telnet, streaming video/audio, sip, and a few others). Clearly they had to be ported to IPv6 but nothing special was done for mipv6. The above statement is for the server, router, and handhelds we are testing with at this time and putting in test labs deploying IPv6 in test beds. I don't see draft 19 from draft 18 as big deal either.
But I can see optimizations per Samita's comments below helping with very fast movement, and having socket options to set to affect that movement is quite smart and someone should proceed with the work (I can't to much IETF work now sorry). /jim [A people who would give up their freedom out of fear did not deserve it in the first place. Ben Franklin] > -----Original Message----- > From: Samita Chakrabarti [mailto:[EMAIL PROTECTED]] > Sent: Sunday, November 24, 2002 11:59 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Proposal for MIPv6 APIs to switch default source > address selection > > > > > > > > => in order to use the API, an application needs to be changed. So > > with only the API, the only way to influence the Co@/H@ > choice is to > > change all common applications... So the API will get only very > > limited use and the smart user should still wait for a device to > > fulfill his needs. > > > > Yes, the applications need to change to accomodate MobileIP. > The goal should be to change them minimally. Thus a API would > help in this case, as it may turn the knob to tell the kernel > which address to use instead of a default address. The > application may not need to specify the exact COA, the kernel > can choose the correct one corresponding to the default > homeaddress ( assuming application has knowledge about the > correct home address). This will be useful for multi-homed > mobile nodes as well. > > > they need to use COA for local cases in the visited link. > > > > => yes, all the short term not bound to the home applications could > > like to use a Co@. There are a lot of situations where to get > > communications killed by movements is not a problem... > > > > > It will not be desirable to restart common applications upon > movement, however small their numbers may be. Then we will > loose essence of MobileIP. > > > some existing apps would have to be modified or written for > > MIPv6 anyway. > > > > => we have to keep the number of such applications as low > as possible. > > > > I don't know how many apps fall in this category, may be we > should think about that. Off the top of my head, they could > be dns-client, printer-client, or any application that > requests service discovery in the local network. > > -Samita > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
