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


To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Cc: itojun@iijlab.net, Bill Manning <bmanning@ISI.EDU>, dnsop@cafax.se
From: Mark.Andrews@isc.org
Date: Wed, 19 Sep 2001 23:42:44 +1000
In-reply-to: Your message of "Wed, 19 Sep 2001 14:02:10 +0200." <Roam.SIMC.2.0.6.1000900930.441.nordmark@bebop.france>
Sender: owner-dnsop@cafax.se
Subject: Re: operationally (if not yet WG) related


> > 
> > >>"We recommend DNS administrators DO NOT use mapped IPv6 addresses with
> > >>opcode 28 <type AAAA> resource records in ANY zone file."
> > >
> > >	I agree 120%.
> 
> I also agree with Bill's suggestion for DNS operation.
> 
> > 	more words:
> > 	from what RFC2553 3.7 says, IPv4 mapped addresses are not supposed to
> > 	appear on the wire.  they are OS-internal representation of IPv4 peers
> > 	on top of AF_INET6 socket.  they are not supposed to appear in the wild
> > 	like AAAA records.
> 
> I think it would make sense to figure out whether it makes sense to
> extend the restriction on the IPv4-mapped address format to other places
> where it would appear in essentially textual form.
> 
> While IPv4-mapped addresses are quite useful in the API I have not seen
> any need to have them appear in textual format e.g. in configuration files.
> Thus instead of having configuration files (or other textual literal addresse
> s)
> use ::ffff:a.b.c.d they should just use a.b.c.d.
> 
> It makes sense discussing the general (non-DNS specific) issue in ipng.
> For example, I can envision getting implementors modify 
> getnameinfo and inet_ntop to always present an IPv4-mapped address
> as the IPv4 address i.e. without the leading "::ffff:" text.
> That would help prevent these addresses appearing in undesired places
> in the future.
> (Of course, one could also entertain having getaddrinfo/inet_pton refuse
> to *parse* such addresses but that might be more difficult to introduce
> immediately.)

	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.

>   Erik

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