At 9:47 AM +0300 4/4/02, Pekka Nikander wrote: >Thus, I really think that we should make such a bit *reservation*... >If it later turns out that the reservation does not need to be used, >after all, the better. Then release it or use it for something even >more productive.
Pekka, I think that making such a reservation is not *quite* as harmless as you imply. If I understand correctly, if we were to agree today to reserve a bit in the IPv6 IID (or a subrange of the IID space), the Mobile IP folks would then immediately proceed to put some language in the Mobile IPv6 spec requiring (or forbidding) certain behavior for packets carrying (or not carrying) IIDs from that reserved space. If we then get a large number of deployed IPv6 nodes that conform to that Mobile IPv6 specification, that would effectively limit any potential future use of the reserved IID space to only those uses that are compatible with the Mobile-IPv6-mandated behavior. To be less abstract: if the Mobile IPv6 spec says "don't do RR for addresses with IIDs in the reserved space", and if we get a large installed base of nodes obeying that requirement, then we effectively lose the ability to have RR applied to any addresses that use the reserved IID space. That limits what the reserved space can be used for in the future. Maybe that's a consequence we will decide is acceptable, given our best current guess at the potential benefits of the proposed crypto-IIDs, but we should be aware that a trade-off is being made. Designing for future extensibility is hard, and certainly requires more than just reserving a block of space. The fancy encoding of the Type field in IPv6 Hop-by-Hop and Destination options is an example of the sort of thing you probably have to do to "get it right", but I am certainly not suggesting that we do that within the IID field! Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
