[CentOS-mirror] IPv6 Mirroring

Tue Aug 2 15:10:28 UTC 2011
Matt Domsch <Matt_Domsch at dell.com>

On Mon, Aug 01, 2011 at 05:45:16PM -0500, Kevin Stange wrote:
> >> 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.

agreed, IPv6-enabling the mirror infrastructure is a worthwhile goal
in and of itself.

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

I'm with you to here. :-)

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

Here's where I start to lose you.  We don't presently have a way for a
client to indicate to anyone anywhere that it "prefers" v6 instead of
v4, or vice versa.  From the server side, it sees a connection, either
on v6 or on v4, and sees an address.  We would have to add a flag into
the yum mirrorlist request URL to give the client an opportunity to
note its preference.  Not hard technically, but the obvious
implementation would require manual configuration by each end user,
and that's nearly never done.

How would you envision a client recognizing that it should prefer v6
over v4, automatically?  Solving that cleanly, the rest is

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

You're asking for a different sort order to the results list, based on
the presence of a "prefers_v6=1' flag in the request URL.  Not
difficult really, MirrorManager could add that.  Right now it doesn't
do A or AAAA lookups for its mirrors, it just returns the URLs that
the mirror admins put in the database, and the clients then do their
own DNS lookups, and then connect whichever way they choose.  So MM
would need to add DNS lookups and cache that info, and use it in the
sort order.

MM would also need to add a flag for each mirror Host, indicating
"prefers_v6_clients", because I expect for most hosts, they really
don't care.  What does that do to the sort order?

Protocol is orthogonal to network distance, I don't really like mixing
the two in the ordered list:

(same ASN) + (in netblock) + (in peer ASN) + (client_prefers_v6 &&
host_prefers_v6) + (client_prefers_v6) + (rest of the list in
geographic order) ?

(the above assumes a MM implementation, which CentOS isn't using at
the moment, I'm simply projecting.  That's another discussion to be
had when time allows.)


Matt Domsch
Technology Strategist
Dell | Office of the CTO