Tony, First of all, I think that connecting to the Internet MUST be madated, not optional :)
Having cleared that out, I have a couple of comments below. While I am willing to believe that > there are valid > reasons to make adjustments based on characteristics of the > link, this > document is fundamentally flawed because it is based around > the pretense > that small footprint devices are somehow special. We MUST NOT allow > ourselves to modify well thought out architectural > fundamentals based on > point-in-time engineering constraints that are dubious at best. => That's a bit inaccurate, there is a major difference that is due to the BW contraints of the air link. I see your points about size and memory, but it would be good if we identify the parts related to size and memory in which the draft deviates from IPv6 standards and distinguish them from the BW and l2-specific impacts. > The argument that small devices have limited processors or memory > overlooks the fact that the processor and memory of many hand-held > devices today is significantly greater than the > workstations that were > available when IPv4 was defined. Interesting point; there > was no problem > getting the stack and an array of applications to fit then. Another > interesting point; there are frequently rumors that laptops > will include > cellular interfaces, so where does the processing and > memory constraint > fit in that case? => It doesn't. But this is a classical argument which essentially says :'if you can't build it now, wait for a few years and you'll fit everything in'... well, as an engineer I don't have a major problem with that, but if I was someone who's trying to sell a wide range of products for different market segments, and some of those need to be limited in many ways to be sellable at all, then I would have a problem with this logic. Again, to be able to improve the quality of the draft, we need to point out *exactly* where the relevant problems are. Margaret did some of this already and it is being discussed. > > If a document on cellular requirements makes any sense, it has to be > based on differences in fundamental characteristics of the > air link, not > the device on either end. Avoiding DAD simply due to > expense is not a > valid justification, but if the loss characteristics of the > link make it > more problematic than valuable, there may be an argument. => The document does NOT avoid DAD. The document is aimed at a generic cellular host, and wherever applicable, makes an applicability statement on the 3GPP-specific cases. The reason DAD is not needed in 3GPP, is that the way an address is allocated leaves no room for on-link duplication. And still, the document does not say, you MUST NOT do DAD, it simply says that in *this* instance of a cellular network, DAD is not needed. So if you just want to implement it anyway, then go ahead. > Keep in mind > that doing so precludes the use of RFC3041 addresses, so the > applications where anonymity is most valuable (as one moves > around and > doesn't movement traced) are precluded. => This is not a problem and address privacy is already supported without the need for DAD. The 3gpp-advice draft, the cellular host draft and 3GPP TS 23.060 can provide the exact details. A non-zero probability of > collision requires a mechanism to resolve duplicates, and DAD is the > currently defined one. If another one exists that makes > more sense over > a lossy air-link, we should consider replacing DAD because it will > probably be more reliable in the general case as well. => It doesn't make sense if a host gets a /64 prefix that can not be used by anyone else on the cellular interface. Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
