from:"James R. Cutler"

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

2024-01-20 Thread James R Cutler

s not 
>>> compatible with devices that do not support it.  it would not be 
>>> appropriate to expect every device vendor to support it.  ...   ":
>>> Perhaps we have some offset about the terminology of "who supports 
>>> whom?" My understanding of the OpenWrt project is that it is an open-source 
>>> program code that supports a long list (but not all) of primarily 
>>> commercial RGs (Residential/Routing Gateways) and WiFi routers that serve / 
>>> support CPE devices (on-premises IoTs). Its basic purpose is to let private 
>>> network owners to replace the firmware code in the RGs with the OpenWrt 
>>> equivalent so that they will have full control of their RGs and then modify 
>>> them if desired. Thus, the basic release of each OpenWrt code maintains 
>>> most of the original functionalities in the OEM device. So, neither the 
>>> original RG nor any IoT manufacturers need be involved with the OpenWrt, 
>>> let alone supporting it. My reference to its V19.07.3 was the version that 
>>> expanded its usable address pool to include 240/4. That was all.
>>> 
>>> For sure, OpenWrt does not run on all RGs in the field. But, this does 
>>> not restrict an overlay network like RAN from starting to network only 
>>> those premises with RGs that run on OpenWrt (plus those RGs compatible with 
>>> 240/4 from the factories). Since the existing CG-NAT is not disturbed and 
>>> daily Internet services are going normally, RAN growth can take its time.
>>> 
>>> 3)" You've provided a link to a D-Link managed switch, not a router. 
>>> Just because it can support L2 routing, doesn't make it a router.   ":
>>> Correct, this is just a basic example for networking the RGs to 
>>> experiment the RAN configuration. It is not intended to be a full-fledged 
>>> router which will have other considerations that are way beyond what EzIP 
>>> should be involved with.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> Abe (2024-01-18 22:48)
>>> 
>>> 


Wow, changes happen when one is busy. When was the acronym "RAN" applied to a 
"Stealthy Overlay Network"? In my experience RAN is most often a Radio Access 
Network (military and cellular nets). Return Authorization Number is accepted 
usage in commerce.  I now have several questions:

Shouldn't the acronym be SON, except that is also used many places?
Why are we discussing a "Stealthy Overlay Network" anyway? If truly is 
stealthy, it is probably not guided by RFC.
What does OpenWRT have to do with this? 
I saw the beginning of this discussion long long ago. I still do not understand 
the merits of messing with IPv4 address allocations, especially comparing cost 
of a limited lifetime "Stealthy Overlay Network" as comparted to actually 
deploying and using IPv6. Where will be the long term savings? IPv6 has an 
expected lifetime far in excess of any hacks to extend IPv4 lifetime.
Show me the money.
-
James R Cutler
james.cut...@consultant.com

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

2024-01-14 Thread James R Cutler

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields mailto:br...@bryanfields.net>> wrote:
> On 1/12/24 3:04 PM, Mu wrote:
>> Would it be possible for you to reply in-thread, rather than creating a new 
>> thread with a new subject line every time you reply to someone?
>> 
>> Trying to follow the conversation becomes very difficult for no reason.
> 
> Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> how this works based on message ID.  This thread displays fine in threaded
> mode in my MUA and in the archives.

Bryan,

My personal use of email agents involves ordering incoming messages by date 
sent. Many others order their inbox by date received. I don't use MUA ordering 
by thread or conversation because I must use MUAs on many diverse systems. So 
for many decades, I have continued to use my own mental programming to sort and 
group messages by subject. This, by the way, is akin to aural conversations 
between persons where announcing a change of subject is expected to be followed 
by a new topic.

For those of us on OCD, ADD, or Autism spectrums, multiple subjects lines cause 
cognitive dissonance - sometimes damaging comprehension of the continuing 
thread (conversation). I don't claim it violates the ADA, but it should 
especially when willfully continued after requests for amended behavior. 
Lazarus Long would probably express this more cogently.

In the interest of polite conversation,
-
James R. Cutler
james.cut...@consultant.com

Re: NTP Sync Issue Across Tata (Europe)

2023-08-14 Thread James R Cutler

> On Aug 14, 2023, at 3:07 AM, Forrest Christian (List Account) 
>  wrote:
> 
> I've responded in bits and pieces to this thread and haven't done an 
> excellent job expressing my overall opinion.   This is probably because my 
> initial goal was to point out that GPS-transmitted time is no less subject to 
> being attacked than your garden variety NTP-transmitted time. Since this 
> thread has evolved, I'd like to describe my overall position to be a bit 
> clearer.
> 

> 
> And finally, as a sort of a tl;dr; Summary:  Each operator needs to decide 
> how critical time is to their network and pick a solution that works for them 
> and fits the organization's budget.   Some operators might point everything 
> at pool.ntp.org <http://pool.ntp.org/> and not run their own servers.  Others 
> might run their own time lab and use that time to provide NTP time and 
> precision time and frequency via various methods.  Most will be somewhere in 
> between. But regardless of which you choose, please be aware that GPS isn't 
> 100% secure, and neither is NTP. If attack resilience matters to you, you 
> should think about all of the attack vectors and design something that is 
> robust enough to meet your use case.
> 
This has been an interesting thread. I consider Forrest Christian’s note to be 
most cogent. Much of the GPS vs Internet sourcing arguments can probably be 
found in NANOG archives from many years ago. The threat list is longer now, but 
the problem of providing Time Service is still the same.

Twenty-five or so years ago my design process for providing Network Time 
Service to a large company intranet started with the business requirements for 
time service. The Management practice of “Not in my cost center” was 
fundamental to NOT attempting GPS-based deployment. The internal enterprise 
network provided a set of geographically distributed Stratum 2 servers having 
carefully firewalled access to a similar set of Stratum 1 servers with Internet 
access. The Stratum 0 server set list included NIST, USNO, and other similar 
sources distributed globally.

The magic of Dr. Mills algorithm made truechimers of the intranet NTP server 
set which did serve well for the lifetime of the company.

-
James R. Cutler

Re: NTP Sync Issue Across Tata (Europe)

2023-08-06 Thread James R Cutler

A carefully selected set of stratum 0 sources for a set of stratum 1 servers is 
the heart of good NTP source design. With at least four “local” stratum 1 
servers, Dr. Mills algorithm is excellent at distinguishing truechimers from 
falsetickers and providing a reliable source of monotonic time. DOS is a 
separate problem.

My NTP network deployment experience for a major auto manufacturer, among 
others, is in agreement with William Herin. A GPS NTP source is a valid Stratum 
0 source, but relying on a single instance for local time is not exceedingly 
better than querying time.apple.com <http://time.apple.com/> or a similar 
source.
-
James R. Cutler 
> 
> William,
> 
> Due to flaws in the NTP protocol, a simple UDP filter is not enough. These 
> flaws make it trivial to spoof NTP packets, and many firewalls have no 
> specific protection against this. in one attack the malefactor simply fires a 
> continuous stream of NTP packets with invalid time at your firewall. When 
> your NTP client queries the spoofed server, the malicious packet is the one 
> you likely receive.
> 
> That’s just one attack vector. There are several others, and all have complex 
> remediation. Why should people bother being exposed to the risk at all? 
> Simply avoid Internet-routed NTP. there are many solutions, as I’ve already 
> described. Having suffered through such attacks more than once, I can say 
> from personal experience that you don’t want to risk it.
> 
> -mel 
> 
>> On Aug 6, 2023, at 10:53 AM, William Herrin  wrote:
>> 
>> On Sat, Aug 5, 2023 at 7:24 PM Mel Beckman  wrote:
>>> That still leaves you open to NTP attacks. The USNO accuracy and monitoring 
>>> is worthless if you suffer, for example, an NTP DDoS attack.
>> 
>> Hi Mel,
>> 
>> From what I can tell, a fairly simple firewall policy of allow UDP 123
>> from known NTP clients and established connections (I sent them a UDP
>> packet recently) stops every one of those attacks (that's actually an
>> NTP attack and not something else like a DNS attack) except for
>> upstream address hijack that happens to coincide with your system
>> boot. And it still depends on the attacker executing an additional
>> sophisticated attack to do more than cause you a denial of service.
>> 
>> The links you sent are very interesting, at least in an academic
>> sense, but they don't cause me to be unduly concerned about employing
>> NTP.
>> 
>> 
>>> if you can eliminate such security problems for $400, I say it’s cheap at 
>>> twice the price.
>> 
>> Except you can't. Redundancy is required for any critical service. At
>> the $400 price point, your approach has multiple
>> single-points-of-failure. The device itself of course. Your ability to
>> receive continuous non-jammed GPS signals at the location where you're
>> able to place an antenna. And in your plan you'll need one of these in
>> every discontiguous network where you have equipment since you're not
>> doing NTP over the Internet.
>> 
>> Not to mention the operations cost. Keeping track of a six inch brick
>> with a wall wart and an antenna installed at a remote site is... not
>> entirely abnormal but it's a one-off that consumes manpower.
>> 
>> And then you're only vulnerable to the litany of Internet attacks
>> which don't involve NTP. Yay!
>> 
>> Don't get me wrong: the Time Machines TM1000A you recommended looks
>> like a cool little device well worth checking into. As a supplement to
>> Internet NTP, not a replacement.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/

Re: Let's Focus on Moving Forward Re: V6 still not supported

2022-04-01 Thread James R Cutler

On Mar 31, 2022, at 11:51 PM, Masataka Ohta  
wrote:
> 
> Owen DeLong wrote:
> 
>> It still suffers from a certain amount of opacity across administrative 
>> domains.
> 
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are used
> within the building, the problem of audit trail opacity is
> suffered.
> 
> Thank you very much to have proven IPv6 useless.
> 
>   Masataka Ohta

You appear to attribute to IPv6 a problem due to building management. Please 
explain how IPv6 is “useless” by some other measure that that of building 
management errors.

Re: V6 still not supported

2022-03-24 Thread James R Cutler

On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG  wrote:
> 
> I think that we’re still OK on allocation policies. What I’d like to see is 
> an end to the IPv4-think in large ISPs, such as Comcast’s continued micro 
> allocations to their customers.

What exactly is your definition of “micro allocations”? Is a prefix/56 a “micro 
allocation”? In over nine years of being an active forum participant and 
customer of Comcast, I can not recall the usage of the term.

Re: BOOTP & ARP history

2022-03-19 Thread James R Cutler

> On Mar 19, 2022, at 2:49 PM, Michael Thomas  wrote:
> 
> IPv6 in comparison was very familiar ground. To me it seemed that it was ipv4 
> with bigger addresses and that was about it. But I've never understood all of 
> the strum und drang about ipv6.

As one tightly involved in multiprotocol networking in the '90s, I viewed with 
interest the evolution of IPv6. Nothing about IPv6 changed fundamental physical 
network design principals, except to remove IPv4 limits on the number of 
subnetworks. Oh, and the removal of coordinated RFC1918 addressing between 
members of the ever active merger and acquisition world. Life became much 
rosier. One could concievably deploy a plant floor with a million IPv6 globally 
unique device address without kludges required by IPv4.

I never ran into Sturm und Drang about IPv6 itself, only about the required 
investment in people and hardware, which I considered a short term bump with a 
long term payoff.

That, I discovered, was the true barrier to IPv6 planning and deployment — 
middle management, especial account managers. The basic argument was “The 
customer must first ask for it and sign a contract, then we will prepare for 
it.” Too much “not in my cost center” mentality crippled the ability of network 
implementers to even deploy IPv6 for demonstration purposes, as well as for 
learning. The idea that “my investment” might also benefit others, even in my 
own company was anathema. I have never become short sighted enough to endorse 
such idiocy.

As one experience with ‘joys’ of end to end connections between NATted networks 
with overlapping RFC1918 space, The advent of CGNAT and various pipe dreams 
(mostly in the US) of extending IPv4 address space offends my business sense 
and technical sense for wasting time, materials, and money.

Re: IPv6 woes - RFC

2021-09-25 Thread James R Cutler

On Sep 25, 2021, at 8:44 PM, Valdis Klētnieks  wrote:
> 
> On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:
> 
>> We should remember there are also multiple ways to print IPv4 addresses.
>> You can zero extend the addresses and on some ancient systems you could
>> also use the integer value.
> 
> 19:17:38 0 [~] ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
> 
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
> 
> That's a bit more than just 'some ancient systems' - depending whether
> it works on other Android releases, and what IoT systems do, we may have
> more systems today that support it than don't support it.

It also works on this 'ancient' macOS Monterey system.

Last login: Sat Sep 25 20:50:00 on ttys000
xz4gb8 ~ % ping 2130706433
PING 2130706433 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.103 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.109 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.047/0.092/0.111/0.026 ms
xz4gb8 ~ %

Re: 10g residential CPE

2020-12-29 Thread James R Cutler

On Dec 29, 2020, at 11:53 AM, Michael Thomas  wrote:
> 
> On 12/29/20 8:42 AM, Aaron Wendel wrote:
>> Oh, we still get calls about speed issues. It's always wonderful when 
>> someone puts their own 10 year old Linksys WRT54G and double NATs behind our 
>> CPE then sends in a speed test wondering why they're only getting 10Mbits on 
>> their Gbit line.  We get those ALL the time. :)
>> 
> Does your CPE not have wireless? If it's double NAT'ing it's at least a 
> router. If it doesn't have wireless, wouldn't it be cheaper to add it so you 
> don't get the support calls?
> 
> Mike
> 
Supplying any configurable residential CPE would not necessarily be cheaper. 
The tracking and accounting for the hardware and qualifying said hardware, not 
to mention truck rolls for hardware updates, could well be more costly than 
fielding support calls (which would likely not decrease anyway).

An intangible benefit of ‘free residential service’ is creation of good will 
far exceeding that received by many other ISPs.  
-
James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Are the days of the showpiece NOC office display gone forever?

2020-12-16 Thread James R Cutler

> On Dec 16, 2020, at 7:25 PM, Randy Bush  wrote:
> 
>> In the traditional sense, by "showpiece NOC" I mean a room designed for the
>> purpose of having large situational awareness displays on a wall, network
>> weathermaps and charts, alerting systems, composed of four or more big flat
>> panel displays. Ideally configured to be actually useful for NOC purposes
>> and also something impressive looking for customer tours.
> 
> though your message has a current date, its content seems to be at least
> 15 years old
> 
> randy

The EDS Network Management Center, or IMS, had multiple large screens, 
shadow-free lighting, and lots of console positions and a visitor gallery with 
curtained window overlooking the operations room. We finished it right around 
1990. Right when the suburban sprawl ws starting to hit Plano. After so much 
there during construction, I was taken aback when I realized I did not 
recognize the inside the building with it’s finished walls.

That implies “at least 15 years” could well be “30 years”
.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: "Hacking" these days - purpose?

2020-12-14 Thread James R Cutler

The probable "purpose of obtaining illicit access to random devices on the 
Internet these days” is to create botnets to attack more lucrative targets or 
to employ them as gateway devices to provide access to local networks which may 
contain targets of interest.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Dec 12, 2020, at 5:26 PM, Peter E. Fry  wrote:
> 
> 
> Simple question: What's the purpose of obtaining illicit access to random 
> devices on the Internet these days, considering that a large majority of 
> attacks are now launched from cheap, readily available and poorly 
> managed/overseen "cloud" services?  Finding anything worthwhile to steal on 
> random machines on the Internet seems unlikely, as does obtaining access 
> superior (in e.g. location, bandwidth, anonymity, etc.) to the service from 
> which the attack was launched.
> 
> 
> I was thinking about this the other day as I was poking at my firewall, and 
> hopped onto the archives (here and elsewhere) to see if I could find any 
> discussion.  I found a few mentions (e.g. "Microsoft is hacking my 
> Asterisk???"), but I didn't catch any mention of purpose.  Am I missing 
> something obvious (either a purpose or a discussion of such)?  Have I lost my 
> mind entirely?  (Can't hurt to check, as I'd likely be the last to know.)
> 
> 
> Peter E. Fry
> 
>

Re: AFRINIC IP Block Thefts -- The Saga Continues

2020-11-16 Thread James R Cutler

DELIBERATE TOP POST

It would be helpful to the NANOG list if posters could try to follow posting 
guidelines and discuss technical (not personal) topics.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Nov 16, 2020, at 10:04 AM, Elad Cohen  wrote:
> 
> Tom,
> 
> Until today all I wrote was facts and evidence, in the contrary to 
> Pore-spilling Ronald. When Ronald keeps defaming me here non-stop, Yes my 
> full right is to sue him, even if you prefer that my blood will be shed here 
> by his filthy soul and pores. And you can be sure that I will respond to any 
> of his defamation messages.
> 
> "No value to the community" - there is value to the community, anyone which 
> is following Pore-spilling Ronald is following the ancient snake, it is not 
> written in Old Testament, it is written in Old Scripture, go ahead and check, 
> Ronald visual appearance match one by one to the lawless one description 
> (lawless one is a term of New Testament) according to Old Scripture.
> 
> Go swim in Ronald juicy pores if you would like.
> 
> 
> From: Tom Beecher mailto:beec...@beecher.cc>>
> Sent: Monday, November 16, 2020 4:54 PM
> To: Elad Cohen mailto:e...@netstyle.io>>
> Cc: nanog@nanog.org <mailto:nanog@nanog.org>  <mailto:nanog@nanog.org>>; adm...@nanog.org <mailto:adm...@nanog.org> 
> mailto:adm...@nanog.org>>
> Subject: Re: AFRINIC IP Block Thefts -- The Saga Continues
>  
> I would like to formally request that Mr. Cohen's privileges to post to this 
> list be revoked, or otherwise curtailed.
> 
> It's one thing to dispute facts with evidence, or generally disagree on a 
> topic. However , threats of legal action and personal attacks citing Old 
> Testament mumbo jumbo, while creative, provide no value to the community. 
> 
> As Mr. Herrin stated well, we are all swimming in enough nutter butter 
> conspiracy theory nonsense every day. I hope we don't normalize it here too. 
> 
> On Mon, Nov 16, 2020 at 4:24 AM Elad Cohen  <mailto:e...@netstyle.io>> wrote:
> 
> If AfriNIC says your "purchases" are misappropriation you'll have to do a lot 
> better than conspiracy theories and phrenology in counter argument.
> 
> 
> Why are you using the word "purchases" with quotation marks, it seems that 
> you are a victim of your next paragraph, and I'm writing it with all due 
> respect.
> 
> Did I start legal proceedings with AfriNIC with conspiracy theories or with 
> facts and data?
> 
> Phrenology (and racism) is the field of Coconut Guilmette, according to his 
> own quotes right here in Nanog.
> 
> "If AfriNIC says" - AfriNIC, nor Spamhaus, nor Ops-Trust, nor MyBroadband, 
> are not the word of god and are not above law and justice.
> 
> To remind to everyone: AfriNIC filed a police complaint on themselves. And 
> AfriNIC CEO lied to the community in the following link when he wrote that I 
> was given a chance to respond when in reality all my emails were ignored. And 
> AfriNIC CEO is intentionally hiding from the community that any AfriNIC 
> policy is applied also to any legacy netblock that even don't have a signed 
> RSA (according to the legal proceedings against AfriNIC, and in contradiction 
> to AfriNIC "Legacy Resource Holders" webpage: 
> https://afrinic.net/membership/legacy-resource 
> <https://afrinic.net/membership/legacy-resource> ), it have implications on 
> each and every legacy resource holder all over the world (that a RIR can just 
> delete a legacy netblock).
> 
> https://lists.afrinic.net/pipermail/community-discuss/2020-January/003458.html
>  
> <https://lists.afrinic.net/pipermail/community-discuss/2020-January/003458.html>
>  - "We are also ensuring that the current holder/contact of the resources are 
> provided with the opportunity of proving their ownership."
> 
> 
> Besides the above, AfriNIC also have a financial motive in their actions, 
> approximately up to more $4M per year from assets that they illegaly and 
> unjustifiably took from me (by sub-allocating them to AfriNIC members), while 
> writing lies to their community and playing a long with the "community 
> pressure" game.
> 
> 
> I find the actions of AfriNIC to be very dangerous, because they are not 
> based on facts and data and law and justice, but only on community pressure. 
> Any network operator, that can elevate himself/herself from bad habits (like 
> enjoying seeing blood spilled and jealousy), would know that today it is me 
> but tomorrow it can be you.
> 
> 
> 
> From: NANOG  <mailto:netstyle...@nanog.org>> on be

Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

2020-03-09 Thread James R Cutler

In this case, “ebony phone” refers to the (usually) black housing of landline 
phones, either dial or manual that your parents probably used for years. Caller 
ID has long been supplied (for extra cost) to subscribers as a signal 
interspersed with the ring signal.

The answer to “what about ebony phones” is to require telcos to verify the 
Caller ID which is delivered to landline telephones along with the ring signal.

Again, this is not likely since it would impact the telco’s profit margin.


James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Mar 9, 2020, at 9:25 PM, Ross Tajvar  wrote:
> 
> What is an "ebony phone"? (Google results for that phrase are mostly porn.)
> 
> On Sat, Mar 7, 2020 at 12:55 PM Christopher Morrow  <mailto:morrowc.li...@gmail.com>> wrote:
> On Sat, Mar 7, 2020 at 4:10 AM Bryan Holloway  <mailto:br...@shout.net>> wrote:
> >
> >
> > On 3/7/20 8:03 AM, Christopher Morrow wrote:
> > > On Fri, Mar 6, 2020 at 11:05 PM Brian J. Murrell  > > <mailto:br...@interlinx.bc.ca>> wrote:
> > >
> > >> So, if my telco can bill the callers for those premium calls, they
> > >> surely know who they are, or at least know where they are sending the
> > >> bill and getting payment from.
> > >
> > > You are mistaken, billing is very hard.
> > > Telcos show this regularly.
> > >
> >
> > On the contrary: billing is easy. Getting it right is hard.
> 
> You are technically correct, the best kind of correct.
> 
> Seriously though, a bunch of the conversation about shaken/stir and
> various problems with spam callers reveals:
>   "telcos don't care (for any reason you can imagine)"
>   "gov't mandates aren't  really going to help"
>   "people care as recipients of these calls, but really there are
> options for them as well to not get the calls (or not answer them)"
> 
> I like that Mr Thomas's answer: "Why can't we just cryptpgraphically
> sign the caller's ANI and use that as a method to ID real callers we
> care about?"
> since that was my suggestion to the stir folk in their very first
> meeting... "what about ebony phones!" said the lawyer from
> telco-ville.

Re: IPv6 Pain Experiment

2019-10-03 Thread James R Cutler

Recently, someone alleged wrote wrote:

> It is hard to make the case to eliminate v4 in use cases where it is working 
> perfectly fine (especially RFC1918 inside an enterprise).

In light of multiple past mergers of existing IPv4 RFC1918 networks resulting 
from company acquisitions and mergers, I think I can make a case that “working 
perfectly fine” is only a temporary condition.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: User Unknown (WAS: really amazon?)

2019-08-12 Thread James R Cutler

> On Aug 12, 2019, at 3:52 PM, Henry Yen  wrote:
> 
> ftp://rfc-editor.org <ftp://rfc-editor.org/>
ftp://rfc-editor.org <ftp://rfc-editor.org/> still mounts perfectly well using 
macOS Finder but shows to be now devoid of useful content via ftp.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: netstat -s, but off topic a bit

2019-07-18 Thread James R Cutler

> Ideally folks should be subshells (unless you're on a strange system or
> legacy system).
> 
I have never thought of myself as subshell, even on a low carbohydrate 
system

> netstat is now mostly obsolete. 
> Replacement for netstat is ss.  
> Replacement for  netstat -r is ip route.
> Replacement for netstat -i is ip -s link.
> Replacement for netstat -g is ip maddr.

Microsoft (Windows, that is) and Apple macOS have no knowledge of ss.

That is why I use netstat often, but never netstat -s to diagnose routing. (Hi, 
Randy.)

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Time and Timing Servers

2019-07-11 Thread James R Cutler

> On Jul 11, 2019, at 11:23 AM, Mike Hammett  wrote:
> 
> I'll look into Meinberg.
> 
> I recent thread mentioned high-sensitivity receivers often allow GPS to work 
> inside. Obviously "inside" has a lot of definitions.
> 
> I will need this facility for the TDM timing signals. It's a central office, 
> not a datacenter.
> 
> I don't know that Internet-based NTP would be accurate enough for the timing 
> signals that I need. Maybe, maybe not.
> 

My experience with Dave Mills NTP algorithm is that, giving sufficient 
diversity in higher stratum sources, GPS versus Internet sources makes no 
practical difference. This assumes that you are concerned with Time for event 
logging and scheduling and not concerned with frequency and phase for clocking 
data on TDM instances.

If you are worrying about backhoe fade — it’s consequences will most likely 
affect other things more strongly than Time differences.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: any interesting/useful resources available to IPv6 only?

2019-05-03 Thread James R Cutler

> On May 3, 2019, at 11:47 AM, Doug Barton  wrote:
> 
> On 5/3/19 8:14 AM, Brian J. Murrell wrote:
>> Hi,
>> I am trying to make a case (to old fuddy-duddies, which is why I even
>> need to actually make a case) for IPv6 for my own selfish reasons.  :-)
>> I wonder if anyone has any references to interesting/useful/otherwise
>> resources on are only available to IPv6 users that they can forward to
>> me.
> 
> This type of marketing approach was pursued doggedly for many of the early 
> years of IPv6 rollout. It was as misguided then as it was ineffective.
> 
> If you have plenty of IPv4 space, you have no case for IPv6. (And I say that 
> as one of the most enthusiastic proponents of it.) OTOH, if you 
> are/might/will be approach(ing) any kind of IPv4 capacity limitation, then 
> you want to start deploying IPv6 ASAP.
> 
> The other case that makes business sense is a content provider with a lot of 
> traffic. You can get different, and often better, peering relationships over 
> IPv6; and there are a lot of eyeball networks, especially mobile providers, 
> who are using it natively nowadays.
> 
> hope this helps,
> 
> Doug

The most valuable/useful network resource available today using IPv6 is a 
mobile network customer. (Not necessarily IPV6 only, but IPv4 requires extra 
effort.)

- 
James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: NTP question

2019-05-02 Thread James R Cutler

> On May 2, 2019, at 2:44 PM, Harlan Stenn  wrote:
> 
> 
> 
> On 5/2/2019 9:13 AM, James R Cutler wrote:
>>> On May 2, 2019, at 10:59 AM, William Herrin >> <mailto:b...@herrin.us>> wrote:
>>> 
>>> On Wed, May 1, 2019 at 7:03 PM Harlan Stenn >> <mailto:st...@nwtime.org>> wrote:
>>> 
>>>It's not clear to me that there's anything *wrong* with using the
>>>pool,
>>>especially if you're using our 'pool' directive in your config file.
>>> 
>>> 
>>> The one time I relied on the pool I lost sync a year later when all
>>> three servers the configuration picked withdrew time services and the
>>> still-running ntp client didn't return to the names to find new ones.
>>> Wonderful if that's fixed now but the pool folks argued just as
>>> strongly for using it back then.
>>> 
>>> Also, telling the security auditor that you have no idea who supplies
>>> your time source is pretty much a non-starter. You can convince them
>>> of a lot of things but you can't convince them it's OK to have no idea
>>> where critical services come from.
>>> 
>>> That's what's wrong with the pool.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> -- 
>>> William Herrin  her...@dirtside.com
>>> <mailto:her...@dirtside.com>  b...@herrin.us <mailto:b...@herrin.us>
>>> Dirtside Systems . Web: <http://www.dirtside.com/>
>> 
>> I have only ever used the pool as a supplement to other servers. Here is
>> a snippet from ntp.conf that was found in the bottom of a locked filing
>> cabinet stuck in a disused lavatory with a sign on the door saying
>> 'Beware of the Leopard.’ *
>> 
>>#External Time Synchronization Source Servers
>>#
>>servertick.usno.navy.mil# open access
>>servertime.apple.com <http://time.apple.com># open access
>>serverTime1.Stupi.SE# open access
>>serverntps1-0.uni-erlangen.de <http://ntps1-0.uni-erlangen.de># open
>>access
>>server0.pool.ntp.org <http://0.pool.ntp.org># open access
>>server1.pool.ntp.org <http://1.pool.ntp.org># open access
>>server2.pool.ntp.org <http://2.pool.ntp.org># open access
> 
> I recommend you replace the above 3 lines with:
> 
> pool CC.pool.ntp.org
> 
> where CC is an appropriate country code or region.
> 
> H
> --
>>servernist1-nj2-ustiming.org <http://nist1-nj2-ustiming.org># open
>>access
>>servernist1-chi-ustiming.org <http://nist1-chi-ustiming.org># open
>>access
>>servernist1-pa-ustiming.org <http://nist1-pa-ustiming.org># open access
>>#
>> 
>> 
>> I have not kept up with pool changes since then.
>> 
>> *Apologies to Douglas Adams
> 
> -- 
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!

Harlan,

That is good advice.  

Company($dayjob) no longer exists, but I will remember your advice next time I 
configure 4 or more Mac minis as an NTP peer group in my home office lab — I 
let the last configuration lapse as keeping up with Apple hardware and macOS 
changes was challenge enough and I no longer supported Network Time Services 
for any $dayjob or client.

The only other note is that, for Company($dayjob), I obtained explicit 
permission from each of a set of globally distributed time services (not shown 
above). I recommend that any new NTP peer group be configured with as diverse a 
set of servers as possible, not limited to just pool and not limited to a 
single connection type. 

Thank you.

Jim
-
James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: NTP question

2019-05-02 Thread James R Cutler

> On May 2, 2019, at 10:59 AM, William Herrin  wrote:
> 
> On Wed, May 1, 2019 at 7:03 PM Harlan Stenn  > wrote:
> It's not clear to me that there's anything *wrong* with using the pool,
> especially if you're using our 'pool' directive in your config file.
> 
> The one time I relied on the pool I lost sync a year later when all three 
> servers the configuration picked withdrew time services and the still-running 
> ntp client didn't return to the names to find new ones. Wonderful if that's 
> fixed now but the pool folks argued just as strongly for using it back then.
> 
> Also, telling the security auditor that you have no idea who supplies your 
> time source is pretty much a non-starter. You can convince them of a lot of 
> things but you can't convince them it's OK to have no idea where critical 
> services come from.
> 
> That's what's wrong with the pool. 
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin  her...@dirtside.com 
>   b...@herrin.us 
> Dirtside Systems . Web:  >

I have only ever used the pool as a supplement to other servers. Here is a 
snippet from ntp.conf that was found in the bottom of a locked filing cabinet 
stuck in a disused lavatory with a sign on the door saying 'Beware of the 
Leopard.’ *

#   External Time Synchronization Source Servers
#
server  tick.usno.navy.mil  # open access
server  time.apple.com  # open access
server  Time1.Stupi.SE  # open access
server  ntps1-0.uni-erlangen.de # open access
server  0.pool.ntp.org  # open access
server  1.pool.ntp.org  # open access
server  2.pool.ntp.org  # open access
server  nist1-nj2-ustiming.org  # open access
server  nist1-chi-ustiming.org  # open access
server  nist1-pa-ustiming.org   # open access
#

I have not kept up with pool changes since then.

*Apologies to Douglas Adams

Re: NTP question

2019-05-01 Thread James R Cutler

> On May 1, 2019, at 9:45 PM, Harlan Stenn  wrote:
> 
> 
> 
> On 5/1/19 5:39 PM, William Herrin wrote:
>> On Wed, May 1, 2019 at 12:23 PM Mehmet Akcin  wrote:
>> 
>>> I am trying to buy a GPS based NTP server like this one
>>> 
>>> https://timemachinescorp.com/product/gps-time-server-tm1000a/
>>> 
>>> but I will be placing this inside a data center, do these need an actual
>>> view of a sky to be able to get signal or will they work fine inside a data
>>> center building? if you have any other hardware requirements to be able to
>>> provide stable time service for hundreds of customers, please let me know.
>>> 
>> 
>> You buy a powered GPS antenna for it. Which antenna depends on the cable
>> length and type. The amplifier in the antenna amplifies the signal just
>> enough to overcome the cable loss between the antenna and the receiver.
>> Nice thick cables lose less signal. Dinky thin ones are easier to work with.
>> 
>> You sure you need a GPS NTP server? You understand that if you do, you need
>> two for reliability right, and probably at geographically diverse
>> locations? If you're not on an air-gapped network, consider syncing a
>> couple head-end NTP servers against tick and tock (.usno.navy.mil, the
>> naval observatory) and not worrying about it. One less piece of equipment
>> to manage, update, secure, etc.
> 
> Two is not a great number.  If they disagree, there is no majority
> clique to be found.
> 
> Also, there is something to be said for using different models/vendors
> for the time sources.  If you only have the same model from one vendor
> and there is a bug, you can lose all your time sources at once.   The
> GPS week rollover happens every ~19.7 years, and when that problem hits
> is a function of the firmware and a manufacturing date put in the firmware.
> 
> These problems can be mitigated if you have "enough" time sources for
> your internal NTP servers and you peer with enough other, possibly your,
> servers.
> 
>> Regards,
>> Bill Herrin
> 
> -- 
> Harlan Stenn 
> http://networktimefoundation.org - be a member!

To amplify the points made by Harlan Stenn:

Four is a better number locally for ntpd instances. As for different 
models/vendors for the time sources, I consider the GPS constellation as one 
vendor so I add multiple internet-connected sources as well to my ntp.conf 
instances.


James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: NTP Question

2019-05-01 Thread James R Cutler

On Wed, May 01, 2019 at 02:35:58PM -0700, Harlan Stenn wrote:
> - Why do folks want to have one or more NTP server masters that have at
> least 1 refclock on them in a data center, instead of having their data
> center NTP server masters that only get time over the internet?

Answers to that include:
Keeping the Auditors happy
Knowing that “everyone does it” - the vendor told them so
Bragging rights (expensive hardware)
Being unbothered by fighting with facilities for building penetrations and 
antenna mounts
Misunderstanding the beauty and economy Dave Mills marvelous algorithms for 
consistent time based on multiple sources, even those connected via internet
Unwillingness or inability to leverage other local resources capacity to run 
ntpd with minimal impact in order to have a good constellation of local NTP 
servers
Willingness to farm out time service without doing a deep dive into why and 
how, just leaving the design to the appliance vendors 
This covers most of what I have encountered in providing enterprise time 
services for $dayjob+clients. I probably left out some significant points, but 
it has been a few years...

My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?)

2019-04-26 Thread James R Cutler

--- amitch...@isipp.com <mailto:amitch...@isipp.com> wrote:
From: "Anne P. Mitchell, Esq." mailto:amitch...@isipp.com>>

[This .sig space open to suggestions.]

Just to continue this clearly trivial discussion:

I enjoy your signature. It always leaves no question regarding the posting 
identity.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Comcast storing WiFi passwords in cleartext?

2019-04-25 Thread James R Cutler

> On Apr 25, 2019, at 8:26 AM, K. Scott Helms  wrote:
> 
> People are missing the point here.  This is _not_ a Comcast "issue" this same 
> data is available to every single cable operator in the US who deploys 
> bundled modem/router/APs that follow the CableLabs standard.  They may or may 
> not expose the data to their end customers, but it's stored in their systems 
> and is often available to their support teams.
> 
> http://mibs.cablelabs.com/MIBs/wireless/CLAB-WIFI-MIB-2017-09-07.txt 
>   
> 
> The same thing applies to most FTTH and xDSL deployments.  They use TR-069 to 
> collect the data instead of SNMP but the object model is the same.  The WiFi 
> MIB above is explicitly built to mimic TR-181 functionality.
> 
> Scott Helms
> 
> 
> 
> On Wed, Apr 24, 2019 at 5:48 PM Rich Kulawiec  > wrote:
> On Wed, Apr 24, 2019 at 03:13:33PM +, Benjamin Sisco wrote:
> > The bigger concern should be the cleartext portion of the subject.
> 
> Yes, and the availability of all this to anyone who hacks Comcast
> customer support.
> 
> —rsk

I have yet to hear any discussion of the business value of access to WiFi 
network password, especially as compared to billing and identity data. Also, 
remote management of local networks by definition requires credentials stored 
off site from the customer. To the typical customer, loss of connectivity is 
much worse than a small chance of sharing the WiFi.

Narrowing the discussion back to Comcast, credentials for “guest” WiFi seem to 
be more used than purloined SNMP MIB data.

Re: Frontier rural FIOS & IPv6

2019-04-01 Thread James R Cutler

> On Mar 31, 2019, at 9:50 PM, Matt Hoppes  
> wrote:
> 
> The telephone example:
> What IS the benefit of DTMF other than I can dial faster?  None. And I can 
> use IVRs. Again - no impact to me as a telephone company. 
> 

OK, this is off topic to an extent, but DTMF provided the opportunity for 
immense savings in the cable plant because of the copper gauge reduction 
allowed. Dropping the requirement for transmitting switch actuations (DC 
on-off) allowed development of more cost effective transmission solutions. The 
removal of the mechanical dial and included governor mechanism dropped both 
manufacturing and maintenance costs for telephone sets and provided the 
opportunity for creative packaging not limited by the rotary dial size. 

That’s enough off topic for now.

As for IPv6: If one assumes that the Internet is a world-wide network of 
networks and that connected devices, including multiple personal devices, will 
continue to proliferate — Management and equipment cost for kluges to 
compensate for the dearth of IPv4 addresses and still provide universal 
connectivity will continue to escalate. Investment in native IPv6 provides an 
obvious future cost avoidance opportunity.

Even ISPs that say, “My network is just fine.” will eventually run into this 
financial reality.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Network Speed Testing and Monitoring Platform

2019-01-16 Thread James R Cutler

On Jan 16, 2019, at 4:01 PM, valdis.kletni...@vt.edu wrote:
> 
> So out of curiosity - does anybody have info on what percentage of residential
> internet connections are on CPE that's been suitably de-bufferbloated?

I have not read anything suggesting that de-bufferbloating has happened. It 
would be nice to see something.

I participated in bufferbloat testing on Comcast Business Internet some years 
ago and have never seen any results published.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: plaintext email?

2019-01-15 Thread James R Cutler

Warning —top posting also with interspersed comments.

👍🏻  <— that’s a thumbs up
> On Jan 15, 2019, at 1:36 PM, b...@theworld.com wrote:
> 
> 
> Re: Top Posting
> 
> To me it depends on whether there's any chance the reader won't know
> what precisely you're responding to in which case in-line is
> warranted.
> 
> I don't have any quoted text in this msg (is that top posting?), is
> anyone lost?
> 
> THE REAL REASON for my responding at all is because there are people
> who lurk and sometimes manage lists who will react angrily, often in
> private email (cowards! :-) ), to a top-post as if you violated some
> inarguable rule and you maybe should be banned or at the very least
> are very rude, similar in tone to if you'd spammed the list or
> whatever.

I am appalled at the nastiness regarding posting prejudices.
"But, but, if your cognitive processes do not match mine, you are an idiot.”
“Why should I love my neighbor as myself? I am so much better"
> 
> I just thought I'd point out it's just a formatting opinion, a
> judgement call by whoever is responding, and nothing more, it's not
> some rule everyone accepts so lose the self-righteous tone.
> 
> If anything I suspect it might have to do with the MUA one uses.
> 
> Maybe, at the very least, accept that the person who top-posted is
> looking at a very different layout than you are, one where that
> top-post looks just fine?

And the viewer/replier may have significantly different cognitive skills.
> 
> I use Emacs/VM for email. It's quite good at, for example, splitting
> the screen so I can look ahead (or behind) in the message if I've lost
> track of some context, or even opening multiple related msgs (even if
> already filed) simultaneously to go back and review what's been said
> already, or forward even to see if one is about to say something which
> has already been adequately addressed.
> 
> It's probably quite a bit different than the one-way upside-down
> (date-wise) scrolling on some vendor-supplied smartphone app.
> 
> I've used them when I've had nothing else and I haven't a clue how one
> can do much else than essentially "more" thru the latest, silo'd, 10^9
> spams interspersed with the occasional bit of ham 20 lines at a time
> so I guess I can understand why some become desperate and angry to get
> others to format their email for their convenience.
> 
> Maybe your problem isn't the top-posting but your lousy MUA?

Or, perhaps, attitude?
> 
> -- 
>    -Barry Shein
> 
> Software Tool & Die| b...@theworld.com | 
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*


James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Top Posting Was: Re: plaintext email?

2019-01-15 Thread James R Cutler

On Jan 15, 2019, at 1:06 PM, John Levine  wrote:
> 
> By the way, have you changed and memorized all your passwords for this
> month yet?

No, I do not follow a predictable rhythm in changing passwords. Some change 
frequently, some change infrequently.

I only remember my login password, my iDevice PINs, and my 1Password password. 
1Password generates and remembers all the rest.

Changing passwords frequently is not effective if passwords are re-used between 
multiple sites. This continues to be the number one rule the I try to inculcate 
in my clients.

Re: plaintext email?

2019-01-13 Thread James R Cutler

On Sun, Jan 13, 2019 at 01:50:58PM -0600, Mike Hammett wrote:
> People use plain-text e-mail on purpose? 


Yes.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: Stupid Question maybe?

2018-12-18 Thread James R Cutler

> On Dec 18, 2018, at 5:43 PM, Brandon Martin  wrote:
> 
> On 12/18/18 2:58 PM, Scott Weeks wrote:
>> You can safely say that 72.234.7.0/24 is a
>> Class C/sized/  network.
>> --
>> But most don't say that.  They just say it's
>> a Class C, which it most assuredly is not.
>> I heckle them until they can give the correct
>> answer: leading bits are 110 or it's not a
>> Class C subnet.
>> scott
> 

I am certain that I read the RFC years ago, but I can’t remember it.  Which RFC?

> This is a favorite interview type question of mine, but I won't disqualify a 
> candidate if they can't come up with the reason.  It's more of a probe for 
> historical domain knowledge (one of many I'll slip in).
> -- 
> Brandon Martin

Re: GTT Regulatory Recovery Surcharge

2018-12-02 Thread James R Cutler

On Dec 2, 2018, at 6:04 PM, Clayton Zekelman  wrote:
> 
> I can't imagine how the corporate sociopaths could justify charging an 
> American recovery fee on a service delivered in Canada.

I would speculate that the reason is ever popular ‘because they can”.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: Oct. 3, 2018 EAS Presidential Alert test

2018-10-03 Thread James R Cutler

Andy,

Received on iPhone 7/iOS 12 on Sprint in SE Michigan.

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Andy Ringsmuth
> Sent: Wednesday, October 03, 2018 2:53 PM
> To: nanog@nanog.org
> Subject: Oct. 3, 2018 EAS Presidential Alert test
> 
> Did anyone on AT&T or an iPhone receive the test today? I believe it was 
> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20 
> EDT.
> 
> I’m in CDT, so 1:18 and 1:20 p.m. CDT.
> 
> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the sending 
> of this at 1:52 p.m. CDT, nothing on phones. I have an office full of AT&T 
> iPhones and not a single one of them alerted.
> 
> FEMA says https://www.fema.gov/emergency-alert-test
> 
> "Cell towers will broadcast the WEA test for approximately 30 minutes 
> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones that 
> are switched on, within range of an active cell tower, and whose wireless 
> provider participates in WEA should be capable of receiving the test message. 
> Some cell phones will not receive the test message, and cell phones should 
> only receive the message once."
> 
> My wife, with a Sprint iPhone, received the test.
> 
> 
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com
> 
>

Re: Proving Gig Speed

2018-07-16 Thread James R Cutler

> On Jul 16, 2018, at 4:31 PM, Carlos Alcantar  wrote:
> 
> It's a complete rabbit hole different hardware with different browsers give 
> different readings, even not having your laptop plugged into power can cause 
> a change in results due to dropping cpu to power save.  The only reliable 
> solution we found for field techs was the exfo ex1.Still talks to the 
> ookla speedtest server etc.  Obvious this is a well known issue and exfo has 
> a solution.
> 
> 
> 
> https://www.exfo.com/en/products/field-network-testing/network-protocol-testing/ethernet-testing/ex1/
> 
> 
> 


This is an interesting device. But the manufactures pages promote it like 
“Speedtest for Dummies”.

Why don’t the User Manual or Spec Sheet mention IPv6 (or even (IPv4)?

I should think technicians would want technical answers.

Cutler


> 
> 
> Carlos Alcantar
> 
> Race Communications / Race Team Member
> 
> Phone: +1 415 376 3314 / car...@race.com / 
> http://www.race.com
> 
> 
> 
> 
> From: NANOG  on behalf of Chris Gross 
> 
> Sent: Monday, July 16, 2018 12:39 PM
> To: Matt Erculiani
> Cc: North American Network Operators' Group
> Subject: RE: Proving Gig Speed
> 
> Winner winner chicken dinner. I forgot to pull "Antivirus is at fault" card 
> from my deck. 250/675 with it installed, 920/920 when removed so now I get to 
> pass the the issue onwards.
> 
> Thanks everyone for your replies and the responses for the 
> adolfintel/speedtest github, I'll definitely look at it as a replacement for 
> later.
> 
> -Original Message-
> From: Matt Erculiani 
> Sent: Monday, July 16, 2018 2:17 PM
> To: Chris Gross 
> Cc: North American Network Operators' Group 
> Subject: Re: Proving Gig Speed
> 
> We use Iperf3 for customers that complain about throughput, it's relatively 
> low overhead compared to the Ookla HTML5 client. Same scenario as you, we 
> have the tech hook up their laptop to the customer's drop and perform 
> testing. I suspect your antivirus may be attempting to perform real-time 
> inspection on the http(s) traffic, which would crush the little laptop CPU 
> for sure.
> 
> Message me off-list and I'll send you a private Iperf3 server IP to test with.
> 
> -Matt
> 
> On Mon, Jul 16, 2018 at 12:58 PM, Chris Gross  
> wrote:
>> I'm curious what people here have found as a good standard for providing 
>> solid speedtest results to customers. All our techs have Dell laptops of 
>> various models, but we always hit 100% CPU when doing a Ookla speedtest for 
>> a server we have on site. So then if you have a customer paying for 600M or 
>> 1000M symmetric, they get mad and demand you prove it's full speed. At that 
>> point we have to roll out different people with JDSU's to test and prove 
>> it's functional where a Ookla result would substitute fine if we didn't have 
>> crummy laptops possibly. Even though from what I can see on some google 
>> results, we exceed the standards several providers call for.
>> 
>> Most of these complaints come from the typical "power" internet user of 
>> course that never actually uses more than 50M sustained paying for a 
>> residential connection, so running a circuit test on each turn up is 
>> uncalled for.
>> 
>> Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop 
>> that can actually do symmetric gig, a rugged small inexpensive device we can 
>> roll with instead to prove, or any other weird solution involving ritual 
>> sacrifice that isn't too offensive to the eyes?

Re: SIP fax sending software?

2018-05-30 Thread James R Cutler

> On May 30, 2018, at 4:13 PM, John R. Levine  wrote:
> 
> Can anyone recommend software that sends faxes over SIP?  I have plenty of 
> inbound fax to email services, but now and then I need to send a reply and it 
> looks tacky to use one of the free web ones that put an ad on it.
> 
> I know that if I wanted to pay $15/mo there are lots of lovely services but 
> we're taking about one fax a month, maybe, here.
> 
> Ideally it'd take a postscript or PDF or Word document and a phone number and 
> fax it to that number.  I have Ubuntu, FreeBSD, and MacOS boxes.  Any 
> suggestions?
> 
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Not SIP, but over TCP/IP, I have been happy with iFax from www.ifaxapp.com 
<http://www.ifaxapp.com/> which takes a  document and a phone number and sends 
the document to that number. Charging is against credits which are available at 
varying prices. 

The iFax application is available for macOS, Windows, iOS, and Android. I use 
it on iOS and macOS. See the website for more details on inbound fax, document 
scanning, HIPAA, and other features. 

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: USB Ethernet Adapters

2018-05-16 Thread James R Cutler

> On May 16, 2018, at 5:55 AM, ~  wrote:
> 
> AK-A7611011

The Anker USB-C to Ethernet adapter also uses the Realtek 0x8153 chip.

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE

2018-04-02 Thread James R Cutler

> On Apr 2, 2018, at 11:35 AM, Simon Lockhart  wrote:
> 
> …
> This looks like a willy-waving exercise by Cloudflare coming up with the 
> lowest
> quad-digit IP. They must have known that this would cause routing issues, and
> now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.
> 

I am very impressed at Cloudflare’s forward thinking to force investing a 
significant amount of IPv4 infrastructure. This will obviously become even more 
important in the future as IPv6 withers away and is replaced by IPv4.

And, I repeat, please tell me how many end users know about or care about DNS, 
even after reading snake oil advertisements.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: Yet another Quadruple DNS?

2018-03-29 Thread James R Cutler

> On Mar 29, 2018, at 9:07 AM, Chip Marshall  <mailto:c...@2bithacker.net>> wrote:
> 
> ...
> I think the real question is "when are we going to get some memorable
> IPv6 public recursive DNS servers?"
> 
> 2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as
> 8.8.8.8 or 9.9.9.9.
> 
> -- 
> Chip Marshall mailto:c...@2bithacker.net>>
> http://2bithacker.net/ <http://2bithacker.net/>

Perhaps the real question is why is this important. The great mass of users 
simply does not even know what DNS is. And, supposedly, we wise NANOG people 
know how to cut and paste.

- 75.75.75.75
James R. Cutler
james.cut...@consultant.com <mailto:james.cut...@consultant.com>
PGP keys at http://pgp.mit.edu <http://pgp.mit.edu/>

Re: Waste will kill ipv6 too

2017-12-28 Thread James R Cutler

On Dec 28, 2017, at 4:31 PM, Thomas Bellman  wrote:
> 
> On 2017-12-28 22:31, Owen DeLong wrote:
> 
>> Sure, but that’s intended in the design of IPv6. There’s really no need
>> to think beyond 2^64 because the intent is that a /64 is a single subnet
>> no matter how many or how few machines you want to put on it.
> 
>> Before anyone rolls out the argument about the waste of a /64 for a point
>> to point link with two hosts on it, please consider that the relative
>> difference in waste between a /64 with 10,000 hosts on it and a /64 with
>> 2 hosts on it is less than the rounding error in claiming that a /64 is
>> roughly 18 quintillion addresses. In fact, it’s orders of magnitude less.
> 
> [...]
> 
>> We may, someday, wish we had gone to some value of N larger than 128,
>> but I seriously doubt it will occur in my lifetime.
> 
> My problem with the IPv6 addressing scheme is not the waste of 64 bits
> for the interface identifier, but the lack of bits for the subnet id.
> 16 bits (as you normally get a /48) is not much for a semi-large organi-
> zation, and will force many to have a dense address plan, handing out
> just one or a few subnets at a time, resulting in a patch-work of
> allocations.  24 bits for subnet id would be more usable.

There is no prohibition of requesting an allocation which matches your network. 
That is, simply request what is needed with suitable data for justification and 
get your /40 or whatever.

So, you really have no problem with a default /48 site allocation, just with 
the fact you must do actual work to justify whatever request you make for a 
network with many sites, or large sites, or both. It should be obvious that 
this is actually less work than continually fiddling with “dense address 
plans”. This is why IPv6 should be less costly to deploy and maintain, using 
standard templates, than IPv4 ever dreamed of being. Please let it be so,


> 
> Consider e.g. a university or company campus.  There are probably at
> least 16 departments, so I would like to use 8 bits as department id.
> Several departments are likely to have offices on more than one floor,
> or in more than one building, so I would like to let them have 4 bits
> to specify location, and then 8 bits to specify office/workplace within
> each location.  And allow them to hand out 16 subnets per workplace.
> That adds up to 24 bits.  So a /40 would be nice, not a /48.
> 
> Similarly, an ISP that wants a structured address plan, e.g. to encode
> prefecture, city and part of city in the address, will quickly use up
> bits in the customer id part of the address.
> 
> 
>   /Bellman
>

Re: Waste will kill ipv6 too

2017-12-28 Thread James R Cutler

[Deliberate top post]

All this fear about “waste” killing IPv6 is unwarranted.

It is about time to look at the business aspect of wasting human resources 
fiddling with micro-optimization. We seem to have have two choices:

A. Keep arguing and complicating management of the IPv6 Internet and wasting 
human resources ==> more cost. 

B. Deploy IPv6 to end users using the RA/DHCP-PD and the like with the simplest 
possible templates, e.g., /64+/48 to every edge host/router, no questions 
asked, thus requiring fewer human resources ==> less cost.

Some major networks have long since adopted choice B.

The pace of technology change makes likely that "Waste will kill ipv6 too” will 
be a moot issue by any of the time estimates discussed previously. Any prudent 
business will choose “B”. Any other choice from this list would be a waste of 
time and money. 

See also “Human Use of Human Beings” by Norbert Weiner. 

Cutler

> On Dec 28, 2017, at 12:12 PM, Laszlo Hanyecz  wrote:
> 
> 
> 
> On 2017-12-28 17:55, Michael Crapse wrote:
>> Yes, let's talk about waste, Lets waste 2^64 addresses for a ptp.
>> If that was ipv4 you could recreate the entire internet with that many
>> addresses.
> 
> After all these years people still don't understand IPv6 and that's why we're 
> back to having to do NAT again, even though we now have a practically endless 
> supply of integers.  If we could have all agreed to just do /64+/48 to every 
> edge host/router, no questions asked, we'd never have to talk about this 
> again.  Playing tetris with addresses had to be done with IPv4 but it's not 
> even remotely a concern with IPv6 - the idea of waste and sizing networks is 
> a chore that doesn't need to be thought about anymore.  As you say, if you 
> have a /64, you could run the entire internet with it, if you really wanted 
> to do the kinds of hacks we've been doing with v4, but the idea is that you 
> don't need to do any of that.
> 
> -Laszlo
> 
>> 
>> On 28 December 2017 at 10:39, Owen DeLong  wrote:
>> 
 On Dec 28, 2017, at 09:23 , Octavio Alvarez 
>>> wrote:
 On 12/20/2017 12:23 PM, Mike wrote:
> On 12/17/2017 08:31 PM, Eric Kuhnke wrote:
> Call this the 'shavings', in IPv4 for example, when you assign a P2P
> link with a /30, you are using 2 and wasting 2 addresses. But in IPv6,
> due to ping-pong and just so many technical manuals and other advices,
> you are told to "just use a /64' for your point to points.
 Isn't it a /127 nowadays, per RFC 6547 and RFC 6164? I guess the
 exception would be if a router does not support it.

 Best regards,
 Octavio.
>>> Best practice used most places is to assign a /64 and put a /127 on the
>>> interfaces.
>>> 
>>> Owen
>>> 
>>> 
>>> 
>

Re: MPLS in the campus Network?

2016-10-21 Thread James R Cutler

On Oct 21, 2016, at 4:18 PM, Youssef Ghorbal  wrote, 
in part:
> 
> Until people start complaining they can no more auto discover their
> Time Capsule left in the other building whereas their colleagues in
> the other building can etc etc. All fancy discover protocols breaks
> without L2 continuity !


Minor Correction:  Correctly configured*, an Airport Extreme basestation (Time 
Capsule or not) does not require L2 connectivity to discover. In fact, Wide 
Area is used for discovery of many services not necessarily reachable by L2 
connectivity. Apple’s Back to My Mac service is one example.

*Apple’s "Back to My Mac” Wide Area Bonjour is enabled on an Airport 
basestation by entering appropriate Apple ID and password data in the Base 
Station tab as accessed by Airport Utility.


James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: packet loss question

2016-07-07 Thread James R Cutler

> On Jul 7, 2016, at 3:17 PM, Phillip Lynn  wrote:
> 
> Hi all,
> 
>  I am writing because I do not understand what is happening.  I ran mtr 
> against our email server and www.teco.comand below are the results.  I am not 
> a network engineer so I am at a loss.  I think what I am seeing is maybe a 
> hand off issue, between Frontier and Level3Miami2. If I am correct then what 
> can I do?
> 
>  My system is running Centos 6.5 Linux.
> 
> Thanks,
> 
> Phillip
> 
> 
> 
> (! 1011)-> sudo mtr -r netwolves.securence.com
> HOST: x@netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1  0.0%100.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%103.2 2.0 1.0   4.3   1.2
>  3. 172.99.44.214 0.0%104.0 4.9 2.3   6.9   1.5
>  4. ae8---0.scr02.mias.fl.fronti  0.0%109.3 9.1 7.5   9.8   1.0
>  5. ae1---0.cbr01.mias.fl.fronti  0.0%108.9   9.1   7.6 9.7 0.7
>  6. lag-101.ear3.Miami2.Level3.n 80.0%109.0   8.9   8.8 9.0 0.1
>  7. 10ge9-14.core1.mia1.he.net0.0%10   14.3 13.0 7.6  18.1   4.3
>  8. 10ge1-1.core1.atl1.he.net 0.0%10   25.6  33.2 22.4  99.7  23.6
>  9. 10ge10-4.core1.chi1.he.net0.0%10   45.6  51.8 45.5  82.7  12.5
> 10. 100ge14-2.core1.msp1.he.net   0.0%10   53.6  63.9 53.6 125.2  21.8
> 11. t4-2-usi-cr02-mpls-usinterne  0.0%10   53.2  73.1 53.2 225.6  54.0
> 12. v102.usi-cr04-mtka.usinterne  0.0%10   53.2  53.9 53.2  55.3   0.6
> 13. netwolves.securence.com   0.0%10   53.4  53.9 53.4  55.4   0.7
> 
> (! 1014)-> sudo mtr -r www.teco.com
> HOST: x@netwolves.comLoss%   Snt   Last   Avg Best  Wrst StDev
>  1. 172.24.109.1  0.0%100.6 0.6 0.6   0.7   0.0
>  2. lo0-100.TAMPFL-VFTTP-322.gni  0.0%10  104.8 81.4 1.1 113.2  43.2
>  3. 172.99.47.198 0.0%10  115.0 77.8 2.9 115.0  40.2
>  4. ae7---0.scr01.mias.fl.fronti  0.0%10  111.1 80.2 8.5 113.5  41.3
>  5. ae0---0.cbr01.mias.fl.fronti  0.0%10  105.9  82.2   7.6 115.4 33.8
>  6. lag-101.ear3.Miami2.Level3.n 70.0%10  116.1  80.2   8.5 116.1 62.0
>  7. NTT-level3-80G.Miami.Level3.  0.0%10  110.0 81.5 9.0 120.3  41.9
>  8. ae-3.r20.miamfl02.us.bb.gin.  0.0%10  119.8  84.0 10.0 119.8  38.5
>  9. ae-4.r23.asbnva02.us.bb.gin. 10.0%10  137.4 107.6 30.1 142.7  45.7
> 10. ae-2.r05.asbnva02.us.bb.gin.  0.0%10  135.0 109.9 36.6 140.0  39.1
> 11. xe-0-9-0-8.r05.asbnva02.us.c  0.0%10  147.5 125.6 49.4 165.5  41.1
> 12. 24.52.112.21  0.0%10  158.6 124.0 49.6 161.3  41.5
> 13. 24.52.112.42  0.0%10  151.0 127.7 52.2 159.0  41.2
> 14. ???  100.0100.0 0.0 0.0   0.0   0.0
> 
> --
> Phillip Lynn
> Software Engineer III
> NetWolves
> Phone:813-579-3214
> Fax:813-882-0209
> Email: phillip.l...@netwolves.com
> www.netwolves.com
> 
Phillip,

The data for netwolves.securence.com shows 0% loss between HOST and 
netwolves.securence.com. This is most certainly good. The 80% Loss in line 4 
simply indicates that that particular router was too busy to respond in a 
timely manner to an ECHO request because it was busy forwarding data traffic. 
There is no problem to solve for this connection.

The data for www.teco.com <http://www.teco.com/> has a couple of busy hops. 
However, for as far as the trace succeeds (24.52.112.42) there is no effective 
loss end to end.  The ??? response, similar to *** from traceroute, indicates 
that there is probably no route to the destination from that point. (Or there 
is a firewall blocking SNMP ECHO requests at that point.) Diagnosis may require 
contacting the operator of www.teco.com <http://www.teco.com/> to confirm the 
system is actually on line and operational. Contact information for tech.com is 
in whois.

Auxiliary information - traceroute data from a system in 
plymouth.mi.michigan.comcast.net <http://plymouth.mi.michigan.comcast.net/> 
shows similar results for both targets.

Are there other hosts difficult to reach?

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 Implementation and CPE Behavior

2016-01-11 Thread James R Cutler

> On Jan 11, 2016, at 1:37 PM, Owen DeLong  wrote:
> 
> 
>> On Jan 11, 2016, at 10:23 , James R Cutler  
>> wrote:
>> 
>>> On Jan 11, 2016, at 12:01 PM, Graham Johnston  
>>> wrote:
>>> 
>>> Are most CPE devices generally not IPv6 capable in the first place?  For 
>>> those that are capable are they usually still configured with IPv6 
>>> disabled, requiring the customer to enable it?  For those CPE that are 
>>> capable and enabled, is there a common configuration such as full blown 
>>> DHCPv6 with PD?
>> 
>> I can’t speak regarding “most CPE devices” but for CPE = Apple Airport 
>> Extreme
>> 
>>  • At least since the AirPort Extreme 802.11n (AirPort5,117) was 
>> released in 2011, the hardware has supported native IPv6 routing and 
>> acceptance of PD from the WAN.
>> 
>>  • The default configuration for firmware 7.7.3 is automatic WAN IPv6 
>> configuration, native IPv6 routing, and, acceptance of PD from the WAN. End 
>> systems on the single LAN receive a /64.
> 
> To be more clear… The LAN receives a /64 from which end systems are able to 
> construct one or more end system addresses using SLAAC.

I tried to keep it simple - my original draft said “All end systems on the LAN 
receive the same /64 prefix in RAs, even if the ISP has delegated a /56, for 
example.  It was altogether too wordy so I excised about half of the original 
text. Maybe I went too far.

> 
>> 
>>  • No DHCPv6 is provided to the LAN through firmware up to the current 
>> version 7.7.3. 
>> 
> 
> The good news is that RDNSS is allegedly supported in recent firmware 
> releases.

I have found no documentation from Apple or in the Airport Utility GUI that 
mentions it. I have figured out some of IPv6 entries in .baseconfig files, but 
none for RDNSS.

The bad news is that I have yet to really understand RDNSS in the context of OS 
X. I don’t find any recognizable mention in sysctl inet6 parameters. OS X El 
Capitan systems autoconfigure the LAN/64:EUI-64 address of the Airport Extreme 
along with the IPv4 nnn.nnn.nnn..1 address as DNS server  addresses.  Windows 
10 appears to do the same. (I haven’t bothered to look into Windows internals.  
I don’t get paid to do that anymore.) I keep IPv6 disabled on my Snow Leopard 
Server instances, both because no IPv6 DNS server address is ever 
autoconfigured and because none of those instances should ever get incoming 
IPv6 traffic.
> 
> Owen

Thanks for your comments.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: IPv6 Implementation and CPE Behavior

2016-01-11 Thread James R Cutler

> On Jan 11, 2016, at 12:01 PM, Graham Johnston  
> wrote:
> 
> Are most CPE devices generally not IPv6 capable in the first place?  For 
> those that are capable are they usually still configured with IPv6 disabled, 
> requiring the customer to enable it?  For those CPE that are capable and 
> enabled, is there a common configuration such as full blown DHCPv6 with PD?

I can’t speak regarding “most CPE devices” but for CPE = Apple Airport Extreme

• At least since the AirPort Extreme 802.11n (AirPort5,117) was 
released in 2011, the hardware has supported native IPv6 routing and acceptance 
of PD from the WAN.

• The default configuration for firmware 7.7.3 is automatic WAN IPv6 
configuration, native IPv6 routing, and, acceptance of PD from the WAN. End 
systems on the single LAN receive a /64.

• No DHCPv6 is provided to the LAN through firmware up to the current 
version 7.7.3. 

For all recent Windows, OS X, and. IOS versions, IPv6 “just works” with the 
Airport default IPv6 configuration. Most users can not tell the difference. 

For those connected to ISPs that still can’t spell IPv6, I do manually set 
Internet Options to Configure IPv6: Link-local only. This should not make any 
difference, but it makes me and some eyeballs happier.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: Nat

2015-12-22 Thread James R Cutler

Comments inline


> On Dec 22, 2015, at 12:47 PM, Owen DeLong  wrote:
> 
> 
>> On Dec 22, 2015, at 01:21 , Bjørn Mork  wrote:
>> 
>> 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…
> 
> Arguments based on “need” don’t make any sense in an IPv6 context.
> 
> Sure, we shouldn’t be so profligate in our distribution of the address pool
> that we run out well before the protocol’s useful life is exhausted, but I
> think I’ve shown that the current allocation policies, including /48 have
> adequate protection against that occurring.
> 
> Being more restrictive just for the sake of being more restrictive doesn’t
> serve any purpose. It doesn’t help anyone. As such, I just don’t understand
> those arguments. If someone can show me a tangible benefit from a more
> restrictive policy, I’m open to considering it, but so far, none exists.

The best feature of being more restrictive is continuing employment of people 
and processes for restriction.

The worst feature of being more restrictive is paying for the extra people and 
processes.

If we standardize on /48 (or whatever) then we can put all that money and labor 
into solving the real business problems of the IPv6 Internet..

Cutler
> 
>> 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.
> 
> That’s a really icky alternative to simple BGP multihoming (which is what
> I’m currently using at home).
> 
> Of course, not the worst, but a significantly bad part of this is the provider
> that’s only giving you a /56 to begin with. ;-)
> 
>> Yes, I know. Evil. No need. No CPE support.  Etc.
> 
> True that.
> 
>> 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 :)
> 
> I completely agree.
> 
>> 
>> 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.
> 
> Again, you’re preaching to the choir.
> 
> Owen
>

Re: reliably detecting the presence of a bridge?

2015-12-19 Thread James R Cutler

> On Dec 19, 2015, at 4:53 PM, Larry Sheldon  wrote:
> 
> On 12/19/2015 12:17, William Herrin wrote:
> 
> [snip]
> 
>> I recommend you stop using the word "bridge." I think see where you're
>> heading with it, but I think you're chasing a blind alley which
>> encourages a false mental model of how layer 2 networks function. You
>> came here for answers. This is one of them.
>> 
>> "Bridge" describes a device which existed in layer 2 networks a
>> quarter century ago. You had a 10-base2 ethernet with every station
>> connected to a shared coax wire. Or you had a token ring where each
>> station was wired to the next station in a loop. Or if you were
>> sophisticated you had 10-baseT with a hub that repeated bits from any
>> port to all ports with no concept of packets.
>> 
>> And then you had a bridge which could connect these networks together,
>> buffering complete packets and smartly repeating only the packets
>> which belong on the other side. The bridge let you expand past the
>> distance limitations imposed by the ethernet collision domain, and it
>> let you move between two different speed networks.
>> 
>> These networks are now largely a historical curiousity. There are no
>> hubs, no 10-base2, no token passing rings. Not any more. Individual
>> stations now connect directly to a bridge device, which these days we
>> often call a "switch." Even where the stations have a shared media
>> (e.g. 802.11), the stations talk to the bridge, not to each other.
>> 
>> Bridge specifies a condition that, today, is close enough to always
>> true as makes no difference.
> 
> Super explanation.
> 
> But I still have one question (which might be based on errors)--
> 
> I think I have used WiFi terminals ("air ports", "WiFi routers" [spit]) that 
> offer a "bridge" mode, apparently to build a dedicated radio link between two 
> such terminals.
> 
> Are they operating as a Radia Perlman "bridge", or is this yet another 
> example if the Wiffy World high-jacking words and terms that used to have 
> actual meanings?
> 

Bridge Mode (ATT Passthrough) simply means that the router between the WAN 
connection and the LAN/WiFi ports is turned off and all ports share the same 
switch (so packets just “pass through”. Thus all ports appear connected to a 
common switch.  Call that what you will, there is no spanning tree here even 
though we all love Radia.

> Nice write-up, even though it is sort of sad to be confronted with the fact 
> that my experience and knowledge with hose-connected (10base5. 10base2) or 
> token-ring networks, and hubs, and stuff is now without value.  That is the 
> very worst part of getting old.
> 
> Next objective:  Somebody to 'splain at what happened to the wonderfulness of 
> the OSI model where layer X did not know, could not know, did not care what 
> layer X-1 was, did, or how it did it.

The TCP/IP suite was “free” and essentially drove IPX/SPX, DECNet, AppleTalk, 
and SNA out of any large market.  Digital Equipment Corporation, for example, 
viewed DECnet networking as a profit center rather than a sales enabler for 
their hardware and software.  

And nobody wanted to spend the probably very large cost to remove what was 
essentially network code from applications. This is why almost every 
application existing need (still needs) modification just to accommodate larger 
address integers and a different display mechanism for addresses .
  
> -- 
> sed quis custodiet ipsos custodes? (Juvenal)

Nobody.

Re: Nat

2015-12-19 Thread James R Cutler

This is OT of NAT, but follows the existing discussion.

Since discussion has warped around to host configuration DHCP (again), it might 
be useful to review discussions dating from 2011:

The stupidity of trying to "fix” DHCPv6
and
The Business Wisdom of trying to "fix” DHCPv6

which also refer to discussions from 2009.

The pertinent Business View is 
> The security domain for HOST should not overlap the security domain for 
> ROUTER.
> 
> That is the primary driver of the separate administration of HOST and ROUTER. 
> Heaven help us if the latest M$ virus, or even social-engineering distributed 
> malware began to affect BGP!
It is imperative to supply the features that End System Operators find useful 
for their business. This simple position is independent of IPv4/IPv6 
differences.  

Since DHCP is a Host Configuration tool and is quite independent of router 
configurations except for DHCP forwarding entries, we must quit requiring 
ongoing fiddly network router configuration changes to make End System 
configuration changes. These can be centrally managed by DHCP run to meet End 
System configuration requirement, even including providing default routes. This 
simple position is independent of IPv4/IPv6 differences.

All that is necessary is for us to end the years of religious debate of DHCP vs 
RA and to start providing solutions that meet business management needs.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu



> On Dec 19, 2015, at 1:01 PM, Matthew Petach  wrote:
> 
> On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard  wrote:
>> 
>> 
>> On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
>> 
>>> I'm still waiting for the IETF to come around
>>> to allowing feature parity between IPv4 and IPv6
>>> when it comes to DHCP.  The stance of not
>>> allowing the DHCP server to assign a default
>>> gateway to the host in IPv6 is a big stumbling
>>> point for at least one large enterprise I'm aware
>>> of.
>> 
>> 
>> Tell me again why you want this, and not routing information from the
>> router?
> 
> Apologies for the delay in replying, work has
> been insanely busy as we come to the end
> of the quarter.
> 
> The problem is when you have multiple routers
> in a common arena, there's no way to associate
> a given client with a given router unless the DHCP
> server can give out that information.
> 
> In an enterprise wireless environment,
> you have many different subnets
> for different sets of employees.  Unfortunately,
> the reality of common RF spectrum dictates
> you can't do separate SSIDs for every subnet
> your employees belong to; so, you have one
> SSID for the company that employees associate
> with, and then the DHCP server issues an appropriate
> IP to the laptop based on the certificate/credentials
> presented.  In the v4 world, you get your IP address
> and your router information all from the DHCP server,
> you end up on the right subnet in the right building
> for your job classification, and all is good.
> In the v6 world, your DHCP server hands you an IP
> address, but the client sees an entire spectrum of
> routers to choose from, with no idea of which one
> would be most appropriate to make use of.  Do I
> use the one that's here in the same building as me,
> or do I use one that's several blocks away in an
> entirely different part of the campus?
> 
> The wonderful thing about modern wireless setups
> for enterprises is that you can allow your employees
> to all have their laptops configured to associate with
> the same SSID, and handle all the issues of assigning
> them to a particular subnet and vlan at the RADIUS/DHCPv4
> level; you don't have to have different employees on
> different SSIDs for finance vs engineering vs HR
> vs sales.  In v4, you can segment the employees
> very nicely after they've associated with the AP
> and give them all the necessary information for
> building in which they're in.  V6 doesn't provide that
> ability; so, I associate with the AP, I get my IPv6 address,
> and then I look at which possible routers are announcing
> information about my subnet, and I see there's one in
> building B, one in building F, and one in building W, and
> I just randomly pick one, which may be nearby, or may
> be across the other side of campus.  Furthermore, I also
> see all the announcements from routers for subnets
> I'm *not* a part of, cluttering up the spectrum.  Rather
> than have routers spewing out "here I am" messages
> and taking up RF spectrum, I'd much prefer to explicitly
> tell clients "you're in sales, you're in building W, her

Re: Modem as a service?

2015-12-06 Thread James R Cutler

> On Dec 6, 2015, at 2:19 PM, James Laszko  wrote:
> 
> ... we don’t need to actually connect to the OOB modem on the other side, we 
> just need a NO ANSWER/ANSWER kind of response. …

Forget modems - to probe via some kind of analog connection, just get a single 
instrument wireless telephone with answering capability.  For a bonus, put some 
kind of identifier in the answering message:  No power > no answer; power > 
answer.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: Android (lack of) support for DHCPv6

2015-06-12 Thread James R Cutler

Ray Soucy has given us an nice summary. It goes along with “please let me 
manage my business and don’t take away my tools just to satisfy your 
prejudices.”

Selection of management policies and implementations is ALWAYS a local issue 
(assuming consideration of legal necessities). Especially in the end-to-end 
model, the requirements management of end systems has not changed because the 
IP layer protocol has changed. This is a good reason for not prohibiting 
continuing use of DHCP-based solutions. “Purity of protocols” is not a reason 
for increasing management costs such as described by Ray.

This debate about DHCPv6 has been going on far too long.  I want to know how 
much it will cost the “SLAAC-only” faction to quit fighting DHCPv6.
My conjecture is that it would be minimal, especially as compared to the costs 
for the activities described by Ray.

Putting it differently: What business purpose is served by fighting 
full-functioned DHCPv6 deployment. Don’t give me any RFC or protocol arguments 
- just tell me the business reasons for forcing others to change how they 
manage their business.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu



> On Jun 12, 2015, at 10:07 AM, Ray Soucy  wrote:
> 
> The only thing I would add is that DHCPv6 is not just about "tracking"
> clients.  Yes there are ways to do so using SLAAC, but they are not pretty.
> 
> Giving too much weight to tracking being the reason for DHCPv6 is just as
> bad as giving too much weight to tethering as the reason against it.  It
> skews the conversation.
> 
> For us, DHCPv6 is about *operational consistency*.
> 
> Universities have been running with the end-to-end model everyone is
> looking to IPv6 to restore for a very long time.
> 
> When you connect to our network, wired or wireless, you get a public IP
> with no filtering in place in most cases.
> 
> We have been living the end-to-end model, and that has given us operational
> experience and insight on what it actually takes to support access networks
> using this model.
> 
> Almost every peer institution I talk to has implemented custom systems
> refined over decades to preserve the end-to-end model in a time of
> increasing security incidents and liability.  These include IPAM systems,
> which feed into vulnerability scanning, or host filtering for incident
> response, etc.
> 
> These systems are in place for IPv4, and modifying them to support IPv6
> (which most of us have done) is relatively easy in the case of DHCPv6.
> 
> By maintaining consistency between IPv4 and IPv6 we avoid having to retrain
> hundreds of IT workers on supporting connectivity.  By saying that you
> won't support DHCPv6, you effectively force us into a choice between
> investing considerable effort in redesigning systems and training IT
> personnel, while introducing confusion in the support process because IPv4
> and IPv6 are delivered using completely different methods.
> 
> You have just made it cheaper for us to turn to NAT than to support IPv6.
> That's unacceptable.
> 
> You might be thinking "well that's just universities and a small percent of
> users", but the point here is that we do these things for a reason; we've
> been living without NAT and our collective operational experience doing so
> is something that would be wise to take into consideration instead of
> dismissing it or trying to call us names.
> 
> Organizations running SLAAC who say everything is fine, think everything is
> fine because IPv6 has received almost no attention from bad actors in terms
> of security incidents or denial of service attacks.  Even well known
> servers with IPv6 addresses on our network rarely see SSH attempts over
> IPv6 today.
> 
> *This will fundamentally change as IPv6 adoption grows*.
> 
> Are you prepared to be able to deal with abuse reports of hosts on your
> network participating on denial of service attacks?  Can you associate the
> identity of a system to an individual when law enforcement demands you to
> do so?  How much longer will it take you to track down a host by its IPv6
> address to disable it?  How many other users have degraded service while
> they're waiting for you to do that?
> 
> For most people that are used to the typical IPv4 model (NAT and open pool
> DHCP), these events are very infrequent, so of course they don't get it.
> For those of us running a more liberal network which preserves the
> end-to-end model, free from aggressive filtering on user traffic, these
> incidents are literally daily occurrences.
> 
> The fact is that you never know what service a user might enable on their
> device only to be exploited and degrade service for their peers.
> 
> So yes, we are looking to the

Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality]

2015-03-07 Thread James R Cutler

Frank,

Are your measurements taken at the campus boundary or within the campus network?

I remember the confusion when Centrex was first introduced at UMich. The 
statistic there that confounded was call durations wildly exceeding models, but 
mostly within the campus, not to the outside world.  Could there be peer to 
peer traffic that you do not see?

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

> On Mar 6, 2015, at 11:35 PM, Frank Bulk  wrote:
> 
> The download/upload in our residential/business eyeball network has been
> trending a 95th-percentile based ratio of 9:1.  If I look at a higher-ed
> customer of ours who has symmetric service and has a young demographic the
> average ratio is 11:1 and the peak ratio 8.8:1.  So despite access to
> symmetric speeds, they're not showing a distinctively heavier symmetricity.
> 
> 
> Frank
> 

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality]

2015-02-28 Thread James R Cutler

Mike,

I’m probably happy that I am not normal, as are my clients not normal.

Why are you descending to ad hominem rather than facts?

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

> On Feb 28, 2015, at 1:04 PM, Mike Hammett  wrote:
> 
> Do normal people do it?

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality]

2015-02-28 Thread James R Cutler

On Feb 28, 2015, at 9:19 AM, Mike Hammett  wrote:
> 
> Only have a 25 meg Internet service? Use a 5 MHz channel, not 160 MHz.

So, if I use wireless to my, for example, Apple TV, I should limit the rate 
between my file server Mac and the Apple TV based on my Internet connection 
speed?

I’m not certain that is reasonable.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Verizon Policy Statement on Net Neutrality

2015-02-27 Thread James R Cutler

> On Feb 27, 2015, at 5:52 PM, Naslund, Steve  wrote:
> 
> What is that statement based on?  I have not seen any outcry for more 
> symmetric speeds.  Asymmetry in our networks causes a lot of engineering 
> issues and if it were up to the carriers, we would much rather have more 
> symmetric traffic patterns because it would make life easier for us.  
> Remember that most carrier backbones are built of symmetric circuits.  It 
> would be nice but the users generally download more than they upload.  That 
> is the fact.
> 
> Steven Naslund
> Chicago IL
> 
> 
>> The demand may not be symmetrical, but where demand exists, it is often for 
>> symmetrical speeds.
>> 
>> Side note:  Did I not read that asymmetric paths tend to exacerbate Buffer 
>> Bloat?
> 
>> James R. Cutler
>> james.cut...@consultant.com
>> PGP keys at http://pgp.mit.edu
> 


"the users generally download more than they upload.” may well be true, but is 
refers to bytes moved, not bytes per second.

And, again, what about Buffer Bloat, especially due to considerably slower 
uplinks?


James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Verizon Policy Statement on Net Neutrality

2015-02-27 Thread James R Cutler

> On Feb 27, 2015, at 4:11 PM, Scott Helms  wrote:
> 
> My point is not that upstream
> speed isn't valuable, but merely that demand for it isn't symmetrical and
> unless the market changes won't be in the near term.  Downstream demand is
> growing, in most markets I can see, much faster than upstream demand.

The demand may not be symmetrical, but where demand exists, it is often for 
symmetrical speeds.

Side note:  Did I not read that asymmetric paths tend to exacerbate Buffer 
Bloat?

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 Default Allocation - What size allocation are you giving out

2014-10-09 Thread James R Cutler

On Oct 9, 2014, at 12:07 AM, Faisal Imtiaz  wrote:

> So, let me ask the question in a different manner... 
> What is the wisdom / reasoning behind needing to give a /56 to a Residential 
> customer (vs a /64). 

The wisdom/reasoning behind larger allocations is to control the cost of doing 
business.

Things change.  Customer requirements change.

Arrange your network so that customers can do what they need without 
configuration costs on your part.

Follow the money.   Then keep it.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 Default Allocation - What size allocation are you giving out

2014-10-08 Thread James R Cutler

On Oct 8, 2014, at 9:18 PM, Erik Sundberg  wrote:

> I am planning out our IPv6 deployment right now and I am trying to figure out 
> our default allocation for customer LAN blocks. So what is everyone giving 
> for a default LAN allocation for IPv6 Customers.  I guess the idea of handing 
> a customer /56 (256 /64s) or  a /48 (65,536 /64s) just makes me cringe at the 
> waste. Especially when you know 90% of customers will never have more than 2 
> or 3 subnets. As I see it the customer can always ask for more IPv6 Space.
> 
> /64
> /60
> /56
> /48
> 
> Small Customer?
> Medium Customer?
> Large Customer?
> 
> Thanks
> 
> Erik
> 

Erik,

Selection of a default prefix is easy.  Here are the steps.

1. Design your address allocation systems using /48.
2. Estimate your ongoing address management costs using /48.
3. For each +4 in prefix length, estimate doubling your long term address 
management costs.
4. Keeping in mind  

4.1 Prefixes longer than somewhere around /48 to /56 may be excluded 
from the global routing table
4.2 Your customers want working Internet connections
4.3 You want income at a minimum of ongoing expense

   make a sensible business decision.

Easy-peasy.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Saying goodnight to my GSR

2014-09-20 Thread James R Cutler

On Sep 20, 2014, at 10:18 AM, Matthew Crocker  wrote 
about his old router:

> 
> gsr8-1 uptime is 9 years, 9 weeks, 2 days, 8 hours, 39 minutes
> Uptime for this control processor is 9 years, 2 weeks, 2 days, 18 minutes
> System returned to ROM by Stateful Switchover at 13:46:36 UTC Tue Sep 6 2005
> 

Matt,

Wow.  You have amazing power reliability!

Want to tell us your secret?

Regards.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Credit to Digital Ocean for ipv6 offering

2014-06-19 Thread James R Cutler


On Jun 19, 2014, at 2:02 PM, Daniel Ankers  wrote:

> One of the key things with IPv6 (IMHO) is to stop thinking about addresses,
> and instead just think about networks.  Judging by Owen's earlier mail I
> may not have that quite right and the key might even be to think about
> hierarchies - in either case counting the number of individual addresses is
> something we just don't need to do any more.
> 
> Dan

s/think about networks/think about subnetworks (colloquial: LAN Segments)/ 

With IPv6, the number of hosts in a subnet is (should be) no longer a driver 
for addressing.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Credit to Digital Ocean for ipv6 offering

2014-06-18 Thread James R Cutler

On Jun 18, 2014, at 7:37 PM, Daniel Ankers  wrote:

> On 18 June 2014 19:05, Owen DeLong  wrote:
> 
>> OTOH, it's far better than those ridiculous providers that are screwing
>> over their customers with /56s or even worse, /60s.
>> 
>> Sad, really.
>> 
>> Owen
>> 
>> 
> Is giving a /56 to residential customers REALLY "screwing them over"?
> 
> It may be a failure of imagination on my part, but I'm struggling to come
> up with use cases for the home which would take up even 10% of the networks
> available in a /56.  And if the vast, vast majority of home users will
> never come close to needing the whole of a /56 then I don't see why every
> home should be given a /48.
> 
> Dan

Responding to Dan,

The costs incurred in managing variable subnetting based on user type have been 
clearly demonstrated in almost two decades of IPv4 networking.  If I can assign 
a /48 to each and every customer (not considered a large enterprise) then my 
deployment costs plummet because I do NOT need to spend engineering time on 
address assignment.  I only need to get out my Network Engineer’s binary knife 
to slice the address pie once. The same front office that takes the order can 
at the same time assign the IPv6 Prefix - sort of like Ma Bell does with phone 
numbers.

Since one of my goals as a network provider is to be competitive in price, 
minimizing extraneous labor costs helps me to still make a modest profit.  

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Time Warner IPv6 Reverse DNS?

2014-06-13 Thread James R Cutler

On Jun 13, 2014, at 10:39 AM, Lee Howard  wrote:

> We've corresponded offline.
> 
> I documented the difficulties in providing reverse DNS for IPv6
> residential users in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06
> It's a long-expired draft, which never found sufficient support from a WG
> or AD.  I've been meaning to rewrap it as a BCOP, but lack cycles.
> 
> Lee
> 
> On 6/12/14 11:58 AM, "hasser css"  wrote:
> 
>> Some IPv6 email is not working well for me on my TWC Internet connection
>> due to their IPv6 block not having PTR records.
>> 
>> Is it possible for me to delegate my IPv6 range to my own DNS server, or
>> something similar? I have talked to level 3 support and they were pretty
>> much clueless, so I decide to ask here if anyone has insight or similar
>> issues in the past.
>> 
>> Thanks!
>> 
> 
> 
This exchange brings to mind several questions (and comments):

1. Should not RFC 1033 be considered “Historic”?
I note that iPv6 was only a faint longing and otherwise undefined at 
that time.

2.  What is the real rdns business requirement for residential customers?
I have difficulty finding anything but SMTP servers needing rdns 
entries.
Practical end-to-end security should be independent of media and 
addressing.

3. Would this question be better posed on the “mailop” mailing list (if SMTP 
service is the issue) or perhaps dns-operati...@mail.dns-oarc.net?

Since “hasser css” did not explain his business requirement for rdns, it really 
difficult to provide advice.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Observations of an Internet Middleman (Level3) (was: RIP

2014-05-16 Thread James R Cutler


All this talk about symmetry and asymmetry is interesting.  

Has anyone actually quantified how much congestion is due to buffer bloat which 
is, in turn, exacerbated by asymmetric connections?


James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: NANOG 61 Bellevue - DNS Track

2014-04-26 Thread James R Cutler

Randy,

To an engineer, that _IS_ attractive.

Jim

On Apr 26, 2014, at 9:47 PM, Randy Bush  wrote:

>> I am trying to organize the DNS Track and as usual we would like to
>> make this very attractive.
> 
> mehmet, i know you're an engineer.  screw attractive.  how about
> technically informative and meaty?
> 
> randy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 isn't SMTP

2014-03-26 Thread James R Cutler

On Mar 26, 2014, at 8:47 PM, Fred Baker (fred)  wrote:

> 
> On Mar 25, 2014, at 8:31 PM, Cutler James R  
> wrote:
> 
>> 3.  Arguing about IPv6 in the context of requirements upon SMTP connections 
>> is playing that uncomfortable game with one’s own combat boots.  And not 
>> particularly productive.
> 
> That is one of my two big take-aways from this conversation. The other is 
> that operators of SMTP MTAs should implement RDNS for them, which I thought 
> we already knew.
> 
> To my knowledge, there are three impacts that IPv6 implementation makes on an 
> SMTP implementation. One is that the OS interface to get the address of the 
> next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and 
> would do well to observe RFC 6555’s considerations). Another is that, whether 
> on an incoming or an outbound connection, when the application gets its own 
> address from the OS (binary or as a character string), it needs to allocate 
> more storage for the data structure. The third is that it needs to be able to 
> interpret user@2001:db8::1 as well as user@dns-name and user@192.0.2.1. 
> 
> All things considered, that’s a pretty narrow change set.
> 
> Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. 
> We know that there are people in the world that don’t implement it for IPv4. 
> Yet, here we are, using SMTP/IPv4 to discuss this, and I don’t hear anyone 
> saying that IPv4 isn’t ready for prime time as a result of the fact of some 
> operators not implementing RDNS.
> 
> ...
> 

Fred Baker describes the requirements in a most satisfactory manner.

Thank you, Fred.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to catch a cracker in the US?

2014-03-13 Thread James R Cutler

On Mar 13, 2014, at 3:24 PM, William Herrin  wrote:
> 
> On Thu, Mar 13, 2014 at 3:15 PM, James R Cutler
>  wrote:
>> As of early 1960's - See history of WTBS, Ralph Zaorski, Dick Gruen,
>> Alan Kent, and many others - The then current usage of "hacker" was
>> simply one who produced a "hack" - an unusual or unexpected design
>> or configuration or action which either did the same old thing done more
>> simply/elegantly or which did something new or unexpected altogether.
> 
> Hi James,
> 
> I'm afraid my google-fu doesn't reach back to the 1960's. You don't
> happen to have a handy reference do you?
> 
> Regards,
> Bill Herrin

I carry that data in wet storage, interfaced via voice or 
eyes-on-screen/fingers-on-keyboard.  I haven’t been on the MIT campus for more 
than a few minutes since late 1963.

Regarding the Wikipedia entry for “Hacker”:

The TMRC/MITAL history ignores the pioneering audio systems work that came out 
of WTBS (pre-sale to Ted).  Ralph Zaorski and Barry Blesser were the best 
around at that.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to catch a cracker in the US?

2014-03-13 Thread James R Cutler

On Mar 13, 2014, at 12:46 PM, William Herrin  wrote:
> 
> On Thu, Mar 13, 2014 at 11:45 AM, James R Cutler
>  wrote:
>> And Bill documents yet another redefinition.  Prior to that time, at MIT a 
>> "hacker" produced a novel variation of technology using it in ways not 
>> previously envisioned but not necessarily unlawful.
>> 
>> Mating two different generations of telephone keysets or reducing a complex 
>> rack mount filter to a single small circuit board with an FET or two are 
>> just a couple of examples.  One was just a "hack", the other an "elegant 
>> hack".  We just called
> 
> Hi James,
> 
> Correct me if I'm wrong, but by the time "hacker" emerged as a word
> distinct from "hack" it already carried implications of mischief and
> disregard for the rules in addition to the original implication of
> creatively solving a technical challenge. Is that mistaken?
> 
> Regards,
> Bill Herrin

Bill,

Mistaken? Yes.

As of early 1960’s - See history of WTBS, Ralph Zaorski, Dick Gruen, Alan Kent, 
and many others - The then current usage of “hacker” was simply one who 
produced a “hack” - an unusual or unexpected design or configuration or action 
which either did the same old thing done more simply/elegantly or which did 
something new or unexpected altogether.  Putting an Western Electric power 
plant on an Automatic Electric step-by-step for the East Campus telephone 
switch was one of my “hacks”.

James R. Cutler - james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to catch a cracker in the US?

2014-03-13 Thread James R Cutler

On Mar 13, 2014, at 11:08 AM, William Herrin  wrote:
> 
> On Thu, Mar 13, 2014 at 10:13 AM,   wrote:
>> On Thu, 13 Mar 2014 13:22:40 -, "Sholes, Joshua" said:
>> 
>>> If one came up in this field with a mentor who was old school, or if one
>>> is old school oneself, one tends use the original (as I understand it)
>>> definitions--a "cracker" breaks security or obtains data unlawfully, a
>>> "hacker" is someone who likes ethically playing (in the "joyful
>>> exploration" sense) with complicated systems.
>> 
>> For the old-schoolers, a "cracker" would violate the CFAA to get into a 
>> system.
>> 
>> A hacker would produce a long list of ways to get in without violating the 
>> CFAA.
>> 
>> Unfortunately, we no longer have a well-established word for the latter
>> class of people.
> 
> 
> You're all talkin' 1990s redefinitions here. 1980s crackers cracked
> the copy protections on software (DRM in modern parlance) while
> hackers broke in to online systems. Even that is a redefinition.
> Before that, hackers were anyone who jovially pranked a system in a
> manner typically unlawful which involved creativity and technical
> challenge.
> 
> For example, "hackers" might arrange for live cattle to appear on the
> top of the great dome at MIT.
> 
> Regards,
> Bill Herrin

And Bill documents yet another redefinition.  Prior to that time, at MIT a 
“hacker” produced a novel variation of technology using it in ways not 
previously envisioned but not necessarily unlawful.  

Mating two different generations of telephone keysets or reducing a complex 
rack mount filter to a single small circuit board with an FET or two are just a 
couple of examples.  One was just a “hack”, the other an “elegant hack”.  We 
just called the moving of the rocket a “prank”. 

Cutler



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Filter NTP traffic by packet size?

2014-02-20 Thread James R Cutler


On Feb 20, 2014, at 4:05 PM, Laszlo Hanyecz  wrote:

> Filtering will always break something.  Filtering 'abusive' network traffic 
> is intentionally difficult - you either just let it be, or you filter it 
> along with the 'good' network traffic that it's pretending to be.  How can 
> you even tell it's NTP traffic - maybe by the port numbers?  What if someone 
> is running OpenVPN on those ports?  What about IP options?  Maybe some 
> servers return extra data?  
> 
> This is really not a network operator problem, it's an application problem if 
> anything.  While it makes sense to temporarily filter a large flood to keep 
> the rest of your customers online, it's a very blunt instrument, as the 
> affected customer is usually still taken offline - but I'm talking about 
> specific targeted filters anyway.  Doing blanket filtering based on packet 
> sizes is sure to generate some really hard to debug failure cases that you 
> didn't account for.
> 
> Unfortunately, as long as Facebook loads, most of the users are happy, and so 
> these kinds of practices will likely be implemented in many places, with some 
> people opting to completely filter NTP or UDP.  Maybe it will buy you a 
> little peace and quiet today, but tomorrow it's just going to be happening on 
> a different port/protocol that you can't inspect deeply, and you don't dare 
> block.  I can imagine 10 years from now, where we're writing code that 
> fragments replies into 100 byte packets to get past this, and everyone loses. 
>  Your filter is circumvented, the application performs slower, and the 'bad 
> guys' found another way that you can't filter.  When all that's left is TCP 
> port 443, that's what all the 'abuse' traffic will be using too.
> 
> Laszlo
> 
> 
> On Feb 20, 2014, at 8:41 PM, Edward Roels  wrote:
> 
>> Curious if anyone else thinks filtering out NTP packets above a certain
>> packet size is a good or terrible idea.
>> 
>> From my brief testing it seems 90 bytes for IPv4 and 110 bytes for IPv6 are
>> typical for a client to successfully synchronize to an NTP server.
>> 
>> If I query a server for it's list of peers (ntpq -np ) I've seen
>> packets as large as 522 bytes in a single packet in response to a 54 byte
>> query.  I'll admit I'm not 100% clear of the what is happening
>> protocol-wise when I perform this query.  I see there are multiple packets
>> back forth between me and the server depending on the number of peers it
>> has?
>> 
>> 
>> Would I be breaking something important if I started to filter NTP packets
>>> 200 bytes into my network?
> 
> 

While filtering NTP packets may be a work-around, for any network with firewall 
isolation from the general Internet it would make more sense to:

1.  Establish an internal peer group of NTP Server instances.  As noted, a 
distributed group of four is the absolute minimum, six is more than sufficient.
2.  Default restrict noquery on all internal NTP servers.
2.  Use a common list of external NTP servers for all internal servers.
3.  Provide that list of external NTP servers to the firewall engineer to add 
to a permit ACL (deny all others)

James R. Cutler - james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenNTPProject.org

2014-02-17 Thread James R Cutler

On Feb 17, 2014, at 10:38 AM, Anthony Williams  
wrote:

> Blake:
> 
> Just to make sure I've got this down, listing a device as a "peer" in
> the ntp.conf file will create a situation where both devices are saying,
> "I know what time it is" and splitting the difference?  Whereas when you
> list a device as a "server", it's using that as the authority on the
> correct time?

That is not exactly correct. Listing a system as peer or server means that the 
time from that system will be used as input to the synchronization algorithm.  
The selection process may discard data depending on various criteria regardless 
of peer/server designation. The operations implications are the requirement for 
your own robust group of peers > 3 and lots of servers.

See 
• RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms 
Specification
• RFC 5906: Network Time Protocol Version 4: Autokey Specification
• RFC 5907: Definitions of Managed Objects for Network Time Protocol 
Version 4 (NTPv4)
• RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OpenNTPProject.org

2014-02-16 Thread James R Cutler

On Feb 16, 2014, at 10:03 PM, Kate Gerry  wrote:

> Just add these to your ntp.conf configuration then restart the service: 
> (Works with all default installations that I've found)
> 
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery

It might be useful to note that OS X has long since included these lines in the 
default NTP daemon configuration (/etc/ntp-restrict.conf) thus, “No worrys, 
mate."

James R. Cutler - james.cut...@consultant.com
PGP keys at http://pgp.mit.edu





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Need trusted NTP Sources

2014-02-09 Thread James R Cutler

On Feb 9, 2014, at 3:50 PM, Larry Sheldon  wrote:

> On 2/9/2014 2:45 PM, Jay Ashworth wrote:
> 
>> Or do I understand NTP less well than I think?
> 
> I am of the private opinion that if your name is not "David Mill" (and MAYBE 
> if it IS) the answer is either "42" or "yes".
> — ...

From http://www.eecis.udel.edu/~mills/database/brief/overview/overview.pdf
> Intersection and clustering algorithms pick best true chimers and discard 
> false tickers.
You should look at this presentation and see why Larry Sheldon’s private 
opinion is spot on.

I won’t begin to try explaining in technical detail how this works.  The bottom 
line is that, within a peer group of NTP servers looking at a reasonably large 
set of NTP source servers, all kinds of variations in input data are reduced to 
a coherent local time truth.

My template for NTP service deployment for any organization is very simple:

1. Select four or more local systems and configure them as peer NTP servers.  
In many instances one can leverage local DNS server machines running almost any 
OS — the NTP daemon runs on at least Windows, OS X, UNIX, Linux.  Don’t forget 
appropriate restrict commands.

2. Configure ntpd on the local servers to also select as servers a list of 8-10 
open access servers like pool.ntp.org, usno.navy.mil, nist--ustiming.org.  
If you can arrange authenticated access to other servers, that is possibly 
better.

3.  As desired, configure ntpd on selected local servers for local clocks or 
GPS clocks.  This has little effect on accuracy, but may enhance reliability.  
In many cases, it also requires building penetrations for antennas.  (Not easy 
for network guys.) 

4.  Configure all local time consumers to select from the list of local NTP 
servers.  Authenticate or not as you see fit. You can even use DHCP to inform 
end systems of NTP server addresses.  The router folks will have to include NTP 
server addresses as part of each configuration package.

Over the years I have successfully applied this template for NTP service 
deployments to several large networks. It just works.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

2013-12-31 Thread James R Cutler

On Dec 31, 2013, at 12:11 PM, Ryan Harden  wrote:

> On Dec 31, 2013, at 1:10 AM, Timothy Morizot  wrote:
> 
>> I've been in the process of rolling out IPv6 (again this night) across a
>> very large, highly conservative, and very bureaucratic enterprise. (Roughly
>> 100K employees. More than 600 distinct site. Yada. Yada.) I've had no
>> issues whatsoever implementing the IPv6 RA+DHCPv6 model alongside the IPv4
>> model. In fact, the IPv6 model has generally been much more straightforward
>> and easy to implement.
>> 
>> So I'm a large enterprise operator, not an ISP. Convince me. Because I
>> don't see any need. And if I don't, I'm hard-pressed to see why the IETF
>> would.
>> 
>> Scott
> 
> I haven't seen anyone in this thread argue that DHCPv6+RA doesn't work. So 
> we'd all expect that you'd do just fine deploying that way for your large 
> enterprise. The point is that there are some (And based on the thread here 
> and over at IPv6-OPS, not just a couple) operators who wish or are required 
> to do things differently. I remember thinking how stupid it was we had to 
> either statically configure or run DHCPv6 (which a lot of clients didn't 
> support) for the sole purpose of handing out name servers, then we finally 
> got around to RFC6106. There were lots of people who just couldn't understand 
> why you'd ever want your router handing out name servers/dns search lists. 
> Sure DHCPv6 was/is the 'right' and 'clean' way to do it, but it shouldn't be 
> required to make IPv6 functional. Clearly the IETF agreed, eventually.
> 
> IMO, being able to hand out gateway information based on $criteria via DHCPv6 
> is a logical feature to ask for. Anyone asking for that isn't trying to tell 
> you that RA is broken, that you're doing things wrong, or that their way of 
> thinking is more important that yours. They're asking for it because they 
> have a business need that would make their deployment of IPv6 easier. Which, 
> IMO, should be the goal of these discussions. How do we make it so deploying 
> IPv6 isn't a pain in the butt? No one is asking to change the world, they're 
> asking for the ability to manage their IPv6 systems the same way they do IPv4.
> 
> /Ryan

Please note that Ryan’s “manage their IPv6 systems” really means “run their 
business”.  In many organizations the routing network is managed by a different 
group with different business goals and procedures than end systems.  Allowing 
flexibility for this, if it is not overwhelmingly costly, is a reasonable goal.

On my part, I see adding a default route parameter to DHCPv6 about as earth 
shaking as adding a default NTP server list.  In other words, cut the crap and 
do it so we can save NANOG electrons and get on with solving more important 
network problems.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ISP port blocking practice

2009-10-23 Thread James R. Cutler

No, blocking a port does not restrict a customers use of the network  
any more than one way streets restrict access to downtown stores. It  
just forces certain traffic directions in a bicycle/motorcycle/car/van/ 
truck neutral manner. Carry anything you want.  Others laws restrict  
incendiary content.



On Oct 23, 2009, at 6:15 PM, Dan White wrote:


On 23/10/09 17:58 -0400, James R. Cutler wrote:
Blocking the well known port 25 does not block sending of mail. Or  
the

message content.


It does block incoming SMTP traffic on that well known port.

I think the relevant neutrality principle is that traffic is not  
blocked

by content.


My personal definition doesn't quite gel with that. You're deciding  
for the
customer how they can use their connection, before you have any  
evidence of

nefarious activity.

Would you consider restricting a customer's outgoing port 25 traffic  
to a

specific mail server a step over the net neutrality line?

--
Dan White


James R. Cutler
james.cut...@consultant.com

Re: ISP port blocking practice

2009-10-23 Thread James R. Cutler

Blocking the well known port 25 does not block sending of mail. Or the  
message content.


Blocking various well know M$ protocol ports does not block remote  
file access. Or control the type of files that can be accessed.


I think the relevant neutrality principle is that traffic is not  
blocked by content.


So, no, blocking any port is NOT against the idea of Net Neutrality.

On Oct 23, 2009, at 5:19 PM, Lee Riemer wrote:


Isn't blocking any port against the idea of Net Neutrality?




James R. Cutler
james.cut...@consultant.com

Re: IPv6 Deployment for the LAN

2009-10-22 Thread James R. Cutler



On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:


В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:


OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in
a dynamic host configuration mechanism to
assign a number of parameters to the hosts they administer through
that dynamic configuration mechanism.  These
parameters include, but, are not limited to:

1.  Default Router
2.  DNS Resolver information
3.  Host can provide name to server so server can supply dynamic DNS
update
	4.	IP Address(es) (v4, v6, possibly multiple v6 in the case of  
things

like Shim6, etc.)
5.  NTP servers
6.  Boot server
7.  Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the  
router

because the router is outside of the
administrative control of the Systems Administrator responsible for
the hosts being configured.




And to add a real-world case for this - two months ago at HAR (hacking
at random, a convention in the Netherlands) I was in the network team,
handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and  
at
some point we asked the question around - ok, how should we provide  
DNS

and other useful information for the V6 only people?

After a while with all the brains around, the decision was to write it
on the datenklos through the field, where people can read it and
configure it in their browsers. This would've been funny if it  
wasn't so

sad.

OTOH, for V4 everything with the DHCP worked fine (as it has always
done, even at an event of this size), as is my experience with all the
networks I've administered. Saying that DHCP doesn't work for me is
extremely weird, as to me this means someone made specific effort to
fuck it up.

Finally - we have something that works, that's called DHCP. It might  
not

be perfect, it might have some weird issues and implementations, but
it's actually making our lives easier, is tested and works. I'd love
anything that would be better, but as an option, not as the only  
choice

I have.
And it's not just the protocol that I care about. I care about that  
it's

implemented in a HOST, where I can play with the software as much as
possible, instead on a ROUTER, which is a vastly different device with
rarely-updated OS, and even in the case where they're both the same
machine(as in small office environments), they're again handled at
different layers (kernel vs userspace).
There are reasons that we're using what we're using, and not all of  
them

are "because we're masochistic idiots".


--
Regards,
Vasil Kolev


Following on the comments above:

The security domain for HOST should not overlap the security domain  
for ROUTER.


That is the primary driver of the separate administration of HOST and  
ROUTER. Heaven help us if the latest M$ virus, or even social- 
engineering distributed malware began to affect BGP!


Give the router managers the NTP server addresses and their DHCP  
forwarding list and leave them alone to produce a robust and reliable  
transport facility!


James R. Cutler
james.cut...@consultant.com

[DHCPv6] was Re: IPv6 Deployment for the LAN

2009-10-21 Thread James R. Cutler

We have networks and businesses to run. Why are we rehashing this yet  
again?


For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html 
 shows messages regarding exactly this issue. for emphasis I  
redundantly requote, "You have seen this before from me: Consider the  
Customer/Business Management viewpoint, not just that of routing  
packets around between boxes. Pull your head out of your patch panel  
and look at all the business requirements. If you can show me a more  
cost effective way to distribute all the parameters mentioned here to  
all end systems, I'll support it. In the meantime, don't use religious  
arguments to prevent me from using whatever is appropriate to manage  
my business. I'll even use NAT boxes, if there is no equivalently  
affordable stateful firewall box!"


Just in case the URL is faulty, here is the primary content of the  
referenced page of NANOG list history:


And, besides the list forwarded below,
Designated printers,
Preferred DNS Servers,
and, maybe, more.

Even in a large enterprise, the ratio of "routers" to DHCP servers  
makes control of many end system parameters via DHCP a management win  
compared to configuration of "routers" with this "non-network core"  
data. (In case I was to abstruse, It is cheaper to maintain end system  
parameters in a smaller number of DHCP servers than in a larger number  
of "routers".)


This is completely separate from the fact that many experienced router  
engineers are smart enough configure routers with NTP server
addresses in preference to DNS names, and likewise for many other  
parameters.


The end system population has requirements which respond much more  
dynamically to business requirements than do router configurations,  
which respond mostly to wiring configurations which are, by  
comparison, static. The statement that DHCP is not needed for IPv6  
packet routing may well be exactly accurate. The absence of good DHCP  
support in IPv6 has costly consequences for enterprise management, of  
which IP routing is a small part.


You have seen this before from me: Consider the Customer/Business  
Management viewpoint, not just that of routing packets around between  
boxes. Pull your head out of your patch panel and look at all the  
business requirements. If you can show me a more cost effective way to  
distribute all the parameters mentioned here to all end systems, I'll  
support it. In the meantime, don't use religious arguments to prevent  
me from using whatever is appropriate to manage my business. I'll even  
use NAT boxes, if there is no equivalently affordable stateful  
firewall box!


Cutler

Begin forwarded message:

From: Leo Bicknell 
Date: December 27, 2007 7:33:08 PM EST
To: North American Network Operators Group 
Subject: Re: v6 subnet size for DSL & leased line customers

In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100,  
Iljitsch van Beijnum wrote:

It is wih IPv6: you just connect the ethernet cable and the RAs take
care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_.
If you need extreme control then manual configuration will give you
that, which may be appropriate in some cases, such as servers.

Really. I didn't know RA's could:

- Configure NTP servers for me.
- Tell me where to netboot from.
- Enter dynamic DNS entries in the DNS tree for me.
- Tell me my domain name.
- Tell me the VLAN to use for IP Telephony.

Those are things I use on a regular basis I'd really rather not
manually configure.

--
   Leo Bicknell - bickn...@xxx - CCIE 3440
    PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-requ...@, www.tmbg.org


James R. Cutler
james.cut...@consultant.com

Re: ISP customer assignments - and CIDR

2009-10-16 Thread James R. Cutler



On Oct 16, 2009, at 5:19 PM, Owen DeLong wrote:

I've taught both.  If you try to teach it in Decimal, Hex, or Octal,  
you're right, it's hard

to teach CIDR and easy to teach classful.


It really does not matter the representation as long as you divide  
your Address Pie with a Binary Knife.  Once you understand that --  
1/2, 1/2 of 1/2, 1/2 of 1/2 of 1/2, ... -- then you should understand  
CIDR.  Then, as Owen suggests, deal with the representation. Works for  
IPv4, IPv6, and, probably, IPv8. ;)


Warning, strong opinion follows: One should never have to mention  
Classful addressing except to note that it is archaic, anachronistic,  
and used only by those who remain ignorant by preference.




James R. Cutler
james.cut...@consultant.com

Re: Dan Kaminsky

2009-08-05 Thread James R. Cutler


(2) Saying "type our name into $SERVICE", where $SERVICE is some
popular website that most people trust (like Facebook or whatever),
and has come up with a workable system for disambiguation.



I can only hope that those who believe in "disambiguation" of mailing  
addresses, electronic or otherwise, will be sorely disappointed.  
Return to sender is the only safe course. [No, I am not an architect,  
regardless of what Google says.]  And, I really want whitehouse.gov,  
not whitehouse.com, even though you could only guess my reason.


The design intent of the DNS namespace and structure is to provide  
unambiguous location of domain name related data. The implementation  
of that structure and lookup mechanisms may be flawed, but we should  
fix the flaws, not discard the namespace.


This discussion has wandered widely. Perhaps we should revert to  
discussing how to operate our networks to provide secure connectivity,  
including secure determination of connection targets.



James R. Cutler
james.cut...@consultant.com

Re: Redundant AS's

2009-03-20 Thread James R. Cutler

What this quote means is that it is 65536 times more cost-effective to  
deploy 4 byte ASN than to mess with legacy assignments.



On Mar 20, 2009, at 12:50 PM, Heather Schiller wrote:

I tend to agree w/ Randy.. it's time and money better spent focusing  
our efforts on supporting 4byte ASN (and v6 for that matter)   
Attempts at recovering 2byte ASN's (and v4 space..) are short term  
solutions, at best extend the 'free pool' for a short and  
unpredictable period of time, while incurring more headache,  
expense, and arguing, than working toward supporting the inevitable.


James R. Cutler
james.cut...@consultant.com

Re: v6 & DSL / Cable modems

2009-02-06 Thread James R. Cutler

DHCP items are end system considerations, not routing network  
considerations.


The network operations staff and router configuration engineers do not  
generally concern themselves with end systems.


End systems generally are managed quite independently from the routing  
network. And, they are more subject to the vagaries of day to day  
business variability. Note the "one place" in the quoted message below.


The only overlap is broadcast forwarding for DHCP initiation.

Besides, configuration control is hard enough for router engineers  
without adding the burden of changing end system requirements.  Adding  
the forwarding entries is almost too much already! ;)


So, for routing network operators to denigrate DHCP is probably due to  
lack of consideration of the end user system requirements.  And those  
who denigrate DHCP and say "just hard code it" make end system  
management that much more difficult.


I still conclude that DHCP is a useful tool for both IPv4 and IPv6  
systems.


Cutler

On Feb 6, 2009, at 12:22 PM, sth...@nethelp.no wrote:


The problem is that DHCP seemed like a good idea at the time but it
doesn't make any sense today. We know that parsing complex binary  
data

formats is asking for security problems.


And parsing complex text data structures is better?


What we need is a simple, fast, efficient way to distribute the basic
information that a host needs to start sending and receiving packets
and a pointer to a place where additional location dependent
configuration information can be found. That would be: address 
+prefix,

gateway and (arguably) DNS and then something like a URL for a server
that has the config info. The system and applications can then load
information from the config server over HTTP in XML format or some  
such.


No, this information must be available in *one* place. It's called a
DHCP server. As an operator, this is clearly what I want, both for  
IPv4

and IPv6.

Steinar Haug, Nethelp consulting, sth...@nethelp.no



James R. Cutler
james.cut...@consultant.com

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]

2009-02-05 Thread James R. Cutler



On Feb 5, 2009, at 5:42 PM, Iljitsch van Beijnum wrote:

...An IPv4 DHCP server gives me five things: ...DNS addresses and a  
domain...


==

Actually, lots more than five.  E.g., NTP servers, preferred WINS  
servers (sorry, AD servers) and many other interesting (to some)  
items. And, the DNS domain my laptop joins depends on the network  
where it is connected in accordance with business policies in effect.   
Thus, DHCPv6 is of great interest for portable systems.


I have previously noted that many clever technicians are well versed  
in what we do not need - without considering all the business  
management requirements that end user systems must meet. They are all  
correct, but not right.


James R. Cutler
james.cut...@consultant.com

Re: Private use of non-RFC1918 IP space

2009-02-04 Thread James R. Cutler


Clarification here:

1/8 was never on the EDS backbone.  Was only used locally in one site,  
as far as I can determine.


On Feb 4, 2009, at 7:29 PM, Randy Bush wrote:

I see you've never done business with EDS.  They've been using 1/8  
for
over a decade.  Also, over the years, I've seen a number of  
universities
and supercomputing facilities number nodes out of 1/8 -- however,  
those

systems are never supposed to see the internet anyway, so they could
technically number them however they want.  Personally, I've used  
1/8 in

lab setups.


brilliant!  i think all my competitors should do that.

randy



James R. Cutler
james.cut...@consultant.com

Re: Possible explanations for a large hop in latency

2008-06-26 Thread James R. Cutler


Deep Packet Inspection engine delay. 


On Jun 26, 2008, at 6:51 PM, Frank Bulk wrote:


Our upstream provider has a connection to AT&T (12.88.71.13) where I
relatively consistently measure with a RTT of 15 msec, but the next  
hop
(12.122.112.22) comes in with a RTT of 85 msec.  Unless AT&T is  
sending that
traffic over a cable modem or to Europe and back, I can't see a  
reason why
there is a consistent ~70 msec jump in RTT.  Hops farther along the  
route
are just a few msec more each hop, so it doesn't appear that  
12.122.112.22

has some kind of ICMP rate-limiting.

Is this a real performance issue, or is there some logical  
explanation?


Frank




James R. Cutler
[EMAIL PROTECTED]

Re: [Nanog-futures] Announce list: Re: Hughes Network

2008-05-22 Thread James R. Cutler

The announcement was made to nanog-announce, but not to nanog. I would  
expect that there are scads more readers of nanog than of nanog  
announce.


For some, that could cause unexpected results, especially with the 24  
hour notice.


Corroborative detail below. (Oops, top posting)

Regards.

On May 22, 2008, at 10:45 PM, Jim Popovitch wrote:


On Thu, May 22, 2008 at 9:35 PM, someone wrote:

Add me to the list of never-saw-that. In addition, I just checked the
nanog archives, and there isn't an announcement of that type in the
archives.


Below is the full email, with headers, from Monday.  Hopefully it will
put this issue to rest but somehow I doubt that. ;-)

-Jim P.

MIME-Version: 1.0
To: [EMAIL PROTECTED]
X-Enigmail-Version: 0.95.6
Authentication-Results: hkg-dkim-1; [EMAIL PROTECTED];  
dkim=pass (


philip
(for the SC)
--


___
NANOG-announce mailing list
[EMAIL PROTECTED]
http://mailman.nanog.org/mailman/listinfo/nanog-announce



James R. Cutler
[EMAIL PROTECTED]

Re: [NANOG] fair warning: less than 1000 days left to IPv4 exhaustion

2008-05-02 Thread James R. Cutler

Yes -- spent mostly on getting management approval.

On May 2, 2008, at 5:53 PM, Deepak Jain wrote:

>> Does it take most network operators more than 1000 days to make an  
>> IPv6
> plan and start implementing it?

___
NANOG mailing list
NANOG@nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog

Re: potential hazards of Protect-America act

2008-01-29 Thread James R. Cutler



Well, it could affect the equipment required, floor space, real  
estate cost, log retention, bandwidth requirements, equipment  
addressing, procedures, training, trouble desk, employee count and,  
probably, more.  So, I would think it would affect network  
operations. I would suggest that it is on topic. There are business  
and legal hazards along with the technical hazards.  Compliance with  
differing data privacy and retention laws are not the least of these.



On Jan 29, 2008, at 3:46 PM, <[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]> wrote:





I wonder if this is on topic?

<http://www.crypto.com/papers/paa-ieee.pdf>

Among other things, it discusses technical hazards of the act.


--Michael Dillon


James R. Cutler
[EMAIL PROTECTED]

85 matches

Mail list logo