Subject: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses

From: Bob Halley <[email-masked]>
Date: Tue, 17 Aug 1999 15:25:49 -0700

BIND is one of the applications that would like to use the
IPV6_PKTINFO option.

It would be great if BIND could simply create a single IPv6 UDP socket
with a wildcard address and use it for both IPv4 and IPv6 requests,
but in draft-ietf-ipngwg-2292bis-00.txt, section 11, it says

    [...]  Some implementations, however, may provide access to
    the packet information (source/destination address, send/receive
    interface, and hop limit) on an IPv6 socket that is using IPv4-mapped
    IPv6 addresses.

So, I cannot rely on using IPV6_PKTINFO for IPv4-mapped IPv6 addresses.

Using a single socket both both v4 and v6 is tempting because:

    Only one fd is used.

    Interface scanning is not required.  This has a security benefit,
    since after we bind() to port 53, we can drop privileges and
    still handle subsequent interface additions.

Having IPv6 packet info for IPv4-mapped addresses is also desirable
because we get interface information.  The current method of binding a
socket to each interface address ensures that responses we send will
have a source address which is the same as the destination address the
client used, but we do not know from which interface the packet was
actually received, nor which interface the system will use when we
send our response.

I propose that either:

    Support of IPV6_PKTINFO for IPv4-mapped IPv6 addresses be made
    mandatory

or

    Applications be given an easy way of determining (at compile time or
    run time) whether a given implementation supports IPV6_PKTINFO for
    IPv4-mapped IPv6 addresses

I prefer the former, but realize that it may be too much of a burden to
make mandatory.  If support is not going to be mandatory, we need a
definite way of knowing whether support is available.

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".

/Bob
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Wed, 18 Aug 1999 16:47:53 +0200

In your previous mail you wrote:

=> I agree! Interface scanning is *not* the best way to get the
source info.

   I propose that either:

=> we have it (because we'd like to use it for BIND) then I support
this proposal.

=> propose a name for the define (better than IPV6_INRIA_VERSION :-)

=> I agree (we return ENOPROTOOPT aka "Protocol not available" in such cases).

[email-masked]

---

From: [email-masked]
Date: Thu, 19 Aug 1999 19:40:03 +0900

>So, I cannot rely on using IPV6_PKTINFO for IPv4-mapped IPv6 addresses.

	I would say that this is too much to ask.
	If you need complex operation like IPV6_PKTINFO, expect that to work
	on IPv6 connection toward AF_INET6 socket, no others.  There are
	too many complexities introduced by IPv4 mapped address, and I hate
	to see any additional complexities to be added.

	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).
	There are too many interactions between two AFs introduced by
	IPv4 mapped address.  I do not think it to be healthy.

	I understand IPv4 mapped address (::ffff:10.1.1.1) as a way to ease
	porting of simple AF_INET applications (which listens to only single
	socket) into AF_INET6 application, while continue support for IPv4
	connection on top of AF_INET6 socket.
	The way IPv4 mapped address is defined is not future-proven.
	When the next version of internet protocol - say IPv9 - is introduced
	you will need to port your aplication again.

	IMHO the way for new code to go is to
	- avoid in_addr, in6_addr and other protocol specific data structure
	- avoid gethostbyname2(), getipnodebyname() and other functions that
	  return protocol specific data struture
	- use sockaddr_storage, sockaddr * and get{addr}info() throughout
	  the code
	I always suggest userland programmers to handle AF_INET and
	AF_INET6 as totally separated address families.  things go much
	simpler if you do so (you will have no problem with these
	bind(2) ordeirng issues, port number space issues, and such).
	I have tutorial material on this aspect so feel free to take a look
	at.  I'm happy to give talks on this on any occasions, so just
	contact me.
	http://playground.iijlab.net/newsletter/19990630/

itojun

---

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

>     IPv4-mapped IPv6 addresses

Do you care about the ifindex or just the ability to get the destination
address (in recvmsg) and being able to set the source address per packet
in sendmsg?

The reason I ask is because in our implementation it would be relatively
easy to add the ipi6_addr part of IPV6_PKTINFO for IPv4-mapped addresses
but more difficult to handle the ipi6_ifindex.

Basically this would do the same as using IP_RECVDSTADDR for receive 
and some yet to be defined ancillary data option (IP_SRCADDR???) for send.

   Erik

---

From: Bob Halley <[email-masked]>
Date: Fri, 20 Aug 1999 13:21:05 -0700

> address (in recvmsg) and being able to set the source address per packet

Getting the destination address (and setting the source address in
replies) is interesting because it allows me to use one UDP socket
instead of having to have one for each interface address.

Being able to use ifindex is also interesting, although less so.  I
could use it to select how the server would behave, for example
treating requests that came from an interface on an internal network
differently from those which came from an external interface.

> but more difficult to handle the ipi6_ifindex.

I can certainly understand that.  Still, I'd rather see no
IPV6_PKTINFO for mapped addresses than different levels of
implementation which varied by vendor.

From my application developer's point of view, the attractiveness of
IPv4-mapped IPv6 addresses is living in the V6 world, and using the V6
APIs to get additional functionality.  If mapped addresses are not
"first class" objects, but are subject to many restrictions and
caveats (other than those where there is no meaningful V4 equivalent),
it's going to be easier if I just keep V4 and V6 separate.

/Bob