On 2011-05-31, at 14:01 , Philip Homburg wrote: > I would say that having an interface with two IPv4 addresses is not really in > the model.
Maybe it is rather uncommon, but it is allowed and also supported by all major operating systems; just wanted to point that out. > But SHOULD is a bit tricky in that context. If you assume that statefull > DHCPv6 is expensive (compare to SLAAC) and you want to support extremely > minimal devices, then SHOULD may just be a bit too strong. Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic device with IPv4 support I know of has DHCPv4 support; however, you might be referring to devices even more minimalistic than what I have in mind. I just would like to point out, that I already wrote a DHCPv4 client myself (for a software project) - not fully featured, it only cares for an IP address, a subnet mask, DNS servers, DNS domain and the lease time, all other options are pretty much ignored - and I was surprised how little code I needed for that. It is pretty robust and so far worked well with every DHCP server we ever found. It even supports renewing the lease, though it does not fully implement the state-flow of the RFC (which seems over complicated IMHO). So a device that is not able to run such a simple client must be really, very, very minimalistic and my impression is that DHCPv6 is much simpler than DHCPv4, since it is not an extension to BOOTP (which makes DHCPv4 harder to implement than would otherwise be necessary). > I'm not sure that a bit that distinguishes manual configuration from DHCP is > a good thing. SLAAC with EUID already has its bit. I'm not advocating to make DHCP and manual configuration distinguishable, but to make SLAAC with Priv Ext distinguishable of DHCP and manual addresses: Manual (Static) Address: U = 0, A = 0 DHCP Address: U = 0, A = 0 SLAAC: U = 1, A = 1 SLAAC + Priv Ext: U = 0, A = 1 > So the only thing that remains is how much faith you have in a random number > generator. I think it is no problem, but we have to wait for large scale > deployment to see if that is justified. As a programmer, I don't believe in randomness but in predictability. You don't write code that will only crash in one out of hundred billion cases if you can write code that will never crash for sure - even if the first case is so unlikely, that you may never see the code crash in your whole life. However, we are losing the point here: With IPv6 I just fail to see the argument SLAAC vs DHCPv6, since there is no real reason IMHO for either/or and I fail to see how this is helpful if there are networks based on SLAAC and networks based on DHCPv6, this only adds unnecessary inconsistency. And people make it even worse by requesting a flag to control whether nodes may use privacy extension or not. Why not make it consistent: Every network is always SLAAC, even if there is a DHCP server, it is SLAAC. Privacy Extension is always possible to protect people's privacy if they feel like it. And only DHCP is optional, but when it is available, it does not replace SLAAC, it "completes" it and either hands out an IP address or not, but even when it hands out an IP address, it does not replace SLAAC. And thus I don't really see any need for an M or O flag in a RA message. Clients supporting DHCP will always try DHCP when a link comes up. Really, this traffic is so little compared to current network speeds, it's absolutely insignificant. Regards, Markus -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
