The problem is that some of those devices have really limited memory and they already do (too?) many things, so there is no room left... Some vendors had to go back at their code and spend a lot of time and effort to clean things up to make room for the very basic IPv6 code, so every kb count.
The whole idea of asking them to do extra efforts to implement a functionality that is not needed and that will introduce bugs & instability is not very appealing. Again, this last argument applies also to devices that do not have memory problems: if I do not need functionality X, I'd rather like not to have it implemented as it will lower the operational risks. In other words, what functionality goes into a device is a business decision that is driven by the application considered. The node requirement document is a good place to say: if you want functionality X, here is what you have to do to make sure it interoperates well, it is not the place to make business decisions. If IPsec was used ubiquitously, I'd probably have another opinion. The reality is that today, IPsec usage is more the exception than the rule (at least in my environment), and I do not see this changing soon. - Alain. On 2/26/08 3:53 PM, "Nobuo OKABE" <[EMAIL PROTECTED]> wrote: > Hi Alan, > > Could you please show us detailed evidences > or something about your sugestion? > > We have raised the same kind of discussion at the very beginning of > Node Requirement activities (draft-okabe-ipv6-lcna-minreq-XX) about 2002. > > At that moment, the consensus was not to remove IPsec from standard > by the state of the art. At least, that was my understanding. > > Here are the record of that discussion: > http://www.taca.jp/internet-draft/feedback-01/summary.html > http://www.taca.jp/internet-draft/feedback-01/maillist.html > > Then, we have tried to develop IPsec solution > on small embedded devices with reasonable footprint/performance. > > Through our experience, precisely speaking, > heavy part is not IPsec body > but key exchange protocols, e.g. ike and ikev2, > if you can use cryptographic hardware (ex. AES and SHA1). > (and crypt h/w seems common for small embedded devices, today.) > > By our IPsec implementation experience on 16-bits CPU system, > object code size of IPsec body is not so big: > SADB handling + Inbound/Outbound IPsec processing = 8kbytes > > However, we gave up to implement ike and ikev2 on embedded devices > because of their complexity and the use of public-key crypt. > > Instead, we standardized Kerberos based IPsec key exchange protocol > as KINK (RFC4430) with cisco people. > Roughly speaking, KINK can be implemented with small footprint (45kbytes) > and reasonable processing time (70msec/exchange, w/o waiting time) > on 16-bits CPU system. > > The following paper shows some of data: > http://hiroshi1.hongo.wide.ad.jp/hiroshi/papers/2007/indin2007-Okabe.pdf > > I understand that our approach may be not universal but specific. > However, for me, your sugestion seems too rough to change the consensus. > I would be happy if I see your evidence. > > I hope that the records and the experiences described above > helps the discussion. > > Thanks, > > From: Alain Durand <[EMAIL PROTECTED]> > Subject: Making IPsec *not* mandatory in Node Requirement ( was Re: Updates to > Node Requirements-bis (UNCLASSIFIED)) > Date: Tue, 26 Feb 2008 13:41:37 +0800 > >> The latest draft: draft-ietf-6man-node-req-bis-00.txt >> still lists IPsec as mandatory to implement. >> >> As I mentioned last IETF meeting, this is creating a problem for certain >> kind of devices, like cable modems, who have a very limited memory >> footprint. Those devices operate in an environment where IPsec is not used >> and mandating its implementation has a serious cost: it means that legacy >> devices cannot be upgraded to IPv6... >> >> In DOCSIS 3.0, the decision was to NOT require IPsec implementation on those >> devices. I'm sure other environment have made or will make similar choices. >> >> Moreover, to make the point more general, we are specifying/buying many >> other types of devices where we know that IPsec will never be used. Why >> should the vendor of those devices have to implement it? Because one day I >> might decide to deploy it? IMHO, this is not a good think, because in the >> meantime, I will have to run extra code which means extra bugs, more memory >> and more risks of miss-configuration. >> >> I would like to suggest that the node requirements remove any mention of >> IPsec being mandatory to implement and instead includes text in the line of: >> "if you are going to implement IPsec, here is what you should/must do". >> >> - Alain. > > ----- Nobuo Okabe (Yokogawa Electric Corporation) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
