Re: IPv6 "bloat"

[Masataka Ohta]

Michael Thomas wrote:

So out of the current discussions a lot of people have claimed that ipv6 
is bloated or suffers from second system syndrome, etc.


IPv6 optional header chain, even after it was widely recognized
that IPv4 options are useless/harmful and were deprecated is an
example of IPv6 bloat.

Extensive use of link multicast for nothing is another example
of IPv6 bloat. Note that IPv4 works without any multicast.

So I decided to 
look at a linux kernel (HEAD I assume) and look at the differences 
between the v6 and v4 directories.


See above. That is an improper way to evaluate IPv6 bloat.

An example of second system syndrome of over-engineering
without bloat is various timing parameters specified
for ND, even though timing requirements are different
depending on link types, which means there can be no
standard timing parameters applicable to all the link
types.

Another example of over-engineering is SLAAC to
*statefully* maintain address configuration state
in fully distributed way only to promote
inconsistencies requiring DAD.

An example of under-engineering is lack of the
following consideration of rfc791:

The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information.  For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram.  The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.

as IPv6 optional headers can be arbitrary lengthy, it is not
guaranteed that 512B DNS message can be sent over UDP over
IPv6.

And, there are a lot lot lot more.

Masataka Ohta

Re: IPv6 "bloat"

[Crist Clark]

This is going to be one of the big things the US Federal govt requirements
for agencies to meet the IPv6-only benchmarks will need. Solutions and
products are going to have to mature quickly for agencies to hit 80%
IPv6-only by end of FY25.

On Sun, Mar 20, 2022 at 4:38 PM Owen DeLong via NANOG 
wrote:

>
>
> On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe 
> wrote:
>
> It seems sketchy to me to even retain client MAC information, no? Genuine
> question.
>
> Didn’t we go to a distinct unique identifier system for this very reason?
>
> Am I in the 1990s here or?
>
> We’re just handing out addresses to UEs and things seem to work fine.  For
> me personally, I find the notation of v6 to be very unasthetic, so I tend
> to just conceal it from myself now.
>
>
> Correct me if I’m wrong, but it sounds like you’re viewing this from a
> service provider perspective, in which case everything you’ve said is
> basically correct.
>
> However, the enterprise world is very different. Right, wrong, or
> otherwise, many enterprises feel a strong compulsion to have very strict
> control over addressing and relatively direct accountability of “x address
> = y employee” (regardless of whether that’s actually true or not).
>
> In those environments, yes, IPv6 does present a learning curve and some
> additional challenges. They are not insurmountable and if you were starting
> from scratch needing to build your enterprise on IPv6, it would actually be
> less difficult than IPv4. IPv4, however, has the advantage of well trodden
> paths for enterprise solutions in this space. IPv6 will get there as more
> enterprises start to deploy IPv6, but right now both sides of that process
> suffer from the classic chicken/egg problem. The problem is slow to get
> solved because there are no chickens asking for a solution. Chickens aren’t
> asking for it because there are no eggs to create chickens that need IPv6.
>
> Owen
>
>
> -LB
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> b...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME
> 
>
> FCC License KJ6FJJ
>
>
>
>
> On Mar 19, 2022, at 3:56 PM, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
>
>
>
> On 3/19/22 6:50 PM, Michael Thomas wrote:
>
> On 3/19/22 3:47 PM, Matt Hoppes wrote:
>
> It has "features" which are at a minimum problematic and at a maximum show
> stoppers for network operators.
>
> IPv6 seems like it was designed to be a private network communication
> stack, and how an ISP would use and distribute it was a second though.
>
> What might those be? And it doesn't seem to be a show stopper for a lot of
> very large carriers.
>
>
> Primarily the ability to end-to-end authenticate end devices.   The
> primary and largest glaring issue is that DHCPv6 from the client does not
> include the MAC address, it includes the (I believe) UUID.
>
> We have to sniff the packets to figure out the MAC so that we can
> authenticate the client and/or assign an IP address to the client properly.
>
> It depends how you're managing the network.  If you're running PPPoE you
> can encapsulate in that.   But PPPoE is very 1990 and has its own set of
> problems.  For those running encapsulated traffic, authentication to the
> modem MAC via DHCP that becomes broken.  And thus far, I have not seen a
> solution offered to it.
>
>
> Secondly - and less importantly to deployment, IPv6 also provides a layer
> of problematic tracking for advertisers.  Where as before many devices were
> behind a PAT, now every device has a unique ID -- probably for the life of
> the device. Marketers can now pinpoint down not just to an IP address that
> identifies a single NAT interface, but each individual device.  This is
> problematic from a data collection standpoint.
>
>
>
>

Re: IPv6 "bloat"

[Owen DeLong via NANOG]

> On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe  
> wrote:
> 
> It seems sketchy to me to even retain client MAC information, no? Genuine 
> question.
> 
> Didn’t we go to a distinct unique identifier system for this very reason?
> 
> Am I in the 1990s here or?
> 
> We’re just handing out addresses to UEs and things seem to work fine.  For me 
> personally, I find the notation of v6 to be very unasthetic, so I tend to 
> just conceal it from myself now.

Correct me if I’m wrong, but it sounds like you’re viewing this from a service 
provider perspective, in which case everything you’ve said is basically correct.

However, the enterprise world is very different. Right, wrong, or otherwise, 
many enterprises feel a strong compulsion to have very strict control over 
addressing and relatively direct accountability of “x address = y employee” 
(regardless of whether that’s actually true or not).

In those environments, yes, IPv6 does present a learning curve and some 
additional challenges. They are not insurmountable and if you were starting 
from scratch needing to build your enterprise on IPv6, it would actually be 
less difficult than IPv4. IPv4, however, has the advantage of well trodden 
paths for enterprise solutions in this space. IPv6 will get there as more 
enterprises start to deploy IPv6, but right now both sides of that process 
suffer from the classic chicken/egg problem. The problem is slow to get solved 
because there are no chickens asking for a solution. Chickens aren’t asking for 
it because there are no eggs to create chickens that need IPv6.

Owen

> 
> -LB
> 
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> b...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME 
> 
> FCC License KJ6FJJ
> 
> 
> 
> 
>> On Mar 19, 2022, at 3:56 PM, Matt Hoppes > > wrote:
>> 
>> 
>> 
>> On 3/19/22 6:50 PM, Michael Thomas wrote:
>>> On 3/19/22 3:47 PM, Matt Hoppes wrote:
 It has "features" which are at a minimum problematic and at a maximum show 
 stoppers for network operators.
 
 IPv6 seems like it was designed to be a private network communication 
 stack, and how an ISP would use and distribute it was a second though.
>>> What might those be? And it doesn't seem to be a show stopper for a lot of 
>>> very large carriers.
>> 
>> Primarily the ability to end-to-end authenticate end devices.   The primary 
>> and largest glaring issue is that DHCPv6 from the client does not include 
>> the MAC address, it includes the (I believe) UUID.
>> 
>> We have to sniff the packets to figure out the MAC so that we can 
>> authenticate the client and/or assign an IP address to the client properly.
>> 
>> It depends how you're managing the network.  If you're running PPPoE you can 
>> encapsulate in that.   But PPPoE is very 1990 and has its own set of 
>> problems.  For those running encapsulated traffic, authentication to the 
>> modem MAC via DHCP that becomes broken.  And thus far, I have not seen a 
>> solution offered to it.
>> 
>> 
>> Secondly - and less importantly to deployment, IPv6 also provides a layer of 
>> problematic tracking for advertisers.  Where as before many devices were 
>> behind a PAT, now every device has a unique ID -- probably for the life of 
>> the device. Marketers can now pinpoint down not just to an IP address that 
>> identifies a single NAT interface, but each individual device.  This is 
>> problematic from a data collection standpoint.
>> 
> 

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Greg Skinner via NANOG]

I was referring to the relative number of responses to the most recent Schoen 
IPv4 maintenance draft at the link you gave (quoted by me), as compared to the 
responses here on the NANOG list.  Sorry if that wasn’t clear.

I would argue that Schoen and the co-authors of that draft have spent time 
researching the problem and past discussions.  For example, see the discussion 
on the internet-history list about the history of 0/8 
.

—gregbo

> On Mar 20, 2022, at 11:26 AM, Tom Beecher  wrote:
> 
> I wouldn’t assume that the small number of responses indicates a lack of 
> interest.  It’s possible that people haven’t commented because they’ve seen 
> this topic play itself out over the years, and although they have opinions, 
> they don’t feel compelled to post them there.  (Interestingly enough, some 
> have posted them here.)  Another possibility is that they’re waiting until 
> the draft is presented later this week before expressing their opinions.
> 
> There are quite a few responses. All expressed zero interest.
> 
> This is a pretty common pattern. Someone comes up with an idea, spends zero 
> time researching the history of the problem or previous discussions,and 
> submits it to the IETF. People point out that it's been discussed before,and 
> they aren't interested,but the submitter stamps their feet because nobody is 
> LISTENING to them. 
> 
> On Sun, Mar 20, 2022 at 1:14 PM Greg Skinner via NANOG  > wrote:
> 
> 
> > On Mar 15, 2022, at 7:04 PM, Mark Andrews  > > wrote:
> > 
> > 
> > Firstly nobody uses mailing list digests as references.  Secondly anyone 
> > can post to the mailing list, you just need to subscribe.  If you read the 
> > thread you can see there is no interest in this.
> > 
> > https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/ 
> > 
> > 
> 
> I wouldn’t assume that the small number of responses indicates a lack of 
> interest.  It’s possible that people haven’t commented because they’ve seen 
> this topic play itself out over the years, and although they have opinions, 
> they don’t feel compelled to post them there.  (Interestingly enough, some 
> have posted them here.)  Another possibility is that they’re waiting until 
> the draft is presented later this week before expressing their opinions.
> 
> —gregbo
> 
> 

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Tom Beecher]

>
> I wouldn’t assume that the small number of responses indicates a lack of
> interest.  It’s possible that people haven’t commented because they’ve seen
> this topic play itself out over the years, and although they have opinions,
> they don’t feel compelled to post them there.  (Interestingly enough, some
> have posted them here.)  Another possibility is that they’re waiting until
> the draft is presented later this week before expressing their opinions.
>

There are quite a few responses. All expressed zero interest.

This is a pretty common pattern. Someone comes up with an idea, spends zero
time researching the history of the problem or previous discussions,and
submits it to the IETF. People point out that it's been
discussed before,and they aren't interested,but the submitter stamps their
feet because nobody is LISTENING to them.

On Sun, Mar 20, 2022 at 1:14 PM Greg Skinner via NANOG 
wrote:

>
>
> > On Mar 15, 2022, at 7:04 PM, Mark Andrews  wrote:
> >
> >
> > Firstly nobody uses mailing list digests as references.  Secondly anyone
> can post to the mailing list, you just need to subscribe.  If you read the
> thread you can see there is no interest in this.
> >
> >
> https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/
> >
>
> I wouldn’t assume that the small number of responses indicates a lack of
> interest.  It’s possible that people haven’t commented because they’ve seen
> this topic play itself out over the years, and although they have opinions,
> they don’t feel compelled to post them there.  (Interestingly enough, some
> have posted them here.)  Another possibility is that they’re waiting until
> the draft is presented later this week before expressing their opinions.
>
> —gregbo
>
>
>

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[John Levine]

It appears that Abraham Y. Chen  said:
>     C.    Recently, we were made aware of the Int-Area activities. 
>Attempts to reach the Group Chairs have not received any responses.
>
>     D.    I just received an Int-Area Digest Vol 199, Issue 14 
>requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Greg Skinner via NANOG]

> On Mar 15, 2022, at 7:04 PM, Mark Andrews  wrote:
> 
> 
> Firstly nobody uses mailing list digests as references.  Secondly anyone can 
> post to the mailing list, you just need to subscribe.  If you read the thread 
> you can see there is no interest in this.
> 
> https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/
> 

I wouldn’t assume that the small number of responses indicates a lack of 
interest.  It’s possible that people haven’t commented because they’ve seen 
this topic play itself out over the years, and although they have opinions, 
they don’t feel compelled to post them there.  (Interestingly enough, some have 
posted them here.)  Another possibility is that they’re waiting until the draft 
is presented later this week before expressing their opinions.

—gregbo

Re: IPv6 "bloat"

[Lady Benjamin Cannon of Glencoe]

It seems sketchy to me to even retain client MAC information, no? Genuine 
question.

Didn’t we go to a distinct unique identifier system for this very reason?

Am I in the 1990s here or?

We’re just handing out addresses to UEs and things seem to work fine.  For me 
personally, I find the notation of v6 to be very unasthetic, so I tend to just 
conceal it from myself now.

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
b...@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ




> On Mar 19, 2022, at 3:56 PM, Matt Hoppes  
> wrote:
> 
> 
> 
> On 3/19/22 6:50 PM, Michael Thomas wrote:
>> On 3/19/22 3:47 PM, Matt Hoppes wrote:
>>> It has "features" which are at a minimum problematic and at a maximum show 
>>> stoppers for network operators.
>>> 
>>> IPv6 seems like it was designed to be a private network communication 
>>> stack, and how an ISP would use and distribute it was a second though.
>> What might those be? And it doesn't seem to be a show stopper for a lot of 
>> very large carriers.
> 
> Primarily the ability to end-to-end authenticate end devices.   The primary 
> and largest glaring issue is that DHCPv6 from the client does not include the 
> MAC address, it includes the (I believe) UUID.
> 
> We have to sniff the packets to figure out the MAC so that we can 
> authenticate the client and/or assign an IP address to the client properly.
> 
> It depends how you're managing the network.  If you're running PPPoE you can 
> encapsulate in that.   But PPPoE is very 1990 and has its own set of 
> problems.  For those running encapsulated traffic, authentication to the 
> modem MAC via DHCP that becomes broken.  And thus far, I have not seen a 
> solution offered to it.
> 
> 
> Secondly - and less importantly to deployment, IPv6 also provides a layer of 
> problematic tracking for advertisers.  Where as before many devices were 
> behind a PAT, now every device has a unique ID -- probably for the life of 
> the device. Marketers can now pinpoint down not just to an IP address that 
> identifies a single NAT interface, but each individual device.  This is 
> problematic from a data collection standpoint.
> 

Re: BOOTP & ARP history

[Masataka Ohta]

John Gilmore wrote:


There were tons of things that were slapped onto IP that were basically
experimental like ARP and bootp. CIDR didn't even exist back then.



ARP was "slapped on" in 1982, long before RARP or BOOTP.  The original
IP specs required that the LAN address must fit into the low order bits
of your IP netblock.  This wasn't well thought through, but IP was an
experiment and there were very few other experiments for its designers
to learn from.


Like RIP, wasn't the the feature imported from XNS?


It worked ok when ARPANET was your LAN (see the original
use of 10/8), and when everybody else had Class A addresses, like the
packet radio network or 3-megabit Experimental Ethernet users.  But it
didn't scale up, and it didn't work at all for 10-megabit industry
standard Ethernet, with 48-bit addresses much longer than IP addresses.


Wow! However, even with very long 128bit IPv6 addresses, which was
originally specified 10+6 (or 80+48 where '6' means 6*8=48 bits of
Ethernet MAC) was not enough when I pointed out that MAC address
of IEEE1394 is 64 bits long, after which, IPv6 address became 8+8,
which means layering violation to make L3 address format depends
on L2 address length.

Worse, these days, MAC address is not used for lower part of IPv6
addresses for privacy reasons.

So, ARP is not something slapped in but the correct thing to do
not to cause serious layering violations so much shunned by OSI.

IPv6, along with ND, is something politically slapped in against
IETF consensus to ban CLNP without technical/operational reasons
and is totally broken.

Masataka Ohta

Re: IPv6 "bloat"

[Enno Rey]

Hi,

On Sat, Mar 19, 2022 at 07:11:47PM -0400, Matt Hoppes wrote:
> I misspoke... it's not UUID... It's DUID.
> 
> This isn't a backend management issue.  This is a protocol issue.  The 
> MAC of the interface needs to be sent with a DHCP request so that it can 
> be properly authenticated to the physical device.
> 
> As long as the client and DHCPv6 server are on the same network 
> interface -- it all works fine.  However, when you relay that 
> information, you now lose the MAC address information.

RFC 6939 solves that, since a long time.
See also: 
https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/


> 
> Further, because the MAC is disconnected in IPv6 it becomes more 
> difficult to make the connection between IPs on a dual-stack client.

Not sure if I agree with that either. That connection can be made by various 
other means, see
https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/

cheers

Enno






> 
> Everyone prints the MAC (a unique ID on devices and devices packaging). 
> Almost nobody prints the DUID on a device, so how do you pre-populate 
> your DHCP server?  I can see that it encourages "one interface per 
> network" and so encourages bonding, bridging or whatever, but is being 
> able to differentiate the interfaces of a host really so bad? I can't 
> help but feel that it would have been nice for DHCPv6 to send DUID and MAC.
> 
> 
> 
> On 3/19/22 7:03 PM, Michael Thomas wrote:
> > 
> > On 3/19/22 3:56 PM, Matt Hoppes wrote:
> >>
> >>
> >> On 3/19/22 6:50 PM, Michael Thomas wrote:
> >>>
> >>> On 3/19/22 3:47 PM, Matt Hoppes wrote:
>  It has "features" which are at a minimum problematic and at a 
>  maximum show stoppers for network operators.
> 
>  IPv6 seems like it was designed to be a private network 
>  communication stack, and how an ISP would use and distribute it was 
>  a second though.
> >>>
> >>> What might those be? And it doesn't seem to be a show stopper for a 
> >>> lot of very large carriers.
> >>
> >> Primarily the ability to end-to-end authenticate end devices. The 
> >> primary and largest glaring issue is that DHCPv6 from the client does 
> >> not include the MAC address, it includes the (I believe) UUID.
> >>
> >> We have to sniff the packets to figure out the MAC so that we can 
> >> authenticate the client and/or assign an IP address to the client 
> >> properly.
> >>
> >> It depends how you're managing the network.?? If you're running PPPoE 
> >> you can encapsulate in that. But PPPoE is very 1990 and has its own 
> >> set of problems.?? For those running encapsulated traffic, 
> >> authentication to the modem MAC via DHCP that becomes broken.?? And 
> >> thus far, I have not seen a solution offered to it.
> > 
> > I was honestly more interested in the bloat angle, but this sounds like 
> > a backend problem of your own making most likely. But I'm not motivated 
> > to see if it's actually the case or just a misunderstanding.

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator

Re: V6 still not supported

[Masataka Ohta]

Matt Hoppes wrote:

At this point I would *love* to see IPv4 get extended, a software patch 
applied to devices, and IPv6 die a quick painless death.


A problem is that, a software patch is enough to upgrade an IPv4
host IPv6 capable. :-)

Anyway, with TUPLE (TCP and UDP with Port Length Extension, not
TUBA) using 32bit port numbers, which is easier to deploy than
full QUIC, an IPv4 address can be shared by 2^24 hosts each
having 256 port number ranges.

It should be noted that, with static End to End NAT

https://datatracker.ietf.org/doc/html/draft-ohta-e2e-nat-00

where port number collisions are prevented not by stateful
NAT GW but end systems, state maintenance at the NAT GW
is not necessary, while enjoying full end to end transparency.

Masataka Ohta

Re: V6 still not supported

[borg]

I know its the same, but from UX standpoints looks different.
Anyway, that was just one example.

As for IPv6 -> IPv4 (note the arrow) its pretty much easy.
IPv6 have much bigger address space, so it can embed IPv4 addresses
in special interop subnets that are routed to special NAT GW
that handle IPv6 -> IPv4 translation. Thats right, its one way.
IPv4 -> IPv6 is pretty much impossible. But do we need one?
Todays internet is centralized, a lot of traffic goes into cloud, not 
between users. Also, transition is not 0 -> 1, its gradual. Same about 
users. Some even dont really understand what they are using, happy that 
netflix or facebook opens. There are of course power users, so they will
go different transition path. Dont put everyone into same bucket.

As for content providers (servers) they can stay for IPv4 for a while,
become dual stack or even (once a traffic level shifts) provide
IPv4 -> IPv6 balancers to handle leftovers of IPv4 traffic.

Also, not all services can work via proxying/balacing. Some services
needs to be dual stack from the start.

As for RFC1918, because why not? Why are you forcing me to run my networks
your way? Its mine network and I want to set it up the way I see fit.
Not everyone is going to ask RIPE/LIR was address space for his small 
network. Isnt that too much burden?


-- Original message --

From: Owen DeLong 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: V6 still not supported
Date: Fri, 18 Mar 2022 13:44:13 -0700


This shows a fundamental lack of understanding˙˙ Netmask and Prefixlen/CIDR are 
just
Different ways of representing the exact same thing. While it˙˙s true that 
prior to CIDR, one
COULD implement discontiguous net masks, this was rare in actual practice and 
had no
real use, so nothing was lost in eliminating that capability.

Internal to the operating system, regardless of whether presentation is as a 
CIDR length
or a netmask, it˙˙s still stored and compared against addresses as a bitfield.

Client A has a 128 bit address.
Client B has a 32 bit address and does not understand packets with 128-bit 
addresses.

Please explain how these two clients interoperate.

That is literally what you are asking for here. Math says it doesn˙˙t work.

Why? Why does RFC-1918 space need to exist at all? Why not simply use 
transparent addressing and stop mutilating packet headers?

However, if you really think this is important, I will refer you to what is 
called ULA in IPv6. It˙˙s pretty much all the same problems of RFC1918 minus 
the high probability of collision when merging two networks.

I think you have over-valued it.

Owen

Re: V6 still not supported

[Masataka Ohta]

Tom Ivar Helbekkmo via NANOG wrote:


I really don't see why people think it's so different that v4. To
me back then it mostly seemed like v4 with bigger address.


Then I suppose, like me, you were in favor of the TUBA proposal?  :)


TUBA is TCP/UDP over CLNP (ConnectionLess Network Protocol) designed
by so infamous OSI, which is why it was denied by IETF through
democratic process even though IAB tried to deploy it.

However, as William Allen Simpson wrote:


Then, the powers that be declared that IPv6 should have 128-bit
addresses, and a host of committees were setup with competing CLNP
(TUBA) co-chairs. They incorporated many ideas of CLNP and XNS that
were thought (by many of us) to be worthless, useless, and harmful.
Committee-itis at its worst.


IAB hideously striked back to make IPv6 something a lot worse than
CLNP and XNS.

So, it is rather not the second but the zero-th system syndrome.

Masataka Ohta

Re: Latest from ICANN: Quantum Computers + N85 Peering Forum

[Masataka Ohta]

As I wrote:


Nanog News wrote:


Latest from ICANN: Quantum Computers are "Interesting"…
But Don't Lose your Head



Uselessness of quantum logic gate style quantum computers
will be discussed in a separate mail.


Quantum logic gate style quantum computers use qubits,
which have two orthogonal quantum state |0> and |1>
(which may be a horizontally and vertically polarized
photon, correspondingly, which is familiar for us,
communication engineers) used as bit values of 0 and
1. As they are orthogonal, we can consider |0>+|1>,
(which may be a diagonally polarized photon, easy
to understand classically). But such addition is
improperly called quantum superposition.

Two qubit states are represented as |00>, |11>
and |00>+|11>.

Then, if we can construct a linear circuit to
compute f, a 3 input and 3 output bits function,
f(a, b, c)=(d, e, f) as f(|abc>)=|def>. Then,
we can compute f(|000>)+f(|001>>+...+f(|111>) as
f(|000>+|001>+...+|111>), that is evaluating
f not 8 times but only once, which is quantum
parallelism. It can be extended for N qubit
cases for 2**N parallelism by 2**N terms.

However, though an N qubit state, like an N bit string,
can naturally distinguish 2**N cases, 2**N term
quantum superpositioned states require distinguishing
2**(2**N) cases, which is obviously impossible because
of noise/error (theory of Shannon).

So, QEC (Quantum Error Correction) was invented,
which was expected to reduce noise/error.

QEC certainly work for single term states. Small
non linear error on single term states is no different
from linear error.

The problem, however, is that, QEC is non-linear,
which means not applicable to 2**N term
superpositioned states.

But, it is implicitly and wrongly assumed that
all the 2**N terms will suffer from identical
error, in which case, QEC become linear.

That is single, so called, bit flip error on
the first qubit of:

|000>+|111>

occurs as:

|100>+|111>

or:

|000>+|011>

not (unless strong correlation exists, which
is an improper assumption):

|100>+|011>

which is the reason why quantum logic
gate quantum computer with practical
number of qubits is impossible.

A complication is that it is possible
to construct complex QEC scheme applicable
for 2 term states. So called Shor code
is such QEC. But Shor code itself use
states with more than 2 terms. Anyway,
once QEC scheme is fixed, it is not
applicable to 2**N term states for
large N.

It should also be noted that though
non-linear error on two or more term states
imply errors caused by interactions of multiple
terms, they are ignored.

Masataka Ohta

Re: IPv6 "bloat"

[Owen DeLong via NANOG]

DHCPv6 includes the DEVICE Unique Identifier (DUID). DUID can be any one of 
several things.

By far, the most common ones actually do include the MAC address.

Some systems allow you to choose which type of DUID they supply.

Macs use a long string that includes the EUI-64 at the end:
(an expert from a static host entry in dhcpv6d.conf for a Mac host:
host-identifier option dhcp6.client-id 
00:01:00:01:23:d6:92:16:68:fe:f7:07:11:6f;
hardware ethernet 68:fe:f7:07:11:6f; 
)

Some hosts don’t provide the MAC address, but they provide a device unique 
identifier which is equally useful for authentication, frankly.
For example, a Raritan KVM:
host-identifier option dhcp6.client-id 
00:02:00:00:35:ae:31:49:54:39:41:30:30:31:34:38 ; 

HP Printers provide yet another format of DUID:
host-identifier option dhcp6.client-id 
00:01:00:01:01:e2:85:23:b8:db:ad:ba:db:ad ;


It’s a little more awkward than DHCPv4, but once you get used to it, it’s 
really not so bad. It’s a slight challenge for providing hosts reserved 
addresses, but otherwise, it’s just larger fields in the log entries.

Owen

> On Mar 19, 2022, at 16:20 , Matt Hoppes  
> wrote:
> 
> On a public network (such as WiFi - sure).  On a private network where the 
> only authentication taking place is to the modem which is provided by the 
> service provider, not so much.  It's a closed environment.  The modem demarcs 
> to the end-user and the end-user never touches the switching fabric.
> 
> Interesting about DHCPv6 Option 79.  I had not run across that before. I will 
> look into that more.  Thank you.
> 
> On 3/19/22 7:18 PM, Michael Thomas wrote:
>> Thanks, I didn't think that they'd something that interfered with AAA. Using 
>> a MAC address as authentication seems sort of sketch to me in the first 
>> place.
>> Mike
>> On 3/19/22 4:14 PM, Tom Beecher wrote:
>>> 
>>>Primarily the ability to end-to-end authenticate end devices.   The
>>>primary and largest glaring issue is that DHCPv6 from the client does
>>>not include the MAC address, it includes the (I believe) UUID.
>>> 
>>> 
>>> DHCPv6 Option 79
>>> 
>>> https://datatracker.ietf.org/doc/html/rfc6939
>>> 
>>> 
>>> 
>>> On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes 
>>>  wrote:
>>> 
>>> 
>>> 
>>>On 3/19/22 6:50 PM, Michael Thomas wrote:
>>>>
>>>> On 3/19/22 3:47 PM, Matt Hoppes wrote:
>>>>> It has "features" which are at a minimum problematic and at a
>>>maximum
>>>>> show stoppers for network operators.
>>>>>
>>>>> IPv6 seems like it was designed to be a private network
>>>communication
>>>>> stack, and how an ISP would use and distribute it was a second
>>>though.
>>>>
>>>> What might those be? And it doesn't seem to be a show stopper
>>>for a lot
>>>> of very large carriers.
>>> 
>>>Primarily the ability to end-to-end authenticate end devices.  The
>>>primary and largest glaring issue is that DHCPv6 from the client does
>>>not include the MAC address, it includes the (I believe) UUID.
>>> 
>>>We have to sniff the packets to figure out the MAC so that we can
>>>authenticate the client and/or assign an IP address to the client
>>>properly.
>>> 
>>>It depends how you're managing the network.  If you're running
>>>PPPoE you
>>>can encapsulate in that.   But PPPoE is very 1990 and has its own
>>>set of
>>>problems.  For those running encapsulated traffic, authentication
>>>to the
>>>modem MAC via DHCP that becomes broken.  And thus far, I have not
>>>seen a
>>>solution offered to it.
>>> 
>>> 
>>>Secondly - and less importantly to deployment, IPv6 also provides a
>>>layer of problematic tracking for advertisers.  Where as before many
>>>devices were behind a PAT, now every device has a unique ID --
>>>probably
>>>for the life of the device. Marketers can now pinpoint down not
>>>just to
>>>an IP address that identifies a single NAT interface, but each
>>>individual device.  This is problematic from a data collection
>>>standpoint.
>>>