[arin-ppml] IPv6 Non-connected networks
christopher.morrow at gmail.com
Mon Feb 22 10:05:13 EST 2010
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>
>> 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
>>> 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
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
> 18.104.22.168 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?
More information about the ARIN-PPML