Re: [homenet] Please review the No IPv4 draft
In your letter dated Wed, 16 Apr 2014 09:07:46 -0400 you wrote: Philip Homburg pch-homene...@u-1.phicoh.com wrote: Does that include all edge cases and the user interface? I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 to be shutdown. Do you just shutdown IPv4? Does your code parse the output of ifconfig to figure out if the interface was configured? No, and no. The order is not to shutdown v4. The suggestion is to stop DHCPv4, if it hasn't succeeded, and assume that there isn't any IPv4 for any downstream devices. (This was in the context of FreeBSD.) One option: the DHCPv4 client has an option to shutdown unless it already obtained a lease. Probably requires allocating a signal, changes to the DHCPv4 client, etc. Otherwise, what happens if you kill a DHCPv4 client when it has a lease? - A hard kill (-9) and the address remains installed even when the lease expires. Not good. - (Unlikely) A hard kill and the kernel knows about the lifetime of the lease and deletes the address when it expires. This one would be really great to debug. Send one 'ipv4begone' packet and hour later the admin goes crazy. - A soft kill (say TERM) and DHCPv4 removes the address before shutting down. Nice immediate DoS on IPv4. Alternative, ifconfig $interface | grep 'inet '... Ugly. And unless all of this is spelled out in the RFC in extreme detail, I can already see the presentations in a couple of years: we sent one 'ipv4begone' packet and this is the kind of fireworks you get in the various operating systems. Somebody might just go ahead and implement 'grep option no-ipv4 /var/db/dhclient6.leases.eth0 pkill dhclient' ... ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
Le 2014-04-16 09:07, Michael Richardson a écrit : Ideally the device will not announce an IPv4 default route if it hasn't got one itself. The fact is that all CPE routers today do announce an IPv4 default route to the LAN irrespective of their WAN connectivity status. And there's no reason to think that this will ever change. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On 4/16/14, 6:40 AM, Simon Perreault wrote: Le 2014-04-16 09:07, Michael Richardson a écrit : Ideally the device will not announce an IPv4 default route if it hasn't got one itself. The fact is that all CPE routers today do announce an IPv4 default route to the LAN irrespective of their WAN connectivity status. And there's no reason to think that this will ever change. ipv4 cpe using rfc 1497/2132 option 3 are not announcing a default route, they are indicating that they are a router, the client installs the default route. Simon signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
On Apr 16, 2014, at 9:52 AM, Lorenzo Colitti lore...@google.com wrote: Not Android. I thought Android used dnsmasq. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
slowly I've gotten to understand the numerous layer-2 and layer-3 savings by not having to have the whole DHCPv4 relay and broadcast processing occuring. Could you please explain that? let me see what I recall... That's interesting, especially the FTTH case. Thanks for the info. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Please review the No IPv4 draft
I've not had time to review the whole thread, so apologies if this has been covered elsewhere. It occurs to me that one scenario that needs to considered is when a machine moves from a network which wants to suppress IPv4 to one which is still providing IPv4 (possibly only IPV4). To make that work implies that the DHCPv4 client should still exist in the IPv4-suppressed state, doing nothing except looking for loss of ethernet carrier or change of wireless ESSID, at which time is should try again to get a DHCPv4 lease. However this is implemented, just killing the DHCP client is not going to cut it. My personal feeling is that suppressing IPv4 should be a a DHCPv4 function, that keeps the go-into-hibernation transition solely in the DHCPv4 code, it also means the when IPv4 support finally goes, so does the transition mechanism. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
