<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Re: [arin-ppml] IPv6 Non-connected networks</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>
<BR>
<P><FONT SIZE=2>On 2/22/10 9:05 AM, "Christopher Morrow" <christopher.morrow@gmail.com><BR>
wrote:<BR>
<BR>
> On Mon, Feb 22, 2010 at 9:45 AM, Michael K. Smith <mksmith@adhost.com> wrote:<BR>
>><BR>
>><BR>
>><BR>
>> On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow@gmail.com><BR>
>> wrote:<BR>
>><BR>
>>> On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser@seven.com> wrote:<BR>
>>>>> The current kit deals with packets rather than flows. Flows was<BR>
>>>>> investigated thoroughly and looks very much like a blind alley. It has<BR>
>>>>> some useful niches but the failure modes are catastrophic.<BR>
>>>><BR>
>>>> Yeah, I know that, but they tend to cache information regarding a flow.<BR>
>>><BR>
>>> huh? a CRS or T-series device doesn't cache anything about flows. each<BR>
>>> packet in turn on input is looked up in the FIB for send to the proper<BR>
>>> output interface. (extreme, as another vendor also doesn't cache flow<BR>
>>> info...)<BR>
>>><BR>
>>>> The cache isn't big enough is the problem I am worried about. Some gear<BR>
>>>> likes to populate the routes (FIB) in hardware and if you don't have<BR>
>>>> enough space, they don't all get in there. Chip density being what it<BR>
>>>> is, I would think that more storage is available in the same form factor<BR>
>>>> today than was available when the module was initially designed. It<BR>
>>><BR>
>>> See scudder's talk about 100g and how long you have to lookup before<BR>
>>> your input buffer is full with a full interface.<BR>
>>><BR>
>>> There are 2 parts to this problem (and this is wandering way off<BR>
>>> topic) size of the FIB and rate of change of the FIB.<BR>
>>><BR>
>>> Back to the original topic though... As to providing globally unique<BR>
>>> addresses to end sites who want this for their internal uses only,<BR>
>>> that seems like a worthy goal, to me. I have 2 concerns:<BR>
>>><BR>
>>> 1) creating another rfc1918-ish block. (registration of this space<BR>
>>> seems to avoid this)<BR>
>>> 2) leakages into the global table, unintended ones. (pulling from a<BR>
>>> set supernet seems to cover this concern as well)<BR>
>>><BR>
>> Why wouldn't we just allocate them normally, like any other block? If we<BR>
>> don't give them the 1918'ish status then we don't have to worry about<BR>
>> unintended consequences. Instead, it's up to the end user to make sure the<BR>
>> routes are not leaked but, if they are, they just end up in the DFZ with<BR>
>> everything else.<BR>
><BR>
> one of the original ideas was to lower the bar for 'internal use only'<BR>
> prefixes. For instance:<BR>
><BR>
> You run a large enterprise, you have some internal server things that<BR>
> you want v6 for but won't ever see the light of day.<BR>
> These servers/nets may interconnect with business partners today or as<BR>
> you M&A your way info infamy.<BR>
> You don't have 200 customers nor do you qualify for PI space (and you<BR>
> don't want that anyway), ULA doesn't provide enough uniqueness<BR>
> guarantee either...<BR>
><BR>
> I think the policy should be able to serve these folks, it should also<BR>
> make sure that providers have a simple method to drop these routes on<BR>
> ingress. Willy-Nilly assigning these from current allocations won't<BR>
> help the route filtering problem, lowering the bar across the board<BR>
> seems to be unpalatable.<BR>
<BR>
It seems like we're back to ULA again. It seems that we all want the same<BR>
thing, "unroutable" address space for internal use only. There are any<BR>
number of reasons to have RFC 1918'ish space in v6 and the real difference<BR>
now is that, given the size of the v6 address space, we don't have to<BR>
allocate blocks to be used by all providers. Instead, we're in a position<BR>
where we *can* give everyone their own block.<BR>
<BR>
We could even do the old multicast thing and auto-assign a ULA (or whatever<BR>
it's called) block to each ARIN allocation. In thinking about it, I do<BR>
agree that having a defined block for filtering purposes is preferred.<BR>
><BR>
>> I guess I'm thinking that it would be better to change the restriction on<BR>
>> 6.5.1.1 than create a new set of policies for "unconnected" networks.<BR>
><BR>
> 6.5.8 I think is more along the lines of the proposed users though<BR>
> (not LIR's but EndSites) isn't it?<BR>
><BR>
Agreed. It might even need to be a 6.5.10.<BR>
<BR>
Regards,<BR>
<BR>
Mike<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>