On 29/01/2013 13:18, Ole Troan wrote:
> [...]
>
>>> - If agreed on the principle, and if no one else volunteers, I can be
>>> available to propose a draft to this effect.
>> Seems reasonable.
>>
>>
>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>> IIDs having u=g=1 is reserved. This leaves plenty of space for future
>>> uses of IIDs having u=1, as explicitly expected in RFC 4291.
>> That goes to the argument of (d), that it isn't harmful to assign
>> some space to 4rd.
>
> I still think we need to answer the question Brian raised.
> should the interface-id have any encoded meaning?
That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but it is
unfortuante to make the 4rd work queue behind us. Is there any risk
in doing as Rémi suggested?
On 21/01/2013 16:19, Rémi Després wrote:
...
> With this, 6man can IMHO answer that Softwire can proceed with 4rd, provided:
> - the 16-bit IID prefix 0x0300 replaces the current 0x03
> - it is understood that IANA won't register this IID range before a 6man RFC
> permits it for this experimental-track RFC.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
