Re: Redploying most of 127/8 as unicast public

[Gaurav Kansal]

> On 18-Nov-2021, at 09:10, Jerry Cloe  wrote:
> 
>  
>  
> Subject: Redploying most of 127/8 as unicast public
> To: nanog mailto:nanog@nanog.org>>; 
> This seems like a really bad idea to me; am I really the only one who noticed?
> 
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html 
> 
>  
> I can think of about a dozen /8's that would be better to use. (Hint, they 
> all have DOD in the name.) They haven't been in routing tables for decades 
> and there wouldn't be hardly any technical issues (like there would be with 
> 127/8). The only drawback is I've seen a lot of organizations treat them like 
> rfc1918 space.
>  
This seems to be much better idea then 127/8 or 240/8

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Gaurav Kansal]

> On 20-Nov-2021, at 02:21, g...@toad.com wrote:
> 
> David Conrad  wrote:
>> Doesn't this presume the redeployed addresses would be allocated
>> via a market rather than via the RIRs?
>> 
>> If so, who would receive the money?
> 
> You ask great questions.
> 
> The community can and should do the engineering to extend the IP
> implementations.  If that doesn't happen, the rest of the issues are
> moot.  There would be no addresses to allocate and no money to receive.
> 
> It would take multiple years post-RFC and post-implementation before
> anyone could even contemplate doing allocation, of any sort.  So while
> it's an entertaining sideline to think about later, at this point it is
> a distraction.
> 
>   John
>   
> PS:  It's conceivable that RIRs could allocate via a market.
> One has already done so (APNIC).
What exactly APNIC has done (just for curiosity) ? 

Re: (Free)RADIUS Front-End

[Gaurav Kansal]

I have also developed Free Radius based AAA (Authentication , Authorisation and 
Accounting) solution , and we have replaced Cisco ISE with our in-house 
developed product. 
More than 30K clients are getting authenticated and managed through this portal.

In case, if anyone needs any help or suggestions in FR, then feel free to 
connect.

Thanks,
Gaurav Kansal


> On 12-Feb-2022, at 20:45, mark@tinka.africa wrote:
> 
> For posterity, finally went with Splynx. 
> 
> Really awesome product, covering not only RADIUS but also CRM, billing, 
> invoicing, remote integration, e.t.c.
> 
> Just in case anyone else ends up having the same requirement.
> 
> Mark.
> 
> On 9/20/21 09:19, Mark Tinka wrote:
>> 
>> 
>> On 9/20/21 02:16, Philip Loenneker wrote: 
>>> Splynx is a commercial product designed to be an entire package for running 
>>> an ISP, including billing etc. It uses FreeRadius in the backend which 
>>> chains into their own RADIUS system. Integration for MikroTik routers is 
>>> very extensive, but we have had it working with a variety of other BNGs too 
>>> including Cisco and Linux-based systems. You can add in RADIUS dictionaries 
>>> and customise the router profiles via the GUI to send whatever VSAs you 
>>> require, including for COA. The APIs on it are extensive, making automation 
>>> of service provisioning relatively easy. The IPAM in it is fairly basic, 
>>> primarily ensuring that you don't re-use IPs between multiple services. 
>>> IPv6 support is included, but primarily for IPv6-PD rather than interface 
>>> IPs, however I have managed to get a BNG to assign an IPv4 address, an IPv6 
>>> interface address and IPv6-PD all from the Splynx profile. The accounting 
>>> is ok, allowing you to apply bandwidth caps on users if required, including 
>>> different speeds for different times of day. 
>>> 
>>> www.splynx.com <http://www.splynx.com/> 
>> 
>> Many thanks, Philip. Looks awesome! 
>> 
>> Mark. 
>> 
> 

Re: Google.com SSL cert issues

[Gaurav Kansal]

I am able to access google.com without any issues.

> On 21-Sep-2022, at 20:57, mana...@monmouth.com wrote:
> 
> Is anyone else getting the following error when trying to access any of 
> google's services?
> SSL_ERROR_RX_RECORD_TOO_LONG
> This started about an hour ago and is not dependent on browser type but 
> rather geographic location.
> I have servers on different networks and some can no longer access google.com 
> due to the SSL error.
> 
> 
> 
> 
> Thanks
> 
> Mark

Re: Historical info on how 'x.com' came to be registered

[Gaurav Kansal]

> On 29-Jul-2023, at 01:04, jo...@iecc.com wrote:
> 
> It appears that Drew Weaver  said:
>> -=-=-=-=-=-
>> 
>> Does anyone have any historical information on how 'x.com' came to be 
>> registered even though single letters were reserved?
>> 
>> Is there a story or is it as simple as it was registered prior to the 
>> reservation?
> 
> Here's a story about its history.  It's very old, from 1992.
> 
> https://jimmysoni.substack.com/p/the-colorful-history-of-xcom-aka

Interesting and informative one.
Who knows ‘q’ and ‘z’ nowadays ?? 

Regards,
Gaurav 
> 
> R's,
> John

Re: Acceptance of RPKI unknown in ROV

[Gaurav Kansal via NANOG]

> On 20-Oct-2023, at 00:35, nanog@nanog.org wrote:
> 
> On Thu, 19 Oct 2023 at 11:56, Owen DeLong  > wrote:
>>> 
>>> On Thu, 19 Oct 2023 at 11:46, Owen DeLong via NANOG >> > wrote:
 A question for network operators out there that implement ROV…
 
 Is anyone rejecting RPKI unknown routes at this time?
 
 I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t 
 match the route), but I’m wondering if anyone  is currently or has any 
 plans to start rejecting routes which don’t have a matching ROA at all?
>>> 
>>> 
>>> This would be a bad idea and cause needless fragility in the network 
>>> without any upsides.
>> 
>> I’m not intending to advocate it, I’m asking if anyone is currently doing it.
> 
> 
> I’m not aware of anyone doing this, and have not heard operators express 
> interest in doing this (probably because it seems such an unpleasant concept).
> 
> Somewhat related:
> 
> I do know of operators that require a ROA (if it’s non-legacy space) during 
> their customer onboarding process, for example, in BOYIP for DIA cases.

In my region also, ISPs are asking valid ROAs before on-boarding users. 

> 
> But those operators do not expect the ROA to continually exist after the 
> provisioning has been completed successfully. Making the continued 
> availability of a route dependent on the continued validity of a ROA is where 
> friction starts to form.
> 
> Kind regards,
> 
> Job

Re: ipv6 address management - documentation

[Gaurav Kansal via NANOG]

I will second this.
Netbox is very rich and we can do and manage multiple other things also in 
netbox.
Like I am managing my complete server infra details and my service connectivity 
details in netbox.
Kudos to the developer and the netbox community.

Regards,
Gaurav Kansal


> On 16-Nov-2023, at 23:39, ja...@biel-tech.com wrote:
> 
> My recommendation:
> 
> https://github.com/netbox-community
> 
> 
> On Thu, Nov 16, 2023 at 12:04 PM Aaron Gould  <mailto:aar...@gvtc.com>> wrote:
>> For years I've used an MS Excel spreadsheet to manage my IPv4 
>> addresses.  IPv6 is going to be maddening to manage in a spreadsheet.  
>> What does everyone use for their IPv6 address prefix management and 
>> documentation?  Are there open source tools/apps for this?
>> 
>> -- 
>> -Aaron
>> 
> 
> 
> -- 
> Jason

Re: Out of ideas - Comcast issue BGP peering with Tata

[Gaurav Kansal via NANOG]

Hi friend,

Any idea how many segments are in routing table which are still not part of RIR 
holder ship ?

Regards,
Gaurav Kansal


> On 22-Nov-2023, at 07:40, nanog@nanog.org wrote:
> 
>> 
>>> Special note, deprecation of non-authoritative registries
>>> 
>>> Please note that 'route' and 'route6' objects created after 2023-Aug-15 in 
>>> non-authoritative registries like RADB, NTTCOM, ALTDB won't be processed. 
>>> It is recommended to create RPKI ROA objects instead. In rare cases if 
>>> that's not possible, 'route' and 'route6' must be created in the 
>>> authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE, NIC.br 
>>> or IDNIC.
>> 
> 
> So basically, a giant #@*&$^ you to any legacy holders that aren’t paying an 
> RIR.
> 
> Great!!
> 
> Thanks, Tata
> 

Re: 202401100645.AYC Re: IPv4 address block

[Gaurav Kansal via NANOG]

+1 to the Christopher comment

> On 11-Jan-2024, at 16:24, ch...@thesysadmin.au wrote:
> 
> There really is no reason for 240/4 to remain "reserved". I share Dave's 
> views, I would like to see 240/4 reclassified as unicast space and 2 x /8s 
> delegated to each RIR with the /8s for AFRINIC to be held until their issues 
> have been resolved.
> 
> Reclassifying this space, would add 10+ years onto the free pool for each 
> RIR. Looking at the APNIC free pool, I would estimate there is about 1/6th of 
> a /8 pool available for delegation, another 1/6th reserved. Reclassification 
> would see available pool volumes return to pre-2010 levels.
> 
> https://www.apnic.net/manage-ip/ipv4-exhaustion/
> 
> In the IETF draft that was co-authored by Dave as part of the IPv4 Unicast 
> Extensions Project, a very strong case was presented to convert this space.
> 
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
> 
> Regards,
> Christopher Hawker
> 
> On Thu, 11 Jan 2024 at 20:40, Dave Taht  > wrote:
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher > > wrote:
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >
>> >
>> > Of course correct. It really depends on the vendor / software / versions 
>> > in an environment. A lot of vendors removed that years ago, because 
>> > frankly a lot of large networks have been using 240/4 as pseudo RFC1918 
>> > for years. Others have worked with smaller vendors and open source 
>> > projects to do the same.
>> >
>> > It's consistently a topic in the debates about 240/4 reclassification.
>> 
>> There's debates still? I gave up. After making 240/4 and 0/8 work
>> across all of linux and BSD and all the daemons besides bird (which
>> refused the patch , I took so much flack that I decided I would just
>> work on other things. So much of that flack was BS - like if you kill
>> the checks in the OS the world will end - that didn't happen. Linux
>> has had these two address ranges just work for over 5 years now.
>> 
>> 240/4 is intensely routable and actually used in routers along hops
>> inside multiple networks today, but less so as a destination.
>> 
>> I would really like, one day, to see it move from reserved to unicast
>> status, officially. I would have loved it if 0/8 was used by a space
>> RIR, behind CGNAT, for starters, but with a plan towards making it
>> routable. I am not holding my breath.
>> 
>> The principal accomplishment of the whole unicast extensions project
>> was to save a nanosecond across all the servers in the world on every
>> packet by killing the useless 0/8 check. That patch paid for itself
>> the first weekend after that linux kernel deployed. It is the
>> simplest, most elegant, and most controversial patch I have ever
>> written.
>> 
>> https://news.ycombinator.com/item?id=20430096
>> 
>> 
>> >
>> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler 
>> > mailto:i...@protected-networks.net>> wrote:
>> >>
>> >> On 1/10/24 10:12, Tom Beecher wrote:
>> >> > Karim-
>> >> >
>> >> > Please be cautious about this advice, and understand the full context.
>> >> >
>> >> > 240/4 is still classified as RESERVED space. While you would certainly
>> >> > be able to use it on internal networks if your equipment supports it,
>> >> > you cannot use it as publicly routable space. There have been many
>> >> > proposals over the years to reclassify 240/4, but that has not happened,
>> >> > and is unlikely to at any point in the foreseeable future.
>> >>
>> >> While you may be able to get packets from point A to B in a private
>> >> setting, using them might also be .. a challenge.
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >>
>> >> #define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf000) == 0xf000)
>> >>
>> >> Michael
>> >>
>> 
>> 
>> -- 
>> 40 years of net history, a couple songs:
>> https://www.youtube.com/watch?v=D9RGX6QFm5E
>> Dave Täht CSO, LibreQos

Re: ru tld down?

[Gaurav Kansal via NANOG]

> On 09-Feb-2024, at 02:03, ma...@isc.org wrote:
> 
> 
> 
>> On 9 Feb 2024, at 03:10, darkde...@darkdevil.dk wrote:
>> 
>>> Den 31-01-2024 kl. 20:47 skrev Bjørn Mork:
>>> Why do they put their DNS servers in an unsigned zone?
>> 
>> To try to make a more in-depth example:
>> 
>> At the moment, .COM/.NET is relying on GTLD-SERVERS.NET for the 
>> authoritative DNS.
>> 
>> GTLD-SERVERS.NET is currently relying on NSTLD.COM for the authoritative DNS.
>> 
>> With this example, you are asking why neither GTLD-SERVERS.NET nor NSTLD.COM 
>> has been DNSSEC signed?
>> 
>> In that case, I would probably be extending that a bit, considering a lot of 
>> critical resources out there (even if announced as IPv6 /48 and IPv4 /24) 
>> still do not have any RPKI ROA, at all.
>> 
>> (But maybe that's just me...)
> 
> The NS records in a delegation are NOT SIGNED. The glue addresses in a 
> referral are NOT SIGNED.
For taking care of referrals and delegations, ietf has started preliminary 
work. More info here -

 https://mailarchive.ietf.org/arch/msg/dd/srNtevzS-jrPzMxYv1nATCY5JkM/

> Resolvers use those.  They should get back signed answers from signed zones 
> which are verifiable.
> If they get back unsigned answers for signed zones they will be rejected.  It 
> they get back unsigned
> answers from an unsigned zone then all bets are off.  DNSSEC sign your zones 
> if you are worried
> about that.  There is potential for information leakage with this strategy, 
> but not wrong answers
> being returned from signed zones.  Signing the zones would help a little with 
> the information
> leakage when the servers are not learnt by glue.  It is impossible to prevent 
> all information
> leakage even if all zones, delgations and glue was signed.
> 
> 
>> --
>> Med venlig hilsen / Kind regards,
>> Arne Jensen
>> 
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: 2600:: No longer pings

[Gaurav Kansal via NANOG]

2409:: is replying the ICMPv6 request, in case anyone interested 


> On 6 Apr 2024, at 15:31, nanog@nanog.org wrote:
> 
> It appears that 2600:: no longer responds to ICMP.
> 
> $ mtr -rwc 1 2600::
> Start: 2024-04-06T10:53:41+0100
> HOST: metropolis  Loss%
>  1.|-- lcy02.flat.b621.net  0.0%
> [...]
>  6.|-- ldn-b4-link.ip.twelve99.net  0.0%
>  7.|-- ldn-bb1-v6.ip.twelve99.net   0.0%
>  8.|-- nyk-bb2-v6.ip.twelve99.net   0.0%
>  9.|-- ??? 100.0
> 10.|-- sprint-ic301620-nyk-b5.ip.twelve99-cust.net  0.0%
> 11.|-- ??? 100.0
> 
> This seems to have happened around Friday 5th 13:40 UTC.
> 
> 2600::, a IP address owned by the Sprint network (Now since acquired
> by Cogent Communications) is a common (at least in my circles) IPv6
> testing address, in a similar way that 8.8.8.8 or 1.1.1.1 is for a
> quick address to remember that always pings, when such a address is so
> easy to remember, you sometimes cannot help it becoming a "core
> project" :) ( https://xkcd.com/1361/ )
> 
> 2600:: is also used to be the address of sprint.net, now sprint.net has no v6.
> 
> This is sad, and I would either propose that Cogent/Sprint (I assume
> 2600:: is under the ownership of Cogent now) revive this address as
> it's a very helpful testing address that is burned into the minds of
> many. Or at the very least, I'm more than willing to tank the effort
> of responding to ICMP!