Re: IPv6 "bloat"

[Crist Clark <cjc+nanog () pumpky net>]

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 <nanog () nanog org>
wrote:

> On Mar 20, 2022, at 07:17, Lady Benjamin Cannon of Glencoe <lb () 6by7 net>
> 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
> ben () 6by7 net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME
> <https://alexmhoulton.wixsite.com/6x7networks>
>
> FCC License KJ6FJJ
>
>
>
>
> On Mar 19, 2022, at 3:56 PM, Matt Hoppes <
> mattlists () 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.