[ppml] 2005-1 and/or Multi6

[Michel Py]

>>> Lea Roberts wrote:
>>> or would this policy just create SWAMPv6?

>> Michel Py wrote:
>> This policy would create SWAMPv6.

> David Conrad wrote:
> Err, we already have a SWAMPv6,
 
I don't agree with this
 
> The swamp, which I define as the unaggregated prefixes in the DFZ
 
This is not the swamp, IMHO.
 
> Daniel Roesen wrote:
> Can anyone please define "swamp"?
 
This is a slippery slope, but it is evident that we need to somehow agree on a definition of "swamp".
 
> What does the collection of PI prefixes differ in compared to the
> collection of PA aggregate prefixes other than probably prefix length?
 
IMHO, it does not.

> "Swamp" was the organisational chaos left from the early IPv4 phase.
> I don't see how a /32 set aside by each RIR for /48 PI prefixes can
> be called "swamp" unless you define all PI users as "mud". :-)
 
I agree with this.

We can inventory what is wrong with things that ave, rightfully or not, been associated with the swamp [non exhaustive].
 
1. Due to conservative allocation policies, several organizations have been allocated multiple non-aggregatable prefixes, which inflates the global routing table. IPv6 should be immune to this.
 
2. Early adopters have been given a PI prefix when they did not really need it. This is insignificant.
 
3. The prefix database is not up-to-date.
 
4. Prefixes have been given away for ever, not "rented" nor "leased".
 
5. Random prefixes.
 
 
The situation as of today is one out of 4 things:
 
a. The registered owner of the prefix announces the prefix. No problem.
 
b. Someone else than the legitimate owner of the prefix announces it:
   ba. For legitimate reasons, such as the company was bought, merged, split,
       renamed, moved, etc. and nobody updated the paperwork.
   bb. For illegitimate reasons: the original owner has long disappeared and
       someone else hijacked the prefix, and they will try to BS ARIN that
       they are in the ba. situation and get it transfered. This is called
       prefix hijacking.
 
c. The prefix is not allocated to anybody but someone annouces it. This is called a bogon.
 
Although I agree that there are not too many things that can be done, bb. and c. are not long-term solutions and are good choices for short-term operations such as spamming but not a legitimate business. In the case of bb., history has demonstrated multiple times that the stuff will hit the fan sooner or later and in the case of c. a RIR will allocate that prefix to someone else sooner or later, leading in both cases to the prefix being reclaimed for legitimate use.
 
In the case of IPv6, we are introducing a 5th possibility, which is the announcement of a random, statistically unique local IPv6 address. There is nothing ARIN can do to allocate it to someone else. Besides, contacting the concerned organization might prove difficult as it does not even need to be registered. This can't happen with IPv4 because local addresses are ambiguous: try to announce 192.168.1.0/24 :-D
Even though we might occasionally see RFC1918 prefixes in the global table, nobody would think about doing this to build a business so there is no problem. With local addresses being unique in v6, this becomes a problem.
 
IMHO, the IPv6 swamp would be a combination of 3. 4. and 5. above.
 
Why?
 
3. It's not because they're using IPv6 that bums are going to update the database entries when they did not do it for v4.
 
4. Even if with v6 prefixes are not given away for life but "rented" or "leased", the bottom line is that it costs a lot less to leave things "as-is" vs. actively reclaiming the prefix of people that have stopped paying, for example. Given the lack of pressure to reclaim these prefixes because of address space scarcity, and although in _theory_ RIRs could indeed reclaim prefixes, what is going to happen in many cases is that once a prefix has been allocated to someone on a termed basis the reality will kick in and make it lifelong for most cases.
 
5. As explained above, the reason people don't try to announce RFC1918 prefixes is because it does not work, not because we say they should not.
 
And here we have our swamp.
 

>> Michel Py wrote:
>> 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.

> David Conrad wrote:
> 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.

Get used to it. This is the way out of item 1. above.

 
> I'm not sure why NATv6 would be considered worse than SWAMPv6.
 
Where is Keith Moore when we need him?
 
 
> 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.
 
Let's say one of the primary mechanisms.
 
 
> The advantage of this is that it would theoretically
> allow for SWAMPv6 to be drained (at least to some extent).
 
I don't think so. The bulk of NATv6 users will have a PA prefix just as they do today and it won't change much the size of the routing table.


>> 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.
 
Downloading pirated .mp3 is wrong too, and there must be a hundred million users that are doing it right now.
 

> 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,
 
Impossible, but not required because all of the other ISPs would be under pressure from _their_ customers not to filter ULAs. There is a critical mass that needs to be reached, but if it is reached it will trigger a chain reaction. Remember, this costs nothing to the ISP.
 
 
> they'll probably just get a PA block, NATv6 it to
> some random ULA, and be done with it.
 
You are making my point above. I will point out though that NATv6 on a PI block is better than NATv6 on a PA block.


> 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
 
This is where the control thing comes in: with v4, there are things RIRs can do when people anounce hijacked prefixes or bogons. With v6, there is nothing the RIRs can do if people anounce ULAs. This is what I call losing control.
 
 
> 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).
 
There is no reason to believe that ARIN would not do this as there is a documented way (RFC3531), but again the best way to avoid it is to allocate short enough prefixes so the requester never comes back for more. The number of entries in the routing table is a constrained resource, not IPv6 address space. If lowering the first means wasting the second, be it.
 
Michel.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050413/cdb65bb0/attachment.htm>