On 19/12/2012 14:44, Bless, Roland (TM) wrote:
> Hi,
>
> On 19.12.2012 14:21, Rémi Després wrote:
>> Could we limit the 6man discussion to the question asked by Softwire,
>> i.e. whether new IID types can be defined, using u=g=1, with a first
> ^^^^^^^^^^^^
> Sorry, I'm not yet aware of a concept called IID _types_?
> Do we really have such a thing "IID types"?
I think that's an important point. If we could make a statement like
"The IID consists of N bits that have no meaning; the only constraint
is that they must be unique within the scope of a given link and
routing prefix."
then perhaps we could move forward. Today, the u and g bits are the
only ones that make the previous statement untrue for N=64, I believe.
This would require formally updating RFC 4291, which says:
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.
s/required/recommended/ might be enough. Why is it "required" anyway?
Brian
>
>> If the answer is positive (as it seems it can be), restarting a
>> discussion on the 4rd design is unnecessary. That is only if the
>> answer is negative that Softwire will have to restart working on the
>> subject.
>
> Obviously, this question has further implications, so I
> think it's legitimate to ask whether the proposed solution
> is really a reasonable way of solving the problem.
>
> Regards,
> Roland
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
