Margret has raised several valuable questions about draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not ready for last call. 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. If a device wants to participate as an Internet node, there are basic requirements. Of course, participating in the Internet is optional, so if a device would prefer to avoid the requirements, it may choose to create its own universe.
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? On the subject of applications, the absolute BS about limiting the application set to avoid an IPsec requirement is something that belongs in a product development discussion, NOT a standards discussion. The one point that should be clear is that over time the number of applications used via wireless (cellular or otherwise) will grow, and that we can't predict what they are, much less what they will need from the stack. To that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, applications will never be able to expect support, therefore will have to keep inventing their own mechanisms. The only way to prevent new applications from appearing on computing devices is to put the executable code in non-rewritable, non-replaceable, rom. 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. 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. 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. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
