git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Checking refusal of a network connection


On 2019-06-01 20:44:29 +0200, Markus Elfring wrote:
> > Which specific information in that man page contradicts what I wrote?
> 
> We can agree that the mentioned IP addresses are distinct.
> But the corresponding functionality should be equivalent.
> 
> 
> > If you think of
> >
> > | IPv4 connections can be handled with the v6 API by using the
> > | v4-mapped-on-v6 address type; thus a program needs to support only
> > | this API  type to  support  both  protocols.
> >
> > please note that 127.0.0.1 mapped to IPv6 is ::7f00:1, not ::1.

Oops, that should have been ::ffff:7f00:1.


> I find another information like ?This is handled transparently by
> the address handling functions in the C library.? also interesting.

"Handled transparently" means that an ipv6 server can handle connections
from ipv4 clients without doing anything special. They just appear to
come from a specific IPv6 address range. It doesn't mean the OS performs
random address translations according to user's expectations of
"equivalence".


> > So you still need to bind to two addresses.
> 
> I am unsure about this conclusion.

Well, we don't study theology here. We don't have to theorize (no pun
intended), we can experiment. Why don't you just try it out?


> Under which circumstances will the Python programming interfaces
> support the direct usage of the identification ?::1??

I'm not sure I understand the question. They do.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20190602/ecb0bc1b/attachment.sig>