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
interfa
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
>
> 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 st
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
nt: 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 un
: 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 D
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
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
observ
em 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@na
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 abou
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 adopti
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 bu
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 mec
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.
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
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
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
r 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
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
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
wr
> 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 handin
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
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 p
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 f
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.
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 larg
>
> 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, 20
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 n
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
comm
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
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.
Wha
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:
S
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 me
33 matches
Mail list logo
