[CentOS-mirror] IPv6 Mirroring

Mon Aug 1 22:45:16 UTC 2011
Kevin Stange <kevin at steadfast.net>

On 08/01/2011 05:16 PM, David Richardson wrote:
> On Mon, 1 Aug 2011, Kevin Stange wrote:
>> On 08/01/2011 03:37 PM, Matt Domsch wrote:
>>> On Mon, Aug 01, 2011 at 02:16:30PM -0500, Kevin Stange wrote:
>>>> Karabir suggested we start getting together a list of steps that need
>>>> completion to deliver an IPv6-preferenced or IPv6-only list of mirrors
>>>> for IPv6-only clients using CentOS.
>>> FWIW, Fedora hasn't had a significant need to IPv6-preferenced of
>>> IPv6-only mirrors.  We do manage preference by ASN, netblocks (IPv4
>>> and IPv6), internet2 (and related networks) and country.  Fedora does
>>> have nameservers advertised on AAAA records, as well as A records.
>>> The inbound web proxies are reachable via both AAAA and A records, so
>>> MirrorManager does see a client's IPv6 or IPv4 address.
>>> MirrorManager replies to client requests with DNS names. Mirrors may
>>> themselves advertise a given name with an AAAA or A record.
>> The idea would be to provide DNS names we know have AAAA records to
>> provide better quality of service to a yum client that can't use A
>> records.  Otherwise, it's a lot of poking randomly at hosts until one
>> with AAAA is found.
>> It's also just a good idea at this point to at least build the mirror
>> infrastructure to be IPv6 capable from end to end so that an IPv6-only
>> client at least has a shot at finding a mirror at all.
> The question is: are we optimizing our service for ipv6-only clients, or 
> for ipv6-capable (dual-stack) clients?

I would say we're talking about just making it possible for v6 only
clients to get the mirror list.  Right now a v6 only client cannot
obtain the mirror list at all.  We'd be catering to v6-capable (dual
stack) clients by offering mirror choices with v6 ahead of v4 if the
client seems to prefer v6.

> Returning only a list of v6-capable mirrors to a client will help the case 
> of a v6-only client, but could hurt a v6-capable client.

I would prefer to return v4 with lower priority after the v6 list for
this reason.

> One example problem: what do you do when there are no v6 mirrors in a 
> country (since the mirror system today is country-based)? Do you return v4 
> mirrors from that country, or v6 mirrors from other countries? Remember 
> that in some countries international bandwidth can be very expensive.

This is an interesting question.  If the user connects via v6 we have no
way to know if they're v4-enabled unless we do something really weird.
Right now, we can reasonably assume that they do have v4 because it's
sort of ridiculous not to, then perhaps we want to give v4 addresses for
the local country first, followed by v6 addresses for other countries in
the region?

Making this assumption permanently is not a good idea though, so it
seems wise to me that we are flexible with how things are set up.

> I am a big proponent of ipv6 (my mirror has had a v6 address for years). 
> However, running a client v6-only ignores the fact the most of the 
> internet is still v4-only (let alone dual-stack). It's an interesting 
> experiment, but a v6-only client is not very useful on today's internet 
> (and probably won't be for several years). I don't think we should cater 
> much to people who choose to make their own lives difficult.

Part of my goal is to ready for the idea that someone that does run a v6
only system can actually find a mirror at all (and that means making
centos reachable via v6), but, I recognize for now that it's unlikely.

In the meantime, if the client prefers IPv6, I think it's better to
offer him IPv6 mirrors as the top priority, followed by other regional
v4 only mirrors after that.

Kevin Stange
Chief Technology Officer
Steadfast Networks
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-mirror/attachments/20110801/3fc1072e/attachment-0004.sig>