[arin-ppml] IPv6 Non-connected networks

[Michael K. Smith - Adhost]

On 2/22/10 9:05 AM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> 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.

It seems like we're back to ULA again.  It seems that we all want the same
thing, "unroutable" address space for internal use only.  There are any
number of reasons to have RFC 1918'ish space in v6 and the real difference
now is that, given the size of the v6 address space, we don't have to
allocate blocks to be used by all providers.  Instead, we're in a position
where we *can* give everyone their own block.

We could even do the old multicast thing and auto-assign a ULA (or whatever
it's called) block to each ARIN allocation.  In thinking about it, I do
agree that having a defined block for filtering purposes is preferred.
> 
>> 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?
> 
Agreed.  It might even need to be a 6.5.10.

Regards,

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100222/c22a31b6/attachment.htm>