Re: 4rd IID range & IPv6 addressing architecture

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

2013-01-31 16:35, Ray Hunter <[e-mail]>:

>> Rémi Després <mailto:[e-mail]>
>> 31 January 2013 15:44
>> 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


> No.

I see. Thanks for the clarification. 
Sorry for having misunderstood what you meant in the following answer to my point:
>> This misses the point that 4rd IIDs are chosen to be collision-free with all possible IPv6 hosts that, in sites that use 4rd for IPv4, are configured with SLAAC (and therefore have to comply with RFC4291). 
>> IIDs of these hosts are assigned independently of any knowledge that 4rd is used or not.
> Understood. No new reservation is required. No new behaviour is required
> of existing hosts.
(At least you didn't negate that the proposed 4rd range reservation eliminates the risk of collisions with hosts that, in 4rd sites, use SLAAC.) 


Now, more comments now on what you added:

> I acknowledge that I understood that no new behaviour is required of
> existing implementations, and no existing standards need updating for
> successful experimental deployment of 4rd.

OK. This remains important.

> I do not acknowledge that a (new) global IID reservation is necessary at
> this time for 4rd to function perfectly correctly in an experimental
> deployment.

The difference you make between working "perfectly" "in an experimental environment" and working "perfectly" in some other environment, say in production environment, is unclear to me. 

The 4rd specification has been frozen for a long time now. It is only waiting for the 6man response on compatibility of its reserved IID range with the IPv6 addressing architecture. 

The decision to keep 4rd experimental has been made to avoid several similar standards, but not because of remaining issues on its ability to work in production environments. 


> In practical terms, a (new) reservation for experimental deployment of
> 4rd makes no difference whatsoever.

Well, this reservation does ensure that no other reservation can be made, at any time, which would conflict with that used for 4rd.
The registry of reserved IID ranges is precisely the place to ensure it.


> If there are few or no collisions at the IID level (as we expect), then
> there's no need for a reservation for experimental 4rd at this time.

Completed designs, if available and simple, are better than designs that are already known to be incomplete *including for experiments*. 

In this instance, no possible collisions is better than possibly a few (with additional precautions to deal with them, and risks of having to renumber). 

Is it right to suppose we can agree on this?


> If there are collisions (e.g. due to static numbering) they'll have to
> be renumbered or reconfigured before 4rd is deployed in that environment
> whether a new reservation has been made in an RFC or not. Publishing an
> RFC and registering something in IANA won't change the facts on the ground.
> 
> So unless you plan to update existing standards and/or require a
> universal update of all non-4rd-aware implementations and deployments
> (which I feel would be well beyond the spirit of the experimental status
> of 4rd) I see no significant value in the assignment at this time.

Requiring a "universal update of all non-4rd-aware implementations and deployments" wouldn't make sense at all!
If you think 4rd might introduce such a requirement, could you please explain?

The only standard-track update that is needed concerns RFC 5453, to permit an IID-range reservation for an experimental track solution that doesn't imply any "disruption to existing implementations".  


> And I don't see 6man assigning these u=1 g=1 EUI64 derived IID bits for
> any other use at the moment either.

I don't see any either... but sometimes progress needs a pioneer case ;-).

> But if the WG did decide to do that,
> that would IMHO be the time to make the reservation, and to include a
> range for exclusive use by 4rd if it was ever likely to move to
> standards track.

If 4rd may ever be moved to standard track despite its level of commonality with MAP-E, it would only be because its functional differences are then found significant enough. In view of the recent debate in Softwire, its happening in any short term is very doubtful. 

Yet, what will happen in the longer term belongs to the future.
Today, let's just do things right. 
In this instance, this means reserving the IID range that is needed for 4rd to be up to its objectives.

Regards,
RD




> 
> regards,
> 
>> 
>> 
>> 
>>> 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
>>> --------------------------------------------------------------------
>> Ole Troan <mailto:[e-mail]>
>> 31 January 2013 11:42
>> agree with what Ray says. that gives a path forward for 4rd without
>> requiring us to settle the interface-id structure question.
>> 
>> cheers,
>> Ole
>> 
>> 
>> 
>> Ray Hunter <mailto:[e-mail]>
>> 31 January 2013 11:26
>>> 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
>>>> 
>>>> 
>>> ------------------------------------------------------------------------
>> 
>> 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
>> 
>> 
>>> 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
>>> 
>>> 
>> 
>> ------------------------------------------------------------------------
>