Olivier Péningault <[EMAIL PROTECTED]> writes:
> I don't know where you saw this use of IPv6 address that automagically
> include IPv4 addresses.
I'm talking about the "IPv4-mapped IPv6 address", as defined in section 2.5.4 in
RFC 2373 (you've found it already).
The hack to let an ipv6 socket accept ipv4 connections is described in
RFC 2553, section 3.7:
3.7 Compatibility with IPv4 Nodes
The API also provides a different type of compatibility: the ability
for IPv6 applications to interoperate with IPv4 applications. This
feature uses the IPv4-mapped IPv6 address format defined in the IPv6
addressing architecture specification [2]. This address format
allows the IPv4 address of an IPv4 node to be represented as an IPv6
address. The IPv4 address is encoded into the low-order 32 bits of
the IPv6 address, and the high-order 96 bits hold the fixed prefix
0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows:
::FFFF:<IPv4-address>
These addresses can be generated automatically by the
getipnodebyname() function when the specified host has only IPv4
addresses (as described in Section 6.1).
Applications may use PF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call. When applications use PF_INET6 sockets
to accept TCP connections from IPv4 nodes, or receive UDP packets
from IPv4 nodes, the system returns the peer's address to the
application in the accept(), recvfrom(), or getpeername() call using
a sockaddr_in6 structure encoded this way.
This is an informational rfc, and there's as far as I know no standard
that requires this behavior. There was a long discussion on the ietf
ipng list some year ago on the meaning of the ipv6 wildcard address,
which ended up with a socket option one can set to enable or disable
the ipv4 mapped behaviour. The default behaviour was left undefined,
iirc.
If you say this hack is ugly and that it shouldn't be supported,
that's fine with me, you just need to be aware what you're doing.
> How dhcp will work ?
I'm not familiar with the details of the dhcp protocol, so I'm afraid
I can't give a very detailed answer. But I think the code will have to
operate on a single network interface (i.e. use the layer 2 or "layer
3 part 1" interfaces). A more general question is how to implement
debian's (say) ifup program. Any hooks we'll need for that has to be
implemented in the appropriate layer.
Each layer should probably provide some way for a user of that layer
to get to the layer underneath.
> What about sockets ? Who cares about them, how do they work (we bind on
> a per-interface basis, or on all interfaces ?) ?
I'm not sure I understand the question. A "socket" can mean either an
abstract tuple <ip-address, port, ip-address, port> identifying the
two endpoints of a connection. Or it can mean the socket programming
api that comes from bsd.
We must support the sockets api, as it's the defacto standard (even
w*ndows has the same api, more or less). But if we can arrange things
so that some or all of the socket calls like connect, bind, accept,
etc, are operations on nodes in the filesystem, that would be
excellent.
I haven't made up my mind, my description in the "layer 4" section was
quite fuzzy, because there seems to be several sensible ways to
organize it. The two I'll start looking at is (i) using the current
pfinet interface (now that I've found the .defs file, it looks quite
simple, it's basically a delegation of the socket api calls to a
separate server), and (ii) something more along the lines of plan 9,
mapping the socket name space into the filesystem.
Regards,
/Niels
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
