Re: 4rd IID range & IPv6 addressing architecture

[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.

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
>>> 
>>> 
>> 
>> ------------------------------------------------------------------------