[ppml] 2005-1 status

[Stephen Sprunk]

Thus spake "Jeroen Massar" <jeroen at unfix.org>
> On Fri, 2006-02-03 at 10:04 -0500, Kevin Loch wrote:
> [..]
> >          3) Be currently multihomed using IPv6 connectivity to two
> >             or more separate ARIN LIR's using at least one /48 assigned
> >             to them by each LIR.

Given the below discussion, I think we can simplify this to:

         3) Be currently multihomed using IPv6.

without losing any meaning.  More detail is redundant in the final context 
of the NRPM.

> From this point *everybody* can request at least a /48. Just make a
> tunnel to Hurricane Electric and one to Hexago or a number of other
> sites where you can get such an allocation.

Good point; that's a major oversight.  Though I think the fees for doing it 
would discourage most folks, it still needs to be fixed/clarified.

> Putting down criteria is hard, probably too hard though.
> In either case scrap the "ARIN" part from the above. Some site might
> have arranged connectivity from a party in the LACNIC and one in the
> ARIN region and then they would be excluded from the above.

Sounds logical.  At least one link needs to be in ARIN's region for an 
assignment to make sense; where the rest of the links go shouldn't matter.

> Of course the question 'what is multihoming' is another nice one:

(Un?)fortunately, we already have an official definition.  From the NRPM:

    2.7 Multihomed

    An organization is multihomed if it receives full-time connectivity from
    more than one ISP and has one or more routing prefixes announced
    by at least two of its upstream ISPs.

I'd like to think tunnels wouldn't qualify as "full-time connectivity", but 
it's not clear.  When this definition was adopted it probably wasn't 
considered that someone might get IP service via a tunnel (over what?).  We 
probably need to update this if we wish to exclude tunnels, or at least 
tunnels that aren't to the same ISP that provides the physical link.

Interestingly, an org with two locations but no connection between them may 
qualify as multihomed, even if it only has one ISP at each location.  Also, 
an org with one physical connection may qualify as multihomed if it has a 
tunnel to a second ISP.  Not good.

Note that all of these holes apply just as much to IPv4 if they also apply 
to IPv6.  We either need an update to 2.7 or an official interpretation of 
"full-time connectivity", but IMHO they should no be considered potential 
flaws in this proposal specifically.

>  - one prefix and multiple physically seperate links
>    to the same provider

That's commonly called redundancy, not multihoming.  It doesn't fit the 2.7 
definition in any case.

>  - one [or more] prefix[es] and multiple physically seperate links
>    to multiple providers

That (as edited) seems to be a rewording of 2.7.

>  - multiple prefixes over one/multiple links

The number of prefixes shouldn't be relevant.  If anything, we should 
discourage end sites from announcing multiple prefixes.

> and a large number of other possiblities. Good one of course: is a
> tunnel a seperate link? Probably a reference to the wording on
> getting an ASN would be good to include here.

Section 5 just (implicitly) references section 2.7.  That's no help.

> The main thing I read from 2005-1 is that it gives the folks that want
> it the possiblity to acquire a globally unique address space block.
> Which is a good thing. But there should be a hard note, which is
> also given in the other allocation policies, that the RIR in question
> does not guarantee routability of that prefix.

Section 6.4.2 already covers that.

> IMHO something along the lines of: Pay an initial high fee (say $2k
> US) and then every year a renewal fee ($500 US?) accomplishes
> the same thing.

Presumably ARIN would develop a fee schedule for these assignments.  I think 
we only need to call that out if we have specific directions as to what the 
schedule should look like.

I, for one, would like to see fees waived for a single IPv6 assignment for 
as long as the org is paying fees on one or more IPv4 assignments, but I 
think that should be a separate policy (assuming PI ever passes).

> (Not that having a renewel currently makes sure the prefix is not
> used any more but (S-)BGP(-S) could solve that problem one day ;)

We have the same problem with all other assignment types too, so it's not 
unique to this proposal.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin