Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Sep 1999 22:19:04 -0700 (PDT)

> 	For example, with regard to IPv4 mapped address, the current document
> 	falis to define the kernel behavior, like:
> 	- what should happen when IPv6 wildcard bind(2) is performed on
> 	  port X, then IPv4 specific bind(2) is performed onto port X
> 	Actually current document defined nothing about port number space
> 	treatment (whether IPv6 TCP port number space and IPv4 TCP port number
> 	space is unified, or separated).

I recall there being some email discussion on this a while back,
but I don't recall if we reached consensus.
In any case, this would be a clarification to the basic API.

> 	There are too many interactions between two AFs introduced by
> 	IPv4 mapped address.  I do not think it to be healthy.

I agree that adding much more features to mapped address support 
adds a lot of complexity.
We've stayed away from any IP* options when using mapped addresses.
Thus you can use IPPROTO_IP options on AF_INET sockets.
And you can use IPPROTO_IPV6 options on AF_INET6 sockets as long
as they are not bound or connected to a mapped address.
This limitation helps preserve some sanity in the IP code.

   Erik

--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 02 Sep 1999 14:46:53 +0900

>In any case, this would be a clarification to the basic API.

	For bind(2) ordering, I'm not sure if we can define behaviors for all
	the possibilities, there are too many cases.

	For port number space issue, I heard from someone that X/Open defined
	it to some extent.  I don't have access to documents so take it as a
	rumor until someone confirms it.  Also, Rich Stevens' book assumed
	something on it (I'll check it later).
	We may want to follow them, or fix them.

itojun