Subject: Different sets of needs (Re: Getting the title right (Re: draft-bourbaki-6man-classless-ipv6-00))

From: Mark Smith <[email-masked]>
Date: Tue, 6 Jun 2017 17:52:12 +1000

On 6 June 2017 at 16:36, Roger Jørgensen <[email-masked]> wrote:
> On Tue, Jun 6, 2017 at 7:42 AM, Lorenzo Colitti <[email-masked]> wrote:
>> On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith <[email-masked]> wrote:
>>>
>>> * The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119)
>>
>>
>> As an host implementer, I strongly object to this.
>>
>> In practice (if you ignore the will-never-be-used space in ::/3), the
>> current state of affairs is that the parameter value MUST be 64. That means
>> that an implementation that is compliant with IETF best practices can simply
>> not work when the value is not 64.
>>
>> Saying that the value MAY be larger than 64 is bad for host users for all
>> the reasons written in RFC 7934. I don't think we should support this on
>> general purpose hosts because we as the users of those hosts will all suffer
>> from the reduced functionality and decreased efficiency that that brings.
>
> Why can't we say RECOMMANDED 64, and default SHOULD be 64, and for the
> protocols that require 64 it is a MUST?
>
> ... shouldn't that handle your issue and Job's issue and everyone's issue?
>
> I can't really see why I shouldn't be able to MANUAL configure a /125
> on my interface and have default gateway being provided by RA on
> link-local using /64. Two different address "types".
>
>

I think this is a significant part of the issue. There's really two
sets of needs or desires here, network operators and host
operators/implementers.

IPv6 has really been designed to solve a host addressing problem.
There is no significant inter-router link addressing problem in IPv4
compared to hosts having to sit behind NATs to get enough host
addresses.

Host operators/implementers won't care what prefix length is used by
network operators on inter-router links, as long as the hosts' packets
are successfully forwarded across them.

Where prefix length matters to host operators is at the edge of the
network where the hosts are attached. If some of IPv4 addressing
practices are carried over to IPv6 at the edge of the network (e.g.,
/120s on link-layers that have the capacity to support far more hosts
than that, or a /128 to a CPE), it may recreate the sorts of IPv4 host
addressing and addressing related problems that IPv6 was meant to
prevent.

I think that is the fear (that's my fear), and if it becomes the case,
IPv6 won't have solved the fundamental problem it was meant to solve.

(Although it'd be controversial and contrary to the robustness
principle, one approach host implementers could take to ensuring
they're provided with enough edge address space is to refuse to bring
up IPv6 unless the received PIO(s) has/(have) a large enough prefix
length. An absolute failure presented to an end-user is commonly a
better user experience than partial and possibly subtle intermittent
ones.)

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Jun 2017 16:59:49 +0900

+1

Yes, I think that is what host operators are concerned about. But if the
network operators only care about servers and inter-router links, can we
just put in an exception to cover manual configuration, and move on? I
don't think anybody would object to that.

> better user experience than partial and possibly subtle intermittent

If host operators want to do that they also have to decline to implement
DHCPv6. From the host's perspective, there is little difference between a
64-bit prefix on which the device can only get one IPv6 address, and a
128-bit prefix.

---

From: Mark Smith <[email-masked]>
Date: Tue, 6 Jun 2017 18:27:50 +1000

On 6 June 2017 at 17:59, Lorenzo Colitti <[email-masked]> wrote:
> network operators only care about servers and inter-router links,

My experience having worked in both network operator and host operator
roles is that network operators don't care much about servers either!
In most organisations there a usually an operational and
responsibility boundary between the groups who worry about devices
that carry the packets and those who worry about the devices that send
and receive them.

> can we
> just put in an exception to cover manual configuration, and move on? I don't
> think anybody would object to that.
>
>>
> DHCPv6.

No necessarily. If stateful DHCPv6 is being used for addressing, at
the time of attachment, a host could ask for as many addresses as it
needs/wants and if it doesn't get them, take IPv6 down.

> From the host's perspective, there is little difference between a

To be a bit clearer, I was thinking of a host refusing to attach
unless the RA PIO had a prefix length of 64 in it (or some other large
value). A general "is this link's IPv6 prefix(es) size(s)
unnecessarily small" test, rather than any sort of test for
availability of as many addresses the host itself may want or need
(which is different to the DHCPv6 test I described before).

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Jun 2017 14:48:04 +0200

> If some of IPv4 addressing
> /120s on link-layers that have the capacity to support far more
> hosts than that, or a /128 to a CPE), it may recreate the sorts of
> IPv4 host addressing and addressing related problems that IPv6 was
> meant to prevent.

In my rather complex home network, at /120 prefix would be more than enough
to number all interfaces that need addresses. Even in the next ten years
that is very likely to be true.

Is that a smart way to use the IPv6 address space, no. 

So what this draft does is create a huge mess of the IPv6 address architecture
for very questionable benefits. And those benefits are not even articulated
clearly in the draft.

Adding an extra parameter to a protocol does not in general improve the 
protocol. In fact the opposite is true. Having a fixed boudary at 64 bits 
makes the system easy to explain and easy to troubleshoot. No need to
waste extra cycles in trying to find out what crazy router announced a 
crazy prefix length.

Of course the actual value '64' is derived from modified EUI-64 and with
pseudo random IIDs we can just as well pick another value. But each bit we
drop from the IID increases the chances of a collision. Address collisions
are hard enough to deal with that you want to design for zero collisions,
even in extremely big networks. 

Writing an RFC that requires implementations to support every possible
IID length, even the ones that don't work in practice will only lead to
extra confusion and the need for a new BCP that will tell operators how far
they can go.

---

From: Mark Smith <[email-masked]>
Date: Wed, 7 Jun 2017 09:10:08 +1000

> that is very likely to be true.

I wouldn't want to be so sure about that. That's assuming 1:1
host:address, and we have a BCP saying not to make that assumption.

Host Address Availability Recommendations
https://tools.ietf.org/html/rfc7934