Dear BZS:
1) " ... it was more likely due to the success of CGNAT.": Looking
forward from this milestone marker, what would you envision as the
possible additions to CG-NAT's characteristics and capabilities for the
potential expansion of its services and enhancement to its performances?
Pascal Thubert (pthubert) wrote:
Hi,
Solutions must first avoid broadcast as much as possible, because
there's also the cost of it.
Though I'm not saying all the broadcast must be repeated,
if you think moderate broadcast is costly, just say,
CATENET.
I remember old days when entire network
rd side, it is adoption. People will not move
if it does not hurt enough. And they can bear a lot.
All the best
Pascal
> -Original Message-
> From: Masataka Ohta
> Sent: vendredi 13 janvier 2023 6:36
> To: Pascal Thubert (pthubert) ; nanog@nanog.org
> Subject: Re: A straightf
Pascal Thubert (pthubert) wrote:
Hi,
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
On Wed, Jan 11, 2023 at 11:16 PM Vasilenko Eduard via NANOG
wrote:
> The comment looks outdated: Who cares now about ATM?
You may have missed the sarcasm. The 1995 Addison Wesley IPng book
spends pages and pages talking about potential IPv6 use in the Navy
and interoperability with ATM before it
Of Masataka Ohta
Sent: Thursday, January 12, 2023 7:32 AM
To: nanog@nanog.org
Subject: Re: A straightforward transition plan (was: Re: V6 still not supported)
Randy Bush wrote:
> three of the promises of ipng which ipv6 did not deliver
>o compatibility/transition,
>o security, a
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
Randy Bush wrote:
three of the promises of ipng which ipv6 did not deliver
o compatibility/transition,
o security, and
o routing & renumbering
You miss a promise of
o ND over ATM/NBMA
which caused IPv6 lack a notion of link broadcast.
On January 12, 2023 at 02:11 n...@neo.co.tz (Noah) wrote:
> Hi John,
>
> So, It was assumed that IPv4 depletion would effectively lead to the adoption
> of IPv6. This has not been the case in the last decade save for a very few
> countries in the world.
>
> It was also assumed that IPv6
Randy -
Full agreement - nicely said.
/John
P.s disclaimer: my views alone - do not eat packet.
> On Jan 11, 2023, at 7:10 PM, Randy Bush wrote:
>
>
>>
>> It was assumed that IPng would include a standard straightforward
>> technological solution to support communication with IPv4 hosts –
> It was assumed that IPng would include a standard straightforward
> technological solution to support communication with IPv4 hosts – this
> was a defined hard requirement.
>
> This transition mechanism wasn’t available at the time of the
> selection of IPng, and instead was left as a future
Noah -
It was assumed that IPng would include a standard straightforward technological
solution to support communication with IPv4 hosts – this was a defined hard
requirement.
This transition mechanism wasn’t available at the time of the selection of
IPng, and instead was left as a future
Hi John,
So, It was assumed that IPv4 depletion would effectively lead to the
adoption of IPv6. This has not been the case in the last decade save for a
very few countries in the world.
It was also assumed that IPv6 only networks would crop all over the place
as a result, providing the same
--Original Message-
> From: NANOG On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
>
>
>
> > On 26 Mar 2022, at 21:51, Philip Homburg
> wrote:
>
> On 26 Mar 2022, at 21:51, Philip Homburg wrote:
>
>>> If there is a magical transition technology that allows an IPv6-only host t
>> o
>>> talk to an IPv4-only host, then let's deploy it.
>>
>> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
>> protocol and see what
Philip Homburg wrote:
It should be clear that an IPv4-only host only speaks IPv4. This means
that communication with an IPv4-only host has to be IPv4.
This did not have to be true, had there been an extension/option
standardized at the same time as IPv6 for IPv4 packets to be gateway'd
On Mon, Mar 28, 2022 at 6:22 AM Philip Homburg
wrote:
> >If by ?straightforward transition plan? one means a clear and rational
> set of
> >options that allows networks to plan their own migration from IPv4-only
> to IPv
> >6, while maintaining connectivity to IPv4-only hosts and with a level of
I don't think we can say that NAT64 is a disaster. I will say so if we want to
keep IPv4 only hosts in the "6" side, of course it doesn't work. However,
that's why we moved further with 464XLAT. And the demonstration is that most of
the operators are using it.
I think in your picture you're
> > If there is a magical transition technology that allows an IPv6-only host t
> o
> > talk to an IPv4-only host, then let's deploy it.
>
> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
> protocol and see what happens! (with more coming every year...)
The problem with
>If by ?straightforward transition plan? one means a clear and rational set of
>options that allows networks to plan their own migration from IPv4-only to IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of effor
>t reasonable comparable to just running IPv4, then I
On 25 Mar 2022, at 2:27 PM, Philip Homburg wrote:
>
>> If by ?straightforward transition plan? one means a clear and rational set
>> of
>> options that allows networks to plan their own migration from IPv4-only to
>> IPv
>> 6, while maintaining connectivity to IPv4-only hosts and with a level
21 matches
Mail list logo
