Brian, >>>> - 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?
it depends on what the expected meaning of a reservation is. should all implementations treat the reserved part of the interface-id as martian, and prohibit a user from configuring it for another purpose than 4rd? or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator deploying it will make sure there are no conflicts? one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where I want us to go. I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without creating any expectation that new or existing IPv6 implementations have to change. that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that we're holding up the 4rd work. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
