On 03/10/2019 15:51, Stephen Satchell wrote:

For a start, *add* IPv6 examples in parallel with the IPv4 examples.

1000 times +1 We need (much) more IPv6 examples! -- Marco (pushing for IPv6 examples since 2007 or so like in: https://youtu.be/OLEizGPoB5w?t=30)

On 10/3/19 2:07 PM, Mark Andrews wrote:

Now IPv6 examples are nice but getting several 1000’s people to read draft that just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, 12.0.0.0/8 and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly is a waste of time.

Long ago, I was working on Network Graphics Protocol and the draft RFC for it. My boss said that I needed to write a couple of paragraphs about fixed-point binary fractions, which the protocol used, "because that's not a common thing in the world". How bad was this? The person who was writing the generator of the NGP stream used *floating point* because that person didn't understand that 7FFFFFFF was interpreted as a bitty-point less than 1.0, and 80000001 was a bitty-point less that -1.0 -- and that trying to shoehorn this into IEEE floating-point format almost worked. What my poor boss didn't realize is that exactly 1.0 and -1.0 were not defined. The specification didn't make that clear. When I'm doing technical writing, I find all sorts of corner cases that were missed by the designers and the QA people. It makes me very unpopular. But it also makes for a better product, in the end. So making everything crystal clear and obvious is definitely not "a waste of time." You have no idea what undiscovered bugs may become obvious when you go through the exercise and show all your work. You still need a IPv6 version of RFC 1812. Make it as clean as possible. Use an ax instead of a XACTO knife on the current draft. What is the minimum necessary things that a generic IPv6 router MUST do?

On Fri, 04 Oct 2019 08:20:22 +0900, Masataka Ohta said:

As for requirements for IPv6 routers, how do you think about the following requirement by rfc4443?

44443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443)

rfc1812 says:

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) I suppose you never considered that in the 11 years intervening, we decided that maybe things should be done differently.

IPv6 specification is fatally broken in various ways.

Oddly enough, it doesn't seem to be fatally broken from where I am, or from where Google is, or from where Facebook is, or from where most of the cellphone companies are. You must have a different definition of "fatally broken" than the rest of us.

On Oct 3, 2019, at 3:15 PM, Stephen Satchell <list@satchell.net> wrote:

You still need a IPv6 version of RFC 1812.

If we were to start with the current draft, I would probably want to start over, and have people involved from multiple operators. That said, let me give you some background on RFC 1812. The development started a little after a largish group of people started on what eventually became RFCs 1122 and 1123. The point was that there were a number of RFCs that needed to be updated with hard-earned wisdom - how ARP should work and so on. The group decided that instead of reissuing each individual RFC, they should do one omnibus effort. 1812 similarly covered a lot of "we discovered that this was true or needed to become true". The first editors was Philip Almquist, and it passed through several subsequent pairs of hands. It then sat on a shelf for several years, with people saying "we really should publish that" and not doing so. In 1994, the CIDR change was in full swing, and I was changing employers. Marshall Rose contacted me asking me to take it over, edit CIDR into it and "do whatever else was needed", and publish the thing. My new boss agreed to lt me do so, and I did. I was given the text in RFC 1716 as input, which was then published as "historic", and RFC 1812 was the end product. RFC 1812 is kind of long in the tooth, BTW. Since then, the way the IETF updates documents with hard-earned wisdom has changed. We don't do omnibus documents like RFC 1122/1123 and 1812; we write a document - or 20 of them - that "update" the document in question. You can find that information in the rfc-index.txt file, and in the datatracker. So if there were updates to include corresponding to those RFCs and on IPv6, I think the IETF would tell you to look at RFC 8200. There is one thing in 1122/1123 and 1812 that is not in those kinds of documents that I miss; that is essentially "why". Going through 1122/1123 and 1812, you'll ind several sections that say "we require X", and follow that with a "discussion" section that says "we thought about X, Y, and Z, there were proponents of each, the arguments were X', Y', and Z', and we chose X for this reason". I would presume that what you're really looking for in a 1812-for-IPv6 is not "we require X" as much as "for this reason". Correct me if I'm wrong. I can kick the idea around in the IETF if its important to you. I'll be looking for a LOT of operational input.

Look at CableLabs specifications. There is also RFC 7084, Basic Requirements for IPv6 Customer Edge Routers which CableLabs reference. Also RFC 8585, Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service Mark

On 5 Oct 2019, at 12:00 am, Stephen Satchell <list@satchell.net> wrote:

On 10/3/19 10:13 PM, Fred Baker wrote:

...

There is one thing in 1122/1123 and 1812 that is not in those kinds of documents that I miss; that is essentially "why". Going through 1122/1123 and 1812, you'll ind several sections that say "we require X", and follow that with a "discussion" section that says "we thought about X, Y, and Z, there were proponents of each, the arguments were X', Y', and Z', and we chose X for this reason". I would presume that what you're really looking for in a 1812-for-IPv6 is not "we require X" as much as "for this reason". Correct me if I'm wrong.

Ah. What I'm looking for is a list of check-boxes to include in an implementation specification for an edge router. It can be references to a whole bunch of RFCs and "packaged" as a BCP. The discussions you describe are better in the individual papers.

Side note: I'm used to rationales being included in Standards, and welcome them, as long as they are normative and clearly marked so.

...

I can kick the idea around in the IETF if its important to you. I'll be looking for a LOT of operational input.

It could well me that the data is there, we just need a document to index it all. That's what I thought a BPC was supposed to be. It would be like an article in ACM Computing Surveys, which references the existing literature, as opposed to being created from whole cloth.

I think I steered everyone wrong when I was talking about some of the exposition in the text, specifically the examples. That kind of material really belongs in an RFC. My apologies.

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Sat, 05 Oct 2019 07:01:58 +0900, Masataka Ohta said:

One of a stupidity, among many, of IPv6 is that it assumes links have millions or billions of mostly immobile hosts

Can somebody hand me a match? There's a straw man argument that needs to be set afire here.

On Oct 3, 2019, at 9:51 AM, Stephen Satchell <list@satchell.net> wrote:

It appears that the only parallel paper for IPv6 is draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which currently carries a copyright of 2018. It's a shame that this document is still in limbo; witness this quote: "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.'

Speaking as v6ops chair and the editor of record for 1812. draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be an 1812-like document and adopted as such, but many of the "requirements" that came out of it were specific to the author's operation and not common to other operators. So it ultimately didn't happen.

Someone else mentioned that "IPv6 has been around for 25 years, and why is it taking so long for everyone to adopt it?" I present as evidence the lack of a formally-released requirements RFC for IPv6. It suggests that the "science" of IPv6 is not "settled" yet. That puts the deployment of IPv6 in the category of "experiment" and not "production".

Is that really true?

That's a long story. The IETF realized it needed a next generation protocol in 1990; that's where NATs came from, the successive efforts to recover unused IPv4 space, and research into possible next generation protocols. IPv6 was proposed in 1993-1994, originally published in 1996 as RFC 1883, and republished in 1998 as RFC 2460. It was recently re-re-published as RFC 8200. Supporting work was required in DHCP, DNS, and several routing protocols; that happened over time. ICANN didn't adopt a policy for the allocation of IPv6 address space to RIRs until 2006, and in 2007 there were a number of allocations from IANA to the RIRs and from some of the RIRs to operators in various parts of the world. Testing was also important - primarily done by the NRENs. That wound up with comments going back to various vendors. I was employed by one of them, but will refrain from giving "insider" comments. Suffice it to say that there were multiple vendor implementations, mostly incomplete in one way or another. IANA allocated the last five IPv4 /8s to the RIRs in 2011, and since then the IPv4 address market has been mopping up the slop. Per https://ipv4marketgroup.com/ipv4-pricing/ (if addresses were real estate, ipv4marketgroup would be a real estate agent), the price of an address was stable at or near $10/address from several years, and in 2016-2018 shot to about $18/address. They expect the price to start to fall in the next year or so, as CIOs figure out that its a waste of money. There is no demand until further IPv4 deployment no longer suffices. I would say that there was no real market demand until after January 2011, and probably 2012 or 2013. At this point, there is fairly wide deployment among the ISP and CDN operators, and vendor implementations are fairly complete. Google, APNIC, and Akamai report on traffic levels; Google says that they see at least 5% of the requests they receive from 61 countries use IPv6, and from one country a tad more that half of the requests they receive use IPv6. https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=be,yt,de,gr,my,vn,in,gf,us,uy,fr,tw,jp,lu,ch,mx,br,pt,fi,mq,ax,th,ee,re,hu,gb,ca,gp,tt,ie,lk,nz,au,pe,ec,nl,ae,ro,ga,bo,sa,sx,cz,no,si,sg,pl,gt,at,mo,ar,mm,kr,fo,om,lv,zw,pr,ke,tg,ba. And interesting point in those reports is that Google and Akamai are CDNs, which means that (for the most part) a request goes almost directly from a user's broadband interface to the service in question. APNIC is different in that it operates no CDN; requests they receive cross the backbone, and therefore also measure backbone deployment. To that matter, let me list the APNIC charts of the top ten: https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=BE https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=YT https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=DE https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=GR https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=MY https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=VN https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=GF https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=US https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=UY In each of those, APNIC measures and reports a distinction between a requestor being "IPv6 Capable" and "Preferring IPv6". This is done using a google ad that includes three one-pixel links; one of the names has only an A record, one has only a AAAA record, and one bas both. If the requestor uses the first two links and APNIC receives the SYN, then the end system and every AS en route used and provided an IPv4 or IPv6 capability respectively. In the third case, the end system presumably gets both an IPv4 and an IPv6 address, and makes a choice. If it chooses IPv6, it is reported as preferring IPv6. If you select the links above, you will find that end systems (telephones, laptops, whatever) will generally prefer IPv6 if given the option. Also interesting on those pages, APNIC lists the ASNs serving the indicated country, and separates requests by ASN. For example, in India (https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN), APNIC reports on 100 different ASNs, of which half demonstrate non-trivial IPv6 traffic, and (I think) 20 demonstrate more than 10%. A celebrated one among them is Reliance JIO; https://stats.labs.apnic.net/ipv6/AS55836?c=IN&p=1&v=1&w=30&x=1. You might look at that chart, as it breaks out Reliance JIO and "rest of country". Reliance was a new operator in 2011, and as I understand the story got a small allocation from APNIC (in accordance with its policies) and went to the market to purchase IPv4 address space. They recognized the expense of that approach in perhaps 2015, and started IPv6 deployment. At that time, they were probably the only, or at least the principal, operator using IPv6 AT ALL in that country. What the data shows is that other operators - half of those in India - have since then followed suit, probably due in part to competitive pressure. So we see IPv6 in broadband, in ISPs, and in telephone networks. To give you an anecdote, my kids have teased me about IPv6 for years, and each now have IPv6 service from their various ISPs and telephone networks despite themselves - and use it for the majority of their accesses. What is visibly lacking is enterprise deployment. There are companies that have it, but they are unusual; those that are visible in routing usually have it for their outward-facing services such as mail and web, but not internally. To be very honest, some of that leaves me cross-eyed. A recent example I was asked to give advice on - name consciously left out - was a country that wanted to deploy an NREN that would enable certain services to some 5000 secondary and university-level schools. If they deployed it using IPv4, simply buying the addresses would have cost them $25M; equipment and personnel are not included in that expense. From their RIR, getting the smallest allocation the RIRs give to an ISP - an IPv6 /32 - would cost $2100/month., and would give them allocations for 65535 such end sites. So they have a choice: $25M up front, or $2100/month. Hmm, that's a hard one... MIT recently sold half of their IPv4 address space - 1 /9 out of a /8 - to Amazon, and stated in a blog that they planned to use the proceeds for their IPv6 deployment. A company that I am on the board of independently from me decided to sell half of its legacy /16, and use the proceeds for internal projects. If I were an enterprise CIO, I would see that address space as banked money, and want to access it. I'm obviously clueless - that's not happening. And on lists like this, I am told that there is no deployment - that nobody wants it, and anyone that disagrees with that assessment has lost his or her mind. That all leaves me wondering which of us doesn't quite have their eye on the ball.

On Oct 3, 2019, at 12:30 PM, Stephen Satchell <list@satchell.net> wrote:

On 10/3/19 8:22 AM, Fred Baker wrote:

...

And on lists like this, I am told that there is no deployment - that nobody wants it, and anyone that disagrees with that assessment has lost his or her mind. That all leaves me wondering which of us doesn't quite have their eye on the ball. For the reasons you provided in your original message, the learning curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" -- is steep and uncertain.

And I think you may be misunderstanding the problem. It's not that people don't want it. They lack the zen of it, they don't see the four corners of the thing, something that people took years to learn in IPv4. (I had a leg up, being involved in the original ARPAnet, so I got to watch it grow. Still have the 1984 DDN handbooks, too.)

Funny thing. I was quoting the email in this thread just prior to yours. I won’t say there are no issues in IPv6 deployment; there are. However, having done some myself, if you have IPv4-zen, IPv6-zen is pretty easy to come by with a cheat sheet. For example, does your configuration have statements like IP address 192.0.2.1 255.255.255.0 ? Everywhere you find that, you add a statement like ipv6 address 2001:db8:AABB:1234::/64 eui-64 What I did for the IID (IPv4-speak: “host part”) in a recent project was use the IPv4 address of the interface: IP address 192.0.2.1 255.255.255.0 IPv6 address 2001:db8:aabb:1234:192:0:2:1::/128 The idea was to give the operator a clue. I also put the VLAN number in as the subnet number. A security geek would be all over me - “too many clues!”. That said, I found that by typing “IPv6 address command” into google; the first hit was https://study-ccna.com/how-to-configure-ipv6/. Then, noting that Cisco has a bad habit of pulling things out of there air even though there is a defined way to accomplish it, I corrected the prefix to use the defined documentation prefix. It gets a little interesting when you step away from the switch or router to the firewall; they have their own commands. The ASA, for example, really believes in what Cisco calls “zone-based access control” or “context-based access control”. The good news is that if that’s what you’re trying to achieve (it’s common), configuring that for IPv6 is pretty simple. And similarly, BGP and access lists look a lot like their IPv4 counterparts. What’s a little more of a pain is that if you are using other appliance in your network, they may or may not have IPv6 configurability, and there may or may not be a drop-in replacement. That becomes a conversation with your vendors of choice.

On Thu, 03 Oct 2019 15:28:30 -0600, "Keith Medcalf" said:

On Thursday, 3 October, 2019 11:50, Fred Baker <fredbaker.ietf@gmail.com> wrote:

...

A security geek would be all over me - "too many clues!".

Anyone who says something like that is not a "security geek". They are a "security poser", interested primarily in "security by obscurity" and "security theatre", and have no clue what they are talking about.

Amen to that. If you've been pwned hard enough that vlan numbers are useful to the attacker, the fact the attacker knows your vlan numbers is the *least* of your problems....

On Friday, 4 October, 2019 16:05, William Herrin <bill@herrin.us> wrote:

On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf <kmedcalf@dessus.com> wrote:

...

On Thursday, 3 October, 2019 11:50, Fred Baker <fredbaker.ietf@gmail.com> wrote:

...

...

A security geek would be all over me - "too many clues!".

...

Anyone who says something like that is not a "security geek". They are a "security poser", interested primarily in "security by obscurity" and "security theatre", and have no clue what they are talking about.

It's called "operations security" or "OPSEC." The idea is that from lots of pieces of insignificant information, an adversary can derive or infer more important information you'd like to deny to him. There's a 5-step process used by the U.S. Military but the TL;DR version is: if you don't have to reveal something, don't.

You and I have completely different opinions of how security works. In my world, security must continue to be effective even in the face of an adversary that knows everything there is to know about what is being attacked (except for some authentication secrets, which of course need to be kept secret). If the attacker does not already have that information, then obtaining it is usually a rather trivial reconnaissance operation. The job of "securing" something means to make it impervious to outside influence -- it is the other side of the "safety" coin -- and Safety and Security go hand in hand. Security based on keeping something which is trivial to discover secret is trivial security and can still be trivially bypassed. It is telling that of the thousands of "ransomware attacks" that occur each second, only 617 have been successful so far this year. Those victims probably relied on keeping something secret that did not matter. In other words, they expended effort on the wrong things -- their analysis of risk was inherently flawed. Can you provide a scenario in which knowledge of the VLAN number is a vulnerability that can be exploited? And if you can find one, is there a more effective way to prevent that exploit that will work even if the attacker knows the VLAN number? Would it not be more effective to implement that measure than simply using trivial means (that are trivial to defeat) to hide the VLAN number? This does not mean that you need to publish the VLAN numbers on Facebook for all to see, merely that knowledge of that fact is now irrelevant, and that even if the someone posted the VLAN numbers on Facebook for all to see, then that would not be helpful to the adversary.

IMO, anyone who thinks the folks who developed OPSEC don't have a clue is the one I find wanting.

Opinions vary. That is the nature of opinion. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote:

You've ignored step 1 - identifying critical information that needs protecting. It makes sense to protect information that needs protecting and don't lose sleep over information that doesn't need protecting. Not many of us are planning an invasion of a Nazi-infected Europe any time soon.

We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, the latter of which can be paraphrased as "design systems assuming that your adversary will know as much about them as you do". Not that I'm advocating publishing all internal design documents, but systems whose security is predicated on the secrecy of those are brittle and likely to be badly compromised. Better to assume that enemies know or can find out everything and design/build accordingly. ---rsk

Not everyone attacking your systems is going to have the skills or knowledge to get in though - simple tricks (like hiding what web server you use) can prevent casual attacks from script kiddies and others who aren't committed to targeting you, freeing your security teams to focus on the serious threats.

And this is based on what evidence? It also defies logic. By definition script-kiddies run scripts. If you remove the identification those scripts can no longer identify what is running, and therefore will continue to attack it. What would be useful is to replace that with alternative "disinformation" headers so that the script-kiddies scripts will get a positive result, but that result will not be what they are looking for, so they will go away. Until having disinformation headers gets the same "old wives tale" status as "remove the identifying headers". At which point either course of either action is a waste of effort and $$$ because the script-kiddies will just ignore it as it will be just as cost effective to run the exploit and see what happens. In other words, simple tricks are exactly that. They usually do exactly the opposite of what the "simple tricker" thought they were doing, or do nothing useful at all. Which means that effort and $$$ have been expended at best on a useless endeavour, and at worst one which increased the very activity it was designed to thwart. One would have been far better off putting the $$$ in the slush-fund and using it when some particularly persistent script-kiddie showed up so you could afford to add a filter to the firewall. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

On Tue, Oct 8, 2019 at 6:51 AM Rich Kulawiec <rsk@gsp.org> wrote:

On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote:

...

You've ignored step 1 - identifying critical information that needs protecting. It makes sense to protect information that needs protecting and don't lose sleep over information that doesn't need protecting. Not many of us are planning an invasion of a Nazi-infected Europe any time soon.

We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, the latter of which can be paraphrased as "design systems assuming that your adversary will know as much about them as you do".

They aren't mutually exclusive concepts. A strong security architecture has multiple layers an adversary must penetrate. No layer has to be sufficient on its own, it just has to reduce vulnerability more than it increases cost. Limiting the server banner so it doesn't tell an adversary the exact OS-specific binary you're using has a near-zero cost and forces an adversary to expend more effort searching for a vulnerability. It doesn't magically protect you from hacking on its own. As you say, your security must not be breached just because the adversary figures out what version you're running. But viewed as one layer in an overall plan, limiting that information enhances your security at negligible cost. That's security smart. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

Any additional effort put in by an attacker will increase the chance of an attack being detected before it is successful. COnsider the following two scenerios. Scenerio 1 is a webserver that makes no effort to obfuscate: 1. Attacker does HEAD request on /, which is a legitmate request, and sees the webserver vendor name 2. Attacker does a quick search, and finds there is a vulnerabilty in webserver 3. Attacker exploits vulnerability Now, consider scenerio 2, where the server is configured to hide the webserver vendor and has an IDS/IPS system in place 1. Attacker does HEAD request on /, which is a legitmate request, but there is no usable information in the respone. 2. Attacker does a probe on the webserver to try a number of attacks, which generate a number of 403, 404, 500 etc errors in the webserver logs 3. IDS/IPS sees the sudden spike in errors from a single IP address and blocks the source IP The act of obfuscation made it possible for the IDS/IPS to detect the probe, preventing the attack. WIll this block every attack? Probably not, but it increases the effectiveness of the security by forcing the attacker to take additional (detectable) actions when trying to break in. The lock on your front door can be picked by anyone with a $10 lockpick set in under 5 minutes, does that mean you shouldn't bother locking your doors? Mark ________________________________ From: NANOG <nanog-bounces+mark.collins=mariestopes.org@nanog.org> on behalf of Keith Medcalf <kmedcalf@dessus.com> Sent: 08 October 2019 18:53 To: nanog@nanog.org <nanog@nanog.org> Subject: RE: Update to BCP-38? On Tuesday, 8 October, 2019 11:03, William Herrin <bill@herrin.us> wrote:

Limiting the server banner so it doesn't tell an adversary the exact OS- specific binary you're using has a near-zero cost and forces an adversary to expend more effort searching for a vulnerability. It doesn't magically protect you from hacking on its own. As you say, your security must not be breached just because the adversary figures out what version you're running. But viewed as one layer in an overall plan, limiting that information enhances your security at negligible cost. That's security smart.

I think your analysis is incorrect. There are two cases which are relevant: (1) The attack is non-targetted (that is, it is opportunistic) (2) The attack is targetted at you specifically. In the former (1) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. The script either works or it does not. Even if the "banner" says "Beyond this point there be monsters" will make absolutely not one whit of difference. In the latter (2) case, it does not matter whether the "banner" identifies the specific OS binary or not as it is irrelevant. You have been targetted. All possible exploits will be attempted until success is achieved or the vat of exploits to try runs dry. So while the cost of doing the thing may be near-zero, it is not zero. All those near-zero cost things you do that have no actual advantage can add up to quite a huge total and it will be more advantageous to spend that somewhere where it will, in fact, make a difference. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. This Email from Marie Stopes International and any attachments may contain information which is privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient(s) of this Email or any part of it please notify the sender immediately on receipt and delete it from your system. Any opinion or other information in this email or its attachments that does not relate to the business of Marie Stopes International is personal to the sender and is not given or endorsed by Marie Stopes International.

On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said:

So while the cost of doing the thing may be near-zero, it is not zero.

And in fact, there's more than just the costs of doing it. There's also the costs of having done it. Obfuscating your OpenSSH versions is a *really* good way to make your security scanners that flag backleveled systems fail to flag the systems. Which can cause a really uncomfortable conversation with the CIO about why the local newspaper's front page is running a story about how your organization got totally pwned via a backleveled OpenSSH on one cluster of 5 servers.....

On Oct 3, 2019, at 9:51 AM, Stephen Satchell <list@satchell.net> wrote:

Someone else mentioned that "IPv6 has been around for 25 years, and why is it taking so long for everyone to adopt it?" I present as evidence the lack of a formally-released requirements RFC for IPv6. It suggests that the "science" of IPv6 is not "settled" yet. That puts the deployment of IPv6 in the category of "experiment" and not "production".

And, of course, we now have companies like T-Mobile and others turning IPv4 off. If that's an experiment, wow.

Sent from my iPad

On Oct 3, 2019, at 12:14 PM, Stephen Satchell <list@satchell.net> wrote:

On 10/3/19 8:42 AM, Fred Baker wrote:

...

...

...

On Oct 3, 2019, at 9:51 AM, Stephen Satchell <list@satchell.net> wrote:

Someone else mentioned that "IPv6 has been around for 25 years, and why is it taking so long for everyone to adopt it?" I present as evidence the lack of a formally-released requirements RFC for IPv6. It suggests that the "science" of IPv6 is not "settled" yet. That puts the deployment of IPv6 in the category of "experiment" and not "production".

And, of course, we now have companies like T-Mobile and others turning IPv4 off. If that's an experiment, wow.

The cellular data industry appears to have embraced IPv6 in one form or another. I would expect that the network engineers have done some work to keep IPv4 off their *internal* networks, but provide IPv4 access at the edge. (Isn't a netblock within IPv6 intended to enable bridging to IPv4?) The applications on the phon could be configured to search DNS for AAAA addresses first.

T-Mobile documented what they are doing at https://tools.ietf.org/html/rfc6877.

My AT&T cell phone has both IPv4 and IPv6 addresses. The IPv4 address is from my access point; the IPv6 address appears to be a public address.

So does my T-Mobile phone. It got the IPv4 address from my friendly neighborhood WiFi.

I would like to move to IPv6. I just don't want to shoot myself in the foot, or cause trouble for other people, by being sure my edge router "follows all the rules."