[EMAIL PROTECTED] wrote: [..] > 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.
I guess you would also discard a history book as past learnings are not
good to have?
> They need to know how IPv6 works and how to implement it today.
Exactly the same as IPv4 but with more bits. Nothing odd there.
> 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.
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?
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?
Fortunately the RIRs still in most cases require people to actually
submit a network plan before getting an allocation from them.
Fortunately also those very same RIRs do provide excellent guidance when
people don't get it.
> 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 ;)
You will quickly find out that:
- not many people will use it
- that it is outdated the moment you are done
- that the same arguments you raise against those books you
are trying to claim are 'inaccurate' also go for your site.
[..]
> I'm not so arrogant as to claim I am all-knowing. That doesn't help win
> technical arguments.
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? :)
> 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.
Thus you claim to have the answers but are unable to write them down?
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 is all in the line of work, if you are a network operator or for
that matter anything related to computers you will need to stay on the
pace of things, if you don't, then you loose out.
>> 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.
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.
> The vast majority of these people have a very slim
> understanding of IPv6 and no experience implementing or running it.
If they really understand and grasp networking, IPv6 will not be a
problem. If it is a problem, then that is mostly because they don't want
to understand.
> 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.
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.
optionally:
- /128 for one single device when you know for sure that there
will only be a single device on it.
This has been the same already for the last, what, 5 years++? :)
[..]
> As you just said, IPv6 is *NOT* IPv4 with more bits.
It is as one doesn't have to care about ARP or ND in either setup.
There are other
> differences. You forgot anycast and you forgot to mention that only
Since when is anycast an exclusive IPv6 property? Anycast is a routing
trick. Nothing more, nothing less.
People have been using this for ages already.
> 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.
> You forgot interface addressing vs host addressing,
Is anyone using that then?
> and counting subnets instead of counting hosts.
Most networks I know simply use /24 per LAN, independent of how many
hosts get connected. As such, does that matter? This is just a premise
of the more address bits and that one uses a /64 per LAN instead of
having to tinker around with all those bits.
> You forgot special bits in the interface IDs.
Again does that matter? You can use RA or DHCP, RA will use the special
format, DHCP won't care less for a second.
> The principle of expandability at each level of delegation.
Since when is that new? Remember that old IPv4 book, with the classes,
wellps they are more or less back:
A = /0 - /32
B = /48
C = /64
there you go. It is all easy again.
> And all those transition technologies.
Transition technologies is a completely different ballpark.
But still, it is a very simple answer: Go Dual-stack.
Tunnels are only supposed to connect the islands where you can't do
native IPv6.
As for which one to use, well depends on what situation you are in and
what you require. http://www.sixxs.net/faq/connectivity/?faq=comparison
for a nice comparison table. Which won't provide you much more
information though unless you actually take the time to read a bit about
them.
> See how hard it is for an expert, to just summarize the parts which are
> important to lead a newcomer onto the right path?
See how difficult it is to try and know everything. You really can
ignore everything else. People don't have to know it. And when they do
want to know about it, they can easily check it up with a little google.
>> 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"
They don't have to be. In general they should be though.
> then what does the colleague do to explain?
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!
> 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.
As others and me mentioned: write a draft or write a book...
>> 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.
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.
The Internet is a moving place, if you can't keep up, let others do the
job....
To come back to the recommendations given directly, instead of reading a
book, you can also take a nice workshop. Silvia Hagen is really good in
giving these and guess what, unlike the book which gets printed and
needs distribution, they are fully up to date, check out:
http://www.sunny.ch/education/i_workshops.htm#1
And just in case, there are a lot of other companies providing those
services if you really need to get up to date.
But instead of bickering about people who don't want to educate
themselves a wee bit, can we return to protocol discussions? :)
Greets,
Jeroen
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
