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 straightforward. > > 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.) Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO