Agreed all the way through, Also:
- we have to consider HA and edge router cohabitation on a same link, since the 3775(bis) HA policy is not to give an address back without proper defense when the node comes back home. IOW, the HA policy is that the proxy wins against the real thing, a model that I pushed to change in the revision but failed to this point. - I have trouble to see PMIP in route over when the LoWPAN routers are actually very constrained as well, probably a lot more than a mobile device such as a palmtop that would use the LoWPAN as last resort communication medium. MIPv6 or NEMO seem a better fit in that case. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Zach Shelby >Sent: lundi 25 mai 2009 23:08 >To: Ricardo Silva >Cc: [email protected] >Subject: Re: [6lowpan] MIPv6 and 6LoWPAN (Ricardo Silva) > >Hi Ricardo, > >Thanks for reminding about your draft. A couple quick comments: > >- This model would require the edge routers to be aware of this "Micro >MIPv6" message format, and to provide the compression/decompression. >This means such a micro format would need separate standardization. > >- You should take draft-ietf-6lowpan-hc-05 (when posted) into account as >it will provide next-header compression for extension headers including >some of the optimizations needed by your draft. > >You might want to consider PMIPv6 and NEMO in your next draft, and how >proxy methods could be used first and foremost to avoid LoWPAN nodes to >get involved with MIPv6 at all. > >PMIPv6 and NEMO don't solve the problem of node mobility between domains >however, which would still require a LoWPAN node to speak MIPv6. > >Then again, it probably is just a reality that IPv6 addresses of LoWPAN >nodes will change upon inter-domain node mobility... and applications >will need to live with that. > >- Zach > >Ricardo Silva wrote: >> Dear All, >> >> I am sending our draft about mobility in lowPANs. It would be great if >> you could send me your feedback. >> >> https://datatracker.ietf.org/drafts/draft-silva-6lowpan-mipv6/ >> >> Best regards, >> >> Ricardo Mendão Silva >> >> Laboratory of Telecommunications and Telematic >> Department of Informatics Engineering >> University of Coimbra >> PORTUGAL >> >> >> On May 25, 2009, at 7:00 PM, [email protected] >> <mailto:[email protected]> wrote: >> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send 6lowpan mailing list submissions to >>> [email protected] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> or, via email, send a message with subject or body 'help' to >>> [email protected] >>> >>> You can reach the person managing the list at >>> [email protected] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of 6lowpan digest..." >>> >>> >>> Today's Topics: >>> >>> 1. MIPv6 and 6LoWPAN (Zach Shelby) >>> 2. Re: MIPv6 and 6LoWPAN (Julien Abeille (jabeille)) >>> 3. Re: MIPv6 and 6LoWPAN (Jong-Hyouk Lee) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Mon, 25 May 2009 16:16:27 +0300 >>> From: Zach Shelby <[email protected]> >>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>> To: 6lowpan <[email protected]> >>> Message-ID: <[email protected]> >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> >>> Hi, >>> >>> On a bit of a tangent... I have been studying different ways of dealing >>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >>> some mobility support for micro-mobility, which is good. Properly >>> designed applications can also deal with IP addresses changing. But what >>> if you would want to have a stable IP address for a 6LoWPAN node or a >>> stable prefix for a whole LoWPAN? >>> >>> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >>> - IP-in-IP encapsulation with the home agent >>> - Security for binding management messages >>> - Potentially large amounts of binding messages >>> Is anyone aware of work on MIPv6 proxy mechanisms which would allow e.g. >>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>> Maybe revive the Foreign Agent for IPv6? ;-) >>> >>> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >>> basic NEMO protocol is a perfect match, allowing an Edge Router or other >>> router in the visited network to act as a Mobile Router and perform >>> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >>> all LoWPANs under the router. I don't see route optimization to be >>> necessary for NEMO used with 6LoWPAN, the performance of traffic going >>> through the home agent should be fine. >>> >>> Thoughts? >>> >>> - Zach >>> >>> -- >>> http://www.sensinode.com >>> http://zachshelby.org - My blog ?On the Internet of Things? >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may contain >>> legally privileged information. If you are not the intended recipient, >>> please contact the sender and delete the e-mail from your system without >>> producing, distributing or retaining copies thereof. >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Mon, 25 May 2009 16:21:49 +0200 >>> From: "Julien Abeille (jabeille)" <[email protected]> >>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>> To: "Zach Shelby" <[email protected]>, "6lowpan" <[email protected]> >>> Message-ID: >>> <38f26f36eaa981478a49d1f37f474a8603210...@xmb-ams-33d.emea.cisco.com> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> Hi Zach, >>> >>> The issue with NEMO is that if nodes move from one router to another >>> (meaning the routers doing the nemo signaling), their address change. >>> NEMO is made to handle mobility of the whole network behind the router, >>> not individual nodes moving from this network to another. >>> >>> What you are probably looking for is Proxy Mobile IPv6 >>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >>> done by the netlmm working group >>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext >>> working group (http://www.ietf.org/html.charters/netext-charter.html). >>> >>> Best, >>> Julien >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Zach Shelby >>> Sent: lundi 25 mai 2009 15:16 >>> To: 6lowpan >>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>> >>> Hi, >>> >>> On a bit of a tangent... I have been studying different ways of dealing >>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >>> some mobility support for micro-mobility, which is good. Properly >>> designed applications can also deal with IP addresses changing. But what >>> if you would want to have a stable IP address for a 6LoWPAN node or a >>> stable prefix for a whole LoWPAN? >>> >>> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >>> - IP-in-IP encapsulation with the home agent >>> - Security for binding management messages >>> - Potentially large amounts of binding messages Is anyone aware of work >>> on MIPv6 proxy mechanisms which would allow e.g. >>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>> Maybe revive the Foreign Agent for IPv6? ;-) >>> >>> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >>> basic NEMO protocol is a perfect match, allowing an Edge Router or other >>> router in the visited network to act as a Mobile Router and perform >>> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >>> all LoWPANs under the router. I don't see route optimization to be >>> necessary for NEMO used with 6LoWPAN, the performance of traffic going >>> through the home agent should be fine. >>> >>> Thoughts? >>> >>> - Zach >>> >>> -- >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may contain >>> legally privileged information. If you are not the intended recipient, >>> please contact the sender and delete the e-mail from your system without >>> producing, distributing or retaining copies thereof. >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Mon, 25 May 2009 23:41:08 +0900 >>> From: Jong-Hyouk Lee <[email protected]> >>> Subject: Re: [6lowpan] MIPv6 and 6LoWPAN >>> To: Zach Shelby <[email protected]>, "Julien Abeille (jabeille)" >>> <[email protected]> >>> Cc: 6lowpan <[email protected]> >>> Message-ID: >>> <[email protected]> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Hi, all. >>> >>> NEMO scenarios within PMIPv6 domain have been presented in the following >>> document. >>> >>> http://tools.ietf.org/html/draft-jhlee-netlmm-nemo-scenarios-01 >>> >>> Hope you find useful scenarios for 6LowPAN. >>> >>> Cheers. >>> >>> On Mon, May 25, 2009 at 11:21 PM, Julien Abeille (jabeille) < >>> [email protected]> wrote: >>> >>>> Hi Zach, >>>> >>>> The issue with NEMO is that if nodes move from one router to another >>>> (meaning the routers doing the nemo signaling), their address change. >>>> NEMO is made to handle mobility of the whole network behind the router, >>>> not individual nodes moving from this network to another. >>>> >>>> What you are probably looking for is Proxy Mobile IPv6 >>>> (http://www.ietf.org/rfc/rfc5213.txt) and in general the work behing >>>> done by the netlmm working group >>>> (http://www.ietf.org/html.charters/netlmm-charter.html) and the netext >>>> working group (http://www.ietf.org/html.charters/netext-charter.html). >>>> >>>> Best, >>>> Julien >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of Zach Shelby >>>> Sent: lundi 25 mai 2009 15:16 >>>> To: 6lowpan >>>> Subject: [6lowpan] MIPv6 and 6LoWPAN >>>> >>>> Hi, >>>> >>>> On a bit of a tangent... I have been studying different ways of dealing >>>> with mobility of 6LoWPAN nodes and networks. Extended LoWPANs provide >>>> some mobility support for micro-mobility, which is good. Properly >>>> designed applications can also deal with IP addresses changing. But what >>>> if you would want to have a stable IP address for a 6LoWPAN node or a >>>> stable prefix for a whole LoWPAN? >>>> >>>> MIPv6 have several problems to be used directly by LoWPAN nodes, e.g.: >>>> - IP-in-IP encapsulation with the home agent >>>> - Security for binding management messages >>>> - Potentially large amounts of binding messages Is anyone aware of work >>>> on MIPv6 proxy mechanisms which would allow e.g. >>>> an Edge Router to proxy MIPv6 operations on behalf of a LoWPAN node? >>>> Maybe revive the Foreign Agent for IPv6? ;-) >>>> >>>> NEMO is much more clearly applicable to 6LoWPAN network mobility. The >>>> basic NEMO protocol is a perfect match, allowing an Edge Router or other >>>> router in the visited network to act as a Mobile Router and perform >>>> MIPv6 on behalf of the network. Thus maintaining constant prefixes for >>>> all LoWPANs under the router. I don't see route optimization to be >>>> necessary for NEMO used with 6LoWPAN, the performance of traffic going >>>> through the home agent should be fine. >>>> >>>> Thoughts? >>>> >>>> - Zach >>>> >>>> -- >>>> http://www.sensinode.com >>>> http://zachshelby.org - My blog "On the Internet of Things" >>>> Mobile: +358 40 7796297 >>>> >>>> Zach Shelby >>>> Head of Research >>>> Sensinode Ltd. >>>> Kidekuja 2 >>>> 88610 Vuokatti, FINLAND >>>> >>>> This e-mail and all attached material are confidential and may contain >>>> legally privileged information. If you are not the intended recipient, >>>> please contact the sender and delete the e-mail from your system without >>>> producing, distributing or retaining copies thereof. >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>> >>> >>> >>> -- >>> Internet Management Technology Lab, Sungkyunkwan University. >>> Jong-Hyouk Lee. >>> >>> #email: jonghyouk (at) gmail (dot) com >>> #webpage: http://hurryon.googlepages.com/ >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> <http://www.ietf.org/mail-archive/web/6lowpan/attachments/20090525/29c28f21/attachment.htm> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> End of 6lowpan Digest, Vol 52, Issue 18 >>> *************************************** >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > >-- >http://www.sensinode.com >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >This e-mail and all attached material are confidential and may contain >legally privileged information. If you are not the intended recipient, >please contact the sender and delete the e-mail from your system without >producing, distributing or retaining copies thereof. >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
