[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Appeal on "Unique Local IPv6 Unicast Addresses"

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

-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 

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
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6