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

From: Mark Smith <[email-masked]>
Date: Tue, 6 Jun 2017 14:40:43 +1000

On 6 June 2017 at 11:22, Brian E Carpenter <[email-masked]> wrote:
> On 05/06/2017 21:53, Alexandre Petrescu wrote:
>> Le 04/06/2017 à 13:05, Philip Homburg a écrit :
>> [...]
>>> Moving on to a network architecture point of view, when using pseudo
>>>  random IIDs there will be a longest prefix that can be supported.
>>> Lets say for the sake of argument we can support of /96.
>>>
>>> Then the effect will be that if in the future hosts support SLAAC
>>> upto /96 then we are back at the same hard limit. We have just moved
>>>  be boundary by 32 bits.
>>
>> Similar worries were expressed.
>>
>> However, as I read this draft it does not propose to substitute new hard
>> limit for old hard limit.  The proposal is leave it at 'n', i.e. a variable.
>>
>> The optimistic evolution of this could be that in some IP-over-foo this
>> variable could be exceptionally /96 and largely over-ridden by a
>> backward compatible /64.
>>
>> Maybe something could be written down that clarifies this is not a
>> proposal to substitute new hard limit for old hard limit.
>
> Alexandre,
>
> I think that is what the draft says. Most of the discussion here has not
> been about what the draft says, but about what operators who don't read
> RFCs anyway might or might not do because they don't understand that IPv6
> isn't IPv4+.

If the goal of this document is to state that the IPv6 prefix length
and IID size is a parameter, then I think the title is incorrect. The
title would be better and more accurate if it was something like "IPv6
prefix length (and IID size) is a parameter not a constant".

One the title of a document is accurate, I've found it easier to
determine what is in and out of scope for the document. With a title
of "IPv6 prefix length (and IID size) is a parameter not a constant",
I think the topics would at least be and be in this sort of order:

* Prefix length and IID size is a parameter

- text and references describing why and where

* The parameter's default value SHOULD be 64 ("SHOULD" per RFC2119)

- text and references describing why, mostly a summary and reference to RFC7421

* Possible consequences and considerations when choosing not to use 64

- privacy, security and operational implications to end-user hosts and
applications
- privacy, security and operational implications to infrastructure
- a specific consideration is the type and scope of reachability of
the address/prefix e.g., ND cache DoS less likely of a concern for a
ULA /64, because it isn't reachable over the Internet, and local
network users have a vested interest in the network being available
- summaries and refs to appropriate RFCs and sections of such as
RFC7707, RFC7721, RFC7421 section 4.

Regards,
Mark.

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 6 Jun 2017 00:13:21 -0500

> prefix length (and IID size) is a parameter not a constant".

This is sort of where I got hung up also.  Section 4 deals mostly with
the IID for SLAAC, but this didn't seem to match the introduction:

   ... varied lengths, e.g.  /127, /126, /124, /120, ...  /64 have been
   successfully deployed for many years, glaring mismatches between a
   formal specification and long-standing field deployment practices are
   never wise, not least because of the strong risk of mis-
   implementation, which can easily result in serious operational
   problems.

So to me, that wasn't a problem statement this draft addresses.  Would
it be appropriate to rework this to something on the order of "/127, /126, 
/124, /120, ...  /64 have been successfully deployed for many years and 
this draft seeks to clarify that the IID parameter in SLAAC would 
applicable to these deployments."  

> - text and references describing why and where

In section 2, I-D.jinmei-6man-prefix-clarify is mentioned, but is rfc5942
not clear enough on this front?  Particularly its section 5 deals with
an implementation making assumptions about /64.

Section 3, 
   Additionally, this document clarifies that a node or router MUST
   support routing of any valid network prefix length, even if SLAAC or
   other standards are in use, because routing could choose to
   differentiate at a different granularity than is used by any such
   automated link local address configuration tools.

This isn't really clear to me, is this in reference to the nodes routing
table, or is this about different Prefix Information options in RA's
that are at different granularity?

Section 5,
I had heard anecdotally that one enterprise had specifically chosen to
deploy their datacenter networks with /65 subnets specifically as an
approach to disable "all the automatic stuff" (nobody told them about
link-local I guess).  I do not know if that was actually deployed, but 
I would be pretty curious if there are in fact intentionally short 
prefixes deployed that would cause surprises if SLAAC, etc started 
working one day.
 
Dale

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Jun 2017 14:15:01 +0900

On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith <[email-masked]> wrote:

> I think the topics would at least be and be in this sort of order
>

I think you forgot that if you want to run non-64-bit IIDs on any
currently-defined link type you need to deprecate all the IPv6-over-foo
documents. Remember, Job's original motivation for this draft was "I want
to assign a /123 in my network", and that is not just a violation of RFC
4291, it's a violation of RFC 2464 as well.

To be clear, I still think this document is a bad idea. I still see no
reason for us to do this, and lots of reasons why we shouldn't.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Jun 2017 14:42:28 +0900

> * 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.

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 6 Jun 2017 08:36:04 +0200

On Tue, Jun 6, 2017 at 7:42 AM, Lorenzo Colitti <[email-masked]> wrote:
> that an implementation that is compliant with IETF best practices can simply
> not work when the value is not 64.
>
> 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".

-- 

Roger Jorgensen
[email-masked] / [email-masked]

---

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

> link-local using /64. Two different address "types".

I have absolutely no problems with manual configuration by the device
operator. If that's all we're talking about here, then let's write that up
and publish it.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Jun 2017 11:27:09 +0200

Le 06/06/2017 à 07:15, Lorenzo Colitti a écrit :
> On Tue, Jun 6, 2017 at 1:40 PM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> documents.

YEs, but IP-over-USBnet is not defined, so it's easy to write a draft 
for it about IID len == 63 on a smartphone.

Alex

> Remember, Job's original motivation for this draft was "I
> want to assign a /123 in my network", and that is not just a violation
> of RFC 4291, it's a violation of RFC 2464 as well.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:34:01 +1200

>> On 05/06/2017 21:53, Alexandre Petrescu wrote:
...
> prefix length (and IID size) is a parameter not a constant".

Certainly BCP198 already establishes that IPv6 routing is classless.
To that extent I agree with you. But, like it or not, there's another
message: SLAAC is not compulsory. ILNP is not compulsory. DHCPv6
is not compulsory. AERO is not compulsory. And so on. So although
the main focus is on "/64 is not magic", there is a bit more than that.

However, point taken.

   Brian

> .

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:49:05 +1200

> 4291, it's a violation of RFC 2464 as well.

I think his implied goal is "I want to assign a /123 in my network
and not run SLAAC" 

It's not something I'd want to do, since running SLAAC is so much easier,
but it doesn't seem like the end of the world to me. The hosts will
still have globally routable /128s.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 08:59:47 +1200

> simply not work when the value is not 64.

On this, I tend to agree with Lorenzo. The ipv6-over-foo document needs
to say that the IID length MUST be N (and for all existing foo, N=64).
Otherwise, we can't guarantee out-of-the-box interoperability of
foo interfaces. 

But I want the architectural statement to be that every ipv6-over-foo
document MUST specify N and that the RECOMMENDED value of N is 64.

That covers SLAAC. What the current draft also recognises is that other
addressing schemes (ILNP etc) also need to define N. But we need to
put the definition of N where it belongs, which is in those documents
defining addressing schemes.

Frankly I'd rather we say all that in 4291bis than in a separate draft.
But since 4291bis floundered, there's a separate draft.

> suffer from the reduced functionality and decreased efficiency that that

Again, I actually agree to the extent that it should be NOT RECOMMENDED.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Tue, 6 Jun 2017 14:07:24 -0700

On Jun 5, 2017, at 22:15, Lorenzo Colitti <[email-masked]> wrote:
> 
> Remember, Job's original motivation for this draft was "I want to assign a /123 in my network", and that is not just a violation of RFC 4291, it's a violation of RFC 2464 as well.

I don’t know Job’s original motivation, but the phrase “serious operational problems” does appear near the end of §1 Introduction, although it doesn’t describe what those problems may or may not be. It would be helpful to have a more explanatory problem statement.

The authors also conclude the introduction with this:

>> This document also clarifies that IPv6 routing subnets may be of any length up to 128.

I’d like to assume that s/subnets/prefixes/ should be applied here, but that’s kinda funny because there is no real controversy here or anywhere else that I can see over the question of what the IPv6 standards say about the lengths of routing prefixes, including the on-link routing prefixes used in Neighbor Discovery. The controversy in the context of I-D.ietf-6man-rfc4291bis was entirely about clarifying what the standard says about the lengths of subnet prefixes for address assignment, and not anything to do with routing.

Until this draft is revised to clear up the confusion between on-link routing prefixes and address assignment “subnet” prefixes, I’m not sure what the original motivation for this draft could be. It’s curious that the draft explicitly cites and recommends reviewing I-D.jinmei-6man-prefix-clarify, then it proceeds to disregard completely the carefully drawn distinction and clarification that document was written to provide. I really don’t know what to make of that.

--james woodyatt <[email-masked]>

---

From: David Farmer <[email-masked]>
Date: Tue, 6 Jun 2017 17:14:40 -0500

> defining addressing schemes.

I'd be fine with this except for we need something for manual (AKA static)
configuration, as distinguished from SLAAC or other automatic addressing
schemes you are talking about above.  I'll note, all implementations of
IPv6 that I'm aware of that allow manual configuration of the address, also
allow any prefix length to be specified manually.  If no prefix length is
specified I believe many default to /64.

I'd also be fine with something like; the manual configuration of prefix
lengths other than /64, or /127 for point-to-point router links [RFC6164],
is NOT RECOMMENDED.  But that still leaves room for consenting adults to
manually configure other prefix lengths when they have a specific reasons
to do so, which I also think is one of the goals of this draft.

I believe there are some implementations of IPv6 that don't allow manual
configuration, but I don't believe manual configuration is a required IPv6
feature, so that isn't a problem.

> But since 4291bis floundered, there's a separate draft.

+1, but maybe we can find some consensus through this draft, and not bother
to advance it to RFC and just return to work on 4291bis and advance it.

> Again, I actually agree to the extent that it should be NOT RECOMMENDED.

+1

-- 
===============================================
David Farmer               Email:[email-masked]
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
===============================================