Erik,
As I recall we didn't define the U/L bit ; the IEEE did, and we decided
to invert it. And I thought the U/L bit was only part of the ID allocation
mechanism more than anything else. It has an unfortunate side effect of
appearing to add semantics to the identifier field, but I don't think it
really does so.
In your March 4 mail you wrote
> RFC 2373 does not have any way
> to introduce or identify new types of interface IDs that can be
> identified syntactically by just looking at the interface ID.
Correct, and this is exactly how an identifier field should be
-opaque, no syntax, no semantics. That is my whole point.
Brian
Erik Nordmark wrote:
>
> Brian,
>
> > In which case, I violently agree with Keith. We've already
> > overloaded IP addresses with two functions - locator and
> > identifier. We've been rebuffing various suggestions for
> > yet more overloading for years (the porno bit for example) and
> > this is in the same category - not the right place to put a security
> > hint. It's quite inappropriate to damage the opaqueness of a pure ID
> > field in such a way. If a security hint is needed, it should be somewhere
> > else.
>
> Three - not two.
> In addition to locator and identifier we also effectively encode
> how the interface ID part is allocated (by having the universal/local
> bit in there.)
> Pekka's proposal (that has been discussed in the mobile-ipv6 context)
> essentially extends the ability to encode how the interface ID has
> been allocated to carry additional information.
> Basically when the bit is set to say "don't use non-default semantics"
> it would involve some checks against the interface ID.
>
> It would be most useful if folks could read the URLs that Pekka pointed
> so that we can gain a better shared understanding of the security issues
> involved.
>
> > On a practical point, I don't see how this fits with the addressing
> > architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires
> > that "For all unicast addresses, except those that start with binary
> > value 000, Interface IDs are required to be 64 bits long and to be
> > constructed in Modified EUI-64 format." It also doesn't fit with
> > the RFC 3041 privacy extensions.
>
> I sent an email to the ipng list on titled
> Reserving bits in RFC 2473 Interface IDs?
> on March 4th.
> Since the above comment seems to be about that email I'd appreciate if you
> could recast it as a comment against that email.
>
> Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
