Just note: recent python-ethtool (0.4) is able to retrieve IPv6 addresses.

Committed ed5bf74acf118784f7abcd4fc956730e4f2ed9f3

Available in 0.99.4+

This patch changes fact names!

Most notably, 

net.interface.eth0.broadcast -> net.interface.eth0.ipv4_broadcast
net.interface.lo.netmask -> net.interface.lo.ipv4_netmask
net.interface.lo.ipaddr -> net.interface.lo.ipv4_address
net.interface.lo.hwaddr -> net.interface.lo.mac_address
network.ipaddr -> network.ipv4_address

This change is meant to reflect that some of the fact information
is only relevant for IPv4 and to bring the fact names more in-line
with what ethtool calls the various interface properties.

Also, the ipv6 facts are suffixed by the scope for the address.  For example,

net.interface.eth0.ipv6_address.link: fe80::5054:ff:feb5:8309

The "link" portion is the scope.  As I understand it, the same interface can have multiple IPv6 addresses each with a different scope.

Please note some comments:

*  ethtool returns different scope for "public" IPv6 address. On EL6 it is "universe", while on EL5 is is "global".
In rhn_client_tools we put there:
                scope = ip6.scope
                if scope == 'global':
                    scope = 'universe'
Just to be uniform across platform. It may not bother you, but you should be aware that you will get on el6:
 net.interface.eth0.ipv6_address.universe: 2620:52:0:221b:dad3:85ff:fe81:bda7
while on el5 you will get:
 net.interface.eth0.ipv6_address.global: 2620:52:0:221b:dad3:85ff:fe81:bda7

* I did not find in IPv6 documentation if it possible of if it is forbidden to have for one interface and one scope two ip addresses (in two or even one netmask). It is definitelly possible for IPv4. If it is possible for IPv6 then you have problem with your current code.

* in getNetworkInfo you have:
  host = socket.gethostname()
which does not need to return FQDN. And may not be resolvable from outside of this one particular machine. In rhn_client_tools we recently flipped to:
       for family in (AF_INET6, AF_INET):
            try:
                s = socket.socket(family)
            except socket.error:
                continue

            try:
                s.settimeout(5)
                s.connect((server, port))
                intf_tmp = s.getsockname()[0]
                if family == AF_INET:
                    intf = intf_tmp
                else:
                    intf6 = intf_tmp
                hostname_tmp = socket.getfqdn(intf_tmp)
                if hostname_tmp != intf_tmp:
                    hostname = hostname_tmp

which I find more robust. It returns you hostname which you can safely use in kickstats or generaly in management tools (like Katello). And it prefer IPv4 hostnames rather then IPv6 hostnames - as they can be different.

I will leave up to you if you address this issues in this BZ, or if you clone it, or if you will ignore it.

Moving to verified..

RPM used:
[root@dhcp201-162 ~]# rpm -qa | grep subscription-manager
subscription-manager-firstboot-0.99.9-1.git.2.0e7297c.el6.x86_64
subscription-manager-0.99.9-1.git.2.0e7297c.el6.x86_64
subscription-manager-migration-0.99.9-1.git.2.0e7297c.el6.x86_64
subscription-manager-migration-data-1.12.2-1.git.0.ede4958.el6.noarch
subscription-manager-debuginfo-0.99.9-1.el6.x86_64
subscription-manager-gnome-0.99.9-1.git.2.0e7297c.el6.x86_64


[root@dhcp201-162 ~]# subscription-manager facts --list | grep ipv6
net.interface.br0.ipv6_address.global: 2620:52:0:41c9:be30:5bff:fed4:a098
net.interface.br0.ipv6_address.link: fe80::be30:5bff:fed4:a098
net.interface.br0.ipv6_netmask.global: 64
net.interface.br0.ipv6_netmask.link: 64
net.interface.eth0.ipv6_address.link: fe80::be30:5bff:fed4:a098
net.interface.eth0.ipv6_netmask.link: 64
net.interface.lo.ipv6_address.host: ::1
net.interface.lo.ipv6_netmask.host: 128
net.interface.vnet0.ipv6_address.link: fe80::fc54:ff:fe71:b99b
net.interface.vnet0.ipv6_netmask.link: 64
network.ipv6_address: ::1

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0804.html