inline. Ole Troan wrote: > 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=1 is reserved. This leaves plenty of space for future >>>>> uses of IIDs having u= 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? my 2 cents.
If 4rd is truly experimental then indeed I think it's up to the operators deploying it to ensure they choose a unique IID range within the scope of where they are operating 4rd (between tunnel endpoints and the tunnel gateway). My initial concerns were that this could cause harm even in experimental form, but I've convinced myself that it shouldn't. In this case I see no need for a hard global IID reservation, because at the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC. On the other hand, If 4rd is not truly experimental, or it's expected to work universally across AS boundaries, I suspect the WG will have to wait for an answer to Brian's question on whether structure within the IID is desirable. I don't think there's any clear consensus so far on that point (indeed there are some counter posts saying structure within the IID is undesirable). My own particular concern here is that there is a danger of creating a precedent of a completely new class of IPv6 addressing by the back door without this being fully and properly debated i.e. address ranges that don't perform DAD, and that are associated directly with a certain tunnel or transport protocol, and yet which are assigned within the generic GUA space, but perhaps which overlap with other IPv6 prefix spaces too. e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by 6to4 (2002::/16) being associated with 4rd IIDs? e.g. 2 How would this new class of IID encoded ranges/tunnel/transport protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08 (both of which assume that bit-contiguous left-anchored IPv6 prefixes map to transport protocols, not individual IID bits)? These questions probably have little relevance to 4rd being deployed in an experimental situation, and I think we should perhaps try to keep them decoupled as far as possible. > 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 --------------------------------------------------------------------
