Hello Masataka-san
> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
>
> As such, the solutions
Hello Masataka-san
For that issue at least there was some effort.
Though ATM and FR appear to be long gone, the problem got even worse with
pseudo wires / overlays and wireless.
It was tackled in the IoT community 10+ years ago and we ended up with RFC 8505
and 8928. This is implemented in
age-
> From: Saku Ytti
> Sent: mercredi 10 août 2022 7:14
> To: Pascal Thubert (pthubert)
> Cc: Mel Beckman ; nanog@nanog.org
> Subject: Re: IoT - The end of the internet
>
> On Wed, 10 Aug 2022 at 07:54, Pascal Thubert (pthubert) via NANOG
> wrote:
>
> > On a
On a more positive note, the IPv6 IoT can be seen as an experiment on how we
can scale the internet another order of magnitude or 2 without taking the power
or the spectrum consumption to the parallel levels.
For that we turned protocols like ND and MLD from broadcast pull to unicast
push in a
Dear Abe:
Yes, this is plain IP in IP. For a router does not know about YADA, this looks
like the most basic form of tunnel you can get. Which is where the inner/outer
terminology comes from. All very classical. We could do an over-UDP variation
if people want it.
I used a condensed format to
Dear all
Following advice from thus list, I updated the YADA I-Draft (latest is
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to
come soon if feedback is heard) and proposed it to the v6ops WG at the IETF.
For memory, the main goal here is to find a compromise as
enefits of it other than just moving to IPv6?
Regards,
Dave
On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG
mailto:nanog@nanog.org>> wrote:
Hello Matthew
At the moment the draft has a general architecture, and it will take the right
minds and experience to turn a m
Considering this requires updating every single IP stack that wants to utilise
this, what are the benefits of it other than just moving to IPv6?
Regards,
Dave
On Tue, 5 Apr 2022 at 08:24, Pascal Thubert (pthubert) via NANOG
mailto:nanog@nanog.org>> wrote:
Hello Matthew
At the moment the dra
Hello Matthew
At the moment the draft has a general architecture, and it will take the right
minds and experience to turn a model into a live network. Considering what the
people in this list have already built, it’s no gigantic leap to figure they
can build that too. Most of the building
ot enough
bits for Shaft.
If you would appoint Governments as the Shaft responsible then would be a so
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG
[mailto:nanog-bounces+vasilenko.eduard<mailt
uld regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG
[mailto:nanog-bounces+vasilenko.eduard<mailto:nanog-bounces%2Bvasilenko.eduard>=huawei@nanog.org<mailto:huawei@nanog.org>]
On Behalf Of Pascal Thubert (pthub
headers (from IPv4 to IPv6).
>>> Who should implement this gateway and why? He should be formally
>>> appointed to such an exercise, right?
>>> Map this 2 level hierarchy to the real world – you may fail with this.
>>> Ed/
>>> From: Pascal Thubert
gt; be a Default Free Zone?
>> I agree with your real world issue that some things will have to be
>> planned between stake holders, and that it will not be easy.
>> But you know what the French say about “impossible”.
>> Or to paraphrase Sir Arthur, now that we have eliminated
dredi 1 avril 2022 14:32
> To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>; Justin Streiner
> <mailto:strein...@gmail.com>; Abraham Y. Chen <mailto:ayc...@avinta.com>
> Subject: RE: Let's Focus on Moving Forward Re: V6 still not supported re:
> 202203261833.AYC
&g
re:
> 202203261833.AYC
>
> Hi Pascal,
> In general, your idea to create a hierarchy is good.
> In practice, it would fail because you have created a virtual hierarchy
> that does not map to any administrative border. Who should implement
> gateways for the “Shaft”? Why?
> If you woul
Hello Ohta-san
> it is hopeless.
If you look at it, LS - as OSPF and ISIS use it - depends on the fact that all
nodes get the same information and react the same way. Isn't that hopeless too?
Clearly, the above limits LS applicability to stable links and topologies, and
powered devices. This
Hello Dave:
There's RFC 8950 in the context of BGP. That's a refresher of RFC 5589 which is
the one we typically refer to internally.
I glanced at homenet too early, and then too late. Too early, it seemed that
the protocol would be OSPFv3; no discussion. So I left till too late, when the
overnments as the Shaft responsible then would be a so
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On
Behalf Of Pascal Thubert (pthubert) v
point Governments as the Shaft responsible then would be a so
big scandal that you would regret the proposal.
Hence, I do not see proper mapping for the hierarchy to make YADA successful.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei....@nanog.org] On
Behalf Of Pascal Thubert
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
age001.png@01D842A4.69CBE6F0]
Hmm.
-Original Message-
From: NANOG
mailto:nanog-bounces+rkremeier=barryelectric@nanog.org>>
On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg
mailto:pch-nano...@u-1.phicoh.com>>
There are 2 ways to stop a war:
1) one side it utterly defeated and disaggregated
2) both sides suffered enough and agree to start thinking of the best terms for
coexistence
1) is not close to happening any time soon
From this, the conclusion is that we have not suffered enough.
On the side,
For the sake of it, Justin, I just published
https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/.
The first section of the draft (YADA) extends IPv4 range in an IPv4-only world.
For some people that might be enough and I’m totally fine with that.
Keep safe;
Pascal
From: NANOG On
He he, why do you think YADA starts with yet another?
The devil is in the details I guess. AA makes A twice longer, that's the easy
piece. But then, what is the story for the A->AA transition?
The key piece the concept of the shaft, that enables to transit AA between
levels while seeing plain
A very long thread.
Face it: everyone is right, and even technically correct. There's no good and
evil. We'd know, after 20 years.
I live in France and my country has a famous 100-years war in its long history
with England. Do we want to beat this here?
The plain truth:
- IPv4 is here to
>
> 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
Hi Eduard
And SDN, and overlays, and... I certainly agree with what you're saying.
This is why the L3 tech has to keep evolving as a survival trait. It's a
delicate balance between evolving too quickly and producing the impression on
unstable tech in the one hand, and stalling in the
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
son
> 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 observa
Hi Mark and all:
Indeed, we have a plethora of IPv4 encapsulation and 4-to-6 techniques.
I read somewhere down the threads that we (at IETF) made a "stupendously" bad
bet thinking that IPv6 would be generalized quickly thanks to those techniques.
Being partially guilty of that (e.g., but not
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
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
Seems that we lost sync.
I would not rephrase so I made it a draft to make it easy to socialize:
https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html
The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I
agree you need the traditional transition
Hello Phil
The only far ressemblance with 6to4 is the thing that was actually nice in the
design, the automatic word in automatic tunnel. Which for the rest of us means
stateless. Compared to CGNATs that is huge.
Beyond that the proposal is not a tunnel and more akin to a nat64 since it
.
No one yet answered me on the technical aspects. That kind of baffles me.
Keep safe;
Pascal
> Le 25 mars 2022 à 03:17, John Gilmore a écrit :
>
> Pascal Thubert \(pthubert\) via NANOG wrote:
>> I'm personally fond of the IP-in-IP variation that filed in 20+ years
>
OK so you really did not read my post, even now. The tech I described was pure
v4. It would pass your gateway.
The only we can talk is that we listen to each other... Quoting the text so you
do not need to look it up:
"
My frustration is that indeed (as a dev guy) we have been trying hard to
Hello Mark:
> Any such "transition plan" whether "working" or "straightforward" is
> logically impossible. Why anyone thinks such a mythical plan might yet be
> formulated some 20+ years after deploying any of ipv6, ipv4++ or ipv6-lite is
> absurd.
This is dishonest, considering that I just
that we can identify, as
we discuss more.
I look forward to your thoughts and critiques.
Regards,
Abe (2022-03-23 11:59 EDT)
On 2022-03-23 05:01, Pascal Thubert (pthubert) via NANOG wrote:
I see the same thing from the other side, being a S/W developer for switching
and routing boxes since the ea
I see the same thing from the other side, being a S/W developer for switching
and routing boxes since the early 90's. The PM barrier is a high wall indeed.
And yet some techs succeed to pass it. What I'm arguing is that we can pass
that wall if we work together with the same objective.
I've
Complaining is fun and healthy.
But I was unclear, not asking about v4 vs. v6, but about caring for /
contributing to evolution of network protocols, or not.
Some evolution has happened in the IPv6 world, more could happen, so it gets
better. Or throw the baby?
Keep safe;
Pascal
>
Hi:
IPv4 is 40 years old. IPv6 is 25 years old. In Internet time, both are old
timers.
Since then, networks have evolved dramatically, with new physical media like
wireless that hates broadcasts, and new logical constructs like overlays in
cloud and SD WAN which require new IP abstractions
Hello Saku:
> > This is intended to replace ARP, ICMP Router Advertisement, ICMP
> > Redirect, ICMP Information, ICMP Mask, and OSPF Hello in the
> [IPv6]
> > environment. There are also elements of the OSI ES-IS and IS-IS
> Hello.
> >
> > We were forward looking to deployments of
Hello Joel
Far from widely available but:
- we updated IPv6 ND for P2MP with RFC8505
- address ownership can be protected with RFC 8928
- early work is available for eVPN with
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00
All this is IPv6 only and not
Dear all:
How many bits of entropy do we need for (ECMP) load balancing in the core?
This question has kept coming up regularly in many discussions and drafts at
the IETF.
The IPv6 flow label is 20 bits but hardware implementations do their balancing
only on a subset of that, e.g. 12 or 16
Hello Baldur;
There’s the hack that can be helpful and then there’s the proper solution.
As for hacks, indeed snooping can help a lot. As it goes we went for ND and
DHCP snooping rather than MLD and there are many reasons for that, reliability,
Desire to know the address not just the snma
Hello Joel:
The draft is supposed to be factual not divagations; if I went too far
somewhere I need to fix the draft. As you said it is early personal submission.
Multi links subnets are not a figment of my mind. We have millions of routers
deployed that way, using RPL as the subnet routing
I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref
to RFC 5942 in section 4.4 that discusses the use of on-link flag.
Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT
network such as a RPL domain, or a frame relay network with OSPFv2 NBMA
47 matches
Mail list logo
