Re: draft-bourbaki-6man-classless-ipv6-00

Can everyone tone it down a little bit PLEASE!

The actual distance between the positions here is rather small, I believe
we are basically standing nose to nose on different sides of the same line,
which is /64.

I think we all agree that /64 is the normal subnet size in most situations,
in other words the default, especially for subnets with general purpose
hosts, and most notably for subnet with hosts using SLACC. I would like to
see the Draft reinforce that /64 is the norm expected in many situations,
including references to RFC 7421 and RFC 7934. Also, I would like to see
this stated normatively in the draft using RFC 2119 "RECOMMENDED", that is
"/64 is the RECOMMENDED subnet size."

Furthermore, no one disputes that there are exceptions to /64. There are at
least two formal exceptions already, RFC 6164 and addresses that begin with
binary 000. Where we seem to diverge is the number and nature of the
exceptions that should be allowed to /64. One side seems to want only
formally recognized and approved exceptions, where as the draft is arguing
that there is much operational deployment of any number of subnet sizes
like 127, 126, 124, 120, ... beyond the current formally approved
exceptions.

The actual difference between MUST with stated exceptions and RECOMMENDED
is kind of nuanced anyway.

So here is an anecdote of the operational issues here;  In the last month I
established a Direct Internet Access (DIA) connection with the large Cable
Co. in our region to get their IP based video service for our on-campus
residential students and for various offices around the University, with
the added benefit of providing more direct access to campus resources for
commuter students, staff, and facility when at home.  The Cable Co provided
the addressing for the link to do BGP over; They provided a /30 for IPv4,
our internal practice these days is to use a /31, but there is really
nothing wrong with a /30. Since they provided a /30 for IPv4 they quite
logically provided a /126 for IPv6, and use the same last digits between
the IPv4 and IPv6 addresses, again our practice is to use a /127. However,
in totality this seems quite operationally reasonable and logical, but it
violates the IPv6 specifications, should I have told them we can't do
that?  No, in this case I believe its the specification that is wrong, not
the Cable Co's operational practice.

So, should we rewrite RFC6164 to also formally allow the use of a /126 as
well?  Or, should we simply recognize that /64 is a RECOMMENDATION (and
/127 for that matter is too), and let operators use other prefix lengths
that seem appropriate to the situation?

Thanks.

On Fri, Jun 2, 2017 at 9:33 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

> Do not support. A few reasons:
>
>    - The /64 boundary is beneficial for many reasons. See RFC 7421 and
>    RFC 7934.
>    - The document lists no compelling use cases of what you can do with
>    less than 2^64 addresses per link than you can't do with a 2^64 addresses
>    per link.
>    - The only technical motivation in this draft seems to be "classful
>    addressing was a bad idea in IPv4". That's not a valid argument in IPv6
>    because the address space is completely different. A /64 is *four billion
>    times* bigger than the IPv4 internet. That's 10,000 times more than the
>    difference between a grain of sand and the whole planet we live on. Such a
>    huge scaling difference pretty much invalidates any argument that solutions
>    that worked well in IPv4 will work well in IPv6.
>    - Routing on any prefix length is already required by the standards -
>    see BCP 198.
>
> Please stop trying to make IPv6 be the same as IPv4. That will take away
> our ability to make the Internet better once IPv4 is gone.
>
> On Fri, Jun 2, 2017 at 11:12 PM, Peter Hessler <phessler@theapt.org>
> wrote:
>
>> Support
>>
>> On 2017 Jun 02 (Fri) at 16:11:12 +0200 (+0200), Job Snijders wrote:
>> :Hi Working Group,
>> :
>> :Please review the below.
>> :
>> :Kind regards,
>> :
>> :Job
>> :
>> :----- Forwarded message from internet-drafts@ietf.org -----
>> :
>> :Date: Mon, 22 May 2017 04:25:28 -0700
>> :From: internet-drafts@ietf.org
>> :To: Job Snijders <job@ntt.net>, Randy Bush <randy@psg.com>, Christopher
>> Morrow <morrowc@google.com>,
>> :       Fernando Gont <fgont@si6networks.com>, Nick Hilliard <
>> nick@inex.ie>, Geoff Huston
>> :       <gih@apnic.net>, Brian Carpenter <brian.e.carpenter@gmail.com>,
>> Chris Morrow
>> :       <morrowc@google.com>
>> :Subject: New Version Notification for draft-bourbaki-6man-classless-
>> ipv6-00.txt
>> :
>> :
>> :A new version of I-D, draft-bourbaki-6man-classless-ipv6-00.txt
>> :has been successfully submitted by Randy Bush and posted to the
>> :IETF repository.
>> :
>> :Name:          draft-bourbaki-6man-classless-ipv6
>> :Revision:      00
>> :Title:         IPv6 is Classless
>> :Document date: 2017-05-22
>> :Group:         Individual Submission
>> :Pages:         7
>> :URL:            https://www.ietf.org/internet-
>> drafts/draft-bourbaki-6man-classless-ipv6-00.txt
>> :Status:         https://datatracker.ietf.org/
>> doc/draft-bourbaki-6man-classless-ipv6/
>> :Htmlized:       https://tools.ietf.org/html/d
>> raft-bourbaki-6man-classless-ipv6-00
>> :Htmlized:       https://datatracker.ietf.org/
>> doc/html/draft-bourbaki-6man-classless-ipv6-00
>> :
>> :
>> :Abstract:
>> :   Over the history of IPv6, various classful address models have been
>> :   proposed, none of which has withstood the test of time.  The last
>> :   remnant of IPv6 classful addressing is a rigid network interface
>> :   identifier boundary at /64.  This document removes the fixed position
>> :   of that boundary for interface addressing.
>> :
>> :
>> :
>> :
>> :Please note that it may take a couple of minutes from the time of
>> submission
>> :until the htmlized version and diff are available at tools.ietf.org.
>> :
>> :The IETF Secretariat
>> :
>> :
>> :----- End forwarded message -----
>> :
>> :--------------------------------------------------------------------
>> :IETF IPv6 working group mailing list
>> :ipv6@ietf.org
>> :Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> :--------------------------------------------------------------------
>>
>> --
>> If Reagan is the answer, it must have been a VERY silly question.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

-- 
===============================================
David Farmer               Email:farmer@umn.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>
===============================================