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

From: Don Coolidge <[email-masked]>
Date: Tue, 17 Aug 1999 16:05:42 -0700 (PDT)

>Also, in section 11 the draft says:
>
>    In general, attempting to specify an IPv6-only option, such as the
>    Hop-by-Hop options, Destination options, or Routing header on an IPv6
>    socket that is using IPv4-mapped IPv6 addresses, will probably result
>    in an error.
>
>One interpretation of the text above would be that an implementation
>may silently ignore the option. I propose "will result in an error"
>instead of "will probably result in an error".

The text may read the way it does because there are v6 options like 
hoplimit and the Routing header that could potentially be meaningfully
mapped (sometimes with a bit of work) to corresponding v4 options (ttl
and source routing in these cases). My understanding is that there is 
still discussion in the WG as to whether or not this sort of thing 
should be permitted/forbidden/implementation-specific. To change 
the indicated text to "will result in an error" is to close off
that discussion by forbidding such potentially useful mappings.

I'm not implying that I feel one way or another about such cross-gender
mappings; I'm just saying that the indicated text shouldn't be considered 
for change until after the WG has dealt with the entire question of using 
options, either v4 or selected v6 ones, on sockets using mapped addresses.

-- Don Coolidge

--------------------------------------------------------------------
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: Bob Halley <[email-masked]>
Date: Tue, 17 Aug 1999 18:36:00 -0700

> that discussion by forbidding such potentially useful mappings.

My intent is not to forbid specific meaningful mappings, but to deal
with the general case where you are trying to do an operation that has
no meaningful translation back into IPv4.  In such cases, I would like
to forbid silent failure.

/Bob

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Aug 1999 23:00:31 -0700 (PDT)

> to forbid silent failure.

For setsockopt we can definitely forbid silently failures.
But when using ancillary data with sendmsg certain implementations
(that use asynch message passing to get to the TCP/IP stack - also
known as streams) can not return errors from the TCP/IP code to sendmsg.

I can at least clarify that the "may" only applies to sendmsg and not
to setsockopt.

   Erik