Nicolas Williams writes: > The RFC explains why it's bad to manually configure LLAs. And though it > doesn't say MUST NOT, it does say SHOULD NOT, and that provides enough > cover. And while this SHOULD NOT does allow us to allow manual > configuration of LLAs, we ought to have a good reason to ignore that > SHOULD NOT, and any reason rejected by the IETF is not a very good > reason for us to use for justifying an opposite decision.
I think that misses both the intent and the language of section 1.6. The intent of that section is to prohibit *administrators* from using the LLA subnet for their own allocation purposes. They shouldn't try to treat it as roughly equivalent to RFC 1918, which many will likely be tempted to do. The implementations might not have the right duplicate detection support to make such usage safe (fortunately, not an issue with Solaris), and there are special problems that can occur if the addresses are (mis)configured into a DHCP server. It clearly does not say whether an implementation must or even should _refuse_ to allow such a configuration to be set up. Usually, I would say that such things are in the realm of "local policy." Instead, it says that if you can do it, don't. In this case, I think Kacheong's proposal to rope off 'lla' as special and prohibit its use on more than one interface is going a bit above the call of duty. I wouldn't even say that's required as there are *MANY* ways that users can shoot themselves in the foot if they don't understand how IP addressing and routing work. Blocking off one source of harm seems relatively unhelpful to me, but since Kacheong wants it and is doing the work, I won't argue with it. The one point of contention I see here is whether LLA itself is defined by the use of the subnet (as Erik has been arguing) or if it's defined by the subnet plus the random-probe-and-assign mechanism (as Kacheong is saying). The latter definition is tighter and allows for the (mis)use of the LLA subnet as a compatible evolution of the system, but I can see how others would assume that the subnet itself is architecturally defined (by the IETF) to be off limits. In any event, I don't think this is all that serious an issue, as any of the alternatives in this area that've been proposed would work fine. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
