date:20220316

Re: V6 still not supported

2022-03-16 Thread William Allen Simpson


On 3/10/22 9:22 PM, Masataka Ohta wrote:

Matthew Walster wrote:


IPv6 is technologically superior to IPv4, there's no doubt about that.


It is not. Though IPv6 was designed against OSI CLNP (with 20B,
or, optionally, 40B addresses), IPv6 incorporated many abandoned
ideas of CLNP and XNS already known to be useless or harmful with
experiences on IPv4 to be a protocol as bad as or even worse than
CLNP.

For example, address length was extended from original 8B to
16B to allow lower 48bits be MAC addresses, which was what
XNS was doing, only to make ISP operations with raw
addresses prohibitively painful.



IPv6 as originally designed had 8 byte (64-bit) addresses that had no
difficulty including 48-bit MAC addresses for link-local deployment.

It was explicitly stated that they would *NEVER* be globally visible,
as there were many documented examples of duplicate MAC assignments.

Then, the powers that be declared that IPv6 should have 128-bit addresses,
and a host of committees were setup with competing CLNP (TUBA) co-chairs.
They incorporated many ideas of CLNP and XNS that were thought (by many of
us) to be worthless, useless, and harmful.  Committee-itis at its worst.

My original address plan had the leading 32 bits as the existing ASN,
with the lower 32-bits as the existing IPv4 address.  Making ISP
operations eminently easier, as we already knew those two things.

Re: Making Use of 240/4 NetBlock Re: 202203162242.AYC

2022-03-16 Thread Abraham Y. Chen


Hi, Fred:

1)    " ... you will need to replace the existing DNS and DHCP 
systems...  ":    I am glad that you have touched the next level of 
considerations. Operating an RAN with one 240/4 netblock, there will be 
more than enough IP addresses to assign to all client premises. So, the 
EzIP deployment will operate with static IP address disciplines, 
negating the fundamental reasons to have DNS and DHCP. That is, 
transition to running the electronic equivalent of telephony White and 
Yellow Pages would be what EzIP deployment should rely upon.


2)    " ... hear the relevant organizations saying that it changes their 
networking model, ... similar to what has happened with the IPv6 
deployment.  ":    Do they recognize that implementing EzIP address plan 
on CG-NAT changes no network model? So, the perturbation is far less 
than deploying IPv6.


Regards,


Abe (2022-03-16 22:59)


On 2022-03-16 12:03, Fred Baker wrote:

On Mar 16, 2022, at 7:50 AM, Abraham Y. Chen  wrote:

2)Re: Ur. Pt. 2) " So replace every CPE device, including ...   ": It 
is evident that  you even did not glance at the EzIP Draft Abstract before commenting, 
but just relying on your recollection of the past 240/4 efforts.

I did read it. Correct my understanding.

Your proposal is to replace the IP addressing model and IP (yes, you're using 
options, but the architecture changed). Do so do, you will need to replace the 
existing DNS and DHCP systems with a PABX-like model - you need to find a way 
to let systems address each other. It also replaces firewalls with a model that 
prevents communication with devices that don't know the PABX port numbers.

Frankly, I can already hear the relevant organizations saying that it changes 
their networking model, and it starts a process similar to what has happened 
with the IPv6 deployment.




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: V6 still not supported

2022-03-16 Thread William Allen Simpson

I'd flagged this to reply, but sadly am a bit behind

On 3/10/22 11:02 AM, Matthew Walster wrote:
IPv6 is technologically superior to IPv4, there's no doubt about that. It is vastly inferior when it comes to understanding what is going on by your average sysadmin, network engineer, IT helpdesk person -- it is just far too complicated. Even the wording
is confusing, e.g. router/neighbor "solicitation/advertisement" instead of "request/reply".

I'd wanted to clearly distinguish this from the old methods:

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 thousands of systems per link, rather
than the 30 maximum under then current ethernet standards. We needed fewer
announcements, less chatty traffic, and more specific traffic designation.

We also prioritized network security. Moreover requiring addresses be
ephemeral,
such that applications would not be able to tie authentication/authorization to
an
IPv6 address and would be motivated to use cryptographic security.

Unfortunately, later committees decided that rather than a single simpler
secured
address assignment scheme, we needed unsecured SLAAC and duplicate DHCPv6.
Three ways to do the same thing are always a recipe for disaster.

IPv6 is a case study in how all too often human factors are not considered in
the design of engineering projects. [...]

Reminder: I was an operator and one of the original NANOG members.

We spent a lot of time considering human factors. I'd pioneered the
"Operational Considerations" section of the original draft RFCs.

IPv6 is a case study of what happens with committee-itis.

The small design team worked well.

On 3/16/22 9:03 PM, John Gilmore wrote:
> Given the billions of people who eat and sleep for HOURS every day, I
> think I am doing pretty well by just coordinating three people part-time
> trying to improve IPv4 a little bit. [...]
>

Please tell me where this excellent effort is underway?

Re: V6 still not supported

2022-03-16 Thread John Gilmore

> > Let me say that again.  Among all the reasons why IPv6 didn't take
> > over the world, NONE of them is "because we spent all our time
> > improving IPv4 standards instead".
> 
> I'll somewhat call bullshit on this conclusion from the data
> available. True, none of the reasons directly claim "IPv6 isn't good
> enough because we did X for v4 instead", yet all of them in some way
> refer back to "insufficient resources to make this the top priority."
> which means that any resources being dedicated to improving (or more
> accurately further band-aiding) IPv4 are effectively being taken away
> from solving the problems that exist with IPv6 pretty much by
> definition.

Hi, Owen.  Your reasoning proves too much.

You propose that every minute of every day that every human isn't
actively working at top priority to make IPv6 the default protocol on
the Internet, are misguided efforts.  "Pretty much by definition."

"Any resources being dedicated to" eating, sleeping, going to the
bathroom, listening to music, painting a canvas, repairing cars,
steering ships, growing food, running railroads, going to school, going
to work, riding bicycles, ending homelessness, stopping wars, reforming
drug laws, band-aiding IPv4, reducing corruption in government, posting to
mailing lists (as you pointed out -- by posting a message to a mailing
list!), hopping, skipping, and jumping, "are effectively being taken
away from solving the problems that exist with IPv6."

Given the billions of people who eat and sleep for HOURS every day, I
think I am doing pretty well by just coordinating three people part-time
trying to improve IPv4 a little bit.  The eaters' and sleepers' level of
non-IPv6 effort is billions of times stronger than my level of non-IPv6
effort.  Can you forgive me?

John

Re: Regarding BGP offloading

2022-03-16 Thread Jeff Tantsura

IOS- XR and Junos (don’t know about others) expose service level APIs that 
allow offbox best path selection and consequently injecting these back into RIB.
FRR is in process of implementing customized best path using lua scripts.

Cheers,
Jeff

> On Mar 16, 2022, at 16:15, Anurag Bhatia  wrote:
> 
> 
> Hello NANOG!
> 
> 
> I have seen limited talks about offloading of BGP as a whole into 
> containers/VMs etc. Take e.g this old Google blog post from 2017. Quoting 
> from that: 
> 
>> Second, we separate the logic and control of traffic management from the 
>> confines of individual router “boxes.” Rather than relying on thousands of 
>> individual routers to manage and learn from packet streams, we push the 
>> functionality to a distributed system that extracts the aggregate 
>> information. We leverage our large-scale computing infrastructure and 
>> signals from the application itself to learn how individual flows are 
>> performing, as determined by the end user’s perception of quality.
> 
> 
> If I am reading this correctly, it gives an impression of just BGP signalling 
> offload (to VMs/containers...). Is that understanding correct? Speaking from 
> network topology wise anyone here has an idea or could point to a resource on 
> how it is actually achieved? If the frontend device simply starts passing TCP 
> 179 requests to some backend server running say bird, frr etc, how will that 
> information be passed back to the forwarding plane? Are there more public 
> deployments of this sort of setup where BGP as a whole (that is sessions, 
> route calculation, policies, filtering etc) is offloaded to some x86 device 
> in the backend? 
> 
> Or am I just reading it wrong and it's actually smaller VM/containers will 
> full router functionality and BGP alone is not being offloaded? So the 
> logical L3 endpoint here is VMs? What sort of config the device sitting in 
> frontend would have at the interface level to achieve that? 
> 
> 
> 
> Appreciate your responses! 
> 
> Thanks. 
> 
> -- 
> Anurag Bhatia
> anuragbhatia.com

Re: Regarding BGP offloading

2022-03-16 Thread Yang Yu

more details on the particular implementation
https://www.cs.princeton.edu/courses/archive/fall17/cos561/papers/espresso17.pdf

On Wed, Mar 16, 2022 at 6:14 PM Anurag Bhatia  wrote:
>
> Hello NANOG!
>
>
> I have seen limited talks about offloading of BGP as a whole into 
> containers/VMs etc. Take e.g this old Google blog post from 2017. Quoting 
> from that:
>
>> Second, we separate the logic and control of traffic management from the 
>> confines of individual router “boxes.” Rather than relying on thousands of 
>> individual routers to manage and learn from packet streams, we push the 
>> functionality to a distributed system that extracts the aggregate 
>> information. We leverage our large-scale computing infrastructure and 
>> signals from the application itself to learn how individual flows are 
>> performing, as determined by the end user’s perception of quality.
>
>
>
> If I am reading this correctly, it gives an impression of just BGP signalling 
> offload (to VMs/containers...). Is that understanding correct? Speaking from 
> network topology wise anyone here has an idea or could point to a resource on 
> how it is actually achieved? If the frontend device simply starts passing TCP 
> 179 requests to some backend server running say bird, frr etc, how will that 
> information be passed back to the forwarding plane? Are there more public 
> deployments of this sort of setup where BGP as a whole (that is sessions, 
> route calculation, policies, filtering etc) is offloaded to some x86 device 
> in the backend?
>
> Or am I just reading it wrong and it's actually smaller VM/containers will 
> full router functionality and BGP alone is not being offloaded? So the 
> logical L3 endpoint here is VMs? What sort of config the device sitting in 
> frontend would have at the interface level to achieve that?
>
>
>
> Appreciate your responses!
>
> Thanks.
>
> --
> Anurag Bhatia
> anuragbhatia.com

Re: Regarding BGP offloading

2022-03-16 Thread Yang Yu

One way to do it https://inog.net/files/iNOG14v_oliver_sourcerouting.pdf

On Wed, Mar 16, 2022 at 6:14 PM Anurag Bhatia  wrote:
>
> Hello NANOG!
>
>
> I have seen limited talks about offloading of BGP as a whole into 
> containers/VMs etc. Take e.g this old Google blog post from 2017. Quoting 
> from that:
>
>> Second, we separate the logic and control of traffic management from the 
>> confines of individual router “boxes.” Rather than relying on thousands of 
>> individual routers to manage and learn from packet streams, we push the 
>> functionality to a distributed system that extracts the aggregate 
>> information. We leverage our large-scale computing infrastructure and 
>> signals from the application itself to learn how individual flows are 
>> performing, as determined by the end user’s perception of quality.
>
>
>
> If I am reading this correctly, it gives an impression of just BGP signalling 
> offload (to VMs/containers...). Is that understanding correct? Speaking from 
> network topology wise anyone here has an idea or could point to a resource on 
> how it is actually achieved? If the frontend device simply starts passing TCP 
> 179 requests to some backend server running say bird, frr etc, how will that 
> information be passed back to the forwarding plane? Are there more public 
> deployments of this sort of setup where BGP as a whole (that is sessions, 
> route calculation, policies, filtering etc) is offloaded to some x86 device 
> in the backend?
>
> Or am I just reading it wrong and it's actually smaller VM/containers will 
> full router functionality and BGP alone is not being offloaded? So the 
> logical L3 endpoint here is VMs? What sort of config the device sitting in 
> frontend would have at the interface level to achieve that?
>
>
>
> Appreciate your responses!
>
> Thanks.
>
> --
> Anurag Bhatia
> anuragbhatia.com

Regarding BGP offloading

2022-03-16 Thread Anurag Bhatia

Hello NANOG!


I have seen limited talks about offloading of BGP as a whole into
containers/VMs etc. Take e.g this old Google blog post

from 2017. Quoting from that:

*Second, we separate the logic and control of traffic management from the
> confines of individual router “boxes.” Rather than relying on thousands of
> individual routers to manage and learn from packet streams, we push the
> functionality to a distributed system that extracts the aggregate
> information. We leverage our large-scale computing infrastructure and
> signals from the application itself to learn how individual flows are
> performing, as determined by the end user’s perception of quality.*



If I am reading this correctly, it gives an impression of just BGP
signalling offload (to VMs/containers...). Is that understanding correct?
Speaking from network topology wise anyone here has an idea or could point
to a resource on how it is actually achieved? If the frontend device simply
starts passing TCP 179 requests to some backend server running say bird,
frr etc, how will that information be passed back to the forwarding plane?
Are there more public deployments of this sort of setup where BGP as a
whole (that is sessions, route calculation, policies, filtering etc) is
offloaded to some x86 device in the backend?

Or am I just reading it wrong and it's actually smaller VM/containers will
full router functionality and BGP alone is not being offloaded? So the
logical L3 endpoint here is VMs? What sort of config the device sitting in
frontend would have at the interface level to achieve that?



Appreciate your responses!

Thanks.

-- 
Anurag Bhatia
anuragbhatia.com

Re: Not Making Use of 240/4 NetBlock

2022-03-16 Thread Mark Andrews

It’s a business problem for the RIR’s. Selling / leasing known defective 
products is against lots of consumer law. 
-- 
Mark Andrews

> On 17 Mar 2022, at 03:43, Owen DeLong  wrote:
> 
> 
> 
>>> On Mar 15, 2022, at 19:23 , Mark Andrews  wrote:
>>> 
>>> 
>>> 
 On 16 Mar 2022, at 02:54, Owen DeLong via NANOG  wrote:
>>> 
>>> Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able
>>> to claim some detailed knowledge on the subject.
>>> 
>>> In general, the RIRs themselves maintain neutrality about such things, 
>>> looking to their
>>> respective communities for input on what to do. However, so long as the 
>>> IETF and
>>> has not designated the space Unicast Address Space to be delegated to the
>>> RIRs for allocation/assignment, IANA will not delegate it to the RIRs and 
>>> the RIRs
>>> won’t, therefore, delegate it to users.
>>> 
>>> If you really want to see this happen (and I still argue that the amount of 
>>> effort already wasted
>>> discussing this idea vastly exceeds what would be needed towards IPv6 to 
>>> get beyond
>>> caring about it), then the first step must be to convince the IETF to 
>>> designate the
>>> space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the 
>>> RIRs.
>>> 
>>> Once that happens, the rest of the allocation process is basically 
>>> automatic. From a policy
>>> perspective at the RIR level, it will be no different than say 4/8 or 1/8.
>> 
>> Actually it would be fundamentally different to 4/8 or 1/8.  You are looking 
>> at firmware upgrades
>> rather than dealing with squatters and out-of-date ACLs both of which are 
>> self-inflicted by one
>> of the parties.  Routers and end devices that don’t know how to hand 240/4 
>> are no self inflicted
>> injuries.  Issuing 4/8 or 1/8 worked for parties that had been following the 
>> rules.  With 240/4
>> there where no rules to follow which results in RIR’s leasing known 
>> defective addresses.
> 
> I was speaking from an RIR allocation perspective, NOT talking about the 
> technological hurdles
> to implementation.
> 
> I was specifically responding to someone’s question about how the RIRs would 
> be impacted by
> this if it were to come to pass.
> 
> I addressed your concern in the following paragraph as an aside, however.
> 
>> 
>>> Now, convincing vendors to update their firmware, software, etc. is another 
>>> matter
>>> and entirely outside of the control of the RIRs. Merchant compliance with 
>>> IETF standards
>>> is generally considered useful, but it is entirely voluntary and even in 
>>> the best of
>>> circumstances doesn’t every happen instantaneously and almost always 
>>> involves
>>> some stumbles along the way.
>>> 
>>> Owen
>>> 
>>> 
 On Mar 15, 2022, at 02:54 , Sylvain Baya  wrote:
 
 Dear NANOG-ers,
 Hope this email finds you in good health!
 Please see my comments below, inline...
 
 Le mardi 15 mars 2022,  a écrit :
 
 
 Hi Barry,
 Thanks for your email, brother!
 
 
 But the RIRs are the ones fielding requests for IPv4 space, and have
 some notion of how policy implementation might work in practice, so
 should have a lot of useful input.
 
 
 ...of course, it appears that RIRs have the opportunity
 to add their useful inputs, as Impact Analysis Report
 (IAR); during the Policy Development Process (PDP)
 initiated by the *appropriate* [1] Internet community.
 They explain it themselves here [2].
 __
 [1]: 
 [2]: 
 
 Shalom,
 --sb.
 
 
 On March 14, 2022 at 00:45 niels=na...@bakker.net (Niels Bakker) wrote:
> * b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:
>> Personally I'd rather hear from the RIRs regarding the value or not 
>> of making more IPv4 space such as 240/4 available. They're on the 
>> front lines of this.
> 
> You've got your policy development process diagram upside down. The 
> community decides what the RIRs implement. They're not in touch with 
> merchant silicon manufacturers.
> 
> 
>-- Niels.
 
 -- 
   -Barry Shein
 
 Software Tool & Die| b...@theworld.com | 
 http://www.TheWorld.com
 Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
 The World: Since 1989  | A Public Information Utility | *oo*
 
 
 -- 
 Best Regards !
 __
 baya.sylvain[AT cmNOG DOT cm]|
 Subscribe to Mailing List: 
 __
 #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec 
 vous tous! ‪#‎Amen‬!»
 ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
 «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire 
 après TOI, ô

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

2022-03-16 Thread Greg Skinner via NANOG

I have qualms about these drafts also.  However, even if the IETF does not move 
forward with any of them (not even to adopt them as WG items), that doesn’t 
mean they never will.  Times change.  Circumstances change.  The IETF has 
changed its position on several (IMO) key issues during its existence.  Perhaps 
this will be one of those times.

Incidentally, if you take a look at this post from Theodore Ts’o 
  he’s 
pretty much saying the same thing that Barry Shein said, that the IETF isn’t as 
good at policy as it is in producing protocol standards.  (The thread it’s from 
started from a response to the publication of RFC2008 
 as a Best Current Practice, in 
spite of “vigorous opposition”.)

The other thing I wanted to say is for anyone who doesn’t know a lot about the 
IETF workings, the contributions of some of the authors of the Schoen drafts 
are recognized and respected in the IETF Transport Area.  They’re not new to 
this stuff.  They have “clue”.  They do due diligence.  They produce running 
code, and (IMO) are seeking rough consensus.  I believe that in the IETF of, 
say, a quarter century ago, their drafts would have progressed further through 
the standards process.  For various reasons, today’s IETF is different, but 
could still change its minds.  I believe the authors of the Schoen drafts are 
capable of drumming up support for their ideas even if they don’t (immediately) 
become IETF drafts, and that the IETF might change its position on their ideas, 
as a result of such support.

—gregbo

> On Mar 16, 2022, at 5:28 AM, Tom Beecher  wrote:
> 
> No quibble about the discussion happening on a NOG list, not at all. 
> 
> But frankly unless the proposal is even starting to move forward in the IETF 
> process such that a standards change is possible, it's just noise. ( I don't 
> predict that the draft being discussed ever gets that far anyways ; it has 
> serious deficiencies.) 
> 
> On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG  > wrote:
> I agree.  iMO, this 240/4 issue is another one of those tussles in cyberspace 
> .   But I 
> don’t fault IETF people or anyone else who pursues technical solutions to 
> these types of problems as long as they are open and honest about the 
> limitations of these solutions.
> 
> Also, IMO, the value of having a discussion about this issue here (and other 
> NOG forums) is to get the perspective of people who (generally speaking) deal 
> more immediately with the problems the broader “online" population has with 
> IETF-based technology.
> 
> —gregbo
> 
>> On Mar 8, 2022, at 9:25 PM, b...@theworld.com  
>> wrote:
>> 
>> 
>> I'm beginning to wonder if the internet will survive the ipv6 adoption
>> debates.
>> 
>> Here's the real problem which you all can promptly ignore:
>> 
>> The IETF et al are full of bright technical people who can design
>> protocols, packet formats, etc.
>> 
>> But many of the major problems facing the internet are not, at their
>> core, engineering problems.
>> 
>> They're in the realm of social, legal, marketing, politics, int'l
>> policy, governance, law enforcement, commerce, economics, sociology,
>> psychology, etc. which TBH as bright as many of the engineers et al
>> are these problems are way beyond their ken, occasional polymath
>> excepted.
>> 
>> But first you have to admit you have a problem, and limitations.
>> 
>> Shouting at the rafters about address space depletion etc while waving
>> RFCs may not quite do it.
>> 
>> Similar can be said about spam, malware attacks, phishing, etc.
>> 
>> Yet another cryptographic protocol probably won't save the day but as
>> the expression goes when all you have is a hammer the whole world
>> looks like a nail.
>> 
>> -- 
>>-Barry Shein
>> 
>> Software Tool & Die| bzs at TheWorld.com   
>>| http://www.TheWorld.com 
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>> 
>

47 matches

Mail list logo