Subject: Re: IP_RECVIF addition
To: Bill Fenner <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 10/22/1996 09:14:12
This is a multipart MIME message.
Content-Type: text/plain; charset=us-ascii
The following internet draft contains a slightly different way of doing
that for IPv6. Add a correspond mode for Ipv4 should be trivial. I may
be biased since I worked on the draft but it solves in a cleaner way.
(get both destination address and the interface index (no sockaddr_dl)
in one ancillary data message).
id AA26515; Sat, 19 Oct 1996 17:01:29 -0400
id QAA03858; Sat, 19 Oct 1996 16:56:26 -0400 (EDT)
id NAA03345; Sat, 19 Oct 1996 13:47:38 -0700
id AA03797; Sat, 19 Oct 96 13:53:08 PDT
id AA03791; Sat, 19 Oct 96 13:52:54 PDT
id NAA12377; Sat, 19 Oct 1996 13:46:03 -0700
id NAA28623; Sat, 19 Oct 1996 13:45:16 -0700
From: firstname.lastname@example.org (W. Richard Stevens)
Date: Sat, 19 Oct 1996 13:45:15 -0700
Reply-To: "W. Richard Stevens" <email@example.com>
Subject: (IPng 2351) new "Advanced Sockets API for IPv6" I-D
Matt Thomas and I have just submitted a new I-D that picks up where the
existing "Basic Socket Interface Extensions for IPv6" I-D leaves off.
It should appear in the I-D directories sometime this coming week as
If you want a copy before then, help yourself to:
Attached is the Introduction.
Specifications are in progress for changes to the sockets API to
support IP version 6 . These changes are for TCP and UDP-based
applications. The current document defines some the "advanced"
features of the sockets API that are required for applications to
take advantage of additional features of IPv6.
Today, the portability of applications using IPv4 raw sockets is
quite high, but this is mainly because most IPv4 implementations
started from a common base (the Berkeley source code) or at least
started with the Berkeley headers. This allows programs such as
Ping and Traceroute, for example, to compile with minimal effort on
many hosts that support the sockets API. With IPv6, however, there
is no common source code base that implementors are starting from,
and the possibility for divergence at this level between different
implementations is high. To avoid a complete lack of portability
amongst applications that use raw IPv6 sockets, some standardization
There are also features from the basic IPv6 specification that are
not addressed in : sending and receiving hop-by-hop options,
destination options, and routing headers, specifying the outgoing
interface, and being told of the receiving interface.
This document can be divided into the following main sections.
1. Definitions of the basic constants and structures required for
applications to use raw IPv6 sockets. This includes structure
definitions for the IPv6 and ICMPv6 headers and all associated
constants (e.g., values for the next header field).
2. Some basic semantic definitions for IPv6 raw sockets. For exam-
ple, a raw ICMPv4 socket requires the application to calculate
and store the ICMPv4 header checksum. But with IPv6 this would
require the application to choose the source IPv6 address
because the source address is part of the pseudo header that
ICMPv6 now uses for its checksum computation. It should be
defined that with a raw ICMPv6 socket the kernel always calcu-
lates and stores the ICMPv6 header checksum.
3. Interface identification: how applications specify the outgoing
interface and are told of the incoming interface. There are a
class of applications that need this capability and the tech-
nique should be portable.
4. Access to the optional hop-by-hop, destination, and routing
The final two items (interface identification and access to the IPv6
extension headers) are specified using the "ancillary data" fields
that were added to the 4.3BSD Reno sockets API in 1990. The reason
is that these ancillary data fields are part of the Posix.1g stan-
dard (which should be approved in 1997) and should therefore be
adopted by most vendors.
This document does not address application access to either the
authentication header or the encapsulating security payload header.
IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page: http://playground.sun.com/ipng
Direct all administrative requests to firstname.lastname@example.org
Content-Type: text/plain; charset=us-ascii
Matt Thomas Internet: email@example.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html
Westford, MA Disclaimer: I disavow all knowledge of this message