Re: IPv6 will never fly: ARIN continues to kill it
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
I have an application where I will have approximately 2000 hosts (many
of them virtualized) in a cabinet, and I will eventually have hundreds
of such cabinets spread around the world.
...
Site-local addresses could be used, but they are distasteful to me for
all the reasons that they were deprecated, and all the reasons in
rfc1627. (ARIN has suggested that I might consider site-local addresses)
I hope you misunderstood; ARIN should have been referring to ULAs, RFC 4193.
ARIN has asked told me:
(2) In order to receive an initial IPv6 assignment, you must
qualify for an IPv4 assignment or allocation from ARIN under
the IPv4 policy currently in effect.
That is correct.
Well, the answer would be, for this use would be "use 10.x" network for
IPv4. That's why I asked for IPv6.
(none of the other rfc1918 spaces are big enough for my use, btw)
That is not. ARIN policy is that private addresses are preferred, but
public addresses can be assigned for private use if there's a decent
justification. Also note that actually _requesting_ PIv4 space is not
required to get PIv6 space; only _qualifying_ is required. You appear to
qualify based on the limited information provided.
I am very disappointed. I don't expect anyone to go and fix ARIN.
I am simply posting to express myself.
You appear to qualify for a PI /48 (or more than one) under existing policy.
If you are unhappy with the policy or need a better explanation, please join
ppml at arin.net and ask for help. If you do not believe ARIN is following the
existing policy, please contact hostmaster at arin.net.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
(Exim 4.43)
id 1IY1ax-0007pz-Rq; Wed, 19 Sep 2007 11:36:07 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1av-0007pb-Vi
for ietf at ietf.org; Wed, 19 Sep 2007 11:36:06 -0400
Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82]
helo=defiant.dfw.nostrum.com)
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY1av-0003eH-0M
for ietf at ietf.org; Wed, 19 Sep 2007 11:36:05 -0400
Received: from ssprunkxp (localhost [127.0.0.1])
by defiant.dfw.nostrum.com (8.13.8/8.13.8/Debian-3) with SMTP id
l8JFZtrS013501; Wed, 19 Sep 2007 10:36:03 -0500
Message-ID: <012d01c7fad2$ba56df00$573816ac at atlanta.polycom.com>
From: "Stephen Sprunk" <stephen at sprunk.org>
To: "Michael Richardson" <mcr at sandelman.ottawa.on.ca>, <ietf at ietf.org>
References: <11452.1189607641 at marajade.sandelman.ca>
Date: Wed, 19 Sep 2007 10:15:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Virus-Scanned: ClamAV 0.91.1/4341/Wed Sep 19 10:11:47 2007 on
defiant.dfw.nostrum.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc:
Subject: Re: IPv6 will never fly: ARIN continues to kill it
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org
Thus spake "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
I have an application where I will have approximately 2000 hosts (many
of them virtualized) in a cabinet, and I will eventually have hundreds
of such cabinets spread around the world.
...
Site-local addresses could be used, but they are distasteful to me for
all the reasons that they were deprecated, and all the reasons in
rfc1627. (ARIN has suggested that I might consider site-local addresses)
I hope you misunderstood; ARIN should have been referring to ULAs, RFC 4193.
ARIN has asked told me:
(2) In order to receive an initial IPv6 assignment, you must
qualify for an IPv4 assignment or allocation from ARIN under
the IPv4 policy currently in effect.
That is correct.
Well, the answer would be, for this use would be "use 10.x" network for
IPv4. That's why I asked for IPv6.
(none of the other rfc1918 spaces are big enough for my use, btw)
That is not. ARIN policy is that private addresses are preferred, but
public addresses can be assigned for private use if there's a decent
justification. Also note that actually _requesting_ PIv4 space is not
required to get PIv6 space; only _qualifying_ is required. You appear to
qualify based on the limited information provided.
I am very disappointed. I don't expect anyone to go and fix ARIN.
I am simply posting to express myself.
You appear to qualify for a PI /48 (or more than one) under existing policy.
If you are unhappy with the policy or need a better explanation, please join
ppml at arin.net and ask for help. If you do not believe ARIN is following the
existing policy, please contact hostmaster at arin.net.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.