Subject: Where's the limit on the Robustness Principle? (Re: SLAAC on non-/64 networks)

From: Mark Smith <[email-masked]>
Date: Fri, 23 Mar 2018 06:59:44 +1100

On 23 March 2018 at 03:55, Lorenzo Colitti <[email-masked]> wrote:
> On Thu, Mar 22, 2018 at 4:48 PM, Fernando Gont <[email-masked]>
> wrote:
>>
>> > I'm not very clear why we can't find consensus wording on this, since
>> > istm we are all after the same result: ISPs hand out >=64, SLAAC
>> > continues to work, and sites have flexibility when they need it.
>>
>> That's exacty my take, and why the situation puzzles me.
>
>
> I don't think there is lack of consensus over what the desired result is.
>
> I think the lack of consensus is a) over what will happen if we remove this
> limitation, and b) whether that outcome is more desirable or less desirable
> than the situation we are in now.
>

+1

/64 is very established. However, if it was changed to something
similarly fixed but longer e.g. /80, to overcome the issue of sites
only being given a /64, then I'd be willing to accept it.

Of course, the trouble is, the same argument could then be made about
a /80 boundary, repeatedly for longer boundaries, until /128 is
reached. I think those arguing for removing the boundary are validly
taking it the conclusion that there shouldn't be a boundary if any
boundary re-creates the problem.

I see this in the context of Jon Postel's Robustness principle, "being
liberal in what you accept", and trying to work with it. If somebody
gets only a single /64 for a multi-link site, then try to make it
work, by splitting the /64 up further. If the /64 can provide enough
addresses to number all of the site's links, and give hosts as many
addresses as they need, then the single /64 was enough, although not
ideal (because it is contrary to the recommendations and many RFCs).

The thing I've realised as that at some point, "being liberal in what
you accept", and trying to work with it, gets to the point where the
service starts to degrade, and then degrade significantly, and at some
point you end up doing the end user a disservice by trying persisting
with trying to make it work. It would be better to have an absolute
hard failure at or near that point, indicating some unacceptable
condition has occurred (i.e. which we call a fault), rather than
persist with a degraded service that isn't really satisfying the
end-user's requirements.

In this discussion, I think that fault point is encountered at least when IPv6:

- privacy and temporary IPv6 addresses have lost their security
properties, or worse,

- hosts can't get as many addresses as they'd need, contrary to
BCP204/RFC7934, or worse,

- most or all hosts at the site can only have one address, or worse,

- an IPv6 address has to be shared between many hosts.

At any of those thresholds, the IPv6 service has devolved to being not
much or no better than IPv4's, and that makes IPv6 have no value - the
end-user may has well have continued to use IPv4. They're not a fault
condition in IPv4 (although some used to be), however they should be
considered so in IPv6.

I see removing the /64 prefix-size/64 bit IID boundary, and making it
entirely arbitrary, to be making all of the above degraded threshold
points entirely legitimate. Advice not to do them is no more than
advice that can be easily ignored, if the standards don't effectively
prevent them and actually indirectly legitimise them.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>