[arin-ppml] Simplified IPv6 policy

[William Herrin]

On Wed, Dec 23, 2009 at 4:05 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On 12/23/2009 10:52 AM, William Herrin wrote:
>> There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in
>> this proposal with its classifications that enable strong disaggregate
>> filtering. Not in existing IPv6 policy that enables less effective
>> prefix filtering. Not in the IETF's recommendations.
>>
>
>> Convincing ISPs to accept /48 cutouts from each other is in direct
>> opposition to the classification for disaggregate management that your
>> proposal creates.
>>
>> Further, suggesting that policy can't fix it is a cop-out. Policy did
>> fix it in IPv4: by authorizing /24 cutouts for multihomed entities
>> regardless of size based on the knowledge that /24's are generally
>> routable.
>>
>
> I'm not sure what you think makes /24 PA in IPv4 special, then.  It's not
> because ARIN policy allows ISPs to give them out: IPv6 PA /48s can be given
> out even more easily.  Is it just because we have a swamp of legacy class
> C's that can't be filtered?

Hi Scott,

It's because of 4.2.3.6 -combined with- the accurate expectation that
/24's are individually routable. Only in combination do these two
elements result in a functional technical solution. Even then it's
suboptimal; we'd be better off if ARIN gave out the /24. Some things
in BGP have subtle differences when its a cutout instead of a distinct
block. But I digress...

There is no expectation that a /48 cutout will be individually
routable and the policy appears to be evolving further from that sort
of use. Thus ARIN IPv6 policy needs an element functionally comparable
to the combination of 4.2.3.6 and IPv4 prefix filtering best
practices.


>> Successful ARIN IPv6 policy will have to create an IPv6 equivalent to
>> a multihomed IPv4 /24 PA cutout or else leave a well-funded class of
>> users with a solid technical basis for actively opposing IPv6
>> deployment.
>
> I proposed (and we adopted) policy 2007-21
> (https://www.arin.net/policy/proposals/2007_21.html) to address the issue of
> the class of users with legacy /24s who couldn't get IPv6 PI space.  Maybe
> once I understand what aspects of IPv4 PA /24s need to be replicated in
> IPv6, I can better understand where current policy (and current proposals)
> fall short.

I remember having something to do with that. ;) Hopefully my
explanation above helps.



>> Translation: You don't want me to deploy IPv6. Okay. I won't.
>>
>> This is an example of how needs-based allocation gets you into real
>> trouble real fast. As the gatekeeper, ARIN is stuck with this
>> damned-if-you-do, damned-if-you-don't problem which in a dynamic
>> system like 103 was solved with a trivial application of cash by those
>> willing to spend it.
>>
>> If ARIN is to be the gatekeeper then ARIN policy must solve this
>> problem. Full stop.
>>
>
> I think you're making an unfounded assumption that PI space is the only way
> to multihome.  It is true today that PI space is (mostly) routable, because
> most ISPs see filtering PI space as more problematic than carrying it in
> their RIBs and FIBs.  However, if PI space were given out like domain names,
> then that tradeoff  would no longer hold.  If, for example, we adopted 103
> as written (with your suggested fee schedule), then /48s and probably even
> /40s would be filtered by a large number of ISPs, requiring everyone
> desiring global reachability to upgrade to a /32 or go back to PA space.
>
> On the other hand, the only thing I can see preventing ISPs from accepting
> PA /48s is the lack of market pressure to do so.

It all comes back to filtering. When I see a disaggregate /48 cut out
of an ISP's /32, I can't tell whether it's a multihomed customer (that
I need to carry) or traffic engineering (which will work out OK even
if I drop it).

The price for strong TE filtering is that multihomed PA cutouts have
to be replaced with PI. Can't have both. That's just the character of
the technology.

IMHO, the potential for TE filtering is too valuable to give up and PA
cutouts never worked very well to begin with. They should be replaced
with PI.



>>>>> 6.2.3.5  Large (/28)
>>>>> To qualify for a /28, an organization must demonstrate the need to make
>>>>> assignments and/or reallocations equal to at least 20,000 /48s.
>> Why would they renumber? Your proposal allows them to hold both a /32 and
>> a /28.
> Or they could keep both, but I'd rather not force them to have two blocks
> when one will do, either.

I don't see any harm in starting with "demonstrate the need" and
changing it if a lot of ISPs "demonstrate" a need they doesn't match
their deployment.




On Wed, Dec 23, 2009 at 3:43 PM, Owen DeLong <owen at delong.com> wrote:
>> 6.2.3.3  Small (/40)
>> To qualify for a /40 allocation or assignment, an organization must qualify
>> for two or more /48s.
>
> This is in direct conflict with the statement at the beginning that an
> organization can only qualify for one block
> of each size. This problem persists in your subsequent requirements to
> qualify for larger blocks as well.

Hi Owen,

I don't see the issue. At 500 hosts you're qualified for a /48. At
1000 (or having received an order to provide service to a downstream
customer) you'd be qualified for two if two was allowed and thus a
/40. Or is it just a wordsmithing gripe?

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004