Hi Michael: My take is that address ownership and uniqueness is a fundamental assumption of the IPv6 architecture and it must be ensured. The current ND does that at low cost. Basically similar to the cost of DHCP, with similar flows.
Pascal >-----Original Message----- >From: Stuber, Michael [mailto:[email protected]] >Sent: mardi 10 novembre 2009 05:41 >To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; [email protected] >Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >I realize that I'm new here, and I may be asking questions that have >already been hashed to death, but I confess I don't feel think that DAD >is appropriate on 802.15.4 mesh networks, unless the scope is limited to >the immediate neighbors. Imagine a PAN with hundreds of nodes trying to >form. > >I understand that this may run afoul of the v6 RFCs, but I believe the >idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I >believe this would be a reasonable adaption. I for one am willing to >give up mesh-wide DAD in this context. > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:[email protected]] >Sent: Monday, November 09, 2009 8:21 PM >To: Stuber, Michael; Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; [email protected] >Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: >4861 usage in LLNs] > >Hi Michael; > >To be very clear, I have nothing against using / optimizing DHCP in >LoWPAN. All the contrary. >A great item for rechartering I suspect. Just don't call it ND. > >Note that even if an address is obtained via DHCP, it has to be DADed >through ND. >And if a backbone is used, the address has to be proxied. Etc... > >IOW, DHCP is an alternate to SLAAC to get an address (and other stuff), >but the ND draft is still needed. >DHCP does not remove the need for ND, never did still does not. > >Pascal > >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On >Behalf Of Stuber, Michael >>Sent: mardi 10 novembre 2009 04:57 >>To: Kris Pister; Jonathan Hui >>Cc: Carsten Bormann; 6lowpan; [email protected] >>Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: >4861 usage in LLNs] >> >>Life may be getting better, but that doesn't mean we have the wrong >>target. Abandoning the installed base just goes to reinforce the idea >>that IP isn't an appropriate technology for things. Qualifications for > >>parts in appliances, meters, and cars may take much longer than in >other >>consumer electronics. There are lots of products shipping today with >>802.15.4 chips that do not match the (nicer) specs you outline below. >>If we want to enable IP everywhere, we must acknowledge that small >>footprint parts are an important part of "everywhere." >> >>That said, I too am in favor of exploring optimized DHCP. It would >>provide the flexibility of living in an edge router, or being >>centralized. It is a well defined, characterized protocol. >> >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On >>Behalf Of Kris Pister >>Sent: Monday, November 09, 2009 6:53 PM >>To: Jonathan Hui >>Cc: Carsten Bormann; 6lowpan; [email protected] >>Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: >4861 >>usage in LLNs] >> >>+1 in favor of using optimized DHCP if possible (no opinion on 'if >>possible'), rather than inventing something new. >> >>As I've shared with several people in private emails recently, it's >>pretty clear that lowpan nodes are going to get more capable moving >>forward, not less. Why? Radios don't scale down in area when you >scale >> >>CMOS processes. Today's 15.4 single-chip nodes are made in >technologies >> >>that are several (maybe five?) generations behind the cutting edge. >>This makes economic sense because the sales volumes don't support the >>need for expensive mask sets yet. >>When there's a volume application, and someone puts a 5mm2 radio into >>modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >>10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >>many tens of kB of RAM, and the radio will still be by far the biggest >>thing on the chip. >> >>Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >>not up to commercial standards - it's a five year old, expensive, >>academic platform - great for it's time, but old. Single-chip nodes >>from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit > >>processor, and they aren't made in cutting-edge processes yet either. >>Life is just going to get better. Let's try to find the smallest >>optimized set of *existing* protocols that serve our needs, that run on > >>the existing new low-cost hardware (not the old workhorses). Let's >>invent the absolute minimum of new "optimized" protocols, because it's >>not at all clear to me that we are optimizing the right things at this >>point. The less we invent, the broader the set of applications and >>applications programmers we address. >> >>ksjp >> >>Jonathan Hui wrote: >>> >>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>> >>>> Again, entirely getting rid of a function is always the best >>>> optimization. >>>> Can we do that for DAD? >>> >>> The *need* for DAD is the core question for me. As specified within >>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >>> protocol. That protocol looks and smells like DHCP - there's >>> request/response, lease times, relays. The whiteboard may also >>> administratively assign addresses. So in the end, it's not clear to >>> me why we would need to *detect* duplicates when we essentially >>> *avoid* them from the beginning. >>> >>> I've voiced my comment several times over the past 1+ years and >>> presented a draft that argues for the use of optimized DHCP in >Dublin, >> >>> so this is not new from my end. The fact that the current 6lowpan-nd > >>> document has evolved towards using DHCP-like mechanisms is not an >>> accident. But if what we do is DHCP-like, it would seem to make >sense >> >>> to utilize existing DHCP infrastructure rather than defining >something >> >>> new. >>> >>> -- >>> Jonathan Hui >>> >>_______________________________________________ >>6lowpan mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/6lowpan >>_______________________________________________ >>6lowpan mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
