Re: Juniper hardware recommendation

2021-05-08 Thread Bjørn Mork
Adam Thompson  writes:


>   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!

https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
https://apps.juniper.net/hct/model/?component=MIC6-10G


Bjørn


Re: Myanmar internet - something to think about if you're having a bad day

2021-04-27 Thread Bjørn Mork
scott  writes:

> Telenor and Ooredoo, it's time to do the right thing.

Wrt Telenor, please see the info posted at
https://www.telenor.com/sustainability/responsible-business/human-rights/mitigate/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021/


Bjørn


Time to validate the TLS configuration on your SMTP servers (was: Re: AS5 ipv6 hijack?)

2021-04-12 Thread Bjørn Mork
OK, so that email bounced.  Or will eventually because this does not go
away with someone doing something:

  ... Deferred: 403 4.7.0 TLS handshake failed.

I am posting this in public because it unfortunately is a very common
problem.

Debian buster was released on July 6th, 2019. It includes openssl 1.1.1
with this configuration update among number of other improvements:

openssl (1.1.1~~pre6-1) experimental; urgency=medium

  * New upstream version
  * Increase default security level from 1 to 2. This moves from the 80 bit
security level to the 112 bit securit level and will require 2048 bit RSA
and DHE keys.

 -- Kurt Roeckx   Tue, 01 May 2018 16:00:55 +0200


I assume similar policies have been applied to all modern and maintained
operating systems by now.

Everyone should verify their own SMTP servers to avoid losing email due
to TLS failures.  Doing so is simple from e.g Debian:


bjorn@canardo:/usr/local/src/openwrt$ cd

   
bjorn@canardo:~$ host interhost.net 

   
interhost.net has address 185.18.204.66
interhost.net mail is handled by 10 pineapp.interhost.co.il.

bjorn@canardo:~$ openssl s_client -quiet -connect pineapp.interhost.co.il:25 
-starttls smtp
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL RSA CA 
2018
verify return:1
depth=0 CN = *.interhost.co.il
verify return:1
139901908640896:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too 
small:../ssl/statem/statem_clnt.c:2150:


The fix obviously depends on the server, but is usually as simple as
regnerating the DH parameters.  See for example
https://forums.freebsd.org/threads/sendmail-dh-key-too-small.51985/



Bjørn


Re: AS5 ipv6 hijack?

2021-04-12 Thread Bjørn Mork
Dmitry Sherman  writes:

> I see ipv6 bgp hijack of our prefixes via AS5.

Or misunderstood prepending attempt, like hijacks from low AS numbers
often are?



Bjørn


Re: login.authorize.net has A and CNAME records

2021-04-07 Thread Bjørn Mork
Mark Andrews  writes:

> It shouldn’t matter.  Only non-rfc-compliant servers allow A and CNAME
> to co-exist at the same name.  That combination was prohibited by RFC
> 1034.

Right.  Thanks.  I confused myself multiple times here ;-)


The issue seems to be that the cloudflare servers takes a shortcut and
convert the CNAME to A, dropping the intermediate CNAME.   That's
obviously not OK.


So it looks correct when you do:


bjorn@miraculix:/tmp$ dig CNAME login.authorize.net 
@ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> CNAME login.authorize.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52372
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.   IN  CNAME

;; ANSWER SECTION:
login.authorize.net.300 IN  CNAME   
login.authorize.net.cdn.cloudflare.net.

;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:23 CEST 2021
;; MSG SIZE  rcvd: 97

bjorn@miraculix:/tmp$ dig A login.authorize.net.cdn.cloudflare.net 
@ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net.cdn.cloudflare.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54740
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.cdn.cloudflare.net.IN A

;; ANSWER SECTION:
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.8.127
login.authorize.net.cdn.cloudflare.net. 300 IN A 104.18.9.127

;; Query time: 28 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:01:41 CEST 2021
;; MSG SIZE  rcvd: 99



But not when you query for A directly:



bjorn@miraculix:/tmp$ dig A login.authorize.net @ns0210.secondary.cloudflare.com

; <<>> DiG 9.16.13-Debian <<>> A login.authorize.net 
@ns0210.secondary.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26197
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;login.authorize.net.   IN  A

;; ANSWER SECTION:
login.authorize.net.300 IN  A   104.18.9.127
login.authorize.net.300 IN  A   104.18.8.127

;; Query time: 24 msec
;; SERVER: 162.159.33.85#53(162.159.33.85)
;; WHEN: Wed Apr 07 10:02:25 CEST 2021
;; MSG SIZE  rcvd: 80



So a Cloudflare bug.



Bjørn


Re: login.authorize.net has A and CNAME records

2021-04-07 Thread Bjørn Mork
Bjørn Mork  writes:

> Seth Mattinen  writes:
>> On 4/6/21 11:35 AM, Arne Jensen wrote:
>>> login.authorize.net. is a CNAME, but does not have any A records itself.
>>
>>
>> This one returns A records:
>
> Looks like they host DNS on both cloudflare and akami, but zone contents
> are different on the two platforms:
>
>  bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
> "$s: ";dig +short login.authorize.net @$s|xargs; done
>  a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
>  ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127
>  ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127

Doh! I should know better.  Sorry, ignore that.  Don't ask for A records
if you want to see CNAMEs..


Bjørn


Re: login.authorize.net has A and CNAME records

2021-04-07 Thread Bjørn Mork
Seth Mattinen  writes:
> On 4/6/21 11:35 AM, Arne Jensen wrote:
>> login.authorize.net. is a CNAME, but does not have any A records itself.
>
>
> This one returns A records:

Looks like they host DNS on both cloudflare and akami, but zone contents
are different on the two platforms:

 bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
"$s: ";dig +short login.authorize.net @$s|xargs; done
 a10-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a1-190.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a2-65.akam.net.: login.authorize.net.cdn.cloudflare.net.
 a9-64.akam.net.: login.authorize.net.cdn.cloudflare.net.
 ns0090.secondary.cloudflare.com.: 104.18.8.127 104.18.9.127
 ns0210.secondary.cloudflare.com.: 104.18.9.127 104.18.8.127

Interesting enough the serial number is consistent though:

 bjorn@miraculix:~$ for s in $(dig +short ns authorize.net|sort); do echo -n 
"$s: ";dig +short soa authorize.net @$s; done
 a10-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a1-190.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a2-65.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 a9-64.akam.net.: ns1.dnsvisa.com. premiumdns.support.neustar. 2019103361 600 
300 1209600 300
 ns0090.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 
2019103361 600 300 1209600 300
 ns0210.secondary.cloudflare.com.: ns1.dnsvisa.com. premiumdns.support.neustar. 
2019103361 600 300 1209600 300


I wish I could say that this is surprising



Bjørn


Re: DoD IP Space

2021-02-10 Thread Bjørn Mork
Ca By  writes:

> 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.

I certainly agree that this is easier and makes more sense.  I just
don't buy the "can't be done" wrt using rfc1918.


Bjørn


Re: DoD IP Space

2021-02-10 Thread Bjørn Mork
Ca By  writes:

> On Wed, Feb 10, 2021 at 4:32 AM Valdis Klētnieks 
> wrote:
>
>> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
>> > Please explain to me how you uniquely number 40M endpoints with RFC-1918
>> without running out of
>> > addresses and without creating partitioned networks.
>>
>> OK.. I'll bite.  What network design needs 40M endpoints and can't tolerate
>> partitioned networks?  There's eyeball networks out there that have that
>> many
>> endpoints, but they end up partitioned behind multiple NAT boxes.
>>
>>
> Why would you assume partitioning is an acceptable design constraint ?
>
> I don’t think the cellular networks in the USA, each with over a 100M
> subscribers, wants their customers partitioned, and that is why the IMS /
> SIP on each modern phone is exclusively ipv6, afaik

You don't need to partition the customers to partition the network.
It's not like any single network entity scales to a 100M sessions in any
case.  You will need more than one SIP server.

You'll have multiple instances of "that user with 10.10.10.10", but
that's easily addressed that by including the associated network
segment.  So you have "that user with 10.10.10.10 in segment A" and
"that user with 10.10.10.10 in segment B". They can both be part of the
same customer database or whatever


Bjørn


Re: DoD IP Space

2021-02-10 Thread Bjørn Mork
Owen DeLong  writes:

> Please explain to me how you uniquely number 40M endpoints with RFC-1918 
> without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.


You added "without ..." and did not explain why.  This does look a bit
like an excuse to me.  But there is probably some explanation I don't
see.

Why would you not partition the network?


Bjørn


Re: "Hacking" these days - purpose?

2020-12-17 Thread Bjørn Mork
For fun and/or profit.  Like the purpose always has been.

Note that the definition of fun will vary.  But overcoming a challenge
of some sort is almost universally considered "fun".


Bjørn


Re: Centurylink having a bad morning?

2020-09-01 Thread Bjørn Mork
Eric Kuhnke  writes:

> There's a number of enterprise end user type customers of 3356 that have
> on-premises server rooms/hosting for their stuff. And they spend a lot of
> money every month for a 'redundant' metro ethernet circuit that takes
> diverse fiber paths from their business park office building to the local
> clink/level3 POP. But all that last mile redundancy and fail over ability
> doesn't do much for them when 3356 breaks its network at the BGP level.

Well, many of us are paying for redundant power supplies or redundant
REs, even if that doesn't make any difference when the chassis is on
fire.  I guess most people know that, and still buy those redundant
components.

It's always about cost versus risk.  I certainly hope nobody here
believe single homed is completely failsafe.

(the lack of withdrawal making multi homed customers fail too is more
unexpected, and a new factor to consider in the future)


Bjørn


Re: Ipv6 help

2020-08-26 Thread Bjørn Mork
Brian Johnson  writes:

>> 1) It needs *much less* IPv4 addresses (in the NAT64) for the same number of 
>> customers.
>
> I cannot see how this is even possible. If I use private space
> internally to the CGN, then the available external space is the same
> and the internal customers are the same and I can do the same over sub
> ratio under both circumstance. Tell me how the math is different.

Because NAT64 implies DNS64, which avoids NATing any dual stack service.
This makes a major difference today.


Bjørn


Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

2020-08-26 Thread Bjørn Mork
What problem are you trying to solve?


Bjørn


Re: Ipv6 help

2020-08-26 Thread Bjørn Mork
Brandon Martin  writes:
> On 8/25/20 3:38 PM, JORDI PALET MARTINEZ via NANOG wrote:
>> This is very common in many countries and not related to IPv6, but
>> because many operators have special configs or features in the CPEs
>> they provide.
>
> I really, really hate to force users to use my network edge router (I
> provide the ONT, though, and I provide an edge router that works and
> most users do take it), but it can be tough to ensure users have
> something that supports all the right modern features and can be
> configured via standard means.

You aren't forcing anything if you allow the users to use any CPE and
document the features it must/should have.

 You want IPv4 access without DNS? Then you need CLAT
 You don't know what CLAT is?  Call your CPE vendor for support
 You don't care what CLAT is?  Use our CPE
 You want to call us for support?  Use our CPE

There is no force here.  It all is pretty similar to

 You want to connect the CPE to our ONT?  Then you need Ethernet
 etc.
 
excluding all those TokenRing routers.

> It would be nice if the consumer router industry could get its
> collective act together and at least come up with some easy-ish to
> understand feature support table that customers can match up with
> their service provider's list of needs.

If you create such a feature table as the service provider, and the
customer is unable to match it against their CPE documentation, then
that's a problem between the CPE vendor and the customer.

I can't understand why you want to make it your problem, as long as you
offer a CPE that just works.


Bjørn


Re: understanding IPv6

2020-06-07 Thread Bjørn Mork
On Sun, Jun 7, 2020 at 2:00 AM Fred Baker  wrote:

>  I'm sorry you have chosen to ignore documents like RFC 3315, which is
>  where DHCP PD was first described (in 2003). It's not like anyone's
>  hiding it.

Erhm, you probably meant RFC 3633 (also 2003).  There was no PD in the
original DHCPv6 spec


Bjørn


Re: understanding IPv6

2020-06-07 Thread Bjørn Mork
Daniel Sterling  writes:

> In all seriousness, I have been trying to understand IPv6 for a long
> time, and the documentation that I read (again, admittedly not often
> RFCs, but certainly Wikipedia, linux distro docs, etc) never mentioned
> DHCP PD, or at least never mentioned it as something important for how
> end-users would use IPv6.

Sorry, but I have some problems understanding this. AFAICT, you can't
read anything about configuring IPv6 access without seeing DHCPv6-PD
mentioned.

You referred to how OpenWrt "does it out of the box" for example.  So
just for fun, I tried to follow the most natural route from
https://openwrt.org to their IPv6 documentation for end users, which is
3 clicks from the front page to
https://openwrt.org/docs/guide-user/network/ipv6/start
where the first bullet point you see under "Native IPv6 connection" is
  * Automatic bootstrap from SLAAC, stateless DHCPv6, stateful DHCPv6,
DHCPv6-PD and any combination



Bjørn






Don't email clients have a kill file?

2020-05-14 Thread Bjørn Mork
At the risk of starting an off topic discussion here, but am I the only
one who'd like to see more plonks and less troll feeding?

I miss Usenet.


Bjørn


Re: Are underground utility markers essential workers?

2020-04-22 Thread Bjørn Mork
Nick Hilliard  writes:

> we have a very poorly-defined idea of what constitutes an "essential
> worker"

I thought "management" was the definition of non-essential workers. Who
else would have a job without being essential/critical for day-to-day
business?


Bjørn


Re: free collaborative tools for low BW and losy connections

2020-03-29 Thread Bjørn Mork
Nick Hilliard  writes:

> nntp is a non-scalable protocol which broke under its own
> weight.

How is nntp non-scalable?  It allows an infinite number of servers
connected in a tiered network, where you only have to connect to a few
other peers and carry whatever part of the traffic you want.

Binaries broke USENET.  That has little to do with nntp.

nntp is still working just fine and still carrying a few discussion
groups here and there.  And you have a really nice mailling list gateway
at news.gmane.io (which recently replaced gmane.org - see
https://lars.ingebrigtsen.no/2020/01/15/news-gmane-org-is-now-news-gmane-io/
for full story)


Bjørn


Re: Gmail email blocking is off the rails (again)

2019-12-05 Thread Bjørn Mork
"John Levine"  writes:

> Google accepts my mail just fine, including from my mailing lists.
> Their goal is to make their users happy by accepting the mail the
> users want and not the mail the users don't want.

If we rule out asking the users for every mail, then that means applying
statistics on empirical data.  The problem is that smoothing the edges
might throw away mail that the recipient care about, just because most
other users didn't.

Small players risk being blocked on the sole reason that they are too
small to make any measurable number of gmail users want their mail.



Bjørn


Re: Disney+ Streaming

2019-11-29 Thread Bjørn Mork
Sure. Like we all have been begging for an "Internet service" without
any peering...

The consumers have been begging for unbundling of content and transport.
This does not imply fragmentation of either. That's a content provider
straw man.  It is only reasonable to assume that all content providers
will see the benefit in mutual agreements for content exchange with all
other content providers.  Just like it's reasonable to assume your ISP
will let you access services hosted by some other ISP.

Of course, if ISPs wanted to make money then they would have tried to
monopolize the market by fragmentation.  Not..



Bjørn

Owen DeLong  writes:

> While I agree about the likely outcome, I will point out that consumers have 
> been
> begging for unbundling for years.
>
> This fragmentation of streaming services _IS_ the direct result of that 
> request.
>
> It’s unbundled service, exactly what they have been asking for.
>
> Owen
>
>
>> On Nov 26, 2019, at 01:54 , Mark Tinka  wrote:
>> 
>> 
>> 
>> On 12/Nov/19 22:36, Brian J. Murrell wrote:
>> 
>>> 
>>> I actually suspect streaming is going to decline (at least in
>>> comparison to where it could have grown to) if this streaming service
>>> fragmentation continues.
>>> 
>>> I think people are going to reject the idea that they need to subscribe
>>> to a dozen streaming services at $10-$20/mo. each and will be driven
>>> back the good old "single source" (piracy) they used to use before 1
>>> (or perhaps 2) streaming services kept them happy enough to abandon
>>> piracy.
>>> 
>>> The content providers are going to piss in their bed again due to
>>> greed.  Again.
>> 
>> This!
>> 
>> At the beginning of this year, I dumped Prime Video because while I
>> initially got it for "The Grand Tour", almost all the other content was
>> not available in Africa. Didn't see the point of shelling out over
>> US$100/year for just one show, especially since we already have Netflix
>> + a local linear pay TV service.
>> 
>> I bought the wife a new iPhone 11 Pro earlier this month. This got us
>> 1-year's worth of free AppleTV+. Not a lot of content so far, but I hear
>> the same about Disney+. Granted 2 of the 3 shows on TV+ are not bad. But
>> it's free, so what the heck.
>> 
>> I'm not keen on paying for more than one streaming service, if I'm
>> honest. There already isn't enough time in the world for regular life,
>> never mind watching one streaming service... now we have to deal with
>> more, each with their own price? Not sure how well the streaming
>> providers expect regular folk to take all of this fragmentation.
>> 
>> As my daughter would say, "They can miss me with it :-)".
>> 
>> Mark.
>> 


Re: BGP over TLS

2019-10-22 Thread Bjørn Mork
Christopher Morrow  writes:

> The x.509 system, to be effective here would require a TrustAnchor /
> Root-of-Trust that both parties agreed was acceptable...

As in a shared TrustAnchor?  No.  Both ends could use a simple self
signed certificate and be configured to trust the other.  A hash of the
peers public key would be sufficient for the BGP peer configuration.

Or you could use more complex PKI models, with a CA hierarchy or
whatever.  The point is that TLS doesn't force you to do that

Authenticating the peer by its public key hash is as simple as using an
TCP-MD5 password.

> To get around that you propose we hopscotch over to 'TLS with
> preshared keys (PSK)'...ok, that smells nice,

Maybe.  Personally I don't see the point.

>> My personal major gripe with certificate based systems is that many
>> routers don't have an RTC and won't know what time it is until they can
>> NTP, which likely requires protocol adjacencies, and then a dependency loop.
>
> this is also a problem, but really ... your igp should get you to an
> NTP source... or we'd all get to that fairly quickly, right? :)
>   (some of this is updating 'best practices' in building / maintaining
> a network, right?)

You may ignore notAfter and notBegin like DANE does. The ntp issue is
another reason.  But IMHO the most important one is that you don't want
any sort of forced key rotation, where the configuration that was valid
yesterday suddenly becomes invalid.  That's a policy designed for a
completely different usecase than running a routing protocol.

You'll probably want to trust your configured pinned peer key for as
long as it is part of your configuration.  And if you are using a CA,
then you'll probably want to use a CRL to withdraw specific certificates
instead of depending on a timeout.

And before someone claims that notAfter and notBegin validation is
mandated by the RFC 5280 certificate policy - The good authors of RFC
5280 anticipated that their "Internet applications" policy wouldn't
necessarily fit all:

   Some communities will need to supplement, or possibly replace, this
   profile in order to meet the requirements of specialized application
   domains or environments with additional authorization, assurance, or
   operational requirements.  However, for basic applications, common
   representations of frequently used attributes are defined so that
   application developers can obtain necessary information without
   regard to the issuer of a particular certificate or certificate
   revocation list (CRL).


BTW, using TLS for management protocols is not completely unknown.  We
already have RADSEC (RFC 6614) and syslog-tls (RFC 5425), and probably
others I haven't touched yet.  The certificate management problem is
pretty much the same for all these.  You have a closed group of
clients/servers/peers using explicitly configured sessions.  You want
both ends to authenticate each other.  You don't necessarily want an
umbrella trust anchor in the form of a CA.  Defining trust per session
is fine, using pinned certificates.


Bjørn


Re: BGP over TLS

2019-10-21 Thread Bjørn Mork
Jeffrey Haas  writes:

>  Exactly how the cert lifetime interacts with peering sessions is
>  likely to be several flavors of ugly.

If you pin the key, then there is no reason to care about expiration.
You could define the certificate as valid for as long as the pinned key
matches.  This is similar to what DANE does.


Bjørn


BGP over TLS (was: Re: "Using Cloud Resources to Dramatically Improve Internet Routing")

2019-10-21 Thread Bjørn Mork
Christopher Morrow  writes:

> isn't julien's idea more akin to DOT then DOH ?

Yes, and I really like Julien's proposal.  It even looks pretty
complete.  There are just a few details missing around how to make the
MD5 => TLS transition smooth.

Sorry for any confusion caused by an attempt to make a joke on DoH.  I
didn't anticipate the sudden turn to serious discussion :-)  Which
obviously was a good one.  I am all for BGP over TLS, so let's discuss
https://laptop006.livejournal.com/60532.html



Bjørn


Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

2019-10-20 Thread Bjørn Mork
Julien Goodwin  writes:
> On 20/10/19 11:08 pm, Bjørn Mork wrote:
>> Hank Nussbacher  writes:
>>> On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
>>>> On Fri, Oct 04, 2019 at 03:52:26PM -0400,
>>>>   Phil Pishioneri  wrote
>>>>   a message of 9 lines which said:
>>>>
>>>>> Using Cloud Resources to Dramatically Improve Internet Routing
>>>>> UMass Amherst researchers to use cloud-based ‘logically centralized
>>>>> control’
>>>> Executive summary: it's SDN for BGP. Centralizing Internet routing,
>>>> what could go wrong? (As the authors say, "One reason is there is no
>>>> single entity that has a big picture of what is going on, no
>>>> manager". I wonder who will be Internet's manager.)
>>>>
>>> Centralized Internet routing - sounds like DoH for BGP.
>> 
>> Great idea!  Why don't we just run BGP over HTTPS?  Everyone already has
>> a browser, so we can get rid of all these expensive routers.
>
> IMO BGP over TLS actually makes a bunch of sense,

Absolutely.  And so does DNS over TLS. A lot of sense.

But if you start encoding the BGP protocol data in the TLS session as
HTTP so you can tunnel it over a shared 443 port to some distant
endpoint, and even traverse HTTP proxies, then it would look like a
joke.

Or in the DoH case, would make you wish it was a joke.


Bjørn


Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

2019-10-20 Thread Bjørn Mork
Hank Nussbacher  writes:
> On 07/10/2019 17:42, Stephane Bortzmeyer wrote:
>> On Fri, Oct 04, 2019 at 03:52:26PM -0400,
>>   Phil Pishioneri  wrote
>>   a message of 9 lines which said:
>>
>>> Using Cloud Resources to Dramatically Improve Internet Routing
>>> UMass Amherst researchers to use cloud-based ‘logically centralized
>>> control’
>> Executive summary: it's SDN for BGP. Centralizing Internet routing,
>> what could go wrong? (As the authors say, "One reason is there is no
>> single entity that has a big picture of what is going on, no
>> manager". I wonder who will be Internet's manager.)
>>
> Centralized Internet routing - sounds like DoH for BGP.

Great idea!  Why don't we just run BGP over HTTPS?  Everyone already has
a browser, so we can get rid of all these expensive routers.

The future is BoH


Bjørn


Re: Elad Cohen

2019-09-19 Thread Bjørn Mork
Jon Sands  writes:
> On 9/19/2019 6:12 AM, Ronald F. Guilmette wrote:
>>
>> I just want to ruling on this.  Am I the first and only person who has ever
>> received a cartooney directly on the NANOG list?
>
> I can't remember if it was over NANOG or not, but back in 2010 a good
> friend of mine Mike Bailey (now deceased) received similar bold faced
> legal threats (mostly threats of DMCA if I remember right) from FDC
> Servers when he exposed to the WHT forums that they were at the time
> using power strips daisy chained, motherboards sitting on cardboard,
> etc in their chicago datacenter - he documented with pictures a number
> of fire code violations and was threatened with DMCA notices for
> it. Sadly the pictures no longer load, but oh boy were they special:
> https://web.archive.org/web/20100228172939/http://ub3r.net/fdc/readme.htm

You can see one of those pics here:
https://itknowledgeexchange.techtarget.com/IT-watch-blog/fdcservers-colocation-data-center-gives-new-life-to-the-term-boxen/

> I do agree though, this should probably be taken way off-list.

Sure.  But there is still some popcorn left ;-)


Bjørn



Re: Mx204 alternative

2019-09-02 Thread Bjørn Mork
Mark Tinka  writes:

> The MX80 and MX104 have no business being in any modern conversation
> these days :-).

Except for the other MX-80, of course, which are better than ever.
https://en.wikipedia.org/wiki/MX-80


Bjørn


Re: Protecting 1Gb Ethernet From Lightning Strikes

2019-08-14 Thread Bjørn Mork
Måns Nilsson  writes:

> /Måns, has 6 pairs 9/125 between garage and house at home. 

Now you made me worry that my single OM4 pair to the garden shed might
be insufficient ;-)


Bjørn


Re: SFP supplier in Europe?

2019-04-05 Thread Bjørn Mork
nanog-...@mail.com writes:

> Unfortunately Fiberstore is what led me to ask about alternative
> suppliers. Fiberstore actually ships in their Bidi SFPs from Asia


Odd. They have lots of different BiDi SFFs "in Stock, EU Warehouse"
according to https://www.fs.com/de-en/c/bidi-sfp-89

> and lead times are one to two weeks.

My experience is that they ship a lot faster than that from Asia too,
but I guess I've just been lucky.


Bjørn


Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

2019-03-05 Thread Bjørn Mork
Stephen Satchell  writes:

> On 3/5/19 2:54 AM, Thomas Bellman wrote:
>> Out of curiosity, which operating systems put anything useful (for use
>> in ECMP) into the flow label of IPv6 packets?  At the moment, I only
>> have access to CentOS 6 and CentOS 7 machines, and both of them set the
>> flow label to zero for all traffic.
>
> Did you submit a bug report?

I believe this was fixed 5 years ago (in Linux v3.17):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73

But RHEL and CentOS are using kernels from the stone age, so they
haven't noticed yet.


Bjørn


Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

2019-02-28 Thread Bjørn Mork
Måns Nilsson  writes:

> NS5
>   21
> DNSKEY3
> SPF   1
> A 28
> NSEC  62
> AFSDB 3
> RP1
> MX2
> CNAME 9
> SOA   2
> RRSIG 147
> TXT   6
> SSHFP 14
> SRV   20
> DS4
> Total:16 rrtypes in zone

No TLSA records? 


Bjørn


Re: A Deep Dive on the Recent Widespread DNS Hijacking

2019-02-26 Thread Bjørn Mork
Bill Woodcock  writes:

> We need to get switched over to DANE as quickly as possible, and stop
> wasting effort trying to keep the CA system alive with ever-hackier
> band-aids.

Sure. Just won't happen as long as there is money left in the CA
business.


Bjørn


Re: sendmail.cf

2019-02-22 Thread Bjørn Mork
b...@theworld.com writes:

> The predecessor to sendmail was delivermail, 1979, also written by
> Eric Allman.
>
>   https://en.wikipedia.org/wiki/Delivermail

Damn.  Now you made me read RFC801 and wonder why we didn't have an
updated version for the IPv6 transition.  Or: Where would the Internet
have been today without that very explicit "complete switch over" goal?


Bjørn


Re: DNS Flag Day, Friday, Feb 1st, 2019

2019-01-24 Thread Bjørn Mork
Mark Andrews  writes:

> I’ve been complaining for YEARS about lack of EDNS compliance.

Didn't help.

bjorn@miraculix:~$  dig +edns=42 +noednsnegotiation @1.1 

; <<>> DiG 9.11.5-P1-1-Debian <<>> +edns=42 +noednsnegotiation @1.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40525
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   9060IN  NS  d.root-servers.net.
.   9060IN  NS  e.root-servers.net.
.   9060IN  NS  f.root-servers.net.
.   9060IN  NS  g.root-servers.net.
.   9060IN  NS  h.root-servers.net.
.   9060IN  NS  i.root-servers.net.
.   9060IN  NS  j.root-servers.net.
.   9060IN  NS  k.root-servers.net.
.   9060IN  NS  l.root-servers.net.
.   9060IN  NS  m.root-servers.net.
.   9060IN  NS  a.root-servers.net.
.   9060IN  NS  b.root-servers.net.
.   9060IN  NS  c.root-servers.net.

;; Query time: 3 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Jan 24 14:40:00 CET 2019
;; MSG SIZE  rcvd: 431



Bjørn


Re: the e-mail of the future is the e-mail oft the past, was Enough port 26 talk...

2019-01-15 Thread Bjørn Mork
Miles Fidelman  writes:

> Ever since the net went commercial, we've been seeing more and more
> walled gardens - driven by folks with an economic advantage to
> segmenting & capturing audiences.  Whenever someone talks about how
> great some new technology is, I'm always reminded to "follow the
> money."  (And ain't it ironic that Microsoft supports calendaring
> protocols, while Google breaks them.)

And this is happening to email too.

It's not IM or online conferencing that will kill email, but
fragmentation into multiple closed email environments. We accept SPF and
DMARC, abusing DNS to deliberately break SMTP. All in the name of spam
protection, Mailing lists barely work anymore and have to resort to
hacks to be able to forward messages to their recipients.  Traditional
forwarding to another account hasn't worked in years. Smaller providers
are regularily blocked causing service disruption to their users.

It's just a matter of time before the big players, well known for their
disregard of open protocols, just shut off SMTP completely. They'll
probably "invent" something much better as an excuse... And the masses
will love them for that, because it finally removed the spam "problem".

And everyone has a gmail account anyway, so why bother with outside
email?



Bjørn


Re: Enough port 26 talk...

2019-01-13 Thread Bjørn Mork
Yes.  What is all the fuzz about?  Email will be as dead as USENET in a
couple of years anyway.

Welcome to the age of "feeds".  You may cry now.


Bjørn


Re: WIndows Updates Fail Via IPv6

2018-11-13 Thread Bjørn Mork
John Von Essen  writes:

> I recently go a Linksys home wifi router, by default it enables ipv6
> on the LAN. If there is no native IPv6 on the WAN side (which is my
> case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.

Could this be a 6RD tunnel requested by your ISP using DHCP with
OPTION_6RD? Ref RFC5969

Setting up any tunnel to some pre-configured endpoint by default does
not sound like a good idea  But DHCP on the WAN side is "trusted",
so configuring a DHCP requested tunnel by default is reasonable.

> For the first few weeks of using the router, I had no idea alot of my
> traffic was going out via the v6 tunnel.
>
> Then I started getting random reachability and availability
> issues. Google would not load, but Bing and Yahoo would, and so on. I
> thought it was a FiOS issue, but after digging, I discovered the v6
> tunnel, disabled it and all my issues went away.
>
> I dont know what Linksys uses for the v6 tunnel because its buried in
> the firmware, but any tunnel service is vulnerable to a variety of
> issues that could effect access. Its odd that it always effects
> Windows update all the time, but who knows.

It would be great to have more details about this default tunnel setup.
Can't you sniff the traffic?

Anyway:  Thanks for yet another argument for native dual-stack.
Avoiding such unwanted tunnels is really simple:

If you're an ISP:
  Offer native dual-stack to your Internet access customers.

If you're an Internet access customer:
  Request native dual-stack from your ISP

Problem solved.


Bjørn


Re: bloomberg on supermicro: sky is falling

2018-10-12 Thread Bjørn Mork
"Naslund, Steve"  writes:

> It only proves that you have seen the card at some point.  Useless.

It doesn't even prove that much.  There is nothing preventing a rogue
online shop from storing and reusing the CVV you give them.  Or selling
your complete card details including zip code, CVV and whatever.

In practice, the CVV is just 3 more digits in the card number. No
security whatsoever in that.


Bjørn


Re: Service provider story about tracking down TCP RSTs

2018-09-02 Thread Bjørn Mork
William Herrin  writes:

> On Sun, Sep 2, 2018 at 6:06 AM, Bjørn Mork  wrote:
>> William Herrin  writes:
>>>  https://bill.herrin.us/network/anycasttcp.html
>>
>> I didn't see a security section in your document.  Did you consider the
>> side effects of this sequence number abuse?
>
> Hi Bjørn,
>
> In the "issues and criticisms" section.

I can see the effect on syn cookies being disussed there, but I don't
think that covers all concerns wrt more predicatable sequence numbers.

See RFC6528, including its references.


Bjørn


Re: Service provider story about tracking down TCP RSTs

2018-09-02 Thread Bjørn Mork
William Herrin  writes:

> BTW, for anyone concerned about an explosion in state management
> overhead, the TL;DR version is: the anycast node which first accepts
> the TCP connection encodes its identity in the TCP sequence number
> where all the other nodes can statelessly find it in the subsequent
> packets.

I didn't see a security section in your document.  Did you consider the
side effects of this sequence number abuse?


Bjørn


Re: Email security: PGP/GPG & S/MIME vulnerability drop imminent

2018-05-15 Thread Bjørn Mork
Brian Kantor  writes:

> On Tue, May 15, 2018 at 05:34:31AM -0400, Rich Kulawiec wrote:
>> On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote:
>> > TL;DR = Don't use HTML email [snip]
>> 
>> That's enough right there.  HTML markup in email is used exclusively
>> by three kinds of people: (1) ignorant newbies who don't know any
>> better (2) ineducable morons who refuse to learn (3) spammers.
>> There are no exceptions.
>> 
>> ---rsk
>
> Ah, if it only were those.  But the infestation has spread; nearly
> every corporate communication these days is polluted by HTML, with
> a very high percentage of that containing no content other than
> hyperlinks that say, in one form or another, "click on this link
> to read your message."

I don't see any contradiction here.

> Banks especially.

All three combined.


Bjørn


Re: IPv4 and IPv6 hijacking by AS 6

2018-04-14 Thread Bjørn Mork
Randy Bush  writes:

>> I believe we've seen bogus low AS number announcements a few times
>> before, and they've usually been caused by attemts to configure
>> AS path prepending without understanding and/or reading the docs.
>> 
>> Someone might have wrongly assumed that
>> 
>>set as-path prepend 133711 133711
>> 
>> could be written shorter like
>> 
>>set as-path prepend 133711 2
>> 
>> and there you go...
>
> for someone else's prefix?

No, of course not. At least I have no reason to beliece so.

I briefly looked at a couple of the examples Anurag posted.  And for
those, the next AS number in the path seemed consistent with the prefix
owner:

*   43.227.224.0/24  208.51.134.254   0 0 3549 3356 6453 
4755 133711 133711 133711 2 i
*   91.143.144.0/20  208.51.134.254   0 0 3549 3356 12389 
41837 41837 2 i


bjorn@miraculix:~$ whois 43.227.224.0/24 |grep origin
origin: AS133711
origin: AS58965

bjorn@miraculix:~$ whois 91.143.144.0/20  |grep origin
origin: AS41837



Bjørn


Re: IPv4 and IPv6 hijacking by AS 6

2018-04-13 Thread Bjørn Mork
Anurag Bhatia  writes:

> Similar for AS2.

I believe we've seen bogus low AS number announcements a few times
before, and they've usually been caused by attemts to configure
AS path prepending without understanding and/or reading the docs.

Someone might have wrongly assumed that

   set as-path prepend 133711 133711

could be written shorter like

   set as-path prepend 133711 2

and there you go...




Bjørn


Re: Why doesn't "Cloudflare 1.1.1.1" compress root answers?

2018-04-05 Thread Bjørn Mork
Anurag Bhatia  writes:

> Never realised of such compression on answered. Is this is something well
> documented? Curious.

https://tools.ietf.org/html/rfc1035#section-4.1.4


Bjørn


Why doesn't "Cloudflare 1.1.1.1" compress root answers?

2018-04-03 Thread Bjørn Mork
At first I thought they had disabled compression:

 bjorn@miraculix:~$ dig . ns @1.1.1.1|grep SIZE
 ;; MSG SIZE  rcvd: 431
 bjorn@miraculix:~$ dig . ns @8.8.8.8|grep SIZE
 ;; MSG SIZE  rcvd: 239
 bjorn@miraculix:~$ dig . ns @9.9.9.9|grep SIZE
 ;; MSG SIZE  rcvd: 239


But then I noticed that they *do* compress other names:

 bjorn@miraculix:~$ dig net ns @1.1.1.1|grep SIZE
 ;; MSG SIZE  rcvd: 253
 bjorn@miraculix:~$ dig net ns @8.8.8.8|grep SIZE
 ;; MSG SIZE  rcvd: 253
 bjorn@miraculix:~$ dig net ns @9.9.9.9|grep SIZE
 ;; MSG SIZE  rcvd: 253


Which just makes it even more confusing.  What's so special about root?
Except for the obvious :-)



Bjørn



Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

2018-03-02 Thread Bjørn Mork
Owen DeLong <o...@delong.com> writes:

>> On Mar 2, 2018, at 3:17 AM, Bjørn Mork <bj...@mork.no> wrote:
>> 
>> Owen DeLong <o...@delong.com> writes:
>> 
>>> What can you do with ULA that GUA isn’t suitable for?
>> 
>> 1) get
>> 2) keep
>> 3) move
>
> Wrong.
>
> 1) get
>   Easy as going to http://tunnelbroker.net <http://tunnelbroker.net/> and 
> filling out a form. Remember to check the box for your /48.

Provided you have IPv4 connectivity and an email address you can and
will associate with the tunnel/prefix.  You are limiting the scope here.

> 2) keep
>   Admittedly, you might have to connect to your tunnel every once in a 
> while to keep it alive, but that’s
>   hardly a high bar.

Depends.  How about preconfigured devices in storage?  There are a
number of use cases where outside connectivity does not matter, and
where depending on regular connections will complicate stuff.

> 3) move
>   If you’re not talking to the internet with it (which you can’t with 
> ULA, theoretically), you can move that same
>   HE /48 anywhere you want, with the additional advantage that you can, 
> if you need to, connect your tunnel
>   and actually make it work on the internet too.

Sure. There is also a long tradition in IPv4 for "borrowing" someone
elses addresses.  It is never a good idea.  You or anyone else cannot
make any guarantee about HE address availability at any point in time or
space.

You may also want to consider https://www.tunnelbroker.net/tos.php


>> Granted, many of us can do that with GUAs too.  But with ULA those
>> features are avaible to everyone everywhere.  Which is useful for a
>
> You really think that doing ULA according to the RFCs (collision
> avoidance algorithm and all) is easier than filling out a form at HE?
> REALLY?

Yes.

You are comparing apples and orange seeds.  If you don't want to
construct your tunnel from the RFCs, then you cannot require ULA users
to start there either,

The ULA equivalent of the HE tunnel form is an ULA calculator. E.g
http://www.kame.net/~suz/gen-ula.html

Which is much simpler.  At least it looks simpler to me.

But it doesn't really matter.  The main point is that ULAs are usable in
many cases where HE (or other ISP allocated) GUAs are not. If you don't
care about Internet connectivity, then ULAs are as good as PI GUA space.

Believe it or not, but there are still devices and networks where
Internet connectivity is either optional or even unwanted.  These
devices and networks still need addresses for their internal
communcation.

>> number of applications where you care mostly about the local environment
>> and not so much about global connectivity.
>
> I hear you, but I’m not convinced about the ease.

When was the last time you saw a non RFC1918 address in a consumer
equipment setup guide?  If we consider the distant future where IPv4 is
long dead and buried, what is default configuration URL is going to
replace http://192.168.1.1/ and similar?

IoT might be a thing for a while until people start worrying about where
they store their data.  I'm sure local sensor networks will become
popular again once the hype is over.

Many ISPs make more money on providing network accesses which are
isolated from the Internet than actually providing Internet access

More and more systems are made up of networked subsystems.  Take a look
at your average core router for example. These susbsystems need
addresses.  But you rarely want them to connect to the Internet.

One can easily imagine future PC or handheld systems where internal
buses like I2C and USB (when used to connect *internal* lowspeed
components like fingerprint readers etc) have been replaced by IP over
ethernet.

Just to name a few applications I can think of here and now.  There are
many many more.

I'm not claiming that ULAs are the answers to all these.  There are
certainly reasons why you might want GUAs instead.  But these are cases
where the main disadvantage of the ULAs - The lack of Internet
connectivity - does not matter, or is even turned into an advantage.




Bjørn


Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

2018-03-02 Thread Bjørn Mork
Owen DeLong  writes:

> I don’t agree that making RFC-1918 limitations a default in any daemon makes 
> any
> sense whatsoever.

+1

One of the more annoying anti-features I know of in this regard is the
dnsmasq rebind "protection".  It claims to protect web browsers on the
LAN against DNS rebind attacks.  But the implementation does not
consider which adresses are used on the LAN at all.  It simply blocks
any A record pointing to an RFC1918 address, making a few bogus
assumptions:
- IPv4 LAN addresses are selected from RFC1918
- RFC1918 addresses are never used on the WAN side of a CPE
- Noone use IPv6 on their LAN

It's hard to know how many users have been bitten by the first
one. You'd have to depend on this rebind "protection" in the first
place, and that would be stupid.

But the second assumption regularily bites end users when their ISP
provides some ISP internal service using RFC1918 addresses.  Which of course
is fine.

The anti-feature has been enabled by default in OpenWrt for a long time,
ref https://wiki.openwrt.org/doc/uci/dhcp#all_options , which means that
there is a large user base having this enabled without knowing.

> First, there are plenty of LANs out there that don’t use RFC-1918.
>
> Second, RFC-1918 doesn’t apply to IPv6 at all,

Could you try to explain that to the OpenWrt guys?  Thanks



Bjørn


Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

2018-03-02 Thread Bjørn Mork
Owen DeLong  writes:

> What can you do with ULA that GUA isn’t suitable for?

1) get
2) keep
3) move

Granted, many of us can do that with GUAs too.  But with ULA those
features are avaible to everyone everywhere.  Which is useful for a
number of applications where you care mostly about the local environment
and not so much about global connectivity.


Bjørn


Re: Incoming SMTP in the year 2017 and absence of DKIM

2017-11-30 Thread Bjørn Mork
Steve Atkins <st...@blighty.com> writes:

>> On Nov 30, 2017, at 1:22 AM, Bjørn Mork <bj...@mork.no> wrote:
>> 
>> "John Levine" <jo...@iecc.com> writes:
>> 
>>> Broken rDNS is just broken, since there's approximately no reason ever
>>> to send from a host that doesn't know its own name.
>> 
>> rDNS is not a host attribute, and will therefore tell you exactly
>> nothing about the host.
>
> It tells you something about the competence of the operator and
> whether the host is intended by the owners to send email.

No.  It only tells you something about the administrative split between
IP address management and host management.

There is no way my laptop is going to be able to update the rDNS for all
addresses it will use in different networks.  This does in no way affect
its MTA configuration.

> Or, for a more empirical way to look at it, there's reasonable correlation
> between having missing, generic or incorrect reverse DNS and the host
> being a source of unwanted or malicious email.

Really?  Where did you get those numbers?  This is a myth.  Spam sources
are average Internet hosts.  The split between working and non-working
rDNS is mostly between IPv4 and IPv6, not between ham and spam.  And if
there is some correlation there, then I'd say that an IPv4 host is more
likely to be a spam source than a dual stack or IPv6 only host.



Bjørn


Re: Incoming SMTP in the year 2017 and absence of DKIM

2017-11-30 Thread Bjørn Mork
"John Levine"  writes:

> Broken rDNS is just broken, since there's approximately no reason ever
> to send from a host that doesn't know its own name.

rDNS is not a host attribute, and will therefore tell you exactly
nothing about the host.


Bjørn



Re: Google DNS intermittent ServFail for Disney subdomain

2017-10-20 Thread Bjørn Mork
David Sotnick  writes:

> Gotta love it when a problem is solved, by the OP, within an hour of
> resorting to mailing the NANOG community.

That's the way it is.  Posting to a public forum always make you think
about the issue a second time, and that's what it takes.

The weird thing is that I've tried to cheat the system by thinking
without posting, and it doesn't work!  Don't know why, but there appears
to be a difference between thinking and thinking :-)

Thanks a lot for posting the solution.


Bjørn


Re: BGP Optimizers

2017-09-01 Thread Bjørn Mork
Job Snijders  writes:

> Using a BGP
> optimizer is essentially trading a degree of risk to society for the
> purpose of saving a few bucks or milliseconds. It is basically saying:
> "The optimizer helps me, but may hurt others, and I am fine with that".

People drive SUVs.


Bjørn


Re: Google DNS --- Figuring out which DNS Cluster you are using

2017-08-24 Thread Bjørn Mork
Stephane Bortzmeyer  writes:

> On Thu, Aug 24, 2017 at 10:53:58AM +1000,
>  Mark Andrews  wrote 
>  a message of 39 lines which said:
>
>> If Google was being sensible the servers would just return the
>> information along with the answer.  They all support EDNS.
>
> I fully agree with you that NSID (RFC 5001) is great and Google should
> really deploy it.

+1 for NSID! Should be mandatory for anycast DNS, IMHO.  I don't
understand why Google haven't enabled it.


> However:
>
>> e.g. dig +nsid @8.8.8.8
>
> I assume that Google wants also to be debuggable by people who work on
> inferior operating systems, and have no dig. Hence this trick. For
> instance, L.root-servers.net has both NSID and a special name,
> identity.l.root-servers.org (see RFC 7108).

As you state, there is no problem providing both.  Or an infinite number
of special names if they like.  But NSID provides something none of the
special names can.  Quoting the justification in the intro of RFC5001:

   Given that a DNS query is an idempotent operation with no retained
   state, it would appear that the only completely reliable way to
   obtain the identity of the name server that responded to a particular
   query is to have that name server include identifying information in
   the response itself.


Sometimes it just isn't enough to know which server answered the
previous or next requests.



Bjørn


Re: Some advice on IPv6 planning and ARIN request, please

2017-07-11 Thread Bjørn Mork
Mark Andrews  writes:

> If I had 32 departments and were wanting to give them equal sized
> allocations then I'd give them a /53 each which is 2064 subnets
> each.  It isn't that hard to do 8 delegations in the reverse tree
> for each of the 32 departments.  Delegation on nibble boundaries
> is for convience and nothing else.

I believe you under-estimate the importance of sysadmin convenience...

Yes, you *can* do 8 delegations.  And you are of course right - it's not
even hard.  But it does come with a "less convenient" price tag, so
you'd better get something back.  What was that, exactly?  Right, you
saved a /48.  Big deal.


Bjørn


Re: Some advice on IPv6 planning and ARIN request, please

2017-07-09 Thread Bjørn Mork
"Radu-Adrian Feurdean"  writes:

> No, but I assume IPv6 is still subject to common-sense.

I don't see how you can make that assumption.

If common sense had been applied, then people would have realized that
there are more important parameters than address conservation to
consider when it comes to IPv6 planning/design/discussions/whatever.



Bjørn


Re: Question to Google

2017-05-15 Thread Bjørn Mork
Todd Underwood  writes:
> On Mon, May 15, 2017 at 8:43 AM, Stephane Bortzmeyer 
> wrote:
>
>>
>> There are many zones (including your isc.org) that have several name
>> servers dual-stacked, and they didn't notice a problem. Furthermore,
>> since the DNS is a tree, resolution of google.com requires a proper
>> resolution of the root and .com, both having IPv6 name servers.
>>
>
> "didn't notice a problem" is woefully insufficient here.
>
> how carefully was this measured?  how was it measured?  across what
> diversity of traffic.  what was the threshold for "a problem" here.

Agreed.  Most domain owners/zone admins probably would not notice this,
even if it was a very real problem for one or two ISPs.

But given that, I do wonder how such an ISP could provide any service at
all. As pointed out by Stephane, there are so many zones having dual
stacked DNS servers nowadays that one more or less makes little
difference.  Even if that zone is google.com.  The rest of the world are
dual stacked wrt DNS, with very few exceptions.

What about the root zone?  Or microsoft.com?  Or facebook.com?  No users
interested in either of those?  Only google.com?

Sorry, I do not buy the excuse.



Bjørn


Re: BCP for securing IPv6 Linux end node in AWS

2017-05-14 Thread Bjørn Mork
Alarig Le Lay  writes:

> So, my advise is simply to not filter ICMP and ICMPv6. And by the way,
> why do want to filter ICMP? You will not be DDoSed with pings.


I tend to agree.  But if you still want to do it, then there is some
advice in https://tools.ietf.org/html/rfc4890


Bjørn


Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations

2017-03-17 Thread Bjørn Mork
William Herrin  writes:
> On Fri, Mar 17, 2017 at 7:52 AM, Romeo Zwart  wrote:
>> RIPE NCC have issued a statement about the issue here:
>>
>>  https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>>
>> Our apologies for the inconvenience caused.
>
> Hmm. That sounds like an ARIN-side bug too. ARIN's code responded to
> corrupted data by zeroing out the data instead of using the last known good
> data. That's awfully brittle for such a critical service.

Well, it was a nice smoke test of the "RDNS required" anti-feature.  All
of a sudden we couldn't even send email to ourselves, having smarthosts
in one of the affected zones. Nice.

Maybe time to re-evaluate the usefulness of that config...



Bjørn



Re: IPv6 Residential Deployment Survey

2016-05-23 Thread Bjørn Mork
Got as far as the second page, where I was met by the question

  "What technology is used for the customer link ?
   Choose one of the following answers "

Come on... One technology per ISP?  In what world is that?



Bjørn




John Curran  writes:

> NANOGers -
>
> If you are providing residential Internet service with IPv6 (or
> are a customer of same), please take a moment to complete
> Jordi’s survey - this will help provide insight into the actual
> technical practices being used in residential IPv6 deployment.
>
> More details in attached email - Thanks!
> /John
>
>
> Begin forwarded message:
>
> From: John Curran >
> Subject: [arin-ppml] IPv6 Residential Deployment Survey
> Date: May 22, 2016 at 6:24:17 AM GMT+2
> To: ARIN PPML >
>
> Folks -
>
> Jordi Palet Martínez is conducting a brief survey regarding IPv6 
> deployment
> in residential Internet service.   Having insight into the various 
> practices that
> are in use may help to inform IPv6 number resource policy development, and
> thus I ask that you take a moment to complete the survey if you are 
> providing
> such services (whether production or trial basis.)
>
> Jordi notes -
>
> "The results will be published and updated every month or so -
>   No personal data will be published.
>
>   (If you know your network, it takes less than 2 minutes to complete 
> it)
>   The survey can be responded even if is not yet a commercial service,
>   and customers can also respond, not just the ISP. However, to avoid
>   duplicate data, make sure to include the country and ISP name.”
>
>  The IPv6 Residential Deployment Survey may be found here -
> 
>
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN


Re: Stop IPv6 Google traffic

2016-04-11 Thread Bjørn Mork
b...@theworld.com writes:

> It seems like every technical list is over-run with
> meta-conversations, how do I (blah), WHY WOULD YOU WANT TO (blah)?!?!

It is reasonable to expect anyone asking for help to describe the
process leading up to the situation where they are stuck.  I'd say it is
rare that such an explanation can be given without describing the
original problem.

If you are worrying about these meta discussions, then I'd suggest
killng them off in the first place by simply answering the questions
before they are asked.



Bjørn


Re: IPV6 planning

2016-03-08 Thread Bjørn Mork
Owen DeLong  writes:
>> On Mar 7, 2016, at 16:01 , Alarig Le Lay  wrote:
>> 
>> It’s not exactly specific to Windows, dhcpcd use a something like that
>> (my IPv6 is 2a00:5884:8316:2653:fd40:d47d:556f:c426). And at least,
>> there is a RFC related to that, https://tools.ietf.org/html/rfc7217.
>
> Yes, but in the case of Windows, that happens with SLAAC without DHCP.

Yes, and SLAAC is what rfc7217 is about

> TTBOMK, this is unique to windows.

Nope.  See for example the stable_secret setting in
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

But Linux doesn't create this in addition to the EUI-64 derived
address.  It creates in instead.  And it won't happen by default.  Only
if you configure a secret. Except for weird interfaces without any
EUI-64 identifier, like raw IP interfaces, which will use this code to
support SLAAC.

How does Windows manage to *use* three addresses? I can understand how
the rfc7217 address and the privacy address can be use for different
purposes, but what do they use the EUI-64 address for?


Bjørn


Re: Devices with only USB console port - Need a Console Server Solution

2016-02-02 Thread Bjørn Mork
Erik Sundberg  writes:

> Just some follow up on this one. I have also posed in the C-NSP list
>
> Yes you do need to have this kit to have serial console, No a normal
> USB-DB9 Console adapters do not work.

Which could be because the driver for that particular Console adapters
is missing.  Or even that the driver is there, but recognizing specific
Cisco device IDs only.  As you are probably aware, there are no standard
USB-DB9 Console adapters.  They are all vendor specific.  But the
cloning industry has created a few semi-standards based on specific
chipsets.

> Here are some pictures of the ASR920 Console kit A920-CONS-KIT-S

No inside pictures :)

Assuming that this is really an USB device, and that the console port is
really an USB host port, it would be useful to know the USB decriptors
of the device.  You wouldn't be willing to connect it to a Linux PC and
run "lsusb -vd", would you?


Bjørn


Re: Devices with only USB console port - Need a Console Server Solution

2016-02-02 Thread Bjørn Mork
Christopher Morrow  writes:

> seems like a total improvement swapping 1 well known, simple cable for 
> 2...
>
> hurray progress?

The USB port is probably cheaper than anything else. And it gives them
more flexibility.  No need for both an RS232 and Ethernet console port.
The USB port can be both, depending only on driver/application support
on the router.  And you have other options as well. Wifi console maybe?
Or a direct USB-USB cable (with the necessary logic to appear as a
device to both ends).

It is also possible to create USB only console servers, if the market
wants that.  Avoiding two RS232 conversions per console port will save
enough capacitors to run a Tesla.

Whether these alternatives become available is of course up to Cisco.
You do need the driver and application support on the router.  Time will
show what they come up with.


Bjørn


Re: Equipment Supporting 2.5gbps and 5gbps

2016-01-30 Thread Bjørn Mork
"Alex Hargrove"  writes:

> I just purchased some empty Intel X520-DA2 cards and then picked up
> the E10GSFPSR-compatible optics for them from Fiberstore.

Note that this requirement is implemented in the driver.  YMMV depending
on OS, but in Linux you can disable it with the usual warnings by
setting 'allow_unsupported_sfp=1' :

 bjorn@canardo:~$ modinfo -p ixgbe
 max_vfs:Maximum number of virtual functions to allocate per physical function 
- default is zero and maximum value is 63. (Deprecated) (uint)
 allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 
82599-based adapters (uint)
 debug:Debug level (0=none,...,16=all) (int)


Bjørn


Re: SMS gateways

2016-01-12 Thread Bjørn Mork
Adam Kennedy  writes:

> I picked up two of the AT "Beam" USB devices that use the LTE network.
> Netgear is the listed manufacturer and has firmware for the units that
> makes them usable on Linux. I loaded the driver for those into a Debian box
> and I'm able to use smstools open source software to send SMS from the unit
> directly to cell network. The AT Beam's were $20 I think and cost us
> about $15/mo as additional lines on our corporate plan.

Note that messaging in LTE networks tend to use IP, just like voice in
LTE networks.  It seems a little awkward having to use an LTE device
just to set up a dedicated IP VPN for SMS delivery if you have any other
fixed IP access at the site...

But I guess hiding all the nasty IMS implementation details in the LTE
module firmware, controlling it by standard GSM AT commands, has some
benefit here.  At least the firmware source code is unavailable so you
don't see how hideous it is :)


Bjørn


Re: Deploying IPv6 in an ISP network [ was: Best Source for ARIN Region /24 ]

2016-01-12 Thread Bjørn Mork
Baldur Norddahl  writes:

> Note that 12 is "0b" in hexadecimal.

Only when gravity is negative IIRC.


Bjørn


Re: Looking for Yahoo eMail contact

2016-01-11 Thread Bjørn Mork
Elizabeth Zwicky via NANOG  writes:

> "permanently deferred"

Does not compute :)


Bjørn


Re: IPv4 shutdown in mobile

2015-12-27 Thread Bjørn Mork
Mikael Abrahamsson  writes:

> North America is by far the leader in number of IPv6 enabled customers
> which
>
> https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html#networks
>
> shows.

On the top ten country list, I see

 6 European countries (Belgium, Germany, Luxembourg, Estonia, France, Norway)
 1 African country (Liberia)
 1 North American country (USA)
 1 Oceanian country (Kiribati)
 1 Asian country (Malaysia)

Looks like Europe is way ahead to me :)


Bjørn


Re: Nat

2015-12-22 Thread Bjørn Mork
Owen DeLong  writes:
>> On Dec 20, 2015, at 08:57 , Mike Hammett  wrote:
>
>> The idea that there's a possible need for more than 4 bits worth of
>> subnets in a home is simply ludicrous and we have people advocating
>> 16 bits worth of subnets. How does that compare to the entire IPv4
>> Internet?
>
> I have more than 16 subnets in my house, so I can cite at least one
> house with need for more than 4 bits just in a hand-coded network.
>
> Considering the future possibilities for automated topological
> hierarchies using DHCP-PD with dynamic joining and pruning routers, I
> think 8 bits is simply not enough to allow for the kind of flexibility
> we’d like to give to developers, so 16 bits seems like a reasonable
> compromise.

Thanks for summarizing why /48 for everybody is possible.  But I fear
that is not helping much against arguments based on "need". I believe it
is difficult to argue that anyone needs any IP address at all, given
that there are lots of people in the world who seem to survive just fine
without one...

So, with that sorted out, let's consider what you can do with 16 bits of
subnets.  One example is checksum neutral prefix translation (RFC6296)
without touching the interface id bits . Let's say you have two upstream
ISPs handing you the prefixes A/48 and B/56.  Neither offer any
multihoming support to residential users and both do BCP38 of course. So
you use B/56 internally and do prefix translation to allow your router
to select upstream without involving the clients.  Thanks to the A/48
from the first ISP, you are able to choose a set of 256 (or possibly 255
since 0x cannot be used) checksum neutral subnet pairs.

Yes, I know. Evil. No need. No CPE support.  Etc.

The important part is that 16 bits of subnets is enough to play
algorithmic tricks with the subnet part of your address too, whereas
this is much more difficult with fewer bits.  No, you don't need to do
it.  But you CAN.  The sparse IPv6 addressing model is about opening up
possibilities.  Note that those possibilities includes restricting
yourself to using a single address.  You don't have to use all your 2^80
addresses :)

And for the ISPs, using /48 for every user means fewer prefix lengths to
consider for routing and address management. Sure, we manage diverse
prefix lengths in IPv4 today, but why not take advantage of this
possible simplification if we can? Only those living on bugs will object
to simpler address databases and routing filters.


Bjørn


Re: DHCPv6 PD & Routing Questions

2015-11-26 Thread Bjørn Mork
Mark Andrews  writes:

> The DHCP server usually is sitting
> in a data center on the other side of the country with zero ability
> to inject approptiate routes.

Not too sure about that.  At least, that's not what we do.  We run the
DHCPv6 and DHCP servers on our BNGs (or BRAS or whatever the current
buzzword for "access router" is).  So the "servers" have full control
of both DHCP/DHCPv6 and routing.

The DHCP backend database may need to be centralised, but tunneling the
DHCP protocol all they way through your network just to achieve that
seems unnecessarily risky and error-prone.  Moving the DHCP frontends as
close as possible to the clients is a very simple way to make DHCP
scalable and robust. If you feel you should have a DHCP server in more
than one site for robustness, then you might as well do a fully
distributed design.  Going half-way, centralising everything and then
dividing it on multiple datasenters is just ten times the trouble..

If you only do pool-based arbitrary address allocations, then you might
not need a centralised database at all.  Distribute your prefixes to the
BNGs and let them manage the pools independently of each other.

> The DHCP relay could also have injected routes but that is a second
> class solution.

DHCP relays *are* second class solutions :)  Unfortunately they cannot
always be avoided in the semi-L2-environments like ISP access networks
often are.


Bjørn


Re: DHCPv6 PD & Routing Questions

2015-11-25 Thread Bjørn Mork
Mark Andrews  writes:

> This isn't rocket science.  Just use your @#!Q$# brains when you build
> CPE routers.

Right... Still waiting for the first CPE built like that :)


Bjørn


Re: Advance notice - H-root address change on December 1, 2015

2015-11-17 Thread Bjørn Mork
Mark Andrews  writes:

> The [func] below are bug fixes / security fixes.

Umh, using a very relaxed definition maybe...

I was very happy to see this feature added in 9.9.8, and I can certainly
agree that it is security related.  But I hardly think it is suitable
for the strict "no new features" policy that many stable distros
enforce:


> +3938.[func]  Added quotas to be used in recursive resolvers
> + that are under high query load for names in zones
> + whose authoritative servers are nonresponsive or
> + are experiencing a denial of service attack.
> +
> + - "fetches-per-server" limits the number of
> +   simultaneous queries that can be sent to any
> +   single authoritative server.  The configured
> +   value is a starting point; it is automatically
> +   adjusted downward if the server is partially or
> +   completely non-responsive. The algorithm used to
> +   adjust the quota can be configured via the
> +   "fetch-quota-params" option.
> + - "fetches-per-zone" limits the number of
> +   simultaneous queries that can be sent for names
> +   within a single domain.  (Note: Unlike
> +   "fetches-per-server", this value is not
> +   self-tuning.)
> + - New stats counters have been added to count
> +   queries spilled due to these quotas.
> +
> + These options are not available by default;
> + use "configure --enable-fetchlimit" (or
> + --enable-developer) to include them in the build.
> +
> + See the ARM for details of these options. [RT #37125]



Yes, I know they could still upgrade to 9.9.8 without this particular
feature, by simply not enabling it in the build.  But the restricted
feature set policy tends to be applied on a source level.

Playing the devil's advocate here... As I said, I was really happy to see
this feature in 9.9.8 myself.


Bjørn


Re: DNSSEC and ISPs faking DNS responses

2015-11-13 Thread Bjørn Mork
Jean-Francois Mezei  writes:

> The Québec government is wanting to pass a law that will force ISPs to
> block and/or redirect certain sites it doesn't like.

BTDT.  See
https://torrentfreak.com/pirate-sites-must-pay-legal-costs-of-own-blockade-court-rules-150902/

(yes, we could discuss the point of all this - but that is a political
discussion, and there are better fora for those. Let's keep this
techical here, please)

Now, we mostly don't do DNSSEC validation yet, and luckily none of the
blocked domains have any DS records either. So DNSSEC is not yet a real
problem in this regard.  But there is no reason to think this luck will
last forever.  Given the "success", we can only assume there will be
more court orders.  And we do want to enable DNSSEC validation
everywhere at some point.

So what do we do? We currently point the blocked domains to addresses of
a web server with a short explanation.  But what if the domains were
signed?  We could let validating servers return SERVFAIL.  But I'd
really prefer avoiding that for the simple reason that there is no way
to distinguish that SERVFAIL from one caused by e.g. a domain owner
configuration error.  So I'm wondering if DLV might help us here?  I
imagine it will allow us to return a signed response to the client,
with the AD flag, even if we have taken control of the domain.  Or won't
that work at all if the parent has a DS record?

If the DLV strategy works, then the main advantage would be that a
validating client could distiguish between a domain owner error and a
deliberate "error" added by us as a resolver operator.  The DLV signed
response will still fail client calidation.  And we would of course
publish the DLV key, so that anyone wishing to verify the source of the
failing signatures could do that (assuming that some clients may accept
us as a MITM, but still want to prevent others from the same attack).

What do you all think? Is this feasible?  Any better solutions?

OK, I should probably lab this instead of discussing it... 


Bjørn (working for Telenor, but definitely not having any role in PR or
legal matters)


Re: IP-Echelon Compliance

2015-10-13 Thread Bjørn Mork
Seth Arnold  writes:

> Please feel free to get in touch with us to request changes.
>
> Expedited processing of your requests is offered through the Notice Recipient 
> Management for ISPs section of our website located here:
> http://www.ip-echelon.com/isp-notice-management/ 
> 

Are you serious? You receive spam and then you go to a link provided by
the spammer, entering your contact information into a web form? I don't
think so...

Take it with their upstream abuse contact instead.


Bjørn


Re: IPv6 Subscriber Access Deployments

2015-09-12 Thread Bjørn Mork
Owen DeLong  writes:

> Sure, but this is a useless savings that comes at the cost of awkward 
> traceroute output
> that will initially confuse your new employees and consistently confuse your 
> customers.

Like MPLS or asymmetric routing...

Noone wants unnecessarily confused employees or customers, but I don't
think confusing traceroute output comes very high on the network design
criteria list these days :)

Whether the savings are useless depends on how you count the cost.
Address space savings are of course pointless, but managing address
allocations does have a cost.  It doesn't have to be high, but it is a
cost you have to consider.

FWIW, we decided to go with an IA_NA based WAN GUA for CPE management
purposes - we needed a management address and didn't want to steal from
the customers IA_PD prefix.


Bjørn


Re: Yet Another BGP (Border Gateway Protocol) Python Implementation

2015-08-07 Thread Bjørn Mork
Randy Bush ra...@psg.com writes:

 perhaps dissing someone for their free code is even ruder than not doing
 ipv6 in 2015?  you don't have to use either.

Definitely.  In any case, one advantage of open sourcing stuff is that
you can always answer such comments with a simple

  Patches welcome!

which tends to silence critics :-)


Bjørn


Re: Supplier 100/200Mbps on Canarias Is.

2015-03-18 Thread Bjørn Mork
Marco Paesani ma...@paesani.it writes:

 I need a supplier on Canarias Is, do you have some info ?

http://www.d-alix.com/


Bjørn


Re: Reverse DNS RFCs and Recommendations

2013-11-04 Thread Bjørn Mork
Mark Andrews ma...@isc.org writes:

 That said it is possible to completely automate the secure assignment
 of PTR records.  It is also possible to completely automate the
 secure delegation of the reverse name space.  See
 http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00

I like that.  I'd really like to see CPE vendors implementing it.

AFAICT, it is perfectly possible to apply that on top of the idea you
had about letting TCP clients update their own key. CPEs supporting the
DHCPv6 option will use that, while the others still have the ability to
add a KEY record from a TCP client in the deletated prefix.  As long as
you let TSIG signed updates trump anything and do not allow unsigned
updates if there is a KEY, then these should work just fine together.

But I believe the draft could use a couple of clarifications to avoid
interpretation bugs:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
   includes a KEY-RDATA option (code point TBA) which contains a the
   rdata of a DNS KEY record containing a RSASHA256 key using the public
   components of the previously generated RSA key pair.

Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
top level option?  I.e. will it be possible to set different keys for
(the theoretical) multi-prefix requests?

We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
it is important to explicitly state where such options, which may be
considered local to part of the DHCPv6 message, belong.  I do know that
RFC3315 is clear on the default:

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  

But experience with OPTION_DNS_SERVERS has shown that this is not
enough.  Pleace be explicit about where in the packet any new DHCPv6
options belong.


   CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
   name space to itself and others if they have been configured.  The
   CPE uses SIG(0) [RFC2931] to sign the request with owner name
   matching the reverse of the delegated prefix.

This could use a few examples and clarifications wrt the owner name.  I
interpret it as:

 IA_PD = 2001:db8:1::/48 = owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

But what about for example IA_PD = 2001:db8:2:4::/62 ?  Are you going to
add multiple owner names, or should there be some rule here allowing
multiple delegations with a single owner name for PD on non-nibble
boundaries?  For example

 IA_PD = 2001:db8:2:4::/62 
   = owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
  allowed to update:
 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa


(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)



Bjørn



Re: IP4 address conservation method

2013-06-07 Thread Bjørn Mork
Jimmy Hess mysi...@gmail.com writes:

 The kernel has its defaults,  but  distribution vendors such as
 Redhat/Ubuntu/Debian, are free to supply their own defaults  through
 sysctl.conf or their NetworkManager packages  or network configuration
 scripts...

 It's interesting to note they have so far chosen to go (mostly) with
 the defaults.

 I'm sure most people do not have a problem,  or else,  someone would
 have updated the defaults by now

Changing defaults will break stuff for people relying on those defaults.
This is usually not acceptable. At least not in the kernel.

The behaviour is well documented and easy to change.  Whining about the
defaults not matching personal preferences is useless noise.


Bjørn



Re: IP4 address conservation method

2013-06-06 Thread Bjørn Mork
William Herrin b...@herrin.us writes:
 On Wed, Jun 5, 2013 at 6:25 PM, Ricky Beam jfb...@gmail.com wrote:
 I won't argue against calling Linux wrong.  However, the linux way of
 dealing with ARP is well tuned for host and not router duty.

 I love Linux and use it throughout my work but I can't tell you the
 number of times its ARP behavior has bitten me. If you send a packet
 to a VIP on a Linux box and it doesn't have an arp entry for the
 default gateway, the Linux box will send an arp request... with the
 vip as the source. That is just wrong. Wrong, wrong, wrong. Use the
 damn interface IP when you arp for something on that interface. If the
 router doesn't happen to like the bad arp (since the VIP isn't on the
 router's LAN) the router will ignore it. And your service will merrily
 pop up and down depending on whether the Linux box has any traffic to
 originate.

Did you try setting sys.net.ipv4.conf.all.arp_announce=2 ?

Yes, the system default may be tuned for host/desktop usage, but it's
not like you *have* to use the system default.  Tweak it as you like.
And if there isn't enough knobs, then you can always add another one.
You have the source code.


Bjørn



Re: What do people use public suffix for?

2013-04-19 Thread Bjørn Mork
Jay Ashworth j...@baylink.com writes:

 - Original Message -
 From: John Levine jo...@iecc.com

 The public suffix list contains points in the DNS where (roughly
 speaking) names below that point are under different management from
 each other and from that name. It's here: http://publicsuffix.org/
 
 The idea is that abc.foo.com and xyz.foo.com have the same management,
 but abc.co.uk and xyz.co.uk do not.
 
 You don't have to tell me that it's a gross crock, but it seems to
 be a useful one. What do people use it for? Here's what I know of:
 
 * Web browsers use it to manage cookies to keep a site from putting
 cookies that will affect other sites, e.g. abc.foo.co.uk can set a
 cookie for foo.co.uk but not for co.uk.
 
 * DMARC (www.dmarc.org) uses it to find a policy record in the DNS
 that describes a subtree, e.g., if you get mail that purports to be
 from e...@reply1.ebay.com it checks the policy at ebay.com.
 
 What other current applications are there?

 Seems to me that it's a crock because *it should be in the DNS*.

It is already, isn't it?  The NS and SOA records will tell you all there
is to know about zone splits and cross zone relations.

 I should be able to retrieve the AS (administrative split) record 
 for .co.uk, and there should be one that says, yup, there's an
 administrative split below me; nothing under there is mine unless 
 you also get an exception record for a subdomain.

Use the SOA record.  If it is identical for two zones, then the
adminstrative authority for those zones is the same.

For example, microsoft.co.uk and microsoft.com can be considered
under the same administration:

 bjorn@nemi:~$ dig +short soa microsoft.co.uk 
 ns1.msft.net. msnhst.microsoft.com. 2013032601 1800 900 2419200 3600
 bjorn@nemi:~$ dig +short soa microsoft.com
 ns1.msft.net. msnhst.microsoft.com. 2013041803 300 600 2419200 3600

While apple.co.uk and apple.com may be, depending on how strict you
are going to be when comparing:

 bjorn@nemi:~$ dig +short soa apple.co.uk 
 nserver.euro.apple.com. hostmaster.apple.com. 10 1800 900 2592000 1800
 bjorn@nemi:~$ dig +short soa apple.com
 gridmaster-ib.apple.com. hostmaster.apple.com. 2010086586 1800 900 2016000 
86500


etc.


Bjørn



Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....

2012-11-29 Thread Bjørn Mork
Dobbins, Roland rdobb...@arbor.net writes:

 On Nov 29, 2012, at 12:18 AM, Bjørn Mork wrote:

 But I will absolutely refuse the idea that anyone incapable of
 getting their application tested with IPv6 are able to create any
 useful networking software.

 Who's talking about 'networking software'?  'Networking software' is
 irrelevant for the vast majority of the userbase.  I'm talking about
 ordinary applications which do stupid things like edit documents and
 calculate payroll runs.

If it doesn't do IPv4 then I don't see the need for IPv6 support.


Bjørn



Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....

2012-11-29 Thread Bjørn Mork
Dobbins, Roland rdobb...@arbor.net writes:
 On Nov 29, 2012, at 4:28 PM, Bjørn Mork wrote:

 If it doesn't do IPv4 then I don't see the need for IPv6 support.

 To me, 'networking software'  software which happens to access the
 network.  Quagga is an example of 'networking software'.

OK, that makes sense.  What's the proper term for software which happens
to access the network?


Bjørn



Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....

2012-11-28 Thread Bjørn Mork
david raistrick dr...@icantclick.org writes:
 On Tue, 27 Nov 2012, Jeroen Massar wrote:

 As for actually getting IPv6 at home or at work, there are so many ways
 to get that, thus not having it is a completely ridiculous excuse.

 bull.  explain using a tunnel broker to anyone who isn't a network
 engineer.

Do you really want to run netowrking software written by someone
incapable of setting up a test network?  This doesn't have anything with
tunnel brokers or native access to do at all.


Bjørn



Re: Big day for IPv6 - 1% native penetration

2012-11-28 Thread Bjørn Mork
Mikael Abrahamsson swm...@swm.pp.se writes:
 On Tue, 27 Nov 2012, mike wrote:

 You're saying there are no cellular v6 deployments? I'm about 99%
 certain that you're wrong. I see v6 addresses in my apache logs all
 the time and they're almost definitely while they're not on wifi (my
 site uploads gps data while people are skiing, so they're usually on
 cellular).

 I am in Europe. None of Apple och Microsoft mobile devices will do
 IPv6 on the mobile side.

They won't do maps either. Does that mean that maps don't exist?
Try to keep device bugs and network deployment issues separate.

 I don't know if they do special versions for
 the US market, but for general 3GPP networks, it doesn't work.

IPv6 work just fine in 3GPP networks.  Also in Europe.


Bjørn



Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....

2012-11-28 Thread Bjørn Mork
Dobbins, Roland rdobb...@arbor.net writes:

 On Nov 28, 2012, at 4:52 PM, Bjørn Mork wrote:

 Do you really want to run netowrking software written by someone incapable 
 of setting up a test network?

 If you don't think you're running some piece or another of software
 right this minute which was coded by someone incapable of setting up a
 test network, you're mistaken.

Maybe so.  But do I _want_ do run that software?  No.

Anyway, I am not sure which programs that would be.  The applications
with open sockets on my laptop are currently:

cupsd
dhclient
emacs
gpsd
gvfsd-http
inetd
mysqld
named
netserver
ntpd
rpcbind
rpc.statd
(squid)
ssh
sshd

This is of course not a complete list of all applications I need to
verify.  I should add a number of client applications not currently
running, and inetd may fire up proftpd and atftpd when necessary.

But FWIW the only suspicious application I can see on that initial list
is gvfsd-http.  I don't know anything about the programmers behind that.
I am pretty sure the people behind the rest of the software are capable
of setting up a test network.



Bjørn



Re: Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications....

2012-11-28 Thread Bjørn Mork
david raistrick dr...@icantclick.org writes:
 On Wed, 28 Nov 2012, Bjørn Mork wrote:

 Do you really want to run netowrking software written by someone
 incapable of setting up a test network?  This doesn't have anything with
 tunnel brokers or native access to do at all.

 So the software engineer should now -also- be responsible for, and
 capable of, recreating both the network as well as 3rd party systems
 that he/she has to code against?

I am not claiming that every engineer in a big project should have all
knowledge necessary to complete the project, or have the responsibility
for every task in the project.  But defining and configuring a suitable
test environment is an absolute requirement for any software project. So
*someone* in a network software development project will need to know
how to set up networking for the testing.

 again focusing on just our last title release - 20+ 3rd party
 interfaces run by 6 different companies.   Is the software engineer
 really responsible for faking things like xbox live, PSN, facebook,
 twitter, google, etc on a test network?

If your application interface with those services and you expect those
parts of the application to work, then I'd say so, yes. There may be
occasional exceptions from this rule, but most of the time you'll find
that any untested parts of an application does not work.  Now I'd guess
that most of those services also offer a test environment.  You will of
course primarily use that.

The claim wrt IPv6 was that it was too difficult to use existing test
enviroments.

The degree of real world simulation you need for testing will of course
vary.  It's not like a hobbyist Android app developer must set up his
own cellular network.  Running the app in an emulator is likely enough
for most uses, including IPv6 testing.

This discussion seem to go off into the wild, so I am not sure there is
any point continuing it.  But I will absolutely refuse the idea that
anyone incapable of getting their application tested with IPv6 are able
to create any useful networking software.  That's simply not possible.
If it fails on IPv6 then it is guaranteed to fail on IPv4 as well, only
less obvious ond therefore more dangerous.

The claim that missing IPv6 support in software has anything to do with
the lack of native IPv6 internet access is just stupid.  You may wonder
how anyone could develop a new protocol, or microcode for a new CPU, or
a driver for a new hardware device, or anything at all really. You just
cannot count on having access to a full scale production environment
during software development.  You will have to find some way to simulate
the missing parts.

Native IPv6 internet access has never been a requirement for developing
IPv6 aware applications.  That was a bad excuse even 10 years ago. Today
it is just ridiculous.


Bjørn



Re: guys != gender neutral

2012-09-28 Thread Bjørn Mork
Scott Howard sc...@doc.net.au writes:
 On Thu, Sep 27, 2012 at 11:10 AM, Jo Rhett jrh...@netconsonance.com wrote:

 Guys seem to think that it's gender neutral. The majority of women are
 used to this, but they have indicated to me that they don't believe it to
 be very neutral. Using guys is not gender neutral, it's flat out implying
 the other gender doesn't matter. *


 The Oxford English dictionary apparently disagrees with you.

 http://oxforddictionaries.com/definition/american_english/guy?region=usq=guys
 (*guys*) people of either sex: * you guys want some coffee?
 *

 As other many words in the English language there are multiple definitions,
 and one of those definitions is gender specific - but the one above is very
 much gender neutral (either sex - it doesn't get much clearer than that!)

Well, either sort of implies that there are only two sexes.  I believe
people of any sex would have been better.  See e.g.
http://en.wikipedia.org/wiki/Third_gender


Bjørn



Re: Bird vs Quagga revisited

2012-09-01 Thread Bjørn Mork
Seth Mattinen se...@rollernet.us writes:

 What's the state of MPLS on Linux these days?

There was some renewed interest recently (i.e. last year).  See the
discussion starting at
http://www.spinics.net/lists/netdev/msg180282.html

But do note davem's replies in
http://www.spinics.net/lists/netdev/msg180401.html
http://www.spinics.net/lists/netdev/msg180646.html

Don't put too much into the fringe facility comment.  There have been
similar comments on e.g. IPv6, and that went in some time ago :-)

So in short: There is some interest and some people working on this in
a direction which has some hope of mainline integration.


Bjørn



Re: Bird vs Quagga revisited

2012-09-01 Thread Bjørn Mork
Edward Dore edward.d...@freethought-internet.co.uk writes:

 They used to publish the source for their 2.4 kernel on
 routerboard.com (in fact, it's still available at
 http://routerboard.com/files/linux-2.4.31.zip), but I've not seen
 anything for the 2.6 kernel however and the routerboard.com site was
 redesigned a little while ago, seemingly without the links as far as I
 can tell.

 It might be a case of you need to ask them for it. Would be
 interesting to see which bits are GPL.

There is no doubt that *all* bits of the Linux kernel are GPL.  Whether
vendors respect this is another question.  But Mikrotik most certainly
cannot distribute the Linux kernel, modified or not, without also
providing the full source code.


Bjørn



Re: job screening question

2012-07-10 Thread Bjørn Mork
David Coulson da...@davidcoulson.net writes:

 Anyone else noticed their memory has gotten worse since Google came
 along? :)

Huh?  Hasn't Google always been there?


Bjørn



Re: IETF - Overlapping IPv4 Address Support

2012-03-07 Thread Bjørn Mork
You seem to have skipped a calendar page.


Bjørn



Re: Huawei edge routers..

2012-03-06 Thread Bjørn Mork
Saku Ytti s...@ytti.fi writes:

 I've not really used them much, I think I've just configured enough to get
 6VPE working, and it worked (against CSCO and JNPR) and was easy enough to
 do without docs.  On paper they look fine, CLI is worse than IOS, but
 honestly if CLI is critical to you, you're probably doing something wrong
 anyhow (meaning, systems should be touching routers, not people)


Hmm, we have systems using CLI as interface to the routers.  What other
options do these boxes provide?


Bjørn



Re: How are you doing DHCPv6 ?

2012-01-21 Thread Bjørn Mork
Randy Carpenter rcar...@network1.net writes:

 DHCP is certainly not stateless, which is why there is a concept of
 leases, which are stored in a file. You can't have 2 servers answering
 for the same subnet without some sort of coordination, or you would
 have a potential for duplicate addresses being assigned.

Duplicate assignments are not a problem as long as you ensure that the
client is the same.

I.e. if the prefix delegating DHCPv6 server serves a statically assigned
prefix to an end user based on information *uniquely identifying that
user*, then you can replicate that setup to as many completely
independent DHCPv6 servers as you like.  Different end users will still
not receive duplicate assignments.

But if you want the DHCPv6 server to dynamically allocate a new prefix
to each client, then you are up for problems of course.  Don't see why
you would want to do that though.  Redundant DHCPv6 will be only one of
many problems in such a setup. 


Bjørn



Re: How are you doing DHCPv6 ?

2012-01-20 Thread Bjørn Mork
Randy Carpenter rcar...@network1.net writes:

 I am wondering how people out there are using DHCPv6 to handle
 assigning prefixes to end users.

 We have a requirement for it to be a redundant server that is
 centrally located.

OK, so then you've already made your choice.

Another solution is having the DHCPv6 servers distributed while keeping
the database centrally managed.  This is the route the delegated prefix
will travel:

central MySQL master = local MySQL slave on each RADIUS server =
RADIUS based per client provisioning = local DHCPv6 server running on
each access router = DHCPv6 client on customer CPE

This is about as redundant as it gets if you have multiple RADIUS
servers in multiple sites. No need for any cooperation between the
DHCPv6 servers to be fully redundant.

The only assumption is that either will the client always connect to the
same access router, or the prefix must move between the access routers
the client uses.  Whether this is a deaggregation problem for you or not
depends on how those access routers can be grouped, if at all.

But that problem is really unrelated to DHCPv6


Bjørn



Re: subnet prefix length 64 breaks IPv6?

2012-01-07 Thread Bjørn Mork
sth...@nethelp.no writes:

 And yes, we know equipment that cannot *filter* on full IPv6 + port
 number headers exists (e.g. Cisco 6500/7600 with 144 bit TCAMs) - my
 original point was that I still haven't seen equipment with forwarding
 problems for prefixes  64 bits. 

Depends on what you consider a problem and whether you consider a layer
3 switch a router at all, but there are certainly some switches which
will be more or less effective depending on prefix length.  Ref e.g.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swsdm.html#wp1257279

where you'll find this carefully worded hint:

 Note: An IPv4 route requires only one TCAM entry. Because of the
hardware compression scheme used for IPv6, an IPv6 route can take
more than one TCAM entry, reducing the number of entries forwarded
in hardware. For example, for IPv6 directly connected IP addresses,
the desktop template might allow less than two thousand entries.


Translated: The stated numbers for IPv6 routes are twice the real max.
However, prefix compression may give better utilisation under certain
conditions.


Bjørn



Re: Dynamic (changing) IPv6 prefix delegation

2011-11-22 Thread Bjørn Mork
Nathan Eisenberg nat...@atlasnetworks.us writes:

 What does Joe Sixpack do at home with a /48 that he cannot do with a
 /56 or a /60?

What does Joe's ISPack save the missing bits for?


Bjørn



Re: Dynamic (changing) IPv6 prefix delegation

2011-11-21 Thread Bjørn Mork
Seth Mos seth@dds.nl writes:

 Hello List,

 As a pfSense developer I recently ran into a test system that (actually)
 gets a IPv6 prefix from it's ISP. (Hurrah).

 What is bewildering to me is that each time the system establishes a new
 PPPoE session to the ISP they assign a different IPv6 prefix via
 delegation together with a differing IPv4 address for the WAN.

 Is this going to be forward for other consumer ISPs in the world?

I certainly hope not.

But you should be prepared to handle the situation anyway.  Even those
ISPs providing a stable prefix may have to change it from time to time.
Which means that there is always a risk that the prefix changes with a
new PPPoE session, even if that doesn't happen every time.  And if the
prefix does change, then the old prefix will most likely not be routed
out the new PPP interface even if the lease hasn't expired yet.

You'll probably want to deprecate the old prefix when this happens,
signalling to the hosts that they should prefer the new prefix for new
sessions. 


Bjørn



  1   2   >