[arin-ppml] IPv6 Non-connected networks

[Christopher Morrow]

On Mon, Feb 22, 2010 at 9:45 AM, Michael K. Smith <mksmith at adhost.com> wrote:
>
>
>
> On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
> wrote:
>
>> On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>>>> The current kit deals with packets rather than flows. Flows was
>>>> investigated thoroughly and looks very much like a blind alley. It has
>>>> some useful niches but the failure modes are catastrophic.
>>>
>>> Yeah, I know that, but they tend to cache information regarding a flow.
>>
>> huh? a CRS or T-series device doesn't cache anything about flows. each
>> packet in turn on input is looked up in the FIB for send to the proper
>> output interface. (extreme, as another vendor also doesn't cache flow
>> info...)
>>
>>> The cache isn't big enough is the problem I am worried about.  Some gear
>>> likes to populate the routes (FIB) in hardware and if you don't have
>>> enough space, they don't all get in there. Chip density being what it
>>> is, I would think that more storage is available in the same form factor
>>> today than was available when the module was initially designed.  It
>>
>> See scudder's talk about 100g and how long you have to lookup before
>> your input buffer is full with a full interface.
>>
>> There are 2 parts to this problem (and this is wandering way off
>> topic) size of the FIB and rate of change of the FIB.
>>
>> Back to the original topic though... As to providing globally unique
>> addresses to end sites who want this for their internal uses only,
>> that seems like a worthy goal, to me. I have 2 concerns:
>>
>> 1) creating another rfc1918-ish block. (registration of this space
>> seems to avoid this)
>> 2) leakages into the global table, unintended ones. (pulling from a
>> set supernet seems to cover this concern as well)
>>
> Why wouldn't we just allocate them normally, like any other block?  If we
> don't give them the 1918'ish status then we don't have to worry about
> unintended consequences.  Instead, it's up to the end user to make sure the
> routes are not leaked but, if they are, they just end up in the DFZ with
> everything else.

one of the original ideas was to lower the bar for 'internal use only'
prefixes. For instance:

You run a large enterprise, you have some internal server things that
you want v6 for but won't ever see the light of day.
These servers/nets may interconnect with business partners today or as
you M&A your way info infamy.
You don't have 200 customers nor do you qualify for PI space (and you
don't want that anyway), ULA doesn't provide enough uniqueness
guarantee either...

I think the policy should be able to serve these folks, it should also
make sure that providers have a simple method to drop these routes on
ingress. Willy-Nilly assigning these from current allocations won't
help the route filtering problem, lowering the bar across the board
seems to be unpalatable.

> I guess I'm thinking that it would be better to change the restriction on
> 6.5.1.1 than create a new set of policies for "unconnected" networks.

6.5.8 I think is more along the lines of the proposed users though
(not LIR's but EndSites) isn't it?

-Chris