> -----邮件原件----- > 发件人: Rémi Després [mailto:[email protected]] > 发送时间: 2009年12月10日 22:25 > 收件人: Brian E Carpenter > 抄送: Christian Huitema; [email protected]; Xu Xiaohu > 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL > non-0::/3 IPv6 addresses ? > > Brian E Carpenter wrote : > > On 2009-12-10 05:59, Rémi Després wrote: > >> Christian Huitema wrote : > > >>> The opening of the can of worms lies in your statement, "on IPv6 links > >>> having /64 subnet prefixes." We gained a lot of simplicity from > > >> I would however have no objection to replacing "links having /64 subnet > >> prefixes" by "links subject to the neighbor discovery protocol". > >> This, in my understanding, would avoid opening this can of worms. > > > Unfortunately, I don't think so. You have to consider the case of > > address referrals. I don't know of any magic by which a third party > > host (or application instance in a third party host, to be more precise) > > would know by looking at an address that it belongs to a link subject > > to the ND protocol. All it knows is that the address is, or is not, > > a unicast address whose first three bits are 000. > > The important point is that AFAIK the third party doesn't need to know. > As long as the first part of the address referral can be routed, it can > use it as destination, and leave the target network decide what to do. > > For example, it isn't necessary in a source host, and in a source > network, to recognize that a destination is an ISATAP address. > It is enough that the destination network, and destination host, > recognize it. > We know, of course, that the ISATAP address format does comply with the > "u" bit constraint, but AFAIK there is no *documented technical reason* > why, today, this couldn't have been dispensed from. > > > So either we *do* keep the rule that in such addresses u/g is > > valid, or we *don't* keep that rule. We can't make it conditional. > > Agreed, but in my understanding my proposal doesn't make it conditional. > It just restricts its scope. > > >> Unless you can come up with a real technical reason preventing such > >> simplification in the future, or someone else, it's time IMO to clean up > >> this unfortunate detail of the spec. > > > > It isn't unfortunate. > > I don't mean unfortunate *when it was stated*, just unfortunate *now* > (i.e. in a different context where more and more address fields, to be > converted in some way to produce on-link addresses, are embedded in IPv6 > addresses.) > > It was actually intended to leave the door open > > for 8+8 (as it was understood at the time), since 8+8 and GSE required > > globally unique IIDs. > > Thanks for this reference. > > Note that: > o draft-odell-8+8-00 has its unique End System Designators (ESDs) in the > first 15 bits of the 9th and 10th address octets, and they provide "for > 32768 distinct partitions in the Private Topology". They may therefore > have *any values* in "u" and "g" bits. > o draft-ietf-ipwng-gseaddr-00 distinguishes GSE addresses from others by > a GSE-specific mark in the first bits of addresses. There is no need for > any "u" bit to know that ESDs are globally unique. > > Interesting, isn't it? > > > Today's derivative of 8+8, ILNP, does *not* require > > globally unique IIDs. > > Good to be confirmed! > > > But that decision in the ILNP design might itself > > be contentious.
"ILNP requires that a Node ID is unique *within the context of a given Locator*. ILNP does not require that a Node ID be globally unique." This statement is made by Ran, the major author of ILNP. Hence it seems that the IID constrain is also not much useful for ILNP, IMHO. For more details, please see the previous discussion thread: http://www.ietf.org/mail-archive/web/rrg/current/msg05111.html Best wishes, Xiaohu > > I think we'd need some sort of community decision > > about this whole topic before taking a decision about the u/g detail. > > Full agreement on this. > That's the purpose of contributing here. > > Best regards, > > RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
