On Tue, 31 May 2011, Markus Hanauska wrote:
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? My main argument was
(and still is), that through a couple of tiny changes in the RFCs (only
a couple of sentences) and equally small changes to implementations
(5-10 lines of additional code), IPv6 could have been so much easier for
everyone: Hardware vendors producing IPv6 hardware, software vendors
writing IPv6 software, network administrators creating IPv6 networks,
end users actually using IPv6. The negative impact would have been close
to zero, the positive impact would have been big and maybe IPv6 would
have been somewhat more mainstream as of today if people had considered
some tiny things. The most important ones are:
The impact of changes can be quite substantial.
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.
Agree. Adding DHCPv6 support to an existing IPv6 capable implementation
might be possible.
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 disagree with introduction of another flags. This requires substantial
changes in the codes.... Which will take ages....
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).
We need M/O bits to give some sort of consistency. But nothing prevent a
host to use DHCPv6 and SLAAC address and static in the same time.
I have to disagree with your suggested ordering.
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).
Nothing prevent you the suggest an draft document for multicast or anycast
resolving DNS. There is environment where SLAAC more acceptable - e.g.
less adminisration, and there is environment where DHCPv6 is the only way
to operate.
Best Regards,
Janos Mohacsi
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
