Subject: [sunset4] question about problem 7 of draft-dionne-sunset4-v4gapanalysis-00

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 23:29:20 -0400

>   PROBLEM 7:  Completely disabling IPv4 at runtime often reveals
>               implementation bugs.  Hard-coded dependencies on IPv4
>               abound, such as on the 127.0.0.1 address assigned to the
>              loopback interface.  It is therefore often operationally
>              impossible to completely disable IPv4 on individual
>              nodes.

given that lo0/127.0.0.1 data never leaves the host, it's pretty much of
of scope for the IETF.  Further, if we agree that one turns off IPv4 on
a per-interface basis, then whether or not lo0 has IPv4 on or off isn't
relevant to the external world.

While I think that trying to build operating systems without IPv4 (and
reporting any code savings) is a useful thing to do, I think it's out of
scope.  If 127.0.0.1 turns out to be hard coded somewhere *in a
protocol*, that would be important to know.

(As an aside a debian VM template that I've used way too much was
missing turning on lo0. It mostly worked. NFS failed, and a few other
things would fail, but surprising little, cause it would take me months
to notice..)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Simon Perreault <[email-masked]>
Date: Mon, 30 Jul 2012 22:38:56 -0700

Le 2012-07-30 20:29, Michael Richardson a écrit :
> of scope for the IETF.

If people want to turn off IPv4 on lo0, and they're unable to, then it's 
in scope for the IETF. The IETF created IPv4. We can at least 
acknowledge and document the problem. Maybe we can even do something 
about it, but I'm not too sure what at this point. Making it easier for 
people to disable it, even if it's on lo0, is very much IETF's burden.

> Further, if we agree that one turns off IPv4 on

True.

Note that we're not saying that people SHOULD turn off lo0. We're only 
saying that when people want to do that, they're hitting a wall. That's 
a real problem with a protocol that the IETF created. It may only be due 
to implementations. But it's still a real problem. Can we do something 
about it? I don't know yet. But there are people working on it.

> things would fail, but surprising little, cause it would take me months

Super cool! :)

One thing I immediately noticed when I removed 127.0.0.1 on Fedora 17 
was that virtualization didn't work anymore. It turns out that libvirtd 
binds to 127.0.0.1 and I haven't found a way to change that. So when I 
need a VM I have to "ip addr add 127.0.0.1/8 dev lo" by hand...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca