On Tue, 2012-03-13 at 22:45 +1030, Glen Turner wrote: > Hi, > > I am the network engineer at Australia's Academic and Research Network > responsible for assisting the deployment of IPv6 across Australian > universities. Your posting was bought to my attention. > > Your phrasing of the condition for blocking is pretty broad: there are > lots of ways to break IPv6, just as there are with IPv4, and just as > with IPv4 not all of them are significant enough to be blocking. > > Can I suggest the following as a starting point: > - failure in configuration of interface addresses with a link scope > address via stateless address autoconfiguration should block > - failure in configuration of interface addresses with a global scope > via stateless address autoconfiguration should block > - failure in configuration of interface addresses with a global scope > via manual configuration should block > - failure in configuration of DNS forwarding via stateless DHCP6 should > block > - failure in configuration of DNS forwarding via RAs should block > - failure of connectivity of network ::1/128 (localhost) of all > services should block > - failure of unicast or multicast connectivity of link local addressing > of allowed services should block > - failure of unicast connectivity of global addressing of allowed > services should block > - failure of connectivity of ICMP6 service for codes <= 127 should > block > > Non-stateless DHCP6 is primarily used by ISPs to configure customer > routers. Those routers present SLAAC to their downstream users. > > Non-stateless DHCP6 is also used by enterprises who wish to parallel > their existing management of computers via IPv4 DHCP into IPv6. In my > view that is a poor network design choice, but there is no denying that > it is a choice made by some enterprise networks. > > At this point in time you could deploy a IPv6 with manual configuration > and with SLAAC (with both stateless DHCP6 and RAs to configure DNS) and > make most people happy. The significance of the proportion of people > made unhappy may or may not be enough for a release blocking bug (as > opposed to simple lack of support for that IPv6 feature) -- that's > really your choice. > > It also depends if statefull DHCP6 host configuration was supported in a > previous release, in that case a regression leads to such a complicated > scenario for network engineers and systems administrators that the bug > should be release blocking. Thanks, Glen. Let me come clean and say my eyes glazed over about three sentences into that. =) If I'm semi-grokking it vaguely correctly, however, the meat of what you're suggesting here is that stateful (as opposed to stateless) autoconfiguration should not be a blocking issue? As far as 'what worked in previous releases' goes, my impression is that we can pretty much work from the assumption that IPv6 has never entirely worked OOTB on Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
