Re: Starting to Drop Invalids for Customers

[Mark Tinka]

On 10/Dec/19 19:20, Randy Bush wrote:

>
> cool.  any stats and lessons appreciated.

Will do, Randy.

Mark.

Re: Starting to Drop Invalids for Customers

[Mark Tinka]

On 10/Dec/19 21:47, Arturo Servin wrote:

> Mark
>
> Invalid according to RPKI or IRR? Or both?

According to RPKI.

Mark.

Re: Short-circuited traceroutes on FIOS

[Nimrod Levy]

I'm in the same region as Chris and I still can't make it fail. I wonder if
it's because I have static addressing?

On Tue, Dec 10, 2019 at 11:59 PM Christopher Morrow 
wrote:

> On Tue, Dec 10, 2019 at 11:44 PM Lee  wrote:
> > It's protocol specific.  Windows tracert uses icmp instead of udp.
> > On a linux box try
> >   ping -t 2 205.132.109.90
> >
> > You should get a time to live exceeded but the Verizon router gives
> > you an echo reply instead.
>
> that's hilariously bad :( I think this is the OLT really that's doing
> this...
> $ ping -t 3 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> From 130.81.32.236 icmp_seq=1 Time to live exceeded
>
> $ ping -t 1 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> From 192.168.100.1 icmp_seq=1 Time to live exceeded
>
> $ ping -t 2 205.132.109.90
> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
> 64 bytes from 205.132.109.90: icmp_seq=1 ttl=254 time=3.38 ms
>
> An outbound traceroute has:
>  1  _gateway (192.168.100.1)  2.537 ms  2.587 ms  2.703 ms
>  2  * * *
>  3  B3320.WASHDC-LCR-21.verizon-gni.net (130.81.32.236)  6.638 ms
> B3320.WASHDC-LCR-22.verizon-gni.net (130.81.32.238)  6.223 ms  6.414
> ms
> ...
>
> and inbound that hop 2 is:
>  6  HundredGigE2-4-0-3.WASHDC-LCR-22.verizon-gni.NET (140.222.238.55)
> 5.504 ms HundredGigE2-6-0-3.WASHDC-LCR-21.verizon-gni.NET
> (140.222.234.53)  9.261 ms  9.266 ms
>  7  ae203-0.WASHDC-VFTTP-320.verizon-gni.net ()  7.955 ms  3.026 ms
> ae204-0.WASHDC-VFTTP-320.verizon-gni.net (130.81.32.239)  2.347 ms
>
> oh well, just wonky gpon again?
>

Re: Starting to Drop Invalids for Customers

[Nick Hilliard]

Christopher Morrow wrote on 11/12/2019 03:45:

On Tue, Dec 10, 2019 at 7:32 PM Rubens Kuhl  wrote:

Which brings me to my favorite possible RPKI-IRR integration: a ROA
that says that IRR objects on IRR source x with maintainer Y are
authoritative for a given number resource. Kinda like SPF for BGP.


Is this required? or a crutch for use until a network can publish
all of their routing data in the RPKI?


it sounds like a great idea which is a terrible idea.  Each operator 
will make their own choice about what RPKI TALs to accept.  Once they're 
loaded up on the rpki caches, do you really want to push more complexity 
down to the router control plane with and start making per-device 
choices about how to handle the trust level of each individual ROA?  The 
internet dfz is already being killed with complexity.  Configuring 
per-prefix trust levels at a per-device level is nuts - and wholly 
non-scalable.


If you don't want to see ROAs from a specific source, then don't import 
their TAL.


Nick

Re: Starting to Drop Invalids for Customers

[Rubens Kuhl]

>
> > Which brings me to my favorite possible RPKI-IRR integration: a ROA that
> says that IRR objects on IRR source x with maintainer Y are authoritative
> for a given number resource. Kinda like SPF for BGP.
> >
>
> Is this required? or a crutch for use until a network can publish all
> of their routing data in the RPKI?
>
>
It provides an adoption path based on the information already published in
IRRs by operators for some years. It also covers for the fact that RPKI
currently is only origin-validation.


Rubens

Re: Short-circuited traceroutes on FIOS

[Etienne-Victor Depasquale]

Traceroute is becoming more and more an expert's tool because
interpretation of its results isn't straightforward.

I had written a paper last year and mentioned its misuse in academia in the
context of estimating the number of energy-consuming devices between a
source and a destination.
Traceroute was being used to count the number of physical router devices
from the hop count, notwithstanding the use of MPLS in domain cores.
To an external observer, this results in significant underestimation of the
energy consumption in the path from source to destination.

On Thu, Dec 12, 2019 at 12:51 AM Valdis Klētnieks 
wrote:

> On Wed, 11 Dec 2019 19:26:09 +0200, Saku Ytti said:
> > On Wed, 11 Dec 2019 at 19:14, Rob Foehl  wrote:
> >
> > > Support claims that it was a mistake, but it's also been 15+ months and
> > > it's pretty deliberate behavior.  Draw your own conclusions...
> >
> > TTL decrement issues are fairly common across multiple vendors and hw,
> > can be sw can be hw limit
>
> Yes, but you need to screw up gloriously on the decrement if you think that
> "I decremented and it's zero now" means "therefor it must have been
> addressed
> to me, so I'll send an ECHO REPLY instead of TTL EXCEEDED".
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Starting to Drop Invalids for Customers

[Christopher Morrow]

On Wed, Dec 11, 2019 at 11:35 AM Matt Corallo  wrote:
>
> Right, but you’re also taking a strong, cryptographically-authenticated 
> system and making it sign non-authenticated data. Please don’t do that. If 
> you want to add the data to RPKI, there should be a way to add the data to 
> RPKI, not sign away control of your number resources to unauthenticated 
> sources.
>

I don't think that's what I was saying, at all, actually.

I was saying:
  "I assume you must have some system to create IRR data, that system
knows: '1.0.1.0/24 ASFOO MAINT-FOOBAR'  is ok."

that system could now add '1.0.1.0/24 ASFOO' to the RPKI.

Where does that say: "make it sign unauthenticated data" ?

> > On Dec 11, 2019, at 10:17, Christopher Morrow  
> > wrote:
> >
> > On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:
> >>
> >>
> >>>
>  Which brings me to my favorite possible RPKI-IRR integration: a ROA that 
>  says that IRR objects on IRR source x with maintainer Y are 
>  authoritative for a given number resource. Kinda like SPF for BGP.
> 
> >>>
> >>> Is this required? or a crutch for use until a network can publish all
> >>> of their routing data in the RPKI?
> >>>
> >>
> >> It provides an adoption path based on the information already published in 
> >> IRRs by operators for some years. It also covers for the fact that RPKI 
> >> currently is only origin-validation.
> >
> > I would think that if you(royal you) already are publishing:
> >  "these are the routes i'm going to originate (and here are my customer 
> > lists)"
> >
> > and you (royal you) are accepting the effort to publish 1 'new' thing
> > in the RPKI.
> >
> > you could just as easily take the 'stuff I'm going to publish in IRR'
> > and 'also publish in RPKI'.
> > Right? So adoption path aside, because that seems like a weird
> > argument (since your automation to make IRR data appear can ALSO just
> > send rpki updates), your belief is that: "Hey, this irr object is
> > really, really me" is still useful/required/necessary/interesting?
> >
> > -chris
>

Downtown Boston Dark Fiber Pricing

[Rod Beck]

Hi,

I have questions regarding IRU pricing in this market. Please contact off list.

Thanks gang.

Regards,

Roderick.


Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

36-70-605-5144


[1467221477350_image005.png]

Re: Short-circuited traceroutes on FIOS

[Rob Foehl]

On Tue, 10 Dec 2019, Joe Maimon wrote:

Anyone have an idea why there are some destinations that on residential 
verizon fios here in NY area terminate right on first external hop?


They're returning fake ICMP echo replies from their BNGs for echo packets 
with TTL=1, thus any ICMP traceroute (Windows and mtr by default, etc.) 
seems to terminate at their layer 3 edge.  UDP/TCP traceroute are 
unaffected, ICMP works fine if you set the initial TTL to n+1 where n is 
the hop that's lying.


Support claims that it was a mistake, but it's also been 15+ months and 
it's pretty deliberate behavior.  Draw your own conclusions...


-Rob

Re: Short-circuited traceroutes on FIOS

[Mike Hammett]

How have we gone this long of a conversation without someone from FIOS stepping 
in and setting the record straight? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Joe Maimon"  
To: "North American Networking and Offtopic Gripes List"  
Sent: Tuesday, December 10, 2019 1:47:17 PM 
Subject: Short-circuited traceroutes on FIOS 

Anyone have an idea why there are some destinations that on residential 
verizon fios here in NY area terminate right on first external hop? 

There seems to be a CDN common denominator here. On other networks with 
more typical BGP paths and traceroutes, users are reporting issues 
accessing these sites. 

C:\Users\Home>tracert www.usfoods.com 

Tracing route to statics.usfoods.com [205.132.109.90] 
over a maximum of 30 hops: 

1 3 ms <1 ms <1 ms 172.18.24.1 
2 4 ms 3 ms 3 ms 192.168.2.33 
3 17 ms 6 ms 3 ms statics.usfoods.com [205.132.109.90] 

Trace complete. 

C:\Users\Home>tracert atworkhp.americanexpress.com 

Tracing route to atworkhp.americanexpress.com.akadns.net [139.71.19.87] 
over a maximum of 30 hops: 

1 2 ms <1 ms <1 ms 172.18.24.1 
2 3 ms 4 ms 23 ms 192.168.2.33 
3 21 ms 11 ms 5 ms atworkhomepage2.americanexpress.com 
[139.71.19.87] 

Trace complete. 

C:\Users\Home>tracert portal.discover.com 

Tracing route to e14577.x.akamaiedge.net [23.51.172.254] 
over a maximum of 30 hops: 

1 3 ms 1 ms 18 ms 172.18.24.1 
2 21 ms 7 ms 6 ms 192.168.2.33 
3 4 ms 2 ms 2 ms 
a23-51-172-254.deploy.static.akamaitechnologies.com [23.51.172.254] 

Trace complete. 

Re: Short-circuited traceroutes on FIOS

[Javier J]

If you have static addressing (biz account) then possibly different from
what I have.

In North NJ, 3 different accounts I can verify have ICMP blocked as of
sometime earlier this year or late last year so have to use udp to get a
real traceroute.

Could not be deployed in all areas the same way.

 - Javier

On Wed, Dec 11, 2019 at 7:19 AM Nimrod Levy  wrote:

> I'm in the same region as Chris and I still can't make it fail. I wonder
> if it's because I have static addressing?
>
> On Tue, Dec 10, 2019 at 11:59 PM Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>> On Tue, Dec 10, 2019 at 11:44 PM Lee  wrote:
>> > It's protocol specific.  Windows tracert uses icmp instead of udp.
>> > On a linux box try
>> >   ping -t 2 205.132.109.90
>> >
>> > You should get a time to live exceeded but the Verizon router gives
>> > you an echo reply instead.
>>
>> that's hilariously bad :( I think this is the OLT really that's doing
>> this...
>> $ ping -t 3 205.132.109.90
>> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
>> From 130.81.32.236 icmp_seq=1 Time to live exceeded
>>
>> $ ping -t 1 205.132.109.90
>> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
>> From 192.168.100.1 icmp_seq=1 Time to live exceeded
>>
>> $ ping -t 2 205.132.109.90
>> PING 205.132.109.90 (205.132.109.90) 56(84) bytes of data.
>> 64 bytes from 205.132.109.90: icmp_seq=1 ttl=254 time=3.38 ms
>>
>> An outbound traceroute has:
>>  1  _gateway (192.168.100.1)  2.537 ms  2.587 ms  2.703 ms
>>  2  * * *
>>  3  B3320.WASHDC-LCR-21.verizon-gni.net (130.81.32.236)  6.638 ms
>> B3320.WASHDC-LCR-22.verizon-gni.net (130.81.32.238)  6.223 ms  6.414
>> ms
>> ...
>>
>> and inbound that hop 2 is:
>>  6  HundredGigE2-4-0-3.WASHDC-LCR-22.verizon-gni.NET (140.222.238.55)
>> 5.504 ms HundredGigE2-6-0-3.WASHDC-LCR-21.verizon-gni.NET
>> (140.222.234.53)  9.261 ms  9.266 ms
>>  7  ae203-0.WASHDC-VFTTP-320.verizon-gni.net ()  7.955 ms  3.026 ms
>> ae204-0.WASHDC-VFTTP-320.verizon-gni.net (130.81.32.239)  2.347 ms
>>
>> oh well, just wonky gpon again?
>>
>

Re: Starting to Drop Invalids for Customers

[Christopher Morrow]

On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:
>
>
>>
>> > Which brings me to my favorite possible RPKI-IRR integration: a ROA that 
>> > says that IRR objects on IRR source x with maintainer Y are authoritative 
>> > for a given number resource. Kinda like SPF for BGP.
>> >
>>
>> Is this required? or a crutch for use until a network can publish all
>> of their routing data in the RPKI?
>>
>
> It provides an adoption path based on the information already published in 
> IRRs by operators for some years. It also covers for the fact that RPKI 
> currently is only origin-validation.

I would think that if you(royal you) already are publishing:
  "these are the routes i'm going to originate (and here are my customer lists)"

and you (royal you) are accepting the effort to publish 1 'new' thing
in the RPKI.

you could just as easily take the 'stuff I'm going to publish in IRR'
and 'also publish in RPKI'.
Right? So adoption path aside, because that seems like a weird
argument (since your automation to make IRR data appear can ALSO just
send rpki updates), your belief is that: "Hey, this irr object is
really, really me" is still useful/required/necessary/interesting?

-chris

Re: Starting to Drop Invalids for Customers

[Rubens Kuhl]

On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow 
wrote:

> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:
> >
> >
> >>
> >> > Which brings me to my favorite possible RPKI-IRR integration: a ROA
> that says that IRR objects on IRR source x with maintainer Y are
> authoritative for a given number resource. Kinda like SPF for BGP.
> >> >
> >>
> >> Is this required? or a crutch for use until a network can publish all
> >> of their routing data in the RPKI?
> >>
> >
> > It provides an adoption path based on the information already published
> in IRRs by operators for some years. It also covers for the fact that RPKI
> currently is only origin-validation.
>
> I would think that if you(royal you) already are publishing:
>   "these are the routes i'm going to originate (and here are my customer
> lists)"
>
> and you (royal you) are accepting the effort to publish 1 'new' thing
> in the RPKI.
>
> you could just as easily take the 'stuff I'm going to publish in IRR'
> and 'also publish in RPKI'.
> Right? So adoption path aside, because that seems like a weird
> argument (since your automation to make IRR data appear can ALSO just
> send rpki updates), your belief is that: "Hey, this irr object is
> really, really me" is still useful/required/necessary/interesting?
>
>
The history of development of BGP path-validation standards does not give
much hope so far... people never seen to be able to agree on how to do it.
OTOH, people seem comfortable publishing those relations in IRR... and some
using that for prefix-filter building, including AS 15169 that presented
yesterday on an IX conference and said preferring using IRR over RPKI to
automate prefix filtering.

Frankly, I'll take any form of authenticated path-validation that gets
traction in the DFZ, whether it's pretty or not. Pure RPKI for both origin
and path validation looks much better to me, but will it fly ?


Rubens

Re: Short-circuited traceroutes on FIOS

[Stephen Frost]

Greetings,

* Mike Hammett (na...@ics-il.net) wrote:
> How have we gone this long of a conversation without someone from FIOS 
> stepping in and setting the record straight? 

How have we gone this long without ipv6 on FIOS ...?

(though I've heard that it may have shown up in some places, I'm
certainly still not seeing it...)

Thanks,

Stephen


signature.asc
Description: PGP signature

Re: Starting to Drop Invalids for Customers

[Matt Corallo]

Right, but you’re also taking a strong, cryptographically-authenticated system 
and making it sign non-authenticated data. Please don’t do that. If you want to 
add the data to RPKI, there should be a way to add the data to RPKI, not sign 
away control of your number resources to unauthenticated sources.

> On Dec 11, 2019, at 10:17, Christopher Morrow  wrote:
> 
> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:
>> 
>> 
>>> 
 Which brings me to my favorite possible RPKI-IRR integration: a ROA that 
 says that IRR objects on IRR source x with maintainer Y are authoritative 
 for a given number resource. Kinda like SPF for BGP.
 
>>> 
>>> Is this required? or a crutch for use until a network can publish all
>>> of their routing data in the RPKI?
>>> 
>> 
>> It provides an adoption path based on the information already published in 
>> IRRs by operators for some years. It also covers for the fact that RPKI 
>> currently is only origin-validation.
> 
> I would think that if you(royal you) already are publishing:
>  "these are the routes i'm going to originate (and here are my customer 
> lists)"
> 
> and you (royal you) are accepting the effort to publish 1 'new' thing
> in the RPKI.
> 
> you could just as easily take the 'stuff I'm going to publish in IRR'
> and 'also publish in RPKI'.
> Right? So adoption path aside, because that seems like a weird
> argument (since your automation to make IRR data appear can ALSO just
> send rpki updates), your belief is that: "Hey, this irr object is
> really, really me" is still useful/required/necessary/interesting?
> 
> -chris

Re: Starting to Drop Invalids for Customers

[Christopher Morrow]

On Wed, Dec 11, 2019 at 11:52 AM Rubens Kuhl  wrote:
>
>
>
> On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow  
> wrote:
>>
>> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:
>> >
>> >
>> >>
>> >> > Which brings me to my favorite possible RPKI-IRR integration: a ROA 
>> >> > that says that IRR objects on IRR source x with maintainer Y are 
>> >> > authoritative for a given number resource. Kinda like SPF for BGP.
>> >> >
>> >>
>> >> Is this required? or a crutch for use until a network can publish all
>> >> of their routing data in the RPKI?
>> >>
>> >
>> > It provides an adoption path based on the information already published in 
>> > IRRs by operators for some years. It also covers for the fact that RPKI 
>> > currently is only origin-validation.
>>
>> I would think that if you(royal you) already are publishing:
>>   "these are the routes i'm going to originate (and here are my customer 
>> lists)"
>>
>> and you (royal you) are accepting the effort to publish 1 'new' thing
>> in the RPKI.
>>
>> you could just as easily take the 'stuff I'm going to publish in IRR'
>> and 'also publish in RPKI'.
>> Right? So adoption path aside, because that seems like a weird
>> argument (since your automation to make IRR data appear can ALSO just
>> send rpki updates), your belief is that: "Hey, this irr object is
>> really, really me" is still useful/required/necessary/interesting?
>>
>
> The history of development of BGP path-validation standards does not give 
> much hope so far... people never seen to be able to agree on how to do it.

I think path-validation is .. BGPSec - rfc8206
right? so clearly some folks agreed on the process/path/etc for
validating paths in bgp.
Will that get deployed? unclear to me... To get it deployed though
we'd need to start at the beginning of the story and get RPKI data
published.

> OTOH, people seem comfortable publishing those relations in IRR... and some 
> using that for prefix-filter building, including AS 15169 that presented 
> yesterday on an IX conference and said preferring using IRR over RPKI to 
> automate prefix filtering.

oh, someone presented yesterday, cool...  err... I think their
presentation says (or should have said?) something like:
  "today we plan to use IRR data, we'll be adding RPKI data as it's
available and we're comfy with the integration efforts..."
   (that's what this preso said anyway:
 
https://docs.google.com/presentation/d/1-SIa98o-QrMALW3maAvu_W_PHTJRAr0Nv-kO1-gNcs8/edit?usp=sharing
  when i presented it 2x)

 I think that's still the project plan...

>
> Frankly, I'll take any form of authenticated path-validation that gets 
> traction in the DFZ, whether it's pretty or not. Pure RPKI for both origin 
> and path validation looks much better to me, but will it fly ?
>



I think the RPKI adoption and usage in the DFZ and near-to-dfz is
picking up (says the graphs, etc).
I'd love to see it more picked up, but folk don't REALLY have a need
for it 'yet', once more large players start publishing and requiring
though :)
the goal of the slide deck above, and job's efforts and mark's efforts
and jay/nimrod's efforts (and cloudflare/mahtin/jerome/etc .. plus
a host of others) is to make it apparent: "Hey, get your data
straight, publish in RPKI, start validating!"

-chris

>
> Rubens
>
>
>
>

Re: Short-circuited traceroutes on FIOS

[Saku Ytti]

On Wed, 11 Dec 2019 at 19:14, Rob Foehl  wrote:

> Support claims that it was a mistake, but it's also been 15+ months and
> it's pretty deliberate behavior.  Draw your own conclusions...

TTL decrement issues are fairly common across multiple vendors and hw,
can be sw can be hw limit. Common issues for example is if MPLS egress
PE receives explicit null labeled packet, it may not be able to
decrement TTL.
I may lack in imagination, but I struggle to envision a situation
where people decided to do this and then decided to be sneaky peaky
about it.


-- 
  ++ytti

Re: Starting to Drop Invalids for Customers

[Matt Corallo]

Ah, right. Fair. I was responding, I suppose, to Rubens' original
description, which was exactly this.

On 12/11/19 5:08 PM, Christopher Morrow wrote:
> On Wed, Dec 11, 2019 at 11:35 AM Matt Corallo  wrote:
>>
>> Right, but you’re also taking a strong, cryptographically-authenticated 
>> system and making it sign non-authenticated data. Please don’t do that. If 
>> you want to add the data to RPKI, there should be a way to add the data to 
>> RPKI, not sign away control of your number resources to unauthenticated 
>> sources.
>>
> 
> I don't think that's what I was saying, at all, actually.
> 
> I was saying:
>   "I assume you must have some system to create IRR data, that system
> knows: '1.0.1.0/24 ASFOO MAINT-FOOBAR'  is ok."
> 
> that system could now add '1.0.1.0/24 ASFOO' to the RPKI.
> 
> Where does that say: "make it sign unauthenticated data" ?
> 
>>> On Dec 11, 2019, at 10:17, Christopher Morrow  
>>> wrote:
>>>
>>> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl  wrote:


>
>> Which brings me to my favorite possible RPKI-IRR integration: a ROA that 
>> says that IRR objects on IRR source x with maintainer Y are 
>> authoritative for a given number resource. Kinda like SPF for BGP.
>>
>
> Is this required? or a crutch for use until a network can publish all
> of their routing data in the RPKI?
>

 It provides an adoption path based on the information already published in 
 IRRs by operators for some years. It also covers for the fact that RPKI 
 currently is only origin-validation.
>>>
>>> I would think that if you(royal you) already are publishing:
>>>  "these are the routes i'm going to originate (and here are my customer 
>>> lists)"
>>>
>>> and you (royal you) are accepting the effort to publish 1 'new' thing
>>> in the RPKI.
>>>
>>> you could just as easily take the 'stuff I'm going to publish in IRR'
>>> and 'also publish in RPKI'.
>>> Right? So adoption path aside, because that seems like a weird
>>> argument (since your automation to make IRR data appear can ALSO just
>>> send rpki updates), your belief is that: "Hey, this irr object is
>>> really, really me" is still useful/required/necessary/interesting?
>>>
>>> -chris
>>

Re: Short-circuited traceroutes on FIOS

[Valdis Klētnieks]

On Wed, 11 Dec 2019 19:26:09 +0200, Saku Ytti said:
> On Wed, 11 Dec 2019 at 19:14, Rob Foehl  wrote:
>
> > Support claims that it was a mistake, but it's also been 15+ months and
> > it's pretty deliberate behavior.  Draw your own conclusions...
>
> TTL decrement issues are fairly common across multiple vendors and hw,
> can be sw can be hw limit

Yes, but you need to screw up gloriously on the decrement if you think that
"I decremented and it's zero now" means "therefor it must have been addressed
to me, so I'll send an ECHO REPLY instead of TTL EXCEEDED".


pgpmaeuPEyxyP.pgp
Description: PGP signature