Fedora IPv6 testing and improvements - request for ideas

Scott Schmit i.grok at comcast.net
Wed Nov 4 05:54:49 UTC 2015


On Tue, Nov 03, 2015 at 01:12:09PM -0500, Pavel Simerda wrote:
> You can of course have combinations. We can add that once we have
> specific test cases that would show importance of a standalone category
> for such a setup. Otherwise one would usually view IPv6 global and IPv6
> local communication as two isolated things.

I only brought it up because both ULA and non-ULA global are "global" so
some software could pick inappropriate prefixes.  That doesn't show up
if you never hand out multiple prefixes to choose from.

> > Another case would be multi-homed IPv6, where you have global IPv6
> > addresses from multiple sources (could be two ISPs, two tunnel
> > providers, or one ISP and one tunnel provider).
> 
> Interesting. Any specific test cases for that?

Assuming link/ISP/prefix A vs B.
Check that:
- Apps connected to via A respond from A and not B.
- If A is preferred over B, apps source via A instead of B unless/until
  A has been withdrawn/is unavailable.
- Things keep working if A is withdrawn/is unavailable.
- If the preference is reconfigured, that the apps respect that change.
- Starting with only A, advertise higher-priority B and watch that
  things switch.

I think that covers what people usually want for multi-homing.

This ignores the router end of actually being able to
express/route/manage the above correctly.

> > IPv6 is designed to be inherently more dynamic than IPv4 (particularly
> > with RAs) -- we should test transitions between connectivity states
> > (simulating an ISP connection dropping and coming back up or a router
> > going down and coming back up).
> 
> While IPv6 is designed to be inherently dynamic, operators seem to be
> avoiding it as much as possible and use it in a way more similar to
> IPv4. Specific test cases and common usage are welcome, though.

Yeah, I've noticed that, too.  Seems like a bit of wanting their cake
(dynamically provisioning & reconfiguring customers) while eating it too
(not wanting to support/use protocols intended to allow that without
breaking things).  To be fair, I don't think it's just the operators.

As for test cases: have the router withdraw the global prefix and see
that things drop back to IPv4 (if you've got only one prefix) or switch
over to another configured global prefix (if there's more than one).
Then do the opposite and see that the new prefixes get picked up.
Alternatively, have the router transition the network to new prefixes
(renumbering).

I feel like those are somewhat obvious (re)statements, so I'm not sure
if this is what you're looking for.

FWIW, I expect most software to handle this poorly unless the kernel
somehow does this automagically for userspace programs, but I get the
impression that you're trying to assess current state as much as fix
things.

> > Speed differences between IPv6 & IPv4 could be a factor as well (happy
> > eyeballs) -- though reportedly IPv6 has tended to be faster than IPv4
> > rather than the previously-expected inverse.
> > 
> > Checking support for DHCPv6-PD would also be valuable.
> 
> We're not really focusing on a Fedora based router use case. As always,
> that doesn't mean someone cannot join and extend the effort. If you're
> interested in the classic connection sharing feature, it may be better
> to contact NetworkManager developers directly.

Fair enough re DHCPv6-PD (I suspected that was a bit of a long shot
<g>), but you maybe missed the "happy eyeballs" bit above that...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3800 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151104/4d73ba43/attachment.bin>


More information about the devel mailing list