- On Mar 19, 2022, at 6:44 PM, Matt Hoppes
mattli...@rivervalleyinternet.net wrote:
> After a time of transition, all clients would be running 128 bit
> addresses (or whatever length was determined to be helpful).
What you describe is literally IPv6.
> Just like with IPv6, there would
On 19Mar22, Matt Hoppes allegedly wrote:
> So, while it's true that a 192.168.0.1 computer couldn't connect to a
> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch
> would be very simple and quick to deploy
Let's call this ipv4++
Question: How does 192.168.0.1 learn about
It appears that Matt Hoppes said:
>Just like with IPv6, there would be a transition period, but during that
>time software updates would very easily bring equipment up to spec much
>faster and quicker.
>
>Eventually, 192.168.0.1 would be represented (for example) as
>0.0.0.0.192.168.0.1 (or
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
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
>
> 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,
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
>
> So, while it's true that a 192.168.0.1 computer couldn't connect to a
> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch
> would be very simple and quick to deploy.
>
Software patches are never simple and quick to deploy. In fact, a common
argument from people who don't
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
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
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.
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:
After a time of transition, all clients would be running 128 bit
addresses (or whatever length was determined to be helpful).
Just like with IPv6, there would be a transition period, but during that
time software updates would very easily bring equipment up to spec much
faster and quicker.
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
On 3/19/22 1:44 PM, James R Cutler wrote:
On Mar 19, 2022, at 2:49 PM, Michael Thomas wrote:
IPv6 in comparison was very familiar ground. To me it seemed that it was ipv4
with bigger addresses and that was about it. But I've never understood all of
the strum und drang about ipv6.
As one
> On Mar 19, 2022, at 2:49 PM, Michael Thomas wrote:
>
> IPv6 in comparison was very familiar ground. To me it seemed that it was ipv4
> with bigger addresses and that was about it. But I've never understood all of
> the strum und drang about ipv6.
As one tightly involved in multiprotocol
I had completely forgot about RARP! We had similar considerations when I
designed the Lantronix terminal servers. We patterned them off of the
DEC terminal servers on the DEC side which net loaded images (I want to
think that DEC used MOP to download, but I could be wrong), but the
combination
Michael Thomas 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.
Speaking as one of the co-designers of BOOTP (RFC 951): yes, it was
experimental. So why was it "slapped onto" IP? Well, in
On Sat, 19 Mar 2022 at 03:32, wrote:
> I'll mention, as I often do at this point in this conversation over
> the past few decades, that nothing stops you from designing and
> implementing such a network and, for demonstration / proof of concept
> purposes at least, floating it on top of IP.
>
>
19 matches
Mail list logo
