The latest Windows builds for Python 3.5.3/3.6.0 do not export socket.IPPROTO_IPV6, even though e.g. socket.IPV6_V6ONLY is exported. This seems to be wrong to me as IPV6_V6ONLY requires the corresponding socket option level IPPROTO_IPV6 to be actually useful. The same issue at least also applies to IPPROTO_IPV4.

christian.heimes mentioned that this is intended behaviour in https://bugs.python.org/issue6926 as Windows would not define the constants. Now I am all but an expert on this, but it seems to me that IPPROTO_IPV6 is defined in Windows:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff543746(v=vs.85).aspx. Apologies if I'm missing something here.

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32
>>> import socket; socket.IPPROTO_IPV6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'socket' has no attribute 'IPPROTO_IPV6'

As a workaround, IPPROTO_IPV6 can be substituted with the hardcoded constant 41.

The macro is defined but not defined. If I insert the following line before the #ifdef check:

    #define IPPROTO_IPV6 IPPROTO_IPV6

then the constant gets added:

    >>> import _socket
    >>> _socket.IPPROTO_IPV6
    41

The same applies to IPPROTO_IPV4 and probably others.

Unless someone has a better (more automated) way to handle the Winsock IPPROTO enum, I suggest we either special-case the individual tests for MS_WINDOWS when we know that Winsock defines the value; or just define macros for the values in the enum:

    #ifdef MS_WINDOWS /* Macros based on the IPPROTO enum. */
    #define IPPROTO_ICMP IPPROTO_ICMP
    #define IPPROTO_IGMP IPPROTO_IGMP
    #define IPPROTO_GGP IPPROTO_GGP
    #define IPPROTO_TCP IPPROTO_TCP
    #define IPPROTO_PUP IPPROTO_PUP
    #define IPPROTO_UDP IPPROTO_UDP
    #define IPPROTO_IDP IPPROTO_IDP
    #define IPPROTO_ND IPPROTO_ND 
    #define IPPROTO_RAW IPPROTO_RAW
    #define IPPROTO_MAX IPPROTO_MAX
    #if (_WIN32_WINNT >= 0x0501)
    #define IPPROTO_HOPOPTS IPPROTO_HOPOPTS
    #define IPPROTO_IPV4 IPPROTO_IPV4
    #define IPPROTO_IPV6 IPPROTO_IPV6
    #define IPPROTO_ROUTING IPPROTO_ROUTING
    #define IPPROTO_FRAGMENT IPPROTO_FRAGMENT
    #define IPPROTO_ESP IPPROTO_ESP
    #define IPPROTO_AH IPPROTO_AH
    #define IPPROTO_ICMPV6 IPPROTO_ICMPV6
    #define IPPROTO_NONE IPPROTO_NONE
    #define IPPROTO_DSTOPTS IPPROTO_DSTOPTS
    #define IPPROTO_ICLFXBM IPPROTO_ICLFXBM
    #endif /* (_WIN32_WINNT >= 0x0501) */
    #if (_WIN32_WINNT >= 0x0600)
    #define IPPROTO_ST IPPROTO_ST
    #define IPPROTO_CBT IPPROTO_CBT
    #define IPPROTO_EGP IPPROTO_EGP
    #define IPPROTO_IGP IPPROTO_IGP
    #define IPPROTO_RDP IPPROTO_RDP
    #define IPPROTO_PIM IPPROTO_PIM
    #define IPPROTO_PGM IPPROTO_PGM
    #define IPPROTO_L2TP IPPROTO_L2TP
    #define IPPROTO_SCTP IPPROTO_SCTP
    #endif /* (_WIN32_WINNT >= 0x0600) */
    #endif /* MS_WINDOWS */

or call PyModule_AddIntConstant(m, "IPPROTO_ICMP", IPPROTO_ICMP) and so on for each enum value.

We may just want to copy the values from the enum if there are different versions when they were introduced. But if that's not a problem, adding the MS_WINDOWS check is better than defining new macros.

Can confirm this is still a problem in latest versions of 3.5, 3.6, and 3.7

Any progress made on this?

No progress, but I like the extra defines idea best (directly in socketmodule.c, not in a public header file). That's the easiest way to close the gap between (apparently) real constants used on Windows and the preprocessor defines (apparently) used elsewhere.

It turns out having this fix would be useful for proceeding with issue17561, which right now cannot support dual-stack IPv4/6 on Windows because IPPROTO_IPV6 is missing, see my comment:
https://github.com/python/cpython/pull/11784#issuecomment-465078646

@eryksun I tried your patch (https://bugs.python.org/issue29515#msg287477) on Windows 10 and it looks good. It introduces the following new constants:

IPPROTO_IGMP
IPPROTO_GGP
IPPROTO_PUP
IPPROTO_IDP
IPPROTO_ND
IPPROTO_MAX
IPPROTO_HOPOPTS
IPPROTO_IPV4
IPPROTO_IPV6
IPPROTO_ROUTING
IPPROTO_FRAGMENT
IPPROTO_ESP
IPPROTO_AH
IPPROTO_ICMPV6
IPPROTO_NONE
IPPROTO_DSTOPTS
IPPROTO_EGP
IPPROTO_PIM
IPPROTO_SCTP

...plus these Windows-only ones for which I had to add an additional PyModule_AddIntMacro() call:

IPPROTO_ICLFXBM
IPPROTO_ST
IPPROTO_CBT
IPPROTO_IGP
IPPROTO_RDP
IPPROTO_PGM
IPPROTO_L2TP

Up 'till now only these ones were exposed:

IPPROTO_ICMP
IPPROTO_TCP
IPPROTO_UDP
IPPROTO_RAW

I think we can proceed with this. Care to provide a patch?

@Eryk do you mind if I make a PR with your code(I will of course author you)? Regardless from issue17561 I think this is an important fix because without IPPROTO_IPV6 is not possible to implement a dual-stack IPv4/6 socket on Windows.

> do you mind if I make a PR with your code(I will of course author you)?

Go for it. I prefer no credit, but you're free to do as you wish.

Done:
https://github.com/python/cpython/pull/12183/
This adds quite a bunch of new constants so I would be keen on considering it an enhancement rather than a bugfix and land it in 3.8 only. As for 3.7 and 3.6 (and 2.7?) it may make sense to fix IPPROTO_IPV6 only. Thoughts?

I lean towards it being considered a bug fix. First, the lack of parity between Windows and Linux-based OSs causes confusion. Second, the current workaround to hard-code the value in is far from best practice.

The problem is that if we add lots of new constants in 3.7.3, code written in that version very easily becomes incompatible with 3.7.2 and earlier. So we don't like making changes like that.

If we know which ones are "normally" defined on Linux machines, where specifying them on Windows will make it just work, then I'd just add those ones.

Anything that is Windows-specific (if any?) or that may cause applications to break if they're testing for the constant but it doesn't work smoothly should not go back to 3.7.

I see your point.

Then perhaps only a subset of the more vital ones get added to previous releases?

#define IPPROTO_IPV4 IPPROTO_IPV4
#define IPPROTO_IPV6 IPPROTO_IPV6
#define IPPROTO_TCP IPPROTO_TCP
#define IPPROTO_UDP IPPROTO_UDP
#define IPPROTO_ICMP IPPROTO_ICMP
#define IPPROTO_ICMPV6 IPPROTO_ICMPV6
#define IPPROTO_RAW IPPROTO_RAW

IPPROTO_TCP/UDP/RAW/ICMP are already there. AFAICT the only useful one here is IPPROTO_IPV6, because it's needed for enabling dual-stack. I don't think IPPROTO_IPV4 is a must (e.g. it's not available on Linux). Same for IPPROTO_ICMPV6. The only reason we may decide to backport one of these is because they are not officially documented (see issue27409). That gives us some flexibility but potentially it may do more harm than good because an app running on 3.7.3 would break on 3.7.2. Note: the original ticket (issue6926) is from 2009, meaning that whoever wanted these missing constants on Windows already hard-coded them in their Python code long ago.

I'd like to move forward with this in order to fix issue17561. If there are no complaints I'm gonna merge this in ~ a week.

New changeset 3eca28c61363a03b81b9fb12775490d6e42d8ecf by Giampaolo Rodola in branch 'master':
bpo-29515: add missing socket.IPPROTO_* constants on Windows (GH-12183)
https://github.com/python/cpython/commit/3eca28c61363a03b81b9fb12775490d6e42d8ecf

Merged. I'm agnostic about backporting IPPROTO_IPV6 (or others) on < 3.8 so I'll leave it up to somebody else to decide/implement.

As of June last year, Python 3.7 is in security fix only mode, so there's nothing more to be done here.