2012-12-21 12:00, Ole Troan <otr...@employees.org> :

> Remi,
> 
>>> there appears to be quite a lot of pushback in 6man against the use of u/g 
>>> bits as specified in the 4rd draft.
>> 
>> FUD, yes, but technically founded pushback that haven't been answered, no 
>> one left AFAIK. 
> 
> I can't parse the above.

Fair enough.
I mean that,  AFAIK, all technical objections to u=g=1 being used for new IID 
formats have been answered.
I do understand that some may feel differently, and that in this case the 
debate must go on to reach common enough understanding. 
That's why I continue to provide explanations on technical points that, in 
others' opinions, appear to be unresolved.  


>> For instance, in you own long list of doubts, you included:
>> - The need to "update every implementation". It definitely doesn't exist.
> 
> can you please explain that? given that a RFC4941 implementation may create 
> interface-id's that conflict with the 4rd
> reserved range.

Privacy option IIDs (RFC 4941) all have u=0. They cannot conflict with 4rd IIDs 
which all have u=1 .


>> - The view that "we should design protocols that do not depend on well known 
>> addresses or ports". This doesn't concern 4rd which uses neither WHA nor 
>> WKP. 
> 
> well-known or reserved range. I'm not in favour of either.
> 
>> With these two in particular, one can get the impression that your are 
>> trying to oppose 4rd by all possible means. Without  clarification of when 
>> your chair hat is on or off, this is unfortunate IMHO. 
> 
> chair off, I thought I made that clear. I have asked Bob to make the call on 
> this. I don't believe you are in a position to declare what consensus of the 
> 6man working group is either. ;-)

The fact that the chairs are in charge of identifying consensus is crystal 
clear to me.
I just express my opinion when I believe it is useful to the community.


> I'm not trying to oppose 4rd by "all possible means". I'm trying to limit 
> collateral damage to IPv6 specifications and implementations.
> I think that 4rd would function perfectly well without any reserved 
> interface-identifier space. do you disagree with that?

Yes, we do disagree on this:
- With the reserved IID range, 4rd can be activated in any IPv6 site without 
interfering with its subnet assignments, and without any host having to be 
renumbered because of a conflict with a 4rd IPv6 address. 
- This wouldn't work if 4rd IIDs would have u=0, because some hosts having 
RFC4291-compliant IIDs may be in conflict.
- MAP-E hasn't the same need because implementations can use the protocol field 
to discriminate MAP-E packets from native IPv6 packets. 

Regards,
RD



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to