2012-12-20 à 16:50, "Bless, Roland (TM)" <roland.bl...@kit.edu> :
> Hi Rémi, > > On 20.12.2012 09:54, Rémi Després wrote: >> Interface addresses at the link layer are specified by IEEE to be >> universally unique. This has been effective fort link-layer >> communication to need neither manual configuration nor a DAD-like >> protocol at this layer. > > IEEE link layer addresses should be universally unique, but there > were cases in which this assumption is not true, esp. if you consider > that some manufacturers simply hijacked others OUIs or that most NICs > and drivers allow to set nearly arbitrary MAC addresses. > Moreover, there are now vast amounts of virtual machines in use that > may use non legitimate IEEE addresses. So IMHO one should not rely on > supposed universal uniqueness, but always perform DAD to detect > conflicts... No disagreement. Systematic DAD can be recommended, but without ignoring that RFC 4291 permits to skip it for IIDs that have universal scope (u=1). >> At the IP layer, it has also been effective to support a good level >> of address stability without needing manual configurations. > > Yep, however, this is also true for algorithmically derived IIDs > as with privacy extensions or CGAs. - CGAs contribute maintain address stability, true, but also true that EUI-64 IIDs having u=1 contribute too, and have been largely deployed, and this is no reason to abandon the current meaning of the u bit. - "Privacy" and "address stability" are to a good extent contradictory. To get privacy, EUI-64 IIDs are out of scope. >> Address stability is useful for servers, yes, but also for referrals, >> and in general when addresses are advertised in various ways. > > My point was that statically assigned IIDs may lead to even more > stable IPv6 addresses than those generated out of EUI-64s. Same view on this too, but not forgetting that, in well-behaved hosts, statically assigned IIDs MUST comply with RFC 4291 (and therefore not have u=g=1). > >> Relaxing uniqueness of IIDs that are based on universal-scope EUI-64 >> would be a step backward. There is no need AFAIK for such a >> regression. > > I never promoted to "relax the uniqueness of IIDs" (whatever that > means), No disagreement on this, then. > my point was to avoid introducing a certain structure into > IIDs. There is no structure today in IIDs that have u=0", but there is one in RFC 4291 for those that have u=1. Abandoning it would be a step backward. >>> what new types of universal-scope addresses? >> >> One appears now with 4rd. As stated in the note of the draft >> submitted to 6man, "Its function is to ensure that 4rd IPv6 addresses >> are recognizable by CEs without any interference with the choice of >> subnet prefixes in CE sites". These prefixes, as well as IIDs used in >> sites that support 4rd may have been chosen before 4rd is activated. > > Yes, I read that, but it's unclear to me why it would be such a big > deal to "reconfigure" the subnet prefixes for 4rd use since you have > to activate and configure your box anyway, i.e., maybe you can > flag an existing prefix for 4rd use when turning 4rd on. Moreover, > would it really be such a big deal to change a subnet prefix when > turning 4rd on, since we have auto configuration? Whether it is a big deal or not to reconfigure can be debated but, AFAIK, that operation is simplified if the need for such reconfigurations is avoided by design. Hoping this helps to reach common understanding, Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
