Michel,

My $0.02 about the hash/random/collision issue: It's a non-issue.
I would agree with you, but only if I shared the same view of the
GUPI prefix usage.  That is, if GUPIs are really used only by
explicit administrator action in big corporations, then fine.
But unfortunately I don't believe so.

The prefix generation happens only one time for the site. Collisions
would not be detected until two sites merge or establish a VPN
connection.
Agreed.  Though, I can vision dynamic "sites" that are created
and dismissed fairly often.  OTOH, if we decide to define a GUPI
address space, we can formulate the usage guidelines so that
they should not be used in such a case, and that a still
another type of addresses are needed for such "sites".

The site gets its GUPI /48 prefix once, then the network administrator
configures all routers within the site with subnets that fit in that
prefix. This could be automated, but the fact of the matter is that
there needs to be a router somewhere that seeds this prefix. If what you
are talking about is automatic subnet number generation, this would be a
zeroconf issue.
Agreed.  But I can also see a "semi-automatic" case; a SOHO or non-IT
company configuring their network, and pushing a "button" to generate
a site prefix for their network.  Most probably they would not want
to pay the *trouble* of registering their prefix; still the fee might
be a non-issue for them.

A site note:  The reason for the registration fee is to discourage
prefix hoarding.  The fee can be lower than the trouble needed for
registering a single prefix.  (When registering multiple prefixes,
the trouble for the subsequent prefixes is much lower than in the
beginning, since learning is a big part of the initial trouble.)

Besides the fact that making site-locals too easy is bad, I don't see
why obtaining the prefix should be generated by a router. It is clear
that the first thing the network administrator would do is to write down
the /48 s/he will be using, and would be the one requesting the prefix
in the first place.
Hmm.  I would agree that this is the case today, more or less.
But, iff small sites become common, the situation would be different.

If I remember correctly, one of the design goals in the whole IPv6
standardization has been minimization of human intervention.  That's
the reason why we have address autoconfiguration, that's the reason
why we have been developing router renumbering etc.  Or am I mistaken?

Thus, I think that *if* we create these GUPI prefixes, their creation
should be semi-automatic.  Not fully automatic since they are not
always needed.  But, sure, we can start with a completely manual
process and revise it later, if people feel that there is some
danger is such a semi-automatic creation.

Also, whatever the random/hash algorithm is chosen and published, it
also is clear that the first thing that the network administrator would
do is to go to the web to find if someone has already written an applet
that would do the job.
There will be "sites" that do not have Internet access at the time
they want to configure their prefix.  Either they will hand pick one,
most probably causing unnecessary collisions, or the process should
be semi-automatic, with built-in assistance in routers or in router
configuration software.

--Pekka Nikander

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

Reply via email to