[Redbrick-ipv6] Re: [Admin-discuss] RedBrick IPv6 Network

Colm MacCarthaigh colmmacc at redbrick.dcu.ie
Fri Dec 19 00:05:34 GMT 2003


On Thu, Dec 18, 2003 at 11:40:37PM +0000, Philip Reynolds wrote:
> > On non KAME (basically BSD's) it does, due to a lack of
> > the IPV6_V6ONLY socket option. This has been fixed in kernel
> > since 2.4.20, but the system headers don't define it, so
> > we'd need to patch the system headers and then recompile
> > ssh :/
> 
> Ahh, that explains what I'm seeing so (on FreeBSD boxes).

It basically boils down to the OpenSSH team deciding to single-handledly
deprecate RFC3493 and RFC3542,  *sigh*

I've attachted the mail exchange (mbox format) between myself and Theo
about it all from a while back. There doesnt seem much hope of them
budging on the issue. *shrug*, I half agree with them - mapped addresses
are hassle, but deliberately ignoring current standards is taking it
a bit too far.

-- 
colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/ 
-------------- next part --------------
>From colmmacc at redbrick.dcu.ie Wed Oct 29 17:01:47 2003
Date: Wed, 29 Oct 2003 17:01:47 +0000
From: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
To: itojun at iijlab.net
Cc: bugtraq at securityfocus.com
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI
Message-ID: <20031029170147.GA8692 at carbon.redbrick.dcu.ie>
References: <20031029055821.494DF13 at coconut.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <20031029055821.494DF13 at coconut.itojun.org>
User-Agent: Mutt/1.3.28i
Status: RO
Content-Length: 2607

On Wed, Oct 29, 2003 at 02:58:21PM +0900, itojun at iijlab.net wrote:
> 	solution: do not accept IPv4 traffic by using AF_INET6 socket.  use
> 	AF_INET socket (http server should listen to AF_INET and AF_INET6
> 	socket explicitly).

This has been debated here before, however it is worth noting that 
this is not nearly as straight-forward a solution as you suggest. Some 
platforms do not allow this behaviour (Linux and Tru64 come to mind),
and indeed there are other valid reasons not to use AF_INET6
sockets explicitly.

Consider the logic required to listen on a port using explicit
family sockets in a manner an administrator can cope with;

   1.  Call getaddrinfo with PF_UNSPEC and AI_PASSIVE, get :: and
       0.0.0.0 back in that order.
   2.  Try to create a socket on ::, don't scream too loudly if it
       doesn't work.
   3.  Try to set it to IPv6 only, don't scream too loudly if it doesn't
       work
   4.  Try to bind() and listen() to it, don't scream too loudly if it
       doesn't work.
   5.  If 2 and 4 were successful, but 3 wasn't; Don't even try to listen
       on 0.0.0.0.
   6.  Otherwise try to listen on 0.0.0.0 and bomb out on error.

Now consider the logic required if you allow the use of mapped 
addresses;

   1. Call getaddrinfo with PF_UNSPEC and AI_PASSIVE, get ::
      and 0.0.0.0 back in that order.
   2. Try to bind to the first one that works.

It must be noted that this approach is generally simpler (and to my mind,
less error-prone), portable (certainly within *nix, though not win32)
and AF forwards-compatible. 

Allthough a much weaker argument, some would point out that an additional
socket to listen on can have a performance effect, particularly on
select/poll based implementations. To be honest, I doubt this is a
sigificant factor, but some feel differently and it is worth noting.

Whilst I agree that the world would certainly be simpler without
mapped address, and that it may be appropriate to describe them
as harmful, they do exist and are inescaple in terms of practical
programming.

Since mapped addresses are a fact of life and must be handled for
applications to be considered portable, it is better to handle them more
considerately than not at all. Explicitly checking for mapped-addresses
and rendering them available in a suitable manner is not hard.

For the record, Apache's httpd renders mapped addresses available in
such a manner, and does not exhibit the problem you describe.

-- 
colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/ 

>From deraadt at cvs.openbsd.org Wed Oct 29 17:27:12 2003
Return-path: <deraadt at cvs.openbsd.org>
Envelope-to: colmmacc at redbrick.dcu.ie
Delivery-date: Wed, 29 Oct 2003 17:27:13 +0000
Received: from cvs.openbsd.org ([199.185.137.3])
	by prodigy.redbrick.dcu.ie with esmtp (Exim 4.23)
	id 1AEu6C-0006tF-Ku
	for colmmacc at redbrick.dcu.ie; Wed, 29 Oct 2003 17:27:12 +0000
Received: from cvs.openbsd.org (localhost [127.0.0.1])
	by cvs.openbsd.org (8.12.10/8.12.1) with ESMTP id h9THRSR1032223
	for <colmmacc at redbrick.dcu.ie>; Wed, 29 Oct 2003 10:27:28 -0700 (MST)
Message-Id: <200310291727.h9THRSR1032223 at cvs.openbsd.org>
To: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI 
In-reply-to: Your message of "Wed, 29 Oct 2003 17:01:47 GMT."
             <20031029170147.GA8692 at carbon.redbrick.dcu.ie> 
Date: Wed, 29 Oct 2003 10:27:28 -0700
From: Theo de Raadt <deraadt at cvs.openbsd.org>
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on prodigy
Status: RO
X-Status: A
Content-Length: 161

You are wrong.

mapped addresses are always going to be dangerous.

They are "automatic tunnels".

I'm going to petition for IPX built into V6.

What the fuck.


>From colmmacc at redbrick.dcu.ie Wed Oct 29 17:41:52 2003
Date: Wed, 29 Oct 2003 17:41:52 +0000
From: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
To: Theo de Raadt <deraadt at cvs.openbsd.org>
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI
Message-ID: <20031029174152.GA25679 at carbon.redbrick.dcu.ie>
References: <20031029170147.GA8692 at carbon.redbrick.dcu.ie> <200310291727.h9THRSR1032223 at cvs.openbsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <200310291727.h9THRSR1032223 at cvs.openbsd.org>
User-Agent: Mutt/1.3.28i
Status: RO
Content-Length: 925

On Wed, Oct 29, 2003 at 10:27:28AM -0700, Theo de Raadt wrote:
> You are wrong.
> 
> mapped addresses are always going to be dangerous.

I agree, but believe that since we currently have no choice but to deal
with them, that it is better to deal with them properly than not at all.

Right now, more is served by making people aware of the problems and
how to fix them, whilst maintaining portability, than merely refusing
to deal with mapped-addresses.

Vendors and developers certainly need to be pressured into providing
IPV6_V6ONLY, and that's happening; but in the meantime merely saying
"use AF_INET and AF_INET6 explicitly" doesn't serve much purpose, since
it won't work on doesn't widely-deployed platforms and leads to
even worse code as people try to work around this.

-- 
colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/ 

>From deraadt at cvs.openbsd.org Wed Oct 29 17:45:50 2003
Return-path: <deraadt at cvs.openbsd.org>
Envelope-to: colmmacc at redbrick.dcu.ie
Delivery-date: Wed, 29 Oct 2003 17:45:50 +0000
Received: from cvs.openbsd.org ([199.185.137.3])
	by prodigy.redbrick.dcu.ie with esmtp (Exim 4.23)
	id 1AEuOE-0007Dm-99
	for colmmacc at redbrick.dcu.ie; Wed, 29 Oct 2003 17:45:50 +0000
Received: from cvs.openbsd.org (localhost [127.0.0.1])
	by cvs.openbsd.org (8.12.10/8.12.1) with ESMTP id h9THkSR1015384
	for <colmmacc at redbrick.dcu.ie>; Wed, 29 Oct 2003 10:46:28 -0700 (MST)
Message-Id: <200310291746.h9THkSR1015384 at cvs.openbsd.org>
To: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI 
In-reply-to: Your message of "Wed, 29 Oct 2003 17:41:52 GMT."
             <20031029174152.GA25679 at carbon.redbrick.dcu.ie> 
Date: Wed, 29 Oct 2003 10:46:28 -0700
From: Theo de Raadt <deraadt at cvs.openbsd.org>
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on prodigy
Status: RO
X-Status: A
Content-Length: 963
Lines: 29

> Right now, more is served by making people aware of the problems and
> how to fix them, whilst maintaining portability, than merely refusing
> to deal with mapped-addresses.

What the fuck?

You don't KNOW how to deal with them!

How do you filter them?  Have you ever sat down and tried to write
packet filters which deal with this?

It's *impossible*!

Please pay attention to my credentials.  itojun and I both are very
sure that it is *impossible* for application authors to cope with this,
let alone network admins!

> Vendors and developers certainly need to be pressured into providing
> IPV6_V6ONLY, and that's happening; but in the meantime merely saying
> "use AF_INET and AF_INET6 explicitly" doesn't serve much purpose, since
> it won't work on doesn't widely-deployed platforms and leads to
> even worse code as people try to work around this.

Bullshit.

You think we give people crap first then later we can fix it?

How fucking deluded of you.


>From colmmacc at redbrick.dcu.ie Wed Oct 29 18:13:33 2003
Date: Wed, 29 Oct 2003 18:13:33 +0000
From: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
To: Theo de Raadt <deraadt at cvs.openbsd.org>
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI
Message-ID: <20031029181333.GA29431 at carbon.redbrick.dcu.ie>
References: <20031029174152.GA25679 at carbon.redbrick.dcu.ie> <200310291746.h9THkSR1015384 at cvs.openbsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <200310291746.h9THkSR1015384 at cvs.openbsd.org>
User-Agent: Mutt/1.3.28i
Status: RO
Content-Length: 4038

On Wed, Oct 29, 2003 at 10:46:28AM -0700, Theo de Raadt wrote:
> > Right now, more is served by making people aware of the problems and
> > how to fix them, whilst maintaining portability, than merely refusing
> > to deal with mapped-addresses.
> 
> What the fuck?
> 
> You don't KNOW how to deal with them!

Well, I've written the (well actually rewritten itojun's) v6 code for NSD, 
some of the v6 code for Apache, have an AF-agnostic ACL implementation 
I've written for arbitrary use, am a network engineer for a production 
150,000 user national IPv6 network and maintain a lot of production v6 
boxen, I'm cetainly familiar in dealing with them. 

> How do you filter them?  Have you ever sat down and tried to write
> packet filters which deal with this?

Yes, I have. And yes, it's pretty damn ugly, and infeasible for
decent use. My approach for an ACL implementation (which whilst a layer 
removed, shares some of the problems) was to compile all subnet 
reprentations into 128bits, any v4 rulesets are converted into mapped 
format during compilation. 

During testing, the macros which handle v4 (mapped or otherwise)
would only care about the 4th set of 32-bits. If a 128-bit comparison
is somehow triggered, then we'll match that too. It's not efficient,
it's not nice, but it works.

I'm aware of the problems associated with packet filters, and don't
quote this example as some kind of statement that is applicable to
packet filters. I'm merely trying to convey that yes, I do actually
know about these problems, deal with them on a regular basis and
hate them >:

> It's *impossible*!
> 
> Please pay attention to my credentials.  itojun and I both are very
> sure that it is *impossible* for application authors to cope with this,
> let alone network admins!

I'm well aware of both of your credentials. I'm (possibly!) known to 
Itojun, and  have contributed to his excellent document at 
http://www.kame.net/newsletter/19980604/, with some of these experiences, 
and have also directly worked on Itojun's code (in the example of NSD) to 
get portability. But I am also fully aware of the portability problems 
associated with the suggested approach.

It simply doesn't work yet. It's a good suggestion, but it's premature.
For any currently in-use application which needs portability, mapped
address *will have* to be considered. So it is right and proper
that they be handled correctly, rather than ignored!

> > Vendors and developers certainly need to be pressured into providing
> > IPV6_V6ONLY, and that's happening; but in the meantime merely saying
> > "use AF_INET and AF_INET6 explicitly" doesn't serve much purpose, since
> > it won't work on doesn't widely-deployed platforms and leads to
> > even worse code as people try to work around this.
> 
> Bullshit.

Not at all, and if you require a concrete example checkout a copy
of server/listen.c from Apache's httpd-2.1 (HEAD) tree. Take a look
at the munging I had to perform on ap_listen_open after the rewrite
Justin Erenkrantz did (which was inlinde with the AF_INET,AF_INET6
recommendations).

> You think we give people crap first then later we can fix it?

No, but I do find it non-sensical that the excellent recommendation
in the internet draft:

 "In EVERY application, check for IPv4-mapped addresses wherever
  addresses enter code paths under your control (i.e., are returned from
  system calls, or from library calls, or are input from the user or a
  file), and handle them in an appropriate manner.  This approach is
  difficult in reality, and there is no way to determine whether it has
  been followed fully."

is not given greater parity with the suggestion of using
AF_INET/AF_INET6. To application programmers (as opposed to kernel
developers), the former is (in my opinion) more useful advise,
since the use of mapped addresses can not currently be avoided
on widely-deployed platforms. 

-- 
colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/ 

>From colmmacc at redbrick.dcu.ie Wed Oct 29 19:19:56 2003
Date: Wed, 29 Oct 2003 19:19:56 +0000
From: Colm MacCarthaigh <colmmacc at redbrick.dcu.ie>
To: der Mouse <mouse at Rodents.Montreal.QC.CA>
Cc: bugtraq at securityfocus.com
Subject: Re: possible issue with IPv4 mapped address and $REMOTE_ADDR in CGI
Message-ID: <20031029191956.GA31601 at carbon.redbrick.dcu.ie>
References: <20031029055821.494DF13 at coconut.itojun.org> <20031029170147.GA8692 at carbon.redbrick.dcu.ie> <200310291814.NAA18908 at Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <200310291814.NAA18908 at Sparkle.Rodents.Montreal.QC.CA>
User-Agent: Mutt/1.3.28i
Status: RO
Content-Length: 1350

On Wed, Oct 29, 2003 at 01:06:55PM -0500, der Mouse wrote:
> Also, note that the application can get whichever set of semantics it
> prefers by explicitly setting the V6ONLY option on the socket; 

My main point is that this is not the case. The V6ONLY socket option
is not honoured by some widely-deployed Operating Systems.

Although the situation is rapidly improving, I would argue that
it is currently still worth accompanying a recommendation of using
explicit AF sockets with the excellent recommendation from section
4 of the I-D;

 "In EVERY application, check for IPv4-mapped addresses wherever
  addresses enter code paths under your control (i.e., are returned from
  system calls, or from library calls, or are input from the user or a
  file), and handle them in an appropriate manner.  This approach is
  difficult in reality, and there is no way to determine whether it has
  been followed fully."

Proposing "do not accept IPv4 traffic by using AF_INET6 socket" without
even a "where available" qualifier as a solution is unsuitable and
unrealistic. It is a simple fact of life that current application
developers have to live with the fact that some OS's do not support
this behaviour.

-- 
colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie  
Web:                                 http://devnull.redbrick.dcu.ie/ 


More information about the Redbrick-ipv6 mailing list