2013/1/30, Ray Hunter <v6...@globis.net>: > 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.
Just some comments from operational views. I guess it's true operators could avoid confliction with u=1 g=1 in near future. However, I believe that is relative short-term guarantee with the condition of a particular operational domain. The term of "experimental" is not really mean "experimental" to a commercial network. It would be safe for operations if there is legitimate registry to ensure there is no need to renumbering. Therefore I prefer Remi's proposal (e) to grant 4rd 0x0300. Best Regards Gang > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
