<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Re: [ppml] 2005-1 and/or Multi6</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText98561 dir=ltr>
<DIV dir=ltr><FONT face="Courier New" size=2>>>> Lea Roberts
wrote:</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>>>> or would this policy
just create SWAMPv6?<BR></FONT><FONT size=2></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>>> Michel Py
wrote:</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>>> This policy would create
SWAMPv6.<BR></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2>> David Conrad
wrote:<BR></FONT><FONT size=2>> Err, we already have a
SWAMPv6,</FONT></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>I don't agree with
this</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr>
<DIV dir=ltr><FONT face="Courier New" size=2>> The swamp, which I define as
the unaggregated prefixes in the DFZ</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>This is not the swamp,
IMHO.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>> Daniel Roesen
wrote:</FONT></DIV>
<DIV dir=ltr><FONT size=2><FONT face="Courier New">> Can anyone please define
"swamp"?</FONT></DIV></FONT>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>This is a slippery slope, but it is
evident that we need to somehow agree on a definition of "swamp".</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2>> What does the collection
of PI prefixes differ in compared to the</FONT></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2>>
collection</FONT></FONT><FONT face="Courier New"><FONT
size=2> of</FONT></FONT><FONT face="Courier New"><FONT size=2> PA
aggregate prefixes other than probably prefix length?</FONT></FONT></DIV><FONT
face="Courier New"><FONT size=2></FONT></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2></FONT></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2>IMHO, it does not.</DIV>
<DIV dir=ltr><BR>> "Swamp" was the organisational chaos left from the early
IPv4 phase.</DIV>
<DIV dir=ltr>> I don't see how a /32 set aside by each RIR for /48 PI
prefixes can</DIV>
<DIV dir=ltr>> be called "swamp" unless you define all PI users as "mud".
:-)</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I agree with this.</FONT><BR></DIV></FONT>
<DIV dir=ltr><FONT face="Courier New" size=2>We can inventory what is wrong with
things that ave, rightfully or not, been associated with the swamp [non
exhaustive].</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>2. Early adopters have been given a
PI prefix when they did not really need it. This is insignificant.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>3. The prefix database is not
up-to-date.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>4. Prefixes have been given away
for ever, not "rented" nor "leased".</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>5. Random prefixes.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>The situation as of today is one
out of 4 things:</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>a. The registered owner of the
prefix announces the prefix. No problem.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>b. Someone else than the legitimate
owner of the prefix announces it:</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2> ba. For
legitimate reasons, such as the company was bought, merged, split,</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"
size=2> renamed, moved, etc. and nobody
updated the paperwork.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2> bb. For illegitimate
reasons: the original owner has long disappeared and</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"
size=2> someone else hijacked the prefix,
and they will try to BS ARIN that</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"
size=2> they are in the ba. situation and
get it transfered. This is called</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New"
size=2> prefix hijacking.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>c. The prefix is not allocated to
anybody but someone annouces it. This is called a bogon.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>IMHO, the IPv6 swamp would be a
combination of 3. 4. and 5. above.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>Why?</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>And here we have our
swamp.</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2></FONT> </DIV><FONT
face="Courier New" size=2>
<DIV dir=ltr><BR>>> Michel Py wrote:</DIV>
<DIV dir=ltr>>> SWAMPv6 will be more difficult to clean than SWAMPv4, for
two reasons:<BR>>> a) Owners of SWAMPv6 blocks willing to release them
will have to do<BR>>> _both_ of the following: aa) renumber ab) embrace a
new technology.<BR>>> b) There will be no pressure to recover SWAMPv6
space as address<BR>>> scarcity will not be an
issue.<BR><BR>> David Conrad wrote:<BR>> While I agree with the
first, I am not so confident of the second</FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" size=2>> as most people appear to
be. The size of prefixes being allocated</FONT></DIV>
<DIV dir=ltr><FONT size=2><FONT face="Courier New">> today worries
me. A lot.<BR></FONT></FONT></DIV>
<DIV dir=ltr><FONT size=2><FONT face="Courier New">Get used to it. This is the
way out of item 1. above.</FONT></FONT></DIV><FONT size=2><FONT
face="Courier New">
<DIV dir=ltr><BR> </DIV>
<DIV dir=ltr>> I'm not sure why NATv6 would be considered worse than
SWAMPv6.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Where is Keith Moore when we need him?</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>> As you indicate, NATv6 will indeed become simpler due to ULAs.
Given</DIV>
<DIV dir=ltr>> the cost of renumbering scales with the number of devices
on the</DIV>
<DIV dir=ltr>> network, I fully expect NATv6 to eventually become the
primary</DIV>
<DIV dir=ltr>> mechanism by which IPv6 is used.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Let's say one of the primary mechanisms.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>> The advantage of this is that it would theoretically</DIV>
<DIV dir=ltr>> allow for SWAMPv6 to be drained (at least to some
extent).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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.<BR><BR><BR>>> 3. MEGASWAMPv6, obtained by routing Unique Local IPv6
Unicast</DIV>
<DIV dir=ltr>>> Addresses globally (which requires nothing but
enterprises and</DIV>
<DIV dir=ltr>>> operators to conveniently "forget" to filter them
under financial</DIV>
<DIV dir=ltr>>> pressure). In other words, instead of giving money to
ARIN to</DIV>
<DIV dir=ltr>>> obtain a 2005-1 block, enterprises would give the
money to their</DIV>
<DIV dir=ltr>>> ISP(s) to "forget" to filter the Unique Local IPv6
Unicast they</DIV>
<DIV dir=ltr>>> announce.<BR></DIV>
<DIV dir=ltr>> I guess I'm not too worried about this as I see it paralleling
to</DIV>
<DIV dir=ltr>> some extent people announcing randomly chosen prefixes in
IPv4.</DIV>
<DIV dir=ltr>> Yes, it happens, but most folks know that it is simply
wrong.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Downloading pirated .mp3 is wrong too, and there must be a hundred
million users that are doing it right now.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr><BR>> Unless the enterprise paying their ISP to have their
ULA</DIV>
<DIV dir=ltr>> announced is willing to run the risk of having to pay
every</DIV>
<DIV dir=ltr>> ISP of folks to whom the enterprise wants to
connect,</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>> they'll probably just get a PA block, NATv6 it to</DIV>
<DIV dir=ltr>> some random ULA, and be done with it.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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.<BR><BR></DIV>
<DIV dir=ltr>> The swamp, which I define as the unaggregated prefixes in
the</DIV>
<DIV dir=ltr>> DFZ, is not and has never been under the control of ARIN
or</DIV>
<DIV dir=ltr>> any of the other RIRs</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>> As somewhat of an aside, hopefully, if 2005-1 were to be</DIV>
<DIV dir=ltr>> enacted, ARIN staff would do the allocations in such
a way</DIV>
<DIV dir=ltr>> as to increase the likelihood of aggregate-ability
in the</DIV>
<DIV dir=ltr>> future (i.e., doing sparse allocations such that if any
PI</DIV>
<DIV dir=ltr>> requestor needed more PI space, the second prefix
allocated</DIV>
<DIV dir=ltr>> could be aggregated with the first).</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>Michel.</DIV>
<DIV dir=ltr> </DIV></FONT></FONT>
</BODY>
</HTML>