Subject: Re: "professional" in an IETF context

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 1 Nov 2021 14:06:27 +0200

On Sun, Oct 31, 2021 at 11:13 PM Keith Moore <[email-masked]>
wrote:

> On 10/31/21 3:34 PM, Brian E Carpenter wrote:
>
> > I repeat my suggestion that s/unprofessional/uncivil/ would fix the
> > document under discussion.
>
> Perhaps it would.   And all other things being equal, a simpler fix is
> attractive.  But I don't know why others seem to insist on "professional".
>
>
The reason mybe that it is thought that only who authors an RFC is
professional.
As years while checking in IETF context, it is seen some new people IETF
motivation can be heard that 'you should write an RFC', but maybe a better
motivation is 'you should work/discuss with one WG together regarding one
milestone for progress.
If the word 'professional' makes confusion it is better to change it, or
define it in the document.
I totally agree with the definition give by Keith, which is in the
beginning of thread, so please add it to the draft.

Best Regards,
AB

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 1 Nov 2021 22:15:13 +0900

Keith Moore wrote:

>> It's what we expect of our doctors, lawyers, and... ENGINEERS.  It
>> is an ENGINEERING Task Force, after all.  And I would hope that
>> most of us here are actually engineers, with some reasonable level
>> of engineering knowledge, experience, and professionalism.

And the goal should be to prevent IETF perform meaningless
engineering such as development of stupid protocols, including
but not limited to, IPv6 and LISP.

> 5. Whatever you’re working on, try to help build consensus
> or craft or find a compromise that can attract broad support.

That should be the gold paved road to the hell of committee
designed protocols.

> Again
> you’re free to withhold support or to point out problems with a
> proposal, you’re free to offer alternative proposals, and/or to
> appeal formal decisions, but not to obstruct discussion. State/log
> your objections and move on (But you should have a reasonable
> expectation that such objections will not be forgotten and be
> reviewed again at last call time).

Feel free to move forward on the road.

But, if you want to be a good engineer, learn to actively disrespect
not only poor engineering results but also poor engineers, even
though poor engineers say it is not "professional" behavior.

					Masataka Ohta

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 1 Nov 2021 10:06:39 -0400

Abdussalam Baryun wrote:
>
>
> On Sun, Oct 31, 2021 at 11:13 PM Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> As years while checking in IETF context, it is seen some new people 
> IETF motivation can be heard that 'you should write an RFC', but maybe 
> a better motivation is 'you should work/discuss with one WG together 
> regarding one milestone for progress.
> If the word 'professional' makes confusion it is better to change it, 
> or define it in the document.
Is that really true, though?  We certainly have a lot of protocols, 
written by amateurs - some of which have ignored RFCs and led to their 
own standards processes.  Are there not RFCs similarly written by folks 
with limited experience?  Or is it that "unprofessional" RFCs don't make 
it past the RFC editorial process?

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 1 Nov 2021 10:08:53 -0400

> but not limited to, IPv6 and LISP.
Now THIS seems like a living example of something that is both 
unprofessional AND uncivil.

Miles Fidelman

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 1 Nov 2021 23:58:24 +0900

Miles Fidelman wrote:

>> engineering such as development of stupid protocols, including but
>> not limited to, IPv6 and LISP.

> unprofessional AND uncivil.

Thank you very much for clarifying that requiring to be "professional"
or "civil" means prohibiting fair criticism against poor engineering
results.

							Masataka Ohta

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 1 Nov 2021 11:05:44 -0400

Ohta-san, your email (retained as the first part of the below) is not in 
my view fair criticism against poor engineering results.  it is a baldly 
and badly expresssed personal opinion.  Even if someone were inclined to 
agree with you, there is no information there by which to attempt to 
improve the process or results.  Nor is there even any detail of what 
you consider "stupid" about the protocols.  Even the use of the word 
"stupid" casts into question whether your note could be considered fair 
criticism.

People have the right and even the obligation to criticize IETF 
protocols.  Both before and after publication as RFC.  Recently, a 
participant raised specific and clear security concerns with a published 
RFC.  That is what is supposed to happen.

Yours,
Joel

PS: I would normally simply ignore your largely content free remarks, 
but I want to make sure that others realize that Miles' reaction is 
shared by others.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 2 Nov 2021 00:37:02 +0900

Joel M. Halpern wrote:

> and badly expresssed personal opinion. 

FYI, on 2019/10/15 16:10, I wrote to this list:

 > Subject: Re: Sergeant-at-arms engagement model
 > Keith Moore wrote:
 >
 >> The words "They also include criticizing an idea in an insulting
 >> orexcessively hostile manner" are troubling.   I realize that one
 >> maycriticize an idea in such a way as to effectively be critical of the
 >>  person proposing the idea.  And yet, it is essential that people be
 >> able to discuss ideas candidly, and sometimes to criticize
 >> ideasemphatically.   I believe it's inappropriate to impugn a
 >> participant's motive without supporting evidence of that motive.  But
 >> I don't believe it's wrong to point out any problem with an idea
 >> itself, nor with potential ill effects of an idea, nor even with the
 >> appearance of an idea.   Sometimes this is a fine line, but it's
 >> essential that the SAAs not interfere with vigorous discussion of
 >> relevant ideas.
 >
 > Let me try.
 >
 > IPv6 with unnecessarily lengthy 16B addresses without valid
 > technical reasoning only to make network operations prohibitively
 > painful is a garbage protocol.
 >
 > LISP, which perform ID to locator mapping, which is best
 > performed by DNS, in a lot less scalable way than DNS
 > is a garbage protocol.
 >
 >                      Masataka Ohta

but SAAs did not act against it.

							Masataka Ohta

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Nov 2021 10:44:57 -0500

>  > painful is a garbage protocol.

It could be. But IPv6 was made workable by clever modifications over time
and now it works pretty well and widely used.

>  > performed by DNS, in a lot less scalable way than DNS

LISP should not have stayed that long in IETF, otherwise I am OK with
defining protocols like that and trying.

Behcet

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 1 Nov 2021 16:39:38 +0000

> 
> It could be. But IPv6 was made workable by clever modifications over time and now it works pretty well and widely used.

To quote a well known phrase, “you may think that, but I could not possible comment” … but I will.

IP fundamentally started out as a UNI and extended its scope to attempt to be a universal connectivity protocol.

IPv6 was designed around the perception of how the Internet worked over 20 years ago.

IPv6 as a UNI is in my view inadequate in that it does not properly support the degree of sophistication needed to specify current and future SLOs. A trivial example is the way that ECN needed to be hacked into it. Adding support for determinism in will be much harder. The one size fits all addressing and the way that we have to work round that is problemantic. The single address size and domain was a good idea at the time, except that most of the time IP  traffic sits in another protocol with an entirely different addressing scope and paradigm.

However  we seem to find it hard to accept that the fundamental internet protocols should be in a perpetual state of renewal or otherwise risk obsolescence.

As professionals we should accept that we need to continually test status quo against the unthinkable, but as an institution we seem to find that hard to accept.

Best regards

Stewart

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2021 12:46:36 -0400

> unprofessional AND uncivil. 

I don't agree with that opinion of IPv6.    (I'll reserve opinion about 
LISP - I didn't like what it was when originally proposed, but I haven't 
tried to evaluate what it ended up being.)

But people absolutely should be free to criticize IETF work, even work 
that some people are pleased with.   Even if they say that the work is 
useless, meaningless, or harmful.

(it might help, though, if the criticism has some informative detail to 
it, so that readers can understand why it's being criticized.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 1 Nov 2021 12:51:56 -0400

On 11/1/21 12:39 PM, Stewart Bryant wrote:

> However  we seem to find it hard to accept that the fundamental 
> internet protocols should be in a perpetual state of renewal or 
> otherwise risk obsolescence.

I have come to believe (or understand) that interoperability over time 
is important.  That is, it's not only important that two implementations 
be able to operate at the time they are deployed, but also important 
that implementations be able to interoperate with other implementations 
from decades before or hence.   Because old systems cannot always be 
upgraded, and it's very unrealistic to assume that they can or should 
be.   That doesn't mean that the protocol can't evolve, but it needs to 
preserve backward compatibility - and it's complex to do that if the 
protocol changes very much.

Keith

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 1 Nov 2021 14:19:11 -0400

> or "civil" means prohibiting fair criticism against poor engineering
I can't speak to LISP (other than the language, which is just plain 
brilliant).  But a lot of good engineering went into IPv6 (speaking as 
an outside observer) - calling it "meaningless" and "stupid" is both 
uncivil and unprofessional - certainly in print.  (In a design review, 
in context, "that's just plain moronic, on the face of it" - might be 
considered both civil, and professional).

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 1 Nov 2021 14:20:34 -0400

Joel M. Halpern wrote:
> Ohta-san, your email (retained as the first part of the below) is not 
> in my view fair criticism against poor engineering results.  it is a 
> baldly and badly expresssed personal opinion.  Even if someone were 
> inclined to agree with you, there is no information there by which to 
> attempt to improve the process or results.  Nor is there even any 
> detail of what you consider "stupid" about the protocols.  Even the 
> use of the word "stupid" casts into question whether your note could 
> be considered fair criticism.
>
> participant raised specific and clear security concerns with a 
> published RFC.  That is what is supposed to happen.
>
> Yours,
> Joel
>

And I thank you for that. :-)

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 1 Nov 2021 14:24:07 -0400

Stewart Bryant wrote:
>>
>> It could be. But IPv6 was made workable by clever modifications over 
>> time and now it works pretty well and widely used.
>
Or to quote another long-term protocol world denizen "you could do that, 
but it would be silly."

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Nov 2021 08:48:06 +1300

Somebody whose email never reaches my inbox alledgedly said:

>       > IPv6 with unnecessarily lengthy 16B addresses without valid
>       > technical reasoning only to make network operations prohibitively
>       > painful is a garbage protocol.

Apart from its incivility, this sentence is factually untrue. The address
length was 8 bytes in the early design of what became IPv6, which was of
course essential to overcome the main limitation of IPv4. It was expanded
to 16 bytes when the value of an interface identifier in addition to
a routeable prefix was considered. That idea was based on existing
practice in several non-IP network technologies, and on the IPng
requirements process. In other words, on technical reasoning and on
running code.

Professionalism includes factual accuracy.

    Brian

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 1 Nov 2021 20:06:04 +0000

Sent from my iPad

> On 1 Nov 2021, at 19:49, Brian E Carpenter <[email-masked]> wrote:
> 
> course essential to overcome the main limitation of IPv4.

There were other techniques of course such as IPv4 in IPv4 which would allowed existing network kit to largely be used unchanged, and would probably have given fewer migration issues.

However you cannot refute a criticism of IPv6 having 128bit addresses by  arguing that it started with 64bits because it does actually have 128 bit addresses.

> It was expanded
> a routeable prefix was considered.That idea was based on existing

Of course variable length and multi-address family approaches existed at the time, and were rejected. One of the reasons for this was politics, in particular a desire not to use an ISO protocol. There was also a counter argument based on forwarder performance, but there were ISO routers that were of comparable speed.

> Professionalism includes factual accuracy.

It also includes reviewing if the right decisions were taken so we learn from history.

Stewart

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Nov 2021 22:08:25 +0100

> Professionalism includes factual accuracy.

Folks,

it’s a trap.

Somewhere in the distant past of this thread, there was a discussion about a code of conduct, that included the word professional (conduct, that is, or “behavior”).  What was meant was probably civil, productive behavior.

Now somehow, discussions of this kind can be easily exploded by changing the subject subtly.  So we moved from professional conduct via professional documents (*) to professionally designed (i.e., clairvoyant) protocols, and I think we haven’t quite arrived at professional hobbyist tools, but sure soon will.  So it is no longer possible to read the (sometimes quite useful) comments on the original question.

I honestly don’t know if the tendency of discussions to explode this way is due to an actual strategy of some participants, or if I should apply Hanlon’s razor [1] and “never attribute to malice that which is adequately explained by stupidity” (not a very professionally phrased statement, but quite popular).

Let’s be a bit more, er, professional in using this list.

Grüße, Carsten

(*) Hey, I can do that too: A technical document is not very professional if it measures bitrate in “kbps” and “mpbs” [sic].  Even my mobile phone company can do better.  Let’s see if I can get my own thread here :-)  Please don’t.

[1]: https://en.wikipedia.org/wiki/Hanlon%27s_razor

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Nov 2021 11:22:38 +1300

Stewart,

I didn't intend to relitigate IPv6 design decisions, but only to refute the misinformation that the choice of address size and format was not the result of technical reasoning. But since you rang the doorbell, see below.
> There were other techniques of course such as IPv4 in IPv4 which would allowed existing network kit to largely be used unchanged, and would probably have given fewer migration issues.

There were many such proposals around. There's a whole book about it. My personal proposal that would have squared the size of the address space was kicked out after a BOF at the Seattle IETF. There was a pretty extensive process of sieving proposals against requirements.

> However you cannot refute a criticism of IPv6 having 128bit addresses by  arguing that it started with 64bits because it does actually have 128 bit addresses.

That's not what I did. I explained why we did it.

> Of course variable length and multi-address family approaches existed at the time, and were rejected. One of the reasons for this was politics, in particular a desire not to use an ISO protocol. Th…

CLNP conforming with US GOSIP had *fixed length* addresses (20 bytes), so 
the concern about processing time was not really an argument against CLNP. Incidentally, I came into the IPng process with a strong bias in favour of CLNP, and I had already committed resources to deploying CLNP (DECNET Phase V). But the analysis of solutions against requirements persuaded 
me otherwise.

> It also includes reviewing if the right decisions were taken so we learn from history.

Agreed.

     Brian

---

From: Scott Bradner <[email-masked]>
Date: Mon, 1 Nov 2021 19:09:47 -0400

fwiw - we tried to explain the decision process in RFC 1752

Scott

> On Nov 1, 2021, at 4:06 PM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPad
>

---

From: Lloyd W <[email-masked]>
Date: Tue, 2 Nov 2021 13:18:11 +1100

> On 2 Nov 2021, at 08:09, Carsten Bormann <[email-masked]> wrote:
> 
> I think we haven’t quite arrived at professional hobbyist tools, but sure soon will.

best description of git I've heard.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 2 Nov 2021 16:12:22 +0200

On Mon, Nov 1, 2021 at 4:08 PM Miles Fidelman <[email-masked]>
wrote:

> written by amateurs - some of which have ignored RFCs and led to their own
> standards processes.  Are there not RFCs similarly written by folks with
> limited experience?  Or is it that "unprofessional" RFCs don't make it past
> the RFC editorial process?
>

It is true. We all know what we have and what we don't have, but we always
want/need better.

AB

> not true,

> not true,

We only find truth by good discussions and respecting each other, because
God is truth and he only guides to the truth.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 2 Nov 2021 12:20:15 -0400

Abdussalam Baryun wrote:
>
>
> On Mon, Nov 1, 2021 at 4:08 PM Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Abdussalam Baryun wrote:
>>
>>
>>     The reason mybe that it is thought that only who authors an RFC
>>     is professional.
>>     As years while checking in IETF context, it is seen some new
>>     people IETF motivation can be heard that 'you should write an
>>     RFC', but maybe a better motivation is 'you should work/discuss
>>     with one WG together regarding one milestone for progress.
>>     If the word 'professional' makes confusion it is better to change
>>     it, or define it in the document.
>>     I totally agree with the definition give by Keith, which is in
>>     the beginning of thread, so please add it to the draft.
>>
>>
>     Is that really true, though?  We certainly have a lot of
>     protocols, written by amateurs - some of which have ignored RFCs
>     and led to their own standards processes. Are there not RFCs
>     similarly written by folks with limited experience?  Or is it that
>     "unprofessional" RFCs don't make it past the RFC editorial process?
>
>
> It is true. We all know what we have and what we don't have, but we 
> always want/need better.
>
> AB
Might I ask what "it" you're referring to?

> We only find truth by good discussions and respecting each other, 
> because God is truth and he only guides to the truth.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Nov 2021 01:36:52 +0900

> Somebody whose email never reaches my inbox alledgedly said:

How professional you are.

> Apart from its incivility,

Are there anyone else who think such criticism for IPv6 as:

is not civil?

Or, can we just conclude that requiring to be "civil" as demonstrated
by Brian Carpenter is practically censorship not only unprofessional
and uncivil but also immoral and, worse, unlawful?

 > this sentence is factually untrue.
 > It was expanded
 > a routeable prefix was considered.

The fact is that there is no such idea of SIP nor IPng requirement
to have "interface identifier" only to make IPv6 address
purposelessly lengthy at all.

 > That idea was based on existing

As I already pointed out in the past here, having "interface
identifier" is a feature inherited from XNS having running code.

But, that XNS and IPv6 have running code dose not mean they
are good.

						Masataka Ohta

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 2 Nov 2021 16:45:13 +0000

+1.
It was a big mistake to break OSI model and include L2 address (MAC) inside L3 address (IPv6).
Half of the address bits were wasted.
Many people are coming and coming asking that they would like too to get some bits of IPv6 address for some new protocol.
Eduard
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Masataka Ohta
Sent: Tuesday, November 2, 2021 7:37 PM
To: [email-masked]
Subject: Re: "professional" in an IETF context

is not civil?

Or, can we just conclude that requiring to be "civil" as demonstrated by Brian Carpenter is practically censorship not only unprofessional and uncivil but also immoral and, worse, unlawful?

 > to 16 bytes when the value of an interface identifier in addition to  > a routeable prefix was considered.

The fact is that there is no such idea of SIP nor IPng requirement to have "interface identifier" only to make IPv6 address purposelessly lengthy at all.

 > practice in several non-IP network technologies, and on the IPng  > requirements process. In other words, on technical reasoning and on  > running code.

As I already pointed out in the past here, having "interface identifier" is a feature inherited from XNS having running code.

But, that XNS and IPv6 have running code dose not mean they are good.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Nov 2021 02:05:01 +0900

On 2021/11/03 1:45, Vasilenko Eduard wrote:

> +1. It was a big mistake to break OSI model and include L2 address
> (MAC) inside L3 address (IPv6). Half of the address bits were
> wasted. Many people are coming and coming asking that they would like
> too to get some bits of IPv6 address for some new protocol. Eduard

Indeed. Originally, as proposed by IPng directorates, interface ID
was 48bit long. However, as I pointed out that IEEE1394 has 64bit
MAC, it was extended to be 64bit long.

But, I haven't noticed that it is layer violation. Thank you.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Nov 2021 09:07:46 +1300

> It was a big mistake to break OSI model and include L2 address (MAC) inside L3 address (IPv6).

I think you are not familiar with the CLNP NSAPA GOSIP addressing model. As RFC1526 clearly explains, the CLNP address architecture proposed for the Internet embodied an ID field that could be an IEEE MAC address (see section 3.1 in particular). That's how DECnet/OSI worked, too. (And Novell Netware, copied from Xerox PUP, a.k.a. XNS.)

We didn't break the OSI model, we copied it.

> Half of the address bits were wasted.

No, we *doubled* the address size to accomodate the ID field. Most people at the time expected a 64 bit address. I believe that it was the 20 byte GOSIP address that made the 16 byte IPv6 address thinkable.

    Brian

> Many people are coming and coming asking that they would like too to get some bits of IPv6 address for some new protocol.> Eduard

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Nov 2021 21:46:21 +0000

Sent from my iPad

> On 2 Nov 2021, at 20:08, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 2 Nov 2021 21:58:41 +0000

> I believe that it was the 20 byte GOSIP address that made the 16 byte IPv6 address thinkable.

The address architecture was highly flexible and you could have used almost any length you wished, and the forwarders could support multiple address families concurrently.

Stewart

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 2 Nov 2021 18:10:09 -0400

some people thought that and others strongly did not 

see https://www.sobco.com/ipng/big_ten/big_ten_packet_format.txt for one of the final proposals

Scott

> On Nov 2, 2021, at 5:58 PM, Stewart Bryant <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Nov 2021 11:42:01 +1300

> The address architecture was highly flexible and you could have used almost any length you wished, and the forwarders could support multiple address families concurrently.

Yes. (Hence RFC1888 section 5.) But in practice at that time, US GOSIP was the only game in town.

As Scott's citation suggests, the choice of a fixed length address field was contested. There was draft-rekhter-bigten-addr-arch-00 which went into more detail on variable length addresses (and acknowledged RFC1629).

    Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Nov 2021 17:14:08 +0900

Scott O. Bradner wrote:

> see https://www.sobco.com/ipng/big_ten/big_ten_packet_format.txt > for one of the final proposals

It says:

    This document attempts to borrow the best from all of the existing
    IPng proposals (CATNIP, SIPP, TUBA).

which is, as all the real engineers know, the surest way to
lose, though politicians think it the best compromise.

It should also be noted that SIPP is already a union
of SIP and PIP, though Paul Francis, who proposed PIP,
was, in the face of SIPP, saying "PIP is dead".

So, SIPP was developed highly politically, though its
address is still 64bit long.

							Masataka Ohta

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 3 Nov 2021 08:31:13 +0000

Then why Address Resolution Protocol was needed in principle? (ND or whatever)
If the L3 address always had an L2 address inside?

The OSI was calling for layers isolation. It was a big deal for OSI.
It is not the isolation when addresses from different layers are inserted into each other.

Brian explained how it did happen: this mistake was copied from another protocol.
IMHO: it is not a good excuse.

The consequences are forever with us:
1. Filters from all vendors are 4x affected between IPv6 and IPv4. 2x was because of this decision.
2. Table sizes are 2x affected. And maybe affected 4x in the future if the IPv6 address would be expanded from 64 to 128.
3. SPRING is looking at how to "Compress SIDs". Such a label stack stresses PFE scalability 2x for not a good reason.

Wasting 2x more bits for addresses is not "free lunch".
We could waste more energy and squeeze more gates into the ASIC to overcome the scalability problem created.
IPv6 is anti-green technology as a result.
If it is needed to process more bits - it is the cost for nature.

By the way, IPv6 is close to "64-bit addressing technology" now. In reality, it is a little bigger because bits are not wasted for IDs on the subnet.
All these calculations of addresses per every atom on the Earth are wrong. Real address space is 2^64 smaller.
The current practice to "waste as much IPv6 as possible for every design" would fire back in a few decades.
Or a big revamp would be needed to expand from 64 to 128 bits. CIDR again.

Eduard
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Tuesday, November 2, 2021 11:08 PM
To: [email-masked]
Subject: Accurate history [Re: "professional" in an IETF context]

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 3 Nov 2021 10:15:26 +0100

> address is still 64bit long.
While *perhaps* SIPP shared some principles with Pip I don't think that 
either the addressing or routing architecture was one of them.  My 
recollection was that the 128 bit address came to be because of concerns 
that we'd end up having to do All Of This *again* if there were a 
shortage.  Nobody wanted that, and so we ended up with 128 bits.  That 
wasn't the only reason: the idea of doing away with ARP and permitting 
some amount of auto-configuration based on the MAC address had its 
appeal.  You can say that IPv6 was the result of committee thinking, and 
I would probably agree, but I'm not sure what the alternative would be.  
After all, politics begin in a room with more than one person.

You can *somewhat* follow the development of Pip in particular at the 
24th through 27th IETF meetings.  I say, “somewhat” because even by the 
24th IETF, Paul had evolved his ideas (the sign of a good engineer).  I 
just can't find good earlier references.

Eliot

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 3 Nov 2021 21:40:32 +0900

Eliot Lear wrote:

> either the addressing or routing architecture was one of them. 

   https://www.potaroo.net/ietf/idref/draft-ietf-sipp-spec/
   o  Changed name from "SIP" to "SIPP" as part of merger with Pip.

IIRC, some routing header was added to SIP to politically claim
it is merged with PIP.

> My 
> shortage.

As it is obvious even at that time that 64bit is a lot more than
enough, that was a poor excuse for political merger, I'm afraid.

> You can say that IPv6 was the result of committee thinking, and 

 >> address is still 64bit long.

SIP or SIPP was an alternative.

As an afterthought, it were even better if very complicated
functionality of SIP that it has optional headers, which
was denied by long and extensive operational experience
of IPv4, which makes SIP and IPv6 not simple at all, were
removed. Fragmentation could and should have been handled
more elegantly than PMTUD.

						Masataka Ohta

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 3 Nov 2021 13:37:14 +0000

> Fragmentation could and should have been handled more elegantly than PMTUD.

Correct, and we have done that with OMNI.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Nov 2021 10:43:09 +1300

Eduardo,
> If the L3 address always had an L2 address inside?

It was always clear that using the MAC address as the interface identifier was specified for each LAN technology separately. If you recall the discussions a couple of years ago, I was arguing for /64 being clearly defined as a *parameter* of the address architecture which we have currently set at 64. In the very early days it was set at 48. Even in RFC1884, the use of a MAC address as the IID was *explicitly* stated to be an example (section 2.4.1).

ND is therefore an unavoidable step, especially on a LAN with no router.

> It is not the isolation when addresses from different layers are inserted into each other.

It has been described as a serious bug in the OSI model, by none less than John Day, but this is indeed what OSI does. The OSI Reference Model says you can create layer N address by concatenating an (N-1)-address on the end of an (N)-identifier. But that isn't the IPv6 model. A layer 3 address is a layer 3 identifier concatenated to a layer 3 routeable prefix. And today we have largely discarded the pragma that the layer 3 identifier is constructed from the layer 2 address.

> IMHO: it is not a good excuse.

No, I didn't say it was a mistake or offer an excuse. I just tried to provide objective facts.

> 1. Filters from all vendors are 4x affected between IPv6 and IPv4. 2x was because of this decision.> 2. Table sizes are 2x affected. And maybe affected 4x in the future if the IPv6 address would be expanded from 64 to 128.

On the timescale concerned, Moore's law has given us a factor of more than 1000. I agree that there's an energy cost to everything, but most energy wastage comes from idiocies like Bitcoin and unnecessarily high quality video, not from FIB lookups.

> All these calculations of addresses per every atom on the Earth are wrong. Real address space is 2^64 smaller.

Sure. The important calculation is how many prefixes are available. The atoms in the universe calculation is just silly.

> The current practice to "waste as much IPv6 as possible for every design" would fire back in a few decades.

If you're arguing for flexibility in the /64 boundary, yes, I would still like to see it clearly defined as a parameter in the architecture that we might vary in some contexts (e.g. IoT). If you're arguing against using address bits for higher-layer semantics, I fully agree with you. But if you look around, you'll find a lot of people who think that's a great idea. (As long as they confine it to their own limited domains, however, it doesn't really matter that much.)

> Or a big revamp would be needed to expand from 64 to 128 bits. CIDR again.

Yes, there are some warning signs in BGP4 growth for IPv6, but due to /48s. In the end, it's BGP4 scaling that limits everything.
https://dx.doi.org/10.1145/3477482.3477490

    Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Nov 2021 23:40:26 -0400

> Professionalism includes factual accuracy.

+1

Remember that only 8 bytes of the 'Internet P' address actually route on
the Inter-network.

The 16 bit port field for IPv4 is also insufficient. But given the choice,
I would much rather have 64 bits I can use for local routing than an 80 bit
port field.

The size of an IPv6 header is only an issue because the Ethernet standard
has failed to mandate support for larger frames to keep up with needs. 1500
bytes of payload is too small. Problem is that until a new version of
ethernet mandate support for decent sized frames, using them is going to
pose practical difficulties.

They should increase the frame size to 64KB and limit the scope of the
checksum to the first 500 bytes. Payload integrity is not a layer 3
concern. Misrouting due to corrupted address headers is though.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 4 Nov 2021 08:14:27 +0000

What about WiFi or 3GPP? Should it increase MTU too?
Reminder: wireless is a loss environment, repeating 64k frames would be very expensive.

And if the majority of links (by number) would be still limited, how big is the value for the minority of links supporting hyper-big frames?

The problem is not with bandwidth. 16B/800B=2% is not a big overhead.
The problem is with the cost of processing additional bits in ASIC (for Routing, Filtering).
Much more gates are needed on ASICs (including memory chips).
More cost, more power consumption.

The situation is especially strange because only 8bytes of IPv6 addresses are used now.

Ed/
From: ietf [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, November 4, 2021 6:40 AM
To: Brian E Carpenter <[email-masked]>
Cc: IETF Discussion Mailing List <[email-masked]>
Subject: Re: "professional" in an IETF context

On Mon, Nov 1, 2021 at 3:49 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

    Brian

+1

Remember that only 8 bytes of the 'Internet P' address actually route on the Inter-network.

The 16 bit port field for IPv4 is also insufficient. But given the choice, I would much rather have 64 bits I can use for local routing than an 80 bit port field.

The size of an IPv6 header is only an issue because the Ethernet standard has failed to mandate support for larger frames to keep up with needs. 1500 bytes of payload is too small. Problem is that until a new version of ethernet mandate support for decent sized frames, using them is going to pose practical difficulties.

They should increase the frame size to 64KB and limit the scope of the checksum to the first 500 bytes. Payload integrity is not a layer 3 concern. Misrouting due to corrupted address headers is though.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 4 Nov 2021 09:40:01 +0000

Hi Brian,
Agree with all your arguments.
But let me rephrase one in the way more convenient for me:
"Address Resolution Protocol is needed to have the flexibility in the future to move subnet boundary from /64 to something bigger."

It would have one not good implication if it would happen:
Many prefixes started from high-order bits would be already occupied.
Does not matter how many bits would be attached at the end of the IPv6 address - all these bits would be in possession of the current owner of the prefix.
New companies would have to accept smaller prefixes left and chop low-order bits.
Then the Internet would split for ASes that manipulate primarily high-order bits and ASes that manipulate low-order bits.
Not nice. It would mandate to process all 128 bits, but efficiency would be like 65-66bits.

You see: the expansion 64->128 is not so useful because bits are attached from the wrong end.
It does not make too much sense from an architectural point of view. IPv6 is 64bit addressing architecture forever.
Prefix boundary expansion is useful only to bypass ultimatum from Mobile chipset vendors: to solve the problem of filtered DHCP-PD.
IMHO: it is better to develop something instead of DHCP-PD to deliver the prefix to a smartphone.
Could be a good question: why the same vendors would not filter it out again?

Hence, I could return to the question: do we not need an address resolution protocol for IPv6?
Because it is reserving the flexibility for something that does not make sense anyway.
It looks like we have taken the worst combination: L3 address bloated by L2 address inclusion but not truncated redundant address resolution protocol for such a situation.

Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, November 4, 2021 12:43 AM
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Subject: Re: Accurate history [Re: "professional" in an IETF context]

Eduardo,
On 03-Nov-21 21:31, Vasilenko Eduard wrote:
> Then why Address Resolution Protocol was needed in principle? (ND or 
> whatever) If the L3 address always had an L2 address inside?

    Brian

> I think you are not familiar with the CLNP NSAPA GOSIP addressing 
> model. As RFC1526 clearly explains, the CLNP address architecture 
> proposed for the Internet embodied an ID field that could be an IEEE 
> MAC address (see section 3.1 in particular). That's how DECnet/OSI 
> worked, too. (And Novell Netware, copied from Xerox PUP, a.k.a. XNS.)
> 
>> Many people are coming and coming asking that they would like too to 
>> get some bits of IPv6 address for some new protocol.> Eduard
>

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 5 Nov 2021 00:10:20 +0900

> whatever) If the L3 address always had an L2 address inside?

There is no such specification in rfc1526 to mandate "L3 address
always had an L2 address inside", which means ARP is necessary for
other address formats, which means optional specification of
"L3 address always had an L2 address inside" was purposelessly
specified.

> The OSI was calling for layers isolation. It was a big deal for OSI.

According to wikipedia

    https://en.wikipedia.org/wiki/Abstraction_layer
    In computing, an abstraction layer or abstraction level is a
    way of hiding the working details of a subsystem, allowing
    the separation of concerns to facilitate interoperability
    and platform independence.

that is, isolation/separation should be a property of layering
in general not specific to OSI.

> inserted into each other.

See above that layering is merely "allowing the separation", not
forcing the separation. As such, even with a properly layered
protocol, you can have implementations actively destroying the
separation, though, I think them purposelessly complicated.

					Masataka Ohta

PS

Existence of running code for some specification means
not that the specification is good but that we can
operate and evaluate the specification to judge whether
it is good or not.

						Masataka Ohta

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 4 Nov 2021 08:27:02 -0700

> operate and evaluate the specification to judge whether

This, surprisingly, can't be said enough. I've repeatedly heard the
argument that someone's running code is verification that the idea is
sound, and therefore the solution should be adopted. And I can rarely tell
if they are simply lacking any sense of architecture or if they are just
trolling the group to push their work. Either way, it's exhausting.

- Shep

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Nov 2021 11:03:56 -0500

Folks,

I am unable to understand what Ohta-san or Vasilenko are trying to achieve,
I sympathize with those who expressed concern on the running code that
lacks architecture.
 I think this discussion is at least 10 years late. We can not get IPv6 to
have 64 bit addresses at this point.
It is just simply time-consuming and unnecessary "gossiping".

It would probably be more productive to propose to start new activity on
Next Generation IP and see if it goes somewhere in IETF. Even if it goes,
remember IP is the base protocol and changing the base shakes things all
the way up. So then we restart  and possibly redo many things that have
been done long ago when IPv6 standardization was finished.

Behcet

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 4 Nov 2021 16:13:23 +0000

Behcet Sarikaya wrote on 04/11/2021 16:03:
> I think this discussion is at least 10 years late.

*26 years too late.

It seems to be a thing to bring ipv6 design considerations out for a 
ritual flogging every couple of years.  Best to ignore it when it happens.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 4 Nov 2021 16:23:03 +0000

If the reasoning is non-technical (political or business)
then running code is about “how many people are behind it”.
Make sense for “consensus” that is the product of political debates.
Hence, “running code” is not trolling – it is the search for additional arguments in the political debates.

The running code should be massively deployed to prove anything in Architecture.
Eduard
From: ietf [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, November 4, 2021 6:27 PM
To: Masataka Ohta <[email-masked]>
Cc: IETF discussion list <[email-masked]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

                                                Masataka Ohta

This, surprisingly, can't be said enough. I've repeatedly heard the argument that someone's running code is verification that the idea is sound, and therefore the solution should be adopted. And I can rarely tell if they are simply lacking any sense of architecture or if they are just trolling the group to push their work. Either way, it's exhausting.

- Shep

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 4 Nov 2021 16:26:41 +0000

The fact that IPv6 is not possible to extend above 64 bits is more or less important by itself.

Interface ID is still not used for something usefull, but ND creates a lot of problems.
It is still possible to return it to MAC and cancel the biggest part of the ND that creates a lot of problems.

Eduard
From: ietf [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday, November 4, 2021 7:04 PM
To: IETF <[email-masked]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

Folks,

I am unable to understand what Ohta-san or Vasilenko are trying to achieve,
I sympathize with those who expressed concern on the running code that lacks architecture.
 I think this discussion is at least 10 years late. We can not get IPv6 to have 64 bit addresses at this point.
It is just simply time-consuming and unnecessary "gossiping".

It would probably be more productive to propose to start new activity on Next Generation IP and see if it goes somewhere in IETF. Even if it goes, remember IP is the base protocol and changing the base shakes things all the way up. So then we restart  and possibly redo many things that have been done long ago when IPv6 standardization was finished.

Behcet

On Thu, Nov 4, 2021 at 10:10 AM Masataka Ohta <[email-masked]<mailto:[email-masked]>> wrote:

According to wikipedia

                                        Masataka Ohta

PS

                                                Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Thu, 4 Nov 2021 12:53:56 -0400

On 11/4/21 12:26 PM, Vasilenko Eduard wrote:

> It is still possible to return it to MAC and cancel the biggest part 
> of the ND that creates a lot of problems.
>
For privacy reasons alone, I'd say that's a non-starter.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Nov 2021 22:19:08 -0400

> trolling the group to push their work. Either way, it's exhausting.

The fact someone can get code to run does suggest that they have a solution
to at least a part of the problem. It rarely means they have a complete
solution.

But I have on multiple occasions received the following objections to a
proposal.

1) We don't believe your specification without code.

2) You are only here to peddle the code you have already written, you
should have talked to people earlier.

And it's the same damn people both times.

Men should really take more notice when women complain about mansplaining
because the people who do that to women do the exact same thing to other
men.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 5 Nov 2021 14:23:45 +0900

Greg Shepherd wrote:

> argument that someone's running code is verification that the idea
> is sound,

If "sound" means no ambiguity or contradiction is found
in the specification under the environment assumed by the
code, you are right.

But, it may merely be that ambiguities or contradictions
are overlooked by implementers.

Moreover, there may be ambiguities or contradictions under
other environments.

Worse, lack of ambiguity or contradiction in the specification
only means it "sound" but not good, useful nor worth adopting.

So, existence of running code does not mean so much.

But, as no code is required to make something PS,
specifications with ambiguity/contradiction often
become PSes.

> and therefore the solution should be adopted.

Totally wrong.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 5 Nov 2021 14:39:00 +0900

> I am unable to understand what Ohta-san or Vasilenko are trying to achieve,

My point is just that IETF should accept the operational reality
that IPv6 is not and will not be deployed so widely, with reasons,
to reach the critical mass and deployment schemes today require
NAT, we should abandon IPv6 and live with IPv4 and NAT.

> I think this discussion is at least 10 years late.

That's one of a reason why IPv6 is hopeless, though there are so
many other reasons.

							Masataka Ohta

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 5 Nov 2021 07:55:19 +0000

Privacy is a myth.

OTTs deliver 70% of traffic. They could correlate users by 100 parameters (including your browser window size).
Just changing IID would not impact their correlation. Not at all.

Your carrier has to know all your sessions for Lawful Intercept.

Whom you are trying to mislead by IID changes?

It just creates a heavy load on logs collection for troubleshooting, forensic, and legal intercept.

Eduard
From: ietf [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Thursday, November 4, 2021 7:54 PM
To: [email-masked]
Subject: Re: Accurate history [Re: "professional" in an IETF context]

Keith

---

From: Scott Bradner <[email-masked]>
Date: Fri, 5 Nov 2021 05:50:24 -0400

> On Nov 5, 2021, at 1:39 AM, Masataka Ohta <[email-masked]> wrote:
...

> NAT, we should abandon IPv6 and live with IPv4 and NAT.

https://www.google.com/intl/en/ipv6/statistics.html - total IPv6 at Google 32.41%

---

From: [email-masked]
Date: Fri, 5 Nov 2021 10:58:39 +0100

> https://www.google.com/intl/en/ipv6/statistics.html - total IPv6 at Google 32.41%

Perhaps a better lithmus test would be:
"Would an end-user notice if IPv6 was removed from his/her/it's host?"

O.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 5 Nov 2021 10:00:31 +0000

> https://www.google.com/intl/en/ipv6/statistics.html  - total IPv6 at Google 32.41%

I suspect, without direct evidence to hand, that these figures are 
heavily weighted by small numbers of larger carriers pulling content 
from small numbers of larger content networks.  There is a long tail of 
sites and networks that are not ipv6-enabled now, and are likely not to 
ever deploy the protocol, at no particular disadvantage to themselves.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 5 Nov 2021 11:10:58 +0000

In reality, this number is close to 45% for IPv6 users,
Because Google (and APNIC as a result) see only 128M of Chinese,
But China itself reports 528M.

We could estimate IPv6 traffic at 30% because different sources show that 70% of the content is available on IPv6
(except China where this number is much smaller!).

IMHO: IPv6 has strong adoption in Telco.
We could argue: is it a brute force approach from governments
or geeks justifying their jobs on OTT's side?
Difficult to find a business here.
But anyway, it is moving to IPv6.

What is important: Enterprises have no clear sign of IPv6 adoption.
ND protocol has a heavy influence on this.
Of course, ND is not the only reason. But maybe the biggest one.

Eduard
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Friday, November 5, 2021 1:01 PM
To: Scott Bradner <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

> https://www.google.com/intl/en/ipv6/statistics.html  - total IPv6 at 

I suspect, without direct evidence to hand, that these figures are heavily weighted by small numbers of larger carriers pulling content from small numbers of larger content networks.  There is a long tail of sites and networks that are not ipv6-enabled now, and are likely not to ever deploy the protocol, at no particular disadvantage to themselves.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 5 Nov 2021 11:22:31 +0000

> "Would an end-user notice if IPv6 was removed from his/her/it's host?"

this would not be the only important test.  Another would be: if ipv6 
were removed from the entire user base, would the operator notice, and 
if it were bad enough, would the end user notice - e.g. pricing, 
video-provider dropping out due to NAT session concurrency problems, CGN 
hardware/software total-cost-of-ownership, etc.

ipv4 will not go away until there is a compelling reason to abandon it 
in favour of ipv6 or another future protocol.  One reason to sit up and 
take notice is that ipv4 addresses currently cost $50/each, so if you 
need lots of ipv4 addresses, they are now a commodity which may make a 
difference to your bottom line.

Conversely there are plenty of organisations in some parts of the world 
that have more than enough ipv4 address space for their needs.

Dislodging organically evolved protocols is always difficult and often 
impossible.

Nick

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 5 Nov 2021 12:09:40 +0000

> On 5 Nov 2021, at 11:10, Vasilenko Eduard <[email-masked]> wrote:
> 

Indeed, and I have had a consistent complaint from a British security conscious large private sector technology savvy company, that IPv6 is so much harder to secure than IPv4 they have no interest in moving. I think that part of this is the conflict between the privacy that IPv6 offers and their need to know that *every* packet on their network is entitled to be there doing what it is doing.

- Stewart

---

From: [email-masked]
Date: Fri, 5 Nov 2021 13:33:57 +0100

Changed subject to reflect discussion.

> Indeed, and I have had a consistent complaint from a British security conscious large private sector technology savvy company, that IPv6 is so much harder to secure than IPv4 they have no interest…

"If we had just one more transition mechanism, or if IPv6 had just behaved this way, then it would have been deployed".

I think that's a fallacy. There are many reasons why IPv6 didn't replace IPv4. Including business models, centralisation of the Internet etc.

Regarding ND, you can operate IPv6 pretty much like you operate an IPv4 network.
Single address to the host, even private address if you so prefer.
(By pushing NAT64 we ensured that all IPv6 applications have to be NAT aware anyway).

O.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 5 Nov 2021 23:09:42 +0900

> ever deploy the protocol, at no particular disadvantage to themselves.

Yup, that is the essential point.

Most small providers will keep offering IPv4 only services, because
it costs less than offering dual stack or IPv6 only with NAT
services, which is a not so direct evidence against IPv6.

					Masataka Ohta

---

From: Geoff Huston <[email-masked]>
Date: Fri, 5 Nov 2021 19:40:26 +0000

> On 5 Nov 2021, at 9:00 pm, Nick Hilliard <[email-masked]> wrote:
> 

More generally, I suspect that it's a case of sampling bias. Whenever you generalise from a samped set to a more general observation you need to understand to what extent the sample is made, and how the nature of the sample impacts the general result. The most striking example in Google’s IPv6 numbers if China, where the 1.34% number reported in that Google URL appears to be anomalously low. Akamai measure some 22% for China [1]. APNIC measures 20% [2] Given the significant user population within China (800M) thats a pretty major difference. 

It's also a case of what is being measured. Traffic Volume? Session Count? Eyeballs? 

All of these measurement programs are capable of providing a decent picture at the general level but each have their failings as you move in closer to get a more granular view.

Geoff

[1] https://www.akamai.com/visualizations/state-of-the-internet-report/ipv6-adoption-visualization
[2] https://stats.labs.apnic.net/ipv6/CN

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 08:48:31 +1300

On 06-Nov-21 00:22, Nick Hilliard wrote:
> in favour of ipv6 or another future protocol.

That's always been the plan. Coexistence was always the design target.

    Brian

> One reason to sit up and

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 08:56:49 +1300

On 06-Nov-21 08:40, Geoff Huston wrote:
> More generally, I suspect that it's a case of sampling bias. Whenever you generalise from a samped set to a more general observation you need to 
understand to what extent the sample is made, and how the nature of the sample impacts the general result. The most striking example in Google’s IPv6 numbers if China, where the 1.34% number reported in that Google URL appears to be anomalously low. Akamai measure some 22% for China [1]. APNIC measures 20% [2] Given the significant user population within China (800M) thats a pretty major difference.
> It's also a case of what is being measured. Traffic Volume? Session Count? Eyeballs?

In Google's case, the IPv6 percentage depends  only on the IP version number used by a
random sample of Google users:

Lorenzo Colitti, Steinar H. Gunderson, Erik Kline, and Tiziana Refice. 2010. Evaluating
IPv6 adoption in the Internet. In PAM 2010.
http://www.pam2010.ethz.ch/papers/full-length/15.pdf

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 09:13:06 +1300

On 06-Nov-21 01:09, Stewart Bryant wrote:
> 
> 
>> On 5 Nov 2021, at 11:10, Vasilenko Eduard <[email-masked] <mailto:[email-masked]>> wrote:
>>

You can administratively disable "privacy" (temporary) addresses, but most sites find it safer to perform access control based on MAC addresses. Temporary addresses are intended to confuse the outside world, not the local network operator. They are *intended* to make lawful intercept harder. That's a feature, not a bug. I agree that they also make debugging harder, which may be another reason to disable them.

Complaining about ND seems odd if sites tolerate ARP. Anybody else remember ARP storms? ND was designed to avoid that risk.

All these are FUD arguments used in support of operational inertia.

     Brian

---

From: Vasilenko Eduard <[email-masked]>
Date: Sun, 7 Nov 2021 11:00:16 +0000

If it is the best practice to disable "temporary addresses" (because it is fake privacy anyway)
Then what is the purpose of waisting (2^64-1)/2^64 of IPv6 addresses space?
The next reason could be to greatly simplify Address Resolution Protocol (some link parameters still make sense to broadcast).

Or else, we have to accept that half of the address bits are just the garbage that every node needs to store and process.
Except for a few bits that are needed on many subnets anyway to organize local connectivity.

About ARP storm:
ND has much bigger DoS capabilities because
- 2^64 subnet permits to push the router to find all 2^64 addresses, it could be done even from outside of the subnet
- temporarily addresses 10x increase the load on the protocol and the same on the log and correlation engine (for LI, forensic, and troubleshooting)
It is famous how WiFi degrades on any physical IETFevent because of the huge number of multicasts per second.
All of these multicasts would not be needed if MAC would be inside every IPv6 address as it was intended initially.
It is the best use for these 64bits.

Eduard
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, November 5, 2021 11:13 PM
To: Stewart Bryant <[email-masked]>; Vasilenko Eduard <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 8 Nov 2021 10:21:32 +1300

> If it is the best practice to disable "temporary addresses" (because it is fake privacy anyway)

I didn't say it was best practice. I expect it to be a common practice in enterprise networks, but the reason it's the recommended default for operating systems is so that individuals will benefit from the small amount of privacy it offers.

> Then what is the purpose of waisting (2^64-1)/2^64 of IPv6 addresses space?

We've debated this so often; I can only suggest reading RFC7136 and RFC7421 again, and the whole debate around the abandoned draft-ietf-6man-rfc4291bis. There is no consensus in the IETF for changing the /64 boundary.

> ND has much bigger DoS capabilities because
ARP storms were not DOS attacks; they were bugs built into combining certain IPv4 implementations with spanning tree bridges.

> It is famous how WiFi degrades on any physical IETFevent because of the huge number of multicasts per second.

Sure. Building a single /64 that big is a very debatable design choice. The principle fix for ARP storms (and other forms of broadcast storms in IPv4) was subnetting. The same should apply to IPv6 network design.

> It is the best use for these 64bits.

It's said that to make any Internet problem harder, just say "multicast". And it's true. But the real culprit here isn't "multicast", it's "scaling". Subnetting is the right answer and there is no shortage of /64s in the universe.

     Brian

---

From: Erik Kline <[email-masked]>
Date: Sun, 7 Nov 2021 13:58:44 -0800

>
> > All of these multicasts would not be needed if MAC would be inside every
> IPv6 address as it was intended initially.
> It's said that to make any Internet problem harder, just say "multicast".
> And it's true. But the real culprit here isn't "multicast", it's "scaling".
> Subnetting is the right answer and there is no shortage of /64s in the
> universe.
>
>      Brian
>

<no hats>

For general purpose hosts I agree.  I think the 3GPP/RFC 8273 model has
some nice simplicity to offer.  Some of the complexity moves to managing
host attachment and migration, but perhaps that's something worthy of
further IETF study and development.

> >>> On 5 Nov 2021, at 11:10, Vasilenko Eduard <[email-masked]
> <mailto:[email-masked]>> wrote:
> >>>
> >> Indeed, and I have had a consistent complaint from a British security
> conscious large private sector technology savvy company, that IPv6 is so
> much harder to secure than IPv4 they have no interest in moving. I think
> that part of this is the conflict between the privacy that IPv6 offers and
> their need to know that *every* packet on their network is entitled to be
> there doing what it is doing.
> >
> >
> > You can administratively disable "privacy" (temporary) addresses, but
> most sites find it safer to perform access control based on MAC addresses.
> Temporary addresses are intended to confuse the outside world, not the
> local network operator. They are *intended* to make lawful intercept
> harder. That's a feature, not a bug. I agree that they also make debugging
> harder, which may be another reason to disable them.
> >
> > Complaining about ND seems odd if sites tolerate ARP. Anybody else
> remember ARP storms? ND was designed to avoid that risk.
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 8 Nov 2021 09:06:24 +0000

RFC7136 section 5: "In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values."
Sorry, It is not an Architecture, if half of the bits of IPv6 address is left for "whatever you want".
Effectively, the second half of the IPv6 address is metadata that is mandatory to process by all intermediate nodes
even if it is not used
because it is a part of the basic header.
Ed/
-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, November 8, 2021 12:22 AM
To: Vasilenko Eduard <[email-masked]>; Stewart Bryant <[email-masked]>
Cc: IETF <[email-masked]>
Subject: Re: Accurate history [Re: "professional" in an IETF context]

> - 2^64 subnet permits to push the router to find all 2^64 addresses, 
> it could be done even from outside of the subnet
> - temporarily addresses 10x increase the load on the protocol and the 
> same on the log and correlation engine (for LI, forensic, and troubleshooting) It is famous how WiFi degrades on any physical IETFevent because of the huge number of multicasts per second.

     Brian

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 8 Nov 2021 23:13:31 +0900

> About ARP storm:

For the accurate history, ARP storm was a problem about 30 or 35
years ago, when some network managers were putting *thousands* of
hosts in a single broadcast domain. Then, as switch implementations
were too often buggy, broadcast storm was a rare but serious problem
of the managers and it was sometimes called ARP storm because
ARP is the major protocol to use broadcast.

Though IP people at that time were happy with small subnets
divided by routers following the CATENET model, the reasoning
to have large broadcast domain was that managing routers to
support multiple L3 protocols is painful, which is still so
for management of routers supporting both IPv4 and IPv6.

IIRC, Brian was a such manager.

But, as IPv4 became the only protocol worth supporting, Ethernet
broadcast domain became small divided by IPv4-only routers and
switch implementations became not so buggy, ARP storm is not a
problem today at all.

> ND has much bigger DoS capabilities because

Though many people who insists on IPv6 totally misunderstand,
broadcast ban by IPv6 is totally meaningless as requiring to
support all host multicast instead of broadcast is as bad (it
is actually not bad) as supporting broadcast.

Though I have found that, these days, some people says "ARP storm"
mean some compromised host generates a lot of broadcast ARP packets,
it is no worse than the host generates a lot of all-host-multicast
ND packets.

As such, ND is no better than ARP.

						Masataka Ohta