Subject: Objection to draft-ietf-6man-rfc4291bis-07.txt

From: Peter Hessler <[email-masked]>
Date: Thu, 23 Feb 2017 14:40:26 +0100

Restricting all subnets to The One True Size(tm) of /64 is utterly
ridiculous.  Sure, that may be an artificial limitation of SLAAC and
various other technologies, but *those* can have limitations.

Limiting it inside the entire specification is even stupider of an idea
than still supporting Classful networks.

As an implementation, OpenBSD will never add such a crazy thing.  And
you know that many other implementations won't do so either.

I strongly oppose this draft.

-- 
Numeric stability is probably not all that important when you're guessing.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 23:14:35 +0900

> I strongly oppose this draft.

Bit late to object to that text now I'm afraid.

A good time to object would have been 19 years ago when the text you object
to became the standard:

4291bis-07 (currently under discussion):

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
   on inter-router point-to-point links.  However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long.  The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]

RFC 4291 (February 2006):

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

RFC 3513 (April 2003):

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

RFC 2373 (July 1998):

   In a number of the format prefixes (see section 2.4) Interface IDs
   are required to be 64 bits long and to be constructed in IEEE EUI-64
   format [EUI64].

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Feb 2017 15:36:02 +0100

> Bit late to object to that text now I'm afraid.

You are overstepping, Peter's message is submitted well within the
proper time window:

	The IESG has received a request from the IPv6 Maintenance WG (6man) to
	consider the following document:
	- 'IP Version 6 Addressing Architecture'
	  <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard

	The IESG plans to make a decision in the next few weeks, and solicits
	final comments on this action. Please send substantive comments to the
	[email-masked] mailing lists by 2017-03-01. Exceptionally, comments may be
	sent to [email-masked] instead. 

> A good time to object would have been 19 years ago when the text you
> object to became the standard:

You realise that new people are born every day, and not everyone who
participates in IETF is 50+ years old? Even I were not of legal age 19
years ago.

Your comment borders on the verge of discrimation based on age. This
violates the fundamentals on which we work together to standardise
technologies.

Comments which imply "you should've been there" are both demeaning
and derogatory to operators who come to IETF to improve the current
state of affairs.

Kind regards,

Job

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Feb 2017 23:46:45 +0900

> and derogatory to operators who come to IETF to improve the current

My intention was not to imply anything of the sort. I apologize if that was
how it was received. FWIW I wasn't there when the standard was written,
either.

My point was a purely technical one: this is not new text or a new
proposal. It is the current text of the standard, and has been the current
text of the standard for almost 20 years. Opposing this document will
prevent this document from becoming a standard, but it won't prevent that
text from becoming a standard because it is *already* the standard.

---

From: Peter Hessler <[email-masked]>
Date: Thu, 23 Feb 2017 15:47:25 +0100

On 2017 Feb 23 (Thu) at 23:14:35 +0900 (+0900), Lorenzo Colitti wrote:
:On Thu, Feb 23, 2017 at 10:40 PM, Peter Hessler <[email-masked]> wrote:
:
:> As an implementation, OpenBSD will never add such a crazy thing.  And
:> you know that many other implementations won't do so either.
:>
:> I strongly oppose this draft.
:>
:
:Bit late to object to that text now I'm afraid.
:
:A good time to object would have been 19 years ago when the text you object
:to became the standard:

So, it's my fault that I wasn't participating 19 years ago?  Really?

If it's too late to object to the text, why did you change it?

:4291bis-07 (currently under discussion):
:
:   IPv6 unicast routing is based on prefixes of any valid length up to
:   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
:   on inter-router point-to-point links.  However, the Interface ID of
:   all unicast addresses, except those that start with the binary value
:   000, is required to be 64 bits long.  The rationale for the 64 bit
:   boundary in IPv6 addresses can be found in [RFC7421]
:
:RFC 4291 (February 2006):
:
:   For all unicast addresses, except those that start with binary value
:   000, Interface IDs are required to be 64 bits long and to be
:   constructed in Modified EUI-64 format.

-- 
This life is a test.  It is only a test.  Had this been an actual life,
you would have received further instructions as to what to do and where
to go.

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 23 Feb 2017 16:07:47 +0100

> Le 23 févr. 2017 à 15:14, Lorenzo Colitti <[email-masked]> a écrit :
> 
> On Thu, Feb 23, 2017 at 10:40 PM, Peter Hessler <[email-masked] <mailto:[email-masked]>> wrote:
> A good time to object would have been 19 years ago when the text you object to became the standard:
> 

The 000 rule is not implemented anywhere. 
How could that become part of the full standard if there is not a single implementation ?
But I would be curious to see someone try to upstream that in Linux.

- Pierre

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 23 Feb 2017 17:27:56 +0100

I agree with the objection.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Feb 2017 08:44:52 +1300

> Bit late to object to that text now I'm afraid.

Nonsense. The exactly correct time to object is when a document is being
Last Called for Internet Standard status. Until this point in time, IPv6
has only been a Proposed Standard.

Actually it has been very educational for me - not in my understanding
of how IPv6 works, but in showing how badly this particular aspect has been
documented for the last 20 years. Mainly, we've had too many words in the
addressing architecture. I expect the next version to have fewer words
on this topic.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Feb 2017 20:15:29 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> addressing architecture. I expect the next version to have fewer words

The fix should be straightforward enough. For one thing, all of the arguments which depended on EUI-64 are deprecated. In RFC 4291, for instance,

   The text representation of IPv6 address prefixes is similar to the
   way IPv4 address prefixes are written in Classless Inter-Domain
   Routing (CIDR) notation [CIDR].  An IPv6 address prefix is
   represented by the notation:

      ipv6-address/prefix-length

   where

      ipv6-address    is an IPv6 address in any of the notations listed
                      in Section 2.2.

      prefix-length   is a decimal value specifying how many of the
                      leftmost contiguous bits of the address comprise
                      the prefix.

Nothing more is needed in this text, but if people insist, we might add, "prefix length may be any value, including values greater than or less than 64 bits."

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

This should be reworded to reflect reality.

[NEW]

   Global Unicast addresses in the 2000::/3 space are currently
   constrained to 64-bit interface ID field (i.e., n + m = 64),
   formatted as described in Section 2.5.1. Other examples of
   global scope unicast 64-bit interface ID are SLAAC, ULA, ...

This leaves the possibility of future changes even to this rule in 2000::/3.

DHCPv6 and static configuration seem the logical ways of assigning arbitrary length prefixes.

Bert

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Feb 2017 07:28:26 +1100

On 24 Feb. 2017 06:45, "Brian E Carpenter" <[email-masked]> wrote:

I think another issue is that people with an IPv4 only background may
expect that IPv6 is just IPv4 with bigger addresses. They then find
many other new things, and, as they're not aware that many if not all
of these things were used and deployed in other layer 3 protocols such
as IPX, CLNS and Appletalk, think there is too much change and too
many untested capabilities.

IPv4 was primarily designed and developed in the 1970s. Protocols like
XNS/IPX/CLNS and Appletalk were designed and widely deployed in the
1980s and 1990s (e.g., Appletalk v1 in 1985). IPv6 was designed in the
mid 1990s, and I think it has taken ideas from all of these ancestor
and popular at the time protocols. I think about the only thing that
is really new in IPv6 is the idea of using different multicast groups
based on portions of the IID for neighbor discovery messages - even
then Appletalk uses multicast for that function, however it was just a
single group.

So perhaps one of the barriers we're pushing up against is the
perception that there look to be far to many new things in IPv6 (i.e.,
it's not just IPv4 with bigger addresses), even though they're only
really new if your reference is just IPv4.

Regards,
Mark.

---

From: Iván Arce <[email-masked]>
Date: Thu, 23 Feb 2017 17:37:07 -0300

> object to became the standard:

    "The Last Call is intended as a final check with the IETF community
     to make sure that no important concerns have been missed or
     misunderstood.

     The IESG review takes into account comments received during the
     Last Call.  Once Last Call has been completed, the IESG will
     deliberate whether to accept the document on the standards
     track."

     https://www.ietf.org/iesg/standards-role.html

Seems you are attributing to yourself an authoritative opinion that you
don't have. Maybe you thought posting a lot allows you to dictate things.

I find your reiterative trolling about _form_ rather than _substance_
out of place and out of touch with reality.

To be clear: it is false that your point was purely technical. Your
point was purely procedural, about IETF procedures not about the actual
technical matter being discussed. And it was also wrong.

Besides, if IETF participants are not supposed to object to technical
spec at Last Call, BEFORE they become Internet Standards, then when
should they do it?

-ivan

-- 
Iván Arce
Director del Programa STIC
Fundación Dr. Manuel Sadosky
http://www.fundacionsadosky.org.ar
TE: (+54-11) 4328-5164
GPG fingerprint: 4D97 3003 76C9 9DA4 7209  7982 0A1D 10BE CEA9 1B6E

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Feb 2017 20:41:09 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith

> many untested capabilities.

Perhaps, and yet "the community" has determined that embedding MAC addresses in layer 3 addresses is a bad idea. No one is championing IPX these days. I do agree with the sentiment about too many changes, by the way.

IPv6 nets need to be capable of expanding at the EDGES. This reflects my reality. If this is not allowed, the simple conclusion is that NAT66 is going to be used extensively. We have solved this problem before!

Bert

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Feb 2017 21:44:38 +0100

On Fri, Feb 24, 2017 at 07:28:26AM +1100, Mark Smith wrote:
> > Nonsense. The exactly correct time to object is when a document is
> > being Last Called for Internet Standard status. Until this point in
> > time, IPv6 has only been a Proposed Standard.
> 
> > Actually it has been very educational for me - not in my
> > understanding of how IPv6 works, but in showing how badly this
> > particular aspect has been documented for the last 20 years. Mainly,
> > we've had too many words in the addressing architecture. I expect
> > the next version to have fewer words on this topic.
> 

This is called a "straw man argument". You construct this nonsensical
non-existent "IPv4 only person" and then making ridiculous assertions
about this "ignorant ipv4 person".

This type of argument is often used in polemical debate, particularly in
arguments about highly charged emotional issues, where the defeat of
"ipv4 people" may be more valued than critical thinking or understanding
both sides of the issue.

> then Appletalk uses multicast for that function, however it was just a

Thank you for this lesson in history, but I assure you that many of us
are intimately familiar with IPv6. 

> really new if your reference is just IPv4.

Can you please tone down the fanboyism a bit? Not only are you repeating
yourself, but in repeating the IPv6 evangelism you are not contributing
anything of substance to this technical dialogue.

The topic of discussion is not whether IPv6 differs from IPv4 or how it
differs from IPv6. Strictly speaking IPv4 has _nothing_ to do with this
discussion.

Kind regards,

Job

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Feb 2017 08:01:53 +1100

What do you know about IPX?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Feb 2017 21:48:54 +0000

> addressing architecture. I expect the next version to have fewer words

looking at it from a slightly different angle, we've had 20 years where
the protocol has achieved some degree of acceptance, so it may be a good
idea to consider the merits of aligning theory with practice.  The /64
interface limitation is a prime example of something that ought to be
revisited.

Nick

---

From: james woodyatt <[email-masked]>
Date: Thu, 23 Feb 2017 13:57:32 -0800

On Feb 23, 2017, at 05:40, Peter Hessler <[email-masked]> wrote:
> […]

It would help if those objecting to the promotion of RFC 4291 to Standard, unless the requirement for subnet prefixes to be generally /64 (except where noted by standards track documents), would please remember that SLAAC is only one of several technologies dependent on it. That’s why this draft now includes a reference to RFC 7421, which lists a non-exhaustive list of several things that are broken on subnets where prefixes longer than /64 are used.

My counter to these objections should be regarded from an overview perspective.

IPv6 is about more than just routers and the few thousands of network operators who love them. It’s also about hosts, their application software and the billions of ordinary people who use them.

Many of those Proposed Standard protocols listed in RFC 7421 (and a few others that were overlooked in that document, but which are nevertheless important) may not seem strictly necessary to the operator community bringing these objections, but they are necessary to make host applications provide user experiences on which billions of people depend. Insisting that RFC 4291 drop this requirement to be published as a full Standard is tantamount to insisting that IPv6 itself not be required to meet the needs of billions of humans around the world because Classful Networks make a few thousand network operators have a sad.

Needs of the many. Needs of the few. Seems like an obvious balancing problem to me.

--james woodyatt <[email-masked]>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Feb 2017 22:37:29 +0000

> Needs of the many. Needs of the few. Seems like an obvious balancing problem to me.

If you feel that network interfaces longer than /64 shouldn't be used,
then please feel free to add text to this ID which reassigns rfc6164 to
historical.  If you don't want to do this or feel that it wouldn't gain
consensus, then please don't propose renewing a specification which
explicitly contradicts another standards track document which is in
widescale current production use.

As withering aphorisms seem to be the order of the day, either have your
cake or eat your cake.

Nick

---

From: james woodyatt <[email-masked]>
Date: Thu, 23 Feb 2017 14:50:18 -0800

On Feb 23, 2017, at 14:37, Nick Hilliard <[email-masked]> wrote:
> historical.  […]

Hmm, since RFC 6164 is a Standards Track document, it’s already covered as a legitimate exception under the text I already proposed, which seemed mostly well received, except by people who seem to think it’s not enough to recognize standard IETF exceptions to the /64 subnet prefix requirement.

Some participants seem to be promising they will continue objecting to the promotion of RFC 4291 to full Standard until the /64 subnet prefix length requirement is dropped entirely. I think those objections should not block the advancement of this draft.

> As withering aphorisms seem to be the order of the day, either have your

Shorter james: have some cake.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 23 Feb 2017 23:10:19 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of james woodyatt

> Some participants seem to be promising they will continue objecting to the
> promotion of RFC 4291 to full Standard until the /64 subnet prefix length
> requirement is dropped entirely.

Dropped entirely except for the 2000::/3 space, and the handful of other exceptions. Yes.

I'm still reading the propaganda in the popular press, about how huge the 128-bit address space is. It could be huge, but only if it's done right. Half of it, in effect, is out the window.

Bert

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Feb 2017 23:38:18 +0000

james woodyatt wrote:
> Hmm, since RFC 6164 is a Standards Track document, it’s already
> covered as a legitimate exception under the text I already proposed,
> which seemed mostly well received, except by people who seem to think
> it’s not enough to recognize standard IETF exceptions to the /64
> subnet prefix requirement.

What's your advice to vendors then?  To disable all interface netmasks
except /64 and /127?  Or to operators?  Are you really suggesting that
"thou shalt use only prescribed netmasks on your interfaces" is a viable
proposition?

This is not an idle question, btw.  Putting text into standards track
rfcs creates an expectation that the text will be built in production
code to be deployed on production networks.  What you're proposing is
straight-up Section 1 of rfc 6919.

This horse bolted 20 years ago and the shed door is long rotted.
Everyone understands that there are several situations where /64 is
mandatory, but it's terribly silly for the IETF to pretend that anyone
is going to pay the slightest attention to a requirement of this form.
They won't: vendors won't and operators won't, so we need to stop
pretending that this is a useful approach on this point.

> Some participants seem to be promising they will continue objecting
> to the promotion of RFC 4291 to full Standard until the /64 subnet
> prefix length requirement is dropped entirely. I think those
> objections should not block the advancement of this draft.

We'll need to disagree then.

Nick

---

From: james woodyatt <[email-masked]>
Date: Thu, 23 Feb 2017 16:05:57 -0800

On Feb 23, 2017, at 15:38, Nick Hilliard <[email-masked]> wrote:
> except /64 and /127?  Or to operators?

I am aware of at least one major vendor, whose devices in the field number well into the billions, devices that simply do not accept any subnet prefix other than /64. Seems to work fine for them because none of their devices are intended to be deployed in any of the standard scenarios where prefixes other than /64 are recommended by IETF.

My advice to vendors is pretty simple.

	1. Always support /64 subnets in general usage scenarios.
	2. Assume misconfiguration in general usage scenarios where subnets are not /64.
	3. Support /127 subnets if your device will be deployed under RFC 6164.
	4. Support any other standards as necessary, where limitations caused by non-/64 subnet prefixes are acceptable.

The text I proposed would allow vendors of host operating system the necessary cover to follow that advice. Dropping the requirement would mean my advice would have to change.

	1. Always prefer /64 subnets where available.
	2. Accept limitations entailed by necessity of accepting non-/64 subnets.
	3. Drop all features that depend on always receiving a /64 subnet.

Some of those features are pretty important to me, so that’s why I’m engaged in this debate.

> Are you really suggesting that "thou shalt use only prescribed netmasks on your interfaces" is a viable proposition? […]

In general usage scenarios? Yes. I am. I have a device in my pocket that does exactly that. Everyone in my family does. Those devices would not work very well if the /64 subnet requirement were dropped and operators felt free to ignore it, and adapting them to function on subnets with longer prefixes would entail making those devices less functional.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Feb 2017 13:22:18 +1300

James,
> 	2. Assume misconfiguration in general usage scenarios where subnets are not /64.

That is terribly bad advice, but is fortunately ignored by most vendors, who
know what CIDR means.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2017 09:46:24 +0900

> pretending that this is a useful approach on this point.

I think you're only looking at half of the picture. Perhaps router vendors
and router operators won't pay attention to a requirement of this form, and
most haven't - though I will note that there are major router architectures
that have different performance and cost characteristics for /0-/64 and
/65-/127. (Anyone who claims that that is silly because classful addressing
is bad should think about the fact that routing is not magic, but based on
the laws of phisics, and bear in mind that routing on a >/64 prefix takes
twice the memory, and fast memory is very, very expensive.)

But even more importantly - even if router vendors and operators ignore
this requirement, host software and host implementations can rely - and, in
the 20 years since this was standardized, have been written to rely - on
this standard to provide useful functionality to their users.

If we remove the 64-bit boundary we are actually changing the balance
between the needs of network operators and host operators (a.k.a "users").
That's a big change, and it's not something we should do just because
"classful addressing is bad". I don't want a future where my ISP gives my
home network or my mobile device a /120 and I have to count myself lucky
because it's better than having a single IPv4 address.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Feb 2017 22:19:24 -0500

picking out one messge, not particularly picking ON one message...

On Thu, Feb 23, 2017 at 4:57 PM, james woodyatt <[email-masked]> wrote:

> It would help if those objecting to the promotion of RFC 4291 to Standard,
> unless the requirement for subnet prefixes to be generally /64 (except
> where noted by standards track documents), would please remember that SLAAC
> is only one of several technologies dependent on it. That’s why this draft
> now includes a reference to RFC 7421, which lists a non-exhaustive list of
> several things that are broken on subnets where prefixes longer than /64
> are used.
>
>
there seems to be a general sense, in reading the many threads now about
this -bis draft, that we can only have one way. In the proposed changed
text, ~150 messages back and 2 threads over, there was the callout for
applications which require 64bit subnet masks ALONG with "if you really
know what you are doing, feel free to use a different subnet mask".

I feel like folk are stuck in the 1 or the other camp, and that isn't
helpful to this discussion.

Why can't we have both?

As  to age of text and other things, I look at this -bis and the review
here as the final step to making 'ipv6' a real standard and not a 'proposed
standard' correct? So before we stamp things 'DONE' making sure all eyes
are dotted and tees are crossed surely seems sane and rational.

-chris

---

From: <[email-masked]>
Date: Fri, 24 Feb 2017 07:29:49 +0000

Hi Brian, 

I really hope we will have few words on this topic. 

Pointing to RFC7608 as a general assumption + another one to RFC7421 to clarify that 64 is only a parameter in some schemes would be enough, IMO. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : jeudi 23 février 2017 20:45
> À : Lorenzo Colitti; Peter Hessler
> Cc : IETF IPv6 Mailing List
> Objet : Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
>

---

From: Peter Hessler <[email-masked]>
Date: Fri, 24 Feb 2017 09:22:23 +0100

On 2017 Feb 23 (Thu) at 22:19:24 -0500 (-0500), Christopher Morrow wrote:
:picking out one messge, not particularly picking ON one message...
:
:On Thu, Feb 23, 2017 at 4:57 PM, james woodyatt <[email-masked]> wrote:
:
:> On Feb 23, 2017, at 05:40, Peter Hessler <[email-masked]> wrote:
:> >
:> > Restricting all subnets to The One True Size(tm) of /64 is utterly
:> > ridiculous.  Sure, that may be an artificial limitation of SLAAC and
:> > various other technologies, but *those* can have limitations.
:> >
:> > Limiting it inside the entire specification is even stupider of an idea
:> > than still supporting Classful networks.
:> > […]
:>
:> It would help if those objecting to the promotion of RFC 4291 to Standard,
:> unless the requirement for subnet prefixes to be generally /64 (except
:> where noted by standards track documents), would please remember that SLAAC
:> is only one of several technologies dependent on it. That’s why this draft
:> now includes a reference to RFC 7421, which lists a non-exhaustive list of
:> several things that are broken on subnets where prefixes longer than /64
:> are used.
:>
:>
:there seems to be a general sense, in reading the many threads now about
:this -bis draft, that we can only have one way. In the proposed changed
:text, ~150 messages back and 2 threads over, there was the callout for
:applications which require 64bit subnet masks ALONG with "if you really
:know what you are doing, feel free to use a different subnet mask".
:
:I feel like folk are stuck in the 1 or the other camp, and that isn't
:helpful to this discussion.
:
:Why can't we have both?
:

I would be perfectly happy if the _IPv6 Protocol_ itself did not have
any limitations on subnet sizes, but if SLAAC and other protocols had
limitations.

Those limitations can be described in other documents, and won't block
other usage.

:As  to age of text and other things, I look at this -bis and the review
:here as the final step to making 'ipv6' a real standard and not a 'proposed
:standard' correct? So before we stamp things 'DONE' making sure all eyes
:are dotted and tees are crossed surely seems sane and rational.
:
:-chris

-- 
A day for firm decisions!!!!!  Or is it?

---

From: <[email-masked]>
Date: Fri, 24 Feb 2017 09:01:32 +0000

Hi Peter, 

Please see inline. 

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Peter Hessler
> Envoyé : vendredi 24 février 2017 09:22
> À : Christopher Morrow
> Cc : james woodyatt; 6man WG
> any limitations on subnet sizes

[Med] This is BCP198: https://tools.ietf.org/html/bcp198.

" The length of an
   IPv6 prefix may be any number from zero to 128" 

, but if SLAAC and other protocols had
> Those limitations can be described in other documents, and won't block

[Med] This is already documented by Brian et al.: https://tools.ietf.org/html/rfc7421

---

From: Sander Steffann <[email-masked]>
Date: Fri, 24 Feb 2017 10:13:08 +0100

Hi,

> But even more importantly - even if router vendors and operators ignore this requirement, host software and host implementations can rely - and, in the 20 years since this was standardized, have been written to rely - on this standard to provide useful functionality to their users.
> 
> If we remove the 64-bit boundary we are actually changing the balance between the needs of network operators and host operators (a.k.a "users"). That's a big change, and it's not something we should do just because "classful addressing is bad". I don't want a future where my ISP gives my home network or my mobile device a /120 and I have to count myself lucky because it's better than having a single IPv4 address.

This is indeed my greatest fear if we go down that path. It's exactly the reason I'm so torn (as you have seen in my previous messages) on this topic. I want a world where consenting adults can use whatever prefix length they need, but where the standard (read this as meaning both "standards-based" and "default") design still uses /64. As we have seen getting the RFC text right is hard...

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Feb 2017 11:11:50 +0000

james woodyatt wrote:
> In general usage scenarios? Yes. I am. I have a device in my pocket that
> does exactly that. Everyone in my family does. Those devices would not
> work very well if the /64 subnet requirement were dropped and operators
> felt free to ignore it, and adapting them to function on subnets with
> longer prefixes would entail making those devices less functional.

which is fine - mobile devices are important and numerous and good
candidates for the sort of interface that the /64 requirement was trying
to cater for.  But they are by no means the only type of device which
runs ipv6.

Let me be more specific then: are you proposing that vendors write code
to allow or disallow interface subnets which aren't /64 (or /127)? This
is a binary choice; a vendor needs to choose one way or another.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 24 Feb 2017 11:24:46 +0000

> between the needs of network operators and host operators (a.k.a

No, we're not. The /64 requirement will still remain for the config /
deployment scenarios that are important to you. Please stop inventing
things.

Nick

---

From: <[email-masked]>
Date: Fri, 24 Feb 2017 12:24:55 +0000

Exactly, Nick. 

For example, mobile devices will continue to be assigned /64 or even shorter. Operators are voicing for this publically: https://tools.ietf.org/html/rfc7849  

Cheers,
Med

> De : ipv6 [mailto:[email-masked]] De la part de Nick Hilliard
> Envoyé : vendredi 24 février 2017 12:25
> À : Lorenzo Colitti
> Cc : 6man WG

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 15:51:21 +0100

Le 23/02/2017 à 23:50, james woodyatt a écrit :
>> If you feel that network interfaces longer than /64 shouldn't be
>> used, then please feel free to add text to this ID which reassigns
>> rfc6164 to historical.  […]
>

I agree.  Advancement should be pursued.  But dont drop the objections.

Alex

>> As withering aphorisms seem to be the order of the day, either have
>> your cake or eat your cake.
>
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 10:20:22 -0500

>> prefix length requirement is dropped entirely. I think those
I don't think this is the case, at all.

I hear job/randy/nick/stefan/michael all saying: "Hey /64 for SLAAC and the
like is great, but keep in mind I need to be able to configure longer
prefixes.. so don't make /64 (and /127) the ONLY options"

The reasoning for the 'not the only options' text is precisely because
we've all run into vendors that made poor assumptions about ipv6 prefix
lengths over time :( We (or I at least) noted that 'classful' constructs
don't survive long term, so avoiding them where we know they aren't helpful
is a great step forward.

> I agree.  Advancement should be pursued.  But dont drop the objections.

I agree that we need to finalize this standard, but... do want to make sure
I'm not boxed into a corner :)

---

From: james woodyatt <[email-masked]>
Date: Fri, 24 Feb 2017 10:11:03 -0800

> is a binary choice; a vendor needs to choose one way or another.

I don’t know how I can be more clear about this: I insist that general purpose host operating system developers should be expressly permitted to write code that declines to accept subnet prefixes of any length other than /64 on the grounds that these are not used in general IPv6 networking and the successor to RFC 4291 continues to say so.

I know there are operating systems with billions of units in the field today that do exactly this because RFC 4291 and its predecessors have for years given them clear license to do so, and I don’t want to see the publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license as a side effect of promoting IPv6 to full Standard category.

You want to remove that license? I suppose we can continue discussing that, but I think you should try to do it in a separate draft once IPv6 is officially promoted.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 13:18:35 -0500

On Fri, Feb 24, 2017 at 1:11 PM, james woodyatt <[email-masked]> wrote:

> I don’t know how I can be more clear about this: I insist that general
> purpose host operating system developers should be expressly permitted to
> write code that declines to accept subnet prefixes of any length other than
> /64 on the grounds that these are not used in general IPv6 networking and
> the successor to RFC 4291 continues to say so.
>
>
it's totally possible that a 'general purpose host operating system
developer' may get a bug-report / feature-request from a customer in the
future (if they follow the above advice, i mean) that says: "Hey, I need to
configure my widget from foocom with a /96 prefix because 'reasons'" ...
which seems ok to me, the 2 folk can sort out their problem and move along.

that doesn't mean that the proposed text (now 180+ messages back) needs to
change though.
 -chris

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 24 Feb 2017 19:38:38 +0100

> Le 24 févr. 2017 à 19:11, james woodyatt <[email-masked]> a écrit :
> 
> On Feb 24, 2017, at 03:11, Nick Hilliard <[email-masked] <mailto:[email-masked]>> wrote:
>> 

This has nothing to do with RFC4291 and does not require RFC4291 to say anything specific about that.
Support of SLAAC is already mandatory.
Support of stateful DHCP is not mandatory.
Devices that are not supposed to be configured manually can perfectly support SLAAC only over ethernet, and fail in all cases where SLAAC cannot be used. 
This does not need to be specifically allowed by RFC4291.

RFC4291 is applicable to *all* IPv6 devices, not a subset of them. So let's not put in there things that are specific to some use-cases and would be just a pain in other deployments.
There is plenty of literature about the use of /64 in home, enterprise or other specific networks already.

-Pierre

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Feb 2017 12:42:09 -0600

On Fri, Feb 24, 2017 at 12:11 PM, james woodyatt <[email-masked]> wrote:

> I know there are operating systems with billions of units in the field
> today that do exactly this because RFC 4291 and its predecessors have for
> years given them clear license to do so, and I don’t want to see the
> publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license
> as a side effect of promoting IPv6 to full Standard category.
>
> You want to remove that license? I suppose we can continue discussing
> that, but I think you should try to do it in a separate draft once IPv6 is
> officially promoted.
>

I would not want to make code that does /64 only out of compliance with the
spec, especially for SLAAC.  I would like to discourage that stance, maybe
for DHCP, but for sure for manual configuration if that mode is provided.
But, I don't see /64 only as a invalid stance for an host OS to take.  But
neither do I want the spec to disallow non-/64 for DHCP, manual
configuration, or potential new modes of configuration if we ever get
there.  I think SLAAC should to remain /64 only. I think DHCP and manual
configuration should be encourage to support non-/64 options, but even they
should allow /64 only.

thanks

-- 
===============================================
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
===============================================

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 24 Feb 2017 19:10:10 +0000

> as a side effect of promoting IPv6 to full Standard category.

But this is exactly why RFC 4291-bis has to get this right. The unicast address space 2000::/3 is the only one that should be so constrained. We need to nip this problem in the bud.

OSs can be updated, when it becomes necessary.

> You want to remove that license?

Remove that misinterpretation as a GENERAL rule for IPv6? Yes. Prefixes can be of any length, in general, in IPv6.

Bert

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 14:36:23 -0500

sorry, a clarification request below.

On Fri, Feb 24, 2017 at 1:42 PM, David Farmer <[email-masked]> wrote:

> I would not want to make code that does /64 only out of compliance with
> the spec, especially for SLAAC.  I would like to discourage that stance,
> maybe for DHCP, but for sure for manual configuration if that mode is
> provided.  But, I don't see /64 only as a invalid stance for an host OS to
> take.  But neither do I want the spec to disallow non-/64 for DHCP, manual
please restate your last sentence... I think you missed a word or three?

> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Feb 2017 08:48:24 +1300

Bert,
> But this is exactly why RFC 4291-bis has to get this right. The unicast address space 2000::/3 is the only one that should be so constrained. We need to nip this problem in the bud.

I don't think that specific IANA-delegated prefixes belong in this document.
And a few weeks ago I suggested limiting the /64 rule to currently delegated
address space, and was loudly told "No!". What we need to get across
is the notion that this is a parameter, not a constant, and today's
setting of the parameter is 64. I strongly suspect that the document editor
has got that message and will come up with some new text.

    Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Feb 2017 13:51:08 -0600

> please restate your last sentence... I think you missed a word or three?

It's still ok for a host OSes to do /64 only with DHCP and manual config,
not preferred.  I'd prefer host OSes support non-/64 as well for DHCP and
manual config, but not mandatory.  Only /64 should be REQUIRED of anyone,
host, router, or what ever.  Non-/64 should be OPTIONAL for everyone.

Is that clearer?

thanks

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 14:55:19 -0500

> host, router, or what ever.  Non-/64 should be OPTIONAL for everyone.
clearer, but not what I was expecting...

OPTIONAL means 'will not happen without customer loud voices' (generally).
I'm worried that OPTIONAL is going to cause problems :(

---

From: David Farmer <[email-masked]>
Date: Fri, 24 Feb 2017 14:02:11 -0600

> I'm worried that OPTIONAL is going to cause problems :(

I was trying to be conservative in the change to push through the process.
I'd be open to RECOMMENDED, but I don't see REQUIRED as an option, it would
break too much

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Feb 2017 17:18:15 -0300

On 02/24/2017 04:48 PM, Brian E Carpenter wrote:
> setting of the parameter is 64. 

+1

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 25 Feb 2017 11:02:33 +0100

Le 24/02/2017 à 21:02, David Farmer a écrit :
>
>
> On Fri, Feb 24, 2017 at 1:55 PM, Christopher Morrow
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>     On Fri, Feb 24, 2017 at 2:51 PM, David Farmer <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>         On Fri, Feb 24, 2017 at 1:36 PM, Christopher Morrow
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             On Fri, Feb 24, 2017 at 1:42 PM, David Farmer
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>                 On Fri, Feb 24, 2017 at 12:11 PM, james woodyatt
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     On Feb 24, 2017, at 03:11, Nick Hilliard
>                     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>                     I don’t know how I can be more clear about this: I
>                     insist that general purpose host operating system
>                     developers should be expressly permitted to write
>                     code that declines to accept subnet prefixes of any
>                     length other than /64 on the grounds that these are
>                     not used in general IPv6 networking and the
>                     successor to RFC 4291 continues to say so.
>
>                     I know there are operating systems with billions of
>                     units in the field today that do exactly this
>                     because RFC 4291 and its predecessors have for years
>                     given them clear license to do so, and I don’t want
>                     to see the publication of I-D.ietf-6man-rfc4291bis
>                     as RFC come to remove this license as a side effect
>                     of promoting IPv6 to full Standard category.
>
>                     You want to remove that license? I suppose we can
>                     continue discussing that, but I think you should try
>                     to do it in a separate draft once IPv6 is officially
>                     promoted.
>
>                 I would not want to make code that does /64 only out of
>                 compliance with the spec, especially for SLAAC.  I would
>                 like to discourage that stance, maybe for DHCP, but for
>                 sure for manual configuration if that mode is provided.
>                 But, I don't see /64 only as a invalid stance for an
>                 host OS to take.  But neither do I want the spec to
>                 disallow non-/64 for DHCP, manual configuration, or
>                 potential new modes of configuration if we ever get
>                 there.  I think SLAAC should to remain /64 only. I think
>                 DHCP and manual configuration should be encourage to
>                 support non-/64 options, but even they should allow /64
>                 only.
>
>
>         It's still ok for a host OSes to do /64 only with DHCP and
>         manual config, not preferred.  I'd prefer host OSes support
>         non-/64 as well for DHCP and manual config, but not mandatory.
>         Only /64 should be REQUIRED of anyone, host, router, or what
>         ever.  Non-/64 should be OPTIONAL for everyone.
>
>         Is that clearer?
>
>
> I was trying to be conservative in the change to push through the
> process. I'd be open to RECOMMENDED, but I don't see REQUIRED as an
> option, it would break too much

Depending how it reads...

I would agree if I read "/64 was RECOMMENDED in the past".

I would not agree if I read "/64 is NOT RECOMMENDED".

I would not agree if I read "/64 is RECOMMENDED".

Alex

> <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Feb 2017 08:15:25 +1300

On 25/02/2017 23:02, Alexandre Petrescu wrote:
...
> I would agree if I read "/64 was RECOMMENDED in the past".

That would be a lie, since until now it was 'required' in the text.
 
> I would not agree if I read "/64 is NOT RECOMMENDED".

But nobody is suggesting that (in RFC 2119 it is equal to SHOULD NOT).

> I would not agree if I read "/64 is RECOMMENDED".

There I think you are wrong. It is the value that today allows portable
interoperable host software (on IEEE 802.1 or 802.11 media) so it is, in
fact, the only plausible default that we can suggest. 'Recommended' leaves
plenty of space that 'required' does not.

    Brian

---

From: David Farmer <[email-masked]>
Date: Sat, 25 Feb 2017 14:40:40 -0600

> plenty of space that 'required' does not.

So we can't simply say "/64 subnet prefixes are RECOMMENDED" or "64 bit
IIDs are REQUIRED", depending on the context of the discussion it is
actually both.

I think we are trying to say 64 is the default subnet prefix length and IID
length, and should be used most of the time, and other non-64 subnet prefix
lengths and IID lengths can be use when necessary in special cases.
However, 64 can only be an effective default, if every implementation of
IPv6 actually supports it.

Therefore, "/64 subnet prefixes are operationally RECOMMENDED" and "all
implementations of IPv6 are REQUIRED to support 64 bit IIDs".

What Chris and I were discussing is what is the proper statement about
non-64 subnet prefix lengths and IID lengths?  I don't think non-64
lengths can be "REQUIRED" because some implementations of IPv6 only support
64 as the subnet prefix length and IID length.  This is not right or wrong,
it is just a fact we have to live with. So that leaves either "OPTIONAL" or
"RECOMMENDED" for support of non-64 lengths.  I started with "OPTIONAL" but
said I'd consider "RECOMMENDED".

Thinking about this a bit more; I think the non-64 lengths should be
"OPTIONAL for host implementations of IPv6 to support", "RECOMMENDED for
router implementations of IPv6 to support", "operational use of /127 subnet
prefixes for point-to-point router links is RECOMMENDED", and by
implication, but doesn't need to be said explicitly, the operational use of
other non-64 lengths is NOT RECOMMENDED, but not prohibited or limited in
any way either.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Feb 2017 11:22:07 +1300

> other non-64 lengths is NOT RECOMMENDED, but not prohibited or limited in

In the context of *this* thread about the addressing architecture, I don't
think we should say much at all. Most of what you say belongs IMHO in a
separate, and quite short, operational BCP.

   Brian

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Feb 2017 08:27:37 +0800

> has got that message and will come up with some new text.

+1, xing

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Feb 2017 08:28:47 +0800

+1, xing

---

From: Mark Smith <[email-masked]>
Date: Sun, 26 Feb 2017 16:24:43 +1100

On 26 February 2017 at 07:40, David Farmer <[email-masked]> wrote:
>
>
> On Sat, Feb 25, 2017 at 1:15 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>

> prefixes for point-to-point router links is RECOMMENDED",

I don't think /127s should be at a level of RECOMMENDED.

They are a way to mitigate a ND cache attack if your implementation is
vulnerable to one.

They are a way to mitigate a ICMP ping-pong attack, however that
requires the /127 prefix length to be configured on both ends of the
link, and that is not a requirement of the IPv6 protocol - there is no
requirement and no checking that all nodes attached to a link have
addresses from the prefix assigned to the link. A link with a /127 on
one end, and just a LL on the other (as could happen on links between
a service provide and a customer if there isn't configuration
discipline), is vulnerable to a ping-pong attack, yet would not be
obviously failing e.g., still deliver 100% successful Internet access
to that customer.

/127 of course prevent things that /64 can provide. For example, just
like hosts, Internet connected routers would benefit from being
protected from unsolicited inbound address scans by having a random
address within a /64 (you can't launch a TCP syn attack against a BGP
speaking router if you can't find it).

I think a RECOMMENDED and therefore default parameter is the one that
should have the greatest chance of interoperability, is the one that
is likely to provide the best security in the least secure
environment, and the one that is making the least functionality or
capability tradeoffs.

In my mind, /127s make too many tradeoffs to mitigate a couple of
attacks for which it may not be necessary or effective if
configuration is not verified as correct.

I think recommending /127s for point-to-point router links also
creates an implicit and unstated constraint that RFC8064
("Recommendation on Stable IPv6 Interface Identifiers") only applies
to hosts. If that is the actual constraint, it should have been stated
in that RFC, and ideally in the title of it.

People of course can use /127s in their own network if they choose to
and are willing to sacrifice the potential benefits to their routers
of not using /64s, because IPv6 supports it per BCP198.

I think making /127s a default recommendation for point-to-point links
is effectively saying that routers have no need for any of the
benefits hosts get from /64s, and I don't think that is the case.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 26 Feb 2017 19:55:01 +0100

Le 25/02/2017 à 20:15, Brian E Carpenter a écrit :
> On 25/02/2017 23:02, Alexandre Petrescu wrote: ...

I would then agree if I read "/64 was required in the past".

> But nobody is suggesting that (in RFC 2119 it is equal to SHOULD

A few people said that they are afraid that if we say "/64 is NOT
RECOMMENDED" then the cellular operator will only assign one /128 to one
User Terminal.

In a sense I agree with that worry.  Although that would require
operators to use DHCPv6 to assign addresses, and that is rarely the case.

But that worry should be expressed differently.

That worry should be expressed such that it requires operators to assign
a /63, or a /62, or a /61 to User Terminal.

Assigning one /64 to User Terminal is equivalent to assigning one /128
to User Terminal.  So that does not address the worry of being assigned
only one address.

The theory of 2^64 addresses being available in a /64 prefix is broken
compared to the reality of SLAAC-on-Ethernet-on-ptp-links.  This should
be explained to both operators and end users.

> There I think you are wrong.

I think I am wrong depending on what tense we use: is it about the
future or about the past?

When we say "is RECOMMENDED" and it becomes an RFC then that will
effectively be recommended during the next 10 years or so, until next
RFC update.  I fully disagree with this plan.  It will comfort the
cellular operators to continue assigning a single /64 to one User Terminal.

> It is the value that today allows portable interoperable host
> software (on IEEE 802.1 or 802.11 media)

(for 802.1 and 802.11 media - there is much I can say here - basically
IPv6 stacks interface to EthernertII headers, no 802.1 nor 802.11, but
that's another matter; wireshark and RFC2464 show that).

I would like to add that, in addition to the Ethernet I suppose you want
to talk about by saying 802.1 and 802.11, the 64 limit is so only if
SLAAC is there too.

If one uses only Ethernet (no SLAAC) then the 64 is not set in stone.

If one uses only SLAAC (no Ethernet) then the 64 is not set in stone.

If one uses SLAAC-on-Ethernet then 64 is set in stone, and only then.

 From this, to make a general IPv6 Architecture Architecture that says
that 64 is RECOMMENDED default there is a long way.

> so it is, in fact, the only plausible default that we can suggest.
> 'Recommended' leaves plenty of space that 'required' does not.

To me RECOMMENDED and REQUIRED - capitalized or otherwise - both sound
too strong compared to simple ability to leave with 64.

If there was a word that said "CAN LIVE with 64" then I would agree with it.

But why should we suggest a plen there in the first place?

Is it because we want to be compatible to existing implementations?  If
yes then we can say that "in the past the /64 was required", and be
silent about the future.  We can also say that some existing
implementations break other standards when they want to be compatible
with a _supposed_ 64 requirement (as we both discovered with this netsh
command).

Is it because we are afraid of cellular operator assigning only one
address?  If yes know that assigning one /64 is no different than
assigning a /128 as long as SLAAC-on-Ethernet is used on ptp links.

We can also describe what breaks on some implementations which:
(1) route a /120 to a subnet where a /64 is used
(2) locally self-configure /64 prefixes when nobody asks to

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Feb 2017 08:24:52 +1300

Aelexandre,
On 27/02/2017 07:55, Alexandre Petrescu wrote:
... 
> that 64 is RECOMMENDED default there is a long way.

You didn't pay attention to my phrase "portable interoperable host software".

I carry my laptop and my Android phone around quite a lot. I want them
to just work when they find themselves on a new IPv6 network. Given that
we never put in place dynamic parameterisation of the 802.1/802.11 IID
length, that's only possible because the various software writers involved
over the years all implemented /64. End of message.
 
   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 27 Feb 2017 11:22:44 +0100

Le 26/02/2017 à 20:24, Brian E Carpenter a écrit :
> Aelexandre, On 27/02/2017 07:55, Alexandre Petrescu wrote: ...
>> effectively be recommended during the next 10 years or so, until
>> next RFC update.  I fully disagree with this plan.  It will
>> comfort the cellular operators to continue assigning a single /64
>> to one User Terminal.
>>
>> (for 802.1 and 802.11 media - there is much I can say here -
>> basically IPv6 stacks interface to EthernertII headers, no 802.1
>> nor 802.11, but that's another matter; wireshark and RFC2464 show
>> that).
>>
>> I would like to add that, in addition to the Ethernet I suppose
>> you want to talk about by saying 802.1 and 802.11, the 64 limit is
>> so only if SLAAC is there too.
>>
>> From this, to make a general IPv6 Architecture Architecture that
>> says that 64 is RECOMMENDED default there is a long way.
>
> I carry my laptop and my Android phone around quite a lot. I want
> them to just work when they find themselves on a new IPv6 network.
> Given that we never put in place dynamic parameterisation of the
> 802.1/802.11 IID length, that's only possible because the various
> software writers involved over the years all implemented /64. End of
> message.

I see.

We want the laptop and android to continue work that way - it is good.
But could they just rely on RFC2464?  Isn't the IPv6 Addressing
Architecture too high a promotion for just that case?

IMHO maybe we are trying to improve an earlier 4291 paragraph whose
initial intention may have been good, but is not consensual.  That par
is "All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field".

There are additional messages that circulated in private, and that have
not been posted publicly, about the validity of an "Interface ID"
altogether.  What's the meaning of an Interface Identifier when one can
have same IID on different interfaces?

Or is the laptop/android use-case actually needing a "Host
Identifier" (not an IID)?

Has the option of removing this 4291 paragraph altogether been
considered (instead of improving it)?

Alex

---

From: Mark Smith <[email-masked]>
Date: Tue, 28 Feb 2017 18:41:14 +1100

On 27 Feb. 2017 21:23, "Alexandre Petrescu" <[email-masked]>
wrote:

I see.

IMHO maybe we are trying to improve an earlier 4291 paragraph whose
initial intention may have been good, but is not consensual.

Just to be clear, consensus doesn't mean unanimous.

https://tools.ietf.org/html/rfc7282

That par

Answered in RFC4291.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Feb 2017 13:04:02 +0100

Le 28/02/2017 à 08:41, Mark Smith a écrit :
>
>
> On 27 Feb. 2017 21:23, "Alexandre Petrescu"
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>
>
> next RFC update.  I fully disagree with this plan.  It will comfort
> the cellular operators to continue assigning a single /64 to one
> User Terminal.
>
> basically IPv6 stacks interface to EthernertII headers, no 802.1 nor
> 802.11, but that's another matter; wireshark and RFC2464 show that).
>
> I would like to add that, in addition to the Ethernet I suppose you
> want to talk about by saying 802.1 and 802.11, the 64 limit is so
> only if SLAAC is there too.
>
>> From this, to make a general IPv6 Architecture Architecture
> that says that 64 is RECOMMENDED default there is a long way.
>
>
> We want the laptop and android to continue work that way - it is
> good. But could they just rely on RFC2464?  Isn't the IPv6 Addressing

YEs, unanimity is at best suspicious.

> https://tools.ietf.org/html/rfc7282

Huming is an innovative way of voting compared to other voting systems.
  It's practiced in v6ops some times, maybe less in 6man.  What do you 
think?

> That par is "All Global Unicast addresses other than those that
> start with binary 000 have a 64-bit interface ID field".
>
> There are additional messages that circulated in private, and that
> have not been posted publicly, about the validity of an "Interface
> ID" altogether.  What's the meaning of an Interface Identifier when
> one can have same IID on different interfaces?
>
>
> Answered in RFC4291.

Well, at the risk disturbing the common wisdom, look foolish with
isolated opinion - I think an evolution is needed.

The very sense of Interface Identifier may have evolved.  The virtual
interfaces are common now, IPv6 people talk "Host ID" routinely, the
48bit MAC addresses are less and less expected unique,  EUI-64 is no
longer considered elsewhere, EUI-128 is about to appear, we need app
IDs, Virtual Machine IDs and car IDs.

The dimension of the IID may have been overly specified.

Commonly one sees something like 3 to 5 IPv6 addresses on a
single-interface (more than 2 addresses, but nowhere near 2^64).  So an
IID of 3 to 4 bits is sufficient.

Commonly one sees subnets with 2 interfaces on them (cellular ptp), WiFi
subnets or office subnets with a thousand interfaces on them (nowhere
near 2^64).  So a Host ID or an Interface ID of length 10 is sufficient.

So is this Interface ID still well-dimensioned?  Wasnt 64 too hungry?
Isnt this 64 eating out too much in the plen?

Finally, there is no advice of what bits to put between fe80:: and a
64bit the Interface ID - zeros or ones?  linux says it's a fe80::/64 and
IIRC BSD says it's a fe80::/10.  The routing entries based on that can
make for interop problems.

None of these were so obvious when the 64bit Interface ID invention came
about, I think.

Alex

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Feb 2017 22:39:02 +0900

> that, but I think you should try to do it in a separate draft once IPv6 is

What James said. The 64-bit boundary is crucial to ensuring leaf nodes and
hosts never run out of addresses, which is critical to preserving
end-to-end connectivity.

The thing about a 64-bit prefix length is that it *never runs out of
addresses*. Even if you create a million new addresses every second, it
will take you almost 600 THOUSAND YEARS to run out. We can use that
property for all sorts of valuable things, many of which we likely haven't
though of. I fundamentally disagree that "now we have experience running
IPv6" we know what we can do with it. We really don't, not yet. We're not
even running 20% of the public Internet on IPv6, and pretty much the
entirety of people who work on the Internet today learned about IPv4. We
are bound to IPv4 practices more than we even realize.

I think the 64-bit balance is actually the best thing about IPv6. The way
to think of it is: IPv6 provides 4 billion times more /64s than IPv4 has
addresses... and each of those /64s provides unlimited space for
innovation, all while preserving end-to-end connectivity.

We should not throw that away just because of some arbitrary notion that
"classful addresses are bad". They were certainly bad in IPv4, because IPv4
*didn't have enough space*. We don't have that problem in IPv6 today. And
to those who say we will have that problem tomorrow: why can't we talk
about that again when we run out of 2000::/3 and we only have 88% of the
address space left?

So I really don't understand why we count individual IPv6 addresses and
insist that we need to be able to assign a subnet a /124? What's the point?
It can't be /64s cost money - you can buy 42,950 of them for 1 cent
<https://www.arin.net/fees/fee_schedule.html>. Is it address conservation?
But the numbers that have been run again and again in multiple RFCs and RIR
policies say that it's not a problem. So why, then? I don't think the ND
cache exhaustion attacks are a sufficient reason. They're pretty easy to
defend against.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 28 Feb 2017 15:48:54 +0100

Le 28/02/2017 à 14:39, Lorenzo Colitti a écrit :
> On Sat, Feb 25, 2017 at 3:11 AM, james woodyatt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I don’t know how I can be more clear about this: I insist that
>     general purpose host operating system developers should be expressly
>     permitted to write code that declines to accept subnet prefixes of
>     any length other than /64 on the grounds that these are not used in
>     general IPv6 networking and the successor to RFC 4291 continues to
>     say so.
>
>     I know there are operating systems with billions of units in the
>     field today that do exactly this because RFC 4291 and its
>     predecessors have for years given them clear license to do so, and I
>     don’t want to see the publication of I-D.ietf-6man-rfc4291bis as RFC
>     come to remove this license as a side effect of promoting IPv6 to
>     full Standard category.
>
>     You want to remove that license? I suppose we can continue
>     discussing that, but I think you should try to do it in a separate
>     draft once IPv6 is officially promoted.
>
>
> What James said. The 64-bit boundary is crucial to ensuring leaf nodes
> and hosts never run out of addresses, which is critical to preserving
> end-to-end connectivity.
>
> property for all sorts of valuable things, many of which we likely
> haven't though of. I fundamentally disagree that "now we have experience
> running IPv6" we know what we can do with it. We really don't, not yet.
> We're not even running 20% of the public Internet on IPv6, and pretty
> much the entirety of people who work on the Internet today learned about
> IPv4. We are bound to IPv4 practices more than we even realize.
>
> I think the 64-bit balance is actually the best thing about IPv6. The
> way to think of it is: IPv6 provides 4 billion times more /64s than IPv4
> has addresses... and each of those /64s provides unlimited space for
> "classful addresses are bad". They were certainly bad in IPv4, because
> IPv4 *didn't have enough space*. We don't have that problem in IPv6
> today. And to those who say we will have that problem tomorrow: why
> can't we talk about that again when we run out of 2000::/3 and we only
> have 88% of the address space left?
>
> insist that we need to be able to assign a subnet a /124? What's the
> point? It can't be /64s cost money - you can buy 42,950 of them for 1
> cent <https://www.arin.net/fees/fee_schedule.html>. Is it address
> conservation? But the numbers that have been run again and again in
> multiple RFCs and RIR policies say that it's not a problem. So why,
> then? I don't think the ND cache exhaustion attacks are a sufficient
> reason. They're pretty easy to defend against.

Because with this 64 limit the network can not grow at the edges.

Cellular network operators dont assign multiple /64s per connection - 
just one.  I would like to ask you what do you think about this?  Do you 
think cellular network operators could assign multiple /64s per one 
connection?  Or a /63?

Extending a network with bridging tools can only grow that much (not 
enough for some settings like vehicular networks).  IP routing can grow 
it much more.  I would like to ask you what do you think about this?  Do 
you think bridging is enough to grow at the edges?

SLAAC/Ethernet can not work with plen 65 or a bigger value.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Tue, 28 Feb 2017 15:58:30 +0100

> Cellular network operators dont assign multiple /64s per connection
> - just one.  I would like to ask you what do you think about this?
> Do you think cellular network operators could assign multiple /64s
> per one connection?  Or a /63?

So those providers are just providing a broken IPv6 connection.

I don't fully agree with Lorenzo, but anything longer than a /56 just
doesn't make any sense in this context.

Note that a /56 is already longer than an IMSI.

---

From: David Farmer <[email-masked]>
Date: Tue, 28 Feb 2017 09:46:06 -0600

On Tue, Feb 28, 2017 at 7:39 AM, Lorenzo Colitti <[email-masked]> wrote:

> <https://www.arin.net/fees/fee_schedule.html>. Is it address
> multiple RFCs and RIR policies say that it's not a problem. So why, then? I
> don't think the ND cache exhaustion attacks are a sufficient reason.
> They're pretty easy to defend against.
>

I'm fine with OS requiring /64, that is, and should be, the lowest common
denominator, this is an operational fact we all have to deal with.
Everything MUST support /64. However, saying that host can refuse other
than /64, admits this is a parameter could be something other than /64.

However many OSes also allow configurations other than just /64, is this
OK? Is that how RFC4291 should be interpreted? Honestly, I don't read it
that way, I think it says /64 only now and forever.  And, I don't think
that is correct.

I think we should be saying OS MAY allow configurations other than /64, at
least with manual configuration, and maybe DHCPv6 too.  Further, operators
should be allowed do configure other than /64, when they know all devices
on a network can support such a configuration.  If they don't know this for
sure they SHOULD configure /64.

Saying that /64 is required is a false imperative, at best it is an
aspirational statement not an actual requirement, at it's worst it creates
confusion and incompatibilities. The fact that RAs allow other lengths
means this has always been a parameter.  We have defined this as a
parameter not as a constant. Trying to redefine it as a constant, only
confuses people.  Saying that this is a parameter that is recommended to be
64 makes sense.  I'd even include the consequences of not using 64.   But,
saying it's a parameter that is required to be 64, sound like it's a
constant or at least masquerading as a constant, and only confuses people.

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 1 Mar 2017 01:29:51 +0900

On Wed, Mar 1, 2017 at 12:46 AM, David Farmer <[email-masked]> wrote:

> that way,

IMO the important question is not "should an OS refuse to configure a /65
when manually configuring an address". I think the much more important
questions are, "can the OS assume that it can use the full 64 bits to form
an IID", and "will this link ever run out of IPv6 addresses". The answers
to those should be yes and no.

> least with manual configuration, and maybe DHCPv6 too.
>

I really don't want to use a network that provides a /120 and requires
DHCPv6 to connect. Not only does it offer subpar functionality, it does so
for no good reason. At least in IPv4 there was a reason: there weren't
enough addresses. Would you want to use such a network?

Another thing I think we should avoid is to remove the fixed 64 barrier and
open the door to having this debate again and again, once for every new
IPv6-over-foo document and once for every new address configuration
protocol (today we have SLAAC and DHCPv6, who knows what we'll have in the
future).

We have defined this as a parameter not as a constant.

I really don't understand this statement. How can you say that it's a
parameter, given that every RFC that has been published on this topic
starting from 1998 states that (most) IIDs are 64 bits long?

Most of the code in most implementations treated this a parameter, but
there is code that just takes the 64-bit length at face value, and is well
within its rights to do so, because it's specified by the standard.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Mar 2017 08:56:00 +1300

On 01/03/2017 05:29, Lorenzo Colitti wrote:
...
> starting from 1998 states that (most) IIDs are 64 bits long?

Yes, I think we have a long tradition of expressing this badly, and now
is a chance to get it right. It's clear at the point where it's
introduced in RFC4291 that it's a floating boundary:

  "A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+"

but later in the same document we state that (128-n) == 64. That is
inconsistent; what we're trying to do now is fix that inconsistency
in a way that is *also* consistent with running code, SLAAC, and the
newly important privacy issues that require long, unpredictable IIDs.

> within its rights to do so, because it's specified by the standard.

And that's our fault, all the way back to RFC3513. (RFC2373 was more
cautious.)

On 27/02/2017 23:22, Alexandre Petrescu wrote:
...
> considered (instead of improving it)?

This idea has some merit. Fixing a parameter doesn't really belong in
the architecture document. However, I think we've painted ourselves
into a corner here, so we have to say something.

     Brian

---

From: james woodyatt <[email-masked]>
Date: Tue, 28 Feb 2017 12:09:23 -0800

On Feb 28, 2017, at 07:46, David Farmer <[email-masked]> wrote:
> 
> I think we should be saying OS MAY allow configurations other than /64, at least with manual configuration, and maybe DHCPv6 too.

This statement puzzles me because I see the distinction between subnet prefix assignment and interface address assignment as A) really important, and B) one of the ways that IPv6 improves greatly on IPv4. I really really really don’t want to lose that improvement.

p1. DHCPv6 does not assign subnet prefixes. DHCPv4 does, but that was a feature that we deliberately left out of DHCPv6. We put prefix *delegation* to routers into DHCPv6, which is a whole other discussion I don’t want to have right now, but we left subnet prefix assignment to the Router Discovery protocol, where I would say it rightly belongs.

p2. Manual configuration of IPv6 interface addresses and IPv6 subnet prefixes are separate and distinct processes. Either of them can be manually or automatically configured independently from the other in several of the host OS implementations I know about. This is not so often the case in IPv4 implementations.

In all these debates we are having about I-D.ietf-6man-rfc4291-07, I have been very careful to maintain that it is only *subnet* prefix assignment where I am insisting that /64 is a general requirement, with known exceptions for things like subnets that consist entirely of routers.

For that reason, I really don’t know how to respond when people insist that DHCPv6 is somehow involved in the discussion about subnet prefix assignment. Are they confused about how subnet prefixes are assigned in IPv6?

Yes, I recognize that Router Advertisement messages are defined with a packet format that allows routers to advertise PIO with L=1 and a Prefix Length > 64. I continue to maintain those should not be used. There are a lot of IPv6 applications, including quite a few Standards Track protocols published by IETF, that will simply truncate those prefixes to a /64 in every place where an IPv6 interface address must be mapped to a subnet prefix. And there are many SLAAC implementations that will decline to assign statelessly any interface addresses in a prefix advertised with A=1 and Prefix Length > 64. There are also a few implementations [broken ones, admittedly] kicking around that will simply ignore those PIO entirely. I think the successor to RFC 4291 needs to recognize that is reality and provide appropriate requirements language.

---

From: David Farmer <[email-masked]>
Date: Tue, 28 Feb 2017 14:33:58 -0600

> to those should be yes and no.

I don't disagree with your answers, and you may not think the manual config
question is important, but others seem too.

> enough addresses. Would you want to use such a network?

And you don't have too.  But, your saying no one else can ever have a
reason to do that, and I'm not so sure about that.  And something on the
other side of the Internet can't make any assumption about what I'm doing
anyway.  You are saying it can't be done because the 64 bit boundary is
even more important than CIDR and addresses on the other side of the
Internet are supposed to be opaque.  Where as I disagree, CIDR and the
opaqueness of addresses across the Internet are more fundamental properties
than 64 bit boundary.  Which is why I say the 64 bit boundary is really a
RECOMMENDATION.  And CIDR and the opaqueness of addresses across the
Internet are REQUIREMENTS.

> Another thing I think we should avoid is to remove the fixed 64 barrier
> and open the door to having this debate again and again, once for every new

Which is why it time to get this right and saying it is now and forever 64
isn't right.

> We have defined this as a parameter not as a constant.
con·stant

adjective: constant
1. occurring continuously over a period of time.
- remaining the same over a period of time.

noun: constant; plural noun: constants
1. a situation or state of affairs that does not change.

MATHEMATICS
a quantity or parameter that does not change its value whatever the value
of the variables, under a given set of conditions.

PHYSICS
a number expressing a relation or property that remains the same in all
circumstances, or for the same substance under the same conditions.

Or;

A mathematical constant is a special number, usually a real number, that is
"significantly interesting in some way". Constants arise in many areas of
mathematics, with constants such as e and π occurring in such diverse
contexts as geometry, number theory, and calculus.

https://en.wikipedia.org/wiki/Mathematical_constant

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Feb 2017 17:36:03 -0300

>    attached to, where different addresses may have different values for

I agree with Brian's comment. We need to get this fixed.

Regarding long IIDs:
* when it comes to privacy, either long or very short will generally do
-- with long, you can produce good unpredictable IIDs. With short IIDs,
you almost guarantee collisions of IIDs, hence the IIDs are meaningless
to track nodes (as in IPv4).

* From a network scanning et al, long IIDs are obviously desirable.
But.. /64 would do in the same way that something > 50 bits would
probably do.

Thanks,

---

From: Greg Hankins <[email-masked]>
Date: Wed, 1 Mar 2017 02:27:47 -0500

>constant or at least masquerading as a constant, and only confuses people.

I strongly agree with this statement that the text should be revised to be
a recommendation instead of a strict requirement that prevents operators
from choosing an addressing scheme that best suits their needs.  The way
I read section 2.4 is that it's a /64 requirement, even though we have
other standards (/127) and clear evidence from operators that they have
a number of other mask lengths deployed.

Speaking for my employer's (Nokia) implementation of IPv6, where I am the
product manager responsible for our IPv6 feature set, we allow customers
to configure a mask length of their choice.  We can never change our
implementation to be compliant with the proposed text because of the
operational havoc it would create for our customers.  It's simply infeasible
to impose these kind of addressing restrictions.

Kind regards,
Greg

--
Greg Hankins <[email-masked]>