> So you are letting people 'design' networks who can't even be > bothered to read up? Can you inform me of the places where > that is, so that I can avoid them?
You seem to think that the world is nice and neat and tidy. That people don't do things unless a more informed person "lets" them do it. Unfortunately, the world is not like that. > And really, what is so hard about giving a /64 per LAN, > counting a bit how many subnets you have in this neighborhood > and that region and applying some simple arithmetic? Because when that neighborhood needs to expand beyond what you were able to foresee, then you need to restructure both the neighborhood and the region. But if you had stuck to the model of giving a /48 per site, and a /64 per LAN, then you would never suffer this problem. > Fortunately the RIRs still in most cases require people to > actually submit a network plan before getting an allocation from them. But the network plan counts /48 subnets, not /64s. > Fortunately also those very same RIRs do provide excellent > guidance when people don't get it. Given that one RIR has already introduced a policy that allocates /56 to small sites, I can see no reason to trust that RIRs are necessarily better informed. The fact that they give excellent advice on IPv4 does not imply that they are capable of giving similarly excellent advice on IPv6. > > They need to understand that it is a sin to undersize a > subnet block > > which is the reverse of the situation with IPv4. > > I have one very simple solution to your problem: > Write and publish a book or website about this ;) Why add yet another website to the mix? ARIN has set up an educational wiki for IPv6 so I am satisfied to just contribute to that. Because it is a wiki, many people can contribute and errors can be corrected, or conflicting theories can be clearly explained. > You will quickly find out that: > - not many people will use it > - that it is outdated the moment you are done That is not true of wikis. > - that the same arguments you raise against those books you > are trying to claim are 'inaccurate' also go for your site. If a wiki is inaccurate, then it can be corrected. > But you do want the summary so you can win it without > actually knowing why those decisions where made, which > actually would allow you to argument why they where made, > though by other people and thus allow you to make a stronger case? :) It doesn't matter how strong your case is if people don't understand it. The more that you require the other person to learn and understand, the harder it is to convince them of something or displace a mistaken idea. Referring to an IETF standards document is a shortcut for this. > Thus you claim to have the answers but are unable to write them down? I've never claimed to have the answers. > Also since when are RFC's even remotely the 'current state' anyway? > They tend to take a long time to become actual RFC's and > vendors tend to do things just a bit different. That's why I am highlighting the fact that now, when we are finally beginning to reach exponential growth of IPv6 deployment, we need to have an RFC that reflects the "current state" of IPv6. > Then they should also know that sometimes they are wrong. > They should also know that things change. And that sometimes > they need to read a book or a some other material on it. And if they don't know this, and you only have 15 minutes of their time, how do you convince them that they really need to take the time to read the book? Where is the authoritative summary that can be used to make this argument? > The current RIR policies are simple: > - /48 for end-sites > - /64 when you know very sure that that end-site will have only > ever one single network behind it. Wrong. The current policies depend on region and in one region, it includes /56 for small sites. There is also a proposal under discussion that would recommend /120 for smallest sites. > This has been the same already for the last, what, 5 years++? :) Keeping your head in the sand will not fix the problem. There is a growing number of people tinkering with IPv6 policies and architecture whose goal is to conserve IPv6 address space, just as IPv4 address space is conserved. > Since when is anycast an exclusive IPv6 property? Anycast is > a routing trick. Nothing more, nothing less. In IPv4, anycast is a routing trick. In IPv6 it is part of the addressing architecture. > > 1/8th of the total space is currently allocated for unicast. > > Does that matter? You are only supposed to use the space that > gets assigned/allocated to you from a RIR. It matters when people make claims about IPv6 exhaustion based on 2000::3 > Actually answer that he doesn't know what he is talking about > and go/redirect to a place where they do. > > tip: [EMAIL PROTECTED] already exists for more than 10 years now > and a lot of people have found great help there. Don't be > afraid to ask! Are you suggesting that the best we can do to provide a management summary of the current state of IPv6 is to tell people to mail their questions to some unknown expert? > > 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. > > There is no flag day. This is btw clearly noted in the > beginning of Christian Huitema's book which is also 10 years > old already. What does a flag day have to do with anything? The problem is that IPv4 addresses are on the verge of running out so there is an exponential growth in IPv6 deployment as a result. That is a mass migration event. > The Internet is a moving place, if you can't keep up, let > others do the job.... Right. As I was saying, would it be possible for some people with IETF experience during the design of IPv6 please write a couple of summaries of IPv6, one "IPv6 Guidelines for ISPs" and one "IPv6 Guidelines for RIRs". The intent would be to collect together material which is currently scattered among many RFCs and in some case, not in any RFCs at all. > To come back to the recommendations given directly, instead > of reading a book, you can also take a nice workshop. > And just in case, there are a lot of other companies > providing those services if you really need to get up to date. If my problem was just in getting myself up to date, I would not be asking for these documents to be produced by the IETF. > But instead of bickering about people who don't want to > educate themselves a wee bit, can we return to protocol > discussions? :) The 6MAN charter says that this WG is for the maintenance, upkeep and advancement of the IPv6 protocol. I am asking for documents which fit squarely under "advancement". It also says that all new work items not listed in the charter require WG approval, which is why I am asking for this here. Your message is a good example of the reason why. You have referred to many places where a person can find information about IPv6 but have been unable to refer to an authoritative source that carries the same weight as an RFC. --Michael Dillon -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
