Re: 4rd IID range & IPv6 addressing architecture

[GangChen <[e-mail]>]

Hello Ray,

2013/1/31, Ray Hunter <[e-mail]>:
>> 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.

Understood your objection.

If "Experimental" was claimed to not be "No guarantees" due to
"Subject only to editorial considerations and to verification that
there has been adequate coordination with the standards process."

I would say 4rd seems a different story.

It was proposed as "standard track".  The label of "experimental" was
made because Softwire group needs to determine the way moving on among
competing solutions, not technical limitation to a commerical network.

It's regretful to not allow 4rd with the ability since the
"experimental" is underqualified to reservation.

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

May I understand the "no compelling reason" means V bits
recommendation fits into "Experimental" status?

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

I have a different view. If there is no prompt reservation, it may
likely have such impact.

Best Regards

Gang

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