Subject: Appeal Response - Request To Advance : "Unique Local IPv6 Unicast Addresses"

From: Brian Haberman <[email-masked]>
Date: Tue, 24 Feb 2004 13:48:31 -0500

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.

>- 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 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.  There are
similar blocks of addresses in IPv4.

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

>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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Fri, 27 Feb 2004 14:53:09 -0800

On Feb 24, 2004, at 10:48 AM, Brian Haberman wrote:

>> I found it very unfortunate that the chair decided to request to 
>> advance this document

My appeal is not on the process but on technical merits,

>
>> - Permanent allocation is equivalent of selling address space, which 
>> is very different from
>>   More, this is imposing a business model to the entity that will be 
>> in charge of the allocations,
> 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
> draft is the same as selling address space.

We clearly differ here.

>  We also note that there are
> 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

Nothing with the same scope as what is proposed here.

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

>> - The document does not contain any wording recommending against the 
>> 'all zero' self allocation.
>>   It merely say that:
>>    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.

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.

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

>> places the quality and/or integrity of the Working Group's product(s) 
>> in significant
>> jeopardy.
>>

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.

---

From: [email-masked]
Date: Sat, 28 Feb 2004 07:57:10 +0900

>         and without any procedure for de-allocation."

	i support Alain 100%.

itojun

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Feb 2004 20:23:15 -0500

Alain,

>   of this wg to document that using that particular pattern can be 

I think I understand your point here.

> allocations have to be permanent.  There is a requirement to make
> those addresses stable in time, but this is very different from
> permanent allocation.

Let me ask you this then. If the word "permanent" is not appropriate,
what word is? To me, "not permanent" means that at some future time an
allocation that has been made to an endsite may be revoked. But this
begs the question of why an end site would ever want to use such
addresses. I.e, this raises such questions as:

 - under what conditions would an address be reclaimed?
 - who does the revokation?
 - what recourse does the  end site have?

My understanding is that the whole point of these allocations being
"permanent" is that once and ends site gets one, it can use it without
worry that it will have to give it up at some future time.

Also, why do we need to make these allocations "non permantent"? Is
there some future scenario we're worried about where it becomes
important to be able to reclaim these addresses? I.e., are they ever
going to become a scarce resource?

Also, would we ever conceive of taking back an end-site's usage of an
address block it generated under the non-centrally allocated block?
In particular, if your answer no, but yes for those from the centrally
allocated block, I'd like to understand the rational behind that
thinking.

Thomas

---

From: Alain Durand <[email-masked]>
Date: Fri, 27 Feb 2004 22:46:33 -0800

On Feb 27, 2004, at 5:23 PM, Thomas Narten wrote:
> allocation that has been made to an endsite may be revoked.

The point I'm arguing is that it is not the IETF business to decide 
this.
So not saying anything is probably the best option. Another one is
saying that the entity in charge of the allocation is required to 
provide those allocation for the long term
and not specify anything further. It is a policy decision made by the 
entity(ies) in charge
to decide what long term means.

>  But this

to be decided by the entity(ies) managing the allocation and their 
customer by contract.

>  - who does the revokation?

the entity(ies) responsible for the allocations.

>  - what recourse does the  end site have?

See the contract between the chosen entity and the customer.
Again, this is policy, not protocol. i.e. this is not IETF business.

> Also, why do we need to make these allocations "non permantent"?

I'm not asking to make them non permanent in the document, but rather 
not to
specify in an IETF document that they are permanent. This is different.
If the entity in charge of the allocations decide that permanent 
allocation
is the way they want to run their business, fine.

>  Is

I'm worried about the scenario where IETF does policy and not protocols 
anymore.

> allocated block, I'd like to understand the rational behind that

The two are different, The self generated addresses are not guaranteed 
to be unique,
so permanent/non permanent or revocation is a meaningless discussion 
for them.

	- Alain,