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

[John Santos]

On 30 Oct 2009 spiffnolee at yahoo.com wrote:

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


Why are you libeling me?  You say I'm a careless if I turn on IPv6 on my
LAN before my ISP offers IPv6 connectivity, so how the hell am I supposed
to test whether our applications work with IPv6, as some of my customers
are demanding?  (By "our applications", I mean applications that we write
for our customers.  How are our programmers supposed to write network-
agnostic applications without ever seeing an actual IPv6 network?)


> 
> > 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 can't work on my side until my ISP offers IPv6, according to you.


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

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539