> From: Robert Elz <[EMAIL PROTECTED]> > Date: Wed, 14 Aug 2002 14:24:44 +0300 > From: Markku Savela <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | - implementation requires more complex code > > I don't know how you reach that conclusion. The DAD approach is > simple to understand and to code ...
Yes, I guessed my claim would need some further explanations. "Complexity" can be somewhat subjective thing... > | I would propose following rules instead of do DAD on every address: > > And this is simpler than "do DAD on every address" ? Well, I tried be nice and thought to allow doing DAD on manually configured addresses. But, I can also define even simple rule that works (but, is "*really* strict ID for one node"): "regadless of address you configure, always do DAD on linklocal address using the ID-part of your address" Although, a bit longer statement, the implementation is surely at least as simple as the "do DAD on every address". Why do I think "do DAD on every address" is more complex: --------------------------------------------------------- You need to look under the hood to uncover the nasty bits... (1) By far the most displeasing fact is that, it has the "delayed failure mode": when the node comes online, it passes the DAD on link local, but there there is no guarantee that it remains fully functional later because - at any time later the link may require a use of a prefix (A=1) from RA, and when trying to make a global address with it, this can "legally fail". Node really cannot complain, it just need to have extra complexity of code to generate new id for that prefix. A node cannot decide on "autopilot" whether this is error or not. - compared to DIID, when node comes online (or an address is configured) and passes the DAD on link local, it guaranteed to be working with any announced prefix (A=1). Having to nodes trying for same link local is ALWAYS an error condition. Node does not need any additional logic for generating new ID's on RA's (although, it could, but it can also complain loudly on the error log about condition). That is, with "DIID" you can plug in a node (or configure an address) to a link and watch it autoconfigure in few seconds. If that passes, you can expect it to stay functional, with whatever prefixes the link will use now or later. (2) A minor issue, if your link has 1000 nodes doing "do DAD", a nasty node can generate nice traffic by fakin RA with multiple prefixes from different address (as every node will be doing DAD on every prefix*id combination). MINOR issue, because if bad guy gets this level access to link, you are hosed anyway... Anyway, with DIID, RA with any number of prefixes causes ZERO DAD probes. *************** Finally, the autoconfigure draft must be changed to allow only one choice. If people think "do DAD" is it, it can be implemented. It is just my opinion that DIID would be more simple. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
