[ppml] 2005-1 and/or Multi6

[David Conrad]

Hi,

Speaking for myself (and as someone who at one time, long ago, 
participated in the multi6 working group and then stopped as the 
OSIfication became too much to bear):

On Apr 13, 2005, at 11:05 AM, Michel Py wrote:
>> since one of the good arguments for 2005-1 is to allow provider
>> independent multi-homing, is there anyone out there who has been
>> following the multi6 working group in IETF who believes there
>> will a timely alternative forthcoming from that working group?
> I stopped following it when I realized that no alternative would come
> out in a timely manner, and it was a while ago.

I too am somewhat skeptical that shim6 will get any sort of real 
deployment.

>> do folks believe that PI /48s assigned under 2005-1, should it
>> become policy, would be willingly returned to ARIN by assignees
>> once an alternative workable multi6 implementation exists
>
> I don't. From the user's prospective, no multihoming alternative will
> ever be as simple and straightforward as a PI block, why would one 
> spend
> time and money switching to a complicated solution when one already has
> a simple one working fine?

I agree.  As long as renumbering is non-transparent to the user, PI 
will be preferable.  As long as maintenance and announce-ability of PI 
is viewed as cheaper than the potential cost of renumbering, people 
will not voluntarily return a PI allocated block.  It is, of course, 
theoretically possible for ARIN to force a return of a PI block, but I 
suspect if this were actually done, ARIN's legal defense fund would 
need a quite significant boost.

>> or would this policy just create SWAMPv6?
> This policy would create SWAMPv6.

Err, we already have a SWAMPv6, the question is merely how large it 
will become.  However, I have been and continue to be of the firm 
believe that the RIRs have little control over any swamp as it is ISPs 
who make the decision whether or not a particular prefix announcement 
is accepted.  RIRs can create conditions in which a swamp can be 
created, in fact 2005-1 would provide such conditions, however it is 
the ISPs which announce/accept unaggregated prefixes that actually 
create the swamp.

> SWAMPv6 will be more difficult to
> clean than SWAMPv4, for two reasons:
> a) Owners of SWAMPv6 blocks willing to release them will have to do
> _both_ of the following: aa) renumber ab) embrace a new technology.
> b) There will be no pressure to recover SWAMPv6 space as address
> scarcity will not be an issue.

While I agree with the first, I am not so confident of the second as 
most people appear to be.  The size of prefixes being allocated today 
worries me.  A lot.

> In the absolute, this is bad. That being said, it does not look that 
> bad
> compared to other alternatives which include:
>
> 1. NATv6, made easier by Unique Local IPv6 Unicast Addresses [compared
> to NATv4: no ambiguity, which is one of the major NATv4 issues].

I'm not sure why NATv6 would be considered worse than SWAMPv6.  As you 
indicate, NATv6 will indeed become simpler due to ULAs.  Given the cost 
of renumbering scales with the number of devices on the network, I 
fully expect NATv6 to eventually become the primary mechanism by which 
IPv6 is used.  The advantage of this is that it would theoretically 
allow for SWAMPv6 to be drained (at least to some extent).

Of course, I don't consider NAT to be inherently evil (heck, I use it 
every day).

> 2. Delay furthermore v6 deployment because of the lack of a multihoming
> solution.

I don't believe v6 deployment will be significantly delayed by lack of 
a multihoming solution.  The cost of making the transition to v6, the 
lack of obvious non-geek justification for making that transition, and 
the continued requirement to have user involvement in renumbering when 
changing providers are all more than sufficient to slow down v6 
deployment.

> 3. MEGASWAMPv6, obtained by routing Unique Local IPv6 Unicast Addresses
> globally (which requires nothing but enterprises and operators to
> conveniently "forget" to filter them under financial pressure). In 
> other
> words, instead of giving money to ARIN to obtain a 2005-1 block,
> enterprises would give the money to their ISP(s) to "forget" to filter
> the Unique Local IPv6 Unicast they announce.

I guess I'm not too worried about this as I see it paralleling to some 
extent people announcing randomly chosen prefixes in IPv4.  Yes, it 
happens, but most folks know that it is simply wrong.  Unless the 
enterprise paying their ISP to have their ULA announced is willing to 
run the risk of having to pay every ISP of folks to whom the enterprise 
wants to connect, they'll probably just get a PA block, NATv6 it to 
some random ULA, and be done with it.

> I have opposed swamp creation in the past, but what we are facing now 
> is
> not whether we will have a swamp or not but whether the swamp will
> remain under ARIN control or not.

The swamp, which I define as the unaggregated prefixes in the DFZ, is 
not and has never been under the control of ARIN or any of the other 
RIRs -- the RIRs don't generally announce prefixes.  In my mind, the 
question is really whether or not the initial conditions for rapid 
growth of the swamp should be permitted in order to facilitate IPv6 
deployment and acceptance.  The swamp can be much larger than it used 
to be because of Moore's Law but there is an implicit 
disparity/unfairness created when the limits of router CPU/memory are 
reached (again).

As somewhat of an aside, hopefully, if 2005-1 were to be enacted, ARIN 
staff would do the allocations in such a way as to increase the 
likelihood of aggregate-ability in the future (i.e., doing sparse 
allocations such that if any PI requestor needed more PI space, the 
second prefix allocated could be aggregated with the first).

Rgds,
-drc
My opinions, nothing more.