[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Mark.Andrews@isc.org
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>, itojun@iijlab.net, Bill Manning <bmanning@ISI.EDU>, dnsop@cafax.se
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Date: Wed, 19 Sep 2001 16:15:41 +0200 (CEST)
In-Reply-To: "Your message with ID" <200109191342.f8JDgir34253@drugs.dv.isc.org>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Sender: owner-dnsop@cafax.se
Subject: Re: operationally (if not yet WG) related


[I think we should move this to the ipng list.]

> 	Hiding the fact that it is a mapped address will just make
> 	it harder for developers to see that they are dealing with
> 	mapped address.  People generally print raw addresses for
> 	debugging / security reasons.  In both cases knowing that
> 	you are using mapped addresses is useful knowledge.

I understand that for debugging folks need to see the bits.
But I'm concerned about the textual mapped addresses appearing in
other unwanted places because the average ported application which
uses getnameinfo or inet_ntop will print mapped addresses with a leading 
"::ffff:".

So if we don't want the mapped literal addresses appear in application output
but we do want them to appear in debugging output the question is which
code we want to burden to do extra work.

Thus we have a choice between making the normal application printing
code look like
	if (IN6_IS_ADDR_V4MAPPED(...)) {
		struct in_addr ina;

		ina = sin6->...
		printf("Trying %s ...\n", inet_ntop(AF_INET, &ina, ...));
	} else {
		printf("Trying %s ...\n",
		 inet_ntop(AF_INET6,&sin6->sin6_addr...));
	}
or making the it just do
	printf("Trying %s ...\n", inet_ntop(AF_INET6,&sin6->sin6_addr...));

and have debugging code have to do the logical inverse as in
	if (IN6_IS_ADDR_V4MAPPED(...))
		prefix = "::ffff:";
	else
		prefix = "";
	printf("?? bad address %s%s\n", prefix, 
	    inet_ntop(AF_INET6,&sin6->sin6_addr...));

Or we could get the best of both worlds by 
1) recommending getnameinfo with the numeric flags instead of inet_ntop
2) making the default getnameinfo ommit the "::ffff:" for mapped address
3) adding a flag to getnameinfo to get the "debug" style output for mapped
   addresses.

> 	What we should be doing is making mapped address a more of
> 	a first class IPv6 address.  Taking each of the currently
> 	defined options and saying if they apply to mapped addresses
> 	or not and if so which option they map to in the IPv4 world.

While I agree that this would be ideal, I'm not certain we can get all
the implementations to do this.
But currently we don't even have a list of what it means to be a first class -
some recent experience with building Java IPv6 support indicates that
it isn't sufficient to handle IPv4-mapped address everywhere but that
one also has to handle ifindicies for IPv4-only interfaces in e.g.
IPV6_MULTICAST_IF and the like.

I think it would be a good idea for somebody to run down the list
of the IPv6 basic and advanced APIs and see what it would mean to
make IPv4-mapped addresses first class. The only thing I think can be
included up front is the SOCK_RAW related parts - raw socket applications
need to be aware whether they are sending and receiving IPv4 or IPv6 header
formats thus IPv4-mapped addresses don't buy much for such applications.

  Erik

> 	Things like in6_pktinfo are very useful when applied with
> 	mapped addresses.  Being able to send replies from the same
> 	address that the packet was sent to using one socket rather
> 	than hundreds or thousands of sockets which is what you
> 	have to do in the IPv4 world today.
> 
> 	As for the threat models when mapped addresses are sent
> 	over the wire.  Publish them so that they can be taken into
> 	account when the application is designed.  Provide switches
> 	like IPV6ONLY so that you can eliminate part of the threat.
> 
> 	Mark
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org



Home | Date list | Subject list