Re: Enhanced SIIT

[todd@fries.net]

Penned by Iljitsch van Beijnum on 20071018 15:22.42, we have:
> On 18-okt-2007, at 14:27, Todd T. Fries wrote:
>
>> The question I think is the wrong question.  I've read enough of the
>> discussion on this topic to realize the people discussing it here presume
>> that stateless communication between IPv4 and IPv6 is some holy grail that
>> must be achieved at all costs.
>
> It's not so much the statelessness that's important, but the ability for 
> people to go ahead with IPv6 and reduce their IPv4 footprint *now* rather 
> than more or less be forced to wait until everyone else is dual stack. The 
> problem with dual stack is that it provides no compelling benefits: you get 
> all the complexity that's in IPv4, all the complexity that's in IPv6, and 
> any complexity arising from their interaction to boot.

I use the following every hour of my business operation:

 - afs
 - dns
 - http
 - smtp
 - imap
 - ssh
 - ipsec

Of these, I use all but the first with v6 where I can, and v4 where I can't.

afs has no IPv6 roadmap to my understanding.

I have a pda that I `did not realize' for several months that it had no v4
connectivity to the outside world simply because I did not use it .. I only
used a local v4 link to get to my afs server.

The compelling benefit to me is that I can access any system w/out port
forwarding or NAT in the v6 case.  If not, I can fall back to v4 if I have
to.

Irregardless of the mechanism, to access IPv4 networks from an IPv6 only
network, there must be an IPv4 host doing some sort of proxying or translation,
in that I am sure we can agree.  Whether you consider this a router or a
firewall or a proxy or something else, the name is the only thing changing
here, the underlying concept does not change this.

>> However, any stateless transition mechanism is going to be as harmful as
>> IPv4 mapped IPv6 addressing given that you add an entire complex case to
>> firewalls and any security issues you wish to address.
>
> Unfortunately, firewalls are used in such an abundant variety of harmful 
> ways, that there is no reasonable way to accommodate their use in most IETF 
> work. People shouldn't depend on firewalls as crutches that let them keep 
> doing things that they shouldn't be doing.

I love this.  This specifically states that NAT should never have gone through
IETF, in my understanding.

>> To answer your other statement, I cannot see how you call the IPv6 api
>> something to transition to and once transitioned to, you cannot use
>> the IPv4 API.
>
> I'm not saying you can't, I'm saying it doesn't make sense to use different 
> code paths for IPv4 and IPv6.

In applications, I wholeheartedly agree.  Proper coding ensures utilizing
IPv4 or IPv6 whichever is available, applications should never care unless
they specifically have to record or deal with addresses in some manner.

>> There are some new standard functions, getaddrinfo() for example, that
>> support both protocols.  If you write your code properly, you need not
>> care which protocol you are talking to.
>
> Right. That's exactly what I'm saying. But the OpenBSD people didn't want 
> that, and made sure their kernel would only allow the IPv6 API to generate 
> IPv6 packets. Fortunately, this is something that's no longer a system-wide 
> setting these days (well, unless you use Windows XP, where v4 and v6 are 
> separate protocols that shall never meet in an API) but something that 
> applications can control.
>
> [...]

Um, I think you misunderstand.  I am an `OpenBSD' person, for whatever it
is worth.

For an application (client) you can code like this (good for the eye, not
guaranteed to compile):

int
connect_func(char *host, char *port)
{
	struct addrinfo hints, *ai, *aitop;
	int err, net;
	char strport[NI_MAXSERV];

	memset(&hints, 0, sizeof(hints));
	hints.ai_family = AF_UNSPEC;
	snprintf(strport, sizeof strport, "%u", port);
	if ((err = getaddrinfo(host, strport, &hints, &aitop)) != 0)
		fatal("%s: %s port %s", __progname, host, port, strerror(err));

	for (ai = aitop; ai; ai = ai->ai_next) {
		if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6)
			continue;
		if (getnameinfo(ai->ai_addr, ai->ai_addrlen,
		    ntop, sizeof(ntop), strport, sizeof(strport),
		    NI_NUMERICHOST|NI_NUMERICSERV) != 0) {
			error("getnameinfo failed");
			continue;
		}

		net = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
		if (net < 0)
			continue;

		if (connect(net, ai->ai_addr, ai->ai_addrlen) < 0) {
			close(net)
			continue;
		}
		break;
	}
	freeaddrinfo(aitop);
	return net;
}

Why do you have to insist the api is separate?  It looks pretty uniformly
integrated to me.

If you insist that it seems odd to have a server bind to a different address
familiy as a separate socket, well, that's a different discussion.  That
much is quite clear from the references you removed from my last email.

>> So there is infrastructure in place that is transitioning to IPv6 as we 
>> speak.
>
> On the other hand, none of the big content sites uses IPv6, very few 
> end-user ISPs offer IPv6 and none of the common CPEs support IPv6. The same 
> thing was true several years ago, but we are now making way more progress 
> using up the remaining IPv4 space than adding IPv6 in these three areas.

And why is it a bad thing to let the IPv4 space pressure convince the end-user
ISP's and CPE's from supporting IPv6?  Not that it should be the only means
of coersion, mind you .. ;-)

>> The biggest holdup in the IPv6 transition in my humble opinion is the lack
>> of having IPv6 root dns servers in the advertised/example 
>> root.cache/root.hints
>> file.
>
> Huh? Not to say that I'm happy with the glacial progress in that area, but 
> how exactly would that help? Yes, with IPv6 root servers it's possible for 
> a system that runs IPv6-only to reach another IPv6 system without touching 
> any IPv4 infrastructure if all the DNS servers in the delegation chain also 
> support IPv6, but the problem is that you can't run IPv6-only anyway 
> because then you don't have access to the top 100 web sites, any of the 
> large IM networks, etc.

How exactly it would help is because today unless I go hunt out (and anybody
else, for that matter) the actual IPv6 address of root nameservers, and then
add that to the hints file directly, I have an IPv6 capable name server that
only queries 2nd level name servers, not root servers, via IPv6.

If I want to run a nameserver on an IPv6 only network, I have to use a dual
stack fowarder or find one of the IPv6 only root servers my self.

If one wishes to boot strapping IPv6 islands into using IPv6 only, then I
believe that providing at least the core protocol (dns) for the internet for
IPv6 without relying on IPv4 root name servers by default, both as advertised
in the root.hints/root.cache file and in the default distribution of dns
server software.

Yes, there are many other places that rely on IPv4, but root dns server IPv6
address is not something we can control in the IPv6 islands.

Thanks,
-- 
Todd Fries .. todd@fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt