On Feb 24, 2004, at 10:48 AM, Brian Haberman wrote:
Alain,
At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we are responding as such.
I found it very unfortunate that the chair decided to request to advance this document
without answering two major issues I raised during the last call:
Before forwarding the document to the IESG we reviewed the discussion of
all issues raised during the w.g. last call and concluded that the
current draft resolved issues where there was a consensus to make
changes. There were many significant changes (e.g., removing the
requirement to charge for the central allocations, etc.). We did not
see that there was any consensus to make the changes you requested.
My appeal is not on the process but on technical merits,
- Permanent allocation is equivalent of selling address space, which is very different from
the notion of stewardship that are now in place for any IP address allocation today.
There are a number of legal questions not answered around this point.
More, this is imposing a business model to the entity that will be in charge of the allocations,
and I believe that the IETF should refrain from imposing business model.
We believe that the current draft is very clear that it is not imposing a business model. It clearly states a set of requirements for how these
prefixes should be allocated. Earlier versions of the draft may have had that issue, but based on comments received during the working group
last call, this text was changed. In addition there were a number of
comments from Geoff Huston on the business model issue that led to
changes in earlier versions of the draft.
We do not agree that permanent address allocations as called for in this
draft is the same as selling address space.
We clearly differ here.
We also note that there are
other types of IPv6 addresses that are allocated in similar manner. This includes link-local addresses, site-local addresses (currently
being deprecated), multicast addresses, and NSAP addresses.
All those blocks have different purposes and much narrower scope. Also, they are not assigned to
end users. As the draft says, those addresses
are to be treated as global unicast and there is no precedent for allocating such global unicast addresses
to end users.
I maintain that the legal ramification of the proposal have not been explored enough.
There are similar blocks of addresses in IPv4.
Nothing with the same scope as what is proposed here.
The Unique Local Addresses defined in the draft meet a clearly defined need that has been discussed at great length in the working group. The
permanency of these addresses is an important part of the requirements.
Another point where we differ. I dispute this requirement.
There is no technical rationale for making those allocation absolutely permanent.
There is a strong rationale to make sure they can be stable over a reasonably long period
of time, but this is very different from permanent.
They are by definition different from how other global IPv6 unicast addresses are allocated and managed. This is why they were defined in the first place.
- The document does not contain any wording recommending against the 'all zero' self allocation.
It merely say that:
"Locally assigned global IDs MUST be generated with a pseudo-random
algorithm consistent with [RANDOM].". However, it should be noted that [RANDOM]
or RFC1750 does not contain any mandate, just provide ideas on how to do things.
An 'all zero' self allocation would create the prefix FD00::/48 and will be very tempting
to use by many.
This working group just spend more than a year to deprecate the site local
fec0::/10 prefixes, just to reinvent it here.
When you raised this issue on the mailing list the subsequent discussion
indicated that the document was very clear on what was required (i.e., what MUST be done as you quote above) and that there wasn't any reason
to provide a list of exceptions to this. Quoting from Christian
Huitema's email dated Wed, 28 Jan 2004:
"The draft already says that we MUST assign these numbers exactly one
way. Why on earth would we need to enumerate the 25 ways that should
not be used?"
You forget my answer to this question: because the wg spend a huge amount of valuable time
to deprecate those addresses and I contend that this draft as written today provides a way to re-introduce them.
You logic seems to be that we are reinventing site-local addresses because we only describe what someone MUST do and do not describe how to
turn this back into site-local addresses. We believe your suggestion would have the opposite effect from what you desire.
I do not believe in security through obscurity, It is better to clearly articulate the danger of using the specific
all zero pattern, IETF wgs have a moral obligation to point to potential issues when they are well known,
Again, after so much time spent in the wg discussing the SL issues, I think it is not appropriate to just push
the issue under the rug.
Also, if someone
wants to use site-locals, they can just ignore the deprecation document and keep using them. Why would they need to bother to use this prefix.
Different issue, The responsibility of the wg is to point that there is a potential problem here,
See Tim Chown Email a few days ago and you'll find a simple way to address the issue I'm pointing at.
As the request to advance this document came from the Ipv6 wg chairs, representing the wg,
it is my opinion that the IPv6 Working Groug has made an incorrect technical choice which
places the quality and/or integrity of the Working Group's product(s) in significant
jeopardy.
As the request to advance this document has already been sent to you, ADs,
this is my appeal to you to reject it and send it back to the working group.
For the reasons stated above, we do not agree that our action was incorrect and deny your appeal.
Regards, Brian Haberman and Bob Hinden IPv6 Working Group Chairs
For the reasons stated above, I still believe that the wg is making an incorrect decision by allowing
this document to progress as is and I maintain my appeal to our AD.
Dear ADs, consider this mail as my second step in the appeal chain.
Specifically, the part I object to are:
- under the FD00::/8 prefix (Locally assigned):
using the 'all zero' pattern instead of random bits would have the exact same effect
as using the 'site local' address: it would create ambiguous addresses. The ipv6
wg spend over a year deprecating 'site local' addresses for that reason. It is the duty
of this wg to document that using that particular pattern can be harmful.
-under the FC00::/8 prefix (Centrally assigned:)
the document says that:
" The requirements for centrally assigned global ID allocations are:
- Available to anyone in an unbiased manner.
- Permanent with no periodic fees.
- Allocation on a permanent basis, without any need for renewal
and without any procedure for de-allocation."I object that there is any technical requirement to mandate that the allocations have to be permanent.
There is a requirement to make those addresses stable in time, but this is very different
from permanent allocation.
Also, the entity managing the allocations should have the possibility to reclaim addresses
under circumstances to be determined.
But more important, the IETF should stick to protocol design and should not wander in
economic/business model territory by mandating any kind of fee structure.
Let me reassure you that I'm not doing this in a hopeless effort to stall the process,
but because I honestly believe that the issues mentioned above must be carefully examined
by people outside of this working group.
- Alain.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
