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

[Fred Templin <ftemplin at iprg.nokia.com>]

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
ftemplin@iprg.nokia.com

Tony Hain 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. 
> 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: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] 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
> > > ipv6@ietf.org
> > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >      
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >    
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>  


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------