RE: Stupid ULA discussion

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

James, 

> -----Original Message-----
> From: james woodyatt [mailto:jhw at apple.com] 
> Sent: Wednesday, December 05, 2007 3:27 PM
> To: IETF IPv6 Mailing List
> Subject: Re: Stupid ULA discussion
> 
> The subject line on this thread is absolutely correct.
> 
> On Dec 5, 2007, at 13:32, Brian Dickson wrote:
> > Iljitsch van Beijnum wrote:
> >> ULA is LOCAL.
> >>
> >> It has nothing to do with PI.
> >>
> >> People need address space to number the links between their SQL  
> >> and web servers. This is completely orthogonal to address space  
> >> used on the internet.
> >
> > ULA is also UNIQUE.
> > (Well, for half of ULA, "probably unique").
> 
> The phrase you are looking for is "statistically unique."
> 
> "Probably," my house will still be standing in another thirty 
> years.   
> Yet, I'm still paying for fire insurance.  "Statistically," there is  
> no chance I'm going to die by being struck on the head directly by a  
> newly fallen meteorite.  Am I concerned enough about my exposure to  
> the risk of falling meteorites to worry about whether my life  
> insurance policy covers it?  Not at all.
> 
> Which gives me an idea: I should go into the insurance business,  
> selling ULA prefixes that I *GUARANTEE* (for an UNLIMITED 
> TIME!!!) to  
> be ABSOLUTELY UNIQUE or I will pay triple the cost of migrating your  
> network to a new ULA prefix when a documented collision occurs.  I  
> can do this with 5 lines of totally stateless Perl added to some  
> stupid web server- it's just a random number generator.  I'll MAKE  
> ZILLIONS FAST!

I have seen phony versions of such a "service" advertised by
others at least twice in the past; nice work if you can get it!
 
> > It would be a service, rather than a disservice, to the community  
> > of "network admins" (LAN admins), to educate them on the value of  
> > uniqueness.
> 
> And the difference between "probably unique" and *statistically*  
> unique.  Here's Brad DeLong explaining what kinds of tragedy can  
> befall the poor sod who fails to grasp the importance of statistics:
> 
> 	<http://delong.typepad.com/sdj/2007/12/intellectual-ga.html>
> 
> The key sentences...
> >> This is the principal insight of the science of statistics. it is  
> >> an important insight. It is a powerful insight. It is also not an  
> >> *obvious* insight--that's what makes it powerful and important.
> >>
> 
> Emphasis mine.
> 
> > And to point out the existence of a suitable replacement 
> for IPv4's  
> > 10.0.0.0/8 et al, if they want a non-registered, non-unique, truly  
> > non-routable address space that maps well to their current  RFC  
> > 1918 space.
> >
> > And that would be the IPv4-mapped IPv6 address space for RFC 1918.
> > I.e. ::ffff:10.0.0.0, ::ffff:172.16.0.0 and 
> ::ffff:192.168.0.0 (as / 
> > 104, /108, and /112 respectively.)
> >
> > And yes, I know it's ugly and rude.
> 
> Suresh Krishnan is correct.  Please do not suggest anything remotely  
> close to this.  Not V4MAPPED addresses.  Not V4COMPAT 
> addresses.  Not  
> 6to4-prefix addresses.  Not Teredo addresses.  Please do not embed  
> RFC 1918 addresses in IPv6 addresses full-stop.

This is exactly why we have ISATAP addresses (RFC4214).

Fred
fred.l.templin at boeing.com

> To do so is morally  
> equivalent to reinventing the functionality of the deprecated site- 
> local addresses in some other corner of the address space for 
> no good  
> purpose.  That way lies utter madness.  Go not that way.
> 
> > But it makes it easy for the end admin to manage the dual-stack  
> > universe between their SQL and web servers.
> 
> 
> If we're going to have another round of this discussion, can all the  
> participants please make a solemn pledge to read RFC 3879 all 
> the way  
> through and to ask the authors, who are both regular participants  
> here, for help with the underlying concepts if any of them are  
> confusing?  Please?
> 
> --
> james woodyatt <jhw at apple.com>
> member of technical staff, communications engineering
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6 at ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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