Re: [v6ops] Please review the No IPv4 draft

[Simon Perreault <[e-mail]>]

Le 2014-04-14 16:21, Ray Hunter a écrit :
> That we are discussing turning off IPv4 in both RA and DHCPv6 just
> highlights to me how ridiculous host configuration has become.
> 
> To me this proposal just introduces all sorts of horrible race
> conditions and inconsistencies, and I'm not convinced it's any better
> than just configuring up IPv4 via DHCPv4 with either a self assigned
> address or an RFC 1918 address and saying nothing about remote
> connectivity (given that most OSes already have IPv4 detection
> mechanisms in place to work out whether they are on a corporate network
> with proxies or the Internet or on an isolated island or whatever.)
> 
> e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies
> either before or after a host receives that RA advertisement?
> Does the host have to then disable IPv4 once it is already up? For how
> long?

Yes. Forever. This is in our draft.

If IPv4 is already up, then there is a problem with your network's
configuration. If you're saying over IPv4 that there is no IPv4 service,
but on the other hand you *are* in fact providing IPv4 service, there's
a contradiction somewhere. So in fact what would happen is the host
would abort an unresponsive IPv4 provisioning process.

> What if DHCPv6 and RA are not consistent (given they may not even be the
> same router or device responding)?

Then you have a network configuration consistency problem. We have the
same issue whenever we define similar options in DHCPv6 and RA. Take for
example DNS resolver provisioning, which is IMHO worse because we're not
even talking about conflicting binary options, but list-values options
that need to be merged somehow.

This is not germane to the No-IPv4 problem. I wouldn't mind removing
either the DHCPv6 or RA option if provisioning consistency proves to be
an issue that people care about.

> What if one router is IPv4 only and the other IPv6 only? And they're
> from 2 different ISP providers connected to a common L2 LAN? That's a
> perfectly valid configuration in my opinion.

Absolutely. This is why we define how this option works in
multiple-interfaces scenarios. This is all in the draft.

> Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"?

No. It's an absence of information, period.

> How would this be implemented consistently given RA is generally ICMP
> (kernel space) and DHCPv6 user space (daemon)?

I would make it all percolate all the way up to the controlling glue
code (e.g., NetworkManager or init scripts).

> Given the O and M bit saga, what makes anyone think that this additional
> signalling will be any better?

Because it helps fix real problems we're having today, and it helps
people move to IPv6-only networks.

> Why would any end host trust this message?

Why would any end host trust anything received over DHCP or RA? This
issue is not germane to the No IPv4 problem.

> IMHO the place to turn off or signal limited IPv4 connectivity is in
> DHCPv4 (if we ever even attempt to do that). 

Why?

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