On Tue, Feb 21, 2017 at 10:44 PM, Christopher Morrow <christopher.morrow@xxxxxxxxx> wrote:
On Tue, Feb 21, 2017 at 10:51 PM, Lorenzo Colitti <lorenzo@xxxxxxxxxx> wrote:On Wed, Feb 22, 2017 at 12:12 PM, Christopher Morrow <christopher.morrow@xxxxxxxxx> 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@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
David Farmer Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
==============================