Hemant Singh (shemant) wrote: > > IMO this is already fairly well spelled out in 2461bis. There was talk > earlier on the list of adding something along the list of: > This document RECOMMENDS that implementations use default values > specified > here. > > <hs> Since we are working on how to fold in text from our I-D as changes > to 2461bis, this bullet 5 from section 2 of our I-D will also fall into > that work of where to specify this recommendation in 2461bis.
That single sentence will do instead and take care of all the other defaults as well. I'll to see what happened to that thread, but something like that would be useful for both 2461bis and 2462bis. > >> 2461bis on page 19 did not show us any relevant words. > > Note that a future revision of the address architecture [RFC3513] > and a future link-type specific document, which will still be > consistent with each other, could potentially allow for an > interface identifier of length other than the value defined in the > current documents. Thus, an implementation should not assume a > particular constant. Rather, it should expect any lengths of > interface identifiers. > > I suggest the 'should' in the last sentence be replaced by SHOULD. > > <hs> Ah, this is text on page 17 of 2462bis -08. Good catch. We agree > that the "should" be replaced with SHOULD. So does Tatuya want to make > such a change to 2462bis before sending it off? Well, looking at 08 draft, it shows up in Section 5.5.3 at the top of page 19, but I don't really care were the text is as long as it right... > > <hs> OK, so we have reached consensus between us for changing the text > of 2462bis. We like our original paragraph because it clearly mentions > manual configuration, which is not mentioned in your suggested > paragraph. Well, we reached agreement, not quire consensus.... In this particular case, manual configuration is just an example. There may be other means of forming the same address. Regardless of how the address was assigned, the issue is that skipping DAD is bad. You wanted to document a rationale, and for why, and that is what we should do. The final recommendation stays the same. -vlad > > Thanks. > > - Hemant & Wes > > Something like: > - Each individual unicast address SHOULD be tested for uniqueness. > Note that there are implementations deployed that only perform > Duplicate Address Detection for the link-local address and skip > the test for the global address using the same interface > identifier as that of the link-local address. Whereas this > document does not invalidate such implementations, this kind of > "optimization" is NOT RECOMMENDED, and new implementations MUST > NOT do that optimization. This optimization came from the > assumption that all of an interface's addresses are generated from > the same identifier. However, the assumption does not actually > stand; new types of addresses have been introduced where the > interface identifiers are not necessarily the same for all unicast > addresses on a single interface [RFC3041] [RFC3972]. > Additionally, > hosts that implement the "optimization" may end up configuring > duplicate addresses and causing network disruptions. Requiring to > perform Duplicate Address Detection for all unicast addresses will > make the algorithm robust for the current and future such special > interface identifiers. > > -vlad > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
