RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-san

> > - there's no way to know if 2 locations are OK (anycast)
> 
> If you mean IPv6 anycast to allow 2 or more hosts sharing an anycast address,
> it is just broken not useful for any purpose and ignored.

One case I have in mind is when one wants to bundle multiple physical 
interfaces as one logical P2MP interface that reaches different routers, e.g., 
for server multihoming. 

There's a single owner and a single address, but it is presented to both 
routers on different physical interfaces and can be routed to any of those. 
Then the routers inject the address in some overlay and may fight unless they 
realize that they work on behalf of the same end point.

Basically I'm talking about a proper L3 abstraction for cases where LAG / 
Etherchannel are used today. K8S needs a unique IP like that.

> Instead, IPv4 style anycast is widely deployed for IPv6.

I guess you mean the one we configure on a server loopback for load balancing? 
Certainly. The end result is the same for the routing (weighted ECMP) so for 
all I know we can use the same signals.

Keep safe;

Pascal

 

Re: IPv6 "bloat" history

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:


You can't expect people still working primarily on v6 have much
sense of engineering.


That includes me


Sorry for confusion. I mean "people still working primarily on v6"
are people who insist on IPv6 and ND as is, because any required
repair on it would delay the day when IPv6 is fully deployed.

Worse, actually, though they insist packet format stay same,
semantics has been randomly changing a lot as they wish.


As broadcast/multicast packets are first sent to APs as unicast
packets with ACKs, snooping by APs should be reliable at L2.


Well, up to the N retries. After that the stack is not even aware
that the multicast was not delivered.


That is a unicast problem.

But, I understand your point. That is, though it can be remedied
by upper layer ACKs, there can be NACKs but no ACKs for DAD.


Oh but that's just the beginning of the story;


Yup.


yes we mostly can form
an initial state and it mostly appears to work and people are mostly
satisfied. And then you realize:

- there's no way to know how long the device will you that address


With some interval, an AP can unicast fake DAD to the device,
I think, though it wastes power to do so.

> - there's no clean way to
> know is an address is still in use (e.g., without reviving it in the
> host stack)

See above, though I don't think it clean.


- there's no way to know which is the most recent
location of the address (unless you have a fine time distribution and
that costs)


Yup.


- there's no way to know if 2 locations are OK (anycast)


If you mean IPv6 anycast to allow 2 or more hosts sharing an
anycast address, it is just broken not useful for any purpose
and ignored.

Instead, IPv4 style anycast is widely deployed for IPv6.


- there's no way to know for sure that the claimer is the owner


You may use IPSEC, though securely configuring security key
for IPSEC is at least as difficult as securely configuring
address without IPSEC, which means requiring cryptographic
security for DHCP is a bad idea.


Certainly a bad guy doing impersonation and DOS can play havoc in
such network, but at least between good guys we get something we can
operate.


I'm sure there are a lot of security holes in or around IPv6 I
haven't noticed yet.


I'm not saying that snooping DHCP is fully deterministic but it's
orders of magnitude better than snooping SLAAC when it comes to
forming a state like an association than SLAAC.


Of course.


So, by snooping DAD, which is ugly, ARP table can be constructed.


A Proof of Concept, yes, an enterprise-class-quality network, no. If
you try, start populating the hot-line before you turn the lights on


I merely said "constructed", which does not imply "maintained".


E.g., a DAD coming from the wire
that is sent over the wireless is not deterministically delivered and
a duplicate is often missed.


Even with a single AP, as DAD to terminals is multicast (from
the AP) and unreliable, duplicate is often missed.


I do not need to continue the endless list do I?


If you think people still working primarily on v6, with my
meaning, have much sense of engineering, you should.

Masataka Ohta

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

> 
> Pascal Thubert (pthubert) wrote:
> 
> > You're perfectly correct. This is exactly what the registration would
> > be for. I'm concerned about its adoption that I do not see coming on
> > Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
> > worse*.
> 
> You can't expect people still working primarily on v6 have much sense of
> engineering.

That includes me

> 
> > * APs today snoop DHCP; DHCP is observable and stateful, with a
> > lifetime that allows to clean up. So snooping it is mostly good enough
> > there. The hassle is the SL in SLAAC which causes broadcasts and is
> > not deterministically observable; this problem is specific to IPv6. We
> > already have the registration to avoid snooping DHCP and SLAAC; yet we
> > do not observe any adoption in mainline APs and STAs.
> 
> As broadcast/multicast packets are first sent to APs as unicast packets with
> ACKs, snooping by APs should be reliable at L2.

Well, up to the N retries. After that the stack is not even aware that the 
multicast was not delivered. 

Oh but that's just the beginning of the story; yes we mostly can form an 
initial state and it mostly appears to work and people are mostly satisfied. 
And then you realize:

- there's no way to know how long the device will you that address
- there's no way to know how many addresses the device will form
- there's no way to know how many addresses the device has already formed and 
which (at least MLD can do that)
- there's no clean way to know is an address is still in use (e.g., without 
reviving it in the host stack)
- there's no way to know which is the most recent location of the address 
(unless you have a fine time distribution and that costs)
- there's no way to know if 2 locations are OK (anycast)
- there's no way to know for sure that the claimer is the owner

Snooping DHCP you expect:
- one address per MAC (that's it's pretty limiting but that protects the 
network)
- A MAC address or least a unique ID to differentiate duplicates (but not 
recognize a thief)
- An upper bound for the state lifetime based on the lease

Certainly a bad guy doing impersonation and DOS can play havoc in such network, 
but at least between good guys we get something we can operate.

I'm not saying that snooping DHCP is fully deterministic but it's orders of 
magnitude better than snooping SLAAC when it comes to forming a state like an 
association than SLAAC. Knowing that you base things like EVPN on such state, 
using SLAAC is building on sand.

Ideally you'd want:
- a negotiated contract for a number of addresses with a lifetime, etc
- a provable ownership so we route to the legitimate owner and can do SAVI
- a sense of mobility so we can route the packets to the latest location
- a sense of anycast vs unicast so we can install routing properly based on that
- the capability to indicate whether the address should be redistributed, a 
sense of weight in ECMP, etc...

We've done just that, and with that, we're effectively providing a 
deterministic state that we can redistribute in routing or ARP/ND proxy.

In the case of EVPN that gives this:
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling

Then again, retrofitting the ND registration for IPv4 addresses is piece of 
cake, but IPv4 is DHCP only and the pain does not really feel; so people may 
not be inclined to make the steps for IPv4. To be seen.

> 
> So, by snooping DAD, which is ugly, ARP table can be constructed.

A Proof of Concept, yes, an enterprise-class-quality network, no. If you try, 
start populating the hot-line before you turn the lights on 😊

> 
> A problem, however, is that there is no ACK above L2, that is, there is no
> end to end ACK, which means, if something goes wrong above L2, the result can
> be weird.

Yes, and all the other things above. E.g., a DAD coming from the wire that is 
sent over the wireless is not deterministically delivered and a duplicate is 
often missed. I do not need to continue the endless list do I?

Keep safe;

Pascal

> 
>   Masataka Ohta

Re: IPv6 "bloat" history

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:


You're perfectly correct. This is exactly what the registration would
be for. I'm concerned about its adoption that I do not see coming on
Wi-Fi/ Ethernet, even for v6 (SLAAC) where the problem is a lot
worse*.


You can't expect people still working primarily on v6 have
much sense of engineering.


* APs today snoop DHCP; DHCP is observable and stateful, with a
lifetime that allows to clean up. So snooping it is mostly good
enough there. The hassle is the SL in SLAAC which causes broadcasts
and is not deterministically observable; this problem is specific to
IPv6. We already have the registration to avoid snooping DHCP and
SLAAC; yet we do not observe any adoption in mainline APs and STAs.


As broadcast/multicast packets are first sent to APs as unicast
packets with ACKs, snooping by APs should be reliable at L2.

So, by snooping DAD, which is ugly, ARP table can be constructed.

A problem, however, is that there is no ACK above L2, that is,
there is no end to end ACK, which means, if something goes wrong
above L2, the result can be weird.

Masataka Ohta

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Fun, I had a parallel experience with NEMO that I implemented in IOS. 

But I mostly read the fate of MIP and NEMO as a lack of ask. Which is similar 
to the lack of desire today for the uplifts we made to IPv6 as a whole, and ND 
in particular.

Anyway, RPL has a lot to do with what we learned there, including the abstract 
objective function that yields the metrics you are talking about, typically 
including things like ETX/ETX^2, RSSI and LQI.

So yes, things that make sense eventually emerge.

Keep safe.

Pascal

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 14:10
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/31/22 7:44 AM, William Allen Simpson wrote:
> > [heavy sigh]
> >
> > All of these things were well understood circa 1992-93.
> >
> > That's why the original Neighbor Discovery was entirely link state.
> >
> > ND link state announcements handled the hidden terminal problem.
> 
> Also, it almost goes without saying that the original ND tried to handle the
> near-far problem.  For example, where I'm talking to a far away AP streaming
> to the TV in front of me.
> 
> At my home, I've had to wire the TV.  Streaming to the AP, then the AP
> sending the same traffic over the same wireless band to the TV caused lots of
> drops and jitter.
> 
> The near-far problem can be detected and solved.  That's the reason for the
> Metric field.
> 
> Furthermore, one of the messages in this thread mentioned trying to backport
> v6 features to v4.
> 
> We've already been down that road.  IPsec and MobileIP were developed for v6.
> After quitting the v6 project(s), I'd backported both of them to v4.  Like
> v6, then they were assigned to others who ruined them.
> Committee-itis at its worst.

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Don't sigh! You envisioned it and we built it, William.

We have IPv6 mesh networks with thousands on nodes per mesh deployed around 
you. The standard is called WI-SUN. WI-SUN totals millions of nodes deployed in 
North America; so what you described cannot not only be envisioned as you did, 
it can be built and deployed at scale, even on low power far reach wireless.

The core L3 components for Wi-SUN are RFC 8505 which is your link state ND 
thingy, RFC 6550 that does the routing over what OSPF called P2MP and which 
really means non-transitive, and RFC 9010 that redistribute the former in the 
latter. We are now working on registering multicast, anycast and prefixes in 
the same model.

It's just that the wired world (including operators) are mostly unaware of 
these capabilities. Whether they are even interested is not a given either. 
Louis the XVth said "après moi le déluge". I read pretty much the same thing on 
the list in the recent days as a migration strategy. 

Certainly, complaining from a comfort zone is a lot easier than acting out to 
solve the problem. "La critique est aisée mais l'art est difficile" is another 
good one.

I claim that bashing at the IETF for IPv6 as it was 20 years ago is unfair and 
that a little refresh / resync is in order. If what we produced since in an 
attempt to solve the issues you describe can help, then ask for it, amend it, 
say something, so something.

Today, decoupling the L1/2 (physical) network from the L3 abstractions of 
subnet and link is totally doable. This yields a world of possibilities for 
deployments. For all those (or the very few) who care, there's 
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-06

Keep safe;

Pascal

PS : When I say that DHCP mostly does the trick is not that I like it, but that 
customers (think EVPN) are reasonably happy with the result, while SLAAC is a 
lot worse for pretty much the whole collection of its design points, and cherry 
on the cake, the onlink model.

> -Original Message-
> From: William Allen Simpson 
> Sent: jeudi 31 mars 2022 13:44
> To: nanog@nanog.org
> Cc: Pascal Thubert (pthubert) ; Masataka Ohta
> 
> Subject: Re: IPv6 "bloat" history
> 
> On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:
> > * APs today snoop DHCP; DHCP is observable and stateful, with a lifetime
> that allows to clean up. So snooping it is mostly good enough there. The
> hassle is the SL in SLAAC which causes broadcasts and is not
> deterministically observable; this problem is specific to IPv6. We already
> have the registration to avoid snooping DHCP and SLAAC; yet we do not observe
> any adoption in mainline APs and STAs.
> >
> 
> [heavy sigh]
> 
> All of these things were well understood circa 1992-93.
> 
> That's why the original Neighbor Discovery was entirely link state.
> 
> ND link state announcements handled the hidden terminal problem.
> (That is, where node A can hear node B, node B can hear node C, and node C
> can hear node A, but A cannot hear C.)  ND LSAs are/were flexible enough to
> handle both AP (cell) and mesh (AMPR) networks.
> 
> Thus, it was not reliant on central Access Points.  We envisioned mesh
> networks were the future.  Each node should handle its own discovery and
> routing.
> 
> SLAAC is bloat.
> 
> RIPv6 is bloat.
> 
> DHCPv6 is bloat.
> 
> Those are reasons operators have been complaining about IPv6.

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/31/22 7:44 AM, William Allen Simpson wrote:

[heavy sigh]

All of these things were well understood circa 1992-93.

That's why the original Neighbor Discovery was entirely link state.

ND link state announcements handled the hidden terminal problem.


Also, it almost goes without saying that the original ND tried to
handle the near-far problem.  For example, where I'm talking to a far
away AP streaming to the TV in front of me.

At my home, I've had to wire the TV.  Streaming to the AP, then the
AP sending the same traffic over the same wireless band to the TV
caused lots of drops and jitter.

The near-far problem can be detected and solved.  That's the reason
for the Metric field.

Furthermore, one of the messages in this thread mentioned trying to
backport v6 features to v4.

We've already been down that road.  IPsec and MobileIP were developed
for v6.  After quitting the v6 project(s), I'd backported both of
them to v4.  Like v6, then they were assigned to others who ruined them.
Committee-itis at its worst.

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/29/22 5:21 AM, Pascal Thubert (pthubert) via NANOG wrote:

* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that 
allows to clean up. So snooping it is mostly good enough there. The hassle is 
the SL in SLAAC which causes broadcasts and is not deterministically 
observable; this problem is specific to IPv6. We already have the registration 
to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in 
mainline APs and STAs.



[heavy sigh]

All of these things were well understood circa 1992-93.

That's why the original Neighbor Discovery was entirely link state.

ND link state announcements handled the hidden terminal problem.
(That is, where node A can hear node B, node B can hear node C,
and node C can hear node A, but A cannot hear C.)  ND LSAs are/were
flexible enough to handle both AP (cell) and mesh (AMPR) networks.

Thus, it was not reliant on central Access Points.  We envisioned
mesh networks were the future.  Each node should handle its own
discovery and routing.

SLAAC is bloat.

RIPv6 is bloat.

DHCPv6 is bloat.

Those are reasons operators have been complaining about IPv6.

RE: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-san

> An ARP table entry can be created when an IP address is assigned during
> registration process and destroyed if the registration is invalidated.
> 
> Or, do I misunderstand anything?

You're perfectly correct. This is exactly what the registration would be for. 
I'm concerned about its adoption that I do not see coming on Wi-Fi/ Ethernet, 
even for v6 (SLAAC) where the problem is a lot worse*.

The IoT world already adopted the registration model, though. Millions of nodes 
on 802.15.4 radios are deployed to prove it works. We even redistribute RFC 
8505 in routing protocols that carry host routes in IoT networks (RPL), which 
is how we avoid your lookup issue on a wide low power mesh network.

Extending the registration to IPv4 is easy, we could even use mapped addresses 
and be done. But what magic will trigger attention / adoption when adoption is 
not showing in IPv6?

Keep safe;

Pascal


* APs today snoop DHCP; DHCP is observable and stateful, with a lifetime that 
allows to clean up. So snooping it is mostly good enough there. The hassle is 
the SL in SLAAC which causes broadcasts and is not deterministically 
observable; this problem is specific to IPv6. We already have the registration 
to avoid snooping DHCP and SLAAC; yet we do not observe any adoption in 
mainline APs and STAs. 







> -Original Message-
> From: Masataka Ohta 
> Sent: mardi 29 mars 2022 10:57
> To: Pascal Thubert (pthubert) ; nanog@nanog.org
> Subject: Re: IPv6 "bloat" history
> 
> Pascal Thubert (pthubert) wrote:
> 
> > I tried exactly what you suggested for IPv6 with RFC 8505 and 8929.
> > But to few people in mainstream networks realize what you just said.
> 
> I found, theoretically by reading 802.11 specification, broadcast/multicast
> reliability problem and reported to
> IPv6 WG about 20 years ago. So, I'm pleased to know that some people
> recognize it as a real problem and worked on it. Thank you.
> 
> > It started long long ago with the idea to use inverse ARP for the
> > registration, I guess it is still doable but I am not optimistic about
> > adoption considering that v6 is a lot worse with more addresses and
> > DAD.
> 
> Aren't IP addresses are assigned from APs? Then, the APs can construct ARP
> table without actually running ARP or inverse ARP, I'm afraid.
> 
> > We are editing the piece on proxy ARP at this very moment at .11me.
> > APs are indeed supposed to proxy both v4 and v6. What is less clear is
> > how they form a deterministic state for that.
> 
> An ARP table entry can be created when an IP address is assigned during
> registration process and destroyed if the registration is invalidated.
> 
> Or, do I misunderstand anything?
> 
>   Masataka Ohta

Re: IPv6 "bloat" history

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:


I tried exactly what you suggested for IPv6 with RFC 8505 and 8929.
But to few people in mainstream networks realize what you just said.


I found, theoretically by reading 802.11 specification,
broadcast/multicast reliability problem and reported to
IPv6 WG about 20 years ago. So, I'm pleased to know
that some people recognize it as a real problem and
worked on it. Thank you.


It started long long ago with the idea to use inverse ARP for the
registration, I guess it is still doable but I am not optimistic
about adoption considering that v6 is a lot worse with more addresses
and DAD.


Aren't IP addresses are assigned from APs? Then, the
APs can construct ARP table without actually running
ARP or inverse ARP, I'm afraid.


We are editing the piece on proxy ARP at this very moment at .11me.
APs are indeed supposed to proxy both v4 and v6. What is less clear
is how they form a deterministic state for that.


An ARP table entry can be created when an IP address is assigned
during registration process and destroyed if the registration is
invalidated.

Or, do I misunderstand anything?

Masataka Ohta

Re: IPv6 "bloat" history

[Pascal Thubert (pthubert) via NANOG]

Hello Ohta-San

I tried exactly what you suggested for IPv6 with RFC 8505 and 8929. But to few 
people in mainstream networks realize what you just said.

It started long long ago with the idea to use inverse ARP for the registration, 
I guess it is still doable but I am not optimistic about adoption considering 
that v6 is a lot worse with more addresses and DAD.

We are editing the piece on proxy ARP at this very moment at .11me. APs are 
indeed supposed to proxy both v4 and v6. What is less clear is how they form a 
deterministic state for that.

Regards,

Pascal

> Le 28 mars 2022 à 15:55, Masataka Ohta  a 
> écrit :
> 
> William Allen Simpson wrote:
> 
> > After so many times reinventing the wheel, IP uber alles is a
> > better goal.  Speaking as somebody familiar with the effort.
> 
> I'm afraid you misunderstand my point.
> 
>> John Gilmore recently gave a good history of the ARP origin.
> 
> ARP is perfectly good for CSMA/CD but not so good
> for CSMA/CA where broadcast/multicast is unreliable.
> 
> So, with wifi, we should rely on repeated beacon from
> base stations for AR of the base stations and rely on
> unicast from clients to register them to base stations,
> which should act as proxy for communications between
> clients, which is a totally different protocol from ARP.
> 
> Without such recognition today, wifi users should be
> suffering from some inefficiencies when link is congested,
> which is often the case.
> 
> Other link technology should also require AR mechanism
> of its own.
> 
> As such, performing AR with IP is not so meaningful.
> Worse, even DHCP, which assumes reliable broadcast,
> does not work so efficiently over congested wifi.
> 
>Masataka Ohta

Re: IPv6 "bloat" history

[Masataka Ohta]

William Allen Simpson wrote:

> After so many times reinventing the wheel, IP uber alles is a
> better goal.  Speaking as somebody familiar with the effort.

I'm afraid you misunderstand my point.


John Gilmore recently gave a good history of the ARP origin.


ARP is perfectly good for CSMA/CD but not so good
for CSMA/CA where broadcast/multicast is unreliable.

So, with wifi, we should rely on repeated beacon from
base stations for AR of the base stations and rely on
unicast from clients to register them to base stations,
which should act as proxy for communications between
clients, which is a totally different protocol from ARP.

Without such recognition today, wifi users should be
suffering from some inefficiencies when link is congested,
which is often the case.

Other link technology should also require AR mechanism
of its own.

As such, performing AR with IP is not so meaningful.
Worse, even DHCP, which assumes reliable broadcast,
does not work so efficiently over congested wifi.

Masataka Ohta

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/23/22 2:25 AM, Masataka Ohta wrote:

William Allen Simpson wrote:



Neighbor Discovery is/was agnostic to NBMA.  Putting all the old
ARP and DHCP and other cruft into the IP-layer was my goal, so
that it would be forever link agnostic.


To make "IP uber alles", link-dependent adaptation mechanisms
between IP and links are necessary. So, "ND uber alles" is a
wrong goal.



Meant to reply to this separately.

I've implemented on the order of 35+ protocols, most of them
predating IP.

My first IP implementation was 1979 for the Perkin-Elmer 7/16.
The link layer was X.25 to talk to Merit and over Telenet
(not telnet -- Telenet was a provider in those days).

John Gilmore recently gave a good history of the ARP origin.

Note that for PPP, we also had to negotiate a link layer shim.

Some folks then grabbed that effort, instead of building their
own, resulting in such monstrosities as PPP over Ethernet.

After so many times reinventing the wheel, IP uber alles is a
better goal.  Speaking as somebody familiar with the effort.

Re: IPv6 "bloat" history

[William Allen Simpson]

On 3/23/22 2:25 AM, Masataka Ohta wrote:

William Allen Simpson wrote:


  6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol
 (PIP) had some overlapping features, so we also asked them to merge
 with us (July 1993).  More complexity in the protocol header chaining.


With the merger, Paul Francis was saying he was unhappy
because PIP is dead. So the merger is not voluntary for
him and the added complexity is technically meaningless.



He seemed happy at the Amsterdam 1993 meeting, but as time went on he was
sidelined.  Likewise, I eventually regretted having joined with the others.
We lost control of the main ideas.

For example, originally V6 was designed to use shortest path first
interior routing.  All the announcements were Link State, everything was in
place.  I still wince at the memory of the PARC meeting where Eric stated
that RIP was good enough for V4, so it is good enough for V6.

Then he was assigned to be my "co-author".  So I quit.

What you know as Neighbor Discovery was not the original design.  Nor was
RIPv6 needed.

When I was giving a talk at Google 25 years later I was asked why that
happened (by a then member of the IAB).  A sore spot, long remembered.
Committee-itis at its worst.



IPv4 options were recognized as harmful.  SIPP used header chains instead.
But the whole idea was to speed processing, eliminating hop-by-hop.

Then the committees added back the hop by hop processing (type 0).
Terrible!


Really? But, rfc1710 states:

    The SIPP option headers which are currently defined are:

  Hop-by-Hop Option  Special options which require hop by hop
     processing



Yep, that was one of the reasons I quit.

Digging out my files, I'd forked my documents by July 17, 1994.  (That's
the last date I'd touched them, so it was before then.)  RFC 1710 was later.

Also, I registered IPvB with Jon Postel.

These are all old nroff files, but I could hand format a bit and post
things here.  Not that it makes much difference today, yet some of my
ideas made it into Fibre Channel and InfiniBand.

Re: IPv6 "bloat" history

[Masataka Ohta]

William Allen Simpson wrote:


  6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol
     (PIP) had some overlapping features, so we also asked them to merge
     with us (July 1993).  More complexity in the protocol header chaining.


With the merger, Paul Francis was saying he was unhappy
because PIP is dead. So the merger is not voluntary for
him and the added complexity is technically meaningless.


IPv4 options were recognized as harmful.  SIPP used header chains instead.
But the whole idea was to speed processing, eliminating hop-by-hop.

Then the committees added back the hop by hop processing (type 0).
Terrible!


Really? But, rfc1710 states:

   The SIPP option headers which are currently defined are:

 Hop-by-Hop Option  Special options which require hop by hop
processing


Admittedly, I was also skeptical of packet shredding (what we called
ATM).


Packet shredding harmed router architecture, not protocols.
Many routers are shredding packets internally for no good
reason.

Instead, ATM-centric view that "all the world will be
covered by ATM and global IP could be used only over ATM"
harmed protocols including IPv6 a lot.


Neighbor Discovery is/was agnostic to NBMA.  Putting all the old
ARP and DHCP and other cruft into the IP-layer was my goal, so
that it would be forever link agnostic.


To make "IP uber alles", link-dependent adaptation mechanisms
between IP and links are necessary. So, "ND uber alles" is a
wrong goal.


Yes, we were also getting a push from Fermi Labs and CERN for very
large numbers of nodes per link, rather than old ethernet maximum.


And the reason was that they want to use IPv4 and
DECNET without being annoyed by *dual* *stack* routers!


That's the underlying design for Neighbor Discovery.  Less chatty.


Just wrong requirement.

Large Ethernet segments work poorly by itself. Worse, even
if some L3 might be causing additional damages, the
damages won't go away if IPv6 is added.


Turns out it was the administration's IBM that
had been clogging the campus.


SNA?

Masataka Ohta

Re: IPv6 "bloat" history

[William Allen Simpson]

Admitting to not having read every message in these threads,
but would like to highlight a bit of the history.

IMnsHO, the otherwise useful history is missing a few steps.

 1) The IAB selected ISO CLNP as the next version of IP.

 2) The IETF got angry, disbanded, replaced, and renamed IAB.

 3) On the Big-Internet list, my Practical Internet Protocol Extensions
(PIPE) was an early proposal, and I'd registered V6 with IANA.

I was self-funding.  PIPE was cognizant of the needs of ISPs and
deployment.

 4) Lixia Zhang wrote me that Steve Deering was proposing something
similar, and urged us to pool our efforts.  That became Simple
Internet Protocol (SIP).  We used 64 bit addresses.  We had a clear
path for migration, using the upper 32-bits for the ASN and the old
IPv4 address in the lower 32-bits.  We had running code.

 5) The IP Address Extension (IPAE) proposal had some overlapping features,
and we asked them to merge with us.  That added some complexity.

 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protocol
(PIP) had some overlapping features, so we also asked them to merge
with us (July 1993).  More complexity in the protocol header chaining.

 7) The result was SIPP.  We had 2 interoperable implementations: Naval
Research Labs, and KA9Q NOS (Phil Karn and me).  There were others
well underway.

 8) As noted by John Curran, there was a committee of "powers that be".
After IETF had strong consensus for SIPP, and we had running code,
the "powers that be" decided to throw all that away.

 9) The old junk was added back into IPv6 by committee.

There was also a mention that the Linux IP stack is fairly compact and
that IPv6 is somewhat smaller than the IPv4.  That's because the Linux
stack was ported by Alan Cox from KA9Q NOS.  We gave Alan permission to
change from our personal copyright to GPL.

It has a lot of the features we'd developed, such as packet buffers and
pushdown functions for adding headers, complimentary to BSD pullup.
They made SIPP/IPv6 fairly easy to implement.


On 3/22/22 10:04 AM, Masataka Ohta wrote:

Owen DeLong wrote:


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.


Yes, but IPv6 works without any broadcast. At the time IPv6 was being
developed, broadcasts were rather inconvenient and it was believed
that ethernet switches (which were just beginning to be a thing then)
would facilitate more efficient capabilities by making extensive use
of link multicast instead of broadcast.


No, the history around it is that there was some presentation
in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast
Multiple Access)in general, is multicast capable though not
broadcast capable, which was blindly believed by most, if not
all excluding *me*, people there.



Both Owen and Masataka are correct, in their own way.

IPv4 options were recognized as harmful.  SIPP used header chains instead.
But the whole idea was to speed processing, eliminating hop-by-hop.

Then the committees added back the hop by hop processing (type 0).
Terrible!

Admittedly, I was also skeptical of packet shredding (what we called
ATM).  Sadly, the Chicago NAP required ATM support, and that's where
my connections were located.



It should be noted that IPv6 was less bloat because
ND abandoned its initial goal to support IP over NBMA.



Neighbor Discovery is/was agnostic to NBMA.  Putting all the old
ARP and DHCP and other cruft into the IP-layer was my goal, so
that it would be forever link agnostic.



 > There is still a valid argument to be made that in a switched
 > ethernet world, multicast could offer efficiencies if networks were
 > better tuned to accommodate it vs. broadcast.

That is against the CATENET model that each datalink only
contain small number of hosts where broadcast is not a
problem at all. Though, in CERN, single Ethernet with
thousands of hosts was operated, of course poorly, it
was abandoned to be inoperational a lot before IPv6,
which is partly why IPv6 is inoperational.



Yes, we were also getting a push from Fermi Labs and CERN for very
large numbers of nodes per link, rather than old ethernet maximum.

That's the underlying design for Neighbor Discovery.  Less chatty.

Also, my alma mater was Michigan State University, operating the
largest bridged ethernet in the world in the '80s.  Agreed, it was
"inoperational".  My epiphany was splitting it with KA9Q routers.

Suddenly the engineering building and the computing center each had
great throughput.  Turns out it was the administration's IBM that
had been clogging the campus.  Simple KA9Q routers didn't pass the
bad packets.  That's how I&#x

Re: IPv6 "bloat"

[Masataka Ohta]

Owen DeLong wrote:

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.


Yes, but IPv6 works without any broadcast. At the time IPv6 was being
developed, broadcasts were rather inconvenient and it was believed
that ethernet switches (which were just beginning to be a thing then)
would facilitate more efficient capabilities by making extensive use
of link multicast instead of broadcast.


No, the history around it is that there was some presentation
in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast
Multiple Access)in general, is multicast capable though not
broadcast capable, which was blindly believed by most, if not
all excluding *me*, people there.

It should be noted that IPv6 was less bloat because
ND abandoned its initial goal to support IP over NBMA.

> Turns
> out multicast was arguably a wrong guess, but all indications
> available at the time were that it was a good bet.

See above.

> There is still a valid argument to be made that in a switched
> ethernet world, multicast could offer efficiencies if networks were
> better tuned to accommodate it vs. broadcast.

That is against the CATENET model that each datalink only
contain small number of hosts where broadcast is not a
problem at all. Though, in CERN, single Ethernet with
thousands of hosts was operated, of course poorly, it
was abandoned to be inoperational a lot before IPv6,
which is partly why IPv6 is inoperational.

Masataka Ohta

Re: IPv6 "bloat"

[Owen DeLong via NANOG]

> On Mar 20, 2022, at 22:41, Masataka Ohta  
> wrote:
> 
> 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.

Yes, but IPv6 works without any broadcast. At the time IPv6 was being 
developed, broadcasts were rather inconvenient and it was believed that 
ethernet switches (which were just beginning to be a thing then) would 
facilitate more efficient capabilities by making extensive use of link 
multicast instead of broadcast.

Guess what, we are again bad at predicting the future. You have no choice when 
developing something but to make the best guess about what will happen from the 
information available at the time. Turns out multicast was arguably a wrong 
guess, but all indications available at the time were that it was a good bet.

There is still a valid argument to be made that in a switched ethernet world, 
multicast could offer efficiencies if networks were better tuned to accommodate 
it vs. broadcast. That’d be IPv4 unfriendly, but in a world where IPv4 is 
eventually deprecated and broadcasts are no longer necessary, the potential is 
there.

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

SLAAC doesn’t “statefully” maintain address state in the network or in remote 
systems. Obviously some level of statefulness is required on each local host or 
it would need to repeat the address acquisition process for each unconnected 
frame (whether initiating a connected session or a connectionless frame). DAD 
is there to avoid inconsistencies and more gracefully handle situations where 
addresses get duplicated. IPv4 is particularly bad at this and the “over 
engineering” you speak of here was seen as a solution to that problem in IPv4.

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

It is guaranteed that a 512 octet DNS message can be sent over UDP if it does 
not contain extension headers. You can argue that extension headers should have 
been more carefully considered in RFC791, but two factors come into play there:

1.  I’m not sure the idea of extension headers had been fleshed out 
by the time RFC791 was written. It is one
of the earliest IPv6 RFCs.

2.  Even with full consideration of IPv6 extension headers, I think 
576 is still a reasonable MINIMUM MTU,
since a minimum MTU that can account for all extension headers 
would exceed the common 1500 octet
MTU prevalent at the time (and still relatively prevalent 
today). It’s clear from the text of RFC791 that
this number is by definition a compromise between competing 
factors, wherein there is on one side
the desire to keep the minimum MTU as small as possible and on 
the other side, the need for the
minimum MTU to accommodate a reasonable size payload under the 
majority of circumstances.
For better or worse, I think that 576 is probably as good a 
compromise as can be reached.

So I disagree with your characterization of this as under-engineered.

Owen

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

Re: IPv6 "bloat"

[Matt Hoppes]

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.

Re: IPv6 "bloat"

[Michael Thomas]

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.

Re: IPv6 "bloat"

[Tom Beecher]

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

[Matt Hoppes]

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.


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


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.

Re: IPv6 "bloat"

[Michael Thomas]

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.






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.


I guess you've not heard of privacy addresses. Or DHCPv6.

Mike

Re: IPv6 "bloat"

[Matt Hoppes]

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"

[Michael Thomas]

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.


Mike



On 3/19/22 5:29 PM, 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. So I 
decided to look at a linux kernel (HEAD I assume) and look at the 
differences between the v6 and v4 directories. I just crudely did a 
line count as a quick measure:


ipv6: 68k lines

ipv4: 97k lines

ipv4 looks to have the tcp and udp implementations (35k) so backing 
that out it is about 62k lines. That's pretty comparable. Linux has 
full routing capability so the kernel implements it for both.


So I'm just not getting where this "bloat" is. 10% growth for a 
second system syndrome seems almost miraculously good, imo.


What am i missing? This is in complete agreement with my intuition 30 
years ago that it was no big deal, at least from a software standpoint.


Mike

Re: IPv6 "bloat"

[Matt Hoppes]

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.


On 3/19/22 5:29 PM, 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. So I decided to 
look at a linux kernel (HEAD I assume) and look at the differences 
between the v6 and v4 directories. I just crudely did a line count as a 
quick measure:


ipv6: 68k lines

ipv4: 97k lines

ipv4 looks to have the tcp and udp implementations (35k) so backing that 
out it is about 62k lines. That's pretty comparable. Linux has full 
routing capability so the kernel implements it for both.


So I'm just not getting where this "bloat" is. 10% growth for a second 
system syndrome seems almost miraculously good, imo.


What am i missing? This is in complete agreement with my intuition 30 
years ago that it was no big deal, at least from a software standpoint.


Mike

IPv6 "bloat"

[Michael Thomas]

So out of the current discussions a lot of people have claimed that ipv6 
is bloated or suffers from second system syndrome, etc. So I decided to 
look at a linux kernel (HEAD I assume) and look at the differences 
between the v6 and v4 directories. I just crudely did a line count as a 
quick measure:


ipv6: 68k lines

ipv4: 97k lines

ipv4 looks to have the tcp and udp implementations (35k) so backing that 
out it is about 62k lines. That's pretty comparable. Linux has full 
routing capability so the kernel implements it for both.


So I'm just not getting where this "bloat" is. 10% growth for a second 
system syndrome seems almost miraculously good, imo.


What am i missing? This is in complete agreement with my intuition 30 
years ago that it was no big deal, at least from a software standpoint.


Mike