[arin-ppml] IPv4 Depletion as an ARIN policy concern

[William Herrin]

On Fri, Oct 30, 2009 at 12:23 PM, Lee Howard <spiffnolee at yahoo.com> wrote:
> I agree, 6to4 is in many cases poorly implemented, as are many of the
> other tunnel solutions.  Google's response is to return AAAAs only if
> they have pretty high confidence that the client will have native IPv6.

Hi Lee,

That's an option I look forward to seeing in the bind9 documentation.
But while that helps me, it does little for the plethora of server
operators who don't host their own DNS and have only weak control over
the folks who do.


> Right.  If you don't have IPv6 connectivity, then you can't connect via
> IPv6.  This is not unique to IPv6.  I should have included a Step 0: get
> good IPv6 transit.

Rhetorical question: is it presently possible to get "good" IPv6
transit for the same standard of "good" as is available for IPv4
transit? The answer, of course, is no.

Should IPv6 transport quality ever reach parity with IPv4 transit
quality then naturally my objections would fade. But declaring it "as
good" doesn't make it so and right now it isn't even close enough for
the difference to be subtle.


>> Maybe it's just my COOP mindset, but it seems to me there are a lot of
>> ways that adding IPv6 to my servers can disrupt their IPv4 operation.
>
> Nothing you've said describes interference with the operation of your
> servers.  You've described several ways IPv6 connectivity may fail,
> none of which are inherent to IPv6.

They describe commonly experienced failure modes that impact the
operation of applications otherwise capable of connecting with IPv4 as
an inescapable result of deploying dual stack. I try to minimize the
probability of my servers encountering any failure modes and today
that means no IPv6.


> As I'm sure you know, the conventional wisdom is that by preferring
> IPv6, traffic counters will provide compelling evidence to people like
> you that IPv6 support is required.  And then those who assign
> addresses, when  they see that 100% of traffic is IPv6, can silently
> stop assigning IPv4 addresses, and the Internet will have gracefully
> migrated.

The "conventional wisdom" for IPv6 has failed us in so many ways we
should probably start appending a "[sic]" when we say it. This
particular error in judgment is no exception: trouble bringing IPv4 to
a close is a "nice problem to have" versus the difficulty in getting
IPv6 to a point where we can seriously consider IPv4's end.


At any rate, I'm not trying to argue with you. I'm just explaining
some of the reasons why I stopped my IPv6 deployment work after the
"experimental, figure out how this thing actually works and take it
for a test drive" phase.


>> Or, of course, if a substantial enough deployment of IPv6-only users
>> goes forward despite my own reluctance.
>
> Or maybe if your servers run an app that doesn't like multiple layers
> of NAT?

My services are NAT-tolerant. Long since passed the point where
systems that don't play well with NAT can be considered reliable.


On Fri, Oct 30, 2009 at 1:50 PM,  <michael.dillon at bt.com> wrote:
>> Maybe it's just my COOP mindset, but it seems to me there are
>> a lot of ways that adding IPv6 to my servers can disrupt
>> their IPv4 operation.
>
> You are right. Don't add IPv6 to an IPv4 server. Instead, create
> a translation layer so that IPv6 hosts can access it through the
> translation layer. Part of such a translation layer would be
> a different hostname, for instance use ipv6.example.com instead
> of www.example.com.

Which is, no doubt, the first form of IPv6 deployment that I will do.
But then what?

Assuming I can clear enough obstacles to move to that stage, how does
that movement encourage or empower anyone else to move to the stage
beyond?


On Fri, Oct 30, 2009 at 11:42 AM, Owen DeLong <owen at delong.com> wrote:
> Not exactly... It will have already looked up the A records, but, when
> the connect() call returns ETIMEOUT, the loop will continue to iterate
> until connect() succeeds.  Yes, the successive calls to connect()
> should use the IPv6 address first.

Owen,

Connect generally doesn't return ETIMEOUT for at least two minutes and
sometimes as long as 15. For a web browser, that might as well be
forever. Application developers can do non-blocking connects that time
out sooner but they generally don't.


> The same is true if you have an IPv4 application hosted on multiple
> addresses and the first one is not working at the moment.

Hence the reason I *don't have* IPv4 applications hosted on multiple addresses.


> I've been running dual-stack for several months now, and, frankly, have
> not noticed a significant number of degraded events.

Why would you see problems? The servers you're contacting are either
intentionally IPv6 (ipv6.google.com) or offer no AAAA records to
distract you (www.google.com). You don't see problems because people
like me have declined to deploy IPv6 on their servers.


> Actually, if you want to do that, for the most part, you only need to modify
> the getaddrinfo() library on your system.

Great. Let's get modifying and get those modifications deployed so
that the possibility of IPv6 on my production servers can enter my
comfort zone.

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004