On Tue, Feb 21, 2017 at 10:44 PM, Christopher Morrow <
christopher(_dot_)morrow(_at_)gmail(_dot_)com> wrote:
On Tue, Feb 21, 2017 at 10:51 PM, Lorenzo Colitti
<lorenzo(_at_)google(_dot_)com>
wrote:
On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <
christopher(_dot_)morrow(_at_)gmail(_dot_)com> wrote:
But the configuration cost and management overhead is not proportional
to the hosts that are served by those interconnections, it is proportional
to the number of interconnections. A 10x100G peering interconnection that
serves X million hosts is one interface that has to be managed.
isn't the dicsussion here really:
"If you want to use /64 go ahead, if you want to use /121 go for it,
if you want to use SLAAC you'll get a /64 and like it"
Not sure. I for one wouldn't agree with that position, because I don't
see that /121 has enough advantages over /127 and /64 - and few enough
downsides for general-purpose hosts - to make it a good idea in general.
I don't think /121 is anymore special than /127... or /64. My point was we
don't care what prefix people use, generally, that there are cases where a
/64 is required and that's fine, there are cases where /64 isn't and people
can do what they want there. It's simple enough to do SLAAC/64 on lans and
other places.
Requiring /64 or /127 and nothing else means when you do have to do a /120
or something else you MAY end up fighting vendor problems because they made
assumptions about: "only ever 64 or 127".
I have to disagree with Chis slightly, /127 and /64 are slightly special,
in that they are clearly RECOMMENDED and the others (/126 through /65)
are NOT RECOMMENDED. The problem we have is that some people think it
isn't enough to say /64 is only RECOMMENDED and want something stronger,
the stronger option is REQUIRED, and the current and historic text says
"required". On the other hand we have people saying REQUIRED is too
strong, because it implies that /126 through /65 are not possible to use,
which is demonstrably false.
There is no universal (Internet wide) requirement, to make the Internet
work, that all interfaces have /64 as their as their prefix. In fact as a
host on the other side of the Internet from me, you are forbidden from
making that very assumption, you must treat my 128 IPv6 address as opaque.
Their is a local requirement that all interfaces on the same link have the
same prefix. The easies way to achieve this is to assume a fixed prefix
everywhere, and we picked /64 for that, and built it into SLAAC. Once we
picked it, we have also built a whole bunch of other things that depend on
that pick, many of those other things are discussed in RFC7421.
Is the operational effort to utilize other prefix lengths (/126 through
/65) justified, including the issues discussed in RFC7421? Most of the
time, probably NO, but some times, YES it is. Here is the crux of this
issue, some of you think it is never justified. But tough, this simply is
not your call, and again on the other side of the Internet you are not
supposed to care anyway.
Furthermore, as currently written it is easy to misinterpret the text as
implying that a configuration of something other than /64 MUST be ignored
or overridden. My preferred solution is to simply change "required" to
"recommended" in the current text. I'd also be ok with saying /64 is
required for SLAAC, and recommended for everything else. But, If current
"required" is kept for everything, then it needs to be clarified who the
requirement is directed at, and that there are other exceptions than just
addresses that begin with 000. I think something like the following would
would deal with the first part;
Other than the implications for Stateless Address
Autoconfiguration(SLAAC)[RFC4862],
this requirement primarily constrains operators of IPv6 networks and
does not imply
implementations of IPv6 are to ignore or override a configuration that
is in conflict with
this requirement.
And as has been talked about, for the second part we can enumerate the
exceptions or say that there are other standards track exceptions beyond
just the addresses that begin with 000.
Thanks.
--
===============================================
David Farmer Email:farmer(_at_)umn(_dot_)edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
===============================================