<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: Some discussion from ARIN XI


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 -





<<< Chronological >>> Author    Subject <<< Threads >>>