Re: Some discussion from ARIN XI

[Kurt Erik Lindqvist <]

> There has been some discussion of portable address space at the ARIN 
> XI meeting. I'm reporting here as this may be useful to consider in 
> your own discussions about portable address space.
>
> The issues discussed were raised in these policy proposals:
>
> Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks
> http://www.arin.net/policy/2002_3.html
>
> Policy Proposal 2003-6: Micro-Assignments with Sponsorship
> http://www.arin.net/policy/2003_6.html
>
> Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks
> http://www.arin.net/policy/2002_3.html
>
> The reason 2002-3 came back was that it had received strong support at 
> the ARIN X meeting in October.
>
> Issues raised during the discussion included the following:
>
>   - Does multi-homing matter?
>   - Is load balancing from a single provider a problem?
>   - Rush for space?
>   - Impact on routing table?
>   - should the minimum allocation prefix length be reduced to /22?
>
> There was a suggestion to reduce the minimum allocation to a /21 from 
> a /20. There was also a strong assumption that provider independent 
> space should go hand in hand with multi-homing.
>
> It would be interesting to know the thoughts of people in our region 
> on these topics.
>
> Minutes of the discussions will be available from this page quite soon:
>
> http://www.arin.net/membership/meetings/mem_min.html
Somehow I think that this is not the problem we are trying to solve, or 
at least this is just a part of it. Getting addresspace for multihoming 
is not the same as getting PI space. PI space is normally desired for 
portability, and not needed to achieve multihoming. However, if more 
operators start filtering on RIR allocation boundaries, where you get 
the PA space from will become more important.

Now, the second field where this is interesting is for applicants that 
do not today qualify for getting a routable prefix. For example we 
qualify for getting PI space from RIPE for TLD servers hosted with us, 
but as the policy dictates that RIPE do not need to take routability 
into account we will get a prefix longer than a /24. The reason for 
this is most likely that a) It's impossible to enforce the role of 
verifying routability of a prefix on the RIRs (see 69/8). b) That we 
want to limit routing table growth, at least from using long prefixes.

However, for b) we could as well announce our /26 and that would still 
swamp the routingtable, and we would just not be able to use it very 
well. For a) that is true, but forcing people to use a prefix length 
that is sure to fail will not help.

In RIPE I think that we have a larger problem with second half of my 
text above, and less with multihoming. I would suggest to create a 
minimum (or maximum depending on how you see it) prefix-length, at 
least for certain critical infrastructure. If we are also looking at 
the first problem with multihoming, we will also be somewhat tied up if 
we want to have a common policy for IPv6 and IPv4.

Best regards,

- kurtis -