Re: DAD vs. DIID
In your previous mail you wrote: Always do DAD, no optimisation allowed, is the best approach. => I fully agree and I'd like to see according specifications updated ASAP. Regards [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
a clarification... > Yes, in this case if two nodes happen to have same id, doing DAD on > all addresses would detect the collision. But, you are hosed anyway, > as those same nodes are also using the same link local address (they > have same id, they are on same link => both have fe80::id, and > Neighbor discovery breaks totally for them...). Naturally, if the id=1 is not used in autoconfiguration, then there is no problem, since neither host combines the announced prefixes with this particular id. 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]
Re: DAD vs. DIID
> From: Robert Elz <[EMAIL PROTECTED]> > > | The main fact is that my version is just an implementation based on > | the autoconfigure RFC, taking the allowed DAD optimization (= do DAD > | on link-local, combine id with announced prefixes without doing DAD on > | those combinations). > > The problem is that this only works if no-one is allowed to create > addresses that don't have link local - otherwise the order in which > the addresses are created makes a race condition wrt DAD. It can be made to work, if those who want to define addresses without corresponding link local, take care of not tresspassing the addresses generated by autoconfigure process. I listed some examples of approaches. "DIID" or equivalent is one possible apporach, but I'm not proposing proposing that. I just want to keep the autoconfigure DAD optimization as allowed. Other address configuration MUST take that into account. > Obviously you can define "abnormal" so as anything affected fits, but > certainly KAME (and I suspect Microsoft) would need to change, as it > allows addresses that aren't based upon a LL address to be defined. Yes, my stack allows defining any address manually. I don't code programs that pretend to be more clever than the user. I assume if the user wants some specific address, then he/she will get it (if it passes DAD). In manual configuration I assume user KNOWS from that the address will not collide with autoconfigured (as a root you can always shoot your foot). > Such addresses are subject to DAD, so that's OK, they won't be duplicates, > but the IID part isn't defended against attempts to re-use it in other > addresses (different prefix). I'm not proposing defending plain ID part (that is just an option that is available). > On the other hand, DIID forbids subnets being merged into one link, if > they happen to have nodes assigned with the same IID (like "1"). There > is no problem with uniqueness of the addresses, the prefixes differ, but > because the IIDs don't, DIID would prohibit them from being used on the > same link. If you have two subnets with different prefixes. Apparently you then have a router on both subnets which announce their prefixes. When you merge the subnets, ALL nodes will see both routers and will autoconfigure both prefixes with all of their addresses. Yes, in this case if two nodes happen to have same id, doing DAD on all addresses would detect the collision. But, you are hosed anyway, as those same nodes are also using the same link local address (they have same id, they are on same link => both have fe80::id, and Neighbor discovery breaks totally for them...). 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]
Re: DAD vs. DIID
Date:Thu, 22 Aug 2002 00:46:24 +0300 From:Markku Savela <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The main fact is that my version is just an implementation based on | the autoconfigure RFC, taking the allowed DAD optimization (= do DAD | on link-local, combine id with announced prefixes without doing DAD on | those combinations). The problem is that this only works if no-one is allowed to create addresses that don't have link local - otherwise the order in which the addresses are created makes a race condition wrt DAD. | Some want to disallow the DAD optimization. I would like to present | another proposal: | | | leave autoconfigure basicly RFC as it is now | That doesn't work. Something has to solve the problem that has been identified. | I think autoconfiguration should be the normal mode how IPv6 nodes get | their addresses. Autoconfiguration has always been planned as just one way that addresses can be allocated. It may turn out to be the most common, but it certainly shouldn't yet be being elevated to the status of being the "normal" way. | - just hope you are lucky Well, I'm not sure if you were in Yokohama, but Steve Deering started to make a proposal along those lines. It was going to be essential if the DIID proposal was adopted (I'll let Steve explain it, and why, if he feels inclined) - it kind of just fell by the wayside, when DAD was preferred by just about everyone in the room. | Choosing this does not require a change in any stacks that do DAD on | all addresses (KAME, Microsoft). It only affects abnormal address | configurations. Obviously you can define "abnormal" so as anything affected fits, but certainly KAME (and I suspect Microsoft) would need to change, as it allows addresses that aren't based upon a LL address to be defined. Such addresses are subject to DAD, so that's OK, they won't be duplicates, but the IID part isn't defended against attempts to re-use it in other addresses (different prefix). They would need to change. It is true that there's a tiny chance that when a new prefix is advertised, a node will fail to be able to assign it, because some other node had already assigned itself that prefix with the node's IID (the chance of this in reality seem about as great as the chances of duplicate 3041 addresses, assuming good random number generators, but never mind). DIID would avoid that tiny possibility. On the other hand, DIID forbids subnets being merged into one link, if they happen to have nodes assigned with the same IID (like "1"). There is no problem with uniqueness of the addresses, the prefixes differ, but because the IIDs don't, DIID would prohibit them from being used on the same link. I know which of those I believe is the more likely to actually happen in practice, and which is the more serious if it does happen - and it isn't the first in either case. kre 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]
RE: DAD vs. DIID
> > but > > we shouldn't pretend that "subnet-local" multicast is possible, since > > it isn't. > >"Subnet-local" multicast is indeed possible. >"Network-prefix-local" multicast is not possible. While I'm not sure that I agree with the terminology, since this is a change from the common use of the word "subnet", and doesn't really agree with the use of the term "subnet ID" in the addrarch, I now understand your distinction. I don't think that we should overload the term "subnet" in this way, so we should probably change one of these terms. Using your terminology (I hope)... A "subnet" is defined to be a scope that encompasses one or more links. It can be as small as a single link, or as large as a whole site. The definition of a "subnet" is not related to how network prefixes are configured on those links and/or nodes. In particular, it has no special relationship to the "subnet ID" of a unicast address. In IPv6, we have the ability to send subnet-local multicast traffic, but not subnet-local unicast traffic. The point of "multi-link subnets" (let me know if I'm wrong) is to allow a network prefix to span multiple links. So, really, we are talking about "multi-link network prefixes", not subnets at all. In order to make "multi-link network prefixes" work properly with mechanisms such as DAD and RA, we need to forward certain link-local multicast packets between those links. This makes "multi-link network prefixes" more messy and complex than they would be if they'd been planned into the architecture from the beginning. Folks have discussed the fact that subnet-local multicast addresses should really have been used for DAD, RA, etc. But, this doesn't necessarily make sense. If you buy-in to the concept of "multi-link subnet prefixes", you'd want these messages to span all of the links that are intended to share a set of network prefixes. It isn't clear to me that this is the same set of links that would comprise a single multicast subnet, but you could probably define it that way, if desired. But, even if it would help to use subnet-local multicast, we couldn't change this now for two reasons: 1 - These mechanisms are already widely implemented using link-local multicast addresss. 2 - We haven't defined the equivalent of a subnet-local all-nodes multicast address and/or a subnet-local solicited-nodes multicast address. So, we don't currently have the means to reach the right sets of nodes at the subnet-local scope. The addrarch, ND and autoconf RFCs currently make the architectural assumption that a full unicast network prefix (site-local and/or global prefix PLUS subnet ID) will only span a single link, which is, apparently, in no way related to what scope a subnet-local multicast packet will span. Do you agree? So, really, the question is: Do we want to modify the IPv6 architecture so that a single unicast network prefix can span more than one link? By definition, a subnet already spans multiple links. Margaret 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]
Re: DAD vs. DIID
Date:Wed, 21 Aug 2002 08:31:32 -0700 From:"Charles E. Perkins" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | As I tried to point out | in my previous message, IP doesn't have any business | messing around with details about how the subnet is | actually constructed. I think there's a chasm between uses of the term "subnet" occuring here. The subnet in the sense that is bring proposed in multi-link-subnets is something that's being defined by the IP layer - IP has never used the term in the ISO sense, that's what "link" means. As I understand it, here a "subnet" is simply "the collection of nodes that can be addressed using the same prefix" (where that prefix is not an aggregate of others). That is, one might define prefix::/64 and address a collection of nodes out of that prefix, that's the subnet. Traditional IP has said that the nodes so addressed all have to be connected to the same link. But that's certainly for the IP layer to define, it isn't fixed in concrete by someone else. Whether that traditional definition should be changed or not is the topic of the multi-link-subnet draft (I think) - and I'm not taking a position on that here - but we certainly need to make sure that we're all using the terminology the same way. kre ps: there is absolutely no need to have a concept of "subnet local" addressing, or scope, in order to make any of this work, if making it work was to happen. 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]
RE: DAD vs. DIID
On Wed, 21 Aug 2002, Dave Thaler wrote: > > Besides, > > as Pekka pointed out, none of the nodes on the link will have joined > > the subnet-local multicast group, so the traffic actually won't reach > > any of them. > > Eh? It will reach all of them, ^ > and will be received by the IPv6 layer > as long as it has joined the group. If it hasn't joined the group, then > it's not supposed to be received by that node. That's why it's called > multicast, not broadcast. Please compare this to your message a few days back (and remember the context of all-nodes -multicast addresses): >> So, while you indicate that a link-local address may not be able to >> reach all nodes on a subnet, isn't it also true that a subnet-local >> address may not be able to reach all of the nodes on a link? [...] > The answer is yes it will (so the answer to your > question is: no, not true). If all nodes in the subnet have not joined the subnet-local multicast group, all nodes in the subnet will not be reachable through it. There's some bad miscommunication here. Therefore if you specify "all-nodes-in-subnet" multicast address, it is completely useless for that purpose unless you create some very dirty hacks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
RE: DAD vs. DIID
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] [...] > I'm not talking about the limited way in which the "subnet-local" > multicast scope works today, but about the definition of a subnet. > > The word "subnet" means a group of nodes that share a common global > prefix, including subnet ID. The fact that we don't have a multicast > mechanism to successfully reach this group of nodes doesn't change > the definition of "subnet". > > So, a subnet may include all of the nodes on a single link -- this will > be the most common case, where all of the nodes are generating addresses > from a single set of RAs. > > A subnet may also include a subset of nodes on a single link, if there > is more than one prefix in use on the link, and not all nodes use all > of the prefixes. All of them have interfaces in the subnet scope zone, regardless of whether or not they use addresses in the subnet prefix. > Iff we adopt the multi-link subnet proposal, a subnet may also include > a set of nodes that share a subnet prefix across multiple links. Still > without any requirement that the subnet contain all of the nodes on > each link. But still true that all of those nodes have interfaces in the subnet scope zone regardless of what addresses they have. > I agree that it would be quite tricky to use an IPv6 multicast address > to reach a particular subnet, given how multicast addresses are > constructed. There is no way for a given node to determine whether > a subnet-local multicast is intended for any of its subnets. I disagree. Nodes don't have subnets, nodes have interfaces and addresses. There is a way for a given node to determine whether a subnet-local multicast is intended for any of its interfaces, which is that it's intended for it if the node has joined that subnet-local multicast address on a given interface. > Besides, > as Pekka pointed out, none of the nodes on the link will have joined > the subnet-local multicast group, so the traffic actually won't reach > any of them. Eh? It will reach all of them, and will be received by the IPv6 layer as long as it has joined the group. If it hasn't joined the group, then it's not supposed to be received by that node. That's why it's called multicast, not broadcast. > IPv4 did have a concept of subnet-local broadcast (i.e. 128.224.4.255), > but the ability to address all of the nodes on a single subnet is > apparently lacking in IPv6. I don't consider this a big problem, Here we agree in concept, but I would nitpick with your terminology. IPv4 does not have a concept of "subnet-local" (as defined by the scoped Addrarch) broadcast, it's really network-prefix-local broadcast, and IPv6 doesn't have such a thing. > but > we shouldn't pretend that "subnet-local" multicast is possible, since > it isn't. "Subnet-local" multicast is indeed possible. "Network-prefix-local" multicast is not possible. -Dave 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]
RE: DAD vs. DIID
> From: Charles E. Perkins [mailto:[EMAIL PROTECTED]] [...] > As I wrote before, but perhaps buried in other text, > I think that IP should only be concerned about the > "subnet-local" concept, not the "link-local" concept, > if we are to use those terms as distinguishable concepts. > When the link-local addresses were being first discussed, > I don't remember any discussion that suggested that a > "link" should have a different extent than a "subnet". > > It seems to me that all IP-level protocols need to > have "subnet-local" addressing, not the newer proposed > definition for "link-local". It's defined today as non-routed. You're proposing to route link-local addresses, so you're the one with the "new proposed definition" :) > As I tried to point out > in my previous message, IP doesn't have any business > messing around with details about how the subnet is > actually constructed. Here we disagree. A multi-link subnet router does that (as do IPv4 ARP proxies today, for that matter). > Thus, to restate, I believe that "link-local" addresses > are not required to traverse the entire extent of the > physical medium on which a subnet is defined, then they > are useless for IP protocols. Could not parse the above. Maybe you meant "I believe that IF ..."? ^^ > Perhaps it would be > better to rename these addresses (FE80::/10) to be > called "subnet-local". That's what your position boils down to, yes. (I pointed this out on this list prior to last IETF.) At this point I am undecided on this issue, other than deciding that if fe80::/10 is not subnet-local, DAD is cleaner than DIID. > Do you have examples of protocols that properly use > "link-local" addresses instead of "subnet-local" > protocols? It seems to me that DAD, multicast, > router advertisements, and Mobile IP all need to > have the "subnet-local" property, and I can't think > of any network-layer use for the non-network-layer > definition of "link-local". For unicast link-local addresses, I can't either right offhand, although I can't say one might not exist. I agree that DAD on *non-link-local* addresses needs to have the subnet-local property, but unfortunately DAD is currently defined using multicast scope 2 rather than 3 as it should have been. This means workarounds are required, but this is orthogonal to whether fe80::/10 should be left as link-local or changed to be subnet-local. -Dave 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]
Re: DAD vs. DIID
> From: Thomas Narten <[EMAIL PROTECTED]> > > Note: one thing we could all be better about is defining just what > "DAD vs. DIID" means. I had my implementation before the term "DIID" was coined. I suppose, in the effect, if I have the "id defense mode" turned on, it is very close. The main fact is that my version is just an implementation based on the autoconfigure RFC, taking the allowed DAD optimization (= do DAD on link-local, combine id with announced prefixes without doing DAD on those combinations). Some want to disallow the DAD optimization. I would like to present another proposal: leave autoconfigure basicly RFC as it is now Autoconfigururation deals only with an ID that is assigned to host and is combined with announced prefixes (A=1). If host does this, it must do DAD on link-local and doing DAD other addresses based on same ID is not required. I think autoconfiguration should be the normal mode how IPv6 nodes get their addresses. Anything else is to be treated *exceptional*, and such other mechanisms have to define their own ways of avoiding address collisions. For example, - if address is not link local, they could do DAD on corresponding link local, or - they could assign the ID from a range that is not used by the autoconfigure (put asides id range 1-1024 or somesuch for the purpose). - they guarantee that the prefix part of the address is never announced on the link with A=1 (this also guarantees that address never going to collide with autoconfigured addresses). - just hope you are lucky - etc. I have explained in other messages, that the "Do DAD on every combined address" has some unpleasant features, caused by the "delayed fail mode". This adds complexity, compared to the "optimized DAD", where you do it once, and if passed, you don't have to worry about it. Choosing this does not require a change in any stacks that do DAD on all addresses (KAME, Microsoft). It only affects abnormal address configurations. 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]
Re: DAD vs. DIID
"Charles E. Perkins" <[EMAIL PROTECTED]> writes: > When the link-local addresses were being first discussed, > I don't remember any discussion that suggested that a > "link" should have a different extent than a "subnet". Note: the term "subnet-local" has a specific meaning with regards to multicast. Subnet-local != link-local (per addrarch). For unicast, things are less clear. That is, for unicast, there is link-local, site-local, and global. That's it. There is no "subnet-local" definition per se (note that RFC 2460 does not define the term "subnet"). My assumption has been that when folks talk about scoping, they generally assume the scope boundaries for unicast and multicast are the same (i.e., site-local multicast corresponds to a site in unicast). This may not be a requirement per se, but I would think that having two different notions of what the "site" boundaries were would at best be confusing. But looking at addr-arch, I see it contains the wording: > Currently IPv6 continues the IPv4 model that a subnet prefix is > associated with one link. Multiple subnet prefixes may be assigned > to the same link. So this could lead one to conclude that unicast "subnet" means "link". And link has a *very* specific meaning (per 2460): link- a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernets (simple or bridged); PPP links; X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. So, per the current specs, I conclude that in the case of unicast, "subnet" is equivalent to "link". Personally, I much prefer that "link" be used then because it's much more precise, and because "subnet" in multicast terms is different than "subnet" in unicast terms. This is confusing. > Do you have examples of protocols that properly use "link-local" > addresses instead of "subnet-local" protocols? It seems to me that > DAD, multicast, router advertisements, and Mobile IP all need to > have the "subnet-local" property, and I can't think of any > network-layer use for the non-network-layer definition of > "link-local". I think we are in agreement so long as "subnet-local" == "link-local". Again, I think it would be better to stick with the latter terminology, as it is more clearly defined, and at present, the two terms seem to be equivalent. If you look at the revised addr-arch document, however, it contains the words: 2.7 Multicast Addresses ... subnet-local scope is given a different and larger value than link-local to enable possible support for subnets that span multiple links. But this leaves open the question about whether "subnet" == "link" is really still supposed to be the case with unicast addresses. Thomas 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]
Re: DAD vs. DIID
Hello Brian, As I wrote before, but perhaps buried in other text, I think that IP should only be concerned about the "subnet-local" concept, not the "link-local" concept, if we are to use those terms as distinguishable concepts. When the link-local addresses were being first discussed, I don't remember any discussion that suggested that a "link" should have a different extent than a "subnet". It seems to me that all IP-level protocols need to have "subnet-local" addressing, not the newer proposed definition for "link-local". As I tried to point out in my previous message, IP doesn't have any business messing around with details about how the subnet is actually constructed. Thus, to restate, I believe that "link-local" addresses are not required to traverse the entire extent of the physical medium on which a subnet is defined, then they are useless for IP protocols. Perhaps it would be better to rename these addresses (FE80::/10) to be called "subnet-local". Do you have examples of protocols that properly use "link-local" addresses instead of "subnet-local" protocols? It seems to me that DAD, multicast, router advertisements, and Mobile IP all need to have the "subnet-local" property, and I can't think of any network-layer use for the non-network-layer definition of "link-local". Regards, Charlie P. Brian Zill wrote: > > 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]
Re: DAD vs. DIID
Markku Savela <[EMAIL PROTECTED]> writes: > As a consequence, and observing that others may not have chosen this > tactics, the code also defends plain ID, that is: if it sees a DAD for > address which contains one of my ID's, it will reply to the DAD as if > I had the address. I don't see any catastrophic failures resulting > from it. But I assume we are all in agreement that this is not supported by any of the relevant specs. It is not necessarily forbidden by any spec, but it is not suggested that this be done in any spec. Yours is the first implementation that I've heard that has done this. Note: one thing we could all be better about is defining just what "DAD vs. DIID" means. Some people seem to think that that DIID means "for every address, also create a link-local address and run DAD on it too." This in general, will achieve DIID. But this is not required by the specs today, and folks have consistently objected that requiring every address also be assigned a corresponding LL address is being unreasonable. There are also other ways of achieving DIID. There is also Markku's variant. One could also imagine modifying ND so that comparisons were done on the IID part alone (in some or all cases). But this has the issue of possibly not being backwards compatable with existing implementations. Some also seem to be saying (???) that if one runs DAD on all addresses, that's DIID. But I don't think so. That just means you are doing DAD on all addresses. You can still end up with different nodes using different addresses but sharing an IID (I'm not saying this is necessarily good/desirable, but it is not ruled out). So for those who are advocating some sort of DIID, please be very clear about what it is you are calling for. Just saying "I'm for DIID" isn't specific enough. Thomas 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]
Re: DAD vs. DIID
> The whole issue comes from the introduction of "privacy" and generated > addresses. Actually, not so. The issue can also comes up with DHCP-assigned addresses. Thomas 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]
RE: DAD vs. DIID
Hi Dave, I'm not talking about the limited way in which the "subnet-local" multicast scope works today, but about the definition of a subnet. The word "subnet" means a group of nodes that share a common global prefix, including subnet ID. The fact that we don't have a multicast mechanism to successfully reach this group of nodes doesn't change the definition of "subnet". So, a subnet may include all of the nodes on a single link -- this will be the most common case, where all of the nodes are generating addresses from a single set of RAs. A subnet may also include a subset of nodes on a single link, if there is more than one prefix in use on the link, and not all nodes use all of the prefixes. Iff we adopt the multi-link subnet proposal, a subnet may also include a set of nodes that share a subnet prefix across multiple links. Still without any requirement that the subnet contain all of the nodes on each link. I agree that it would be quite tricky to use an IPv6 multicast address to reach a particular subnet, given how multicast addresses are constructed. There is no way for a given node to determine whether a subnet-local multicast is intended for any of its subnets. Besides, as Pekka pointed out, none of the nodes on the link will have joined the subnet-local multicast group, so the traffic actually won't reach any of them. IPv4 did have a concept of subnet-local broadcast (i.e. 128.224.4.255), but the ability to address all of the nodes on a single subnet is apparently lacking in IPv6. I don't consider this a big problem, but we shouldn't pretend that "subnet-local" multicast is possible, since it isn't. Margaret At 07:37 PM 8/20/02 , Dave Thaler wrote: > > -Original Message- > > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] >[...] > > So, while you indicate that a link-local address may not be able to > > reach all nodes on a subnet, isn't it also true that a subnet-local > > address may not be able to reach all of the nodes on a link? > >Since the boundary of a zone goes through a node, not through a link >(ref: scoped addr arch doc), then no it is not true. The "subnet-local" > >scope contains all interfaces on the link regardless of what addresses >are on those interfaces. > >However, there are no subnet-local unicast addresses (only multicast >ones) >so the question is moot in practice. The closest question you could >construct in practice is: "If a link has multiple subnet prefixes >assigned to it, and I source from a global address in one of them, and >the destination is a subnet-local multicast group, will another machine >on the same link, which does not have an address in the same prefix, >receive the packet." The answer is yes it will (so the answer to your >question is: no, not true). > >-Dave 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]
Re: DAD vs. DIID
Date:Tue, 20 Aug 2002 16:41:05 -0400 From:Margaret Wasserman <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | What surprised me is the assumption that a subnet scope would be "larger" | than a link-local scope. I've had experience running multiple subnets | on a single L2 link, but I have not had experience running a single | subnet across multiple L2 links. Let me try to answer this a different way. That is, while it is certainly possible to run multiple subnets over an L2, this doesn't make them have smaller scope than the L2. The nodes that are only in one of the subnets are that way by choice - they could be in any of them. Any packet on the link is available to all of the nodes connected to it (this is more or less the canonical definition of the link layer). So, you can't be connected to a link and be in a smaller scope, unless you're looking inside L2 (or lower) protocols, at L3 and above, the link is the basic unit. | So, while you indicate that a link-local address may not be able to | reach all nodes on a subnet, isn't it also true that a subnet-local | address may not be able to reach all of the nodes on a link? So, no, it is able to - though it may be that some of the nodes might not choose to receive it. On the other hand, a multi-link subnet (which as a concept takes some grasping, I'm not yet sure I'm convinced of the need) binds multiple links (unitary objects) into one L3 object. Here it is clear that it is possible to have internal divisions, and that one link would be a smaller thing than than a subnet. On the other hand, I'm not sure that I would treat the needs of multi-link subnets as being compelling enough to prefer DAD over DIID if there were other compelling arguments in favour of DIID. That's because I'm not sure I see multi-link as all that compelling without this extra issue. But, here I don't see compelling arguments for DIID, if anything, even without multi-link DAD seems like a better choice. Given that, then that DAD also doesn't shut the door on multi-link is just another factor in its favour. kre 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]
RE: DAD vs. DIID
On Tue, 20 Aug 2002, Dave Thaler wrote: > > -Original Message- > > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] > [...] > > So, while you indicate that a link-local address may not be able to > > reach all nodes on a subnet, isn't it also true that a subnet-local > > address may not be able to reach all of the nodes on a link? >[...] > The closest question you could > construct in practice is: "If a link has multiple subnet prefixes > assigned to it, and I source from a global address in one of them, and > the destination is a subnet-local multicast group, will another machine > on the same link, which does not have an address in the same prefix, > receive the packet." The answer is yes it will (so the answer to your > question is: no, not true). I'll try to answer from a different perspective. If the destination is a subnet-local multicast group, it may not reach all of the nodes on a link. This is because nodes, currently, do not even know of such a multicast group much less join it. In theory it should go to every node, I think. Is there something I've missed? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
RE: DAD vs. DIID
> -Original Message- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] [...] > So, while you indicate that a link-local address may not be able to > reach all nodes on a subnet, isn't it also true that a subnet-local > address may not be able to reach all of the nodes on a link? Since the boundary of a zone goes through a node, not through a link (ref: scoped addr arch doc), then no it is not true. The "subnet-local" scope contains all interfaces on the link regardless of what addresses are on those interfaces. However, there are no subnet-local unicast addresses (only multicast ones) so the question is moot in practice. The closest question you could construct in practice is: "If a link has multiple subnet prefixes assigned to it, and I source from a global address in one of them, and the destination is a subnet-local multicast group, will another machine on the same link, which does not have an address in the same prefix, receive the packet." The answer is yes it will (so the answer to your question is: no, not true). -Dave 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]
RE: DAD vs. DIID
At 03:17 PM 8/20/02 , Brian Zill wrote: >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. I agree that link-local and subnet-local would be different scopes. What surprised me is the assumption that a subnet scope would be "larger" than a link-local scope. I've had experience running multiple subnets on a single L2 link, but I have not had experience running a single subnet across multiple L2 links. So, while you indicate that a link-local address may not be able to reach all nodes on a subnet, isn't it also true that a subnet-local address may not be able to reach all of the nodes on a link? Margaret 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]
RE: DAD vs. DIID
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]
RE: DAD vs. DIID
> From: Markku Savela [mailto:[EMAIL PROTECTED]] > > > From: "Brian Zill" <[EMAIL PROTECTED]> > > > > My take: given that it appears the majority of > > implementations currently do "DAD", and that "DAD" > > provides for a cleaner multi-link subnet architecture, > > I think "DAD" is the better choice. > > Umm.. "majority of implementations"? What is this? How do you > count them? When was this tally performed. I just went by the ones I know about. Judging from the messages on this thread, there are only one or two implementations doing "DIID". Note that I said "it appears", I didn't claim to have conducted an exhaustive poll. > Does each separate implementation count as one? Or, does the > number of nodes running the implementation affect the count? > Or some other weighing algorithm? Well, I had just been considering each separate implementation. Weighing them by existing node count would shift things even more clearly in the "DAD" direction since both KAME and us do "DAD". --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]
RE: DAD vs. DIID
Hi Brian, Although I generally agree with your other thoughts on DIID vs. DAD, I don't understand these portions: >"DIID": > - Multi-link subnet routers would have to defend >link-local addresses across links, which could be >considered confusing and nonsensical. > >"DAD": > - No strange consequences for multi-link subnets. Why would performing DAD or DIID change the requirement for link-local address uniqueness across a subnet? And, even if it did, what does this really simplify, since site-local and global addresses will still have to be unique across a subnet? Since DAD neighbor advertisements are not sent to the target address, but are instead sent to the solicited-node multicast address derived from the target address, routers on multi-link subnets will already have to forward packets to the solicited-node multicast address between links of a multi-link subnet, so that site-local and global DAD will work. So, those routers would need to perform more complex processing, based on the target address within the NA, to _not_ forward link-local DAD packets across a multilink subnet. Am I misunderstanding something? Margaret 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]
Re: DAD vs. DIID
Hello Brian, I haven't studied the multi-link subnet draft. But, in order to be responsive to your note before taking that time... Brian Zill wrote: > "DIID": > - Nodes need to create a link-local address >corresponding to every IID they use on a given >link (and perform DAD on it). > - Nodes don't need to perform DAD for non link-local >address. > - Multi-link subnet routers would have to defend >link-local addresses across links, which could be >considered confusing and nonsensical. It seems to me that, if you allow two nodes on the same subnet to share a link-local address, then you are really starting to eliminate the usefulness of link-local addressing. If I think about how a network protocol should work that would use link-local addresses, I do not want that protocol to know about the sub-network-layer structure of my network. It seems to me that up until recently there was always a (correct!) assumption that the addressability of a "link" was co-terminous with the addressability of the subnet using that link. In other words, the "link-local address" was equally well "subnet-local". Breaking this characteristic suddenly puts "link-local addresses" outside the scope of IP, since IP deals with putting together subnets, not structures with finer granularity. This idea of having multiple identical link-local addresses on the same subnet exposes IP to a level of structure granularity for which it is poorly equipped. In summary, I think that the sub-network definition of "link-local" address muddies the distinction between network-layer addressing and layer-2 addressing, which is a bad thing and to be avoided. I would say that multi-link routers have to defend link-local addresses across the network extent for which they were defined, which is a subnet. > "DAD": > - Nodes don't need to create otherwise unnecessary >link-local addresses corresponding to the IIDs they >use for temporary or public-key-derived addresses. > - Nodes need to perform DAD on all their addresses. > - No strange consequences for multi-link subnets. But I think the strange consequences are not at all strange, if one takes a layer-3 view of layer-3 addressing concept. Or, maybe there is a move to demote link-layer addresses to be sub-network concepts? And, please don't forget the negative impact on home agent operation. > As far as implementation complexity goes, it seems to me that "DAD" is > far simpler, since the rule is the same for all addresses and you don't > need to create extra addresses only used for doing DAD. But I have a rule which I think is better, for which DIID is far simpler. Rewording: As far as implementation complexity goes, it seems to me that "DIID" is far simpler, since the rule is the same for all addresses and you don't need to create extra protocol for coordinating all devices on a subnet. The rule is that link-local addresses are unique on a subnet. This disambiguates nodes on a subnet from the perspective of network-layer protocol, which is an appropriate function for a network-layer address. > Regarding efficiency, I think it depends upon whether a node has more > prefixes or IIDs. For nodes on a link with lots of prefixes, "DIID" > saves a little bandwidth by not having to do as much DAD. Or, in the case I was discussing, a LOT of bandwidth at an important time when responsiveness is important for the user experience, if we get to the point of utilizing IPv6 capabilities for many subnet prefixes. I'd like to keep that possibility open for the future. > For nodes > with lots of IIDs, "DAD" saves node resources related to configuring > twice as many addresses. Offhand, I'd be tempted to give the edge to > "DIID" here, but since I've seen various creative proposals for using > large numbers of IIDs per node, it's not clear. My machines generally > have more IIDs then prefixes. But I think the numbers have to get > pretty significant in either case before these concerns begin to matter. You are right. And, in fact, my understanding of IID is that each on gives another (real or virtual) _network interface_. Since multiple IIDs define multiple network interfaces, a remote node shouldn't be able to tell whether or not different IIDs belong to the "same" node. Nodes without a link-local address almost seem to not have a (real or virtual) network interface. That doesn't seem right to me. Maybe that is the flip side of an "unnumbered interface", a sort of "extraneously-numbered non-interface". > The multi-link subnet router issue is more clear. "DAD" is a better > architectural fit. Link-local addresses stay link-local and don't > become these quasi-subnet-local addresses that are unique across the > subnet but only reachable on-link. This would be wrong. A link-local address SHOULD be reachable over all parts of the subnet, and it would be the respons
Re: DAD vs. DIID
> On Thu, 15 Aug 2002 20:37:16 -0700, > "Brian Zill" <[EMAIL PROTECTED]> said: > My take: given that it appears the majority of implementations currently > do "DAD", and that "DAD" provides for a cleaner multi-link subnet > architecture, I think "DAD" is the better choice. (Aside from the point if multi-link subnet is a good thing or not), I tend to agree your analysis and conclusion. What is the "majority" can be controversial, but just for record, all *BSDs (actually derived from a single codebase, KAME) always do DAD for all addresses. Also, by watching the discussion so far, there seems to be no implementation except Markku's that can be called "DIID". At best, we saw implementations that enable the optimization described in RFC 2462, which I don't call DIID in this context. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
> From: "Brian Zill" <[EMAIL PROTECTED]> > > My take: given that it appears the majority of implementations currently > do "DAD", and that "DAD" provides for a cleaner multi-link subnet > architecture, I think "DAD" is the better choice. Umm.. "majority of implementations"? What is this? How do you count them? When was this tally performed. Does each separate implementation count as one? Or, does the number of nodes running the implementation affect the count? Or some other weighing algorithm? 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]
RE: DAD vs. DIID
Maybe a summary would help: "DIID": - Nodes need to create a link-local address corresponding to every IID they use on a given link (and perform DAD on it). - Nodes don't need to perform DAD for non link-local address. - Multi-link subnet routers would have to defend link-local addresses across links, which could be considered confusing and nonsensical. "DAD": - Nodes don't need to create otherwise unnecessary link-local addresses corresponding to the IIDs they use for temporary or public-key-derived addresses. - Nodes need to perform DAD on all their addresses. - No strange consequences for multi-link subnets. As far as implementation complexity goes, it seems to me that "DAD" is far simpler, since the rule is the same for all addresses and you don't need to create extra addresses only used for doing DAD. Regarding efficiency, I think it depends upon whether a node has more prefixes or IIDs. For nodes on a link with lots of prefixes, "DIID" saves a little bandwidth by not having to do as much DAD. For nodes with lots of IIDs, "DAD" saves node resources related to configuring twice as many addresses. Offhand, I'd be tempted to give the edge to "DIID" here, but since I've seen various creative proposals for using large numbers of IIDs per node, it's not clear. My machines generally have more IIDs then prefixes. But I think the numbers have to get pretty significant in either case before these concerns begin to matter. The multi-link subnet router issue is more clear. "DAD" is a better architectural fit. Link-local addresses stay link-local and don't become these quasi-subnet-local addresses that are unique across the subnet but only reachable on-link. My take: given that it appears the majority of implementations currently do "DAD", and that "DAD" provides for a cleaner multi-link subnet architecture, I think "DAD" is the better choice. --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]
Re: DAD vs. DIID
Hello folks, I have been trying to catch up by reading all the e-mails, but that's very hard these days! I think that DIID is simpler to understand and administer, and is besides much more scalable in the number of prefixes. Furthermore, try as I have to understand why anywone would prefer the DAD approach, I come up emptyhanded except for the single argument that existing implementations do DAD on every address. And I have read a lot of e-mails. Maybe everyone already agrees that DIID is more scalable. If anyone disagrees, I'd be surprised, but please remind me. Then the question is, why do so many people not care about scalability in this matter? That is for me the real puzzler. IPv6 provides so many addresses and so many prefixes that it's hard for us to understand. Therefore, I am sure we do not understand all possible uses for those many addresses and prefixes. Taking brute force unscalable approaches now, and shooting down a whole galaxy of future possibilities, is just not very sportsmanlike, much less wise or conservative with resources. This is my main concern. When I have voiced this concern, I get the answer that "We don't need that many subnet prefixes now". That is a very bad answer. There is one other abstract concern that I have, and one other very concrete concern. I believe that each of them clearly indicates the need for specifying DIID instead of DAD. The other abstract reason that bothers me about this "DAD" algorithm is that it assumes that not all nodes need to carry a link-local address to match their IID. I believe this is also a bad assumption. The link-local address has nice properties for protocol design, and offers a way to do things like Neighbor Discovery in the right way. It's easy to understand, and thus easier to get correct designs, and correct software and hardware. My belief is that the "DAD" algorithm substantially impairs the effectiveness of protocol design at this level. Simply put, it means that global IP addresses may no longer be known to satisfy properties that previously could have been established by protocol using link-local addresses. In other words, algorithms which should have been carried out with the previously useful link-local addresses would then always have to be carried out with global addresses, with the further complications arising from protection against remote attack which are enabled by globailty. If DAD proponents also wish to specify that every IID has to be associated with a link-local address, then I am thoroughly mystified, but at least the above problem goes away. The concrete reason this proposal is unwelcome for me is that it is very bad for Mobile IP.When a home agent receives a Binding Update, it has to ensure that the mobile node's home addresses remains valid on the link (the mobile node's home network). If the mobile node has not yet sent any Binding Update to the home agent, or if the last Binding Update has expired, the mobile node's addresses will remain undefended on the home network. Then, when the Binding Update is received, the first thing the home agent has to do is to ensure that the mobile node's home addresses have not been taken by some other node. If this home agent has to do this for dozens or hundreds of home addresses, it could be quite a burst of protocol. If this happens for a lot of mobile nodes at once, then the situation would just be that much (linearly) worse. Whenever a horde of mobile nodes all suddenly emerge into new radio coverage, this is quite likely to happen. Put briefly, "DAD" is "BAD" for: - scalability for subnet prefix utilization - link-local protocol design - Mobile IP - network administrator sanity (I didn't mention this, but hopefully it's obvious). As best I can tell, DIID is BAD for some existing implementations, and no other reason. In a way, this is benign, for two reasons: - Really using hundreds of subnets is not a concern with existing IPv6 deployments. Thus, if some platforms don't get it perfect just now, no worries. - By the time it really matters, the chances that existing platforms will have undergone _zero_ software upgrades is, approximately, _zero_. I hope this note will have some effect towards moderating the sentiments towards DAD that were in evidence in Yokohama. Regards, Charlie P. 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]
Re: DAD vs. DIID
> 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]
Re: DAD vs. DIID
In your previous mail you wrote: Here I have to raise a hand. I wrote implementation that actually followed the allowed optimization: do DAD only on link-local, and then freely combine that ID with announced prefixes WITHOUT doing a separate DAD for EACH prefix*ID combination. => so you have implemented DIID. This is still fully allowed by current RFC's, => you can't say this is *fully* allowed by current RFCs. In fact IMHO this is both allowed and forbiden so RFCs are not sound... and I still believe this is GOOD, and should not be changed. => there are two points: - RFCs don't clearly specify DAD or DIID. I believe you agree there is a real problem to fix ASAP. - we have to choose between DAD and DIID: as almost everybody implemented DAD the rough consensus is DAD. As a consequence, and observing that others may not have chosen this tactics, the code also defends plain ID, that is: if it sees a DAD for address which contains one of my ID's, it will reply to the DAD as if I had the address. => this is a good idea but is not specified at all in RFCs: you've just shown your DIID choice is not directly compatible with the common DAD choice, so something (in RFCs, not in your implementation) has to be fixed! I don't see any catastrophic failures resulting from it. => only some hundreds of junk mails in the mobile ip mailing list... Regards [EMAIL PROTECTED] 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]
RE: DAD vs. DIID
Folks, The optimizations I did for T64 were added to by our team and we as of a previous release are doing DAD for all addresses now as Tim suggests below. What drove us was Mobile IPv6 and folks creating privacy addresses. /jim > -Original Message- > From: Tim Hartrick [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 15, 2002 2:21 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: Bound, Jim; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > > > All, > > > > > Ok, first definitions: > > > > - Node A, has "globally unigue" id = AI, implements "link local" > > optimization (does DAD only on fe80::AI). > > > > - Node B is the evil one :-). It has its own "globally > unique" id = BI > > for it's link local > > > > I agree. Our implementation won't allow an application to > assign an address > to an interface which has the the "u" bit set. Not even an > application that > has root privileges. Addresses of that form can only be > assigned to interfaces > if the id has been derived directly from the EUI-64 of the > network interface. > Yes, yes, that can be circumvented by diddling the MAC > address of the network > interface but requires more work. We don't allow the fumble fingered > administrator to abscond with someone else's id without > putting some effort > into it. > > I would say that Node B's implementation is kind of broken. > > My general opinion on this topic is that all "statically" > configured addresses > should have DAD performed on them. This includes privacy > addresses. The > only addresses which don't require DAD are addresses which are derived > directly from an advertised prefix and a real EUI-64 which > has been used to > derive a link-local address, which itself has had DAD performed on it. > > I have no problem with changing our implementation to do DAD on every > address but I would have some serious reservations about > creating and defending > a link-local address associated with every privacy address. > That is crazy. > If complexity is the enemy then such a scheme can't be > characterized as > anything but an enemy. > > > > tim > 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]
Re: DAD vs. DIID
All, > > Ok, first definitions: > > - Node A, has "globally unigue" id = AI, implements "link local" > optimization (does DAD only on fe80::AI). > > - Node B is the evil one :-). It has its own "globally unique" id = BI > for it's link local > I agree. Our implementation won't allow an application to assign an address to an interface which has the the "u" bit set. Not even an application that has root privileges. Addresses of that form can only be assigned to interfaces if the id has been derived directly from the EUI-64 of the network interface. Yes, yes, that can be circumvented by diddling the MAC address of the network interface but requires more work. We don't allow the fumble fingered administrator to abscond with someone else's id without putting some effort into it. I would say that Node B's implementation is kind of broken. My general opinion on this topic is that all "statically" configured addresses should have DAD performed on them. This includes privacy addresses. The only addresses which don't require DAD are addresses which are derived directly from an advertised prefix and a real EUI-64 which has been used to derive a link-local address, which itself has had DAD performed on it. I have no problem with changing our implementation to do DAD on every address but I would have some serious reservations about creating and defending a link-local address associated with every privacy address. That is crazy. If complexity is the enemy then such a scheme can't be characterized as anything but an enemy. tim 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]
Re: DAD vs. DIID
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 ... any time an address is to be assigned, run the DAD algorithm (which is the same whether it is used for a pure DAD approach, or a DIID one). That's it. No need to go looking to see if it has run before, no need to invent LL addresses to run DAD on, no need to do any special case handling of incoming NS messages to see if they're DAD< and if so reply to ones that wouldn't otherwise have been replied to,... | - it causes more packets on the link This one is undisputed. I'm not aware of measurements of how many more. Do note though that typical DAD NS packets use wire bandwidth, but nothing else (no-one receives them), so they're not very costly. They're also not usually very frequent (configuring new addresses doesn't happen all that often). | So, I'm kind of wondering what functionality is actually missing? I don't think it is really a question of missing functionality, though a hint of that was presented at the WG meeting. It is more a case of there currently being two different implementations of this in the field, which don't work well together - one of those has to be picked as the correct one. | I would propose following rules instead of do DAD on every address: And this is simpler than "do DAD on every address" ? kre 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]
Re: DAD vs. DIID
> From: Robert Elz <[EMAIL PROTECTED]> > The Yokohama meeting room's opinion was that "just DAD on every > address before assigning it" was the way to go. But, in my honest opinion, that decision is wrong. Doing DAD on every address is in all respects more costly - implementation requires more complex code - it causes more packets on the link It should be remembered that I do not disallow configuring node A: address P1::id1 node B: address P2::id1 as long as "id1" is not configured as "autoconfigure id" to be combined with prefixes that have A=1. So, I'm kind of wondering what functionality is actually missing? I would propose following rules instead of do DAD on every address: - if id is used in autoconfigre (combine with prefix that has A=1), then doing DAD on "fe80::id" is sufficient - if id is not used in autoconfigure, it's actually part of full configured address "prefix::id", then do DAD on "prefix::id". - on receiving DAD on any X::id, there are couple of choices a) declare collision if "id" matches my id that is used in autoconfiguration b) declare collision if (a) AND "x::" is a prefix with A=1. Hoever, it is obvious that (b) is very weak, as RA for X::/64 may come later... 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]
Re: DAD vs. DIID
Date:Wed, 14 Aug 2002 12:42:07 +0300 From:Markku Savela <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | - Node B is the evil one :-). I don't think we need to characterize them, no deicide which is misconfigured. All that matters, is that you have shown what I thought - if we have some nodes doing DIID (optimising away some DAD checks, as has been permitted), and others doing pure DAD, we can get into problems. It is (now) also clear that we have some implementations that work both ways. That's not good. So, we need to require one or the other to avoid the problem. The Yokohama meeting room's opinion was that "just DAD on every address before assigning it" was the way to go. Sure, in your scenario, that means node A might be left with no global addr it can use. But that also might be what is intended to happen. What's important is that the clash is recognised, and reported, so it if something needs fixing, it can be fixed. kre 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]
Re: DAD vs. DIID
> From: Markku Savela <[EMAIL PROTECTED]> > > 5. Router send RA with P1::/64 Should be obvious to everyone, but just to be clear: that P1::/64 must naturally have A=1. If A=0, node A will never try to configure "P1::AI" and thus there is no collision. 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]
Re: DAD vs. DIID
> From: Robert Elz <[EMAIL PROTECTED]> > > But can you test what happens if you configure an address on some other > node (using a different implementation), that happens to be one that yor > node will assign, without doing DAD on it explicitly, and then start > your node after that. I think the first discussion should be about the most common normal case: autoconfiguring using the "globally unique" EUI64 ID (or if not global, then at least ID which is supposed to be normally unique on the link). Ok, first definitions: - Node A, has "globally unigue" id = AI, implements "link local" optimization (does DAD only on fe80::AI). - Node B is the evil one :-). It has its own "globally unique" id = BI for it's link local - Prefix "P1::/64" is advertised on the link by the router. Events in order of occurrence: 1. Node B is manually configured with address "P1::AI" 2. Node B does DAD on "P1::AI" and assigns address, because node A is not yet connected. 3. Node A comes online on the link 4. Node A does DAD on "fe80::AI", and succeeds. 5. Router send RA with P1::/64 6. Node A uses P1::AI without doing DAD (and probably both A and B cannot communicate properly with this address). Some observations: - if before (6.), A did DAD on "P1::AI", it would fail and leave A without any global address to use. It's options would be a) accept the situation and be isolated b) generate temporary AIn and use "P1::AIn" (repeat until DAD succeeds) (can also redo fe80::AIn). - it seems that this is a configuration error on the node B, that should be detected and fixed. - situation does not occur in the normal autoconfiguration, where node needs to have a link local address first. The whole issue comes from the introduction of "privacy" and generated addresses. To me this is a special case, and it should solve it's own problems, and not break the normal case. And one solution is that, whatever address "Prefix::Id" you configure, you always do the DAD on linklocal "fe80::Id" (you don't need to actually generate this address, if you are not going to use it, just handle DAD as if you had it). 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]
Re: DAD vs. DIID
Date:Tue, 13 Aug 2002 18:26:45 +0300 From:Markku Savela <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | As a consequence, and observing that others may not have chosen this | tactics, the code also defends plain ID, that is: if it sees a DAD for | address which contains one of my ID's, it will reply to the DAD as if | I had the address. I don't see any catastrophic failures resulting | from it. Yes, that way should work. But can you test what happens if you configure an address on some other node (using a different implementation), that happens to be one that yor node will assign, without doing DAD on it explicitly, and then start your node after that. That's the case where there's a potential for trouble with mixed implementations I believe. kre 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]
Re: DAD vs. DIID
- Original Message - From: "Bound, Jim" <[EMAIL PROTECTED]> > I recall many of us having concerns to review it. You included. > /jim > http://www.winternet.com/~mikelr/flame78.html Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 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]
Re: DAD vs. DIID
Markku Savela wrote: > > From: Robert Elz <[EMAIL PROTECTED]> > > > But it seems that there aren't actually any such implementations, everyone > > I have seen who has reported has said they do DAD on all addresses before > > configuring them. The fact that everyone did that was one of the > > motivations for the change. > > Here I have to raise a hand. I wrote implementation that actually > followed the allowed optimization: do DAD only on link-local, and then > freely combine that ID with announced prefixes WITHOUT doing a > separate DAD for EACH prefix*ID combination. > Our implementation also follows the optimization. Vladimir 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]
RE: DAD vs. DIID
The code I wrote for T64 does the same. /jim > -Original Message- > From: Markku Savela [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 11:27 AM > To: [EMAIL PROTECTED] > Cc: Bound, Jim; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > From: Robert Elz <[EMAIL PROTECTED]> > > > But it seems that there aren't actually any such > implementations, everyone > > I have seen who has reported has said they do DAD on all > addresses before > > configuring them. The fact that everyone did that was one of the > > motivations for the change. > > Here I have to raise a hand. I wrote implementation that actually > followed the allowed optimization: do DAD only on link-local, and then > freely combine that ID with announced prefixes WITHOUT doing a > separate DAD for EACH prefix*ID combination. > > This is still fully allowed by current RFC's, and I still believe this > is GOOD, and should not be changed. > > As a consequence, and observing that others may not have chosen this > tactics, the code also defends plain ID, that is: if it sees a DAD for > address which contains one of my ID's, it will reply to the DAD as if > I had the address. I don't see any catastrophic failures resulting > from it. > > > 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]
RE: DAD vs. DIID
I recall many of us having concerns to review it. You included. /jim > -Original Message- > From: Robert Elz [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 10:52 AM > To: Bound, Jim > Cc: Margaret Wasserman; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > Date:Mon, 12 Aug 2002 22:37:59 -0400 > From:"Bound, Jim" <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED] > qcorp.net> > > | We had no such consensus. > > Yes, in the room, there was very clear support for this. Margaret > was correct. > > | In fact it was stated we had to take this to the mail list. > > Of course it was - all WG decisions get made on the list, so > everything > "decided" in the room has to be taken to the list. > > That is what is happening now... > > kre > > > 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] > > 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]
Re: DAD vs. DIID
> From: Robert Elz <[EMAIL PROTECTED]> > But it seems that there aren't actually any such implementations, everyone > I have seen who has reported has said they do DAD on all addresses before > configuring them. The fact that everyone did that was one of the > motivations for the change. Here I have to raise a hand. I wrote implementation that actually followed the allowed optimization: do DAD only on link-local, and then freely combine that ID with announced prefixes WITHOUT doing a separate DAD for EACH prefix*ID combination. This is still fully allowed by current RFC's, and I still believe this is GOOD, and should not be changed. As a consequence, and observing that others may not have chosen this tactics, the code also defends plain ID, that is: if it sees a DAD for address which contains one of my ID's, it will reply to the DAD as if I had the address. I don't see any catastrophic failures resulting from it. 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]
Re: DAD vs. DIID
Date:Mon, 12 Aug 2002 22:34:39 -0400 From:"Bound, Jim" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | As long as if two networks merge the following is strictly prohibited: | | two nodes now appear on the network with: | | 4ff3::2 | 4ff3::2 Jim, The idea is that DAD must be performed on any address before it is configured. So, that wouldn't possibly work. Of course, if someone just plugs two cable together, nodes aren't going to do doing (re-doing) DAD on their addresses (any of them, in either scenario) - this has always been recognised as one of the failure modes for DAD, but so unlikely, and so hard to fix, that it isn't worth bothering with. | The implementation is that if two nodes have competing implementations. | If one node checks the entire address and the other does not then we | could end up with in practice in the field with what I want to be | prohibited. Yes, that's true - if there are implementations replying on DIID, and checking only LL's using DAD, then such an implementation might config an address that was already in use by a node that doesn't config LL's for every address it has configured. But it seems that there aren't actually any such implementations, everyone I have seen who has reported has said they do DAD on all addresses before configuring them. The fact that everyone did that was one of the motivations for the change. kre 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]
Re: DAD vs. DIID
Date:Mon, 12 Aug 2002 22:37:59 -0400 From:"Bound, Jim" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | We had no such consensus. Yes, in the room, there was very clear support for this. Margaret was correct. | In fact it was stated we had to take this to the mail list. Of course it was - all WG decisions get made on the list, so everything "decided" in the room has to be taken to the list. That is what is happening now... kre 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]
RE: DAD vs. DIID
Hi Margaret, To the technical discourse below. > -Original Message- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 12:05 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Though, it is not entirely clear to me why > >the /subnet IID uniqueness rather than the /link > >uniqueness makes the case of privacy addresses easier. > > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. A global prefix can use the same link-local address EUI again. I have to now go check but I think the only requirement is not duplicate the linklocal address but the EUI of that address can be reused by non-link-local addresses. Why does this not solve the privacy issue? thanks /jim > > If we only require IIDs to be unique within a subnet, > a node that implements privacy addresses will only need > to generate the single privacy address and perform > DAD for that address. > > As currently document (prior to the discussed changes) > the privacy document is incompatible, in this minor way, > with the addressing architecture and the autoconfiguration > documents. We had two options for what to change: > > - Relax the uniqueness restriction in the > addressing architecture, and make > a corresponding change to the > autoconfiguration document. > -OR- > - Modify the privacy address document to > require the creation and maintenance of > link-local addresses, as described above. > > We had a consensus within the room in Yokohama to choose > the first option, and we are currently checking that > consenus with the list. > > Margaret > > > > > > 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] > > 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]
RE: DAD vs. DIID
Hi Margaret, > -Original Message- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 12:05 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Though, it is not entirely clear to me why > >the /subnet IID uniqueness rather than the /link > >uniqueness makes the case of privacy addresses easier. > > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. > > If we only require IIDs to be unique within a subnet, > a node that implements privacy addresses will only need > to generate the single privacy address and perform > DAD for that address. > > As currently document (prior to the discussed changes) > the privacy document is incompatible, in this minor way, > with the addressing architecture and the autoconfiguration > documents. We had two options for what to change: > > - Relax the uniqueness restriction in the > addressing architecture, and make > a corresponding change to the > autoconfiguration document. > -OR- > - Modify the privacy address document to > require the creation and maintenance of > link-local addresses, as described above. > > We had a consensus within the room in Yokohama to choose > the first option, and we are currently checking that > consenus with the list. We had no such consensus. In fact it was stated we had to take this to the mail list. Many of us were concerned that we wanted to know what problem we are trying to solve. That has been stated by your mail now and that is good. But now we need to discuss the ramifications on this list and if it is warranted. regards, /jim > > Margaret > > > > > > 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] > > 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]
RE: DAD vs. DIID
Hi Margaret, As long as if two networks merge the following is strictly prohibited: two nodes now appear on the network with: 4ff3::2 4ff3::2 So if two networks heal or merge then DAD must be performed fixed per addr conf as you suggest. That is not what got presented at Yokohama. The other issue I have is an implementation one. If we do this and I am not 100% convinced it is required or what problem we are solving and that would be nice to see. The implementation is that if two nodes have competing implementations. If one node checks the entire address and the other does not then we could end up with in practice in the field with what I want to be prohibited. I also need to think on other architecture ramifications to current implementation like the way we account for duplicate prefixes combined with EUI. thanks /jim > -Original Message- > From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 9:59 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > > > Hi Robert, > > >Maybe I am missing something here, but, if the > >Interface Identifier is not unique anymore on a > >link, what is it then supposed to identify and > >be used for ? > > The suggestion doesn't change the purpose of an IID, just > the scope of its uniqueness. > > In the current (pre-change) addressing architecture, an IID > is unique on the link. So, within the scope of a given link, > the IID can be used to identify a particular interface (and, > by extension, a given node). > > This change would modify the scope of that uniqueness to be > a subnet prefix, not the whole link. So, within a set of > interfaces using a particular subnet prefix, the IID would > identify a particular interface. Most links will have > multiple subnet prefixes in use, because they will have a > link-local prefix and a global prefix. Some links may have > many subnet prefixes in use (link-local, one or more > site-local subnets and one or more global subnets). > > Have you seen the slides that Steve Deering presented on > this subject? If they aren't already up on the IETF > proceedings page, they should be shortly. They give an > example of what this means. > > Although the wording is fairly arcane in order to be > exactly correct, the real change comes down to this: > > OLD:IIDs are required to be unique on a link. > > NEW:Only complete addresses are required to > be unique on a link. > > Relaxing the restriction to the second case makes the use of > privacy addresses easier, it doesn't require any major changes > to implementations (we are already doing Duplicate _Address_ > Detection, not Duplicate IID Detection), and it meets the > requirements to uniquely identify a node for communication. > > A side-effect of this change is that we will need to update > the Address Autoconfiguration spec to require the use of DAD > on all addresses, and not allow the currently documented > optimization to only perform DAD on the link-local address. > > I can only think of two cases where the same IID would get used > for different hosts on the same link: > > - If some hosts on the link do not configure global > addresses, but others do. > > - If there are two (or more) subnets running over the > same link, and not all of the hosts on the > link are members of both (or all) subnets. > > >Also, how would then the Link Local address be formed ? > > Not all IIDs are used to create link-local addresses. An > interface is required to have at least one link-local address, > and the IID used to create that address must be different than > the IIDs used to create link-local addresses on other interfaces > on the same link (as required by the per-subnet uniqueness clause, > and as checked by DAD). But it is not necessary, for example, to > create link-local addresses with the randomly generated IIDs used > to create privacy addresses. > > It is important for folks to understand what we are changing > here, so please let me know if any of the above is confusing > or unclear. > > Margaret > > > > > > 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] > > 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]
Re: DAD vs. DIID
> From: Margaret Wasserman <[EMAIL PROTECTED]> > To ensure IID uniqueness on a link, a node that implements > privacy addresses would need to generate a link-local > address for each randomly generated IID (in addition to the > global address generated for privacy), perform DAD on > that address, and maintain that address for the lifetime > of the privacy address in order to respond to other nodes' > DAD messages. Well, that is only one possible implemetation. Another way, when node sees DAD with ID part matching any of the nodes ID's, it can act as if it had the address and defend it (note: this is ONLY with DAD probes, for normal NS it replies only if address is actually configured as whole). This solution does not need actual generation of link local address. 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]
Re: DAD vs. DIID
Hi Robert, >Though, it is not entirely clear to me why >the /subnet IID uniqueness rather than the /link >uniqueness makes the case of privacy addresses easier. To ensure IID uniqueness on a link, a node that implements privacy addresses would need to generate a link-local address for each randomly generated IID (in addition to the global address generated for privacy), perform DAD on that address, and maintain that address for the lifetime of the privacy address in order to respond to other nodes' DAD messages. If we only require IIDs to be unique within a subnet, a node that implements privacy addresses will only need to generate the single privacy address and perform DAD for that address. As currently document (prior to the discussed changes) the privacy document is incompatible, in this minor way, with the addressing architecture and the autoconfiguration documents. We had two options for what to change: - Relax the uniqueness restriction in the addressing architecture, and make a corresponding change to the autoconfiguration document. -OR- - Modify the privacy address document to require the creation and maintenance of link-local addresses, as described above. We had a consensus within the room in Yokohama to choose the first option, and we are currently checking that consenus with the list. Margaret 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]
Re: DAD vs. DIID
Hi Margaret, Thank you for your clarification. I now get the point. > This change would modify the scope of that uniqueness > to be a subnet prefix, not the whole link. So, > within a set of interfaces using a particular > subnet prefix, the IID would identify a particular > interface. > > (..) > > OLD:IIDs are required to be unique on a link. > > NEW:Only complete addresses are required to > be unique on a link. > > Relaxing the restriction to the second case makes > the use of privacy addresses easier, I understand that there is no actual need to require /link IID uniqueness. Though, it is not entirely clear to me why the /subnet IID uniqueness rather than the /link uniqueness makes the case of privacy addresses easier. Robert 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]
Re: DAD vs. DIID
Hi Robert, >Maybe I am missing something here, but, if the >Interface Identifier is not unique anymore on a >link, what is it then supposed to identify and >be used for ? The suggestion doesn't change the purpose of an IID, just the scope of its uniqueness. In the current (pre-change) addressing architecture, an IID is unique on the link. So, within the scope of a given link, the IID can be used to identify a particular interface (and, by extension, a given node). This change would modify the scope of that uniqueness to be a subnet prefix, not the whole link. So, within a set of interfaces using a particular subnet prefix, the IID would identify a particular interface. Most links will have multiple subnet prefixes in use, because they will have a link-local prefix and a global prefix. Some links may have many subnet prefixes in use (link-local, one or more site-local subnets and one or more global subnets). Have you seen the slides that Steve Deering presented on this subject? If they aren't already up on the IETF proceedings page, they should be shortly. They give an example of what this means. Although the wording is fairly arcane in order to be exactly correct, the real change comes down to this: OLD:IIDs are required to be unique on a link. NEW:Only complete addresses are required to be unique on a link. Relaxing the restriction to the second case makes the use of privacy addresses easier, it doesn't require any major changes to implementations (we are already doing Duplicate _Address_ Detection, not Duplicate IID Detection), and it meets the requirements to uniquely identify a node for communication. A side-effect of this change is that we will need to update the Address Autoconfiguration spec to require the use of DAD on all addresses, and not allow the currently documented optimization to only perform DAD on the link-local address. I can only think of two cases where the same IID would get used for different hosts on the same link: - If some hosts on the link do not configure global addresses, but others do. - If there are two (or more) subnets running over the same link, and not all of the hosts on the link are members of both (or all) subnets. >Also, how would then the Link Local address be formed ? Not all IIDs are used to create link-local addresses. An interface is required to have at least one link-local address, and the IID used to create that address must be different than the IIDs used to create link-local addresses on other interfaces on the same link (as required by the per-subnet uniqueness clause, and as checked by DAD). But it is not necessary, for example, to create link-local addresses with the randomly generated IIDs used to create privacy addresses. It is important for folks to understand what we are changing here, so please let me know if any of the above is confusing or unclear. Margaret 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]
Re: DAD vs. DIID
Hi, On Mon, 5 Aug 2002, Margaret Wasserman wrote in "Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt": > In the Yokohama meeting, Steve Deering lead a > discussion on the uniqueness of IIDs, and there > was a pretty big majority of people in the room > who thought that we shouldn't even require IIDs > to be unique on a link. Addresses need to be > unique (obviously), but not necessarily the > IIDs from which they are created. The discussion > will be documented in the minutes, and we'll offer > a chance for people on the list to comment before > we make any final decision, of course. I went through the minutes and presentation of Yokohama meeting about "DAD vs. DIID Discussion". Maybe I am missing something here, but, if the Interface Identifier is not unique anymore on a link, what is it then supposed to identify and be used for ? Also, how would then the Link Local address be formed ? Thanks for any clarification there, Robert 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]
Re: DAD vs. DIID
> On Mon, 29 Jul 2002 14:11:00 +0200, > Francis Dupont <[EMAIL PROTECTED]> said: >Apparently, KAME is not able to configure multiple plain IDs to be >combined freely with all announced prefixes? Or can it? > => I believe KAME has a notion of "the" id of the interface. No, KAME's implementation does not have such a notion, at least not explicitly. So, basically Markku is correct. > This should be discussed on the KAME list. I agree, if we need more discussion on this particular topic, perhaps we'll have to change the place. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
> From: Francis Dupont <[EMAIL PROTECTED]> > >I'm not saying above is bad situation. It does require implementation >to keep track of each combination, to remember wich prefix/id >combinations have collided (or it has to keep a separate list of >collided addresses, so that it doesn't try to reuse those combinations >later). > > => obviously your assumptions about how the autoconf works are not shared. IPv6 addressing architecture defines the process of combining prefixes and ids. Nothing in the RFC's prevents taking the interpretation I presented. It's correct, and perhaps a useful feature. > => with DAD, there is no notion of collided ID, only of collided > addresses. IMHO the confusion comes from the current mixture of DAD > and DIIDD. Well, right. Did I say anything else? This is discussion about two choices (1) do DAD, (2) require the ID part be unique (only one node can use) on the link. The current autoconf is basicly DAD. I just dared to propose that perhaps unique ID approach might be better solution. 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]
Re: DAD vs. DIID
In your previous mail you wrote: > One obvious one is when I have two links, and have assigned pfx1::1 to > my favourite node on one of them, and pfx2::1 to my favourite (different) > node on the other, and then I decide to merge the links into one. Applying > both prefixes to the link is easy, so I shouldn't have to renumber anything > just because of this (pyhsical) change (maybe a temporary one caused by > the death of a switch, while waiting upon a replacement - assuming I'm > too cheap to buy switches that support vlans...). But now I have two ::1's > on the one link. But, even with DAD, you will have problems. => I have no problem... You are announcing pfx1 and pfx2 on the same link. Thus, because both nodes have id=1 => no, they have ids=something and addresses=pfx1::1 and pfx2::1 - both nodes will try to configure now pfx1::1 *AND* pfx2::1 and collide each other. => not if they don't try to configure all ids with all prefixes. - both nodes can now validly try to configure fe80::1, and collide on that => idem. - if a new pfx3 is announced, both nodes will collide on "pfx3::1" => idem. I'm not saying above is bad situation. It does require implementation to keep track of each combination, to remember wich prefix/id combinations have collided (or it has to keep a separate list of collided addresses, so that it doesn't try to reuse those combinations later). => obviously your assumptions about how the autoconf works are not shared. With DIID, you can remove the collided ID, and it will not be used. => with DAD, there is no notion of collided ID, only of collided addresses. IMHO the confusion comes from the current mixture of DAD and DIIDD. Regards [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to >[EMAIL PROTECTED] using -f > From: Robert Elz <[EMAIL PROTECTED]> > One obvious one is when I have two links, and have assigned pfx1::1 to > my favourite node on one of them, and pfx2::1 to my favourite (different) > node on the other, and then I decide to merge the links into one. Applying > both prefixes to the link is easy, so I shouldn't have to renumber anything > just because of this (pyhsical) change (maybe a temporary one caused by > the death of a switch, while waiting upon a replacement - assuming I'm > too cheap to buy switches that support vlans...). But now I have two ::1's > on the one link. But, even with DAD, you will have problems. You are announcing pfx1 and pfx2 on the same link. Thus, because both nodes have id=1 - both nodes will try to configure now pfx1::1 *AND* pfx2::1 and collide each other. - both nodes can now validly try to configure fe80::1, and collide on that - if a new pfx3 is announced, both nodes will collide on "pfx3::1" I'm not saying above is bad situation. It does require implementation to keep track of each combination, to remember wich prefix/id combinations have collided (or it has to keep a separate list of collided addresses, so that it doesn't try to reuse those combinations later). With DIID, you can remove the collided ID, and it will not be used. Of course, implementations can be more complicated: at least I have possibility to use "atomic" address, which will allow me to use "pfx1::1", even if id=1 is removed. You configure prefix, id or atomic address. 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]
Re: DAD vs. DIID
Date:Tue, 30 Jul 2002 07:33:07 +0300 (EEST) From:Pekka Savola <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | > I don't agree with the first sentence there, I think I'm (a) someone... | I'd like to hear what kind of network configuration you have in mind. One obvious one is when I have two links, and have assigned pfx1::1 to my favourite node on one of them, and pfx2::1 to my favourite (different) node on the other, and then I decide to merge the links into one. Applying both prefixes to the link is easy, so I shouldn't have to renumber anything just because of this (pyhsical) change (maybe a temporary one caused by the death of a switch, while waiting upon a replacement - assuming I'm too cheap to buy switches that support vlans...). But now I have two ::1's on the one link. | My main point is just that one should be able "optimize" DAD somehow if | there are long latencies involved (e.g. serialized full DAD is | unacceptable with many addresses). How, that's another issue. Else folks | that need to optimize it will do so anyway. N different DAD's (that is for different addresses) on one link should complete in the time it takes to do one DAD (that is, for one of those addresses), plus noise (the time it takes to transmit the other N-1 packets). Doing DAD for all of the addresses consumes some bandwidth, it has no other noticeable effect (or should have) on the node that is performing the DAD. Certainly there will be two DAD delays when a node boots - the first to get its LL addr, and then one more, for all of the other addresses it creates after it has received the RA (in all of that, I'd actually expect the random wait before sending the RS, if no RA just "happens", to be the biggest source of delay to a booting node). But the number of addresses it has on the link (LL, SL, or global) should not materially affect anything. An implementation that has N addresses ready to verify, so does DAD on the first, then after that is complete, DAD on the second, etc, would be just too cheap to consider for anything real (on the other hand, for some applications where human patience isn't an issue, that might be OK). kre 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]
Re: DAD vs. DIID - multiple IIDs?
Date:Mon, 29 Jul 2002 13:05:49 -0400 From:"Deshpande, Prasad" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | - When and why would someone configure multiple IIDs on an interface? One obvious place would be for various kinds of "hot standby" protocols, when one node needs to take over the functionality of another when the other dies. There the node will have its own addresses (and IIDs) but will also want those of the node it is pretending to be. | - If multiple IIDs are configured on an interface, does that imply that | the interface has multiple link-local addresses, one created from each | IID. I didn't see any RPC/draft which prevents one from having multiple | link-local addresses. On the other hand I couldn't find any statement | that says that there must be a link local address for each IID. That's because there is no rule either way. There's nothing preventing a node (at least attempting to) configure a LL addr with the same IID as that used for every global addr it configures. But nor is there any requirement that it do that. Nodes are required to have a LL addr on every link. Beyond that, almost anything is possible (requiring a LL addr with an IID before allowing a global addr using the same IID will defeat some entirely reasonable configurations, but that just makes that particular implementation less functional than others, not incorrect). kre 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]
Re: DAD vs. DIID
On Mon, 29 Jul 2002, Robert Elz wrote: > | But you agree that the above configuration is very rare, really just a > | "corner case". Someone _might_ want it though. > > I don't agree with the first sentence there, I think I'm (a) someone... I'd like to hear what kind of network configuration you have in mind. > The problem is that you have to know what is enabled/disabled on every other > node on the link as well. So, this would need to be yet another RA > parameter (and there'd have to be some rule on what was permitted when > there is no router in that case). > > It really is simpler just to always do DAD. I agree this is a problem :-(. > On optimistic DAD - maybe I misunderstood what Erik was suggesting, but > I assumed the "optimistic" wouldn't be "irrational" .. that is, for > optimistic DAD, which I think I'd certainly not object to (though I'm also > not sure the actual cost of full DAD is enough for it to matter) I'd > assumed the idea would be to send the first DAD NS, and wait for a reply, > and if no reply came to that one, assume the address is OK, while > simultaneously going on and doing the rest of the DAD procedure (killing > the address if it fails). That more or less cuts the DAD delay by 2/3 (but > it doesn't eliminate it). My main point is just that one should be able "optimize" DAD somehow if there are long latencies involved (e.g. serialized full DAD is unacceptable with many addresses). How, that's another issue. Else folks that need to optimize it will do so anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
RE: DAD vs. DIID - multiple IIDs?
> > From: "Deshpande, Prasad" <[EMAIL PROTECTED]> > > > I have some questions related to multiple IIDs on an interface > > > > - When and why would someone configure multiple IIDs on an > interface? > > offhand, perpaps > > - for a server you might want manually configure nice "prefix::1" > address in addition to the automaticly generated id (or even many > id's you have webserver: id=1, mailserver: id=2, etc.). Now, > depening on needs, you can designate any host as server by adding > the servers "locally-well-known-id" to a host (and removing it from > another). > > - privacy draft (3041?) didn't exactly call for generation of id only, > but it could be done that way too (just generate random id's to be > used). > > > - If multiple IIDs are configured on an interface, does > that imply that > > the interface has multiple link-local addresses, one > created from each > > IID. > > In my case, yes. > Which IID do you use to send out router advertisements? If someone deletes that IID, other routers on the link wont receive router advertisements from it so they will assume that the router with old IID is gone. From my understanding of RFC 3041, it calls out for having global addresses based on "random IIDs". I assume these "random IIDs" are never used to construct link local addresses. Let me know if this is not the case. In your first example, webserver and mailserver could have addresses prefix::1 and prefix::2 but their interface IDs can be A1 (!= 1) and B1 (!= 2). What I am trying to say is that you could have just one IID (and so one link-local address) but multiple interface addresses some of which may be constructed using the IID. Then you can do a DAD on all addresses - including the link-local address. thanks -prasad 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]
RE: DAD vs. DIID - multiple IIDs?
> -Original Message- > From: Markku Savela [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 29, 2002 6:34 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: DAD vs. DIID > > - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. > > - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do >them in parallel or do I have to do them one after another? > > - I configure a new additional ID => I do a DAD for 4 new > addresses. Do I do >them in parallel or do I have to do them one after another? > > Apparently, KAME is not able to configure multiple plain IDs to be > combined freely with all announced prefixes? Or can it? I have some questions related to multiple IIDs on an interface - When and why would someone configure multiple IIDs on an interface? - If multiple IIDs are configured on an interface, does that imply that the interface has multiple link-local addresses, one created from each IID. I didn't see any RPC/draft which prevents one from having multiple link-local addresses. On the other hand I couldn't find any statement that says that there must be a link local address for each IID. thanks -prasad 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]
Re: DAD vs. DIID - multiple IIDs?
> From: "Deshpande, Prasad" <[EMAIL PROTECTED]> > I have some questions related to multiple IIDs on an interface > > - When and why would someone configure multiple IIDs on an interface? offhand, perpaps - for a server you might want manually configure nice "prefix::1" address in addition to the automaticly generated id (or even many id's you have webserver: id=1, mailserver: id=2, etc.). Now, depening on needs, you can designate any host as server by adding the servers "locally-well-known-id" to a host (and removing it from another). - privacy draft (3041?) didn't exactly call for generation of id only, but it could be done that way too (just generate random id's to be used). > - If multiple IIDs are configured on an interface, does that imply that > the interface has multiple link-local addresses, one created from each > IID. In my case, yes. 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]
Re: DAD vs. DIID
Date:Mon, 29 Jul 2002 12:53:16 +0200 From:"Nils Agne Nordbotten" <[EMAIL PROTECTED]> Message-ID: <014001c236ee$24fecd30$8cb9d8c1@nansb> | While this is simple in traditional LANs I'm worried about the consequences | in networks like Bluetooth scatternets where devices in power saving modes | will have to be waked up. If the hardware is rational (a topic about which I know nothing at all, it might not be, but perhaps if pressed, it will improve) the devices won't need to wake up. Remember ND (including DAD) is not ARP, packets aren't broadcast, they're multicast, and to a multicast address which will normally only have as members of the same multicast group nodes sharing the same IID.If you're one of the believers of "no IID sharing" then doing DAD instead of DIIDD won't change that, and usually, there will be no other members of the group than the node which is doing DAD. The DAD packets consume an (insignificant) amount of bandwidth, but when all is working properly, go nowhere at all. | I also imagine there easily will be partitions in | such networks, and that DAD therefore will provide little assurance. If partitions are common (aside: why would anyone use a link where the chances of not being able to talk to any other random node on the link, like the router, or fileserver, ... are not negligible??) then sure, DAD won't provide a lot or protection, but DIID would provide even less, as less probes are done. At least with DAD, you have a better chance of some of your addresses being detected as duplicates, which will start waving the red flags. | Instead address uniqueness could be assured from EUIs. If EUIs are being used to form the addresses, then duplicates should be very very rare, and all DAD really achieves in the usual case is a little bandwidth consumption and a small delay. But it does no harm either. kre 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]
Re: DAD vs. DIID
In your previous mail you wrote: While this is simple in traditional LANs I'm worried about the consequences in networks like Bluetooth scatternets where devices in power saving modes will have to be waked up. I also imagine there easily will be partitions in such networks, and that DAD therefore will provide little assurance. Instead address uniqueness could be assured from EUIs. => I have no concern about the last statement. The problem with (too) optimistic DAD is to fail to detect a collision before the damage and when there are duplicated EUIs the damage is already very great. This is why I proposed to use IMEIs for mobile phones which have no IEEE devices so no EUIs but still have a globally unique hardware number. PPP is another case where DAD can be forgotten. Regards [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
In your previous mail you wrote: Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. => it is uncommon to have 3 ids (usually there are only one or two)... - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? => in parallel of course. - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? => idem. Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? => I believe KAME has a notion of "the" id of the interface. This should be discussed on the KAME list. [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
> for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. While this is simple in traditional LANs I'm worried about the consequences in networks like Bluetooth scatternets where devices in power saving modes will have to be waked up. I also imagine there easily will be partitions in such networks, and that DAD therefore will provide little assurance. Instead address uniqueness could be assured from EUIs. Regards Nils Nordbotten 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]
Re: DAD vs. DIID
>Then, I would like to have some consideration on how to behave in the >following situation: > - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. > - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do > them in parallel or do I have to do them one after another? > - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do > them in parallel or do I have to do them one after another? you can do them in parallel. itojun 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]
Re: DAD vs. DIID
> From: [EMAIL PROTECTED] > > for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. Then, I would like to have some consideration on how to behave in the following situation: - I've 3 prefixes and 3 ids, thus I have total of 9 addresses DADded. - I receive 4th prefix, => I do a DAD for 3 new addresses. Do I do them in parallel or do I have to do them one after another? - I configure a new additional ID => I do a DAD for 4 new addresses. Do I do them in parallel or do I have to do them one after another? Apparently, KAME is not able to configure multiple plain IDs to be combined freely with all announced prefixes? Or can it? 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]
Re: DAD vs. DIID
In your previous mail you wrote: >i see zero reason for prohibiting the above configuration. => I should say I agree with Itojun... If disabled, perform DAD for every address without any optimizations. => IMHO the worse solution is to get a mix of DAD and DIIDD (as today). DAD had the majority at the meeting and is straightforward to implement so we should fix inconsistencies in current specs (including mobile IPv6 one). Regards [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
Date:Mon, 29 Jul 2002 07:25:53 +0300 (EEST) From:Pekka Savola <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: | > >Wouldn't it be much much simpler just to do DIID? I see zero reason for | > >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in | > >a same subnet. | > | > i see zero reason for prohibiting the above configuration. Nor do I. | But you agree that the above configuration is very rare, really just a | "corner case". Someone _might_ want it though. I don't agree with the first sentence there, I think I'm (a) someone... | Perhaps this behaviour should be configurable then? That makes no sense. | If enabled (default), perform DIID only [and possibly skip for EUI64 | addresses]. This is useful in scenarios where there is a large number of | addresses assigned in the nodes. | | If disabled, perform DAD for every address without any optimizations. The problem is that you have to know what is enabled/disabled on every other node on the link as well. So, this would need to be yet another RA parameter (and there'd have to be some rule on what was permitted when there is no router in that case). It really is simpler just to always do DAD. On optimistic DAD - maybe I misunderstood what Erik was suggesting, but I assumed the "optimistic" wouldn't be "irrational" .. that is, for optimistic DAD, which I think I'd certainly not object to (though I'm also not sure the actual cost of full DAD is enough for it to matter) I'd assumed the idea would be to send the first DAD NS, and wait for a reply, and if no reply came to that one, assume the address is OK, while simultaneously going on and doing the rest of the DAD procedure (killing the address if it fails). That more or less cuts the DAD delay by 2/3 (but it doesn't eliminate it). This relies upon NS/NA failure being very rare (so it might be something that you'd do on fairly reliable links, and not on ones known to have greater packet losses). That is, if there is another (operational) user of the address, they're almost always going to reply to the first NS for their address (whether or not it is for DAD purposes). That is certainly in line with my experiences with ARP. kre 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]
Re: DAD vs. DIID
On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: > >Wouldn't it be much much simpler just to do DIID? I see zero reason for > >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in > >a same subnet. > > i see zero reason for prohibiting the above configuration. But you agree that the above configuration is very rare, really just a "corner case". Someone _might_ want it though. Perhaps this behaviour should be configurable then? If enabled (default), perform DIID only [and possibly skip for EUI64 addresses]. This is useful in scenarios where there is a large number of addresses assigned in the nodes. If disabled, perform DAD for every address without any optimizations. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
Re: DAD vs. DIID
>Wouldn't it be much much simpler just to do DIID? I see zero reason for >e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in >a same subnet. i see zero reason for prohibiting the above configuration. itojun 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]
Re: DAD vs. DIID
On Mon, 29 Jul 2002 [EMAIL PROTECTED] wrote: > >> optimistic DAD looks to me to be a good compromise. > >A possible implication of optimistic DAD (i.e. where an address is assigned > >to the interface and used before it is known whether it is a duplicate) is > >that > > - neighbor caches in order nodes will have the wrong information and need > > to be switched back to the correct, original information once DAD fails. > > - TCP connections might be reset (a packet arrives at the new node, which > > doesn't have the TCP state so it sends a reset; the real "owner" of the > > address has the TCP state) > > for this reason, i'm not a fan of optimistic DAD. my preference > is to run full DAD (will take 1 second or so), for every address > assigned to the node. the rule is simple - run it for every address > you assign to the node, that's all. Wouldn't it be much much simpler just to do DIID? I see zero reason for e.g. PRFX1::1/64 and PRFX2::1/64 being assigned on two different nodes in a same subnet. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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]
Re: DAD vs. DIID
>> optimistic DAD looks to me to be a good compromise. >A possible implication of optimistic DAD (i.e. where an address is assigned >to the interface and used before it is known whether it is a duplicate) is >that > - neighbor caches in order nodes will have the wrong information and need > to be switched back to the correct, original information once DAD fails. > - TCP connections might be reset (a packet arrives at the new node, which > doesn't have the TCP state so it sends a reset; the real "owner" of the > address has the TCP state) for this reason, i'm not a fan of optimistic DAD. my preference is to run full DAD (will take 1 second or so), for every address assigned to the node. the rule is simple - run it for every address you assign to the node, that's all. itojun 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]
Re: DAD vs. DIID
> there was also a discussion whether DAD should be done only on > manually configured addresses, and not on MAC address derived and > random ones. no consensus in the room. Erik Nordmark suggested > "optimistic DAD", but there was no time to discuss it. I hope I merely suggested that "optimistic DAD" be explored to better understand the issues and benefits. > optimistic DAD looks to me to be a good compromise. A possible implication of optimistic DAD (i.e. where an address is assigned to the interface and used before it is known whether it is a duplicate) is that - neighbor caches in order nodes will have the wrong information and need to be switched back to the correct, original information once DAD fails. - TCP connections might be reset (a packet arrives at the new node, which doesn't have the TCP state so it sends a reset; the real "owner" of the address has the TCP state) Erik 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]
Re: DAD vs. DIID
In your previous mail you wrote: consensus in the room was for DAD. => it should be very fine to get an official position about this. there was also a discussion whether DAD should be done only on manually configured addresses, and not on MAC address derived and random ones. no consensus in the room. Erik Nordmark suggested "optimistic DAD", but there was no time to discuss it. optimistic DAD looks to me to be a good compromise. => I disagree because the damage can be too great: I prefer collision avoidance to collision detection... As I explained in an old thread about this kind of issues, the choice for optimistic DAD *must* be in the hands of the network manager (i.e., the guy who will be in trouble if the very unlikely event happens). Regards [EMAIL PROTECTED] 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]
Re: DAD vs. DIID
> I would appreciate it if anyone could inform me of the outcome of > the DAD vs. DIID discussion in Yokohama. The meeting minutes are not > available at playground.sun yet. consensus in the room was for DAD. there was also a discussion whether DAD should be done only on manually configured addresses, and not on MAC address derived and random ones. no consensus in the room. Erik Nordmark suggested "optimistic DAD", but there was no time to discuss it. optimistic DAD looks to me to be a good compromise. cheers, Ole 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]
DAD vs. DIID
Hello, I would appreciate it if anyone could inform me of the outcome of the DAD vs. DIID discussion in Yokohama. The meeting minutes are not available at playground.sun yet. Regards Nils Nordbotten
