[arin-ppml] ULA-C

[Kevin Kargel]

> > Well said.  Even RFC-1918 space can be routed across the
> > global internet due to misconfiguration, so, I fail to see
> > how that can possibly provide the protection described.
> >
> > Admittedly, the number of misconfigurations increases in
> > inverse proportion to topological proximity, but,
> > nonetheless, lots of routing tables see RFC-1918 space on the
> > global internet due to misconfiguration.
> >
> > Why would ULA-C or any other "special" prefix be any different?
> >
> > Owen
> >
> > On Apr 11, 2010, at 7:14 PM, joel jaeggli wrote:
> >
> > > Oddly, I work for mondo-megacorp and I find it interesting
> > that you're
> > > speaking for all entities that fit that category collectively.
> > >
> > > From my vantage point ,the security posture associated with a
> > > particular prefix, service or network internal to our
> > administrative
> > > domain is defined by requirements not by some intrinsic
> > nature of the
> > > prefix.
> 
> 
I am in the camp where I do not see any real added value to ULA, but at the same time it won't hurt to provide ULA so if people want it why not.

If we really wanted to swing to the other side of the pendulum, and there is plenty of good space, then perhaps what we should do is to just automatically include a corresponding ULA allocation with each and every GUA allocation..  

It would simplify recordkeeping if the ULA pool were the same size as the GUA pool, so a mirror allocation could be made.  Then there would only need be one registration and database entry for each GUA/ULA pair assigned.

An alternate idea would be to shift the GUA address right eight bits.  For example if I were allocated GUA of 2610:188::0/32 then I could be allocated ULA at fc00:2610:188::0/48 automatically.  Again it would be such a simple repeatable pattern there would only need be one registration and could be done at no additional cost.  

Kevin