> 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.
actually, I disagree, slightly. I think we designed these rules for general-purpose hosts and it's not necessarily a good idea to make them apply to fixed-function devices. if none of the applications on a host can make use of IPsec, and the host is inherently not configurable to set policy based on IPsec then I don't see why the host should have to implement IPsec. OTOH as soon as you make the host programmable, or make it possible to set policy on the host then it's worth considering whether IPsec should be a requirement again. similarly, a host that is strictly an endpoint and has no way of routing messages to other hosts doesn't need to support routing protocols. but as soon as the host can route messages to other hosts (such as via the data port of a cell phone) then it needs to be able to act as a router. (I also think the requirement to impose IPsec on hosts is of dubious value unless IPsec is usable by applications, but that's a separate discussion.) I think the cell phone requirements document would do well to break down the different cases: - cell phone with fixed functions vs. - cell phone that can host applications - cell phone that is strictly an endpoint vs. - cell phone that can provide net connectivity to other devices and examine requirements separately for each case. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
