Subject: An example of what is wrong with the IETF's IPv6 documentation

From: <[email-masked]>
Date: Tue, 23 Oct 2007 06:34:28 +0100

The following thread from ARIN's Public Policy Mailing List is an
example of what is wrong with the IETF's documentation of IPv6. People
are struggling to understand just how IPv6 works, not at the
implementation level of detail, but at a higher level. 

What is mandatory, what is optional? What are the basic principles, what
is the fundamental architecture?

Some people argue that IPv6 is merely IPv4 with more bits, therefore all
the rules and constraints of IPv4 must necessarily be applied. There is
no IETF document that provides the right kind of high-level view of
IPv6, and no document that provides guidelines for RIRs.

In the absence of such guidance, it appears as though people who plan to
alloocate /120's to customers are right, and Brian Dickson is the
authoritative voice of the IETF who understands IPv6 most clearly.

Most people who make decisions about addressing plans in the RIRs or in
ISPs, do not have the time to wade through dozens of RFCs trying to
figure out what is NOT DEPRECATED and what is the IPv6 STANDARD.

I believe that the 6MAN group should add to its charter two documents:
IPv6 guidelines for RIRs and IPv6 Overview for ISPs.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian Dickson
> Sent: 22 October 2007 22:42
> To: ARIN PPML
> Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm
> 
> Leo Bicknell wrote:
> > In a message written on Mon, Oct 22, 2007 at 09:31:36AM 
> -0400, Azinger, Marla wrote:
> >   
> >> 3177 is a recommendation from 2001 and not a standar of any kind.
> >>     
> >
> > I'm afraid many people are not looking at the right RFC's and/or 
> > considering what all needs to be changed if the /64 
> boundary is to be 
> > updated.  I'm fairly sure this is not an exhaustive list, /64 is 
> > referenced in many locations in different IPv6 RFC's, many of which 
> > are standards track.
> >
> > * http://www.faqs.org/rfcs/rfc2373.html
> >   "IP Version 6 Addressing Architecture"
> >   Status: Standards Track
> >
> >   Section 2.5.1: "Interface IDs are required to be 64 bits long..."
> >
> >   Section 2.5.7: Aggregatable Global Unicast Addresses
> >
> >   Section 2.5.8: Local-Use IPv6 Unicast Addresses
> >
> >   
> RFC 2373 was obsoleted by 3531 which was obsoleted by 4291.
> 2.5.8 is gone, but AGUA is still roughly the same (all but 
> 000 require use of EUI-64 modified), and ditto 2.5.1
> > * http://www.faqs.org/rfcs/rfc2374.html
> >   "An IPv6 Aggregatable Global Unicast Address Format"
> >   Status: Standards Track
> >
> >   Section 3.1 makes it clear the lower 64 bits are an interface
> >   identifier for
> >
> >   I also point out section 3.4 makes a recomendation we 
> continue to use
> >   a slow start method:
> >
> >     It is recommended that
> >     organizations assigning NLA address space use "slow 
> start" allocation
> >     procedures similar to [RFC2050].
> >
> >   
> 2374 was obsoleted by 3587.
> > * http://www.faqs.org/rfcs/rfc2450.html
> >   "Proposed TLA and NLA Assignment Rule"
> >   Status: Informational
> >
> >   Section 3: IPv6 Aggregatable Global Unicast Address Format
> >
> >   
> This bit was itself in RFC 2374, which was obsoleted by RFC 3587.
> > * http://www.faqs.org/rfcs/rfc2460.html
> >   "Internet Protocol, Version 6 (IPv6) Specification"
> >   Status: Standards Track
> >
> >   Section 3: Specifically referrs to 2373 (ADDRARCH)
> >   
> 4291  obsoletes 3531 which obsoleted 2373.
> 
> (I don't know why 2460 hasn't been updated with the new references...)
> > * http://www.rfc-editor.org/rfc/rfc3177.txt
> >   "IAB/IESG Recommendations on IPv6 Address Allocations to Sites"
> >   Status: Informational
> >
> >   Section 3: Recomendations
> >   
> This was informational only, from 2001, and IMHO no longer as 
> relevant as it once was.
> 
> So, by my count, that is 4291 and 3587.
> 
> My IETF draft also lists 2464 (Ethernet),  4941 (privacy), 
> and 4862 (autoconfiguration).
> Most other IPv6 RFCs inherit from those few, and mostly the 
> choice is rather axiomatic.
> Two small changes, basically, in a backward-compatible 
> manner, is meant to be as minimally-disruptive as is possible.
> (Think surgery to remove a burst appendix or inflamed tonsils.)
> 
> Anyone interested can see the draft at:
> http://www.ietf.org/internet-drafts/draft-dickson-v6man-new-au
> toconf-00.txt
> 
> My draft even includes the necessary patch for Linux, about 
> 17 lines in total, mostly the result of the necesssary line 
> length provisions for an RFC. (It was 10 lines
> originally.)
> 
> Brian
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List ([email-masked]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml Please contact 
> the ARIN Member Services Help Desk at [email-masked] if you 
> experience any issues.

I don't think it is necessary to discuss the quoted text, just be aware
of how hard it is to pin down how IPv6 works and find authoritative IETF
documents to back up an assertion.

--Michael Dillon 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: David Conrad <[email-masked]>
Date: Tue, 23 Oct 2007 09:12:49 +0200

Michael,

On Oct 23, 2007, at 7:34 AM, <[email-masked]>  
<[email-masked]> wrote:
> example of what is wrong with the IETF's documentation of IPv6.

I look forward to seeing your draft.

Regards,
-drc

---

From: <[email-masked]>
Date: Tue, 23 Oct 2007 09:00:09 +0100

> I look forward to seeing your draft.

Unfortunately, I was not involved in the creation of IPv6, nor did I
follow it as RFCs were released and then deprecated, so I don't fully
understand it myself. This is a piece of work that needs to be taken on
by some of the people who were immersed in the creation of IPv6.

--Michael Dillon

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 23 Oct 2007 10:52:36 +0200

As IETF Sergeant-at-arms, I will suggest that this topic is specific to 6MAN
and should be further discussed there.

Thanks !

Regards,
Jordi

> De: <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 23 Oct 2007 09:00:09 +0100
> Para: <[email-masked]>, <[email-masked]>
> Conversación: An example of what is wrong with the IETF's IPv6 documentation
> Asunto: RE: An example of what is wrong with the IETF's IPv6 documentation
> 
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 23 Oct 2007 08:50:11 +0000

On Tue, Oct 23, 2007 at 06:34:28AM +0100,
 [email-masked] <[email-masked]> wrote 
 a message of 143 lines which said:

> Most people who make decisions about addressing plans in the RIRs or
> in ISPs, do not have the time to wade through dozens of RFCs trying
> to figure out what is NOT DEPRECATED and what is the IPv6 STANDARD.
> 
> I believe that the 6MAN group should add to its charter two
> documents: IPv6 guidelines for RIRs and IPv6 Overview for ISPs.

Do not forget to do the same for the DNS, which is in an even worse
shape in that respect (lots of RFC, some partially deprecated, the two
foundation RFC being extremely old-style, etc).

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Oct 2007 19:20:53 +0930

On Tue, 23 Oct 2007 10:52:36 +0200

> and should be further discussed there.

Books worked for me, but then again, I'm willing to spend my own money
on keeping my knowledge up to date. It seems a fair number of
operational people aren't interested in doing that. RFCs of course
helped clarify points.

RFCs themselves are a waste of time I think for this problem. In my
experience most operational people in networking don't read those
either - sadly they don't know what they're missing.

Power point presentations at NANOG and other meetings seems to be the
only answer (sadly). Maybe groups like the IPv6 forum need to create
evangelist roles and send those people around to evangelising.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Oct 2007 11:46:14 +1300

(cc's trimmed as requested)

> by some of the people who were immersed in the creation of IPv6.

And it has been, in the form of books. I'm not suggesting these
are the only references, but

Migrating to IPv6 by Marc Blanchet
IPv6 Essentials by Silvia Hagen

are pretty much up to date.

     Brian

---

From: Mohsen Souissi <[email-masked]>
Date: Wed, 24 Oct 2007 11:22:39 +0200

On 24 Oct, Brian E Carpenter wrote:
 | (cc's trimmed as requested)
 | 
 | 
 | On 2007-10-23 21:00, [email-masked] wrote:
 | >>>The following thread from ARIN's Public Policy Mailing List is an 
 | >>>example of what is wrong with the IETF's documentation of IPv6.
 | >>I look forward to seeing your draft.
 | >
 | >Unfortunately, I was not involved in the creation of IPv6, nor did I
 | >follow it as RFCs were released and then deprecated, so I don't fully
 | >understand it myself. This is a piece of work that needs to be taken on
 | >by some of the people who were immersed in the creation of IPv6.
 | 
 | And it has been, in the form of books. I'm not suggesting these
 | are the only references, but
 | 
 | Migrating to IPv6 by Marc Blanchet
 | IPv6 Essentials by Silvia Hagen

==> See also the native-French-wiki book: http://livre.g6.asso.fr/
(from the Book "IPv6, Theorie et pratique", O'Reilly, 4th Edition).

 | are pretty much up to date.

==> so is the book online...

Mohsen.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 24 Oct 2007 13:32:07 +0200

Mohsen Souissi wrote:
[..]
> ==> so is the book online...

Also online: http://www.ip6.com/us/book/index.html (first hit for google
(ipv6 book) btw.

Other books on top of the ones mentioned already in random order:
 - Running IPv6
   http://www.runningipv6.net/
 - Deploying IPv6
   http://www.deployingipv6.net/
 - IPv6 In Practice
   http://www.benedikt-stockebrand.de/ipv6-in-practice-index_e.html

And of course the old "IPv6 bible": "IPv6, the new Internet Protocol"
(http://www.huitema.net/ipv6.asp)

I also have the book from Silvia Hagen (IPv6 Essentials) in both German
and English, the good thing about them is that Silvia writes it in a way
that is also understandable by people who didn't do much networking
before. The other books can be a bit more technical, but as this is a
technical topic that should not scare you away from them.

The 'correct' one for you thus depends on what you are looking for of
course ;)

Practical experience is of course the real way to learn to use it. Books
are good references though and tend to read easier than RFCs.

Greets,
 Jeroen

---

From: <[email-masked]>
Date: Wed, 24 Oct 2007 13:21:12 +0100

> Also online: http://www.ip6.com/us/book/index.html (first hit 

I've already mentioned that one on http://www.getipv6.info but I can't
say that it is recommended unless I learn more about it.

I trust Brian Carpenter's recommendation due to his history with the
IETF and I think I trust the French book because it is a wiki and Mohsen
claims it is being kept up to date. 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. I have Huitema's book among others, and that is
one of the reasons why I don't feel confident that I understand IPv6
well enough to write a draft of "Guidelines for RIRs" or "Guidelines for
ISPs". Perhaps there is a newer edition, but is it new enough? Was it,
or any of the other books on your list, vetted by enough eyes to be
trusted? The advantage of an RFC is that it does undergo some serious
vetting by people who went through the process of creating IPv6 and
understand how it works.

Books written by IPv4 experts are particularly problematic, because how
do we know that the author is not blinded by invalid IPv4 assumptions?

> The 'correct' one for you thus depends on what you are 
> looking for of course ;)

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. At this
point, I have to trawl through dozens of RFCs looking for this
information, or else use one of the books Brian recomFrom [email-masked] Wed Oct 24 08:22:12 2007
Content-class: urn:content-classes:message
Date: Wed, 24 Oct 2007 13:21:12 +0100
From: <[email-masked]>
To: <[email-masked]>
Subject: RE: IPv6 Books (Re: An example of what is wrong with the IETF's
	IPv6 documentation)

> Also online: http://www.ip6.com/us/book/index.html (first hit 

I've already mentioned that one on http://www.getipv6.info but I can't
say that it is recommended unless I learn more about it.

I trust Brian Carpenter's recommendation due to his history with the
IETF and I think I trust the French book because it is a wiki and Mohsen
claims it is being kept up to date. 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. I have Huitema's book among others, and that is
one of the reasons why I don't feel confident that I understand IPv6
well enough to write a draft of "Guidelines for RIRs" or "Guidelines for
ISPs". Perhaps there is a newer edition, but is it new enough? Was it,
or any of the other books on your list, vetted by enough eyes to be
trusted? The advantage of an RFC is that it does undergo some serious
vetting by people who went through the process of creating IPv6 and
understand how it works.

Books written by IPv4 experts are particularly problematic, because how
do we know that the author is not blinded by invalid IPv4 assumptions?

> The 'correct' one for you thus depends on what you are 
> looking for of course ;)

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. At this
point, I have to trawl through dozens of RFCs looking for this
information, or else use one of the books Brian recommended and hope
that the fact of his recommendation holds some weight. People are just
beginning to seriously deploy IPv6, many just in lab test environments.
A lot of mistakes are being made because too many people think of IPv6
as IPv4 with more bits. 

> Practical experience is of course the real way to learn to 
> use it. Books are good references though and tend to read 
> easier than RFCs.

It takes years to get the practical experience, and even more years to
unlearn bad habits. As for readability, an overview RFC is not likely to
be as hard to read as a protocol specification.

The real issue here is, does the IETF's responsibility end with giving
the vendors the specs that they need, or does the IETF have a
responsibility to RIRs, network operators, enterprise network managers,
and end users?

--Michael Dillon

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Oct 2007 14:19:17 +0200

that the fact of his recommendation holds some weight. People are just
beginning to seriously deploy IPv6, many just in lab test environments.
A lot of mistakes are being made because too many people think of IPv6
as IPv4 with more bits.=20

> Practical experience is of course the real way to learn to=20
> use it. Books are good references though and tend to read=20
> easier than RFCs.

--Michael Dillon

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Oct 2007 14:19:17 +0200

A book I'm pondering over, buying it maybe one day:

IPv6 Advanced Protocols Implementation
at Morgan-Kaufmann of Elsevier
http://tinyurl.com/2cetvh

Alex

Jeroen Massar wrote:
> ------------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

A book I'm pondering over, buying it maybe one day:

IPv6 Advanced Protocols Implementation
at Morgan-Kaufmann of Elsevier
http://tinyurl.com/2cetvh

Alex

Jeroen Massar wrote:
> ------------------------------------------------------------------------
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Oct 2007 14:47:59 +0200

On 24-okt-2007, at 14:21, <[email-masked]>  
<[email-masked]> wrote:

> Was it, or any of the other books on your list, vetted by enough  
> eyes to be trusted?

Books have technical reviewers before publication and reviews in  
publications and on sites like amazon.com after publication. So I  
wouldn't assume that their quality is necessarily worse than an RFC,  
but if it is, this is usually something that you can easily find out.

> do we know that the author is not blinded by invalid IPv4 assumptions?

So which of those books is written by an "IPv4 expert"?  :-)

> win arguments with people who are still stuck in IPv4 thinking.

Writing a good book is hard and takes a lot of time. I assume the  
same goes for writing a good RFC. Few people get rich from writing  
books about network protocols, but at least you can expect to see  
SOME money. Writing RFCs purely for the benefit of the community on  
the other hand won't make you a dime. So I'm not surprised there  
aren't any RFCs that are useful guidelines to people new to IPv6.

> responsibility to RIRs, network operators, enterprise network  

The IETF can't do anything unless someone volunteers to do the work,  
so answering in the affermative would be an empty gesture.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 24 Oct 2007 15:50:29 +0200

> http://tinyurl.com/2cetvh

Did not see that one before, but I see one important name on the book,
Jinmei, and as such indeed, if you are looking at actually implementing
an IPv6 stack yourself, it most very likely will not be a bad book to
read ;)

/me puts it on the 'add to collection list'

[email-masked] wrote:
> claims it is being kept up to date.

Well, you can also simply accept his recommendation based on the mere
fact that a lot of people have and use the books by Silvia Hagen and she
has been giving IPv6 lectures for quite a few years already, she
definitely knows what she is talking about. But so go for the other books.

The books I noted (thus hardcopies, not the web one) are all written by
people who actively use IPv6, most have implemented IPv6 in a large
environment and have participated in the IETF and also the various RIRs.
As such they definitely know what they are talking about. 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'm not sure that I trust the other
> 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. 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.

The other books are all quite pretty recent (max 2 years old) and thus
indeed contain more up to date information.

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.

[..]
> 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? :)

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...

> A lot of mistakes are being made because too many people think of IPv6

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. Then again, if you play with it too long you don't
really notice a difference anymore I guess ;)

> be as hard to read as a protocol specification.

The big question is: would they then suddenly read it?

No, they would still take a book, ask their friend/colleague.

> responsibility to RIRs, network operators, enterprise network managers,

IMHO, for protocols (thus IPv6, IPv4, POP3, IMAP etc etc) it ends at the
vendors, as those have to implement a protocol.

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.

Though INPUT on those protocols, what can be better, what should change
etc, thus operational input, is of course very welcome as they do have
to use them, and if they don't use them, what is the point of making
them in the first place.

Greets,
 Jeroen

---

From: <[email-masked]>
Date: Wed, 24 Oct 2007 15:30:50 +0100

> 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.

> > 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.

> > 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.

> 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? 

> 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

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 24 Oct 2007 17:03:10 +0200

> 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
> 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

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.

[..]
> 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

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.

> 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.

> 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.

> 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.

> 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-masked] 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,

As others and me mentioned: write a draft or write a book...

> 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

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 24 Oct 2007 17:09:00 +0200 (CEST)

Hi,

I can recommend one book also "IPv6 deployment guide" available in pdf:
from http://www.6journal.org/archive/00000148/ or 
http://www.6diss.org/publications/info/deployment-guide.pdf
Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 24 Oct 2007 19:37:06 +0200

Other free books in PDF available at:

http://www.ipv6tf.org/index.php?page=news/newsroom&id=1260
http://www.ipv6tf.org/index.php?page=news/newsroom&id=988
http://www.ist-ipv6.org/pdf/ISTClusterBooklet2003.pdf

Regards,
Jordi

> De: Mohacsi Janos <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 24 Oct 2007 17:09:00 +0200 (CEST)
> Para: Jeroen Massar <[email-masked]>
> CC: <[email-masked]>, Mohsen Souissi <[email-masked]>
> Asunto: Re: IPv6 Books (Re: An example of what is wrong with the IETF's IPv6
> documentation)
> 
> Hi,
> 

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: David Malone <[email-masked]>
Date: Wed, 24 Oct 2007 22:59:38 +0100

> gotten used to understanding networks and being right when they make

FWIW, when Niall and I were writing, IPv6 Network Adinistration,
these were the people we were trying to target, so we tried to
describe IPv6 features in terms of things that IPv4 network engineers
and sysadmins would understand. I think Iljitsch's book takes a
similar tack.

I was one of the tech reviewers for Silvia's second book, and it
gives wider coverage of protocol details, but has a less operational
flavour.

I have Marc's network implementation book, itojun's programming
book and Jinmei et al.'s stack implementation book on my to-read
list, but sadly I haven't got to them yet.

	David.

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 02:11:00 +0100

> 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.
> 

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.

>  - that it is outdated the moment you are done

That is not true of wikis.

>    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.

> 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?

>    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.

> 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-masked] 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?

> > 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Oct 2007 23:58:23 +0200

On 24-okt-2007, at 17:03, Jeroen Massar wrote:

>> There are other differences. You forgot anycast and you forgot to  
>> mention that only

> People have been using this for ages already.

Note that the anycast that the DNS guys and 6to4 relays use and the  
anycast defined for IPv6 are two very different things. The former is  
indeed a routing trick (hack, really), while the latter is something  
that's done on the link layer. From a book I happen to know well:

"Multicast and anycast addresses may be used as destination addresses  
in packets, but only unicast addresses may be used as source  
addresses. Also, only routers may be configured with an IPv6 anycast  
address.
This means that strictly, anycasting services such as the DNS isn’t  
compatible with RFC 3513. After all, for anycast DNS to work, the  
anycast address must be present on more than one DNS server (which  
presumably are hosts and not routers), and the responses to DNS  
queries are sent back with the destination address of the query (the  
anycast address) as the source address. The host that sent the query  
wouldn’t recognize the response if it came from a different address.  
However, anycasting services is rarely done using the actual IPv6  
anycast link-level mechanism, where several systems configured with  
the same anycast address are connected to the same subnet."

However, I don't believe the IPv6 link anycast service is all that  
widely implemented in routers.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 08:50:18 +0100

> Have you read the analysis pieces on how, "Powerpoint doomed 
> the Columbia" (space shuttle)?
> http://www.washingtonpost.com/wp-dyn/content/article/2005/08/2
> 9/AR2005082901444.html

No but I have read the original report of the investigating committee
into the Challenger disaster and I remember the cluttered slide which
mentioned the O-ring problem. That's why I am not suggesting that the
IETF start producing slideware, but instead suggesting that we need a
summary prose RFC.

> It doomed the Columbia, and killed seven astronauts.

Not to mention Challenger which also killed astronauts.

> I hope that isn't how you are characterizing my proposal, or 
> the underlying premise.

Did I mention your name? If I recall correctly it was Geoff Huston who
raised concerns about IPv6 exhaustion which led to ARIN changing its
policies to recommend that ISPs assign /56 blocks to small site users.

> What I *am* concerned about, is maintaining 1 prefix per ASN, 
> to prevent routing table bloat.

As long as the time of multiple IPv6 prefixes per ASN is delayed until
IPv4 networks start disappearing from the global routing table, we are
OK. I expect to see this begin in 5 years.

> Rational folks can disagree on how much this needs to be contained.

The vendors seem confident that there is no near-term issue here. 

> Basically, this boils down to whatever the WG chair, AD, and 
> consensus of the WG say it is.

Precisely. It has to be discussed in the WG for consensus to form, one
way or another.

--Michael Dillon

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 Oct 2007 22:40:49 -0400

> harder it is to convince them of something or displace a mistaken idea.
Have you read the analysis pieces on how, "Powerpoint doomed the 
Columbia" (space shuttle)?
http://www.washingtonpost.com/wp-dyn/content/article/2005/08/29/AR2005082901444.html

It basically details how use of "summary information" in powerpoint 
slides, resulted in too little
real information being given to managers, who were then unable to 
appreciate the important details
that affected the decisions on what to do about a problem.

Sometimes it is important to ensure the other person gets *all* the 
information they need,
even if it seems like it is too much information.
> It matters when people make claims about IPv6 exhaustion based on
I hope that isn't how you are characterizing my proposal, or the 
underlying premise.

Nothing could be further from the truth!

What I *am* concerned about, is maintaining 1 prefix per ASN, to prevent 
routing table bloat.

That was, and is, the driving motivation for preventing *LIR* allocation 
exhaustion and re-allocation.

There is no doubt that RIRs will have way, way, way more space than LIRs 
will be able to consume
in any reasonable time-frame. The only issue is, how frequently LIRs 
need to get more space.

In an ideal world, that would be as close to "never" as possible.

This is an example of the differences of opinions between degrees of 
importance of a particular goal, even
when everyone believes that the negation of that goal is universally 
considered "bad":

-> Keeping the routing table in the DFZ from growing out of control.

I'm not aware of anyone advocating for allowing the DFZ to grow 
unconstrained, quickly, or in an anarchistic manner.
> advancement of the IPv6 protocol.
I don't speak for 6man. However, let me opine, if you will.
Advancement of a protocol != advancement of a specific deployed internet 
(The Internet),
or of advancement of the *use* of the protocol in a particular environment.

I believe "advancement" means incremental improvements and innovations.
Basically, this boils down to whatever the WG chair, AD, and consensus 
of the WG say it is.

Brian

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 25 Oct 2007 12:37:29 +0200

> others, so that they too, can win technical arguments, or see the error

I think you hit the nail on the head with this one statement: "the CURRENT
state of the IPv6".

The real problem is that IPv6 is still evloving (closing the IPv6 working
group non-withstanding). Thus new changes start to happen and new
discussions about implementiaton occure all the time as people learn what
works and what does not.

Books takes months to write and more to publish - by the time they are in
print the IPv6 world has moved on.
RFCs are not much better, they also take months to get written, then can
take years to be approved (the only one I was part of took more than 2 years
from conception until approval).

Maybe a wiki or other online / real-time solution would be best, but this
will require someone to manage it and people who have a clue to monitor
(moderate) it, and most of these people are either doing it or are working
on improving it (i.e. writing RFCs).
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: <[email-masked]>
Date: Thu, 25 Oct 2007 12:20:19 +0100

> Maybe a wiki or other online / real-time solution would be 
> best, but this will require someone to manage it and people 
> who have a clue to monitor (moderate) it, and most of these 
> people are either doing it or are working on improving it ( 
> i.e. writing RFCs).

I think this is the reason why ARIN set up the wiki at
http://www.getipv6.info and I have been contributing to this wiki along
with a few others. Mostly I have taken comments from mailing lists, such
as Brian Carpenter's specific recommandation of two books as being up to
date.

But it would help if more of the people in IETF who really know IPv6
would go to the wiki and contribute. In particular, there is a page on
adressing plans that is very light, more of a strawman than anything
else. The wiki *is* being managed by ARIN staff so that SPAM/defacementr
attempts are quickly removed.

Ideally, the above-mentioned wiki would evolve into an authoritative
reference source to other materials on the web and in print. I have
started this page http://www.getipv6.info/index.php/Book_Reviews in
order to collect such references. Please feel free to add any other
books to the page.

--Michael Dillon