> Next to that they also have technical reviewers and nowadays > in the age of the Internet there are sites where reviews are > given about the books and you can base your opinion on that too.
I've seen enough inaccuracies in books that I don't really trust the technical review process of publishers, and the website reviews require a certain volume of reviewers in order to converge to a reasonably accurate result. I don't believe any IPv6 books have reached the volume of sales that would result in consensus on review sites. > > I'm not sure that I trust the other > > books in your list, especially since you reference Huitema's book > > which is part of the problem. > > As I stated, it is the "old bible", it is from 1996 or so > after all. As such it is FAR from current but still it is a > great book, just a wee bit outdated. I think that you and I have a fundamental disagreement on how technical material would be presented. I would prefer to hide "wee bit outdated" books, just as I don't say anything about Classful addressing when teaching people what an IPv4 address is. VLSM and CIDR is the state of the art, and classful adressing only deserves mention as an afterthought to explain why on earth so many people still talk about Class C blocks. People don't need to know about TLAs, and the wonderful goals of IPNG which were later discarded along the way. They need to know how IPv6 works and how to implement it today. They need to be able to design a sensible addressing plan that maintains the IPv6 architecture and will not require renumbering large parts of their network in a few years to accommodate growth. They need to understand that it is a sin to undersize a subnet block which is the reverse of the situation with IPv4. > If you have an IPv6 book > collection that that and also "IPng Internet Protocol Next > Generation" by Scott Bradner and Allison Mankin is definitely > a must on the shelf. Yet another book that I have on my bookshelf which led me to require an IPv6 reeducation. > Books need to be edited and published which takes quite some > time and people are not going to redo them everyday. Though, > as I noted, most of them have websites which will contain > errata fixups and also new chapters or extra material to > cover that gap though. > > Run into a bookstore, browse through them and then decide. It > is also a matter of taste and what you want. It takes more than some browsing to judge whether the author really is up to date and not mired in IPv4 thinking or past glories of the IPNG that never was. > > Indeed. I'm not looking for a book at all, but an RFC which > summarizes > > the current state of IPv6 that can be used as an > authoritative source > > to win arguments with people who are still stuck in IPv4 thinking. > > Ehmm, you are trying to make an argument against people while > you actually don't know what you are talking about? :) I'm not so arrogant as to claim I am all-knowing. That doesn't help win technical arguments. And although I can deal with my own educational needs by plodding through RFCs and books etc., that doesn't help me find a concise overview of the CURRENT state of the IPv6 art to recomment to others, so that they too, can win technical arguments, or see the error of their ways. > Really, that won't work. A summary won't help there either, > you will need to know really what you want to talk about. Do > it, then you know and then you can win arguments. That is if > your only target is to always "win" in those things, > sometimes the other party actually makes a very completely > valid point... I don't think you understand the situation. There are loads of people with many years of deep IPv4 experience under their belt. They have gotten used to understanding networks and being right when they make design tradeoffs. The vast majority of these people have a very slim understanding of IPv6 and no experience implementing or running it. Yet they will be expected to design and deploy IPv6 networks that take us through the transition period. You can't tell these people to stop what they are doing, and go back to school. This is the audience for the kind of summary that I proposed. In the RIR sphere it will stop people from supporting policies which recommend *ALL* ISPs to assign a /120 to *ALL* customers unless they can justify more space. To my mind, that is not IPv6 and yet in order to argue against such a policy, people have had to trawl through IPv6 RFCs to see if it is clearly written somewhere that assignments should be a /48 except if you know for sure that there will only ever be one subnet in which case a /64 is appropriate. Even then, the RFCs for IPv6 are known to be full of deprecated material, non-standards material, and so forth, that a lot of people doubt whether or not assigning a /48 is the right thing to do. If we had an RFC with "Guidelines for RIRs" it would not only say that a /48 is right, but it would also explain why it is right and how it fits into a wholistic IPv6 architecture. > > A lot of mistakes are being made because too many people > think of IPv6 > > as IPv4 with more bits. > > Is it anything else than? s/ARP/ND+DAD/, s/subnetting/\/64/ > and a few others, but there is not much else in the most > basic parts that is really different. As you just said, IPv6 is *NOT* IPv4 with more bits. There are other differences. You forgot anycast and you forgot to mention that only 1/8th of the total space is currently allocated for unicast. You forgot interface addressing vs host addressing, and counting subnets instead of counting hosts. You forgot special bits in the interface IDs. The principle of expandability at each level of delegation. And all those transition technologies. See how hard it is for an expert, to just summarize the parts which are important to lead a newcomer onto the right path? > The big question is: would they then suddenly read it? > > No, they would still take a book, ask their friend/colleague. And when the colleague says something which disturbs their sense of order such as "interface Ids really should be 64 bits", then what does the colleague do to explain? Hunt through books and miscellaneous RFCs, or point to a recent clear summary that explains all these differences? A document that covers just the points which cause people to scratch their heads and look confused or exclaim in disbelief. We have to bring a lot of new people up to speed in a short time. > End-users (thus including network operators, who are not > implementing the protocols themselves) should read a good > book about the subject. Or actually, the vendor should be > doing a good job of making it easy to use and provide > adequate documentation. There was a time when the IETF would write RFCs to help end-users, especially when there was a mass migration event such as the one we will see for IPv6 in the next 2-3 years. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
