Hi, Eliot, On 04/22/2013 11:22 AM, Eliot Lear wrote: >>> With this >>> document, I wonder if quite a bit could be removed. >>> >>> Specifically, a great deal of discussion goes into the PRF involving DAD >>> counters, etc, when all that is needed is a suitable PRF. >> Not sure what you mean...What's thetext that you think could/should be >> removed? > > Sorry I wasn't clear: what is the benefit of specifying the algorithm, > when simply popping out another PRF will in just about any instance do > the job (unless you are reinitializing the PRF with the same seed)? There seems to be a disconnect here: We want an algorithm that, roughly speaking, whenever you connect to the same network, gives you the same address. But such address should be different for each network you connect to. The question here is: How do you achieve that? You might argue that, clearly, the autoconf prefix needs to be part of the seed (I'd personally not expect developers to figure this one out). But there are more issues. e.g., say that my node has to network interfaces. If I use both of them to connect to the same network, the address they get should be different (but still have the same properties stated above). How do you achieve that? -- Well, yu need *something* that changes from one interface to another. But even if you figure *something* you mght use for that it might be non-optimal. -- for example, if you use the MAC address, then your address changes if you replace the NIC. If you use the interface index, it doesn't. At the end of the day, the devil lies in the small details. And I'd argue that if it had all been that obvious, it'd have been done before. >>> The draft in >>> fact says this in Section 3 after an explanation of the inputs. Any PRF >>> that follows the guidelines of RFC 4086 should do fine and not cause >>> interoperability OR security problems. >> If you're referring to the text that explains why we're not mandating >> any specific PRF, that text is there because the issue was raisen in the wg, > > Ok. So what I gather is that there was a negotiation within the WG and > that the algorithm is optional. The "negotiation" was that this dspec does not replace the traditional slaac algorithm that, in the case of Ethernet, embeds IEEE identifers in the Interface ID. > Ok. From an outside point of view, I > didn't need to know that, and the question is what was the value of > still specifying the PRF. I think Ran Atkinson answered that. He feels > he wants a fully specified algorithm from which to start. Ok. My only > response is that I don't understand the need (generating 64 bits that > aren't the same shouldn't be that hard), but if the WG really believes > there is one, okay. We're not just "randomizing" the addresses. The are *constant* within each network, but change across networks. >>> Also, the following text in section 3 Page 7 is contorted: >>> >>> This means that this document does not formally obsolete or >>> deprecate any of the existing algorithms to generate Interface IDs >>> (e.g. such as that specified in [RFC2464]). However, those IPv6 >>> implementations that employ this specification must generate all >>> of their "stable" addresses as specified in this document. >>> >>> My suggestion is to simplify remove it as it is self-evident. >> What's the part that is evident? The one about not deprecating existing >> algorithms? -- Because the other ne certainly isn't: if you're going to >> use this algorithm for generating addresses *in addition* to those >> generated by traditional SLAAC, then this document wouldn't mitigate >> address-scanning attacks. > > How would an IPv6 implementation employing this specification vary from > this specification in a way you or the working group would find > objectionable? If, for the same interface you employ this algorithm *and* the traditional SLAAC algorithm, that's objectionable. > Also, did you mean "MUST"? If not, this language is all > the more confusing and I don't know what you mean. Yes, I meant "MUST". -- I will fix this. >>> Finally, this algorithm requires that the resultant host portion be 64 >>> bits. Is that necessary? >> Well, yes- If the PRF produces a bit string larger than 64 bits, and >> you say nothing about how you grab the IID, then the algorithm is >> underspecified. >> >> The easier it is for a developer to go through this document and come up >> with an implementation, the better. The more the open questions, the worse. > > I think we are underestimating our developers but if the working group > feels differently, okay. I don't think so. Lots of folks code on so many different areas, that it'd be unrealistic to expect them to figure everything out by themselves. Yes, there are some smart folks that can figure a lot by themselves... but that's the exception rather than the rule. And even if they were all that smart, we want to make their lives easier: the less they have to figure out by themselves, the better. > I asked the above question because it is at > least conceivable that at some point host portion != 64 bits and this is > the only place in the document where the requirement is stated. Yes, > screwing with the 64 bit boundary today is bound to cause all sorts of > breakage. My understanding is that we're all set for 64-bit identifiers -- with the exception of point to point links where subnets < 64 bits are allowed (fro the most part, as a workaround to buggy implementations that are vulnerable to NCE attacks). > I'm not thinking of today but the future. And yes, another > argument would be that there isn't enough address space for this to be > effectively private. Those are two different issues, but fixing the > boundary here reminds me of mistakes we made with IPv4 way back when. > In this day and age we're talking about a lot more cleanup later. I guess this raises a more fundamental question with respect to whether we want 64-bit identifiers to be the standard, or not. A compromise might be to add a *parenthetical* note such as: "The current IPv6 Addressing architecture defines Interface-Identifiers to be 64 bits long, hence the low-order 64-bits of F() are employed for the Interface-ID. Were the IPv6 Addressing Architecture updated to allow any arbitrary length for the Interface ID, an implementation would need to be prepared to select as many bits from F() (rather than the fixed 64-bits specified above) for the Interface ID, such that an Interface ID of appropriate length is obtained" I'd personally have no issues with that *if* the wg agrees. But I wouldn't want to remove the text on grabbing the low-order 64-bits, since that's makes the spec more clear for the current times. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492