Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-03 Thread Pavel Simerda
- Original Message -
> From: "Miloslav Trmač" 
> 
> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik 
> wrote:
> > = Features/DualstackNetworking =
> > https://fedoraproject.org/wiki/Features/DualstackNetworking
> 
> (Sending to the list instead of using the wiki talk page to hopefully
> gather more information from networking experts.  The recent-ish
> bugzilla activity in this space does suggest that this is a good
> topic to revisit in detail, thanks for taking the effort on.)

Thanks!

> 1. So what is the _precise_ scope of the ''proposed feature''?  For
> example, does "glibc: name resolution must work properly" mean that
> you have some specific proposals to change glibc?

Yes.

I identified a bunch of problems in glibc and commented on previously 
identified problems:

http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo&list_id=7854

Now I'm writing and submitting patches. But it will take time.

> (https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
> suggests changing glibc as one of the options.  Have you decided
> which
> option you propose?  In general, glibc maintainers' signoff or at
> least significant discussion would probably be required for any glibc
> change of this kind.  FWIW, historically it was recommended to have
> AI_ADDRCONFIG enabled, see
> http://www.akkadia.org/drepper/userapi-ipv6.html .)

It is now pretty clear that we need to do #3 and #4 (in this order) and then 
start recommending AI_ADDRCONFIG for connect(), sendto() and other stuff again. 
But I found more fundamental problems in getaddrinfo() while playing with the 
code and while reading IPv6-related bug reports.

Ulrich's documentation is unfortunately not useful as it was written without 
practical IPv6 skills and testing. I recommend to ignore it in favor of the 
resources on Fedora Wiki.

> 2. We already have a guideline requiring IPv6
> (https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuidelines#Networking_Support
> ); to the extent that this feature would propose specific ways to use
> the API, the packaging guideline should point to documentation that
> describes the correct way.

Good point. Specific recommedations that are evolving will be part of this 
feature.

> It would be great to get a wide review of the proposed approach before any 
> extensive effort to
> modify many
> packages starts.

Actually, it's easier than that.

Most important packages either use getaddrinfo() or are moving towards it. Many 
of them (if not most) set AI_ADDRCONFIG. As we are now going to fix 
AI_ADDRCONFIG to make it actually useful and not harmful, that would mean only 
packages that are buggy already would need fixing.

Thank you for your feedback,

Pavel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-03 Thread Pavel Simerda
- Original Message -
> From: "William Brown" 
> 4) For link local to work "nicely", mDNS name resolution should be
> installed and available by default. Avahi can provide such a service
> for ipv6.

Avahi doesn't work for IPv6 link-local addresses and GLIBC doesn't even allow 
nss-mdns to work. This only works with FreeBSD libc and patched Avahi/nss-mdns.

See:

https://bugzilla.redhat.com/show_bug.cgi?id=719178
http://sourceware.org/bugzilla/show_bug.cgi?id=14413

By default, Avahi doesn't work for IPv6 at all, as Lennart swithed it back to 
IPv4-only.

https://bugzilla.redhat.com/show_bug.cgi?id=821127

This is what one of the next features will be about:

https://fedoraproject.org/wiki/Features/ZeroconfNetworking

But I can't fix all of that myself and do my regular work in just one release 
:).

Cheers,

Pavel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-03 Thread Pavel Simerda
- Original Message -
> From: "Tomasz Torcz" 
> On Thu, Jan 03, 2013 at 08:18:19AM +1030, William Brown wrote:
> > > > = Features/DualstackNetworking =
> > > > https://fedoraproject.org/wiki/Features/DualstackNetworking
> > 
> > 1) For a user, there is no option in NetworkManager to enable
> > dhcp6c

It's started as a reaction to AdvManagedFlag or AdvOtherConfigFlag in router 
advertisements, as mandated by the RFCs.

> > from the gui. By Default, this option is "not listed" in
> > ifcfg-ethX,
> > even as a DHCP6C=no, making it hard to find and enable.

Don't use that.

> > 2) Privacy extensions still has no UI to enable / disable from
> > NetworkManager.

Out of scope of this Feature. But might be suitable for:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

Probably worth a bug report on gnome-control-center.

> > 3) dhclient prefix delegation often has issues on pppoe sessions,

Out of scope. No information about that. This would probably need a proper bug 
report.

> Does NetworkManager request prefix delegation nowadays?

IPv6 connection sharing is currently not supported in NetworkManager in any way.

See:

https://bugzilla.gnome.org/show_bug.cgi?id=593815

> It wasn't
> a year ago - https://bugzilla.redhat.com/show_bug.cgi?id=754086
> 
> --
> Tomasz Torcz Morality must always be based on
> practicality.
> xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-03 Thread Pavel Simerda
- Original Message -
> From: "Adam Williamson" 
> 
> On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
> > On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
> >  wrote:
> > > = Features/DualstackNetworking =
> > > https://fedoraproject.org/wiki/Features/DualstackNetworking
> > 
> > (Sending to the list instead of using the wiki talk page to
> > hopefully
> > gather more information from networking experts.  The recent-ish
> > bugzilla activity in this space does suggest that this is a good
> > topic
> > to revisit in detail, thanks for taking the effort on.)
> > 
> > 1. So what is the _precise_ scope of the ''proposed feature''?  For
> 
> Just to second this emotion: I'm very much on the IPv6 train in
> general,
> but it would be very nice if any changes to very sensitive distro
> components - glibc, NetworkManager, stuff like that - could be
> decided
> and nailed down *quickly*. I don't mind this being a sort of
> 'aspirational' feature in general, as it seems to be, but for core
> stuff
> - critpath - it would be very good to have a clearly defined scope
> well
> before we start cutting F19 builds.

So far I don't intend any modifications to NetworkManager in scope of this 
feature, except maybe address configuration format which has already been done.

I am working on thorough modifications to glibc's getaddrinfo, though. It 
unfortunately proved to fail in many ways. This is the main priority of the 
feature, followed by utility libraries (likeglib), and client and server 
applications.

Any help with clarification appreciated.

Cheers,

Pavel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-03 Thread Pavel Simerda
- Original Message -
> From: "William Brown" 
>
> On Thu, 2013-01-03 at 00:01 +, Peter Robinson wrote:
> > On Wed, Jan 2, 2013 at 9:48 PM, William Brown
> >  wrote:
> > > On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
> > >> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
> > >>  wrote:
> > >> > = Features/DualstackNetworking =
> > >> > https://fedoraproject.org/wiki/Features/DualstackNetworking
> > >
> > > I think that this is a really good goal. I can identify the
> > > following
> > > that probably need work as part of this to improve the user
> > > experience.
> > >
> > > 1) For a user, there is no option in NetworkManager to enable
> > > dhcp6c
> > > from the gui. By Default, this option is "not listed" in
> > > ifcfg-ethX,
> > > even as a DHCP6C=no, making it hard to find and enable.
> > >
> > > 2) Privacy extensions still has no UI to enable / disable from
> > > NetworkManager.
> > >
> > > 3) dhclient prefix delegation often has issues on pppoe sessions,
> > > meaning that you will often get the pppoe session dropping out,
> > > ipv4
> > > will recover correctly, but ipv6 will not re-request a prefix
> > > until some
> > > timeout, usually an hour, in which time all ipv6 services are
> > > unavailable. This causes DNS timeouts, webpages to respond
> > > slowly, email
> > > accounts to not fetch etc.
> > 
> > There's also other issues with NM and ppp/pppoe with IPv6. In the
> > service provider space this side of IPv6 is still a moving target
> > with
> > some standards evolving to enable ISPs to push IPv6 subnets out to
> > consumer routers and the like. There's still bugs like [1] to
> > resolve
> > in NM, I know it's closed but that was to open individual bugs and
> > I
> > think there's some bits left to do to properly deal with RFC 5072
> > for
> > v6 over ppp.
> > 
> > Peter
> > 
> > [1] https://bugzilla.gnome.org/show_bug.cgi?id=593813
> 
> I don't necessarily mean that NM should support PD for ppp
> interfaces,
> more that "some parts" of the whole IPv6 experience still need work
> for
> them to operate correctly.
> 
> However, saying that, it would be lovely if in my ifcfg-ppp I could
> just
> add a "DHCP6C-PD" option or the like, and have it work 
> 
> 
> 
> However, as others have said, the "scope" of this work should be
> defined.

From my point of view, it is defined as much as possible. It is all about 
system services and applications that connect, or accept connections over the 
network and, optionally, uses name resolution.

This is mainly about usage of IP addresses and name resolution.

> How will the "outcomes" be assessed? It may be a selfish
> view,
> but I would like to suggest that a good goal would be for a fedora
> machine to act as a ipv4 and ipv6 router with PD (and minimal fuss),

This is out of scope of this feature. But please look at other features
not yet submitted:

https://fedoraproject.org/wiki/Networking#Fedora_feature_pages

Especially:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

> as well as providing ipv4 and ipv6 services such as radvd, dhcp and
> dhcp6.

These have been tested and work. Major use cases documented here:

https://fedoraproject.org/wiki/Networking/Addressing

> These services should probably be defined as well. As already stated,
> a
> good goal would be to try having an "ipv6 only" system, as this will
> quickly highlight many of the issues around ipv6 usage on a network.

IPv6-only Fedora also works for me, at least Fedora 17 with the firewalld 
package installed.

> The reason I suggest the "router" is that it is one of the more
> 'complex' network oriented setups, and will implicitly test basic
> ipv6 connectivity

Unfortunately not. Network testing, and especially IPv6/dualstack testing is 
much more complex than just running an IPv6 system. Therefore even having an 
advanced IPv6 router on Fedora won't help with that.

Again, please look at:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

> ie link local

When writing this feature, I wasn't brave enough to include link-local. IPv6 
zero configuration networking needs much more work then just fixing a couple of 
applications and libraries.

See:

https://fedoraproject.org/wiki/Features/ZeroconfNetworking

> daemons like bind, etc.

Bind is a system service and seems to work rather well.

> Perhaps even a "disconnected" network that relies on link local only?

As above.

Thanks for your feedback,

Pavel Šimerda
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread John Reiser
On 01/02/2013 05:20 PM, Reindl Harald wrote:
> Am 03.01.2013 02:08, schrieb John Reiser:

>> I'd like to use ipv6 for my computers,
>> but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
>> and ipv4-because-ipv6-is-buggy devices (mythtv)
>> must continue to inter-operate to/from/with Fedora

> that is what "Dualstack" means

Good.  The point is that ipv4 consumer devices explicitly
are part of the deal, and cannot be ignored.  Such devices
tend to persist for several generations, and many cannot
be upgraded.  They don't use Fedora shared libraries.
Luckily most of them require only dhcp4 and http-over-tcp+ipv4,
but their actual implementations which work today in Fedora
must continue to work without change for many releases.
For instance, dual stacking must not change the latencies
of dhcp4.

-- 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread Reindl Harald


Am 03.01.2013 02:08, schrieb John Reiser:
>> = Features/DualstackNetworking =
>> https://fedoraproject.org/wiki/Features/DualstackNetworking
> 
> I'd like to use ipv6 for my computers,
> but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
> and ipv4-because-ipv6-is-buggy devices (mythtv)
> must continue to inter-operate to/from/with Fedora

that is what "Dualstack" means



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread John Reiser
> = Features/DualstackNetworking =
> https://fedoraproject.org/wiki/Features/DualstackNetworking

I'd like to use ipv6 for my computers,
but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
and ipv4-because-ipv6-is-buggy devices (mythtv)
must continue to inter-operate to/from/with Fedora.

-- 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread William Brown
On Thu, 2013-01-03 at 00:01 +, Peter Robinson wrote: 
> On Wed, Jan 2, 2013 at 9:48 PM, William Brown  wrote:
> > On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
> >> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik  wrote:
> >> > = Features/DualstackNetworking =
> >> > https://fedoraproject.org/wiki/Features/DualstackNetworking
> >
> > I think that this is a really good goal. I can identify the following
> > that probably need work as part of this to improve the user experience.
> >
> > 1) For a user, there is no option in NetworkManager to enable dhcp6c
> > from the gui. By Default, this option is "not listed" in ifcfg-ethX,
> > even as a DHCP6C=no, making it hard to find and enable.
> >
> > 2) Privacy extensions still has no UI to enable / disable from
> > NetworkManager.
> >
> > 3) dhclient prefix delegation often has issues on pppoe sessions,
> > meaning that you will often get the pppoe session dropping out, ipv4
> > will recover correctly, but ipv6 will not re-request a prefix until some
> > timeout, usually an hour, in which time all ipv6 services are
> > unavailable. This causes DNS timeouts, webpages to respond slowly, email
> > accounts to not fetch etc.
> 
> There's also other issues with NM and ppp/pppoe with IPv6. In the
> service provider space this side of IPv6 is still a moving target with
> some standards evolving to enable ISPs to push IPv6 subnets out to
> consumer routers and the like. There's still bugs like [1] to resolve
> in NM, I know it's closed but that was to open individual bugs and I
> think there's some bits left to do to properly deal with RFC 5072 for
> v6 over ppp.
> 
> Peter
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=593813

I don't necessarily mean that NM should support PD for ppp interfaces,
more that "some parts" of the whole IPv6 experience still need work for
them to operate correctly. 

However, saying that, it would be lovely if in my ifcfg-ppp I could just
add a "DHCP6C-PD" option or the like, and have it work  



However, as others have said, the "scope" of this work should be
defined. How will the "outcomes" be assessed? It may be a selfish view,
but I would like to suggest that a good goal would be for a fedora
machine to act as a ipv4 and ipv6 router with PD (and minimal fuss), as
well as providing ipv4 and ipv6 services such as radvd, dhcp and dhcp6.
These services should probably be defined as well. As already stated, a
good goal would be to try having an "ipv6 only" system, as this will
quickly highlight many of the issues around ipv6 usage on a network.   

The reason I suggest the "router" is that it is one of the more
'complex' network oriented setups, and will implicitly test basic ipv6
connectivity ie link local, daemons like bind, etc. Perhaps even a
"disconnected" network that relies on link local only?



-- 
Sincerely,

William Brown

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread Peter Robinson
On Wed, Jan 2, 2013 at 9:48 PM, William Brown  wrote:
> On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
>> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik  wrote:
>> > = Features/DualstackNetworking =
>> > https://fedoraproject.org/wiki/Features/DualstackNetworking
>
> I think that this is a really good goal. I can identify the following
> that probably need work as part of this to improve the user experience.
>
> 1) For a user, there is no option in NetworkManager to enable dhcp6c
> from the gui. By Default, this option is "not listed" in ifcfg-ethX,
> even as a DHCP6C=no, making it hard to find and enable.
>
> 2) Privacy extensions still has no UI to enable / disable from
> NetworkManager.
>
> 3) dhclient prefix delegation often has issues on pppoe sessions,
> meaning that you will often get the pppoe session dropping out, ipv4
> will recover correctly, but ipv6 will not re-request a prefix until some
> timeout, usually an hour, in which time all ipv6 services are
> unavailable. This causes DNS timeouts, webpages to respond slowly, email
> accounts to not fetch etc.

There's also other issues with NM and ppp/pppoe with IPv6. In the
service provider space this side of IPv6 is still a moving target with
some standards evolving to enable ISPs to push IPv6 subnets out to
consumer routers and the like. There's still bugs like [1] to resolve
in NM, I know it's closed but that was to open individual bugs and I
think there's some bits left to do to properly deal with RFC 5072 for
v6 over ppp.

Peter

[1] https://bugzilla.gnome.org/show_bug.cgi?id=593813
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread Adam Williamson
On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik  wrote:
> > = Features/DualstackNetworking =
> > https://fedoraproject.org/wiki/Features/DualstackNetworking
> 
> (Sending to the list instead of using the wiki talk page to hopefully
> gather more information from networking experts.  The recent-ish
> bugzilla activity in this space does suggest that this is a good topic
> to revisit in detail, thanks for taking the effort on.)
> 
> 1. So what is the _precise_ scope of the ''proposed feature''?  For

Just to second this emotion: I'm very much on the IPv6 train in general,
but it would be very nice if any changes to very sensitive distro
components - glibc, NetworkManager, stuff like that - could be decided
and nailed down *quickly*. I don't mind this being a sort of
'aspirational' feature in general, as it seems to be, but for core stuff
- critpath - it would be very good to have a clearly defined scope well
before we start cutting F19 builds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread Tomasz Torcz
On Thu, Jan 03, 2013 at 08:18:19AM +1030, William Brown wrote:
> > > = Features/DualstackNetworking =
> > > https://fedoraproject.org/wiki/Features/DualstackNetworking
> 
> 1) For a user, there is no option in NetworkManager to enable dhcp6c
> from the gui. By Default, this option is "not listed" in ifcfg-ethX,
> even as a DHCP6C=no, making it hard to find and enable. 
> 
> 2) Privacy extensions still has no UI to enable / disable from
> NetworkManager.
> 
> 3) dhclient prefix delegation often has issues on pppoe sessions,

  Does NetworkManager request prefix delegation nowadays? It wasn't
a year ago - https://bugzilla.redhat.com/show_bug.cgi?id=754086

-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread William Brown
On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote: 
> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik  wrote:
> > = Features/DualstackNetworking =
> > https://fedoraproject.org/wiki/Features/DualstackNetworking

I think that this is a really good goal. I can identify the following
that probably need work as part of this to improve the user experience.

1) For a user, there is no option in NetworkManager to enable dhcp6c
from the gui. By Default, this option is "not listed" in ifcfg-ethX,
even as a DHCP6C=no, making it hard to find and enable. 

2) Privacy extensions still has no UI to enable / disable from
NetworkManager.

3) dhclient prefix delegation often has issues on pppoe sessions,
meaning that you will often get the pppoe session dropping out, ipv4
will recover correctly, but ipv6 will not re-request a prefix until some
timeout, usually an hour, in which time all ipv6 services are
unavailable. This causes DNS timeouts, webpages to respond slowly, email
accounts to not fetch etc. 

4) For link local to work "nicely", mDNS name resolution should be
installed and available by default. Avahi can provide such a service for
ipv6. 


Perhaps a good way to test this, would be to try and run a system or
network as "ipv6 only", as that will quickly identify short comings of
the system. 


-- 
Sincerely,

William Brown

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

2013-01-02 Thread Miloslav Trmač
On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik  wrote:
> = Features/DualstackNetworking =
> https://fedoraproject.org/wiki/Features/DualstackNetworking

(Sending to the list instead of using the wiki talk page to hopefully
gather more information from networking experts.  The recent-ish
bugzilla activity in this space does suggest that this is a good topic
to revisit in detail, thanks for taking the effort on.)

1. So what is the _precise_ scope of the ''proposed feature''?  For
example, does "glibc: name resolution must work properly" mean that
you have some specific proposals to change glibc?

(https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
suggests changing glibc as one of the options.  Have you decided which
option you propose?  In general, glibc maintainers' signoff or at
least significant discussion would probably be required for any glibc
change of this kind.  FWIW, historically it was recommended to have
AI_ADDRCONFIG enabled, see
http://www.akkadia.org/drepper/userapi-ipv6.html .)

2. We already have a guideline requiring IPv6
(https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuidelines#Networking_Support
); to the extent that this feature would propose specific ways to use
the API, the packaging guideline should point to documentation that
describes the correct way.  It would be great to get a wide review of
the proposed approach before any extensive effort to modify many
packages starts.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel