[ppml] 2005-1 and/or Multi6
david.conrad at nominum.com
Wed Apr 13 16:16:27 EDT 2005
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
>> 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
> 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
> 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
> 2. Delay furthermore v6 deployment because of the lack of a multihoming
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
> 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
> 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
> 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
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).
My opinions, nothing more.
More information about the ARIN-PPML