Subject: Request To Advance : "Unique Local IPv6 Unicast Addresses"

From: Brian Haberman <[email-masked]>
Date: Wed, 18 Feb 2004 20:22:21 -0500

Margaret & Thomas,
      On behalf of the IPv6 working group, the chairs request the
advancement of:

	Title		: Unique Local IPv6 Unicast Addresses
	Author(s)	: R. Hinden, B. Haberman
	Filename	: draft-ietf-ipv6-unique-local-addr-03.txt
	Pages		: 16
	Date		: 2004-2-13

as a Proposed Standard.  The -02 version completed working group last
call on 02/02/2004.  This version addresses issues raised during the
last call period.

Regards,
Brian & Bob
IPv6 WG co-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, 20 Feb 2004 01:22:30 -0800

Dears ADs,

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:

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

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

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.

	- Alain.

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 20 Feb 2004 12:17:51 -0800

Alain,

The current document does not enforce a business model (earlier versions
did), but does set technical constraints. Personally I don't think it is
possible to 'Provide mechanisms that prevent hoarding', so the requirement
'without any procedure for de-allocation' creates a problem once hoarding
has been detected. I do not object to the current document as this specific
issue will be resolved by an update once the system is in operation and
practical experience exposes that flaw. 

Recommending against all-zero's is not only a waste of time, it specifically
directs people to the thing you are trying to avoid. There is nothing that a
document can do to prevent a consultant from configuring all of his
customers with the same prefix. He can run [RANDOM] once and use that
everywhere, yet is in full compliance with the document. Even more of a
problem, an equipment manufacturer could run [RANDOM] once and burn that
value into every piece of equipment they ship. The best a document can do is
highlight the issues raised by duplicate assignments, and provide a
mechanism which solves them if used as directed. As much as some people want
to, it is not the IETF's job to legislate operational behavior. The language
in this document is appropriate and it should be published.

Tony

BTW: why wasn't draft-hain-templin-ipv6-localcomm-04.txt sent at the same
time as the unique address & deprecation drafts? They are all dealing with
the same issue.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alain
> Durand
> Sent: Friday, February 20, 2004 1:22 AM
> To: Brian Haberman; Bob Hinden
> Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
> Narten
> Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses"
> 
> Dears ADs,
>

---

From: Bill Manning <[email-masked]>
Date: Fri, 20 Feb 2004 18:40:50 -0800 (PST)

% Alain,
% 
% The current document does not enforce a business model (earlier versions
% did), but does set technical constraints. Personally I don't think it is
% possible to 'Provide mechanisms that prevent hoarding', so the requirement
% 'without any procedure for de-allocation' creates a problem once hoarding
% has been detected. I do not object to the current document as this specific
% issue will be resolved by an update once the system is in operation and
% practical experience exposes that flaw. 

	its not that the document "enforces" a business model,
	it that it creates "property rights" e.g. owned address
	space.  this is -NEW- and is an area untrodden by the 
	IESG/IAB.

% mechanism which solves them if used as directed. As much as some people want
% to, it is not the IETF's job to legislate operational behavior. The language
% in this document is appropriate and it should be published.

	Operational behaviour is one thing, creating legal assests
	is something else.  This is a -VERY- bad idea.

--bill 

% Tony
% 
% > -----Original Message-----
% > From: [email-masked] [mailto:[email-masked]] On Behalf Of Alain
% > Durand
% > Sent: Friday, February 20, 2004 1:22 AM
% > To: Brian Haberman; Bob Hinden
% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
% > Narten
% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses"
% > 
% > Dears ADs,
% > 
% > 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:
% > 
% > - 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.
% > 
% > - 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.
% > 
% > 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.
% > 
% > 	- Alain.
% > 
% > 
% > 
% > 
% > 
% > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote:
% > 
% > > Margaret & Thomas,
% > >      On behalf of the IPv6 working group, the chairs request the
% > > advancement of:
% > >
% > > 	Title		: Unique Local IPv6 Unicast Addresses
% > > 	Author(s)	: R. Hinden, B. Haberman
% > > 	Filename	: draft-ietf-ipv6-unique-local-addr-03.txt
% > > 	Pages		: 16
% > > 	Date		: 2004-2-13
% > >
% > > as a Proposed Standard.  The -02 version completed working group last
% > > call on 02/02/2004.  This version addresses issues raised during the
% > > last call period.
% > >
% > > Regards,
% > > Brian & Bob
% > > IPv6 WG co-chairs
% > >
% > >
% > >
% > > --------------------------------------------------------------------
% > > IETF IPv6 working group mailing list
% > > [email-masked]
% > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% > > --------------------------------------------------------------------
% > 
% > 
% > --------------------------------------------------------------------
% > IETF IPv6 working group mailing list
% > [email-masked]
% > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% > --------------------------------------------------------------------
% 
% 
% --------------------------------------------------------------------
% IETF IPv6 working group mailing list
% [email-masked]
% Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% --------------------------------------------------------------------
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Feb 2004 13:26:09 +0000

> in this document is appropriate and it should be published.

I agree, but I think Alain is right here so could the document not point 
out at least why all zeros is bad?  I recall asking the same question in
Minneapolis...

I would add a third paragraph in 3.2.2 after the RANDOM paragraph that
says something like:

"The use of random IDs in the locally assigned Global ID prefix gives an
 assurance that any network numbered using such a prefix is highly unlikely
 to have that address space clash with any other network that has another
 locally assigned Global ID prefix allocated to it.   This is a particularly
 useful property when considering a number of scenarios, e.g. networks that 
 merge, overlapping VPN address space or hosts mobile between such networks."

I'm sure those words could be improved, but it at least gives the carrot
or incentive to the reader (who might otherwise think "why should I have
to type in 8 random characters in my prefix when zero would work?").

Tim

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Feb 2004 10:10:04 -0800

Tony,

I agree that 'draft-hain-templin-ipv6-localcomm' has served the useful
purpose of focusing the discussion, but (like an RFP or BAA) its sole
purpose was to issue a call for solution alternatives; not to propose
solution alternatives or otherwise seek a more active role in itself.

As such, I believe the 'hain-templin' document should remain current
only until an acceptable solution has been identified and progressed.
Thereafter, the 'hain-templin'  document should gracefully expire
with perhaps a "tombstone" marker left behind as a matter of
historical record, i.e., I don't believe any further progression
will be necessary.

Regards,

Fred L. Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Feb 2004 10:16:01 -0800

Bill,

Whether or not this would be new and untrodden, I believe
we need to step forward together into the unknown - under
the confidence that careful monitoring and any necessary
course-corrections will see us through the uncharted waters.

Regards,

Fred L. Templin
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Tue, 24 Feb 2004 10:09:48 -0800

Alain,

Speaking only as an individual wg participant, I appreciate the concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local deprecation.

Please consider that published documents are by no means  fixed for
all time; rather, there is clear past precedence for course-corrections
once operational experience is gained, e.g., through supplementary
documents, BCPs, updates to existing documents, etc. (We are in
fact seeing numerous instances of the latter in current wg activities.)

Regards,

Fred L. Templin
[email-masked]

Alain Durand wrote:

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Feb 2004 22:13:20 -0800

> through for site local deprecation.

No. Stalling tactics go nowhere. I sincerely believe that there are 
some serious issues
in the document in its current form. I also believe that those issues 
are fairly
easy to address.

I'm not a partisan of Site Local nor a partisan of those new local 
addresses.
However, if the wg decides to go with it, fine. Once the issues I've 
raised
are taken care of, I'd like to see this document progress quickly so
the wg could move on to other important topics.

> fact seeing numerous instances of the latter in current wg activities.)

I understand that. This is not the case here. There are known issues at 
this point,
they are not difficult to fix, let's fix them now. This is the 
responsibility of the wg.

	- Alain.

---

From: Bill Manning <[email-masked]>
Date: Wed, 25 Feb 2004 10:40:24 -0800 (PST)

be prepared to defend yourself in court(s) in any number of
 jurisdictions.  You should check w/ the RIRs on their role/position
 wrt legal precident on address/prefix ownership.  You should
 have the ISOC/IETF legal team review the creation of property rights
 by the WG chairs and the IESG.  Its not going to be easy and its
 not clear the effort justifies the exposure, at least to me.

 If you do this, I will have to rethink my use of IPv6 as tainted
 goods.  The IETF should stick to -PROTOCOL- development, not create
 property rights to be fought over in courts.

YMMV

--bill

% Bill,
% 
% Whether or not this would be new and untrodden, I believe
% we need to step forward together into the unknown - under
% the confidence that careful monitoring and any necessary
% course-corrections will see us through the uncharted waters.
% 
% Regards,
% 
% Fred L. Templin
% [email-masked]
% 
% Bill Manning wrote:
% 
% >% Alain,
% >% 
% >% The current document does not enforce a business model (earlier versions
% >% did), but does set technical constraints. Personally I don't think it is
% >% possible to 'Provide mechanisms that prevent hoarding', so the requirement
% >% 'without any procedure for de-allocation' creates a problem once hoarding
% >% has been detected. I do not object to the current document as this specific
% >% issue will be resolved by an update once the system is in operation and
% >% practical experience exposes that flaw. 
% >
% >	its not that the document "enforces" a business model,
% >	it that it creates "property rights" e.g. owned address
% >	space.  this is -NEW- and is an area untrodden by the 
% >	IESG/IAB.
% >
% >% mechanism which solves them if used as directed. As much as some people want
% >% to, it is not the IETF's job to legislate operational behavior. The language
% >% in this document is appropriate and it should be published.
% >
% >	Operational behaviour is one thing, creating legal assests
% >	is something else.  This is a -VERY- bad idea.
% >
% >--bill 
% >
% >
% >% Tony
% >% 
% >% > -----Original Message-----
% >% > From: [email-masked] [mailto:[email-masked]] On Behalf Of Alain
% >% > Durand
% >% > Sent: Friday, February 20, 2004 1:22 AM
% >% > To: Brian Haberman; Bob Hinden
% >% > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas
% >% > Narten
% >% > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses"
% >% > 
% >% > Dears ADs,
% >% > 
% >% > 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:
% >% > 
% >% > - 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.
% >% > 
% >% > - 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.
% >% > 
% >% > 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.
% >% > 
% >% > 	- Alain.
% >% > 
% >% > 
% >% > 
% >% > 
% >% > 
% >% > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote:
% >% > 
% >% > > Margaret & Thomas,
% >% > >      On behalf of the IPv6 working group, the chairs request the
% >% > > advancement of:
% >% > >
% >% > > 	Title		: Unique Local IPv6 Unicast Addresses
% >% > > 	Author(s)	: R. Hinden, B. Haberman
% >% > > 	Filename	: draft-ietf-ipv6-unique-local-addr-03.txt
% >% > > 	Pages		: 16
% >% > > 	Date		: 2004-2-13
% >% > >
% >% > > as a Proposed Standard.  The -02 version completed working group last
% >% > > call on 02/02/2004.  This version addresses issues raised during the
% >% > > last call period.
% >% > >
% >% > > Regards,
% >% > > Brian & Bob
% >% > > IPv6 WG co-chairs
% >% > >
% >% > >
% >% > >
% >% > > --------------------------------------------------------------------
% >% > > IETF IPv6 working group mailing list
% >% > > [email-masked]
% >% > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% > > --------------------------------------------------------------------
% >% > 
% >% > 
% >% > --------------------------------------------------------------------
% >% > IETF IPv6 working group mailing list
% >% > [email-masked]
% >% > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% > --------------------------------------------------------------------
% >% 
% >% 
% >% --------------------------------------------------------------------
% >% IETF IPv6 working group mailing list
% >% [email-masked]
% >% Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
% >% --------------------------------------------------------------------
% >% 
% >
% >
% >  
% >
% 
% 

-- 
--bill

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 25 Feb 2004 15:18:43 -0600

Thus spake "Bill Manning" <[email-masked]>
> be prepared to defend yourself in court(s) in any number of jurisdictions.
> ... You should have the ISOC/IETF legal team review the creation of
> property rights by the WG chairs and the IESG.  Its not going to be easy
> and its not clear the effort justifies the exposure, at least to me.

Exactly what would an allocation authority be sued for anyways?  The
property in question has no inherent value (being effectively infinite and
free) and there's no obvious basis for ownership disputes when said property
can be replaced at little to no cost.

> You should check w/ the RIRs on their role/position
>  wrt legal precident on address/prefix ownership.

As businesses that owe their livelihood to having monopolies on address
rental, I would think any position they take should be taken with a grain of
salt.

>  property rights to be fought over in courts.

As many others have noted, this is not new ground.  Nearly every number that
IANA hands out, from ports to MIME types to pre-RIR addresses, is by
convention assumed to be the permanent property of whoever it's allocated
to.  The RIRs' renting of addresses is an abberration, not the norm.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin