Re: 4rd IID range & IPv6 addressing architecture

[Rémi Després <[e-mail]>]

2013-01-31  11:42, Ole Troan <[e-mail]> :

> agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.

Do you mean by this that "4rd will work perfectly well _without_ this reservation"?

- If not, please clarify what you mean.

- If yes, you forgot (once more!) that this reservation is what eliminates the risk of collisions with host addresses that, in 4rd sites, comply with RFC 4291.  
In my understanding, Ray has now acknowledged this point.

RD



> 
> cheers,
> Ole
> 
> 
> On Jan 31, 2013, at 11:26 , Ray Hunter <[e-mail]> wrote:
> 
>>> GangChen <mailto:[e-mail]>
>>> 31 January 2013 08:53
>>> 2013/1/30, Ray Hunter <[e-mail]>:
>>>> 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
>>> 
>> 
>> I disagree.
>> 
>> See http://www.ietf.org/iesg/informational-vs-experimental.html
>> 
>> IMVHO "Experimental" means everything could change: including a need for
>> mass renumbering or equipment replacement.
>> 
>> Publication is "Subject only to editorial considerations and to
>> verification that there has been adequate coordination with the
>> standards process." No guarantees. The test I am currently applying when
>> reviewing this ID is whether the experiment is likely to cause harm.
>> 
>> I see no compelling reason at this time to define a global reservation
>> or an explicit IID structure in order for the experiment to be able to
>> proceed and succeed. On the other hand, adding a reservation and
>> structure to the IID at this time would likely impact other
>> implementations (e.g. packet classifiers) and existing documents and IDs
>> (e.g. address selection).
>> 
>> If you want 4rd to be "informational" or "standards track" I also think
>> that's worth discussing, but then I also think there's a lot more to
>> specify and discuss beyond the current ID.
>> 
>>>> 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
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>> 
>>> Ray Hunter <mailto:[e-mail]>
>>> 30 January 2013 16:59
>>> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------