Fwd: Alternative Re: ipv4/25s and above Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:  Please disregard an earlier partial transmission of this 
MSG, caused by operator error. ***


1) One look at the NANOG archive that you retrieved tells me that we are 
the victims of the idiosyncrasies of the eMail system. Unlike snail 
mails that are slow but reliable (There was a story that USPS found a 
forty years old letter stuck in one of the mail collection boxes on 
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail 
monitoring account started to receive a long message that I was sending 
out, even before it was fully sent.) but unpredictable from time to 
time. Unfortunately, most of us are conditioned with its daily behavior 
and do not suspect the electronic system hiccups (As Andrew Grove once 
said, "It is the software, not the hardware."). To deal with this kind 
of issues in none-real-time communications, I practice a discipline, 
started from VM and FAX, that I will do my best to respond within 24 
hours. I encourage my colleagues to start reminding me (either repeat 
the MSG or using alternative channels, such as SkyPe - My handle is 
"Abraham.Y.Chen"), if they do not hear from me after 48 hours on topics 
that they expect my response. This convention prevented much of the 
disruptions. Looking at your comments, I definitely would have responded 
back then if I saw them. One possibility is that I was in the midst of 
being overwhelmed by NANOG posting protocols, such as the digest mode, 
uni-code, personal writing styles, etc. and miseed your MSG. Anyway, 
allow me to try carrying on.


2)   "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes the 
RAN in EzIP terminology. Since each RAN is tethered from the existing 
Internet core by an umbilical cord operating on one IPv4 public address, 
this is like a kite floating in the sky which is the basic building 
block for the overlaying EzIP Sub-Internet when they expand wide enough 
to begin covering significant areas of the world. Note that throughout 
this entire process, the Option Word mechanism in the IP header does not 
need be used at all. (It turns out that utilizing the CG-NAT 
configuration as the EzIP deployment vehicle, the only time that the 
Option Word may be used is when subscribers in two separate RANs wishing 
to have end-to-end communication, such as direct private eMail exchanges.)


3) " ... to drop any packet with an IP option set that you don't 
explicitly want because a significant number of routers kick every 
packet with options to CPU, ... ": Yes, this was what we were reminded 
of when we started our study. However, this appears to be another 
Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's 
Refernce 13) told me that his team had successfully sent packets with 
Option Words. Again, even if the existing routers do knock out packs 
with Option words, the overlay architecture of the RANs allows the 
search for those do allow this operation. Since the use of the Option 
Word turns out to be an option to superceed IPv4's capabilities, we 
should treat it as a consideration for future premium services.


4) " ...Any device that still treated 240/4 differently would need to be 
updated to treat it like anything else. .. ": Yes, this applies to 
regions that desire to enjoy the EzIP characteristics. Since the root of 
each RAN (or sub-RAN) still appears to be one of the current CG-NAT 
modules, there is no change can be detected by other CG-NAT modules. 
This avoids interoperability issues during the incremental deployment.


5) "  ...Any existing filters that dropped packets with *any* IP option 
set would have to be modified to permit the ones you define for 
EzIP":  Since EzIP is not going to activate Option Words initially 
for enhancing the CG-NAT, this should not be a concern. In the future, 
inter-RAN communication by subscribers would use Option words. But, by 
that time, finite number of backbone / gateway routers among RANs 
capable of preserving Option Words would have been identified. This 
approach takes advantage of the hierarchical network configuration that 
CG-NAT has already been practicing implicitly.


6) "... ( At one point in the past, one big router vendor only allowed 
you to configure an ip-options filter based on the IANA defined values, 
not others. ) ...": Well, you are talking about the overly intertwined 
relationship between one big roouter vendor and the IANA which is 
sponsored by the former. So, this is not a technical but a "busniess" 
issue. We have talked with "white box" vendors. One assured us that EzIP 
can be quickly activated in thier programs if customers do ask for it.


7) "... This is a LOT of work and time for an overlay. ...":  You are 
probably visualizing a complete overlay network right from the 

Re: Alternative Re: ipv4/25s and above Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:

1)  One look at the NANOG archive that you retrieved tells me that we 
are the victims of the idiosyncrasies of the eMail system. Unlike the 
snail mails are slow but reliable (There was a story that USPS found a 
forty years old letter stuck in one of the mail collection boxes on 
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail 
monitoring account started to receive a long message that I was sending 
out, even before it was fully sent.) but unpredictable from time to 
time. Unfortunately, most of us are conditioned with the normal speed 
and do not suspect the electronic system hiccups (As Andrew Grove once 
said, "It is the software, not the hardware.). To deal with this kind of 
issues in none-real time communication, I practice a discipline started 
from VM and FAX that I will respond within 24 hours. I encourage 
colleagues to start reminding me (either repeat the MSG or using 
alternative channels, such as SkyPe - My handle is A"Abraham.Y.Chen"), 
if they do not hear from me on topics expecting responses after 48 
hours. This convention prevented much of the disruptions. Looking at 
your comments, I definitely would have responded back then if I saw it. 
One possibility is that I was in the middle of trying to get used to 
NANOG posting protocols. I was probably overwhelmed by the digest mode, 
uni-code,etc. issues. Anyway, allow me to try carry on.


2) "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes the 
RAN in EzIP terminology. Each RAN is tethered from the existing Internet 
core by an umbilical core based on one IPv4 public address. This is like 
a kite floating in the sky which is basic building block of the 
overlaying Sub-Internet when they expand to cover the entire world. 
Throughout this entire process, the Option Word mechanism in the IP head 
doe not need be used at all. (It turns out that utilizing the CG-NAT 
configuration as the starting point, the only time that the Option Word 
may be used is when subscribers in two separate RANs wishing to have 
end-to-end communication, such as direct private eMail exchanges.





On 2022-11-21 18:46, Tom Beecher wrote:


1) As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.


I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
discussion with substance.


With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues 
with your proposal. Others have commented on non-technical, but 
practical considerations. In all cases, you have simply handwaved them 
away or not commented on them further.




On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.

2) Hint: I signed up to NANOG.org only early this year. So,
whatever you
have in mind might be from somewhere else. In addition, even
though I do
not have good memory, I do not leave a loose end to any technical
discussion with substance. The revisions of the EzIP documentation
have
always been improving the presentation style for easing the reader's
efforts, not about modifying our basic scheme. So, you need to be
clear
about the topics that you are referring to. Thanks.

Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
colleagues
>     on this forum can understand.
>
>
> Myself and multiple others provided specific technical rebuttals to
> the proposal in the past on this list.
>
>
>
> On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen

> wrote:
>
>     Dear Tom:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
>     colleagues
>     on this forum can understand.
>
>     Thanks,
>
>
>     Abe (2022-11-21 12:29 EST)
>
>
>
>
>     On 2022-11-21 10:44, Tom Beecher wrote:
>     >
>     >     1) "... Africa ... They don’t really have a lot of
>     alternatives. ...":
>     >     Actually, there is, simple and in plain sight. Please
have a
>     look
>     >     at the
>     >     below IETF Draft:
>     >
>     >
>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 2:13 PM, Tom Beecher  wrote:
> 
>> Serious consideration requires a serious proposal - I don’t think we’ve seen 
>> one yet.
> 
> I would posit that draft-schoen-intarea-unicast-240-03 ( 
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should 
> be considered a serious proposal, in so much as what is proposing is the most 
> direct:
> 
> - Redesignate 240/4 from RESERVED - Future Use to be available for allocation 
> as 'standard' IPv4 addresses. 
> 
> I personally disagree with their position, as does the IETF, so it doesn't 
> appear there will be any more movement on it, but I do believe that the idea 
> itself was serious.

Tom - 

Well, at least it is a readable and clear proposal, but again it lacks any 
meaningful treatment of interoperability – instead comparing the de-reservation 
and potential for future use of 240/4 with the various de-bogon efforts that 
were predominantly efforts to get long-time _already valid_ address space to be 
properly treated in the Internet –  

   Such a host might be inaccessible by some devices either on its local
   network segment or elsewhere on the Internet, due to a combination of
   host software limitations or reachability limitations in the network.
   IPv4 unicast interoperability with 240/4 can be expected to improve
   over time following the publication of this document.  Before or
   after allocations are eventually made within this range,
   "debogonization" efforts for allocated ranges can improve
   reachability to the whole address block.  Similar efforts have
   already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE
   Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16
   [RIPElabs128016].  The Internet community can use network probing
   with any of several measurement-oriented platforms to investigate how
   usable these addresses are at any particular point in time, as well
   as to localize medium-to-large-scale routing problems.  (Examples are
   described in [Huston], [NLNOGRing], and [Atlas].)  Any network
   operator to whom such addresses are made available by a future
   allocation will have to examine the situation in detail to determine
   how well its interoperability requirements will be met.

I.w.  the suggestion that the utilization of 240/4 space will solely be an 
issue for the "operator to whom such addresses are made available “ to examine 
(with respect to their requirements) really completely ignores the fact that 
such address space utilized in the production Internet will experience 
unpredictable intermittent communication failures for years (if not decades) to 
come, and hence it an issue of concern for the entire operations community, not 
just those who may receive such allocations.   Again, the IETF's host and 
router requirements documents has specified discard of these packets since the 
90’s, so there needs to be a clear model for transition (rather than vague 
statements left to the reader)l that covers how network operators at both ends 
will know of the failure (and workarounds) when the use of these addresses 
results in failed communication.  Absent such, I’m not sure why anyone should 
give consideration to this Internet draft– it can’t be safely deployed in the 
actual real-world Internet, making it more of a paper chimera than a serious 
proposal. 

Thanks,
/John

p.s.  Disclaimer(s):  my views alone - any hazards seen in them may be much 
closer than they appear…

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Tom Beecher]

>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>

I would posit that draft-schoen-intarea-unicast-240-03 (
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should
be considered a serious proposal, in so much as what is proposing is the
most direct:

- Redesignate 240/4 from RESERVED - Future Use to be available for
allocation as 'standard' IPv4 addresses.

I personally disagree with their position, as does the IETF, so it doesn't
appear there will be any more movement on it, but I do believe that the
idea itself was serious.

Of course, I also agree with you that there have been plenty of un-serious
proposals floated too which don't really require discussion. :)

On Tue, Nov 22, 2022 at 1:48 PM John Curran  wrote:

>
>
> On Nov 22, 2022, at 1:19 PM, Joe Maimon  wrote:
>
> John Curran wrote:
>
>
> By the way, you shouldn’t feel particularly bad about skipping out on the
> interoperability requirement – anything involving interworking with the
> installed Internet is hard, and this is the same lesson that the IPv6 folks
> found out the hard way…   I will confess that I was a member of the IETF's
> IPng Directorate and thus inherently complicit in that particular fiasco –
>
>
> John,
>
> Flags days on the internet of today have proven to be of limited value.
>
>
> Joe -
>
> I am not suggesting a flag day for 240/4 (or any other particular
> approach) - merely noting that anyone who wishes to promote 240/4 has a
> wide range of options to consider when they decide to get serious and
> actually consider interoperability approaches.
>
> The part I feel bad about is that I am actually un-involved in much of
> anyway with the 240/4 or other ideas, my sole input has been to attempt to
> encourage serious consideration and to rebut  naysaying.
>
>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>
> Yes, a standards update is only the beginning of a real effort, although
> plenty has changed even without that.
>
> Yes, there may and likely will be a large extent of interoperability and
> usability challenges for quite some time, perhaps even enough time that the
> issue becomes moot.
>
> Yes, it may be insurmountable.
>
> Yes, it may render 240/4 unusable and undesirable to the extent that it
> has little contributory effect on IPv4.
>
> However it may not and discouraging serious consideration is actually a
> contributing factor preventing any such potential.
>
>
> I certainly am not discouraging serious consideration… simply awaiting
> something sufficient complete to discuss.
>
> (Saying that “this proposal likely will create interoperability and
> usability challenges – but let’s all talk about the merits of it while
> ignoring that detail for now” doesn’t cut it – I’ve seen that approach once
> before and hasn’t turned out particularly well for anyone involved…)
>
> Best wishes,
> /John
>
> p.s. Disclaimer(s) - my views alone - please remember to have your arms
> and legs fully inside before the ride starts...
>
>
>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 1:19 PM, Joe Maimon  wrote:
> 
> John Curran wrote:
>> 
>> By the way, you shouldn’t feel particularly bad about skipping out on the 
>> interoperability requirement – anything involving interworking with the 
>> installed Internet is hard, and this is the same lesson that the IPv6 folks 
>> found out the hard way…   I will confess that I was a member of the IETF's 
>> IPng Directorate and thus inherently complicit in that particular fiasco –
> 
> John,
> 
> Flags days on the internet of today have proven to be of limited value.

Joe - 

I am not suggesting a flag day for 240/4 (or any other particular approach) - 
merely noting that anyone who wishes to promote 240/4 has a wide range of 
options to consider when they decide to get serious and actually consider 
interoperability approaches. 

> The part I feel bad about is that I am actually un-involved in much of anyway 
> with the 240/4 or other ideas, my sole input has been to attempt to encourage 
> serious consideration and to rebut  naysaying.

Serious consideration requires a serious proposal - I don’t think we’ve seen 
one yet.

> Yes, a standards update is only the beginning of a real effort, although 
> plenty has changed even without that.
> 
> Yes, there may and likely will be a large extent of interoperability and 
> usability challenges for quite some time, perhaps even enough time that the 
> issue becomes moot.
> 
> Yes, it may be insurmountable.
> 
> Yes, it may render 240/4 unusable and undesirable to the extent that it has 
> little contributory effect on IPv4.
> 
> However it may not and discouraging serious consideration is actually a 
> contributing factor preventing any such potential.

I certainly am not discouraging serious consideration… simply awaiting 
something sufficient complete to discuss. 

(Saying that “this proposal likely will create interoperability and usability 
challenges – but let’s all talk about the merits of it while ignoring that 
detail for now” doesn’t cut it – I’ve seen that approach once before and hasn’t 
turned out particularly well for anyone involved…) 

Best wishes,
/John

p.s. Disclaimer(s) - my views alone - please remember to have your arms and 
legs fully inside before the ride starts...

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

That's a hard no!--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 22, 2022, at 08:47, AQ Glass  wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Joe Maimon]

John Curran wrote:



On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
...
Interoperability isn’t insurmountable, but does take some investment 
of effort.  One can imagine any number of techniques (e.g.  flag day 
after which “production devices” on the Internet must support 240/4, 
or DNS resolver hacks that fail to return “A” records with 240/4 
addresses unless a flag is set that says “we’re in the 240/4 routable 
Internet” [ick], etc., etc.)  It doesn’t seem particularly hard to 
come up with some approaches to solve the interoperability problem, 
but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously…)


Joe -

By the way, you shouldn’t feel particularly bad about skipping out on 
the interoperability requirement – anything involving interworking 
with the installed Internet is hard, and this is the same lesson that 
the IPv6 folks found out the hard way…   I will confess that I was a 
member of the IETF's IPng Directorate and thus inherently complicit in 
that particular fiasco –


John,

Flags days on the internet of today have proven to be of limited value.

Suppose complete interoperability is never actually solved. Why does 
240/4 utilitarian value have to be binary? I think we should be trying 
to discover these things instead of using them to handwave away any attempt.


The part I feel bad about is that I am actually un-involved in much of 
anyway with the 240/4 or other ideas, my sole input has been to attempt 
to encourage serious consideration and to rebut  naysaying.


Yes, a standards update is only the beginning of a real effort, although 
plenty has changed even without that.


Yes, there may and likely will be a large extent of interoperability and 
usability challenges for quite some time, perhaps even enough time that 
the issue becomes moot.


Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it 
has little contributory effect on IPv4.


However it may not and discouraging serious consideration is actually a 
contributing factor preventing any such potential.


And to the extent that you and others have discussed and aired various 
points of views and insights, I think I have had some success with my 
efforts thus far.





With IPv6, the first answer to interoperability was “let’s do tunnels 
between IPng islands”; i.e. helpful for lab environments but useless 
otherwise.  We then declared that transition was a problem “to be 
solved later” but that shouldn’t get in the way of the declaration of 
IPng as the new IPv6.  Finally, after failing to solve the problem, we 
reverted to “ships in the night”; i.e. IPv4 and IPv6 running in 
parallel on the same infrastructure – it works, but defeats the entire 
idea of IPv6 as a functional substitute for IPv4 for connecting new 
customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly 
realized that they really needed IPv6, and they really needed 
transition solutions that allowed IPv6 to interoperate for IPv4 for 
new connections, and so we eventually saw real solutions such 
as 464xlat, ds-lite, etc.)


I feel there is some value for the internet record to contain as much as 
possible real debate and consideration instead of group think, 
short-sightedness, idealouges and top down approaches which may not look 
pretty in hindsight. Such as contained in the much larger details of 
your brief recap and that you and others have expanded upon here and 
elsewhere in the past.


In other words, a loyal opposition.



Maintaining interoperability with the existing base is hard - far 
harder than just “updating the standard” -
Without a standard update, there is a bit of a chicken and egg problem 
with pursuing interoperability with any seriousness.


I think 100.64/10 was a missed opportunity to incentivize the industry 
to pursue interoperability.


but is absolutely essential if you want viable reuse of 240/4.  Of 
course, it does raise the question of whether the total effort will be 
worth the purported gain, but that really can’t be assessed until 
there's some specification of the proposed solution for 
interoperability with the existing deployed devices that don’t know 
about the 240/4 change.


Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, 
headaches, or nausea.



Best,

Joe

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
> ...
> Interoperability isn’t insurmountable, but does take some investment of 
> effort.  One can imagine any number of techniques (e.g.  flag day after which 
> “production devices” on the Internet must support 240/4, or DNS resolver 
> hacks that fail to return “A” records with 240/4 addresses unless a flag is 
> set that says “we’re in the 240/4 routable Internet” [ick], etc., etc.)  It 
> doesn’t seem particularly hard to come up with some approaches to solve the 
> interoperability problem, but completely ignoring it is not an answer (and 
> makes it rather difficult to take your proposal seriously…) 

Joe - 

By the way, you shouldn’t feel particularly bad about skipping out on the 
interoperability requirement – anything involving interworking with the 
installed Internet is hard, and this is the same lesson that the IPv6 folks 
found out the hard way…   I will confess that I was a member of the IETF's IPng 
Directorate and thus inherently complicit in that particular fiasco –   

With IPv6, the first answer to interoperability was “let’s do tunnels between 
IPng islands”; i.e. helpful for lab environments but useless otherwise.  We 
then declared that transition was a problem “to be solved later” but that 
shouldn’t get in the way of the declaration of IPng as the new IPv6.  Finally, 
after failing to solve the problem, we reverted to “ships in the night”; i.e. 
IPv4 and IPv6 running in parallel on the same infrastructure – it works, but 
defeats the entire idea of IPv6 as a functional substitute for IPv4 for 
connecting new customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly realized 
that they really needed IPv6, and they really needed transition solutions that 
allowed IPv6 to interoperate for IPv4 for new connections, and so we eventually 
saw real solutions such as 464xlat, ds-lite, etc.) 

Maintaining interoperability with the existing base is hard - far harder than 
just “updating the standard” - but is absolutely essential if you want viable 
reuse of 240/4.  Of course, it does raise the question of whether the total 
effort will be worth the purported gain, but that really can’t be assessed 
until there's some specification of the proposed solution for interoperability 
with the existing deployed devices that don’t know about the 240/4 change. 

Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, headaches, 
or nausea.

RE: BCP38 For BGP Customers

[Adam Thompson]

We’ve seen Juniper EX9ks implement uRPF in such a way that if I have two 
(load-balanced) BGP connections to the EX9k, and uRPF is turned on facing me, I 
immediately experience ~50% outbound packet loss.
Methinks the EX9ks apply uRPF a little too close to the hardware and ignore the 
RIB.
-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
[cid:image002.png@01D8FE60.27B812C0]Chat with me on 
Teams

From: NANOG  On Behalf Of Mike 
Hammett
Sent: November 8, 2022 2:29 PM
To: William Herrin 
Cc: nanog@nanog.org; Grant Taylor 
Subject: Re: BCP38 For BGP Customers

"Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address."

FIB or RIB?

I knew of uRPF as available over an interface, per the routing table, not best 
path available. Or is that implementation dependent?



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "William Herrin" mailto:b...@herrin.us>>
To: "Grant Taylor" 
mailto:gtay...@tnetconsulting.net>>
Cc: nanog@nanog.org
Sent: Tuesday, November 8, 2022 2:01:49 PM
Subject: Re: BCP38 For BGP Customers

On Tue, Nov 8, 2022 at 8:40 AM Grant Taylor via NANOG 
mailto:nanog@nanog.org>> wrote:
> Maybe it's the lack of caffeine, but would someone please remind /
> enlighten me as to why uRPF is a bad idea on downstream interfaces?

Hi Grant,

Two words: asymmetric routing.

If the downstream network is architected in such a way that there's
more than one path in and out of their network then there's no way to
guarantee that any particular router believes the forward path to that
network goes to a particular next hop. It can currently map to any
next hop that goes in the direction of one of the valid paths. That
routing is completely independent of how next hops are selected in the
other direction. Packets can travel in one path and out another.

Reverse path filtering literally says don't accept a packet from
somewhere that isn't currently the next hop for that packet's source
address. When it's possible for the forward route to point a different
direction than the one from which valid packets are received, that is
the wrong thing to do. In fact, it breaks the network.

Useful automated reverse path filtering can ONLY be used when there is
exactly ONE valid path to which and from which packets can be
received. This is where strict mode uRPF actually works.


> N.B. Maybe I'm thinking more a varient of uRPF wherein if I have a route
> to the source from the interface in question.  Thus not uRPF-strict
> (active route) nor uRPF-loose (route on any interface).

Even if a particular router happens to have RIB entries for all the
valid paths to a host (a sketchy proposition at best), only one such
entry will be stored in the FIB where uRPF looks to make its filtering
decision.

As for loose mode, it's basically useless in a BCP38 discussion. Loose
mode only filters bogons. It doesn't prevent impersonation of any IP
address currently routed in the system and doesn't do anything at all
on a router with a default route.

Regards,
Bill Herrin




--
For hire. https://bill.herrin.us/resume/

SPF (and other email security protocols) Survey

[Taejoong (tijay) Chung]

Greetings,

The Sender Policy Framework (SPF) is an easy way to check whether the
sender is authorized to send emails – however, it may cause some security
holes if it causes too many DNS lookups.

Together with researchers from Virginia Tech and Max-Planck-Institut für
Informatik, we would like to understand which challenges operators face
when configuring the proper limit of DNS queries for SPF lookups and when
deploying other email security protocols.

Filling out the survey should take between 5 and 10 minutes; we would
highly appreciate your participation.

 https://www.surveymonkey.com/r/D9M3ZHV

Please note that we do NOT collect any personal information, thus the
Institutional Review Board (IRB) at Virginia Tech determined the survey as
Non-Human Subjects Research. We will aggregate and anonymize all responses
during evaluation and share the results after evaluation.

Please do not hesitate to drop me a mail if you have questions or comments.
Also, please excuse us if you have received this email from different
mailing lists.


Thank you.


Taejoong "Tijay" Chung, Assistant Professor
Virginia Tech  |  Computer Science
Knowledge Works II, RM 2228
2202 Kraft Drive, Blacksburg, VA 24060
(540) 231-0667| ti...@vt.edu

ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[AQ Glass]

anybody interested in this project?

@oracle can own the .ticket tld; NS * ticket. -> virtualhost

96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with
gov.xxx.ticket signup and further instructions

//
https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19

codedevs can commit to
https://github.com/element9v/takebackdarpa

thx
-e

On Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:

>
> https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19
>
> #routetonull discuss
>
> #takebackdarpa
>
> -e
>

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[John Curran]

> On Nov 22, 2022, at 2:09 AM, Joe Maimon  wrote:
> 
> David Conrad wrote:
>> 
>> Again, the issue isn’t fixing a bit of code in a known source tree. It is 
>> getting all the instantiations of that bit of code implemented, tested, and 
>> deployed across all the myriad supported and unsupported systems (both 
>> operational and management) that support 5 billion+ Internet users globally 
>> in a timeframe and for a cost that makes business sense.
> 
> Lets agree to stop conflating the issue of products under active support and 
> refresh cycles with the issue of those that are obsolete and only subject to 
> attrition.

Joe - 

  Ah, if it were only that simple…   service providers have a _huge_ 
amount of installed infrastructure, and it’s in various phases of support (i.e. 
can get new updates, or critical fixes only, or is self-maintained, etc.) 

Vendors supporting 240/4 as general purpose space does not automatically equate 
to Internet infrastructure supporting 240/2, as it requires service providers 
to make conscious decisions to do maintenance on gear that may (in many cases) 
have been effectively frozen in terms of software updates that aren’t critical… 
customer installs and capacity upgrades almost always get first cut at 
resources, and so no, it is not just a case of updating the standards - even 
presuming that the provider has the equipment under software updates, 
availability of such doesn’t mean it will be installed.   You are talking about 
a long period between standards update and actual deployment, and that’s 
presuming actively supported gear. 

> The former, yes it is trivial. An update in standards could yield rapid 
> results here.

Absolutely – but only if you are talking about an equally trivial network 
infrastructure or pure lab environment – otherwise, the standards change is the 
very _beginning_ of a lengthy process for network operators of any size. 

You once again have avoided the question of interoperability during the 
transition period.

Interoperability isn’t insurmountable, but does take some investment of effort. 
 One can imagine any number of techniques (e.g.  flag day after which 
“production devices” on the Internet must support 240/4, or DNS resolver hacks 
that fail to return “A” records with 240/4 addresses unless a flag is set that 
says “we’re in the 240/4 routable Internet” [ick], etc., etc.)  It doesn’t seem 
particularly hard to come up with some approaches to solve the interoperability 
problem, but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously...) 

Thanks,
/John

p.s.  disclaimer: my views alone (little chance any one else would risk blame 
for them!)