bug-hurd
[Top][All Lists]
Advanced

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

Re: Networking design proposal


From: Niels Möller
Subject: Re: Networking design proposal
Date: 26 Oct 2002 23:59:06 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Olivier Péningault <peningault@free.fr> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]