Having read through this thread now, might it be better to recast this document more along the lines of functions supported on the cellular interface rather than requirements for host? Some substantial number of devices for which this is targeted will be dual network interface capable and for the other interface some of these optimizations don't make sense.
The Mobile IPv6 related specifications for the time being only make sense with such a dual network interface capable device, which means the optimizations recommended on the cell facing interface in many cases SHOULDN'T be recommended on the other interfaces. > -----Original Message----- > From: Tony Hain [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 04, 2002 12:07 PM > To: [EMAIL PROTECTED] > Subject: Should connecting to the Internet be Optional? > Importance: High > > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
