Thomas,
>> >4. Implications of Changing Interface Identifiers
>> >
>> > The IPv6 addressing architecture goes to great lengths to ensure that
>> > interface identifiers are globally unique. During the IPng
>> > discussions of the GSE proposal [GSE], it was felt that keeping
>> > interface identifiers globally unique in practice might prove useful
>> > to future transport protocols. Usage of the algorithms in this
>> > document would eliminate that future flexibility.
>
>> Can we get more words that this spec does not eliminate users who want
>> to use identifiers that are globally unique by ignoring this entire
>> spec?
>I'm not sure what more you want the document to say. Can you be more
>specific? Here is my reasoning. I think it is true that if anonymous
>addresses become widely used in practice, the fact will be that a
>large proportion of addresses will not have globally unique
>identifiers in interface identifier part of an address. It may well be
>that future uses of globally unique interface identifiers only makes
>sense if the vast majority of addresses do have a globally unique
>component. I.e, will such a scheme even be useful if only 80% of the
>addresses have unique interface identifiers? What if the percentage is
>only 50%?
OK your making it hard for me then. I do not think this spec should be
permitted to override the 4 year consensus of the IPng working group and
a lot of very contributory folks to make interface identifiers globally
unique. This spec should not be mandatory but a "suggestion". What
is happening now is what the U.S. government is doing lately. The
draft provides assistance to a "potential" threat/problem, which is fine.
But, it should be optional and not mandatory in any manner at all. But
instead because the IPng WG may accept the draft users and implementors
now are put under a set of rules that override the existing and
concensus Addr Arch document. Back to the U.S. comment analogy we use
the goverment for help but they stretch their role beyond our U.S.
Constitution as example in our country.
I don't care if 3% of the users want to have or need global unique
identifiers if they don't want to worry about random-bad-person
listening to the FDDI WDM packets its their right to with IPv6. All we
can do is provide an optional hook not mandate it and I think the draft
in that sense over steps its bounds.
>> Also I waited to respond cause I asked 3 sys admins of very large
>> networks to tell me if they would shut this off on an IPv6
>> implementation. All said yes and it appears the IETF had to play
>> some poltics here. This is just plain silly for corporate
>> Intranets.
>I tend to agree that anonymous addresses may not be appropriate in
>some environments. One of the issues you are really getting at is
>where the knobs to control useage of anonymous addresses should be. I
>think a case can be made that the site should be able to disable their
>usage (i.e, it may be corporate policy to do this). Should an end user
>have the ability to override such a policy? In a corporate setting,
>the answer is quite possibly no. But if a user is at home, and the
>policy is set by the ISP, what then?
Thats a result of the issue I am getting at. My issue is very simple.
The owner of user policy should have the right to ignore this entire
privacy issue is my point. The goal of this drafts work should be to
provide a technical means as a mechanism to prevent not a police state
view of interface identifiers within a standards document. Also I ship
products all over the world. One country might have a completely
different view of "privacy" than does the U.S. jargon and privacy
paranoid potential.
As far as the knobs thats another discussion.
>> Hence, I suggest that some words be stated that for corproate Intranet
>> traffic this is may be very unnecessary.
>How about I add the following lines to paragraph 2 in Section 4.:
>> The desires of protecting individual privacy vs. the desire to
>> effectively maintain and debug a network can conflict with each
>> other. Having clients use addresses that change over time will make
>> it more difficult to track down and isolate operational problems. For
>> example, when looking at packet traces, it could become more
>> difficult to determine whether one is seeing behavior caused by a
>> single errant machine, or by a number of them.
The words above completely miss my point. The reason a user may
not want to be protected by "individual privacy" is simply because they
think its nobodys business in the first place not to just debug
networks, which I would argue is a side-benefit of not doing any absurd
things to control the behavior of networks that have nothing to do with
implementation interoperability which this draft has nothing to do with
but in fact could cause that problem in the market.
>new line:
> Consequently, system administrators in environments where privacy
> is not a primary concern (e.g., corporate intranets) may choose
> to prohibit the assignment and usage of anonymous addresses on
> the nodes that it manages.
OK I can live with this as it does what I think the affect should be
from my words above.
But I think it important what I was getting at and will be a source of
my disagreement with many other things we work on together over the
years. Our job is to provide the implementors and market with the basic
tools to run networks and make them work. Not tell them how networks
should work, and I think we often travel down that slippery slope in the
IETF and in this draft. But I realize this whole issue caused the
problem and even the thinking. How many times do we use the phone, or
even the Internet today. I am far more paranoid and concerned that
networks become so rigid from our standards process that they perform
poorly. Using anonymous addresses is just another notch in stealing
cycles and performance from end nodes yet again in the IPv6 era of
creeping featurism as we enter the new millenia, and yet more knobs to
document for users within IPv6.
But also I think the technical solution you propose in the spec is very
elegant, I just don't think it should be mandatory, but a means to
prevent the privacy abuse potential as a "CHOICE".
thanks
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
