Re: [GLOBAL-V6] Comments on AP Consensus

[Thomas Narten <narten@us.ibm.com>]

Dave Wilson <dave.wilson@heanet.ie> writes:

> > In addition, with IPv6, people *will* *not* accept end sites' routes
> > in the default free zone.  Some providers that already do IPv6 have
> > pretty clearly stated that.

> Yes. This, combined with the proposal under discussion, combined with 
> the fact that the multihoming groups have not yet reported, means that 
> in effect the RIRs are now effectively deciding who may have the ability 
> to decide their own routing policy. This was not the case in IPv4.

I disagree with this assessment. For one thing, this policy only says
what is allowed under *this* policy. It does not preclude other
policies being developed that address other concerns, or preclude a
future revision of this policy.

And, BTW, I believe some more work is needed to deal with, say sites
that need more than a /48. But I think we should not hold up this
policy for that.

Also, the RIRs have little influence over what the ISPs actually route
and don't route. IMO, I expect that the DFZ will carry a number of
prefixes longer than /32s, so long as doing so doesn't cause problems
in practice. But once filtering (of any kind) takes place, it is
important that the RIR policies have been consistent with the goal
that when such filtering takes place, connectivity to *all* sites
remains likely (even if through a sub-optimal path). I.e., through a
larger aggregate.

> Any number of /48 assignments, be it 776 or 200 or any number greater 
> than 1, is a great mechanism for deciding who will make lots of 
> assignments (DSL make lots, NRENs make few) but is not a good mechanism 
> for deciding how many actual addresses will be used, and definitely not 
> a good policy for deciding who may multihome.

This policy does not take a stance on multihoming and is NOT
incompatable with multihoming.

Giving all end sites a portable address, however, which may seem to
support multihoming in the short term, has the potential for causing
great damage in the long term, should filtering be needed. In that
case, so-called "portable" addresses may in fact turn out to be
unroutable. Is that what we want to happen? BTW, RIRs have little
influence over insuring "portability", especially if "portable"
addresses end up being given to end sites in large numbers.

> IMO this policy should concentrate on getting addresses out and leave 
> the multihoming problem to those groups set up for it.

This seems to assume some magic will happen in the multihoming space,
so we don't need to worry about whether RIR policies cause routing
table explosion. I do not think it wise to assume that until we have
more evidence of an approach for which there is some consensus that it
might actually work and satisfy all the competing requirements.

> The consensus seems to be that HD is a good measurement system (I would 
> like to see the discussion on this because I don't agree that it's 
> measuring what people want it to measure).

The HD ratio is the best proposal made so far. Or, depending on your
perspective, the least worst one proposed. If you don't like it, what
do you propose as an alternative?

>     OR

> - Organisations requesting address space that do have an existing IPv4
>     infrastructure, have each of
>     * their own AS number
>     * at least /22 in IPv4 assignments to other organisations
>     * a plan for assigning address space to other organisations

> The above is ugly; the intention is to find a way to allow new IPv6-only 
> providers to enter the market and also give IPv4 providers a migration 
> path. We could time-limit this policy to be replaced when the 
> multihoming groups report, or at a maximum of 2000 assignments per RIR 
> and then stop. That does run the risk of creating a swamp, but the 
> damage is limited.

The current proposal does allow consideration of existing IPv4
infrastructure as justification for a /32 IPv6 assignment. Are the
proposed words to that effect not sufficient?

> As for strict filtering on the RIR-assigned boundary - I do see this as 
> a good thing, but if the RIRs are too strict, there will be pressure on 
> network providers to break something, and I think it is strict filtering 
> which would break first, leading to much more damage than a limited
> swamp.

I suspect that strict filtering will not come immediately, but will
come much later, when the number of routes gets large enough to push
for the need to reduce routing table size. But I could be wrong. :-)

Thomas
-
- This list (global-v6) is handled by majordomo@lists.apnic.net