Re: Q: is RFC3531 still applicable?
. On 15/05/2024 16:00, nanog-requ...@nanog.org wrote: Message: 11 Date: Tue, 14 May 2024 20:12:31 + From: Mel Beckman To: Adam Thompson Cc: nanog Subject: Re: Q: is RFC3531 still applicable? Message-ID:<813adb68-4f73-49cc-ab3f-9be187074...@beckman.org> Content-Type: text/plain; charset="utf-8" I never could understand the motivation behind RFC3531. Just assign /64s. A single /64 subnet has 18,446,744,073,709,551,616 host addresses. It is enough. Period. With IPv6 when you think of assignment to end-user, it's better to think in terms of 'use case' rather than number of hosts within a single network. As a residential user I might have wifi, voip, TV, CCTV,,... each of them can use its own prefix. As a bare metal user in a datacenter , I might have different needs when I build any internal networks. As a corporate user, I think this one is the more obvious. The only end-user who might stick with a single /64 is - 1 smartphone - 1 VM -- Willy Manga
Re: Q: is RFC3531 still applicable?
Hi, On 15/05/2024 16:00, nanog-requ...@nanog.org wrote: Message: 10 Date: Tue, 14 May 2024 19:52:43 + From: Adam Thompson To: nanog Subject: Q: is RFC3531 still applicable? Message-ID: Content-Type: text/plain; charset="iso-8859-1" Not an IPv6 newbie by any stretch, but we still aren't doing it "at scale" and some of you are, so... For a very small & dense (on 128-bit scales, anyway) network, is RFC3531 still the last word in IPv6 allocation strategies? You can read this article [1] . It's a more 'contemporary' approach. 1. https://www.daryllswer.com/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators/ -- Willy Manga
Value of linux net.ipv6.route.max_size
Hi, I recently noticed an issue with some routers complaining with that message: "kernel: Route cache is full: consider increasing sysctl net.ipv6.route.max_size." These routers are running FRR on Debian 12 , kernel 6.1.0-17-amd64. They are receiving full routing table and routes are inserted into the kernel routing table. I saw a similar error here [1] and it leads me to [2] as well but I should admit I did not read everything. I did not dive into the details of the two links but for now , I want to increase that value (and find the source of that error). The current value of net.ipv6.route.max_size is: 4096 . I guess it's the default on at least that kernel. For reference net.ipv4.route.max_size=2147483647 . Of course, we cannot correlate the two but I was wondering, what either people are using or what might be a reasonable value for the IPv6 counterpart. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1813691 2. https://lore.kernel.org/netdev/e022d597-302d-c061-0830-6ed20aa61...@qtmlabs.xyz/T/#u -- Willy Manga
Re: RPKI unknown for superprefixes of existing ROA ?
. On 23/10/2023 16:00, nanog-requ...@nanog.org wrote: Message: 19 Date: Sun, 22 Oct 2023 14:20:56 -0400 From: Amir Herzberg I agree that a good, sensible defense would be to simply announce your entire address block, e.g., in the example, your entire /22 (with a ROA to your ASN), and filter the traffic to the unused prefixes. Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually. I wonder if anyone is using it , in fact. It would be nice to know if someone has the data handy. https://console.rpki-client.org/AS0.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maximum ipv4 bgp prefix length of /24 ?
. On 12/10/2023 10:00, Owen DeLong wrote: [...] However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why? If that works, perhaps… OTOH, I’m not sure it does. I’m not sure the /32 MAXLEN 32 wouldn’t prevent effectiveness of the /36 ROAs. 1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty. I can… It’s an Optional Field in the specification. For the _specification_ yes. But by "Implementation" I'm referring to whatever either the RIR (those using hosted mode) or your own RPKI Certificate Authority (those using the delegated mode) will allow. 2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them. Yes, but if I issue a /34 AS0 with no MAXLEN, that _SHOULD_ mark ALL more specifics as invalid. If that doesn’t work, then you’re right, the AS0 ROAs are essentially useless, but then one has to wonder what value any RIR issued AS0 ROAs would have as well, since they would obviously be less specific. I will let those with more experience than me provide clarifications here. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maximum ipv4 bgp prefix length of /24 ?
. On 11/10/2023 03:52, Delong.com wrote: [...] RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination. Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid. If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs protecting it, and AS YY has allowed more specifics to be announced within the prefix range covered by the ROA, I'm in like flynn, because I just need to configure my router with AS YY as the origin AS, then insert the expected ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the more specific prefix passes RPKI validation, and traffic comes flying my way. Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, then YY has indeed aimed a firearm squarely at their lower distal appendage and fired. However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why? 1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty. 2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them. 1. https://mailman.nanog.org/pipermail/nanog/2023-October/223676.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maximum ipv4 bgp prefix length of /24 ?
. On 11/10/2023 22:29, Delong.com wrote: [...] Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1] You completely ignored my statement of the need for appropriate AS-0 ROAs to block those. I did not want to comment because you can go down that path *and* you will assume everyone doing ROV will consider AS0 ROAs as well. IMHO the bare minimum is to cover your advertisements with a ROA as precise as possible. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maximum ipv4 bgp prefix length of /24 ?
> On 11/10/2023 03:52, Delong.com wrote: On Oct 10, 2023, at 13:36, Matthew Petach wrote: [...] Owen, RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings. OK, but at least they can help limit the extent of required desegregation in combat unless I misunderstand the whole MAXPREFIXLEN option. Actually, RFC 9319 do recommend to "avoid using the maxLength attribute in ROAs except in some specific cases". But I recognise that this RFC is not yet implemented everywhere. RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination. Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid. Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1] 1. https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html#maximum-prefix-length -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maximum ipv4 bgp prefix length of /24 ?
Hi. On 06/10/2023 16:00, nanog-requ...@nanog.org wrote: From: Matthew Petach [...] The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system. Were you expecting it to be lower than IPv4? Mark. I've dug through the mailman mirror on nanog.org, and there's currently no post by Geoff Huston saying that: https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest I read (and send) NANOG emails through the digest emails sent once a day. I noticed the same thing . I assumed it was sent directly to Mark (or the mail will enter my next digest...) But I'll play along. There's significantly less pressure to deaggregate IPv6 space right now, because we don't see many attacks on IPv6 number resources. Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we'll see IPv6 deaggregation completely swamp IPv4 deaggregation. How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course. A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature.asc Description: OpenPGP digital signature
G root servers unreachable via ICMP(v6)
Hi, DNS speaking, I can query G root servers; at least, that's the most important. However, from several sites, either on IPv4 or IPv6, I cannot ping(6) them. Is it by design, or it's an issue? Side question: even if it was by design, is it a good practice to completely restrict ICMP(v6)? Thanks. P.S: I sent the same email to dns-operati...@lists.dns-oarc.net since 12 May 2023 but it's still in moderation.. If one admin is around .. :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: Reverse DNS for eyeballs?
. On 22/04/2023 16:00, nanog-requ...@nanog.org wrote: [...] [..] Really, reverse DNS these days is mostly only useful for: - mail servers (where it shows a modicum of control and clue) - infrastructure/router IPs (so mtr/traceroute can show useful info) - Peers in an Internet eXchange Point ( a subset of the previous bullet point) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Can rr.ntt.net have a AAAA record please?
Hi, Dear admin of rr.ntt.net , I'm not one of your customers, but can you please enable IPv6 on your routing registry? I have to ask because (at least) those using tools like bgpq4 query by default your registry. And if you are using IPv6, your registry is only reachable if I enable a transition technique. Thank you in advance :) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: Perhaps it's time to think about enhancements to the NANOG list...?
. On 21/03/2021 17:29, Willy Manga wrote: > Hi, > > On 21/03/2021 16:00, nanog-requ...@nanog.org wrote: >> Message: 13 >> Date: Sat, 20 Mar 2021 12:46:57 -0600 >> From: David Siegel >> [...] >> The board has been thinking about enhancements to the NANOG list for a >> couple of years now, with the goal of creating a modern interface that the >> younger generation of engineers will be more comfortable using. > > May I suggest that if you *really* want such enhancement, perhaps > upgrade the mailing-list to mailman3. > It's still mailman but with those 'modern' features. one example with APNIC . Here is what the frontend looks like. The available lists: https://mailman.apnic.net/hyperkitty/ Discussions within one list https://mailman.apnic.net/hyperkitty/list/sig-routingsecur...@apnic.net/ Content of one thread https://mailman.apnic.net/hyperkitty/list/sig-routingsecur...@apnic.net/thread/ZH6KCIF5IE2AIPW66VRKEXLZTR46HYV2/ -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: Perhaps it's time to think about enhancements to the NANOG list...?
Hi, On 21/03/2021 16:00, nanog-requ...@nanog.org wrote: > Message: 13 > Date: Sat, 20 Mar 2021 12:46:57 -0600 > From: David Siegel >[...] > The board has been thinking about enhancements to the NANOG list for a > couple of years now, with the goal of creating a modern interface that the > younger generation of engineers will be more comfortable using. May I suggest that if you *really* want such enhancement, perhaps upgrade the mailing-list to mailman3. It's still mailman but with those 'modern' features. But more importantly (not only for NANOG by the way), maybe some kind of 'mailing-list 101' can be helpful sometimes. Many $vendors are fighting hard to make people forget what an email is. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: DoD IP Space
Hi, On 11/02/2021 13:00, nanog-requ...@nanog.org wrote: > Date: Wed, 10 Feb 2021 09:50:56 -0800 > From: Doug Barton >[...] On 2/10/21 5:56 AM, Ca By wrote> >> The 3 cellular networks in the usa, 100m subs each, use ipv6 to uniquely >> address customers. And in the case of ims (telephony on a celluar), it >> is ipv6-only, afaik. > So that answers the question of how to scale networks past what can be > done with 1918 space. Although why the phones would need to talk > directly to each other, I can't imagine. - P2P applications? - (because I'm tethering,) enable customers to share a service to other people without relying to (many) external parties? (actually, that was the purpose of the Internet since the beginning if I'm right) - ... > I also reject the premise that any org, no matter how large, needs to > uniquely number every endpoint. When I was doing IPAM for a living, not > allowing the workstations in Tucson to talk to the printers in Singapore > was considered a feature. I even had one customer who wanted the > printers to all have the same (1918) IP address in every office because > they had a lot of sales people who traveled between offices who couldn't > handle reconfiguring every time they visited a new location. I thought > it was a little too precious personally, but the customer is always > right. :) Here comes the DNS imho if it was accepted by the customer. Same result, better management and flexibility... > Sure, it's easier to give every endpoint a unique address, but it is not > a requirement, and probably isn't even a good idea. Spend a little time > designing your network so that the things that need to talk to each > other can, and the things that don't have to, can't. I did a lot of > large multinational corporations using this type of design and never > even came close to exhausting 1918 space. Here comes your firewall rules and all your ACL ... easier with IPv6 imho -- Willy Manga @ongolaboy https://ongola.blogspot.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: RIPE our of IPv4
Hi, On 02/12/2019 16:00, nanog-requ...@nanog.org wrote: > From: Mark Tinka > [...] > On 1/Dec/19 02:54, Brandon Martin wrote: > >> How slim are your margins to have been around long enough to have a legacy >> IPv4 block but not be able to afford the ARIN fees to get a comparable/very >> usable (/48 to /52 for each IPv4) amount of IPv6? And if you don't need a >> "comparable" amount of IPv6, presumably you aren't using all your legacy >> IPv4 and can sell off part of its presumably huge allocation to get some >> funds. > > AFRINIC offered IPv6 /32's for free for every member that paid for their > IPv4. > > Not sure if they still do, but my annual bill does mention that amount > of IPv6 space we have. still accurate. https://afrinic.net/membership/cost#resource , section 3.1-"For existing members". It is said "No additional fees as a result of the issued IPv6 prefix will apply." Section 3.2. new IPv6-only members get discounts over 3 years -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: RIPE our of IPv4
Hello, On 26/11/2019 16:00, nanog-requ...@nanog.org wrote: > Date: Tue, 26 Nov 2019 00:13:48 -0800 (PST) > From: Sabri Berisha > To: Doug Barton > Cc: nanog > Subject: Re: RIPE our of IPv4 > Message-ID: > <1383247942.183700.1574756028904.javamail.zim...@cluecentral.net> > Content-Type: text/plain; charset=utf-8 > > - On Nov 26, 2019, at 1:36 AM, Doug Barton do...@dougbarton.us wrote: > >> I get that some people still don't like it, but the answer is IPv6. Or, >> folks can keep playing NAT games, etc. But one wonders at what point >> rolling out IPv6 costs less than all the fun you get with [CG]NAT. > When the MBAs start realizing the risk of not deploying it. > > I have some inside knowledge about the IPv6 efforts of a large eyeball > network. In that particular case, the cost of deploying IPv6 internally is > not simply configuring it on the network gear; that has already been done. > The cost of fully supporting IPv6 includes (but is probably not limited to): > > - Support for deploying IPv6 across more than 20 different teams; > - Modifying old (ancient) internal code; > - Modifying old (ancient) database structures (think 16 character fields for > IP addresses); > - Upgrading/replacing load balancers and other legacy crap that only support > IPv4 (yeah, they still exist); > - Modifying the countless home-grown tools that automate firewalls etc; > - Auditing the PCI infrastructure to ensure it is still compliant after > deploying IPv6; > > If it was as simple as upgrading a few IP stacks here and there, it would be > a non-issue. No matter how complex is your network (and your teams), from my humble point of view, there is always something you can do regarding IPv6. The key is not to solve one million problems on one day. The key is to go gradually, one small block after another one. You can even keep all your internal network on v4 (forever if that is your intent ) and use IPv6 on specific portions of your network. > Don't get me wrong, I'm not advocating against IPv6 deployment; on the > contrary. But it is not that simple in the real corporate world. Execs have > bonus targets. IPv6 is not yet important enough to become part of that bonus > target: there is no ROI at this point. In this kind of environment there > needs to be a strong case to invest the capex to support IPv6. > > IPv6 must be supported on the CxO level in order to be deployed. I would have said the very very minimum could be to invest in a dual-stack 'proxy' for public-facing services; internal or external solution, you have the choice. And why even do that ? Because the other side is not only on IPv4. -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: WIndows Updates Fail Via IPv6
Hi, Le 11/11/2018 à 13:00, nanog-requ...@nanog.org a écrit : > [...] > Date: Sun, 11 Nov 2018 11:29:43 +0200 > From: Mark Tinka > Hi all. > Anyone ever figured out why Windows updates fail when the computer has > an IPv6 connection? Weird .. We have PC running Windows 10 pro (20+) in my organization (based in Cameroon) and dont have that issue. > [...] > I have a family PC at home running Windows 10 Pro, and noticed updates > would fail in recent months. It took me a moment to realize that this > started happening only after I enabled IPv6 in the TCP/IP stack. > Disabling it immediately solves the issue. > > Quite odd that this is happening in 2018... IMHO the issue is in the network somewhere ... -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Re: Yet another Quadruple DNS?
Hi, Le 30/03/2018 à 13:00, nanog-requ...@nanog.org a écrit : > >Date: Thu, 29 Mar 2018 09:13:06 -0400 >From: Doug Clements <dcleme...@gmail.com> > >>From https://1.1.1.1/: >For IPv6: *2001:2001::* and/or *2001:2001:2001::* No, it's 1dot1dot1dot1.cloudflare-dns.com (2606:4700:4700::1001 and 2606:4700:4700:: ) -- Willy Manga @ongolaboy https://ongola.blogspot.com/ signature.asc Description: OpenPGP digital signature
Link-local v6 and mobile phones
Hello, a little question :) For mobile operators using v6 on their networks, how do you manage link-local communication between mobile phones ? While I understand it's layer 2 related, am i able for example to make ping sweep and be able to communicate directly with other phone (customer) ? -- Willy Manga (from where I stand mobile operators do not use yet v6 :-\ ) freenode: ongolaBoy Ubuntu Cameroonian Loco Team https://launchpad.net/~manga-willy signature.asc Description: OpenPGP digital signature
