Re: maximum ipv4 bgp prefix length of /24 ?

[Willy Manga]

.

On 11/10/2023 03:52, Delong.com wrote:

[...]

RPKI only asserts that a specific ASN must originate a prefix.  It does nothing 
to validate the authenticity of the origination.


Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix 
length”.

E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum 
Length” attribute of /36, then any advertisement (even originated by 65500) 
that is longer than /36 should be considered invalid.


If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs 
protecting it, and AS YY has allowed more specifics to be announced within the 
prefix range covered by the ROA, I'm in like flynn, because I just need to 
configure my router with AS YY as the origin AS, then insert the expected ASN 
for the neighbor adjacency with my upstreams, and bob's your uncle, the more 
specific prefix passes RPKI validation, and traffic comes flying my way.


Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes 
and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, 
then YY has indeed aimed a firearm squarely at their lower distal appendage and 
fired.

However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as 
well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY 
would generate ROAs for
2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36


As Dale suggested in another email[1], it's better to just cover ROAs 
for what you are advertising. Why?


1. I can't confirm at this stage that all the implementation allows you 
to leave the maxLength field empty.


2. If you want to follow that logic, what you are trying to accomplish 
with AS0 is basically the *complement* of what you are not advertising. 
I believe that will be much more work and you might miss a lot of 
specifics. e.g : under your 2001:db8::/32 , do not forget you have 
16x/36, 2x/33,4x/34,... You will have to insert statement for every 
single of them.


1. https://mailman.nanog.org/pipermail/nanog/2023-October/223676.html

--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 11, 2023, at 18:53, Willy Manga  wrote:
> 
> 
> .
> On 11/10/2023 22:29, Delong.com wrote:
>> [...]
>>> Yes, but in that scenario any advertisements between /32 and /36 from that 
>>> prefix originated by AS65500 are *valid* . That's why "ROAs should be as 
>>> precise as possible, meaning they should match prefixes as announced in 
>>> BGP" [1]
>> You completely ignored my statement of the need for appropriate AS-0 ROAs to 
>> block those.
> 
> I did not want to comment because you can go down that path *and* you will 
> assume everyone doing ROV will consider AS0 ROAs as well.

Well, true, but AIUI, if you’re processing ROAs, one with AS0 must be 
considered as making every matching prefix “Invalid”. In fact, even if one 
doesn’t treat AS0 as a special case in an RPKI validator, AS0 isn’t going to 
match the origin AS for any route you see, or your router and all of the 
routers between you and the origin router are truly broken.

> IMHO the bare minimum is to cover your advertisements with a ROA as precise 
> as possible.

Agree, but in the case where you have to advertise some more specifics, as in 
the example I provided, then if I understand things correctly, you can’t be 
that precise and that’s why I provided the AS0 based solution for the invalid 
more specifics.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Willy Manga]

.
On 11/10/2023 22:29, Delong.com wrote:

[...]

Yes, but in that scenario any advertisements between /32 and /36 from that prefix 
originated by AS65500 are *valid* . That's why "ROAs should be as precise as 
possible, meaning they should match prefixes as announced in BGP" [1]


You completely ignored my statement of the need for appropriate AS-0 ROAs to 
block those.


I did not want to comment because you can go down that path *and* you 
will assume everyone doing ROV will consider AS0 ROAs as well.


IMHO the bare minimum is to cover your advertisements with a ROA as 
precise as possible.


--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

[Peter Potvin via NANOG]

Definitely have received this same spam multiple times and so have a few
others I know. It's ridiculous that they resort to scraping public lists
and DBs to try and achieve what they're attempting to do.

Regards,
Peter Potvin | Executive Director
--
*Accuris Technologies Ltd.*



On Wed, Oct 11, 2023 at 7:52 PM Eric Kuhnke  wrote:

> Is anyone else receiving spam from this organization? Based on the
> contents of the cold solicitations they are sending us, and the addresses
> being sent to, they have scraped ARIN WHOIS data for noc and abuse POC
> contact info and recent ipv4 block transfers.
>
> It's trivially easy to block their entire domain at the mail server level,
> of course...
>
>
>

ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

[Eric Kuhnke]

Is anyone else receiving spam from this organization? Based on the contents
of the cold solicitations they are sending us, and the addresses being sent
to, they have scraped ARIN WHOIS data for noc and abuse POC contact info
and recent ipv4 block transfers.

It's trivially easy to block their entire domain at the mail server level,
of course...

Re: constraining RPKI Trust Anchors

[Randy Bush]

> So while each RP should be able to make policy decisions based on its
> own local criteria, managing a default set of constraints is something
> that is best done centralized. Who do you envision should manage these
> lists? RP software maintainers? RIRs? Others?

and how will this pain-to-maintain list be distributed?  how do i know
a copy is authentic not an attack?

i am all for a single root of trust.  it's just that i thought it was
the iana's job.  but i am easily confused.

randy

Re: xfinity not working

[Delong.com via NANOG]

XFINITY will send you bursts of other peoples data constantly.

That’s the nature of CMTS, it’s a broadcast network, acts like one giant 
ethernet.

Owen


> On Oct 11, 2023, at 15:00, William Herrin  wrote:
> 
> On Wed, Oct 11, 2023 at 12:32 PM Delong.com  wrote:
>> Nope… My Surfboard 8611 has that (just Cable<->single ethernet port).
> 
> Cool. The models I have only bridge.
> 
> 
>> The SRX-340 provides a backup simple network (SRX LAN ->NAT->$CABLECO) in 
>> case things go wrong with the (usually more reliable multi-homed) network. (
> 
> Yeah, that's why I've been messing with Xfinity this week. I've been
> stalling since I moved in last year, waiting to see how long
> Centurylink fiber would work flawlessly enough that I didn't need a
> second carrier. Last year I got a hold of some cable modems, made sure
> I could reach the Xfinity activation service, and then I set it aside.
> I figured that in a pinch I could do Internet off my phone long enough
> to plug everything back in and get Xfinity up and running.
> 
> After the glitch a couple weeks ago when Centurylink sent me bursts of
> other peoples' data for a day or so, I figured it was time to put a
> second provider back in my mix. Imagine my surprise this week when I
> went ahead and bought service, went back to the activation page, and
> it didn't work.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: xfinity not working

[William Herrin]

On Wed, Oct 11, 2023 at 12:32 PM Delong.com  wrote:
> Nope… My Surfboard 8611 has that (just Cable<->single ethernet port).

Cool. The models I have only bridge.


> The SRX-340 provides a backup simple network (SRX LAN ->NAT->$CABLECO) in 
> case things go wrong with the (usually more reliable multi-homed) network. (

Yeah, that's why I've been messing with Xfinity this week. I've been
stalling since I moved in last year, waiting to see how long
Centurylink fiber would work flawlessly enough that I didn't need a
second carrier. Last year I got a hold of some cable modems, made sure
I could reach the Xfinity activation service, and then I set it aside.
I figured that in a pinch I could do Internet off my phone long enough
to plug everything back in and get Xfinity up and running.

After the glitch a couple weeks ago when Centurylink sent me bursts of
other peoples' data for a day or so, I figured it was time to put a
second provider back in my mix. Imagine my surprise this week when I
went ahead and bought service, went back to the activation page, and
it didn't work.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

>> The point here is that at some point, even with translation, we run out of 
>> IPv4 addresses to use for this purpose. What then?
> 
> You deliver the Internet over IPv6.  A really large functional Internet 
> exists today if you only have IPv6.  It is only getting bigger.  Lots of (the 
> majority?) of CDNs deliver content over IPv6.  Lots of companies outsource 
> their SMTP to dual stacked service providers so that email still gets through.
> After 20 years there is no excuse for ISPs failing to deliver IPv6.  If you 
> have to you, outsource your NAT64, DS-Lite transition service to someone that 
> has IPv4.  I’m surprised that it isn’t common today.

And now we have come full circle to the attitude that leads to Matt’s initial 
point:

 As a community, we have failed, because we never acknowledged and 
 addressed the need for backward compatibility between IPv6 and IPv4, and 
 instead counted on magic handwaving about tipping points and transition 
 dates where suddenly there would be "enough" IPv6-connected resources that 
 new networks wouldn't *need* IPv4 address space any more.
 

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Andrews]

> On 12 Oct 2023, at 06:51, Delong.com  wrote:
> 
> 
> 
>> On Oct 11, 2023, at 12:47, Mark Andrews  wrote:
>> 
>> It is no different to deploying PNAT44 in every CPE box in the world to 
>> allow you to connect to the global IPv4 internet today.  Virtually no home 
>> network on the planet has fully functional IPv4 available to it.  Many 
>> businesses networks don’t have fully functional IPv4 networks.  We have 
>> already installed transition middle boxes between the public IPv4 internet 
>> and your private IPv4 internet.  The are just so ubiquitous that you are 
>> unaware of them.  This is just a transition between your IPv4 internet 
>> (public or private) and the global IPv6 internet.
> 
> 1. I’m one of the few homes that is an exception to that “virtually no home” 
> statement.
> 2. Yes, I’m acutely aware of them, I’ve deployed plenty of them, and regret 
> each and every one.
> 3. The difference is that you can deploy a PNAT44 CPE box without an IPv6 
> address. You cannot
> deploy a NAPT64 box without an IPv4 address.
> 
>> Almost all traffic flows go through a transition box today.
> 
> Sad but true. Still not really relevant to the point being made.
> 
>> If the router modifies the source or destination addresses or the ports of 
>> the packet it is a transition box.  It is the border between two internets. 
> 
> Absolutely agree… Still not the point…
> 
> The point here is that at some point, even with translation, we run out of 
> IPv4 addresses to use for this purpose. What then?

You deliver the Internet over IPv6.  A really large functional Internet exists 
today if you only have IPv6.  It is only getting bigger.  Lots of (the 
majority?) of CDNs deliver content over IPv6.  Lots of companies outsource 
their SMTP to dual stacked service providers so that email still gets through.
After 20 years there is no excuse for ISPs failing to deliver IPv6.  If you 
have to you, outsource your NAT64, DS-Lite transition service to someone that 
has IPv4.  I’m surprised that it isn’t common today.

> Owen
> 
>> 
>> -- 
>> Mark Andrews
>> 
>>> On 12 Oct 2023, at 06:07, Delong.com  wrote:
>>> 
>>> 
>>> 
> On Oct 10, 2023, at 17:20, Mark Andrews  wrote:
> 
> 
> 
>> On 11 Oct 2023, at 09:43, Delong.com via NANOG  wrote:
> 
>> As a community, we have failed, because we never acknowledged and 
>> addressed the need for backward compatibility between IPv6 and IPv4, and 
>> instead counted on magic handwaving about tipping points and transition 
>> dates where suddenly there would be "enough" IPv6-connected resources 
>> that new networks wouldn't *need* IPv4 address space any more.
> 
> I’m not sure that we never acknowledged it, but we did fail to address 
> it, largely because I think we basically determined that it’s “too hard”.
 
 It’s not actually that hard to do on a small scale, i.e. inside a home CPE 
 with a DNS server and a NAT64 implementation that supports semi static 
 mappings.  It does require IPv4 sites have IPv6 connectivity. You stand up 
 a DNS46 which requests an unused IPv4 address from a prefix block, say 
 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 
 with the IPv6 address it needs to be mapped to with an initial NAT64 
 lifetime value.  The DNS46 would forget the mapping after half that 
 initial lifetime.  The DNS46 would return A records limited half the 
 lifetime or less so they timeout before the NAT64 mapping expires.  The 
 hard part is scaling up to a large client base because not every DNS query 
 results in IP traffic and you need a prefix block big enough to support 
 the add rate of the client base.  Doing this at ISP scale would be 
 interesting to say the least.  This is not theoretical.  It has been 
 implemented in the past though some to the details might differ.
>>> 
>>> That’s not what we’re talking about… That’s translation, not backwards 
>>> compatibility.
>>> 
 Companies that have gone IPv6-only internally do this with fully static 
 IPv4 to IPv6 mappings and skip the DNS46 step.
>>> 
>>> But doing that requires that the companies have a certain amount of V4. The 
>>> question was how to talk to v4-only hosts with ZERO IPv4 addresses 
>>> available to you.
>>> 
 So if you have a legacy device that can’t talk IPv6 there is a solution 
 space that allows it to talk to the IPv6 internet.  You need to install it 
 however.  Adding DNS46 to a nameserver is about a days if you already have 
 a DNS64 model.  The hard bit is working out how to talk to the NAT64 
 implementation.  A good project to put on a Raspberry Pi or similar.
>>> 
>>> I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 
>>> addresses and none are available to me.
>>> 
>>> How do I make any of this work?
>>> 
>>> That’s the question that remains unsolved and that’s the one we most 
>>> desperately failed 

Re: constraining RPKI Trust Anchors

[Job Snijders via NANOG]

Dear Martin,

On Wed, Oct 11, 2023 at 10:01:53AM +0200, Martin Pels wrote:
> I think this is important work.

Thanks!

> As you indicated in your mail you have spent quite some time compiling
> the constraints files in the appendix. Keeping them up to date
> requires tracking allocations and policy developments in all RIRs. It
> reminds me of bogon filters for unallocated IP space, and the
> associated problems of networks not updating them [0].

Yes, indeed there is a burden associated with this risk mitigation
approach. I deem tracking of ratified policies in all RIRs feasible, but
yeah... it'll definitely be a recurring quarterly todo item. The current
approach in developing these default constraint listings is to focus on
coarse-grained filters, and not bother to document unallocated space
because the resulting churn would hard to manage & distribute.

> So while each RP should be able to make policy decisions based on its
> own local criteria, managing a default set of constraints is something
> that is best done centralized. Who do you envision should manage these
> lists? RP software maintainers? RIRs? Others?

I guess initially it'll be the RP developers (like me), because who else
is chartered to produce such listings at this moment? I do intend to
keep [1] updated. Would you like to help? :-)

I envision the default constraints can be distributed via packages like
rpki-trust-anchors [2] and integral in operating systems like OpenBSD in
order to reduce the burden on operators.

A potential follow-up exercise here could be to propose to increase the
level of detail in IANA's IPv4 Address Space Registry [0] by - for
example - documenting the longer-than-/8 blocks each RIR transferred to
AFRINIC when AFRINIC was instantiated.

Kind regards,

Job

[0]: 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
[1]: 
https://www.ietf.org/archive/id/draft-snijders-constraining-rpki-trust-anchors-00.html
[2]: https://packages.debian.org/stable/rpki-trust-anchors

Re: Lumen Seattle Contact

[Brendan Carlson]

Hey All,

I got an escalation contact. All set here.

Thanks!

On Wed, Oct 11, 2023, 10:54 Brendan Carlson 
wrote:

> Hello All,
>
> I have a client in Seattle, they've been hard down since Sunday due to a
> replaced CL/Lumen switch in the building telephone room. They never got
> hooked up after the switch was replaced.
>
> Can someone please contact me off list about this?
>
> Thanks!
>

Re: Lumen Seattle Contact

[TJ Trout]

Seems like a quick call to the noc with a ticket number they could get
somebody dispatched in half a day or less

On Wed, Oct 11, 2023, 10:57 AM Brendan Carlson 
wrote:

> Hello All,
>
> I have a client in Seattle, they've been hard down since Sunday due to a
> replaced CL/Lumen switch in the building telephone room. They never got
> hooked up after the switch was replaced.
>
> Can someone please contact me off list about this?
>
> Thanks!
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 11, 2023, at 12:47, Mark Andrews  wrote:
> 
> It is no different to deploying PNAT44 in every CPE box in the world to allow 
> you to connect to the global IPv4 internet today.  Virtually no home network 
> on the planet has fully functional IPv4 available to it.  Many businesses 
> networks don’t have fully functional IPv4 networks.  We have already 
> installed transition middle boxes between the public IPv4 internet and your 
> private IPv4 internet.  The are just so ubiquitous that you are unaware of 
> them.  This is just a transition between your IPv4 internet (public or 
> private) and the global IPv6 internet.

1.  I’m one of the few homes that is an exception to that “virtually no 
home” statement.
2.  Yes, I’m acutely aware of them, I’ve deployed plenty of them, and 
regret each and every one.
3.  The difference is that you can deploy a PNAT44 CPE box without an IPv6 
address. You cannot
deploy a NAPT64 box without an IPv4 address.

> Almost all traffic flows go through a transition box today.

Sad but true. Still not really relevant to the point being made.

> If the router modifies the source or destination addresses or the ports of 
> the packet it is a transition box.  It is the border between two internets. 

Absolutely agree… Still not the point…

The point here is that at some point, even with translation, we run out of IPv4 
addresses to use for this purpose. What then?

Owen

> 
> -- 
> Mark Andrews
> 
>> On 12 Oct 2023, at 06:07, Delong.com  wrote:
>> 
>> 
>> 
 On Oct 10, 2023, at 17:20, Mark Andrews  wrote:
 
 
 
> On 11 Oct 2023, at 09:43, Delong.com via NANOG  wrote:
 
> As a community, we have failed, because we never acknowledged and 
> addressed the need for backward compatibility between IPv6 and IPv4, and 
> instead counted on magic handwaving about tipping points and transition 
> dates where suddenly there would be "enough" IPv6-connected resources 
> that new networks wouldn't *need* IPv4 address space any more.
 
 I’m not sure that we never acknowledged it, but we did fail to address it, 
 largely because I think we basically determined that it’s “too hard”.
>>> 
>>> It’s not actually that hard to do on a small scale, i.e. inside a home CPE 
>>> with a DNS server and a NAT64 implementation that supports semi static 
>>> mappings.  It does require IPv4 sites have IPv6 connectivity. You stand up 
>>> a DNS46 which requests an unused IPv4 address from a prefix block, say 
>>> 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 
>>> with the IPv6 address it needs to be mapped to with an initial NAT64 
>>> lifetime value.  The DNS46 would forget the mapping after half that initial 
>>> lifetime.  The DNS46 would return A records limited half the lifetime or 
>>> less so they timeout before the NAT64 mapping expires.  The hard part is 
>>> scaling up to a large client base because not every DNS query results in IP 
>>> traffic and you need a prefix block big enough to support the add rate of 
>>> the client base.  Doing this at ISP scale would be interesting to say the 
>>> least.  This is not theoretical.  It has been implemented in the past 
>>> though some to the details might differ.
>> 
>> That’s not what we’re talking about… That’s translation, not backwards 
>> compatibility.
>> 
>>> Companies that have gone IPv6-only internally do this with fully static 
>>> IPv4 to IPv6 mappings and skip the DNS46 step.
>> 
>> But doing that requires that the companies have a certain amount of V4. The 
>> question was how to talk to v4-only hosts with ZERO IPv4 addresses available 
>> to you.
>> 
>>> So if you have a legacy device that can’t talk IPv6 there is a solution 
>>> space that allows it to talk to the IPv6 internet.  You need to install it 
>>> however.  Adding DNS46 to a nameserver is about a days if you already have 
>>> a DNS64 model.  The hard bit is working out how to talk to the NAT64 
>>> implementation.  A good project to put on a Raspberry Pi or similar.
>> 
>> I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 
>> addresses and none are available to me.
>> 
>> How do I make any of this work?
>> 
>> That’s the question that remains unsolved and that’s the one we most 
>> desperately failed to tackle.
>> 
>> Owen
>> 

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Andrews]

It is no different to deploying PNAT44 in every CPE box in the world to allow 
you to connect to the global IPv4 internet today.  Virtually no home network on 
the planet has fully functional IPv4 available to it.  Many businesses networks 
don’t have fully functional IPv4 networks.  We have already installed 
transition middle boxes between the public IPv4 internet and your private IPv4 
internet.  The are just so ubiquitous that you are unaware of them.  This is 
just a transition between your IPv4 internet (public or private) and the global 
IPv6 internet.

Almost all traffic flows go through a transition box today.

If the router modifies the source or destination addresses or the ports of the 
packet it is a transition box.  It is the border between two internets. 

-- 
Mark Andrews

> On 12 Oct 2023, at 06:07, Delong.com  wrote:
> 
> 
> 
>>> On Oct 10, 2023, at 17:20, Mark Andrews  wrote:
>>> 
>>> 
>>> 
 On 11 Oct 2023, at 09:43, Delong.com via NANOG  wrote:
>>> 
 As a community, we have failed, because we never acknowledged and 
 addressed the need for backward compatibility between IPv6 and IPv4, and 
 instead counted on magic handwaving about tipping points and transition 
 dates where suddenly there would be "enough" IPv6-connected resources that 
 new networks wouldn't *need* IPv4 address space any more.
>>> 
>>> I’m not sure that we never acknowledged it, but we did fail to address it, 
>>> largely because I think we basically determined that it’s “too hard”.
>> 
>> It’s not actually that hard to do on a small scale, i.e. inside a home CPE 
>> with a DNS server and a NAT64 implementation that supports semi static 
>> mappings.  It does require IPv4 sites have IPv6 connectivity. You stand up a 
>> DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, 
>> when there is an IPv6 address without an IPv4 address from the NAT64 with 
>> the IPv6 address it needs to be mapped to with an initial NAT64 lifetime 
>> value.  The DNS46 would forget the mapping after half that initial lifetime. 
>>  The DNS46 would return A records limited half the lifetime or less so they 
>> timeout before the NAT64 mapping expires.  The hard part is scaling up to a 
>> large client base because not every DNS query results in IP traffic and you 
>> need a prefix block big enough to support the add rate of the client base.  
>> Doing this at ISP scale would be interesting to say the least.  This is not 
>> theoretical.  It has been implemented in the past though some to the details 
>> might differ.
> 
> That’s not what we’re talking about… That’s translation, not backwards 
> compatibility.
> 
>> Companies that have gone IPv6-only internally do this with fully static IPv4 
>> to IPv6 mappings and skip the DNS46 step.
> 
> But doing that requires that the companies have a certain amount of V4. The 
> question was how to talk to v4-only hosts with ZERO IPv4 addresses available 
> to you.
> 
>> So if you have a legacy device that can’t talk IPv6 there is a solution 
>> space that allows it to talk to the IPv6 internet.  You need to install it 
>> however.  Adding DNS46 to a nameserver is about a days if you already have a 
>> DNS64 model.  The hard bit is working out how to talk to the NAT64 
>> implementation.  A good project to put on a Raspberry Pi or similar.
> 
> I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 
> addresses and none are available to me.
> 
> How do I make any of this work?
> 
> That’s the question that remains unsolved and that’s the one we most 
> desperately failed to tackle.
> 
> Owen
> 

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 11, 2023, at 11:50, Dale W. Carder  wrote:
> 
> Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 
> 04:52:07PM -0700:
>> However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 
>> as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect 
>> AS YY would generate ROAs for
>>  2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
>>  2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>>  2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
>>  2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>>  2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>>  2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>>  2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>>  2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> 
> Double check, but offhand I believe in this case you do not need all 
> these AS0 ROA's.  Any validated ROA payload fully matching should be
> all you need for it to be valid, and anything that is covered by a vrp
> but not matching is invalid.
> 
> So, I think you can do
>   2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32
>   2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
>   2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
> 
> Dale

My understanding is that the 2001:db8::/32 max=32 would block the /36s from 
being considered valid (in order to prevent someone with trust anchor B 
overriding the policy of someone with trust anchor A).

Since all the trust anchors are ::/0, I think that was deemed important.

I could be wrong, like you, I would need to double check the details.

Owen

Re: xfinity not working

[Delong.com via NANOG]

> On Oct 11, 2023, at 11:34, William Herrin  wrote:
> 
> On Wed, Oct 11, 2023 at 11:12 AM Delong.com  wrote:
>> There are still some knobs…
>> 
>> e.g. bridge mode or not (usually)
> 
> I'm guessing that's only if there's a built-in wifi router. My grand
> experience with cable modems counts to exactly two brands and four
> models, but in each case the model without wifi was solely a bridge.
> The knobs, as such, were: change the password and reboot the modem.
> 

Nope… My Surfboard 8611 has that (just Cable<->single ethernet port).

In non-bridge mode, it acts as a NAT router between the ethernet port and the 
single address dropped on the modem by the $CABLECO DHCP server.

In bridge mode, it passes my packets to the $CABLECO DHCP server.

Since I have business service, I’m able to use that to actually get DHCP 
addresses on multiple devices.

In my case, that’s a pair of MX-240s and an SRX-340.

The SRX-340 provides a backup simple network (SRX LAN ->NAT->$CABLECO) in case 
things go wrong with the (usually more reliable multi-homed) network. (This was 
quick and easy to set up and helped keep the family off my back while 
troubleshooting the transition to the bigger upgrades).

The MX-240s each also have a connection to Ridge Wireless and there are GRE 
tunnels from each via Ridge and Comcast to each of:
+   MX-240 at HE FMT2
+   VM/FRR based router at 55 South Market (San Jose)
+   Act USA in Las Vegas

BGP and traffic flow over the tunnels (BGP is loopback to loopback for FMT2 and 
55 S Market, direct EBGP peering to Act USA).

Owen

Re: constraining RPKI Trust Anchors

[Delong.com via NANOG]

Isn’t this sort of related to the AS-0 ROA effort a while back (except some of 
the RIRs rejected it, unfortunately)?

I suspect that the same reasons behind rejection of AS-0 will also apply to RIR 
implementation of something like this, so plans to address that (and revive 
AS-0 perhaps) might also be a worthy effort.

Owen


> On Oct 11, 2023, at 01:01, Martin Pels  wrote:
> 
> Hi Job,
> 
> I think this is important work.
> 
> As you indicated in your mail you have spent quite some time compiling the 
> constraints files in the appendix. Keeping them up to date requires tracking 
> allocations and policy developments in all RIRs. It reminds me of bogon 
> filters for unallocated IP space, and the associated problems of networks not 
> updating them[0].
> 
> So while each RP should be able to make policy decisions based on its own 
> local criteria, managing a default set of constraints is something that is 
> best done centralized. Who do you envision should manage these lists? RP 
> software maintainers? RIRs? Others?
> 
> [0] https://archive.nanog.org/meetings/nanog33/presentations/deitrich.pdf, 
> slide 4
> 
> Kind regards,
> Martin

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 10, 2023, at 17:20, Mark Andrews  wrote:
> 
> 
> 
>> On 11 Oct 2023, at 09:43, Delong.com via NANOG  wrote:
>> 
>>> As a community, we have failed, because we never acknowledged and addressed 
>>> the need for backward compatibility between IPv6 and IPv4, and instead 
>>> counted on magic handwaving about tipping points and transition dates where 
>>> suddenly there would be "enough" IPv6-connected resources that new networks 
>>> wouldn't *need* IPv4 address space any more.
>> 
>> I’m not sure that we never acknowledged it, but we did fail to address it, 
>> largely because I think we basically determined that it’s “too hard”.
> 
> It’s not actually that hard to do on a small scale, i.e. inside a home CPE 
> with a DNS server and a NAT64 implementation that supports semi static 
> mappings.  It does require IPv4 sites have IPv6 connectivity. You stand up a 
> DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, 
> when there is an IPv6 address without an IPv4 address from the NAT64 with the 
> IPv6 address it needs to be mapped to with an initial NAT64 lifetime value.  
> The DNS46 would forget the mapping after half that initial lifetime.  The 
> DNS46 would return A records limited half the lifetime or less so they 
> timeout before the NAT64 mapping expires.  The hard part is scaling up to a 
> large client base because not every DNS query results in IP traffic and you 
> need a prefix block big enough to support the add rate of the client base.  
> Doing this at ISP scale would be interesting to say the least.  This is not 
> theoretical.  It has been implemented in the past though some to the details 
> might differ.

That’s not what we’re talking about… That’s translation, not backwards 
compatibility.

> Companies that have gone IPv6-only internally do this with fully static IPv4 
> to IPv6 mappings and skip the DNS46 step.

But doing that requires that the companies have a certain amount of V4. The 
question was how to talk to v4-only hosts with ZERO IPv4 addresses available to 
you.

> So if you have a legacy device that can’t talk IPv6 there is a solution space 
> that allows it to talk to the IPv6 internet.  You need to install it however. 
>  Adding DNS46 to a nameserver is about a days if you already have a DNS64 
> model.  The hard bit is working out how to talk to the NAT64 implementation.  
> A good project to put on a Raspberry Pi or similar.

I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 
addresses and none are available to me.

How do I make any of this work?

That’s the question that remains unsolved and that’s the one we most 
desperately failed to tackle.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Dale W. Carder]

Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 
04:52:07PM -0700:
> However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 
> as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS 
> YY would generate ROAs for
>   2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
>   2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
>   2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
>   2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36

Double check, but offhand I believe in this case you do not need all 
these AS0 ROA's.  Any validated ROA payload fully matching should be
all you need for it to be valid, and anything that is covered by a vrp
but not matching is invalid.

So, I think you can do
2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32
2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36

Dale

Re: xfinity not working

[Michael Thomas]

On 10/11/23 11:34 AM, William Herrin wrote:

On Wed, Oct 11, 2023 at 11:12 AM Delong.com  wrote:

There are still some knobs…

e.g. bridge mode or not (usually)

I'm guessing that's only if there's a built-in wifi router. My grand
experience with cable modems counts to exactly two brands and four
models, but in each case the model without wifi was solely a bridge.
The knobs, as such, were: change the password and reboot the modem.


I thought that bridge was the DOCSIS model. Is there a choice these 
days? Back when I was actually working with this, the expectation is the 
modem was pretty dumb and not accessible to the user. It would tftp its 
config from the MSO and that was that.


Mike

Re: xfinity not working

[William Herrin]

On Wed, Oct 11, 2023 at 11:12 AM Delong.com  wrote:
> There are still some knobs…
>
> e.g. bridge mode or not (usually)

I'm guessing that's only if there's a built-in wifi router. My grand
experience with cable modems counts to exactly two brands and four
models, but in each case the model without wifi was solely a bridge.
The knobs, as such, were: change the password and reboot the modem.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 10, 2023, at 22:44, Willy Manga  wrote:
> 
> 
> 
> > On 11/10/2023 03:52, Delong.com wrote:
>> 
>>> On Oct 10, 2023, at 13:36, Matthew Petach  wrote:
>>> [...]
>>> Owen,
>>> 
>>> RPKI only addresses accidental hijackings.
>>> It does not help prevent intentional hijackings.
>> OK, but at least they can help limit the extent of required desegregation in 
>> combat unless I misunderstand the whole MAXPREFIXLEN option.
> 
> Actually, RFC 9319 do recommend to "avoid using the maxLength attribute in 
> ROAs except in some specific cases". But I recognise that this RFC is not yet 
> implemented everywhere.

It’s a BCP, and may be worthy of reconsideration.

The justification in section 1.0 paragraph 3 of that basically points out 
exactly what I said people _SHOULD_ be doing _IF_ they use max prefix and have 
failed to do in “84% were vulnerable…”.

> 
> 
>>> 
>>> RPKI only asserts that a specific ASN must originate a prefix.  It does 
>>> nothing to validate the authenticity of the origination.
>> Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed 
>> prefix length”.
>> E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum 
>> Length” attribute of /36, then any advertisement (even originated by 65500) 
>> that is longer than /36 should be considered invalid.
> 
> Yes, but in that scenario any advertisements between /32 and /36 from that 
> prefix originated by AS65500 are *valid* . That's why "ROAs should be as 
> precise as possible, meaning they should match prefixes as announced in BGP" 
> [1]

You completely ignored my statement of the need for appropriate AS-0 ROAs to 
block those.

Owen

Re: xfinity not working

[Delong.com via NANOG]

There are still some knobs…

e.g. bridge mode or not (usually)

Owen


> On Oct 10, 2023, at 23:01, William Herrin  wrote:
> 
> On Tue, Oct 10, 2023 at 6:07 PM Al Whaley  wrote:
>> My understanding is that the internal web page in the consumer modems is
>> gone.  App or nothing.
> 
> With xfinity, when you plug it a "non-activated" modem, you get a
> walled garden where you can connect to some of their web servers for
> the purpose of linking your modem with your account. Except, as noted,
> it's not presently in good working order..
> 
> And anyway, I brought my own modem which has an internal web server
> and a handful of pages. Mostly status. Since it's the cable modem only
> (no wifi), there aren't any user-level knobs to turn.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Lumen Seattle Contact

[Brendan Carlson]

Hello All,

I have a client in Seattle, they've been hard down since Sunday due to a
replaced CL/Lumen switch in the building telephone room. They never got
hooked up after the switch was replaced.

Can someone please contact me off list about this?

Thanks!

NANOG 89 Socials + More - There is Still Time to Register! Join Us Virtually!

[Nanog News]

*NANOG 89 Socials *
*Network + Meet Community Members *

NANOG Socials are an incredible opportunity to get to know your peers in
the industry + foster important relationships in a relaxed, casual
environment.

They are also a lot of FUN!  Check out full details below.

*MORE INFO * 

*Engage With Us On Social *
*We Are YOUR Community *

Please help spread the word about how awesome NANOG is *by engaging *with
us on Linkedin, Facebook, Instagram, and Twitter.

Social media algorithms are dependent on community engagement. By simply
"liking" or commenting on our social media posts, you will promote content
in our newsfeed and ensure our voice is seen.

*NANOG 89 attendees:* Tag us in your favorite NANOG 89 pictures at #NANOG89
or #WeAreNANOG!

*Where to Watch NANOG 89*

NANOG 89 attendees can stream any presentation from Commodore CDE live
starting Monday, 16 October.

 Link here - nanog.org/events/nanog-89/watch-n89-webcast/

*Have You Checked Out our N89 Keynote Speakers? *
*Don't Miss Out — Sync Your Calendars Now *

*Monday Keynote: *The Expanding Landscape of Internet Governance: Why
Network Operators Need a Global View w/ President and CEO of ARIN, John
Curran.

* Tuesday Keynote:* Fireside Chat with COO of Arista Networks, Anshul
Sadana + NANOG Producer Elizabeth Drolet. Get to know the man behind
the tech and learn more about how to stay successful in today's rapidly
changing environment.

*MORE INFO *

*Enjoy the Best of San Diego On-Site*
*N89 Venue Offers Incredible Beaches, Activities + Award-Winning Dining *

Devour delicious seafood, locally grown products, and enjoy award-winning
chefs without ever leaving the hotel. Loews features four distinct
restaurants with a variety of food options. Check out more hotel highlights
+ helpful information.

*READ MORE *

[NANOG-announce] NANOG 89 Socials + More - There is Still Time to Register! Join Us Virtually!

[Nanog News]

*NANOG 89 Socials *
*Network + Meet Community Members *

NANOG Socials are an incredible opportunity to get to know your peers in
the industry + foster important relationships in a relaxed, casual
environment.

They are also a lot of FUN!  Check out full details below.

*MORE INFO * 

*Engage With Us On Social *
*We Are YOUR Community *

Please help spread the word about how awesome NANOG is *by engaging *with
us on Linkedin, Facebook, Instagram, and Twitter.

Social media algorithms are dependent on community engagement. By simply
"liking" or commenting on our social media posts, you will promote content
in our newsfeed and ensure our voice is seen.

*NANOG 89 attendees:* Tag us in your favorite NANOG 89 pictures at #NANOG89
or #WeAreNANOG!

*Where to Watch NANOG 89*

NANOG 89 attendees can stream any presentation from Commodore CDE live
starting Monday, 16 October.

 Link here - nanog.org/events/nanog-89/watch-n89-webcast/

*Have You Checked Out our N89 Keynote Speakers? *
*Don't Miss Out — Sync Your Calendars Now *

*Monday Keynote: *The Expanding Landscape of Internet Governance: Why
Network Operators Need a Global View w/ President and CEO of ARIN, John
Curran.

* Tuesday Keynote:* Fireside Chat with COO of Arista Networks, Anshul
Sadana + NANOG Producer Elizabeth Drolet. Get to know the man behind
the tech and learn more about how to stay successful in today's rapidly
changing environment.

*MORE INFO *

*Enjoy the Best of San Diego On-Site*
*N89 Venue Offers Incredible Beaches, Activities + Award-Winning Dining *

Devour delicious seafood, locally grown products, and enjoy award-winning
chefs without ever leaving the hotel. Loews features four distinct
restaurants with a variety of food options. Check out more hotel highlights
+ helpful information.

*READ MORE *

___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Jay R. Ashworth]

I'm not disabled (any more than being 58 years old makes you), but I know
lots of people who are.

And procmail still works just fine, I'm told.

Cheers,
-- jra

- Original Message -
> From: "Fred Baker" 
> To: "Warren Kumari" 
> Cc: nanog@nanog.org
> Sent: Friday, October 6, 2023 4:28:43 PM
> Subject: Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

> It’s been absurd for a while now…
> 
> Sent using a machine that autocorrects in interesting ways...
> 
>> On Oct 6, 2023, at 1:15 PM, Warren Kumari  wrote:
> 
>> On Fri, Oct 06, 2023 at 2:58 PM, Sean Donelan < s...@donelan.com > wrote:
> 
>>> The Disability Advocacy Community has been extensively involved with 
>>> CMAS/WEA
>>> since President Bush signed the WARN Act, passed by a republican house and
>>> republican senate, in 2006.
> 
>>> The dozens of disability groups helped design the sound and vibration 
>>> cadence
>>> (which is different than EAS), and the policies for alerting.
> 
>>> Nation-wide testing (EAS) has been conducted since 2011. And nation-wide 
>>> testing
>>> (WEA) since 2014. National tests were conducted almost every between 2011 
>>> and
>>> 2020, suspended during the pandemic.
> 
>>> The national tests are announced at least 60 days in advance by the FCC and
>>> FEMA. News media have multiple stories. Most state and many local goverments
>>> also had notifications.
> 
>>> If you haven't been involved with the disability community for a decade, and
>>> your school office didn't notify special education teachers about the news
>>> releases and government advance notifications, perhaps that's room for
>>> improvement with local school communications. Fire drills, tornado drills, 
>>> etc.
>>> often involve loud sounds and flashing lights.
> 
>> Fine! In that case I *demand* that we stop having fires and tornados and
>> similar. It's super-disruptive to have to go and hide in my basement *every
>> single time* there is a tornado, or pull over every time a fire engine comes
>> barreling down the road…. and those sirens!... and the flashy lights!
>> Wake up people, fire truck and police sirens are *specifically designed* to
>> disrupt! It's all part of their plan to, erm…. well, something something….
> 
>> Ok, now that we have reached the absurdum part of reductio ad absurdum can we
>> get back to network engineering?
> 
> > W

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: constraining RPKI Trust Anchors

[Martin Pels]

Hi Job,

I think this is important work.

As you indicated in your mail you have spent quite some time compiling 
the constraints files in the appendix. Keeping them up to date requires 
tracking allocations and policy developments in all RIRs. It reminds me 
of bogon filters for unallocated IP space, and the associated problems 
of networks not updating them[0].


So while each RP should be able to make policy decisions based on its 
own local criteria, managing a default set of constraints is something 
that is best done centralized. Who do you envision should manage these 
lists? RP software maintainers? RIRs? Others?


[0] 
https://archive.nanog.org/meetings/nanog33/presentations/deitrich.pdf, 
slide 4


Kind regards,
Martin

Re: maximum ipv4 bgp prefix length of /24 ?

[borg]

Well, I think the sane solution would be to push customers/clients
into IPv6 and keep services IPv4. Then start moving services to dualstack.

Most of todays customers/clients are consumers. They just connect to server
to get data, watch movies, listen to music. Gaming is similar. That way,
ISPs could do NAT64 thingie to provide IPv6 -> IPv4 bridges. More IPv4
addresses would be freed for power users. After decade, IPv4 could be nearly 
gone.

If only IPv6 would suck so badly... ;)


-- Original message --

From: Delong.com via NANOG 
To: Matthew Petach 
Cc: Geoff Huston , Delong.com via NANOG 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?
Date: Tue, 10 Oct 2023 15:43:28 -0700

Im not sure that we never acknowledged it, but we did fail to address it,
largely because I think we basically determined that its too hard.

Theres really no way for a machine with a >32 bit address to
feasibly/reliably talk to a machine that only understands 32-bit addresses
short of involving some sort of intermediate proxy host doing some form of
address translation. Weve actually got LOTS of those solutions deployed with
varying levels of success/failure/idiosyncrasies. Ive spent a fair amount of
time thinking about alternatives and admit that I, myself am stumped as to
how one would go about this.

Do you have a proposal for how this problem could have been/could be solved?

Re: xfinity not working

[William Herrin]

On Tue, Oct 10, 2023 at 6:07 PM Al Whaley  wrote:
> My understanding is that the internal web page in the consumer modems is
> gone.  App or nothing.

With xfinity, when you plug it a "non-activated" modem, you get a
walled garden where you can connect to some of their web servers for
the purpose of linking your modem with your account. Except, as noted,
it's not presently in good working order..

And anyway, I brought my own modem which has an internal web server
and a handful of pages. Mostly status. Since it's the cable modem only
(no wifi), there aren't any user-level knobs to turn.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: xfinity not working

[William Herrin]

On Tue, Oct 10, 2023 at 6:36 PM Crist Clark  wrote:
> I had a forced modem upgrade with them earlier this year. I vaguely recall it 
> was not without some frustration, but I managed to get it done.
>
> I don’t seem to have a problem logging in at
> https://login.xfinity.com/login
> Is it transient or still persisting for you?

Howdy,

http://www.xfinity.net/activate only responds if you're on an
unactivated cable modem connected to xfinity.

https://login.xfinity.com/login only works if you're not.

And neither one particularly works with Firefox. It's chrome all the way down.


I gave up and installed the app. User name, password, cable modem's
mac address. And now it's activated.


I know it's bad form to bring this sort of thing to NANOG, but come on
guys: get your act together.

Regards,
Bill Herrin




-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/