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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

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

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