In your letter dated Tue, 31 May 2011 13:19:39 +0200 you wrote: >On 2011-05-31, at 12:35 , Philip Homburg wrote: >> The difference is that IPv4 has a model of one subnet per link. > >Why do you think so? The computer I'm using right now has two IP = >addresses of different IP subnets on the same network interface (and I = >really mean the same layer 2 network, there are no VLANs in use). I = >think pretty much any operating system as of today allows for such a = >configuration.
I would say that having an interface with two IPv4 addresses is not really in the model. But specifically, you may find that for each of those two addresses the host will treat only the subnet associated with the address as on-link. >> That's always that case if you want a configuration that is not = >mainstream: >> you either have to buy a more expensive product that has more = >configuration >> options or, in many cases, you can also use open source. > >But don't you think it helps a lot to push a new technology to = >mainstream if it is possible to also use this technology without any = >expensive hardware or complicated configurations? There will always be people/organisation who are different from mainstream. For example, for the IPv6 setup I'm running at home there are no specs at all. >1) A need for DHCPv6 right from the start and taking it into = >consideration everywhere SLAAC was taken into consideration. E.g. is = >this thread; DHCPv6 should have been "SHOULD" right from day one. I have no idea where that went wrong. 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. >2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual = >addressing all on the same link *AND* same prefix in such a way, that it = >is almost address conflict free without having to rely on ND to discover = >conflicts (since ND will fail for hosts currently offline, but with = >reserved addresses): Defining all addressing schemes in such a way, that = >they don't interfere with each other under "normal" operation conditions = >- of course MAC address conflicts are still possible, two nodes with = >SLAAC + Priv Ext may also collide (only ND can avoid that) and = >misconfiguration will always be possible; but I consider none of these = >as normal operation conditions). Only two flags in 64 bit node addresses = >would have been necessary for that. I'm not sure that a bit that distinguishes manual configuration from DHCP is a good thing. SLAAC with EUID already has its bit. 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. >3) No M/O bits in router advertise messages. Every interface can have a = >manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC = >w/ Priv Ext and that for every prefix it is aware of. The order of = >preference for outgoing traffic is configurable, the default order is = >defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv = >Ext, SLAAC). Some people were worried about useless DHCP traffic. I'm not sure if that is justified. But just setting those bits in the router config should be no problem. That only leaves the case where there is no router. If everybody always sets those bits, then maybe routers will have them as standard. >4) Considering DNS right from the start, since DNS is almost critical = >for many networks as of today. If one of the IPv6 main design goal was = >to allow the majority of networks to operate without a DHCP server (and = >it looks as if it was, otherwise DHCPv6 would have been taken much more = >into account), something like RFC 6106 (former 5006) was missing way too = >long IMHO. Though I still fail to see the need for this RFC at all; I = >had rather said that for simple setups that don't provide DNS servers = >via DHCP, it would have been enough to have a well defined anycast or = >even multicast address for DNS servers (I don't know any real life = >network where DNS server addresses changes so frequently, that this = >wouldn't work well in practice). There is a difference between statefull and stateless DHCPv6. I think NTP is also pretty important. This is just one of those things that have to be corrected based on real world experience. Unfortunately, the real world ignored IPv6 for 15 years. So only now do those things get fixed. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
