This is a multipart MIME message.

--===_0_Tue_Oct_22_09:11:36__1996
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).


--===_0_Tue_Oct_22_09:11:36__1996
Content-Type: message/rfc822
Content-Description: 2293

	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
Message-Id: <199610192045.NAA28623@kohala.kohala.com>
From: rstevens@kohala.com (W. Richard Stevens)
Date: Sat, 19 Oct 1996 13:45:15 -0700
Reply-To: "W. Richard Stevens" <rstevens@kohala.com>
To: ipng@sunroof.eng.sun.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
<draft-stevens-advanced-api-00.txt>.

If you want a copy before then, help yourself to:
ftp://ftp.kohala.com/pub/rstevens/draft-stevens-advanced-api-00.txt

Attached is the Introduction.

	Rich Stevens

---------------------------------------------------------------------

1.  Introduction

    Specifications are in progress for changes to the sockets API to
    support IP version 6 [2].  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
    is necessary.

    There are also features from the basic IPv6 specification that are
    not addressed in [2]: 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
        headers.

    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 majordomo@sunroof.eng.sun.com

--===_0_Tue_Oct_22_09:11:36__1996
Content-Type: text/plain; charset=us-ascii

Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Westford, MA              Disclaimer: I disavow all knowledge of this message

--===_0_Tue_Oct_22_09:11:36__1996--