Brian, you're quite right. I had in mind only one particular class of IID.
Washam, see Appendix A of RFC 4291 regarding modified EUI-64 IIDs
with "u"=0. Also, RFC 3041 has been obsoleted; see RFC 4941 and
its errata if privacy issues apply in your situation.
-K-
On Fri, Jul 15, 2011 at 6:25 P
The authors of RFC 4291 chose not to use the upper case normative
keyword convention defined in RFC 2119. Therefore, 'required' means
what in means in plain English (i.e. REQUIRED in RFC2119ish).
Brian
On 2011-07-15 19:03, Washam Fan wrote:
> Hi,
>
> I quoted this paragraph from RFC4291:
>
>
In your letter dated Fri, 15 Jul 2011 09:31:12 -0400 you wrote:
>To some extent, I would prefer an approach where IPv6 Ops would work
>on that informational document (threats/concerns, operational use cases,
>existing mitigations that could be deployed) first. Then, if there
>were use cases not ad
On 14 Jul 2011, at 23:00 , Joel Jaeggli wrote:
> On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote:
>
>> On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote:
>>> There appear to be several different cases, which can be addressed
>>> by different reasonable mechanisms (not firewalls, and not
See also section 2.5.4 of RFC 4291:
"All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
described in Section 2.5.1."
So I'd say the answer is the IID MUST be 64 bits long, and MUST
satisfy the properties of u
Hi,
I quoted this paragraph from RFC4291:
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
But I am not sure how to interpret the text in a correct way.
If I ass
