Date: Fri, 04 Oct 2002 16:34:02 +0900
From: JINMEI Tatuya <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Then the "other documents" should be considered as an implementation
| requirement?
I'm not sure what you are meaning there?
| For example, does RFC 2464 require implementations to
| use 64-bit interface identifiers (and prohibit using shorter or longer
| identifiers) on ethernet links?
No, nothing like that at all. It requires 64 bit IIDs for stateless
autoconfiguration to work, which is hardly a surprise (and defines 64 bit
IIDs for link local addresses, which is also not exciting) but apart from
that, there is no reason for that doc to express any kind of requirement
on this, and so it, quite correctly, doesn't.
| Also, does RFC 2374 require
| implementations to use 64-bit interface identifiers (and prohibit
| using others) for aggregatable global unicast addresses?
No, it doesn't. That doc kind of assumes the 64 bit IID requirement
from the addr arch doc, but nothing in it in any way depends upon that.
It is mostly concerned with the upper part of the address (how the
prefix is divided up for allocation purposes). Personally I'm not sure
the IETF should be getting involved in attempting to specify that in
any way (though giving some examples of how it might be done is fine).
But in any event, it really has no bearing on the topic being discussed
in this thread.
| I cannot be clear on those questions just from the specification
| documents.
I'm not surprised, and I sympathise. Part of the problem is that these
docs are attempting to over specify that which does not require specification
at all.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
