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

[Lee Howard]

> The moment I publish a AAAA record

> for my web site, your web browser on your IPv4/IPv6 dual-stacked
> machine will attempt to connect to that AAAA record in preference to
> any A records I've published, will it not?

Yes.  It seems to me that requesting AAAA records over IPv4 is 
a bad idea; at least one popular name server now has a now that when
set, will only return AAAA to queries from IPv6 addresses.

> So if I'm using an ARIN /48 and you're using Verizon, your attempt to
> access my web server is going to hang with a retransmitting TCP SYN
> for a while before it falls back to looking up the A records. 

Yes, if a host is dual-stacked but does not have IPv6 connectivity, then
IPv6 access will fail.  Under what conditions does this happen?

> Same if
> I'm on one side of the IPv6 transit-free peering divide and you're on
> the other. The divide they've been talking about over on NANOG where
> just about everybody can get to HE but quite a few folks who can get
> to HE can't get to each other. 

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.

> Same if you happen to have been
> tinkering with 6to4, whose donated public relays are not especially
> well meshed with the IPv6 Internet backbone. 

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.

> Same if either of us is
> multihomed with IPv4 but only single-homed with IPv6 and the link that
> does IPv6 is malfunctioning. Same if IPv6 growing pains are causing a
> connectivity glitch at the moment. 

Yes, if you don't have IPv6 connectivity, you can't connect over IPv6.

> Same if the IPv6 deployment on your
> LAN is in an intermediate state where the machines have global-scope
> IPv6 addresses but don't yet have IPv6 connectivity to the world.

Yes, if you don't have IPv6 connectivity, you can't connect over IPv6.
That's a careless LAN administrator.

> 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.   

Step 0: Get good IPv6 connectivity.  I'll work on my side if you'll 
work on your side.  Actually, I'll work on my side anyway.

> > I ask you, then: what would motivate you to provide IPv6 support
> > on your servers?
> 
> Changes to all the software so that by default a dual stack system
> tries IPv4 first. That way I can adequately mitigate any risk from
> offering IPv6 as an initially second-class service.

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.

> 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?
 
> But I'm easy to motivate: I'll invest vast amounts of time on systems
> of no immediate use merely because they interest me. Other people
> expect (gasp) a prompt ROI.

Fortunately, dual-stacking public-facing servers is pretty cheap and
easy.  There are parts of the Internet where dual-stacking will not
be fast, and a prompt ROI will be impossible.

Lee