[ppml] [address-policy-wg] Those pesky ULAs again

[Rich Emmings]

On Tue, 29 May 2007, Paul_Vixie at isc.org wrote:

> ipv4 has been in continuous redesign since 1968 or so.  what your management
> team needs to look for isn't stasis but rather flag days.  ipv6 is well past
> its final flag day (when all existing implementations are made "wrong" and
> new silicon has to be etched everywhere at once.)

It's an excuse, not a valid one.  IPv4 updates get applied because it's 
started, and those changes don't impact the running enviroment.  IPv6 is not 
started, so those changes are an excuse "It's not ready yet.  Now stop 
bothering me and fix my computer"

I should mention here, by means of disclaimer, is my comments about 
management reflect a variety of shops, and not my current one, mostly we're 
stuffed here waiting for full vendor support _for the applications we need_. 
I've been running a dual stack for two years, in a limited fashion.  It's 
not scaleable yet.

In the late 90's not a purchase order went out without "Must be Y2K 
compliant" stamped on it (for whatever it was worth).  These days, the PO's 
need to go out "Must be IPv6 compliant" -- except that 1/1/2000 was a hard 
date, and IPv6 isn't.  We're still getting new network gear that isn't fully 
supporting IPv6, and in some spaces, there's just not a choice.

> the real problems with IPv6 are those it shares with IPv4, so let's just call
> it "the real problems with IP".  they've been argued forever and go by many
> names.  from ppml's point of view, the right name of the biggest problem is
> "lack of EID/RID split".  since we're using one address for both identity and
> location, it actually matters whether that address is universal or private,
> PI or PA, etc.  as tli pointed out fairly early on, a solution to this
> problem would have added a lot more to the IP address system lifetime than
> adding more bits has added or will add.  so, the problem isn't novel, but
> general recognition of the problem would certainly be novel.

Nothing is perfect, but it's easier to change direction once things are 
irrevokably moving forward, that to get it moving to start.


Apropos of nothing: http://www.caida.org/analysis/topology/as_core_network/ipv6.xml (slightly dated)