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

[Owen DeLong]

On Oct 30, 2009, at 8:31 AM, William Herrin wrote:

> On Fri, Oct 30, 2009 at 10:29 AM, Lee Howard <spiffnolee at yahoo.com>  
> wrote:
>>  There are very few places
>> where adding IPv6 might break something.
>
> Lee,
>
> I'm not sure how you figure that. 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?
>
> 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. Same if

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.

Anyone on Verizon can resolve this by adding a free tunnel to HE.

Additionally, HE is trying to work with Verizon to address an interim
and more long term solutions to this issue.

> 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. Same if you happen to have been
> tinkering with 6to4, whose donated public relays are not especially
> well meshed with the IPv6 Internet backbone. Same if either of us is

That's actually gotten mostly better of late.  Same with Teredo.

> 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. 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.
> They've been discussing the rogue RA problem over on NANOG too.
>
This is one of the places that RA falls short.  RA says "The router is  
up,
it must be good for default."  Would be nice if there was a way to get a
router that can't actually get out to stop advertising an IPv6 default  
route
in the RA.

> With IPv6 turned on, I have to really depend on applications doing a
> smart job falling back to IPv4 when historically applications tend to
> do a poor job falling back to any second choice. And God help you if
> the first choice gave a wrong answer instead of failing to respond.
>
The same is true if you have an IPv4 application hosted on multiple
addresses and the first one is not working at the moment.

> 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.
>
There are a few, but, in reality, it's usually not a meaningful problem,
and, as more and more things become dual-stacked, it will be less and
less of a problem.

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

>
>> 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.
>
Actually, if you want to do that, for the most part, you only need to  
modify
the getaddrinfo() library on your system.

Most applications just iterate through the return from getaddrinfo()  
in the
order of what it provided.

> Or, of course, if a substantial enough deployment of IPv6-only users
> goes forward despite my own reluctance.
>
That is inevitable.
>
Owen