Subject: IPv6 w.g. Last Call on "Basic Socket Interface Extensions for IPv6"

From: Bob Hinden <[email-masked]>
Date: Tue, 11 Dec 2001 19:52:53 -0800

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

	Title		: Basic Socket Interface Extensions for IPv6
	Author(s)	: R. Gilligan, S. Thomson, J. Bound, W. Stevens
	Filename	: draft-ietf-ipngwg-rfc2553bis-04.txt
	Pages		: 32
	Date		: 27-Nov-01

This document will replace RFC2553 that is currently an Informational 
RFC.  The changes from RFC2553 are listed on pages 29 and 30 of the draft.

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will end two
weeks from today on December 26, 2001.

Bob Hinden / Steve Deering

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 17 Dec 2001 09:08:32 -1000 (HST)

> Bob Hinden / Steve Deering

This may be a bit late but I do think that the API should address better
compatibility with IPv4 multicast.  There was some discussion earlier this
year about this but no consensus was reached other than that it should be
fixed.

The problem I think would be helped if, for the purposes of this API,
section 3.7 was extended to optionally allow for a pseudo IPv4-mapped
multicast address.  I'm suggesting adding two sentences to paragraph 2 of
section 3.7:

"These addresses can be generated automatically by the getaddrinfo()
function, when the specified host has only IPv4 addresses (as described in
Section 6.1 and 6.2).  For the purposes of this API, the allowed range of
<IPv4-address> may be extended beyond that defined in RFC 2373 to also
include multicast addresses.  The resulting mapped address should be
treated as a multicast address."

This addition is motivated by one of the design considerations of the API:

" - Where possible, applications should be able to use this
     API to interoperate with both IPv6 and IPv4 hosts.  Applications
     should not need to know which type of host they are
     communicating with."

And further down we have:

"Because of the importance of providing IPv4 compatibility in the API,
these extensions are explicitly designed to operate on machines that
provide complete support for both IPv4 and IPv6."