Re: uPRF strict more

[Mark Tinka]

On 9/29/21 20:14, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their 
peering guidelines.


Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and 
its usefulness today is almost nil.  That being said we still see 
large providers who have it turned on for peering/transit interfaces 
either out of legacy configuration or other reasons.  The vast 
majority do not use it for those interface roles.




If you don't plan to run a full BGP table on a device, don't enable 
uRPF, even loose-mode.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 19:07, Adam Thompson wrote:

We just ran into a typical case where uRPF caused a partial outage for 
one of my customers: the customer is multi-homed, with another 
provider that I'm *also*​ connected to.  Customer advertised a 
longer-prefix to the other guy, so I started sending traffic destined 
for Customer to the Other Provider... who then promptly dropped it 
because they had uRPF enabled on the peering link, and they were 
seeing random source IPs that weren't mine. Well... yeah, that can 
happen (semi-legitimately) anytime you have a topological triangle in 
peering.


I've concluded over the last 2 years that uRPF is *only*​ useful on 
interfaces pointing directly at non-multi-homed customers, and 
*actively dangerous *anywhere else.


That's not exactly true, unless that other provider is not carrying a 
full table on the device your traffic toward your customer was transiting.


Generally, we only run uRPF on boxes that carry a fully BGP table. The 
lack of a full table, even with loose-mode uRPF, will lead to blackholing.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 23:36, Anoop Ghanwani wrote:

This is not true for all ASICs.  Some ASICs choose to incur the 
penalty in a different way, e.g., by halving the prefix tables.  The 
prefix table is then duplicated so that uRPF SA and forwarding DA 
lookups can happen in parallel.  What kind of penalty is incurred is a 
question worth asking the equipment vendor.


Agree with this - the implementation can vary between vendors and 
between hardware.


Best to test your specific platform, to be sure.

Mark.

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 29, 2021, at 14:23 , Victor Kuarsingh  wrote:
> 
> 
> 
> On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas  > wrote:
> 
> 
> On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
>> 
>> 
>> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > > wrote:
>> 
>> 
>>> On Sep 29, 2021, at 09:25, Victor Kuarsingh >> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG >> > wrote:
>>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>>> routers, set the priority of the preferred router to high in the RAs. If 
>>> you’re using one router, set the preferred prefix as desired in the RAs. 
>>> 
>>> Owen
>>> 
>>> I agree this works, but I assume that we would not consider this a consumer 
>>> level solution (requires an administrator to make it work).  It also 
>>> assumes the local network policy allows for auto-addressing vs. requirement 
>>> for DHCP.  
>> 
>> It shouldn’t require an administrator if there’s just one router. If there 
>> are two routers, I’d say we’re beyond the average consumer. 
>> 
>> In the consumer world (Where a consumer has no idea who we are, what IP is 
>> and the Internet is a wireless thing they attach to). 
>> 
>> I am only considering one router (consumer level stuff).  Here is my example:
>> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a 
>> local cable service and/or DSL service, and/or xPON service
>> 
> Isn't the easier (and cheaper) thing to do here is just use a VPN to get 
> behind the corpro firewall? Or as is probably happening more and more there 
> is no corpro network at all since everything is outsourced on the net for 
> smaller companies like your law firm.
> 
> 
> For shops with IT departments, sure that can make sense.  For many mom/pop 
> setups, maybe less likely.  The challenge for us (in this industry) is that 
> we need to address not just the top use cases, but the long tail as well 
> (especially in this new climate of more WFH).

The mom/pop law firm without an IT department probably isn’t working from home 
any more, they’re probably back in the office.

In any case, they probably have the office “resources” they want to use for WFH 
in the cloud somewhere so there’s no difference
in access between home and office.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 29, 2021, at 13:09 , Victor Kuarsingh  wrote:
> 
> 
> 
> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong  > wrote:
> 
> 
>> On Sep 29, 2021, at 09:25, Victor Kuarsingh > > wrote:
>> 
>> 
>> 
>> 
>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG > > wrote:
>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>> routers, set the priority of the preferred router to high in the RAs. If 
>> you’re using one router, set the preferred prefix as desired in the RAs. 
>> 
>> Owen
>> 
>> I agree this works, but I assume that we would not consider this a consumer 
>> level solution (requires an administrator to make it work).  It also assumes 
>> the local network policy allows for auto-addressing vs. requirement for 
>> DHCP.  
> 
> It shouldn’t require an administrator if there’s just one router. If there 
> are two routers, I’d say we’re beyond the average consumer. 
> 
> In the consumer world (Where a consumer has no idea who we are, what IP is 
> and the Internet is a wireless thing they attach to). 
> 
> I am only considering one router (consumer level stuff).  Here is my example:
> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a 
> local cable service and/or DSL service, and/or xPON service

OK, so one router or two?

> - Both providers have IPv6 (competing in the market so don't cooperate on how 
> to address, manage customer homes) 

This shouldn’t be necessary with appropriate CPE, especially if Mr/Ms/Ze Smith 
has a single router for both.

> - Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything 
> else technical (typical consumer); They only knows how to walk into a store 
> and buy a random thing off the shelf and ask for "WiFi".

Again, assuming a single router managing both providers with a sane 
implementation and rational defaults, this shouldn’t be a problem.

Of course, today, that isn’t really available in v4 for the most part, either.

> - Both providers provide IPv6 and delegate a prefix to the router (let's 
> pretend the retail staff knew enough to sell this person a consumer box with 
> 2x WAN interfaces) 

Let’s further pretend that the software in the box is sane about its v6 
implementation and has a “primary” and “backup” port allowing it to make 
rational default choices
about priority/preference fields in the RAs that it generates and that it 
defaults to SLAAC only on the LAN ports.

> - Lets also assume the cable boxes have a consumer actionable way to force 
> R1483 mode, and assume the DSL device can do the same (I know many providers 
> that don't allow this type of configuration)

R1483 is unfamiliar to me unless you mean the RFC covering Multiprotocol 
Encapsulation over ATM Adaptation Layer 5.

Assuming this is what you mean, let me get this straight, we’ve got a consumer 
who doesn’t know what IPv4 or IPv6 are, and she just wants WiFi, but she’s 
supposed to understand what RFC-1483 is and/or the implications of ATM 
Adaptation layer 5 for multi protocol encapsulation? I could be wrong, but I 
think that’s asking a lot.

The CPE should have rational defaults for supporting the two connections, 
period. She shouldn’t need “consumer actionable anything” an it should be 
possible to just plug it in and have it work.

> - So this dual WAN (retail) device now has one Public IPv4 address per WAN 
> interface (assuming one or both of the services was not disallowing bridging 
> mode, in which case its a Private address on one or both of the WAN 
> interfaces)

Sure, but we really don’t care about the IPv4 thing here, that’s going to 
involve tragic NAT hackery and whatever. Hopefully it’s a somewhat temporary 
problem.

> - this dual wan device also gets a PD from both upstream providers which 
> delegates to the CPE

That’s certainly what I would expect.

> I will ignore the dual router case as that normally looks very ugly in 
> networks as customers typically don't hook that up correctly (normally hook 
> one box in behind the first, not in parallel).   Do we think this use case 
> just works today?  Can we say we are confident we know how this all pans out 
> in real production?  e.g. CPE only uses one PD? uses both?  does all the 
> right things to support SLAAC downstream? 

I think that if the CPE has rational defaults (which I admit is not a given 
today) and truly supports IPv6 on the dual WAN ports with proper support for PD 
and corresponding SLAAC on the LAN ports, then yes, this should work.

CPE should use both. It should create RAs with a prefix from the primary port 
PD as preferred,valid,on-link and the secondary port PD as valid,on-link. CPE 
should have no problem doing SLAAC downstream.

I do not know if there are currently any routers that get this right, nor do I 
know if there are not. It’s almost certain there are still CPE routers that get 
this wrong.

> I hate to say it, but for the IPv4 case, a

Re: uPRF strict more

[Sabri Berisha]

- On Sep 29, 2021, at 8:03 AM, Blake Hudson bl...@ispn.net wrote:

Hi Blake,

>     200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
>     210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
>     220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)

These could perhaps be ICMP host unreachables transmitted by your
peers' infrastructure? I've seen my share of production networks 
running on RFC1918 space while routing public blocks.

Thanks,

Sabri

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 5:49 PM Baldur Norddahl 
wrote:

>
>
> On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh  wrote:
>
>> In the consumer world (Where a consumer has no idea who we are, what IP
>> is and the Internet is a wireless thing they attach to).
>>
>> I am only considering one router (consumer level stuff).  Here is my
>> example:
>>
>
> I am afraid you are tailor making your case. We could just as well have an
> even more clueless customer that simply buys a 4G/5G router and attaches it
> to the inside of his LAN in addition to the wifi router he got from his
> DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4
> goes but it _will_ work with IPv6.
>
> As for the tailor made case where the customer buys a device actually made
> for this, said device would also implement IPv6 for dual WAN. Plenty of
> options for how the device could do that, including the possibility of
> doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN
> and source route to the correct ISP.
>

You are correct - various cases will have different results (in fact my
main concern is that with consumer gear - there is quite a bit of
variability in what we can expect).

As for my use case, you are right, it was very specific, but that was on
purpose to have a fruitful discussion (versus hand waving things).  I also
wanted to discuss the dual prefix item as well (which was being discussed).
However it is a very real example and shows up in networks (at least in
NA).  I am sure we can draw a very long table of use cases with different
results.

Don't get me wrong, I want IPv6 to work better, I spent a lot of time
implementing IPv6 in multiple networks. That said, I also don't want to
ignore real common uses cases which impact customers and need to be
resolved.

I would like to dig into your use case a bit just so I understand.  I guess
in this case - you assumed the customer would hook up the LTE/5G router
using LAN side ports (no WAN side port).  That makes sense.  I bring this
up because what I had found when looking at direct network data is that
most consumers serialize connecting second routers to each other (but
that's a single provider use case - so I digress).

In this case, when we say "it won't work".  Do we mean nothing works? or
that the effective result of having a redundant connection to two providers
wont work. I agree that only one side, for IPv4 could work as the host
would only get an address from one or the other router.  This is a great
use case for IPv6 in terms of the benefits for dual router situations.

All that said, I do personally (because of impact on call centers and
costs) differentiate outcomes where something "does not have the full
intended redundancy" (but still works and gets people to the Internet)
versus "can supply brokenness driving calls and IT support" (the latter is
more serious in my opinion).

regards,

Victor K


>
> Regards,
>
> Baldur
>
>

Register Now for NANOG 83 + VIDEO | Ep.2 w/ Geoff Huston

[Nanog News]

*NANOG Partners with ICANN + Internet Society*
*Collaboration of Resources will Better Serve Communities*

In addition to our long-standing relationship with the American Registry
for Internet Numbers (ARIN), NANOG would like to also announce a new
partnership with the Internet Corporation for Assigned Names and Numbers
(ICANN) and the Internet Society.

These partnerships will help realize common objectives, promote
collaboration, and strengthen the outreach efforts of all the organizations
involved.


*READ MORE
*
*How will You Attend NANOG 83?*
*Register Now In-Person or Virtually*

Get excited for hybrid NANOG 83! Expect incredible programming, interactive
expos, networking events from the comfort of your home and/or in person.

The event will take place Nov. 1 - 3 in Minneapolis, MN, and all
programming + networking events will stream live for real-time engagement.

*REGISTER NOW  *

*INTERNET INNOVATORS - NEW EPISODE *
*WATCH EP. 2 w/ Internet Pioneer Geoff Huston*

Leave it to Internet Hall of Fame Global Connector + chief scientist for
APNIC, Geoff Huston to make the hairy + scary parts of the Internet almost
sound charming.

Maybe it's his sparkling wit, pleasant demeanor, (or maybe even) the
Australian accent that makes all pills a little easier to swallow.

Ep.2 of our new web series, "Internet Innovators"  Huston explains why we
need to continue to address the elephants in the room.

Huston also talks about the importance of developing public speaking skills
+ "how to make an impact on a room full of geeks."

We also get to hear more about Huston's childhood in Australia and what
made him the man he is today. Overall, Huston will leave you wanting to ask
better questions and think more critically of the digital world around you.

*WATCH EP. 2 NOW *

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 11:38:19PM +0200, Baldur Norddahl wrote:

On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG 
wrote:


Thanks a lot for sharing.

So 100 Gbps at line rate with 80B frames is about ~150 Mpps.

100 Gbps at line rate with 208B frames is about ~60 Mpps.

It's a significant penalty.



Full rate small packets would be an attack of some kind and could only
realistically arrive at your transit and peering ports. The customers
usually have slower (relatively) ports and a single customer could not
produce a rate of small packets that would be a concern. Therefore uRPF at
customer ports should not be a problem in this regard.


every network is different of course, and admittedly i am a couple generations
of hw from having tested this. the problem was indeed exacerbated by also 
having a ddos scrubbing service, but i still encourage my competitors to run

urpf.

-b



Regards,

Baldur

Re: IPv6 woes - RFC

[Baldur Norddahl]

On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh  wrote:

> In the consumer world (Where a consumer has no idea who we are, what IP is
> and the Internet is a wireless thing they attach to).
>
> I am only considering one router (consumer level stuff).  Here is my
> example:
>

I am afraid you are tailor making your case. We could just as well have an
even more clueless customer that simply buys a 4G/5G router and attaches it
to the inside of his LAN in addition to the wifi router he got from his
DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4
goes but it _will_ work with IPv6.

As for the tailor made case where the customer buys a device actually made
for this, said device would also implement IPv6 for dual WAN. Plenty of
options for how the device could do that, including the possibility of
doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN
and source route to the correct ISP.

Regards,

Baldur

Re: uPRF strict more

[Baldur Norddahl]

On Wed, 29 Sept 2021 at 22:07, Jean St-Laurent via NANOG 
wrote:

> Thanks a lot for sharing.
>
> So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
> 100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
> It's a significant penalty.
>

Full rate small packets would be an attack of some kind and could only
realistically arrive at your transit and peering ports. The customers
usually have slower (relatively) ports and a single customer could not
produce a rate of small packets that would be a concern. Therefore uRPF at
customer ports should not be a problem in this regard.

Regards,

Baldur

Re: IPv6 woes - RFC

[Michael Thomas]

On 9/29/21 2:23 PM, Victor Kuarsingh wrote:



On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas > wrote:



On 9/29/21 1:09 PM, Victor Kuarsingh wrote:



On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong mailto:o...@delong.com>> wrote:




On Sep 29, 2021, at 09:25, Victor Kuarsingh
mailto:vic...@jvknet.com>> wrote:




On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG
mailto:nanog@nanog.org>> wrote:

Use SLAAC, allocate prefixes from both providers. If you
are using multiple routers, set the priority of the
preferred router to high in the RAs. If you’re using one
router, set the preferred prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider
this a consumer level solution (requires an administrator to
make it work).  It also assumes the local network policy
allows for auto-addressing vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one
router. If there are two routers, I’d say we’re beyond the
average consumer.


In the consumer world (Where a consumer has no idea who we are,
what IP is and the Internet is a wireless thing they attach to).

I am only considering one router (consumer level stuff).  Here is
my example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home
and buy a local cable service and/or DSL service, and/or xPON service


Isn't the easier (and cheaper) thing to do here is just use a VPN
to get behind the corpro firewall? Or as is probably happening
more and more there is no corpro network at all since everything
is outsourced on the net for smaller companies like your law firm.


For shops with IT departments, sure that can make sense. For many 
mom/pop setups, maybe less likely.  The challenge for us (in this 
industry) is that we need to address not just the top use cases, but 
the long tail as well (especially in this new climate of more WFH).


The last startup I worked for a customer wanted audit info on our 
corporate network. We didn't have one. We just used various cloud based 
services to get our jobs done and rented cloud based vm's for the 
customer facing services. I would imagine that a mom/pop setup would do 
the same thing these days. Having a corpro network in the small probably 
doesn't make much sense anymore let alone the fancy multihoming 
scenarios to access it. There are security implications with all of 
this, of course, but that's probably the path of least resistance.


Mike

Re: uPRF strict more

[Anoop Ghanwani]

This is not true for all ASICs.  Some ASICs choose to incur the penalty in
a different way, e.g., by halving the prefix tables.  The prefix table is
then duplicated so that uRPF SA and forwarding DA lookups can happen in
parallel.  What kind of penalty is incurred is a question worth asking the
equipment vendor.

On Wed, Sep 29, 2021 at 1:10 PM Jean St-Laurent via NANOG 
wrote:

> Thanks a lot for sharing.
>
> So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
> 100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
> It's a significant penalty.
>
> Jean
>
> -Original Message-
> From: brad dreisbach 
> Sent: September 29, 2021 3:33 PM
> To: Jean St-Laurent 
> Cc: 'brad dreisbach' ; 'Phil Bedard' <
> bedard.p...@gmail.com>; 'North American Network Operators' Group' <
> nanog@nanog.org>
> Subject: Re: uPRF strict more
>
> On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
> >Hi Brad,
> >
> >I'd be interested to hear more about this pps penalty. Do we talk about
> 5% penalty or something closer to 50%?
> >
> >Let me know if you still have some numbers close to you related to PPS
> with uRPF loose.
>
> iirc, strict vs loose doesnt matter, its still an extra lookup which
> effects the performance. i was able to find some numbers to give an example.
>
> the 4x100G tomahawk card was able to pass min frame size(which iirc on
> ixia is
> 80B) at line rate with no features enabled. turn on uRPF and it is only
> able to pass 208B frames at line rate.
>
> similar results were seen with several generations of cisco and juniper
> line cards(if i tested nokia i cant recall, we had stopped doing urpf when
> they were introduced into the network).
>
> -b
>
>
>

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas  wrote:

>
> On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
>
>
>
> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong  wrote:
>
>>
>>
>> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
>>
>> 
>>
>>
>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
>> wrote:
>>
>>> Use SLAAC, allocate prefixes from both providers. If you are using
>>> multiple routers, set the priority of the preferred router to high in the
>>> RAs. If you’re using one router, set the preferred prefix as desired in the
>>> RAs.
>>>
>>> Owen
>>>
>>
>> I agree this works, but I assume that we would not consider this a
>> consumer level solution (requires an administrator to make it work).  It
>> also assumes the local network policy allows for auto-addressing vs.
>> requirement for DHCP.
>>
>>
>> It shouldn’t require an administrator if there’s just one router. If
>> there are two routers, I’d say we’re beyond the average consumer.
>>
>
> In the consumer world (Where a consumer has no idea who we are, what IP is
> and the Internet is a wireless thing they attach to).
>
> I am only considering one router (consumer level stuff).  Here is my
> example:
> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
> local cable service and/or DSL service, and/or xPON service
>
> Isn't the easier (and cheaper) thing to do here is just use a VPN to get
> behind the corpro firewall? Or as is probably happening more and more there
> is no corpro network at all since everything is outsourced on the net for
> smaller companies like your law firm.
>

For shops with IT departments, sure that can make sense.  For many mom/pop
setups, maybe less likely.  The challenge for us (in this industry) is that
we need to address not just the top use cases, but the long tail as well
(especially in this new climate of more WFH).

regards,

Victor K



>
> The use cases that stuck in my mind for the justification for the need for
> routing was for things like Zigbee and other low power networks where you
> want them isolated from the chatter of the local lan. Not saying that I
> agree with the justification, but that was it iirc.
>
> Mike
>

Re: PeeringDB Hackathon - looking for feature requests

[Steve McManus]

Thanks to all who submitted ideas for improving the API - we've added those to 
the backlog and plan to work on them in future PeeringDB releases or 
Hackathons. 

We ended up moving to the IPv6 theme for the NANOG Hackathon - PeeringDB has 
several items available to work on around improving simple search on peeringdb 
- including searching for IP addresses or cidrs. We'd love anyone who's 
participating in the upcoming Hackathon to help out and make PeeringDB better! 

Also, while I have you - another plug to fill in our 2021 survey: 
https://surveyhero.com/c/peeringdb2021usersurvey 
We'd really appreciate more input from the community on what we're doing well, 
could be doing better, etc. Thanks!

-Steve

> On Aug 12, 2021, at 3:27 PM, Steve McManus  wrote:
> 
> PeeringDB is looking at participating at an upcoming NANOG Hackathon. One of 
> the ideas for a theme is to improve the API. Specifically by adding API calls 
> for common use cases that people need to handle outside of the API. 
> Typically, by dumping the entire database to SQL For example - given two 
> IXes, which networks are present at both? We'd like to make a list of such 
> useful queries such that people don't have to dump the database just to run 
> them. A stretch goal would be to expose into the website instead of requiring 
> API calls.
> 
> This issue has some more detail, including a few existing ideas: 
> https://github.com/peeringdb/peeringdb/issues/1020
> 
> Comments there or in email to me would be super helpful. As always, if there 
> are other feature requests for PeeringDB, feel free to create an issue in 
> github ( https://github.com/peeringdb/peeringdb/issues/new/choose ) or in 
> email, even if they're not strictly Hackathon ideas. They are always 
> appreciated!
> 
> Thanks! 
> 
> -Steve
> PeeringDB Product Committee chair

Re: IPv6 woes - RFC

[Michael Thomas]

On 9/29/21 1:09 PM, Victor Kuarsingh wrote:



On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong > wrote:





On Sep 29, 2021, at 09:25, Victor Kuarsingh mailto:vic...@jvknet.com>> wrote:




On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG
mailto:nanog@nanog.org>> wrote:

Use SLAAC, allocate prefixes from both providers. If you are
using multiple routers, set the priority of the preferred
router to high in the RAs. If you’re using one router, set
the preferred prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider this
a consumer level solution (requires an administrator to make it
work).  It also assumes the local network policy allows for
auto-addressing vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one router.
If there are two routers, I’d say we’re beyond the average consumer.


In the consumer world (Where a consumer has no idea who we are, what 
IP is and the Internet is a wireless thing they attach to).


I am only considering one router (consumer level stuff). Here is my 
example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and 
buy a local cable service and/or DSL service, and/or xPON service


Isn't the easier (and cheaper) thing to do here is just use a VPN to get 
behind the corpro firewall? Or as is probably happening more and more 
there is no corpro network at all since everything is outsourced on the 
net for smaller companies like your law firm.


The use cases that stuck in my mind for the justification for the need 
for routing was for things like Zigbee and other low power networks 
where you want them isolated from the chatter of the local lan. Not 
saying that I agree with the justification, but that was it iirc.


Mike

RE: uPRF strict more

[Jean St-Laurent via NANOG]

I understand better why some prefer acl vs uRpf. 

For sure, forwarding 400 Gbps of 80B frames is a sign that something bad is 
happening. 😉

Jean

-Original Message-
From: brad dreisbach  
Sent: September 29, 2021 4:18 PM
To: Jean St-Laurent 
Cc: 'brad dreisbach' ; 'Phil Bedard' ; 
'North American Network Operators' Group' 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 04:07:19PM -0400, Jean St-Laurent wrote:
>Thanks a lot for sharing.
>
>So 100 Gbps at line rate with 80B frames is about ~150 Mpps.
>
>100 Gbps at line rate with 208B frames is about ~60 Mpps.
>
>It's a significant penalty.

and keep in kind the 4x100 card is 1 port per NPU. they make an 8x100 where the 
NPU's are shared. it gets even worse. not to single out cisco, this is just how 
urpf works. juniper had similar penalties, i just cant find the numbers.

-b

>
>Jean
>
>-Original Message-
>From: brad dreisbach 
>Sent: September 29, 2021 3:33 PM
>To: Jean St-Laurent 
>Cc: 'brad dreisbach' ; 'Phil Bedard' 
>; 'North American Network Operators' Group' 
>
>Subject: Re: uPRF strict more
>
>On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
>>Hi Brad,
>>
>>I'd be interested to hear more about this pps penalty. Do we talk about 5% 
>>penalty or something closer to 50%?
>>
>>Let me know if you still have some numbers close to you related to PPS with 
>>uRPF loose.
>
>iirc, strict vs loose doesnt matter, its still an extra lookup which effects 
>the performance. i was able to find some numbers to give an example.
>
>the 4x100G tomahawk card was able to pass min frame size(which iirc on 
>ixia is
>80B) at line rate with no features enabled. turn on uRPF and it is only able 
>to pass 208B frames at line rate.
>
>similar results were seen with several generations of cisco and juniper line 
>cards(if i tested nokia i cant recall, we had stopped doing urpf when they 
>were introduced into the network).
>
>-b
>

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong  wrote:

>
>
> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
>
> 
>
>
> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
> wrote:
>
>> Use SLAAC, allocate prefixes from both providers. If you are using
>> multiple routers, set the priority of the preferred router to high in the
>> RAs. If you’re using one router, set the preferred prefix as desired in the
>> RAs.
>>
>> Owen
>>
>
> I agree this works, but I assume that we would not consider this a
> consumer level solution (requires an administrator to make it work).  It
> also assumes the local network policy allows for auto-addressing vs.
> requirement for DHCP.
>
>
> It shouldn’t require an administrator if there’s just one router. If there
> are two routers, I’d say we’re beyond the average consumer.
>

In the consumer world (Where a consumer has no idea who we are, what IP is
and the Internet is a wireless thing they attach to).

I am only considering one router (consumer level stuff).  Here is my
example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
local cable service and/or DSL service, and/or xPON service
- Both providers have IPv6 (competing in the market so don't cooperate on
how to address, manage customer homes)
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything
anything else technical (typical consumer); They only knows how to walk
into a store and buy a random thing off the shelf and ask for "WiFi".
- Both providers provide IPv6 and delegate a prefix to the router (let's
pretend the retail staff knew enough to sell this person a consumer box
with 2x WAN interfaces)
- Lets also assume the cable boxes have a consumer actionable way to force
R1483 mode, and assume the DSL device can do the same (I know many
providers that don't allow this type of configuration)
- So this dual WAN (retail) device now has one Public IPv4 address per WAN
interface (assuming one or both of the services was not disallowing
bridging mode, in which case its a Private address on one or both of the
WAN interfaces)
- this dual wan device also gets a PD from both upstream providers which
delegates to the CPE

I will ignore the dual router case as that normally looks very ugly in
networks as customers typically don't hook that up correctly (normally hook
one box in behind the first, not in parallel).   Do we think this use case
just works today?  Can we say we are confident we know how this all pans
out in real production?  e.g. CPE only uses one PD? uses both?  does all
the right things to support SLAAC downstream?

I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what
happens and normally the consumer has no clue what's going on and the
router just deals with it. For the IPv6 side, I am not yet confident this
is all just working yet.  I would like to be wrong.  I can say - in my
consumer mode in the US - this example above is not working by default. (I
won't out the providers of course).  I want the answer to be different, but
there is still more work to do (especially since dual provider has become
much more common due to work from home).

regards,

Victor K







>
> I have had IPv6 in my home for a long time now using multiple providers,
> but it definitely works with high touch admin.  I don't see this as a
> barrier to deploy IPv6 though (don't read that into my response).  But IPv6
> still has a few corner cases that require some TLC.
>
>
> It’s not high touch in my environment, but my environment goes way beyond
> consumer and involves ARIN assigned GUA and BGP.
>
> Not every home is the same.
>
> Owen
>
>
> regards,
>
> Victor K
>
>
>
>
>
>
>>
>>
>> On Sep 29, 2021, at 07:35, Christopher Morrow 
>> wrote:
>>
>> 
>>
>>
>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>>
>>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>>
>>> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
>>> routing and NATing however I want..
>>>
>>>
>> why of COURSE you do source address selection!
>> so simple!
>>
>>
>>>
>>> -- Original message --
>>>
>>> From: Mark Andrews 
>>> To: b...@uu3.net
>>> Cc: nanog@nanog.org
>>> Subject: Re: IPv6 woes - RFC
>>> Date: Wed, 29 Sep 2021 00:28:40 +1000
>>>
>>>
>>>
>>> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
>>> >
>>> > Heh, NAT is not that evil after all. Do you expect that all the home
>>> > people will get routable public IPs for all they toys inside house?
>>>
>>> Yes! Remember routable does not mean that it is reachable from outside.
>>>
>>> > And if they change ISP they will get new range?
>>>
>>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>>> get for RIRs are based on handing out multiple /64 to every customer.
>>>
>>> > Doesnt sounds nice to me.. But I guess I its just me
>>>
>>> It sounds like you need to do some reading about IPv6, then actually
>>> use it.  100s o

RE: uPRF strict more

[Jean St-Laurent via NANOG]

Thanks a lot for sharing.

So 100 Gbps at line rate with 80B frames is about ~150 Mpps.

100 Gbps at line rate with 208B frames is about ~60 Mpps.

It's a significant penalty.

Jean

-Original Message-
From: brad dreisbach  
Sent: September 29, 2021 3:33 PM
To: Jean St-Laurent 
Cc: 'brad dreisbach' ; 'Phil Bedard' ; 
'North American Network Operators' Group' 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:
>Hi Brad,
>
>I'd be interested to hear more about this pps penalty. Do we talk about 5% 
>penalty or something closer to 50%?
>
>Let me know if you still have some numbers close to you related to PPS with 
>uRPF loose.

iirc, strict vs loose doesnt matter, its still an extra lookup which effects 
the performance. i was able to find some numbers to give an example.

the 4x100G tomahawk card was able to pass min frame size(which iirc on ixia is
80B) at line rate with no features enabled. turn on uRPF and it is only able to 
pass 208B frames at line rate.

similar results were seen with several generations of cisco and juniper line 
cards(if i tested nokia i cant recall, we had stopped doing urpf when they were 
introduced into the network).

-b

Re: IPv6 woes - RFC

[Michael Thomas]

On 9/29/21 12:22 PM, Owen DeLong via NANOG wrote:




On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:




On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
mailto:nanog@nanog.org>> wrote:


Use SLAAC, allocate prefixes from both providers. If you are
using multiple routers, set the priority of the preferred router
to high in the RAs. If you’re using one router, set the preferred
prefix as desired in the RAs.

Owen


I agree this works, but I assume that we would not consider this a 
consumer level solution (requires an administrator to make it work).  
It also assumes the local network policy allows for auto-addressing 
vs. requirement for DHCP.


It shouldn’t require an administrator if there’s just one router. If 
there are two routers, I’d say we’re beyond the average consumer.



I think the multiple router problem is one of the things that homenet 
was supposed to be solving for such that it is plug and play. But I 
share some of your skepticism.


I wonder if anybody has run an experiment wider than one or two people 
where the home router implements a 6-4 NAT and the default numbering is 
v6 instead of v4. That is, run everything that can run on v6 and NAT it 
to v4 on the wan side (assuming there isn't v6 there). There are lots of 
v6 stacks out there for all of the common OS's and supposedly they 
prefer v6 in a happy eyeballs race. I mean, if we have to NAT why not v6 
NAT the devices that support it and v4 NAT the ones that can't.


I'm not sure if Cablelabs is active with v6 -- last I heard they were 
pushing v6, but that's been ages -- but that would really put their 
money where their mouth is if it really worked well at scale. It would 
also give some incentive to have v6 in the last mile so you don't even 
need the 6-4 NAT. Didn't somebody like Comcast go to a complete v6 
network internally to simplify their network? That sounds like it would 
push the simplification even farther.


Mike

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 02:54:43PM -0400, Jean St-Laurent wrote:

Hi Brad,

I'd be interested to hear more about this pps penalty. Do we talk about 5% 
penalty or something closer to 50%?

Let me know if you still have some numbers close to you related to PPS with 
uRPF loose.


iirc, strict vs loose doesnt matter, its still an extra lookup which effects
the performance. i was able to find some numbers to give an example.

the 4x100G tomahawk card was able to pass min frame size(which iirc on ixia is
80B) at line rate with no features enabled. turn on uRPF and it is only able to
pass 208B frames at line rate.

similar results were seen with several generations of cisco and juniper
line cards(if i tested nokia i cant recall, we had stopped doing urpf
when they were introduced into the network).

-b




Thanks
Jean


-Original Message-
From: NANOG  On Behalf Of brad 
dreisbach
Sent: September 29, 2021 2:35 PM
To: Phil Bedard 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.


uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually end up 
turning it off(for good this last time, probably).

-b



Phil

From: NANOG  on behalf
of Adam Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  on behalf
of Amir Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you
could sum up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
> 
> 
> 
> 
>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG  
>> wrote:
>> Use SLAAC, allocate prefixes from both providers. If you are using multiple 
>> routers, set the priority of the preferred router to high in the RAs. If 
>> you’re using one router, set the preferred prefix as desired in the RAs. 
>> 
>> Owen
> 
> I agree this works, but I assume that we would not consider this a consumer 
> level solution (requires an administrator to make it work).  It also assumes 
> the local network policy allows for auto-addressing vs. requirement for DHCP. 
>  

It shouldn’t require an administrator if there’s just one router. If there are 
two routers, I’d say we’re beyond the average consumer. 

> I have had IPv6 in my home for a long time now using multiple providers, but 
> it definitely works with high touch admin.  I don't see this as a barrier to 
> deploy IPv6 though (don't read that into my response).  But IPv6 still has a 
> few corner cases that require some TLC.

It’s not high touch in my environment, but my environment goes way beyond 
consumer and involves ARIN assigned GUA and BGP. 

Not every home is the same. 

Owen

> 
> regards,
> 
> Victor K
> 
> 
> 
> 
>  
>> 
>> 
 On Sep 29, 2021, at 07:35, Christopher Morrow  
 wrote:
 
>>> 
>>> 
>>> 
 On Wed, Sep 29, 2021 at 4:39 AM  wrote:
 Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
 
 Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
 routing and NATing however I want..
 
>>> 
>>> why of COURSE you do source address selection!
>>> so simple!
>>>  
 
 -- Original message --
 
 From: Mark Andrews 
 To: b...@uu3.net
 Cc: nanog@nanog.org
 Subject: Re: IPv6 woes - RFC
 Date: Wed, 29 Sep 2021 00:28:40 +1000
 
 
 
 > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
 > 
 > Heh, NAT is not that evil after all. Do you expect that all the home
 > people will get routable public IPs for all they toys inside house?
 
 Yes! Remember routable does not mean that it is reachable from outside.
 
 > And if they change ISP they will get new range?
 
 Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
 has only been specified for 18 years now.  The IPv6 address ranges ISP
 get for RIRs are based on handing out multiple /64 to every customer.
 
 > Doesnt sounds nice to me.. But I guess I its just me
 
 It sounds like you need to do some reading about IPv6, then actually
 use it.  100s of millions of home customers are get routable IPv6 prefixes
 today around the world.  It's not scary.  Things don˙˙t blow up.
 
 > Yeah I am aware of putting additional aliases on loopback.
 > 
 > No futher comment about ND and DHCP.
 > 
 > Well, at a time when TCP/IP was invented, 32bit address space looked
 > pretty much big... I dont blame them than they didnt predicted future..
 > Unfortunately, cant say the same about IPv6 R&D taskforce ;)
 > 
 > Hah, multicast... Ill skip it.
 > 
 > Followed change to support CIDR, Internet was still small and considered
 > R&D field...
 > 
 > Okey, I think its no need to futher pollute NANOG list with this.
 > I said at the begining that this is just my subjective opinion.
 > This will not help IPv6 case at all.
 > 
 > At least from my (2) standpoint it would be really cool that IPv6
 > would be finally addopted.
 > 
 > I just wanted to share my toughts about why im not big fan of IPv6.
 > I also wanted to hear other opinions what they dislike about it, no
 > list of how cool IPv6 is and how everyone should use it right away.
 > 
 > 
 > -- Original message --
 > 
 > From: Owen DeLong 
 > To: b...@uu3.net
 > Cc: nanog@nanog.org
 > Subject: Re: IPv6 woes - RFC
 > Date: Sat, 25 Sep 2021 12:01:22 -0700
 > 
 > 
 > 
 >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
 >> 
 >> Well, I think we should not compare IPX to IPv4 because those protocols
 >> were made to handle completly different networks?
 >> 
 >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
 >> 
 >> Well, Industry seems to addapt things quickly when they are good enough.
 >> Better things replace worse. Of course its not always the case, 
 >> sometimes
 >> things are being forced here.. And thats how I feel about IPv6..
 > 
 > Sometimes worse things replace better. NAT, for example was definitely 
 > not
 > an improvement to IPv4. It was a necessary evil intended to be a 
 > temporary
 > fix.
 > 
 >> 
 >> IPv4 Lookback is 127.0.0.1/8
 >> You can use bind IPs within range by applications. Handy
 >> In IPv6 its not the case.
 > 
 > Yo

RE: uPRF strict more

[Jean St-Laurent via NANOG]

Hi Brad,

I'd be interested to hear more about this pps penalty. Do we talk about 5% 
penalty or something closer to 50%? 

Let me know if you still have some numbers close to you related to PPS with 
uRPF loose.

Thanks
Jean


-Original Message-
From: NANOG  On Behalf Of brad 
dreisbach
Sent: September 29, 2021 2:35 PM
To: Phil Bedard 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:
>Disclosure I work for Cisco and try to look after some of their peering 
>guidelines.
>
>Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
>elsewhere on the network eventually is going to cause some issue and its 
>usefulness today is almost nil.  That being said we still see large providers 
>who have it turned on for peering/transit interfaces either out of legacy 
>configuration or other reasons.  The vast majority do not use it for those 
>interface roles.

uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually end up 
turning it off(for good this last time, probably).

-b

>
>Phil
>
>From: NANOG  on behalf 
>of Adam Thompson 
>Date: Wednesday, September 29, 2021 at 1:08 PM
>To: Amir Herzberg , Randy Bush 
>Cc: North American Network Operators' Group 
>Subject: Re: uPRF strict more
>We just ran into a typical case where uRPF caused a partial outage for one of 
>my customers: the customer is multi-homed, with another provider that I'm 
>also​ connected to.  Customer advertised a longer-prefix to the other guy, so 
>I started sending traffic destined for Customer to the Other Provider... who 
>then promptly dropped it because they had uRPF enabled on the peering link, 
>and they were seeing random source IPs that weren't mine.  Well... yeah, that 
>can happen (semi-legitimately) anytime you have a topological triangle in 
>peering.
>
>I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
>pointing directly at non-multi-homed customers, and actively dangerous 
>anywhere else.
>
>-Adam
>
>Adam Thompson
>Consultant, Infrastructure Services
>[1593169877849]
>100 - 135 Innovation Drive
>Winnipeg, MB, R3T 6A8
>(204) 977-6824 or 1-800-430-6404 (MB only) 
>athomp...@merlin.mb.ca
>www.merlin.mb.ca
>
>From: NANOG  on behalf 
>of Amir Herzberg 
>Sent: September 28, 2021 20:06
>To: Randy Bush 
>Cc: North American Network Operators' Group 
>Subject: Re: uPRF strict more
>
>Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
>to high potential for benign loss); it's always great to be either confirmed 
>or corrected...
>
>So if anyone replies just to Randy - pls cc me too (or, Randy, if you 
>could sum up and send to list or me - thanks!)
>
>Amir
>--
>Amir Herzberg
>
>Comcast professor of Security Innovations, Computer Science and 
>Engineering, University of Connecticut
>Homepage: https://sites.google.com/site/amirherzberg/home
>`Applied Introduction to Cryptography' textbook and lectures: 
>https://sites.google.com/site/amirherzberg/applied-crypto-textbooks://sites.google.com/site/amirherzberg/applied-crypto-textbook>
>
>
>
>
>On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
>mailto:ra...@psg.com>> wrote:
>do folk use uPRF strict mode?  i always worried about the multi-homed 
>customer sending packets out the other way which loop back to me;  see 
>RFC 8704 §2.2
>
>do vendors implement the complexity of 8704; and, if so, do operators 
>use it?
>
>clue bat please
>
>randy

Re: uPRF strict more

[brad dreisbach]

On Wed, Sep 29, 2021 at 06:14:21PM +, Phil Bedard wrote:

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.


uRPF incurs a quite severe pps penalty on all of the NPUs i've ever tested.
we have dabbled with it many times over the years and always eventually
end up turning it off(for good this last time, probably).

-b



Phil

From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Phil Bedard]

Disclosure I work for Cisco and try to look after some of their peering 
guidelines.

Agree with Adam’s statement, use uRPF on edge DIA customers.  Using it 
elsewhere on the network eventually is going to cause some issue and its 
usefulness today is almost nil.  That being said we still see large providers 
who have it turned on for peering/transit interfaces either out of legacy 
configuration or other reasons.  The vast majority do not use it for those 
interface roles.

Phil

From: NANOG  on behalf of Adam 
Thompson 
Date: Wednesday, September 29, 2021 at 1:08 PM
To: Amir Herzberg , Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more
We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: uPRF strict more

[Adam Thompson]

We just ran into a typical case where uRPF caused a partial outage for one of 
my customers: the customer is multi-homed, with another provider that I'm also​ 
connected to.  Customer advertised a longer-prefix to the other guy, so I 
started sending traffic destined for Customer to the Other Provider... who then 
promptly dropped it because they had uRPF enabled on the peering link, and they 
were seeing random source IPs that weren't mine.  Well... yeah, that can happen 
(semi-legitimately) anytime you have a topological triangle in peering.

I've concluded over the last 2 years that uRPF is only​ useful on interfaces 
pointing directly at non-multi-homed customers, and actively dangerous anywhere 
else.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  on behalf of Amir 
Herzberg 
Sent: September 28, 2021 20:06
To: Randy Bush 
Cc: North American Network Operators' Group 
Subject: Re: uPRF strict more

Randy, great question. I'm teaching that it's very rarely, if ever, used (due 
to high potential for benign loss); it's always great to be either confirmed or 
corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could sum 
up and send to list or me - thanks!)

Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures: 
https://sites.google.com/site/amirherzberg/applied-crypto-textbook




On Tue, Sep 28, 2021 at 8:50 PM Randy Bush 
mailto:ra...@psg.com>> wrote:
do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
wrote:

> Use SLAAC, allocate prefixes from both providers. If you are using
> multiple routers, set the priority of the preferred router to high in the
> RAs. If you’re using one router, set the preferred prefix as desired in the
> RAs.
>
> Owen
>

I agree this works, but I assume that we would not consider this a consumer
level solution (requires an administrator to make it work).  It also
assumes the local network policy allows for auto-addressing vs. requirement
for DHCP.

I have had IPv6 in my home for a long time now using multiple providers,
but it definitely works with high touch admin.  I don't see this as a
barrier to deploy IPv6 though (don't read that into my response).  But IPv6
still has a few corner cases that require some TLC.

regards,

Victor K






>
>
> On Sep 29, 2021, at 07:35, Christopher Morrow 
> wrote:
>
> 
>
>
> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>
>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>
>> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
>> routing and NATing however I want..
>>
>>
> why of COURSE you do source address selection!
> so simple!
>
>
>>
>> -- Original message --
>>
>> From: Mark Andrews 
>> To: b...@uu3.net
>> Cc: nanog@nanog.org
>> Subject: Re: IPv6 woes - RFC
>> Date: Wed, 29 Sep 2021 00:28:40 +1000
>>
>>
>>
>> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
>> >
>> > Heh, NAT is not that evil after all. Do you expect that all the home
>> > people will get routable public IPs for all they toys inside house?
>>
>> Yes! Remember routable does not mean that it is reachable from outside.
>>
>> > And if they change ISP they will get new range?
>>
>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>> get for RIRs are based on handing out multiple /64 to every customer.
>>
>> > Doesnt sounds nice to me.. But I guess I its just me
>>
>> It sounds like you need to do some reading about IPv6, then actually
>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>> today around the world.  It's not scary.  Things don˙˙t blow up.
>>
>> > Yeah I am aware of putting additional aliases on loopback.
>> >
>> > No futher comment about ND and DHCP.
>> >
>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>> > pretty much big... I dont blame them than they didnt predicted future..
>> > Unfortunately, cant say the same about IPv6 R&D taskforce ;)
>> >
>> > Hah, multicast... Ill skip it.
>> >
>> > Followed change to support CIDR, Internet was still small and considered
>> > R&D field...
>> >
>> > Okey, I think its no need to futher pollute NANOG list with this.
>> > I said at the begining that this is just my subjective opinion.
>> > This will not help IPv6 case at all.
>> >
>> > At least from my (2) standpoint it would be really cool that IPv6
>> > would be finally addopted.
>> >
>> > I just wanted to share my toughts about why im not big fan of IPv6.
>> > I also wanted to hear other opinions what they dislike about it, no
>> > list of how cool IPv6 is and how everyone should use it right away.
>> >
>> >
>> > -- Original message --
>> >
>> > From: Owen DeLong 
>> > To: b...@uu3.net
>> > Cc: nanog@nanog.org
>> > Subject: Re: IPv6 woes - RFC
>> > Date: Sat, 25 Sep 2021 12:01:22 -0700
>> >
>> >
>> >
>> >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
>> >>
>> >> Well, I think we should not compare IPX to IPv4 because those protocols
>> >> were made to handle completly different networks?
>> >>
>> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> >>
>> >> Well, Industry seems to addapt things quickly when they are good
>> enough.
>> >> Better things replace worse. Of course its not always the case,
>> sometimes
>> >> things are being forced here.. And thats how I feel about IPv6..
>> >
>> > Sometimes worse things replace better. NAT, for example was definitely
>> not
>> > an improvement to IPv4. It was a necessary evil intended to be a
>> temporary
>> > fix.
>> >
>> >>
>> >> IPv4 Lookback is 127.0.0.1/8
>> >> You can use bind IPs within range by applications. Handy
>> >> In IPv6 its not the case.
>> >
>> > You are free to assign any additional IPv6 addresses you like to the
>> loopback
>> > interface and then bind them to applications. Personally, I haven˙˙t
>> found a
>> > particularly good use for this, but it is possible.
>> >
>> > It does mean that instead of wasting 1/256th of the entire address space
>> > in every context on loopbacks, you have to assign what you need there,
>> > but you can easily assign a /64 prefix to a loopback interface and have
>> > applications bind within range.
>> >
>> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
>> >
>> > Table overflows weren˙˙t fixe

Re: uPRF strict more

[Blake Hudson]

On 9/29/2021 9:27 AM, Mark Tinka wrote:


On 9/29/21 16:21, Blake Hudson wrote:
I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.


On peering and transit routers, on ports facing the remote side, we 
apply ACL's to drop traffic inbound from reserved space, as well as 
our own (as we shouldn't see it coming in from the outside).


It's amazing how many matches we see, for all space, both IPv4 and 
IPv6. Tells just how open some of the "major" networks are :-).


Ditto. And ditto.

Extended IP access list ACL-TRANSIT-IN
    ...
    160 deny ip host 0.0.0.0 any
    170 deny ip 127.0.0.0 0.255.255.255 any
    180 deny ip 224.0.0.0 15.255.255.255 any
    190 deny ip 240.0.0.0 15.255.255.255 any
    200 deny ip 10.0.0.0 0.255.255.255 any (91057035 matches)
    210 deny ip 172.16.0.0 0.15.255.255 any (1366408 matches)
    220 deny ip 192.168.0.0 0.0.255.255 any (18325538 matches)
    230 deny ip 169.254.0.0 0.0.255.255 any (146523 matches)
    ...

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

Use SLAAC, allocate prefixes from both providers. If you are using multiple 
routers, set the priority of the preferred router to high in the RAs. If you’re 
using one router, set the preferred prefix as desired in the RAs. 

Owen


> On Sep 29, 2021, at 07:35, Christopher Morrow  wrote:
> 
> 
> 
> 
>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>> 
>> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
>> routing and NATing however I want..
>> 
> 
> why of COURSE you do source address selection!
> so simple!
>  
>> 
>> -- Original message --
>> 
>> From: Mark Andrews 
>> To: b...@uu3.net
>> Cc: nanog@nanog.org
>> Subject: Re: IPv6 woes - RFC
>> Date: Wed, 29 Sep 2021 00:28:40 +1000
>> 
>> 
>> 
>> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
>> > 
>> > Heh, NAT is not that evil after all. Do you expect that all the home
>> > people will get routable public IPs for all they toys inside house?
>> 
>> Yes! Remember routable does not mean that it is reachable from outside.
>> 
>> > And if they change ISP they will get new range?
>> 
>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>> get for RIRs are based on handing out multiple /64 to every customer.
>> 
>> > Doesnt sounds nice to me.. But I guess I its just me
>> 
>> It sounds like you need to do some reading about IPv6, then actually
>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>> today around the world.  It's not scary.  Things don˙˙t blow up.
>> 
>> > Yeah I am aware of putting additional aliases on loopback.
>> > 
>> > No futher comment about ND and DHCP.
>> > 
>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>> > pretty much big... I dont blame them than they didnt predicted future..
>> > Unfortunately, cant say the same about IPv6 R&D taskforce ;)
>> > 
>> > Hah, multicast... Ill skip it.
>> > 
>> > Followed change to support CIDR, Internet was still small and considered
>> > R&D field...
>> > 
>> > Okey, I think its no need to futher pollute NANOG list with this.
>> > I said at the begining that this is just my subjective opinion.
>> > This will not help IPv6 case at all.
>> > 
>> > At least from my (2) standpoint it would be really cool that IPv6
>> > would be finally addopted.
>> > 
>> > I just wanted to share my toughts about why im not big fan of IPv6.
>> > I also wanted to hear other opinions what they dislike about it, no
>> > list of how cool IPv6 is and how everyone should use it right away.
>> > 
>> > 
>> > -- Original message --
>> > 
>> > From: Owen DeLong 
>> > To: b...@uu3.net
>> > Cc: nanog@nanog.org
>> > Subject: Re: IPv6 woes - RFC
>> > Date: Sat, 25 Sep 2021 12:01:22 -0700
>> > 
>> > 
>> > 
>> >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
>> >> 
>> >> Well, I think we should not compare IPX to IPv4 because those protocols
>> >> were made to handle completly different networks?
>> >> 
>> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> >> 
>> >> Well, Industry seems to addapt things quickly when they are good enough.
>> >> Better things replace worse. Of course its not always the case, sometimes
>> >> things are being forced here.. And thats how I feel about IPv6..
>> > 
>> > Sometimes worse things replace better. NAT, for example was definitely not
>> > an improvement to IPv4. It was a necessary evil intended to be a temporary
>> > fix.
>> > 
>> >> 
>> >> IPv4 Lookback is 127.0.0.1/8
>> >> You can use bind IPs within range by applications. Handy
>> >> In IPv6 its not the case.
>> > 
>> > You are free to assign any additional IPv6 addresses you like to the 
>> > loopback
>> > interface and then bind them to applications. Personally, I haven˙˙t found 
>> > a
>> > particularly good use for this, but it is possible.
>> > 
>> > It does mean that instead of wasting 1/256th of the entire address space
>> > in every context on loopbacks, you have to assign what you need there,
>> > but you can easily assign a /64 prefix to a loopback interface and have
>> > applications bind within range.
>> > 
>> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
>> > 
>> > Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
>> > ARP. Table overflows are (not really an issue in my experience) the
>> > result of a larger address space than the memory available for the L2
>> > forwarding table on switches or the ND table on hosts. This isn˙˙t due
>> > to a difference in ND vs. ARP. It is due to the fact that there are no
>> > 64-bit networks in IPv4, but they are commonplace in IPv6.
>> > 
>> > Mostly this has been solved in software by managing table discards more
>> > effectively.
>> > 
>> >> IPv6 DHCP: Im not using IPv6, but I heard ppl talking

Re: IPv6 woes - RFC

[Christopher Morrow]

On Wed, Sep 29, 2021 at 4:39 AM  wrote:

> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>
> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
> routing and NATing however I want..
>
>
why of COURSE you do source address selection!
so simple!


>
> -- Original message --
>
> From: Mark Andrews 
> To: b...@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Wed, 29 Sep 2021 00:28:40 +1000
>
>
>
> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
> >
> > Heh, NAT is not that evil after all. Do you expect that all the home
> > people will get routable public IPs for all they toys inside house?
>
> Yes! Remember routable does not mean that it is reachable from outside.
>
> > And if they change ISP they will get new range?
>
> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
> has only been specified for 18 years now.  The IPv6 address ranges ISP
> get for RIRs are based on handing out multiple /64 to every customer.
>
> > Doesnt sounds nice to me.. But I guess I its just me
>
> It sounds like you need to do some reading about IPv6, then actually
> use it.  100s of millions of home customers are get routable IPv6 prefixes
> today around the world.  It's not scary.  Things don˙˙t blow up.
>
> > Yeah I am aware of putting additional aliases on loopback.
> >
> > No futher comment about ND and DHCP.
> >
> > Well, at a time when TCP/IP was invented, 32bit address space looked
> > pretty much big... I dont blame them than they didnt predicted future..
> > Unfortunately, cant say the same about IPv6 R&D taskforce ;)
> >
> > Hah, multicast... Ill skip it.
> >
> > Followed change to support CIDR, Internet was still small and considered
> > R&D field...
> >
> > Okey, I think its no need to futher pollute NANOG list with this.
> > I said at the begining that this is just my subjective opinion.
> > This will not help IPv6 case at all.
> >
> > At least from my (2) standpoint it would be really cool that IPv6
> > would be finally addopted.
> >
> > I just wanted to share my toughts about why im not big fan of IPv6.
> > I also wanted to hear other opinions what they dislike about it, no
> > list of how cool IPv6 is and how everyone should use it right away.
> >
> >
> > -- Original message --
> >
> > From: Owen DeLong 
> > To: b...@uu3.net
> > Cc: nanog@nanog.org
> > Subject: Re: IPv6 woes - RFC
> > Date: Sat, 25 Sep 2021 12:01:22 -0700
> >
> >
> >
> >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
> >>
> >> Well, I think we should not compare IPX to IPv4 because those protocols
> >> were made to handle completly different networks?
> >>
> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
> >>
> >> Well, Industry seems to addapt things quickly when they are good enough.
> >> Better things replace worse. Of course its not always the case,
> sometimes
> >> things are being forced here.. And thats how I feel about IPv6..
> >
> > Sometimes worse things replace better. NAT, for example was definitely
> not
> > an improvement to IPv4. It was a necessary evil intended to be a
> temporary
> > fix.
> >
> >>
> >> IPv4 Lookback is 127.0.0.1/8
> >> You can use bind IPs within range by applications. Handy
> >> In IPv6 its not the case.
> >
> > You are free to assign any additional IPv6 addresses you like to the
> loopback
> > interface and then bind them to applications. Personally, I haven˙˙t
> found a
> > particularly good use for this, but it is possible.
> >
> > It does mean that instead of wasting 1/256th of the entire address space
> > in every context on loopbacks, you have to assign what you need there,
> > but you can easily assign a /64 prefix to a loopback interface and have
> > applications bind within range.
> >
> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
> >
> > Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> > ARP. Table overflows are (not really an issue in my experience) the
> > result of a larger address space than the memory available for the L2
> > forwarding table on switches or the ND table on hosts. This isn˙˙t due
> > to a difference in ND vs. ARP. It is due to the fact that there are no
> > 64-bit networks in IPv4, but they are commonplace in IPv6.
> >
> > Mostly this has been solved in software by managing table discards more
> > effectively.
> >
> >> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some
> >> issues. If this is not the case, im sorry. Its been a while when I last
> time
> >> played with IPv6...
> >
> > I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any
> significant
> > problems with it other than some minor inconveniences introduced by the
> ability
> > to have different DUID types and vendors doing semi-obnoxious things
> along that
> > line.
> >
> >> IPv6 interop: yeah, I agree here.. But people involved with IP

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 16:21, Blake Hudson wrote:

I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.


On peering and transit routers, on ports facing the remote side, we 
apply ACL's to drop traffic inbound from reserved space, as well as our 
own (as we shouldn't see it coming in from the outside).


It's amazing how many matches we see, for all space, both IPv4 and IPv6. 
Tells just how open some of the "major" networks are :-).


Mark.

Re: IPv6 woes - RFC

[Christopher Morrow]

On Tue, Sep 28, 2021 at 4:18 PM Randy Bush  wrote:

> >> the ietf did not give guidance to cpe vendors to protect toys inside
> >> your LAN
> > guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is
> > likely to impact all of our security 'requirements'. :(
>
> that point was made in the paper i cited
>

"This is a preview of subscription content, log in

to
check access."
  

I can see a wierdo looking image with 'port scan data', which roughly seems
to say:
  "Hey, turn on the firewall"
on all of their tested devices... and what look like 'cablelabs affiliates'
mostly did
the right thing with that fw policy.


> > I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was
> > supposed to have provided the guidance you seek here?
>
> got a cite for the guidance?
>
>
sure, that's in the referenced architecture document from your link
(one of the other few things I can see is the references section):
  3. Chown, T., Arkko, J., Brandt, A., Troan, O., Weil, J.: IPv6 home
networking
 architecture principles. RFC 7368, Internet Engineering Task Force
(October 2014)

The points about NAT in v4 being 'helpful' are sort of right, but the
attacks just
move up the stack[0] :( so I don't think it's particularly germaine to
worry/not about nat
for 'security' purposes.

-chris

0: https://us.norton.com/internetsecurity-malware-malvertising.html
(NOTE: I'm not a fan of norton nor any AV really, but.. the article
makes the
'up the stack' point)

Re: uPRF strict more

[Blake Hudson]

As an eyeball network operator (Cable, DSL, Fiber) we use uRPF strict 
mode on customer facing ports on the BRAS gear. Our access gear also 
tends to include source address verification via DHCP snooping (as well 
as limits on the number of DHCP leases and/or MAC addresses each 
customer is allowed) so there are a couple layers of protection.


I do not use uRPF on upstream/transit/IX links or with multi-homed 
customers - or anywhere else where traffic could be asymmetrical; I 
prefer to use stateless ACLs at these locations.




On 9/28/2021 8:06 PM, Amir Herzberg wrote:
Randy, great question. I'm teaching that it's very rarely, if ever, 
used (due to high potential for benign loss); it's always great to be 
either confirmed or corrected...


So if anyone replies just to Randy - pls cc me too (or, Randy, if you 
could sum up and send to list or me - thanks!)


Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and 
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home 

`Applied Introduction to Cryptography' textbook and 
lectures: https://sites.google.com/site/amirherzberg/applied-crypto-textbook 






On Tue, Sep 28, 2021 at 8:50 PM Randy Bush > wrote:


do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Re: Identifying submarine links via traceroute

[Mark Tinka]

On 9/29/21 15:14, Dave Cohen wrote:

As Mark says YMMV as different providers will have markedly different 
conventions, however one additional challenge that will be widespread 
is that most carriers are not placing their L2/3 hardware in the cable 
landing stations, preferring instead to extend from the CLS to more 
centralized POP locations via Layer 1. So what you will see between a 
city pair like Tokyo-Seattle, which very obviously will require some 
wet capacity, will actually be some combination of wet and 
terrestrial. Between the terrestrial extensions and L2/3 overhead it 
would be difficult to determine exactly what the underlying cable(s) 
are even if you had a good idea of what the CLS to CLS latency was.


And with new cables being built (largely by the content folk), CLS-CLS 
termination is no longer in favour. New cables are now being extended 
into city data centres as an "informal" standard, because the content 
folk are not interested in dealing with CLS politics, especially for 
cables where they may collaborate with regular network operators, to 
some extent.


Even though the C2C cable stood for "city-to-city", it wasn't a true 
city to city cable. Some of the most recent cable builds (I'm talking in 
the last 1.5 - 2 years) have been the ones mandating SLTE's are deployed 
at carrier-neutral data centres, and not at the CLS. The CLS is just to 
house the PFE (power feeding equipment).


Mark.

Re: Admin for .tk (not a spam/abuse complaint!)

[Jeroen Massar via NANOG]

On 2021-09-29 01:03, Tim Harman via NANOG wrote:
[..]

{11:58}~ ➭ dig @194.0.41.1 test.tk

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @194.0.41.1 test.tk
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached


A traceroute with a source IP would be sooo useful.

Also, don't forget to check things like RIPE ATLAS, or join NLNOG RING 
to be able to determine where you might have connectivity issues.


Greets,
 Jeroen

Re: Identifying submarine links via traceroute

[Dave Cohen]

As Mark says YMMV as different providers will have markedly different
conventions, however one additional challenge that will be widespread is
that most carriers are not placing their L2/3 hardware in the cable landing
stations, preferring instead to extend from the CLS to more centralized POP
locations via Layer 1. So what you will see between a city pair like
Tokyo-Seattle, which very obviously will require some wet capacity, will
actually be some combination of wet and terrestrial. Between the
terrestrial extensions and L2/3 overhead it would be difficult to determine
exactly what the underlying cable(s) are even if you had a good idea of
what the CLS to CLS latency was.

At a previous $dayjob, for example, we had both 100% terrestrial and
partially wet links in use to connect our core POPs in Seattle and
Vancouver directly. While at the Layer 1 level, the wet link had about a
20% longer optical distance, the distance was short enough that a trace
would generally return 3 or 4 ms between core nodes pretty much
irrespective of the situation (and the trunks terminated into the same
routers in the core anyway, which is a whole other story), so it would have
been impossible to tell which path was used even though I knew exactly what
the backbone architecture looked like.

Again, YMMV as different providers will have different standards and
different city pairs will be easier to determine than others, but there is
no "use this one weird trick" rule here.

On Wed, Sep 29, 2021 at 8:50 AM Mark Tinka  wrote:

>
>
> On 9/29/21 04:23, PAUL R BARFORD wrote:
>
> Hello,
>
> I am a researcher at the University of Wisconsin.  My colleagues at
> Northwestern University and I are studying submarine cable infrastructure.
>
> Our interest is in identifying submarine links in traceroute
> measurements.  Specifically, for a given end-to-end traceroute measurement,
> we would like to be able to identify when two hops are separated by a
> submarine cable.  Our initial focus has been on inter-hop latency, which
> can expose long links.  The challenge is that terrestrial long-haul links
> may have the same or longer link latencies as short submarine links. So,
> we're interested in whether there may be other features (e.g., persistent
> congestion, naming conventions in router interfaces, peering details, etc.)
> or techniques that would indicate submarine links.
>
> Any thoughts or insights you might have would be greatly appreciated -
> off-list responses are welcome.
>
>
> Back in the day, when submarine cables were not as rife, it was not
> uncommon to see things like "FLAG" or "APCN-2" or "SMW-3" in traceroutes. I
> haven't seen such in a very long time, but likely some operators may still
> do this.
>
> For traceroutes that cross oceans visibly, e.g., lhr-jfk, mrs-mba,
> hnd-lax, mru - cdg, e.t.c., you could glean from there. But many operators
> do not follow any "common norm" to annotate things like this, so YMMV.
>
> You also find some countries that will use a submarine festoon either as a
> primary or backup route for a terrestrial link. In such cases, the
> distances may be the same, or even shorter across the festoon, e.g.,
> consider a festoon cable between Cape Town - Durban, vs. a land-based run
> for the same two points.
>
> Considering how wide-spread submarine links are for both short and long
> spans, I think folk are simply treating them as any other link, from an
> operational perspective. You may be able to come up with a semi-automatic
> mechanism to measure this, but I fear without deliberate and consistent
> human intervention, the data could get stale very quickly.
>
> Mark.
>


-- 
- Dave Cohen
craetd...@gmail.com
@dCoSays
www.venicesunlight.com

Re: uPRF strict more

[John Kristoff]

On Tue, 28 Sep 2021 17:47:41 -0700
Randy Bush  wrote:

> do folk use uPRF strict mode?

Presumably you mean uRPF.  As of a few months ago, the .edu  I was doing
netops at, Juniper's 'rpf-check' option was set on all the edge
interfaces where there were only end hosts.  This is strict mode. The
Cisco counterpart devices would use ' ip verify unicast source
reachable-via rx'.  Also strict mode.

More complicated inter-router links would not use this, but some had
form ingress filter that performed roughly the equivalent where
necessary.

John

Re: Identifying submarine links via traceroute

[Mark Tinka]

On 9/29/21 04:23, PAUL R BARFORD wrote:

Hello,

I am a researcher at the University of Wisconsin.  My colleagues at 
Northwestern University and I are studying submarine cable infrastructure.


Our interest is in identifying submarine links in traceroute 
measurements.  Specifically, for a given end-to-end traceroute 
measurement, we would like to be able to identify when two hops are 
separated by a submarine cable.  Our initial focus has been on 
inter-hop latency, which can expose long links.  The challenge is that 
terrestrial long-haul links may have the same or longer link latencies 
as short submarine links. So, we're interested in whether there may be 
other features (e.g., persistent congestion, naming conventions in 
router interfaces, peering details, etc.) or techniques that would 
indicate submarine links.


Any thoughts or insights you might have would be greatly appreciated - 
off-list responses are welcome.


Back in the day, when submarine cables were not as rife, it was not 
uncommon to see things like "FLAG" or "APCN-2" or "SMW-3" in 
traceroutes. I haven't seen such in a very long time, but likely some 
operators may still do this.


For traceroutes that cross oceans visibly, e.g., lhr-jfk, mrs-mba, 
hnd-lax, mru - cdg, e.t.c., you could glean from there. But many 
operators do not follow any "common norm" to annotate things like this, 
so YMMV.


You also find some countries that will use a submarine festoon either as 
a primary or backup route for a terrestrial link. In such cases, the 
distances may be the same, or even shorter across the festoon, e.g., 
consider a festoon cable between Cape Town - Durban, vs. a land-based 
run for the same two points.


Considering how wide-spread submarine links are for both short and long 
spans, I think folk are simply treating them as any other link, from an 
operational perspective. You may be able to come up with a 
semi-automatic mechanism to measure this, but I fear without deliberate 
and consistent human intervention, the data could get stale very quickly.


Mark.

Re: Identifying submarine links via traceroute

[Mehmet Akcin]

Nice challenge.

Check out infrapedia.com where you can see length of cables and this may
help you “guess” latency but given so many cables are within 5-10ms in some
paths there may be  false positives

A very good topic to work on.

On Wed, Sep 29, 2021 at 08:22 PAUL R BARFORD  wrote:

> Hello,
>
> I am a researcher at the University of Wisconsin.  My colleagues at
> Northwestern University and I are studying submarine cable infrastructure.
>
> Our interest is in identifying submarine links in traceroute
> measurements.  Specifically, for a given end-to-end traceroute measurement,
> we would like to be able to identify when two hops are separated by a
> submarine cable.  Our initial focus has been on inter-hop latency, which
> can expose long links.  The challenge is that terrestrial long-haul links
> may have the same or longer link latencies as short submarine links. So,
> we're interested in whether there may be other features (e.g., persistent
> congestion, naming conventions in router interfaces, peering details, etc.)
> or techniques that would indicate submarine links.
>
> Any thoughts or insights you might have would be greatly appreciated -
> off-list responses are welcome.
>
> Thank you.
>
> Regards, PB
>
> Paul Barford
> University of Wisconsin - Madison
>
-- 
Mehmet
+1-424-298-1903

Identifying submarine links via traceroute

[PAUL R BARFORD]

Hello,

I am a researcher at the University of Wisconsin.  My colleagues at 
Northwestern University and I are studying submarine cable infrastructure.

Our interest is in identifying submarine links in traceroute measurements.  
Specifically, for a given end-to-end traceroute measurement, we would like to 
be able to identify when two hops are separated by a submarine cable.  Our 
initial focus has been on inter-hop latency, which can expose long links.  The 
challenge is that terrestrial long-haul links may have the same or longer link 
latencies as short submarine links. So, we're interested in whether there may 
be other features (e.g., persistent congestion, naming conventions in router 
interfaces, peering details, etc.) or techniques that would indicate submarine 
links.

Any thoughts or insights you might have would be greatly appreciated - off-list 
responses are welcome.

Thank you.

Regards, PB

Paul Barford
University of Wisconsin - Madison

Admin for .tk (not a spam/abuse complaint!)

[Tim Harman via NANOG]

Hi,

If anyone has contact details for the operators of the .tk TLD, could 
you contact me off-list please?


We are unable to contact the authoritive NS for this TLD - it seems our 
range is on a blacklist or they have some odd route back to us that 
isn't working.

Thus our customers can't resolve any .tk names.

I've tried mailing a few @dot.tk (from a host that has no trouble 
resolving the domain!) but have heard nothing back.


Specifically after a contact for whoever maintains

;; ADDITIONAL SECTION:
a.ns.tk.172800  IN  A   194.0.38.1
b.ns.tk.172800  IN  A   194.0.39.1
c.ns.tk.172800  IN  A   194.0.40.1
d.ns.tk.172800  IN  A   194.0.41.1

{11:58}~ ➭ dig @194.0.41.1 test.tk

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @194.0.41.1 test.tk
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Many Thanks,

Tim

Re: uPRF strict more

[Barry Greene]

uRPF Strict mode was always suppose a widget for source address validation 
(SAV). Just like DHCP Lease Query (DOCSIS), the TR-69 ACLs, general ACLs, and 
other vendor specific widgets. Like all widgets, there are places where it 
works and other place were it does not. The key principle is to deploy  on the 
customer - provider edge (with provider = to ISPs, CSPs and cloud providers). 

Which widget you select is an engineering decision. As Saku points out, some 
vendors PPS with uRPF is worse than a simple ACLs. But then the PPS hit might 
be OK if uRPF Strict mode cuts down the operational logistics maintaining the 
customer ACLs. No right or wrong, just engineering choices for SAV deployment.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 11:12, Nick Hilliard wrote:



urpf has its place if your network config build processes aren't 
automated to the point that it's no longer necessary.  It would be a 
net security loss to the internet not to have it widely implemented on 
access devices.


As little as 12 months ago, many vendors either had no or a delayed 
roadmap to support uRPF due to lack of support on usually Broadcom 
chips, or just a lack of interest in developing code if the Broadcom 
chip they had supported it.


This was typically the case for new vendors entering the game, or 
existing ones who were starting to build a merchant chip product line.


I had this issue with Nokia's new IXR line last year. I think they may 
have implemented it on some of their boxes, but not sure yet.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 08:03, Saku Ytti wrote:


Vast majority of access ports are stubby, with no multihoming or
redundancy. And uRPF strict is indeed used often here, but answer very
rarely if ever applies for non-stubby port.

Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.


I tend to agree that ACL's will cost less in the data plane. But the 
only issue, if you feel either uRPF or ACL's are an option, is that for 
large customers who have tons of (especially dis-contiguous address 
space that they may not own), the potential for mistakes can happen 
where some space may either be missed, or incorrectly configured, when 
ACL's are a chosen alternative to uRPF.


Mark.

Re: uPRF strict more

[Mark Tinka]

On 9/29/21 02:47, Randy Bush wrote:


do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2


We do loose-mode for BGP customers, regardless of whether they are 
single- or multi-homed.


We do loose-mode on transit routers, as they hold a full table.

We do strict-mode for stub DIA customers.

We do loose-mode for multi-homed DIA customers.

We don't do uRPF on peering routers, as they don't hold a full table.



do vendors implement the complexity of 8704; and, if so, do operators
use it?


Juniper support Feasible Paths, and we use it with no issue.

We don't use Cisco in this role anymore, so not sure.

Mark.

RE: uPRF strict more

[Brian Turnbow via NANOG]

Hi,

> Having said that, I'm not convinced anyone should use uRPF at all.
> Because you should already know what IP addresses are possible behind the
> port, if you do, you can do ACL, and ACL is significantly lower cost in PPS 
> in a
> typical modern lookup engine.
> 
uRPF still has it's place in access.
We use it in single homed customers and one of the reasons is the limit to the 
number of acls.
Asr 1ks are 4k unique acls IIRC , but you can put a lot more users on them.
Maybe things have changed since I last looked but this was the main driver for 
us to use uRPF when we started with 1ks.

Brian

Re: uPRF strict more

[Nick Hilliard]

Saku Ytti wrote on 29/09/2021 07:03:

Having said that, I'm not convinced anyone should use uRPF at all.
Because you should already know what IP addresses are possible behind
the port, if you do, you can do ACL, and ACL is significantly lower
cost in PPS in a typical modern lookup engine.


urpf has its place if your network config build processes aren't 
automated to the point that it's no longer necessary.  It would be a net 
security loss to the internet not to have it widely implemented on 
access devices.


Nick

Re: IPv6 woes - RFC

[borg]

Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?

Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
routing and NATing however I want..


-- Original message --

From: Mark Andrews 
To: b...@uu3.net
Cc: nanog@nanog.org
Subject: Re: IPv6 woes - RFC
Date: Wed, 29 Sep 2021 00:28:40 +1000



> On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
> 
> Heh, NAT is not that evil after all. Do you expect that all the home
> people will get routable public IPs for all they toys inside house?

Yes! Remember routable does not mean that it is reachable from outside.

> And if they change ISP they will get new range?

Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
has only been specified for 18 years now.  The IPv6 address ranges ISP
get for RIRs are based on handing out multiple /64 to every customer.

> Doesnt sounds nice to me.. But I guess I its just me

It sounds like you need to do some reading about IPv6, then actually
use it.  100s of millions of home customers are get routable IPv6 prefixes
today around the world.  It's not scary.  Things don˙˙t blow up.

> Yeah I am aware of putting additional aliases on loopback.
> 
> No futher comment about ND and DHCP.
> 
> Well, at a time when TCP/IP was invented, 32bit address space looked
> pretty much big... I dont blame them than they didnt predicted future..
> Unfortunately, cant say the same about IPv6 R&D taskforce ;)
> 
> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R&D field...
> 
> Okey, I think its no need to futher pollute NANOG list with this.
> I said at the begining that this is just my subjective opinion.
> This will not help IPv6 case at all.
> 
> At least from my (2) standpoint it would be really cool that IPv6
> would be finally addopted.
> 
> I just wanted to share my toughts about why im not big fan of IPv6.
> I also wanted to hear other opinions what they dislike about it, no
> list of how cool IPv6 is and how everyone should use it right away.
> 
> 
> -- Original message --
> 
> From: Owen DeLong 
> To: b...@uu3.net
> Cc: nanog@nanog.org
> Subject: Re: IPv6 woes - RFC
> Date: Sat, 25 Sep 2021 12:01:22 -0700
> 
> 
> 
>> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
>> 
>> Well, I think we should not compare IPX to IPv4 because those protocols
>> were made to handle completly different networks?
>> 
>> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> 
>> Well, Industry seems to addapt things quickly when they are good enough.
>> Better things replace worse. Of course its not always the case, sometimes
>> things are being forced here.. And thats how I feel about IPv6..
> 
> Sometimes worse things replace better. NAT, for example was definitely not
> an improvement to IPv4. It was a necessary evil intended to be a temporary
> fix.
> 
>> 
>> IPv4 Lookback is 127.0.0.1/8
>> You can use bind IPs within range by applications. Handy
>> In IPv6 its not the case.
> 
> You are free to assign any additional IPv6 addresses you like to the loopback
> interface and then bind them to applications. Personally, I haven˙˙t found a
> particularly good use for this, but it is possible.
> 
> It does mean that instead of wasting 1/256th of the entire address space
> in every context on loopbacks, you have to assign what you need there,
> but you can easily assign a /64 prefix to a loopback interface and have
> applications bind within range.
> 
>> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> Tables overflows, attacks and DDoS.. Why to repeat history again?
> 
> Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
>> think about some external IPv4 interop.. Internet was exploding at 1997..
>> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
>> could happen if IPv6 wasnt so alien ;)
> 
> It was thought about˙˙ It was considered. It was long pondered. Problem was,
> nobody could come up w