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]
--------------------------------------------------------------------
