Hi Charlie, > I haven't studied the multi-link subnet draft. But, in order > to be responsive to your note before taking that time...
I guess we're just going to have to disagree about link-local vs. subnet-local. These are two distinct scopes and should be treated as such by the architecture. One shouldn't assume that because you can reach a node via a global address in the same subnet prefix as you that you can also reach it via a link-local address. "DIID" breaks this by making the false assumption that these scopes are equivalent. The whole point of multi-link subnet routers is to allow multiple links, of possibly different physical characteristics, MTUs, etc, to belong to the same subnet. And to do it in an architecturally consistent way. A multi-link subnet router is a real router that drops the hop count between links. It leaves link-local addresses as unique on their link, as it should. Maybe we should define unicast address prefixes for each scope as we have for multicast, so there would be subnet-local unicast addresses. That would allow people who want to do things on a subnet, rather than link, basis to do so. > And, please don't forget the negative impact on home agent operation. You would have the same problem with "DIID" if the mobile node has a large number of home addresses that differed in the IID part. As I noted in my earlier mail, there are plenty of creative proposals for using lots of IIDs per node, just as I suspect there are some for using lots of prefixes per subnet. Let's not break the architecture here over a optimization that has a lot of questionable assumptions in it. If we can't live with "DAD", then I'd much prefer we revise the whole duplicate address detection mechanism. Currently DAD has two serious flaws and one major inconvienience: It doesn't protect against duplicate addresses on reconnected networks (something I would think would happen a lot on some types of wireless links), it doesn't document a recourse to take when your only address is a duplicate (retry with a random address is the obvious solution, but that isn't standardized like EUI-64 is), and it takes longer than we would like. --Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
