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: ppml-bounces(_at_)arin(_dot_)net
[mailto:ppml-bounces(_at_)arin(_dot_)net] 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 (PPML(_at_)arin(_dot_)net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact
the ARIN Member Services Help Desk at info(_at_)arin(_dot_)net 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf