yum dependency resolution behaviour

I have come across a behaviour in yum which I find a little strange when updating a package that has dependencies. I can resolve the issue easily (provide the dependency) but I am interested to know why yum behaves the way it does. Take the following example:

[root@rhel65 ~]# rpm -qa | grep iptables
iptables-1.4.7-11.el6.x86_64
iptables-ipv6-1.4.7-11.el6.x86_64


[root@rhel65 ~]# yum update iptables-1.4.7-14.el6.x86_64.rpm
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Install Process
Examining iptables-1.4.7-14.el6.x86_64.rpm: iptables-1.4.7-14.el6.x86_64
Marking iptables-1.4.7-14.el6.x86_64.rpm as an update to iptables-1.4.7-11.el6.x86_64
Resolving Dependencies
--> Running transaction check
---> Package iptables.x86_64 0:1.4.7-11.el6 will be updated
--> Processing Dependency: iptables = 1.4.7-11.el6 for package: iptables-ipv6-1.4.7-11.el6.x86_64
---> Package iptables.x86_64 0:1.4.7-14.el6 will be an update
--> Running transaction check
---> Package iptables.i686 0:1.4.7-11.el6 will be installed
--> Processing Dependency: libm.so.6 for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2(GLIBC_2.1) for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2(GLIBC_2.0) for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libdl.so.2 for package: iptables-1.4.7-11.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.7) for package: iptables-1.4.7-11.el6.i686
--> Running transaction check
---> Package glibc.i686 0:2.12-1.132.el6 will be installed
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.132.el6.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.132.el6.i686
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.14.3-9.el6 will be installed
--> Finished Dependency Resolution
Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:

         1. You have an upgrade for iptables which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of iptables of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude iptables.otherarch ... this should give you an error
            message showing the root cause of the problem.

         2. You have multiple architectures of iptables installed, but
            yum can only see an upgrade for one of those arcitectures.
            If you don't want/need both architectures anymore then you
            can remove the one with the missing update and everything
            will work.

         3. You have duplicate versions of iptables installed already.
            You can use "yum check" to get yum show these errors.

       ...you can also use --setopt=protected_multilib=false to remove
       this checking, however this is almost never the correct thing to
       do as something else is very likely to go wrong (often causing
       much more problems).

       Protected multilib versions: iptables-1.4.7-14.el6.x86_64 != iptables-1.4.7-11.el6.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

The iptables-ipv6 package depends on the iptables package. In this example, I intentionally attempt to upgrade only the iptables package (which I would expect to fail), but the part that intrigues me is how yum fails. Because the upgrade is increasing the iptables package version, yum then attempts to resolve the iptables-ipv6 package dependency using the equivalent versioned iptables.i686 package which then leads it down a path of continued dependency solving.

It correctly explains the situation in suggestion '1.' of the error, but my questions are:

Would the i686 version of the package really solve the dependency for iptables-ipv6.x86_64? why does yum even attempt that? The iptables.i686 provides 'iptables' which iptables-ipv6 is looking for, but the configuration will result in iptables-ipv6.x86_64 and iptables.i686 at the same version being apparently OK for dependency requirements? (ignoring the upgraded iptables.x86_64).

The behaviour I expected was for yum to complain that iptables-ipv6 depends on iptables (without the resulting i686 package treasure hunt), which is exactly how native RPM handles it:

[root@rhel65 ~]# rpm -Uvh iptables-1.4.7-14.el6.x86_64.rpm
warning: iptables-1.4.7-14.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
error: Failed dependencies:
    iptables = 1.4.7-11.el6 is needed by (installed) iptables-ipv6-1.4.7-11.el6.x86_64

Why are they handled differently?