>I am of the opinion that the scale of IPv6 deployment today is still >in its infancy and the impacts associated with mandating the HAO >processing on all IPv6 nodes is far less than maybe two years from >now.
Is that the point? My point was that the support of binding exchange and binding cache will be useless is several widely deployed configurations, example: - Web clusters - Appliances - Core routers ... You name it. On the other hand, having to support BU is not only additional code, it's also additional resources in constrained environments, and lower quality of service, since it may delay the establishment of the connection (I'm not sure that the draft is very clear about the use of the reverse tunnel while the RO is being established). It's also assuming that the trade off of having a binding cache is always preferable as opposed to other means of validating the HAO. The "always" is a "more often than not" at best, IMHO. Again, examples: - Trusted environment such as Intranet - BU piggybacking, or other means to sign every HaO, for CPU rich - memory poor environments such as load balancers and traffic splitters - Uselessness for attackers if application layer AAA is performed before any other process takes place (e.g. Web Server in a DMZ) I would not "MUST" a design point which degrades the performances of all modes of operation based on the assumptions on one. Pascal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 23, 2002 4:41 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated >>I am of the opinion that the scale of IPv6 deployment today is still >>in its infancy and the impacts associated with mandating the HAO >>processing on all IPv6 nodes is far less than maybe two years from >>now. > > here are a little (incomplete) list of RFC2460-compliant > implementations that does not speak/understand HAO: > > JunOS, ExtremeWare, MacOS 10.2, all FreeBSD since 4.0, all NetBSD > since 1.5, all OpenBSD since 2.7, Solaris beyond 2.7, Linux since 2.2, > all BSD/OS since 4.1. So are you suggesting that these OS' will have no revisions whatsoever in the future and they are now frozen forever? > and any product that ships with these operating systems (note that > many uses *BSD in embedded products such as printers). So every product that uses the IPv6 component of these OS' will not be compliant with the standard. These nodes can still operate just as well via the reverse tunnelling mechanism. I do not expect these nodes to be even upgraded to support the RR scheme as well. Thats just something we have to live with. > > and i would like to stress that it isn't matter of configuration, but > matter of codebase (you can't say "well, they are not configured with > IPv6"). and as you may aware, people do run older revisions of those > operating systems (there still are Win3.1, you know). I know. But you also have to realize that OS' evolve and new features are added. > > if it isn't enough to convince you otherwise, i think you are in > a dream world. There is an aspect of *tunnel vision* w.r.t your statement above. I realize there are commercial networks and commercial products running IPv6 that do not have HAO processing capability. But you are not looking at the potential scale of the nodes that are yet to be developed and deployed. > >itojun > Anyway, this argument is not leading to any conclusions. I would recommend that we move forward. Let the IESG decide if the HAO processing as MUST is too cumbersome for IPv6 nodes. -Basavaraj -------------------------------------------------------------------- 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] --------------------------------------------------------------------
