Re: not really pgp signing in van
Subject: Re: not really pgp signing in van Date: Tue, Sep 10, 2013 at 01:07:19AM - Quoting John Levine (jo...@taugh.com): The MUAs I use (Thunderbird, Alpine, Evolution) support S/MIME a lot better than they support PGP. There's typically a one key command or a button to turn signing and encryption on and off, and they all automagically import the certs from on incoming mail. advocacy type=MUA That is why you should start using mutt. Mutt fetches the PGP key that signed a received message from key servers if it is not present in the local keyring, and verifies it. /advocacy As a result, I've got all the IETFers that sign messages saved in my key ring. Automatically. Subsequent signed messages from that same sender will either validate or be very clearly flagged as fakes. This is exactly the same security level that all SSH fans know and love, ie. wide open for MITM and impostors. It is -- however -- upgradeable to really useful by verifying and signing the sending keys. As has been stated before, MIME multipart signatures and their structured data are definitely capable of maintaining the integrity of the message one is replying to. Frequently, though, this either means that replying properly will trash the message or deteriorate into top-posting. Top-posting, while normally a flogging offense in my book, has the advantage of preserving the replied-to text slightly better. The conversation structure is OTOH trashed[0] The one thing that comes out of this message, then, is that this is a end-node problem that is probably best solved in MUA implementations. A possible method could be to design a diff multipart -- that is a list of edits (i'm thinking of something like diff -e that makes a diff as an ed script that can be applied to the original message.) applied to the replied-to message. This multipart is then signed and transmitted, and the receiving MUA then performs validation of the replied-to text part, the diff part, and if they validate, will merge them, creating a clear presentation of which lines are original and which ones are edited. For reference, the original message of course is included and the MUA should have a display option to show the original unaltered. There are several problems with the above idea, for instance the notion of ever-growing emails as all posters simply shove the history downwards to push their stellar insights on top of the pile, but today, that is mainly a display problem. Since I'm suggesting a fairly aggressive presentation system with preserved history, I think that is tolerable. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I feel like a wet parking meter on Darvon! [0] A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? signature.asc Description: Digital signature
Re: pgp signing in van
Subject: RE: pgp signing in van Date: Mon, Sep 09, 2013 at 05:28:55AM +0100 Quoting l.w...@surrey.ac.uk (l.w...@surrey.ac.uk): There is no upside. By signing your mail you lose plausible deniability, remove legal doubt as to what you said... Thinking twice about what to state has some benefits for communication. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm young ... I'm HEALTHY ... I can HIKE THRU CAPT GROGAN'S LUMBAR REGIONS! signature.asc Description: Digital signature
Re: pgp signing in van
Subject: Re: pgp signing in van Date: Sun, Sep 08, 2013 at 09:50:19PM + Quoting Ted Lemon (ted.le...@nominum.com): On Sep 8, 2013, at 5:33 PM, Michael Richardson mcr+i...@sandelman.ca wrote: To all the people who posted to this thread about how they don't know what a PGP key signature means, and who did not PGP or S/MIME their email: What's the upside to signing my email? I know why I want everybody I know to sign my email, but what's the upside for me if I do it? Until there's a clear win, it's not going to happen. If you, (like I am) are persistent in signing all email, an unsigned email from you is going to Raise Concerns. Bonus point: Signed email gets insane upvotes in Spamassassin. Mutt, Mulberry, and Mail.app (the latter with GPGMail) all do a splendid job of checking the box for you so that you mostly effortlessly can sign all outgoing email. The software is there. The web of trust still is a pain to maintain, but the tools and the benefits are both present. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hey, wait a minute!! I want a divorce!! ... you're not Clint Eastwood!! signature.asc Description: Digital signature
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Date: Fri, Sep 06, 2013 at 09:04:41AM +0300 Quoting Jari Arkko (jari.ar...@piuha.net): I think we should seize this opportunity to take a hard look at what we can do better. Yes, it is completely correct that this is only partially a technical problem, and that there is a lot of technology that, if used, would help. And that technical issues outside IETF space, like endpoint security, or the properties of specific products or implements affects the end result in major ways. And that no amount of communication security helps you if you do not the guy at the other end. But it is also obvious to me that we do not have a situation where everything that could be done has been done. I think we can do more. Some examples: * we're having a discussion in http 2.0 work whether encryption should be mandatory Given the relative impact of http I think that this is the most important of your suggestions. Frankly, I do not think it is sensible to block mandatory crypto in http 2.0. However, I think it is also important to look at how we handle the key distribution problem. The traditional X.509 model has repeatedly been shown to be extremely vulnerable to bad management and directed attacks. Further, the dependency on relatively few root CA instances and the lack of domain name scope limitations makes an attack on said CA not only likely but also most rewarding to the attacker. I do think that more distributed technoligies like DANE play an important rôle here. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Like I always say -- nothing can beat the BRATWURST here in DUSSELDORF!! signature.asc Description: Digital signature
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA Date: Fri, Sep 06, 2013 at 11:46:17AM -0400 Quoting Ted Lemon (ted.le...@nominum.com): On Sep 6, 2013, at 3:25 AM, Måns Nilsson mansa...@besserwisser.org wrote: I do think that more distributed technoligies like DANE play an important rôle here. Right, because there's no way the NSA could ever pwn the DNS root key. It is probably easier for NSA or similar agencies in other countries to coerce X.509 root CA providers that operate on a competetive market than fooling the entire international DNS black helicopter cabal. But that is -- I admit -- an educated guess, based on personal relations. What we should probably be thinking about here is: - Mitigating single points of failure (IOW, we _cannot_ rely on just the root key) In effect, DANE exchanges one trust model for another. I happen to believe that the damage risque is lower with DNSSEC + DANE than the traditional any CA can issue a certificate for any domain name setup. - Hybrid solutions (more trust sources means more work to compromise) - Sanity checking (if a key changes unexpectedly, we should be able to notice) - Multiple trust anchors (for stuff that really matters, we can't rely on the root or on a third party CA) - Trust anchor establishment for sensitive communications (e.g. with banks) agree on all. The threat model isn't really the NSA per se—if they really want to bug you, they will, and you can't stop them, and that's not a uniformly bad thing. The problem is the breathtakingly irresponsible weakening of crypto systems that has been alleged here, and what we can do to mitigate that. Even if we aren't sure that it's happened, or precisely what's happened, it's likely that it has happened, or will happen in the near future. We should be thinking in those terms, not crossing our fingers and hoping for the best. Audit and open source seem to be good starting points. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Yow! It's some people inside the wall! This is better than mopping! signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Thu, Aug 22, 2013 at 12:23:56AM -0400 Quoting Scott Kitterman (scott@kitterma On Thursday, August 22, 2013 00:26:35 Måns Nilsson wrote: ... SPF is a flagship case for the use a TXT record and continue to IPO fast and sloppy crowd. It needs correcting. Badly. Which IPO was that? BTW, in 2003 the choice was use TXT or nothing. So it was a crowd that wanted to accomplish something and did it the only way it was possible. Considering use of TXT wasn't an important factor in the DKIM last call, I conclude that this isn't really about using TXT. It indeed is -- but SPF is as I wrote above a flagship case. SPF was the first, is the most deployed (as its supporters repeatedly assert, wringing their hands, trying to sound apologetical and/or defaîtistic) case of tragedy in the commons that is automated data processing of content in comments and when its proponents try to codify the behaviour of stampeding into the commons by removing the SPF rrtype, enough is enough. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Are we THERE yet? signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S Moonesamy (sm+ietf@elandsys.c My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. The codification of a pessimistic view of the ability of the DNS installed base to adapt to new RRtypes is - in itself - a statement that influences the future of DNS. That this was not completely understood in terms of influence weight is one of the reasons for this debate. There are several questions: (a) Was there an error in RFC 4408? Yes. (b) What was the error in RFC 4408? The TXT rrtype was not properly decommissioned; it lacked definitiveness, and neither publication instructions nor selection/query algorithm satisfy this (originally intended, I suppose and believe) sunset view of the TXT record rôle vis à vis SPF. (c) Why was there an error in RFC 4408? (d) What should be done about the error? 4408bis needs a better defined depreciation statement for TXT, accompanied by publication and query methods that will ensure the continous phasing-out of SPF data in TXT records. A clarification here will help in making DNS UI vendors doing the right thing. I'm quite confident that presently, the UI vendors sleep soundly after reading 4408 and continuing to ignore SPF/99. That is not desirable. There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Apparently. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm using my X-RAY VISION to obtain a rare glimpse of the INNER WORKINGS of this POTATO!! signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Well, almost. 4408 sort of blunders about like the elephant in a china shop wrt. query method and depreciation. (As I have been sternly lectured off-list that I do not understand the SPF payload and therefore am in no position to discuss the DNS usage, I'd like to assert that the payload syntax matters marginally, if at all, for the discussion about which DNS records to use and how.) Specifically, 4408 section 3.1.1 should be updated to: * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if SPF is impossible to publish. * If it is possible to use SPF as a result of having modern provisioning systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, they MUST agree wrt content. * The notion of a sunset date as introduced by Mark Andrews, is interesting. Section 4.1.1 in 4408 should be altered to direct implementations to FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for TXT, thus creating an incentive to improve performance by serving SPF rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The preference for SPF vs TXT that is present in 4408 is to be kept unaltered. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!! signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 04:52:59PM -0400 Quoting Scott Kitterman (scott@kitterma On Wednesday, August 21, 2013 22:05:37 Måns Nilsson wrote: Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Wed, Aug 21, 2013 at 08:51:31AM -0400 Quoting Scott Kitterman (scott@kitterma Apparently. Translated: RFC 4408 was in error because it didn't abandon it's installed base. I gather this is an error you propose to rectify. Well, almost. 4408 sort of blunders about like the elephant in a china shop wrt. query method and depreciation. (As I have been sternly lectured off-list that I do not understand the SPF payload and therefore am in no position to discuss the DNS usage, I'd like to assert that the payload syntax matters marginally, if at all, for the discussion about which DNS records to use and how.) Specifically, 4408 section 3.1.1 should be updated to: * A domain SHOULD use SPF and MAY use TXT. The latter is only suitable if SPF is impossible to publish. This is the point where you abandon the installed base. Particularly given the charter, I think this is an inappropriate approach. As I'm thinking about migration here, let's be generous. Allow publication of TXT too, even if SPF is possible, but then not alone. * If it is possible to use SPF as a result of having modern provisioning systems, SPF MUST be used and consequently, TXT SHOULD NOT be used. (I'd like MUST here, but I'm not certain it flies.) If SPF and TXT coexist, they MUST agree wrt content. draft-schlitt-spf-classic-02, which became RFC 4408, had this MUST when it was approved by the IESG. Since at the time of IESG approval, the RRTYPE for SPF hadn't been allocated yet, they - by necessity - approved a paper design. Fortunately the RRTYPE was allocated sufficiently before AUTH48 that we were able to experiment with running code and determine that this MUST was operationally extremely problematic, so it was removed as part of the AUTH 48 review. Hence my comment about perhaps flying. * The notion of a sunset date as introduced by Mark Andrews, is interesting. Section 4.1.1 in 4408 should be altered to direct implementations to FIRST look for SPF and then _perhaps_ (I'm open for discussion) ask for TXT, thus creating an incentive to improve performance by serving SPF rather than TXT. After a possible sunset, TXT MUST NOT be queried for. The performance implications are more generally constraining on the receive side in high volume mail systems. Adding a second set of sequential DNS queries is a non-starter. Why? There is caching. DNS queries are cheap. The problem of overloading TXT is IMNSHO so bad that it is worth the cost of additional queries; especially if we can collaborate on text to stimulate migration by constructing and specifying algorithms that are faster when using SPF rrtype only. It's much more efficient to go straight to TXT where (ITYM TODAY it is much more efficient and that might change) 99%+ of the time I'll get a correct answer [there are a minute number of domains that publish SPF only, but virtually all type SPF publishers also publish TXT]. I think you're putting the performance implications on the wrong end of the conversation. Let's say we get to this magical sunset date, whose behavior do you think it will influence if they are finding the TXT queries still useful (if they aren't, they won't do it and you don't need the sunset date)? The preference for SPF vs TXT that is present in 4408 is to be kept unaltered. Here's a related conundrum that I haven't seen operationally (due to limited RRTYPE SPF deployment, but I have seen similarly for real in the fallback to v=spf1 records in the SenderID RFCs). It's an example of why you can't ignore the payload. One of the widely used features of SPF is the include mechanism. It allows a sender to authorize the hosts of a third party to send mail on its behalf. It also allows SPF records to be chained together to publish more information while staying in the standard UDP packet limit. Here's an example for the latter from Microsoft's current SPF record: v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com ... A key aspect of include is that the targe domain MUST have an SPF record. If it doesn't, it's a permerror - permanent error. Let's imagine for a moment that example.com has this record published in RRTYPE SPF: v=spf1 a include:example.org -all Then let's consider example.org and imagine that, like most SPF participants today, they have their record
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The IESG (iesg-secret...@ietf.org) The IESG has received a request from the SPF Update WG (spfbis) to consider the following document: - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1' draft-ietf-spfbis-4408bis-19.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as RFC unless substantial parts are reworked. * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. * The overloading of the TXT record is a hack at best, aimed at circumventing DNS management systems vendors that fail to ship support. Breaking the DNS model with specific resource records is not the way to get better application support. (besides, the major argument at the time was it's so hard and takes ages to get a RR type, which isn't true anymore and also, the RRtype is allocated, what's the fuss? ) * The empirical data that was gathered and the conclusions from which that where published as RFC 6686 are IMNSHO flawed and rushed in that they set far too optimistic deadlines for adaptation before declaring failure. The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell the wg that instead of deprecating SPF it should be algorithmically preferred while maintaining support for TXT. Thanks, -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It was a JOKE!! Get it?? I was receiving messages from DAVID LETTERMAN!! YOW!! signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 04:05:49PM - Quoting John Levine (jo...@taugh.com): * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. ... Uh huh. Yes. The TXT specification is TXT-DATAOne or more character-strings. TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found. (RFC 1035 section 3.3.14.) There is nothing syntactially worng with those entries. I congratulate people advocating SPF in TXT records while also writing parsers. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Youth of today! Join me in a mass rally for traditional mental attitudes! signature.asc Description: Digital signature
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Subject: Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 03:59:50PM -0400 Quoting John R Levine (jo...@taugh.com * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. ... The SPF working group discussed this issue at painful, extensive length. As you saw when you read the WG archives, there is a significant interop bug in rfc 4408 in the handling of SPF and TXT records, which (again after painful and extension discussion) we decided the least bad fix was to get rid of SPF records. I don't see anything in your note about how else you think we should address the interop bug. It is in the archives, but for your convenience, and in haste: SPF MUST be published. TXT MAY be published to help in migration. If both, they MUST align. [0] The lookup order should be : Ask for SPF, if not found, ask for TXT, if not found, return ANY. Long-term, one may disregard the TXT fallback. If TXT and SPF differ (and TXT happens to look like SPF syntax), assume that migration is in place, discard TXT and use SPF. And before the whining on query rate starts: The amount of queries is presently uninteresting from a DNS operations perspective. Does matter much less than the squatting on TXT. Besides, we've got caching in DNS, which scales very well. Caching in itself does introduce some pits to fall in, especially regarding TTL in migration states. If deemed suitable, some recommendations on TTL can be discussed. These should however be limited to the unique situation that is trying to publish the same record twice. My naïve hunch is to either recommend publishing both with the same TTL or possibly TXT with a significantly shorter. The latter is probably only interesting in short-term migration states. This discussion is however best had on the spfbis mailing list, after the -19 draft is sent back. In your case it doesn't matter, since your TXT and SPF records make no usable assertions, but a lot of people use SPF right now as part of their mail stream management. Off-topic: They do make usable assertions. It is just that my email policy seems to differ from what you think prudent. I believe I'm free to have a differing policy.[1] Praeterea censeo, Carthaginem esse delendam. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Don't hit me!! I'm in the Twilight Zone!!! [0] Please note that my besserwisser.org records are SPF only. The fact that there is argumentation with a funny prefix in some TXT records is simply some use of TXT records. [1] Mail from me should be authenticated by my PGP signature, not by which IP address that happened to deliver it to your MX node. signature.asc Description: Digital signature
Re: SPF TYPE support
Subject: Re: SPF TYPE support Date: Mon, Aug 19, 2013 at 04:42:42PM -0700 Quoting S Moonesamy (sm+i...@elandsys.com): I personally do not think that it is appropriate to ask any working group participant to shut up. I welcome hearing arguments and I expect a working group to carefully consider them. The repeated assertions of This has been discussed already are in effect shut up, but slightly more polite. I complied until last call. As was recommended by wg chairs. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Yes, but will I see the EASTER BUNNY in skintight leather at an IRON MAIDEN concert? signature.asc Description: Digital signature
Re: Content-free Last Call comments
Subject: Re: Content-free Last Call comments Date: Mon, Jun 10, 2013 at 11:46:29PM + Quoting Ted Lemon (ted.le...@nominum.com): Determining consensus in an IETF last call is a bit more complicated than that. It's not a working group last call. If someone objects to publication during IETF last call, and their objection has already been discussed and addressed in the working group, the objection in IETF last call doesn't break that consensus. So, if wg discussion has been ordered mute by the wg chairs because some wg participants believe the group-think consensus is good enough, can those objections again be raised in IETF LC or are they set in stone? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 NATHAN ... your PARENTS were in a CARCRASH!! They're VOIDED -- They COLLAPSED They had no CHAINSAWS ... They had no MONEY MACHINES ... They did PILLS in SKIMPY GRASS SKIRTS ... Nathan, I EMULATED them ... but they were OFF-KEY ... signature.asc Description: Digital signature
Re: Content-free Last Call comments
Subject: Re: Content-free Last Call comments Date: Tue, Jun 11, 2013 at 01:52:46PM +0200 Quoting Måns Nilsson (mansa...@besserwisser.org): So, if wg discussion has been ordered mute by the wg chairs because some wg participants believe the group-think consensus is good enough, can those objections again be raised in IETF LC or are they set in stone? s/they/the WG decisions/ My apologies. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Once, there was NO fun ... This was before MENU planning, FASHION statements or NAUTILUS equipment ... Then, in 1985 ... FUN was completely encoded in this tiny MICROCHIP ... It contain 14,768 vaguely amusing SIT-COM pilots!! We had to wait FOUR BILLION years but we finally got JERRY LEWIS, MTV and a large selection of creme-filled snack cakes! signature.asc Description: Digital signature
Re: Deployment of standards compliant nameservers
Subject: Re: Deployment of standards compliant nameservers Date: Wed, May 22, 2013 at 12:29:58PM + Quoting Yoav Nir (y...@checkpoint.com): Seems like a tough sell to me. Not worse than BCP38 ;-) OTOH, I have _personally_ done this. I introduced and enforced and got set into policy that name servers hosting domains under .SE should actually have the domain set up and working before we (I was at the registry then, performing transfers between DNS hosting providers and similar work, all very manual and pre-web 1.0) transfered the domain delegation to the new set of servers. I got yelled at quite a lot, but a lot of domain name holders approved. Mostly the anger was from lazy hosting companies that didn't mind having their customers with flapping delegations for a week. It can be done, it won't be popular, but the side effects are good. Mostly. Due to some pressure from someone this policy has been discontinued. I am not responsible anymore. OTTH, I think Marks proposal has some merit. I have a pretty good idea where this comes from, but I think that we -- mostly -- have the tools in 1591, and other documents. OTFH, this won't help until the people shelling out money and other resources to build and run infrastructure start paying attention. The grunt work to be made here is mostly about making certain people know that they should request compliance with the actual standards and not a subset conveniently fitting the preselected candidate. It is unclear to me whether people who are not reading the present set of standards will start reading and paying attention this time around. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm GLAD I remembered to XEROX all my UNDERSHIRTS!! signature.asc Description: Digital signature
Re: A note about draft-ietf-spfbis-4408bis
Subject: Re: A note about draft-ietf-spfbis-4408bis Date: Sun, May 05, 2013 at 11:01:02PM -0400 Quoting Scott Kitterman (sc...@kitterman.com): Personally, I'm quite surprised that doubling the DNS queries associated with SPF for the foreseeable future is a meh issue to DNS people. Infrastructure is generally better at scaling to meet increased load than it is at compensating for protocol ignorance. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Yow! Am I in Milwaukee? signature.asc Description: Digital signature
Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE
Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Thu, May 02, 2013 at 11:20:22AM +0200 Quoting Alessandro Vesely (ves...@tana.it): What percentage of NS servers use dynamic updates primarily? (I only happened to use nsupdate occasionally, e.g. to fix dhcp hiccups.) Every Active Directory installation is using dynamic DNS. And while the unwillingness of that particular vendor to handle unknown RRtypes or add specific support for SPF is a baffling mystery to the rest of the world, they can and do change -- they have a prototype DNSSEC implementation in recent versions complete with a large bunch of new RRtypes. Switching to fully dynamic management would be a major evolutionary step for DNS, and it will certainly make the arguments for strong DNS typing more stringent. Since year 2000 and the initial release of Active Directory that has as a matter of fact happened. The typing argument has always been valid from a design perspective; now there is an operational requirement. /Måns, whose $dayjob includes running AD DNS, but using BIND and Unbound. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Does someone from PEORIA have a SHORTER ATTENTION span than me? signature.asc Description: Digital signature
Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.
Subject: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes. Date: Sun, Apr 07, 2013 at 04:58:52PM -0400 Quoting Hector Santos (hsan...@isdg.net): This is one of those DPEP (Diversity Problem Entry Point) arising from globalization, April 1 HRC (Humor Recognition Culture) differences, IETF stalization and the growth of I-D submissions. I suggest there is a direct correlation among these factors with the end goal efficacy of the submission. Fortunately, there is a technical solution for this particular DPEP: if Date is April.1 then id.filename = joke-+id.filename. end if This solution has all the virtues of carpet-bombing. Mission accomplished but cost and collateral damage are improportionally large. To me, both as humour /per se/ and as sorting help when selecting vendors (cf. my message in this thread yesterday), the value almost totally lies in the subtle play with form and the resulting ambigousness. In other words, if we make it possible to determine by simple logic whether a document is a pun or dead serious, it is useless. I am aware that my position as stated above will be possible to interpret as excluding. As parent of a child diagnosed with Aspergers syndrome, I fully well know the potential consequences of failure to interpret social hints. I believe that * transient failure to get a joke not is cause for safing jokes. The failure is part of the process. * the speed with which we unfail and start to appreciate this art form is personal and differs according to our experience, background and intellectual skills but that the initial failure is necessary. There are subtler ways than policy and procedure to nudge people along when they persist in failing. * the Internet idea of loosely cooperating networks REQUIRES autonomous judgement from the people operating the system. Fostering a culture where IETF texts are seen as close to faultless holy scripture does nothing to encourage skepticism and personal responsibility. * enough has been said in this that we already are risking the sweet uncertainity. Accordingly, I'll try to not communicate further on this, and definitely not propose any procedure work. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I am deeply CONCERNED and I want something GOOD for BREAKFAST! signature.asc Description: Digital signature
Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.
Subject: Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes. Date: Mon, Apr 08, 2013 at 12:30:30AM -0800 Quoting Melinda Shore (melinda.sh...@gmail.com): Doesn't it strike you as odd that this discussion has moved towards some sort of tacit/accepted acknowledgment of the role of joke RFCs as insider/outsider cultural markers rather than just clever bits of writing that are widely enjoyed? I'm a little surprised to find myself developing sympathy for tiresome humorless whiny people. (Wait, no I'm not). Anyway this strikes me as an unfortunate use of those documents. Breaking my own promise to shut up I'll just try to share my (unfinished) thoughts as why this is so. Perhaps it is a reaction to the businessisation of the IETF. Everything needs to be justified and documented (which for the most part is good. Until it is not). So in order to keep the pastime that these documents are, we jerk and try to assign them procedural meaning. When we simply should say They are a funny way to look at ourselves busy trying to describe the world -- but we've somehow lost faith in that. Oh to be an arts major and just being able to place feelings in words and have them graded as passing the exam. ;-) -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... I'm IMAGINING a sensuous GIRAFFE, CAVORTING in the BACK ROOM of a KOSHER DELI -- signature.asc Description: Digital signature
Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.
Subject: Re: Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes. Date: Mon, Apr 08, 2013 at 05:57:54AM -0800 Quoting Melinda Shore (melinda.sh...@gmail.com): I am absolutely not suggesting changing anything other than the unfortunate attitude that the right response to someone missing the joke is to read them out of the meeting/declare them anathema or unworthy or not members of this community. Your beef isn't with me, it's with Måns. To clarify: I was thinking of vendors, not people . The vendor that does not invest in its staff enough to expose them to the IETF culture may not supply my network with code and boxes. People who initially fail to appreciate the jokes for what they are should be enlightened in the most gentle way possible. At no time have I proposed or held the belief that public humiliation is in any way acceptable. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We have DIFFERENT amounts of HAIR -- signature.asc Description: Digital signature
Re: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated April the first
Subject: RE: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated?April the first Date: Sun, Apr 07, 2013 at 11:59:30AM + Quoting Yoav Nir (y...@checkpoint.com): I mostly share the sentiment that this is just humor, so what's the harm. That said, I did at one point have to exercise my diplomatic skills when I got forwarded a customer (nameless here for evermore) question about whether support for RFC 3514 was on our roadmap. On that subject, April 1 RFCen in call for tender, I'd argue that they serve a purpose. If an April 1 RFC is included in MUST or SHOULD -- a clued supplier will have staff that get the joke and reply with only on April 1 or similar. A box-ticking let's hope they don't test this lying bastard will just check it and pull their pants down in public. While the people on this list generally get the joke, not all readers of RFCs are part of this group. The recent RFC 6919 is full of in-jokes (or perhaps, in-roast?) that many outside the IETF will not get. Anyways, it is an issue, but I think these are too much fun to do away with them. I do not want code or devices from people that don't get it in my network. The April 1 series are useful documents. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 So this is what it feels like to be potato salad signature.asc Description: Digital signature
Re: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated April the first
Subject: Re: [IETF] Comments for Humorous RFCs or uncategorised RFCs or dated?April the first Date: Sun, Apr 07, 2013 at 07:31:54PM + Quoting Yoav Nir (y...@checkpoint.com): In this case I could tick that box without being a lying bastard. Just a sort-of deceitful one. It is possible to configure the firewall to drop packets with the evil bit set. I still went with explaining the April 1 RFC concept. You pass. I seem to be able to locate several implementations. Shall we initiate work to elevate 3514 from Informational to Proposed Standard? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I hope the ``Eurythmics'' practice birth control ... signature.asc Description: Digital signature
Re: shared address space... a reality!
On Wed, Mar 14, 2012 at 02:22:04AM -0400, Christopher Morrow wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED GOOD. Now I can BOTH keep sticking my head in the sand AND get NEW RFC 1918 space to number my devices! Trailing edge WINS! Congrats, all you people who joined the ietf mailing list to get your VOTE through. You can sign off now and continue non-contributing to the developement of the future. -- /Måns, pissed off.
Re: IETF Last Calls and Godwin-like rules
Subject: IETF Last Calls and Godwin-like rules Date: Thu, Feb 16, 2012 at 09:04:03AM -0500 Quoting John C Klensin (john-i...@jck.com): ... first appearance of many no-information I support this endorsements from people and constituencies who are not regular participants on the IETF list should immediately trigger a state in which all further statements from that side would be ignored or would end the discussion entirely? Yes, I see the difficulties in figuring out the details of such a rule and implementing it and am mostly joking. Mostly. I support this. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 YOW!! Everybody out of the GENETIC POOL! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 03:42:58PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us If the RIRs do not deny these requests there is likely to be a revolt. On what grounds? The ISPs will come along and say 'I have X new customers, please give me more space for them'. The former being true, on what ground can the RIRs refuse (modulo cases like RIPE)? RIPE NCC is not unique; IIRC there has been extensive synchronisation between RIRen on the subject of sunset allocations. I'd expect any RIR to more or less laugh at the request of a /10 (the size of network we've been told (without any proof beyond handwaving) is required to do CGN nicely) at this stage of address depletion. APNIC: As of Friday, 15 April 2011, each new or existing APNIC account holder is only eligible to request and receive delegations totalling a maximum /22 worth of address space from the APNIC IPv4 address pool. ARIN: Has 3-month consumption cap on allocations. Apparently not so low on space as the others. LACNIC: Has a /22 cap per LIR en route in its PDP. RIPE: Has a /22 rule, as discussed earlier. AFRINIC: I can't at the moment locate their policy, more than that they have incorporated the last five /8's document as governing text in their policy set. Pointers to text welcome. To sum things up, we are at the stage where a /10 is a laughable proposition. The largest usable block (bar squatting on DOD space) for CGN is 10/8. I'd suggest planning for it. That last /22 will probably end up as P router addresses in MPLS core, since all vendors have dragged their feet in implementing v6 MPLS. If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. How? The IETF has neither police, nor an army. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the wrong /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. Folks, we've run out. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 02:36:34PM -0800, David Conrad wrote: Mans, On Feb 13, 2012, at 2:17 PM, Måns Nilsson wrote: To sum things up, we are at the stage where a /10 is a laughable proposition. Other than APNIC, I don't think this is correct. Perhaps folks from the RIRs can confirm. Reading from policy texts, it is. What is stuffed away in the RIR dungeons might technically support such an allocation, of course. For some time still. It is either 10/8 or squat. No other alternatives exist. I'd expect squatting on the wrong /8 to be punishable as a Homeland Security Department -related crime, if one takes the US-centric view. I doubt this, particularly since the use of the addresses we're talking about is entirely internal. Internal schmernal. Stuff leaks. Either by people watching allocations and going Hey or by routing slip Hey, this block ain't 1918, let's route it Folks, we've run out. I'm not dead yet! (to misquote Monty Python) The rumours are persistent, though. -- Måns. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 08:39:03PM -0500, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us We already have a way to make collisions very unlikely, don't use either of 192.168.[01]. I gather that that's not desirable, because otherwise people wouldn't be asking for another block. Of course it could probably be made to work somehow - with enough thrust, etc, etc. But that's not the point - engineering is (or ought to be) all about balancing costs and benefits. Close. The cost to these late adapters without sensible business plans will be higher if they aren't given this allocation. Truth is, that the same problem they are facing has been dealt with in corporate networks for at least 14 years -- I do remember being the victim of a RFC1918 address plan with double NAT for private inter-company links in 1998. The problem is known, solutions exist, and these people have no place requesting a critically scarce resource just to buy themselves fewer customer support calls. Fewer customer support calls one gets by building a better network, not by crying to get community pity. If the people involved were asking for something incredibly painful/expensive in order to make their lives easier, the answer would rightly be 'no'. The cost would far outweigh the benefit. But they're not. All they're asking for is a modest chunk of address space, and the cost of doing that is not significant - we allocate chunks of space _all the time_. Soon, all the time won't be. The IANA has no way of allocating this -- they've run out. Which RIR is going to part with a /10 then? APNIC has run out. The rest of the RIRen are, IIRC, operating in sunset mode, where allocations are _very_ restricted. That is why address space should not be allocated. Because there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. And to top that off, they are too cheap to do the homework of proving their precarious situation. They just state their need and expect us to accept it and codify it in RFC format. But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose Allocate, or don't allocate. That's the only choice. This sounds like a bullying ultimatum. We are not there yet, the alley is wider, and U-turns are possible. The choice is and was between do CGN using RFC1918 and build a network that takes advantage of the latest 15 years of developement in networking. One can argue whether there is significant short-term gains for a commercial entity in doing the right thing as opposed to just cutting corners. And, I firmly believe that any SDO not in touch with reality is bordering on silly. But there is a definite difference between being a tool for the shortsighted on the one hand and crafting good solutions to technical problems on the other. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sun, Feb 12, 2012 at 04:34:40PM -0500, Noel Chiappa wrote: From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. What happened to - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose ...that were the ONLY two choices we have? Suddenly, you introduce a third. Maybe there is more to this... If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. Not any more. Let me quote from RIPE-530, the in-force allocation policy document for RIPE NCC: Allocations for LIRs from the last /8 On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22. LIRs receive only one /22, even if their needs justify a larger allocation. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. RIPE-530, section 5.6 (as copied from http://www.ripe.net/ripe/docs/ripe-530) Again, denying this block is just an attempt to punish ISPs who aren't doing what you want - nothing else. There is _no_ good engineering reason to deny this request. How about there are no addresses left? Allocate, or don't allocate. That's the only choice. This sounds like a bullying ultimatum. Not intended to be; I am not a provider, and have no connection to any provider. This is just my take on what the reality of the situation is. The choice is and was between do CGN using RFC1918 and build a network that takes advantage of the latest 15 years of developement in networking. Don't you think any network that was going to do the second would have already decided that? The ones who are going to do CGN are going to do CGN - the only question is what block of address space they are going to use. Denying them a block is not going to stop CGN. ...which means that the allocation is unecessary ;-) Seriously, Doug Barton pointed out (and I agree) that 99% of the issues with RFC1918 space usage in CGN will be dealt with by using a suitably obscure part of 10/8 or simply 172.16/12. FWIW, most of Asia has been running with layers of NAT for years. Using 1918. Which stinks. That is why we have IPv6. I fully appreciate the need for some legacy connectivity; even though this email conversation is made (from my point of view) fully using IPv6, there are lots of other things needing v4. Running v4 services in NAT and dual-stacking with global scope v6 will give a good incitament to migrate important and E2E-sensitive applications to v6, while preserving some kind of pseudo-reachability for v4 services. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 10:13:25PM -0500, Noel Chiappa wrote: I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. If you have any good technical reasons for finding this a bad idea _other_ than the supposed negative effects on IPv6 deployment, it would be useful to hear them. Are there any? There is no case for it. Any space so allocated will, by tearing down the last community restrains on address reuse, become an extension to RFC1918. There are legitimate uses for unique v4 space as documented in RIR policy and v4 sunset procedures. Let the /10 go there instead. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 12:31:22PM +0100, Roger Jørgensen wrote: On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. Is that true? And if so, why and how can it be formulated or find support it earlier work? And if it is not true. Why and where do you find support for that view? I ask because you might touch something quite fundamental there... can IETF support something that will break/limit reachability on Internet. IMNSHO, the answer should only be NO to that question. Where can I search support for this view? I believe, for starters, that: a/ The original IPv4 Internet was designed with a flat reachability model, as seen from the host IP-stack. (routers are a different thing, but indeed the flatness repeats itself, technically, in the DFZ.) b/ When the Internet faced an address shortage there were two solutions put forward; one being CIDR and the other being IPv6 (nee IPng, IIRC). While it is true that there was work codified in RFC 1631 etc that makes the IETF one of the culprits behind NAT, it is also written that The short-term solution is CIDR (Classless InterDomain Routing) [2]. The long-term solutions consist of various proposals for new internet protocols with larger addresses. Until the long-term solutions are ready an easy way to hold down the demand for IP addresses is through address reuse. This solution has the disadvantage of taking away the end-to-end significance of an IP address, and making up for it with increased state in the network. (RFC 1631, p1) We here clearly see that the authors tasked with describing address translation were fully aware that they were breaking E2E, and that they saw address translation as an intermediate measure to be retired as soon as suitable long-term measures were available. Reading further in the sequence of IETF documents describing NAT, we discover something of a more defaitist position in 3022. The discussion on disadvantages is still there, but there is less talk of replacing NAT with v6. Apparently the massive success of broadband routers was showing. So. With this little historical research made, I think that we can see a couple of things: 1. The IETF knew the drawbacks. 2. NAT was only a desperate measure. 3. NAT was to be retired when IPv6 was ready. 4. The IETF failed to predict the massive market penetration of broadband routers and similar solutions. The key question then becomes, are the market lemmings throwing themselves over the NAT cliff reason enough to give up sound engineering principles? I think that numbering critical devices in a sunset phase (where IPv4 is, resource-wise) uniquely is a more prudent use for address space than giving it away to people who've made bad business decisions (which doing any network business without v6 firmly on the 1-year roadmap is, post say 2006). Especially since it will be used to keep running a system that the IETF has known for 18 years to be severely deficient. -- Måns ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Fri, Feb 10, 2012 at 05:12:31PM -0700, Chris Grundemann wrote: On Fri, Feb 10, 2012 at 15:13, Doug Barton do...@dougbarton.us wrote: On 02/10/2012 10:22, Chris Grundemann wrote: This is not about IPv4 life-support. Seriously? Seriously. The birth of a shared CGN space in no significant way extends the life of IPv4. It does provide the best possible solution to a necessary evil (CGN inside addresses). We do not need another reason for people to delay v6 deployment. Just saying this isn't about sticking your head in the sand does not make it any more so. This _will_be_used_ as an excuse for not rolling out v6. This is about providing the best answer to a difficult problem. The best answer is to make sure that CPEs that will be doing CGN can handle the same 1918 space inside the user network and at the CGN layer. Are you volunteering to buy everyone on earth a new CPE? If not, who do you suggest will? My bet is that no one is willing to drop the billions of dollars required - if they were, we could just sign everyone up for IPv6 capable CPE and skip the whole debate... ;) There are more than 1 prefix in RFC1918. Tell the customers to use another one than the one you inflict on them as bad excuse for not doing v6 quick enough. That there will be increased support load on any provider not giving customers public space is a suitable punishment for above mentioned failure to deliver v6. I still strongly oppose the publication of this draft. In any form except a complete rewrite telling providers to use RFC1918 and be done with it. -- Måns, sadly enough not surprised by the fact that this bad idea still isn't properly killed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (d...@virtualized.org): Michael, On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote: The CGN space seems like a very good place to use 240.0/10. I believe the main driver behind this discussion is the need to deal with deployed non-field-upgradable CPE that has issues with having RFC 1918 space being assigned on the WAN interface. I'd guess said hardware would also likely have issues with 240/4 space being instead. I believe we can narrow the problem with RFC 1918 addresses down to same or overlapping prefix on the outside as inside, rather than assuming that any use of 1918 space on the outside interface is detrimental. Does anybody know of any evidence to the contrary? Vendor default allocations of RFC1918 to broadband router LAN interfaces are limited to nets 10 and 192.168. Does anybody know of any evidence to the contrary? Therefore, point out a /15 from 172.16.0.0/12 and be done with it. The few conflicts arising will fall in two classes: a/ People who have knowingly changed their LAN prefix. b/ Organisations large enough to use _all_ of RFC 1918 inside. a means they can change again. Problem solved. b means that they are large enough to be able to buy public external addresses, if they do not already posess swamp space. Problem solved. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Now I understand the meaning of THE MOD SQUAD! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at 08:17:47PM -0700 Quoting Chris Donley (c.don...@cablelabs.com): We're requesting a /10, not a /12 or /15 (devices attached to one CGN might use the whole /15). Such an allocation would be too small for a regional CGN deployment at a larger ISP, and would likely result in double-CGN. Shared CGN Space really needs to be a /10. The space is going to be reused several times anyway, and NAT (be it carrier, enterprise or SOHO) breaks pretty badly when session space is exhausted. It does not make sense to have much more than a, say, /16 behind each. (CGN is just NAT in a NEBS certified enclosure with an expensive support contract; the basic b0rkenedness remains.) Second, many ISPs do not control customer home network addressing decisions. It is not feasible to tell a customer to renumber, especially when the customer is legitimately using RFC1918 space in accordance with the RFC. As has been restated several times, if you use RFC1918, be prepared to renumber. Goes for everyone, including customers. Unfortunately, your proposal doesn't actually solve the problem we're facing. We are, by request, not discussing solutions (ie. larger address space) but kludges. draft-weil-shared-transition-space-request is polishing manure, not designing solutions. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Hmmm ... A hash-singer and a cross-eyed guy were SLEEPING on a deserted island, when ... signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Thu, Dec 08, 2011 at 12:30:05PM +1100 Quoting Mark Andrews (ma...@isc.org): Does anybody know of any evidence to the contrary?=20 This is not a ISP/CUSTOMER problem. This is a ISP/CUSTOMER/WORK problem. You have the ISP using 172.16/12 You have the customer using 192.168/16 or 10/8 You have WORK using 172.16/12 Enterpises have choosen to use 172.16/12 for EXACTLY the same reasons you want ISP to use 172.16/12. CPE equipment doesn't default to that range. Both the enterprise and the ISP don't want to clash with the employee/customer. I have 1918 space at home, that is used at work. My VPN works. It is common knowledge that split-tunneling is detrimental to network security since so many functions rely (properly or not) on the containment to be close to perfect. In addition to all the RFC 1918 address are for *private* use. Allocating RFC 1918 address is customers not private use, so are you also planning to update RFC 1918 to permit this *new* use case. No. To me, ultimately, private equals an instance of routing policy, ie. AS number. The customer is using 1918 space in spite of not having an AS number (if they have one, they probably got fries with that and have a /24 from swampspace, case closed) and thus must adapt to the provider routing scheme. It MIGHT work with NAT. But not more than that. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Was my SOY LOAF left out in th'RAIN? It tastes REAL GOOD!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)
Subject: Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request) Date: Wed, Dec 07, 2011 at 12:19:49AM +1100 Quoting Mark Andrews (ma...@isc.org): In message 20111206055756.gd20...@besserwisser.org, =?utf-8?B?TcOlbnM=?= Nils son writes: Subject: Re: class E (was: Consensus Call: draft-weil-shared-transition-s= pace-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andr= ews (ma...@isc.org): =20 Ask everyone everywhere that is using this block, in good faith, for some purpose other than supporting addresses behind a CGN to renumber out of this block of RFC 1918 addresss which is now being re-purposed 16 years after it was allocated. I do not understand why it is so hard to come to terms with the fact that IF you have -- in whatever faith -- chosen to use non-unique address space, you have been taking your chanches that sometime, in the future, you WILL have to renumber to keep the illusion of quasi-uniqueness. This goes for everybody. Customer, operator, middlebox or CPE vendor, and my mother. This is inherent in all non-unique space. A new shared allocation from the RIR pools or Class E will not change this fundamental characteristic. Therefore, 1918 space, being the prime example of non-uniqueness, should be quite suited to populate the inside of a CGN. Actually it isn't inherent. It's only if two of the parties involed are forced to use the same address pools that renumbering is inherent. Oh, sorry, I meant the _risk_ (taking your chanches) of conflict as being inherent. Unique addresses are meant to be collision-free, whereas any allocation that might be made as a consequence of this draft can only result in potentially conflicting allocations. Thus, RFC 1918 is as [bad|good] as any other allocation. I furthermore think that any recommendation about address space for CGN insides should try to point out likely candidates (172.28/15, perhaps) but not do more than that. Then broadband router vendors could stay away from that prefix for their defaults (which they do; I've never seen, and anecdotal data[0] confirms it, anything but 192.168/16 and 10/8.) and things would work until the infrastructure and services are upgraded. Further, I think, with personal experience from several 1918-using enterprises[1], that the situation with large organisation with all 1918 space used internally gets put behind CGN is a hoax. Those people nearly always have a guarded stash of old class C swampspace that they use for things like DNS servers, firewall outsides, MX records, etc. Ususally, they can come up with a /27 from that to number a bunch of p2p links. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Xerox your lunch and file it under sex offenders! [0] http://www.answersthatwork.com/Download_Area/ATW_Library/Networking/Network__4-List_of_default_Router_Admin_Passwords_and_IP_addresses.pdf [1] here defined as largish organisation with dedicated IT staff and some cashflow. signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Mon, Dec 05, 2011 at 12:28:56AM -0500 Quoting John C Klensin (john-i...@jck.com): (John, this is more of a general rant than a reply directly to you. Please accept apologies for the kidnapping..) If you advise using some piece of the 1918 space, you can only say We aren't aware of anyone using this space under so-and-so circumstances and not We can prove that no one is using that space. We can also say This space is quite possibly used on the inside of customer-managed devices and thus might create routing system confusion. As with all use of non-unique address space, the responsibility falls on the communicating parties to coordinate their address block utilisation so as to avoid damaging amounts of ambiguity. I did 1918 coordination in joint venture networks 12 years ago, and felt the pain. If I did, then, being the wet-behind-the-ears can-do optimist that I was, why is it that nobody more sane in the industry realised it? I find it repulsive to excessively pamper the late-comers to something that we've KNOWN was going to happen for 15 years. draft-weil-shared-transition-space-request should be rewritten to offer, say, 172.28/16, as Mostly used between CPE and CGN and we all should move on to deploying IPv6 and get the ops warts out of it. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... the MYSTERIANS are in here with my CORDUROY SOAP DISH!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request)
Subject: Re: class E (was: Consensus Call: draft-weil-shared-transition-space-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andrews (ma...@isc.org): Ask everyone everywhere that is using this block, in good faith, for some purpose other than supporting addresses behind a CGN to renumber out of this block of RFC 1918 addresss which is now being re-purposed 16 years after it was allocated. I do not understand why it is so hard to come to terms with the fact that IF you have -- in whatever faith -- chosen to use non-unique address space, you have been taking your chanches that sometime, in the future, you WILL have to renumber to keep the illusion of quasi-uniqueness. This goes for everybody. Customer, operator, middlebox or CPE vendor, and my mother. This is inherent in all non-unique space. A new shared allocation from the RIR pools or Class E will not change this fundamental characteristic. Therefore, 1918 space, being the prime example of non-uniqueness, should be quite suited to populate the inside of a CGN. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Am I SHOPLIFTING? signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Subject: Consensus Call (Update): draft-weil-shared-transition-space-request Date: Sat, Dec 03, 2011 at 05:06:42PM -0500 Quoting Ronald Bonica (rbon...@juniper.net): Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? No. RFC1918 will do, if done wisely. There indeed is additional (oprational) cost, but nothing that can't normally be attributed to the use of non-unique address space. Also, noone has touched on the not-too-unusual use case of one DSL, one PC where the cutomer does not attach a home router/NAT box but instead follows the instruction manual that says Connect PC to DSL modem Ethernet jack.. In that scenario, the CGN is a marginal difference technically speaking. The assignment of a previously-unicast v4 prefix in this case would cause confusion since all How-To's currently present will point out that anything non- RFC1918 is unique or Multicast. Further, if the ISP decides to use 1918 space for CGN deployment there is nothing preventing assigning several addresses (like a /28 or similar) to each customer, removing the need for customer-operated NAT boxes. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? Depends on where you are -- for me and my employers (past and present), none. We enjoy the benefits of abundant Early Registrations. If, OTOH, a new ISP can get a bunch of v4 /24's to properly dualstack important services and interfaces exposed globally, and thus be able to get off the ground using 1918 as v4 dualstack component for the rest, that is a major improvement. - Can alternative /10s be used? While the re-assignment of experimental space up above multicast allocations remains an interesting (or at least amusing) exercise in pain-shifting, the purpose here is to allow more or less orphaned customer equipment to continue working. Forcing previously- experimental address space on them is counter-productive. And, as addressed above, unicast v4 space should be used for things essential. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... I don't like FRANK SINATRA or his CHILDREN. signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: RE: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 09:15:16AM -0500 Quoting Lee Howard (l...@asgard.org): Which problem did ISPs create? By dragging their feet to the inevitable roll-out of v6 they checked the demand for consumer electronics compatible with v6. If v6 connectivity had been norm 6 years ago we'd have more v6-ready devices deployed today. The problem CGN partially solves is providing connectivity for IPv4-only consumer electronics. Renumbering the home network within RFC1918 doesn't provide additional connectivity. When the home router is reconfigured to not have the same prefix on the inside as on the outside, connectivity will improve. It won't be Internet (couldn't be without real addresses on all interfaces) but something closely resembling it. A lot more satisfactory than the unexplainable failure with identical addresses inside and out. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 HUMAN REPLICAS are inserted into VATS of NUTRITIONAL YEAST ... signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:56:55PM + Quoting Daryl Tanner (daryl.tan...@blueyonder.co.uk): I don't like CGN, but the reality is that we're stuck with it. On this basis, it's a case of looking for the least-problematic solution. Which is v6. Propping up v4 will only let those who dragged their feet continue weeping crocodile tears while continuing to fail at their task. It has been established as broad consensus that v6 is the way forward. If industry people failed to do their part in moving towards this future, they should not be surprised at failing as businesses. A dedicated, shared prefix (not from 1918) is the lowest risk for address conflicts, and easiest to manage and control. It is also established practice that if you deploy non-unique address space, be it from 1918 or another special prefix, you are to pay the additional cost in managing the resulting mess. Your network. Your problem. I find it objectionable to waste even more address space on making it easier to avoid DTRT. Moral and perception play a large part here -- if the IETF says it is OK to cheat your way out of what has been the obvious upgrade/expansion/business continuity path since last millenium, what kind of message are we sending out? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... My pants just went on a wild rampage through a Long Island Bowling Alley!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:07:47PM -0500 Quoting Noel Chiappa (j...@mercury.lcs.mit.edu): Which is v6. Yes, beating up on IPv4 has been such a success in getting IPv6 deployed, hasn't it? There is no beating up. v4 is dead, move on. Building a business plan on anything else today is going to fail. Except in some walled gardens where address hoarding has taken place. Like $dayjob, which has a /16 v4 for 4K employees and still has v6 in the backbone and transit and several peers and if not all so at least several end-user networks dual-stacked. All it took was 1. Require v6 support (and at least passable feature parity) in devices. As long as you're doing POS and Ethernet, a no-brainer. Any vendor worth considering will be able to deliver. 2. Require v6 from transit providers and external peers. Completely painless. Got bucketloads of offers at last transit call for tender. All v6-enabled. 3. Extend the enterprise provisioning system^H^H^HH^W^W^W ugly script hack that does router configs to do hex math as well. Took all of a week including adress planning and test deployments. Bonus: The Other Desktop Operating System With The Large Market Share gets extremely happy if it has v6 to play with. because so far, IPv6 deployment is an abysmal failure. Not here. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I just forgot my whole philosophy of life!!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:31:56PM -0500 Quoting Noel Chiappa (j...@mercury.lcs.mit.edu): From: Nilsson mansa...@besserwisser.org There is no beating up. v4 is dead, move on. If you're sure v4 is really dead, why do you care if other people want to re-arrange a few limbs? s/dead/dead for new deployments and startups/ Better? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 We have DIFFERENT amounts of HAIR -- signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
I do not support forwarding the draft (In fact, i oppose it strongly.). Chopping away bits of the usable v4 space to create more unusable space does not in any way help. I can but hope to emulate Randys terse and on-the-spot argumentation, so I'll have to make do with concurring. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 LBJ, LBJ, how many JOKES did you tell today??! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Wed, Nov 30, 2011 at 03:18:24PM -0500 Quoting Wes Beebee (wbee...@cisco.com): Eventually, IPv6 will become more reliable than IPv4. for me, v6 is more reliable at my two most frequented tethering points for the laptop. today. mostly because v6 is clean slate and 100% e2e. this is over tunneling to home. does not matter. the tunnel has lower latency than the v4 route to where I want to go. (wonders of peering wars) See - all you need is a change in perspective... or perhaps timetable. now -1 year was a good time to roll out v6. those who do not have v6 in their backbones today are lagging and will have to pay for it. early adopter pain was 10 years ago (line cards with v4 only feature sets and similar b0rkenendness.) access networks (especially dsl and cable) are a pathetic story in themselves wrt v6, but the backbone has been a breeze to v6-enable for years. peoples RFQen should have started _requiring_ v6 transit and feature parity for v6 and v4 at least two years ago. I did. it helps. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 SANTA CLAUS comes down a FIRE ESCAPE wearing bright blue LEG WARMERS ... He scrubs the POPE with a mild soap or detergent for 15 minutes, starring JANE FONDA!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
--On Thursday, May 27, 2004 12:51:49 -0600 Vernon Schryver [EMAIL PROTECTED] wrote: block port 25 for all types of IP service except the one that draft-klensin-ip-service-terms-01.txt calls Full Internet Connectivity. (agreeing with Iljitsch on this snippet) I have a *very* hard time seeing an IETF document (or discussion on the list) coming even close to endorsing this blocking malpractice. It does not scale (forcing people to use central, probably misconfigured, relays, and it is IMNSHO thorougly bad engineering to try solving L8 problems on L3/4. -- Måns NilssonMN1334-RIPE http://vvv.besserwisser.org +46 706 81 72 04 pgpVmBpJtATHo.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Root Anycast
--On Wednesday, May 19, 2004 01:38:21 +0200 jfcm [EMAIL PROTECTED] wrote: Dear Måns, your points would be well taken if we were talking of the same thing We talk about the scalability and stability of a global name-to-number system. Between us lies some disagreement on how this should be achieved; that is all. On 21:34 18/05/04, Måns Nilsson said: --On Tuesday, May 18, 2004 18:01:05 +0200 jfcm [EMAIL PROTECTED] wrote: 1. first target: distribution of the root machines through a root server matrix and core network - Yes, this is already done. It works, even if it is not top-guided as you envision. I do not envision it as top guided. What we plan is a service of a few separate machines, collecting the national root matrix data (meaning: all what is national and above) and concerting towards a unique version, among themsleves and with other national equivalent agencies. (NB. this concerns DNS among many other real time distributed mutually managed directories). This can be done with caching. You essentially propose a system where two things are done: * Remove the centralism needed for speedy updates. Right now, a new root zone including delegation data can be made available within 48hrs, including purge of the old one. * Initiate a government-to-government negotiation procedure. I see only delay and intervening politics here. Remember -- this is not the length of the Meter or the UTC we are talking about, it is names! Names that do to peoples irrational brains what flags and marching music used to do in the nation-states of the early 20th century. Then the agreed file will be made available to 10 to 250 regional master root severs (one by local business area - probably paid by cities - to support the addition of the local data),. We do not think DNS control and machine power, we think surety, security, stablity, distributed servicing. Ultimately this means probably a national coverage of 1000 machines With the same global and national data. How does this differ from the current anycast developments? I see, for the anycast cases where I have spoken to root admins, that local economies effectively sponsor an instance of one or more of the root servers, and all is well. If the prefix is just locally announced, one gets compartmentisation should this be desired. Prone to failure? OK, but failure on what ? Today the big failure is that we are not free to chose and to develop. The system is not RFC 883 compliant. I cannot chose my data. The root system is not IETF core value compliant, decision is not on the edges. You can choose to run another root zone. You may mix this data with the global version, but doing any of those is an invitation to pain (and your email address will end up in /dev/null (a.k.a. loonybox) in a lot of peoples email systems. The DNS system was designed (much like E.164) to be The One system. Any attempts to break that are painful. Anyway, you can chose the directory system you want. If you do not like it you do not use it. Correct. 2. second target : a user MITM providing hardware, software and brainware firewalling. At root system level it means that the user is to cache his root system. Which part of the present caching resolve server does not provide this service today? Aren't you reinventing the wheel here? :-) We do not speak of the same thing here. You only refer to the 15 K root file and to the 20 years old way to use the internet. If you want people to change their poor habits, you can only propose them better ways for you as part of better services to them. Cache is of no use for them, it is of use for you. Let clarify what you want, and what they want. Let not just continue an old solution because you did not think of something new and better. I, on the contrary, argue that cache is good. It is a carefully balanced engineering compromise between distributed and centralised load. Again, instead of fixing what works (albeit with a bit too much load to be comfortable.) I suggest fixing the cases where caching is not used, ie. broken resolvers and clients. You want to reduce the calls to your system, right? Let stop the cache idea which is something of _your_ system ibn theirs, and propose them an update of _their_ system - like anti-virus updates (ever heard that anti-virus run huge 50x1G systems? And let discover what a user system can bring more to its user owner. So when the user has started using and enjoying _his_ system, you will obtain what you want. Private roots are not subject to DoS. They certainly permit to survive a few hours, days and even probably months. In adding all the root themes we can objectively consider today for ubiquist new services, plus a first necessity software kit and root, we are probably talking of an ASN.1 structure of less than 20 compacted K (comparable to anti-virus updates). Private roots are subject to confusion, mis-directed
Re: Root Anycast
--On Tuesday, May 18, 2004 18:01:05 +0200 jfcm [EMAIL PROTECTED] wrote: 1. first target: distribution of the root machines through a root server matrix and core network - Yes, this is already done. It works, even if it is not top-guided as you envision. containing local root information to make it a need. Decrease of the pressure, risk containement, new data, new services. This is unnecessary and prone to failure. 2. second target : a user MITM providing hardware, software and brainware firewalling. At root system level it means that the user is to cache his root system. Which part of the present caching resolve server does not provide this service today? Aren't you reinventing the wheel here? Private roots are not subject to DoS. They certainly permit to survive a few hours, days and even probably months. In adding all the root themes we can objectively consider today for ubiquist new services, plus a first necessity software kit and root, we are probably talking of an ASN.1 structure of less than 20 compacted K (comparable to anti-virus updates). Private roots are subject to confusion, mis-directed micromanagement by local admins, overly sensitive to local politics, split-vision of what must by design be unified, and endless user frustration. I have tried this in a large corporate network, and it was, even there with a clear chain of command, a horrible mess. Never, ever again will I take anything like it outside a lab (except to kill it). The figures I discussed in a previous memo, show that we could then come back to a 486DX2. However discussing of root server the way we consider them today would be quite meaningless. You have a strong passion for doing something to fix the DNS system. I suggest you channel this passion towards trying to fix all the b0rkened clients (cf. the studies of root server load refered to earlier here) before you try to impose breakage onto the well-functioning root server system. -- Måns NilssonMN1334-RIPE http://vvv.besserwisser.org +46 706 81 72 04 pgpEKl87NJYbq.pgp Description: PGP signature
Re: Thinking differently about the site local problem (was: RE:site local addresses (was Re: Fw: Welcome to the InterNAT...))
--On Monday, March 31, 2003 12:17:44 -0800 Eliot Lear [EMAIL PROTECTED] wrote: Since the address block is ambiguous, routing will assure that if you reach a node it is the correct one. This FUD needs to stop! Right up till the point where two companies start communicating with one another directly with site-locals. Even if there is a router frob to keep the scopes scoped, you can bet it won't be used until someone realizes that the above problem occurred. In every network (well, larger than a single subnet behind a firewall, that is) I've seen, where there were RFC1918 addresses routed on the inside, these things happened, although in v4-land. It is madness. It must stop. With v6, we can make it stop. So, SL must go away, for it is an invitation to madness. All things SL is claimed to solve are solveable with unique addresses too, as long as you've got enough of them. The rest is just simple (perhaps tedious) work that every operations-aware person I know of would prefer to madness. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Re: Fw: Welcome to the InterNAT...
--On Wednesday, March 26, 2003 20:05:11 -0600 Stephen Sprunk [EMAIL PROTECTED] wrote: Thus spake Fred Baker [EMAIL PROTECTED] - Customers that are stupid enough... Someone else's stupidity is not my problem. As a vendor, every customer problem is your problem. Go visit some Fortune 500 customers and ask: . Are you aware you won't be able to get portable IPv6 addresses? . How would you like to renumber your entire network every year? . How would you like us to sell you IPv6 NATs so you'll never have to renumber again? Most F500 customers or similar have their own AS numbers. They can easily become a LIR and get their own assignment. Most of the things making renumbering hard are issues with short-sighted optimisations, like host files instead of DNS, IP addresses in applications, and similar. These all can be taken away in time -- most of the applications that suggest this behaviour are v4-only today, and thus NOW is the time to act decisively to get the message out: Prepare to renumber. As Fred wrote; it is already today possible to build with caution to make renumbering easy. You as a vendor should, instead of making paint-oneself-into-corners misbehaviour possible, make it intuitive to DTRT. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Re: Fw: Welcome to the InterNAT...
--On Thursday, March 27, 2003 09:11:57 +0200 Pekka Savola [EMAIL PROTECTED] wrote: You don't get a portable IPv6 address allocation only by being a LIR. Except by lying or having an interesting interpretation of the required 200 customers in the application, of course... That is because the LIR communities haven't changed that yet. I think it should be changed to what was the intention of a RIPE meeting not long ago; give all who want some space, as long as they are a LIR. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Lost, USB adapter.
Hi, just as I found a working usb-serial adapter at Fry's, I lose it. ATEN USB-RS232 adapter, 9-pin Dsub, translucent iMac-style, one yellow LED. I have to leave today, so, if you find it, mail me, and I'll try to guide you to a suitable Scandinavian who can take it home for me. Alternatively, I'll be in Continental 1-4 for a brief moment during the morning.. -- Måns Nilssonhttp://vvv.besserwisser.org pgp0.pgp Description: PGP signature
Re: new.net (was: Root Server DDoS Attack: What The Media Did NotTell You)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 29, 2002 17:24:43 -0500 Keith Moore [EMAIL PROTECTED] wrote: First target: twice as many as now. why? how will that improve life on the internet? Basically, it will take some of the exclusiveness out of the TLD concept. That is a good thing for peace and quiet on several mailing lists and on the Internet name debate in general. I hope it would shut the nutcases arguing about new TLDs up, because they have been given what they so hotly desire (why escapes me, but I suppose they believe they'll make a big bag of money selling domain names. Good luck.) Technically, it is no problem to keep 500 delegations in sync -- even with higher demands on correctness than are made today, both for the root and most TLDs. However, there can only be one root. That is not up for discussion. (in case somebody thought I think so.) - -- Måns Nilssonhttp://vvv.besserwisser.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE9654E02/pMZDM1cURArisAKCna8uTBH2ueV52O+FaYti9RS9JxACgniNh SCNhNLgmFRP7ViXav1KZxvI= =cZdX -END PGP SIGNATURE-
Re: Root Server DDoS Attack: What The Media Did Not Tell You
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, November 23, 2002 23:02:15 -0500 Michael Froomkin - U.Miami School of Law [EMAIL PROTECTED] wrote: The issue is less the size of the file than the problem of updating many copies of it reliably. The root server operators find it a challenge to assure that even the modestly sized root zone file is correctly distributed to all root servers accurately and in a timely fashion. Are there statistics on this? Certainly the published info I've seen is more of the patting-self-on-back variety. There is a certain amount of work required to keep a large number of servers in sync. Developements such as IXFR, Notify and TSIG all help in speeding up convergence and assuring correctness of data. Still, if the ship is to be run as tight as can be, one needs to perform a significant admin and monitoring work to ensure that these functions actually function. I agree with Valdis that this is not IETF list material; it should be taken to the operations community ASAP. Måns, running DNS servers for fun and public benefit. - -- Måns Nilssonhttp://vvv.besserwisser.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (OpenBSD) iD8DBQE94IaL02/pMZDM1cURAvfzAJ4iFmDxp60u+TCk/coD/MmtyC9CUwCbBsZt svIxKF/bR1R7q7zG/A3f7WU= =JV8U -END PGP SIGNATURE-
Re: Palladium (TCP/MS)
--On Tuesday, October 22, 2002 08:52:17 -0500 Stephen Sprunk [EMAIL PROTECTED] wrote: Microsoft's application protocols (e.g. CIFS aka NetBIOS, Kerberos) are certainly problematic, but I've heard no complaints about their IP stack in several years. Also, this entire paranoia stems AFAICT from the fact that it in XP (as opposed to earlier Windows releases) is possible to open raw sockets. Wow, what a security problem. -- Måns Nilssonhttp://vvv.besserwisser.org
Re: imode far superior to wap
Masataka Ohta wrote: Nilsson; I doubt that you will find support from IETF folks for something that breaks the end-to-end model of IP (as Imode and WAP do as they are implemented today). I want to be able to ssh to my phone (or equivalent). Anything below that is just telephantisms. I'm afraid that ssh for phone is just another telephantisms. :-) Compared to your much healthier view, yes. I do agree that it is very interesting. I was perhaps thinking the same but failed to express; the hand terminal is going to be a computing device with voice capability rather than a phone with datacom kludges. Then it is immediately obvious why one wants to make a VT-style terminal connection to it. :-) (ie SSH) -- Måns NilssonDNS Technichian +46 709 174 840 NIC-SE +46 8 545 85 707MN1334-RIPE
Re: Addresses and ports and taxes -- oh my!
"Dawson, Peter D" wrote: good point... but I do wonder how the border edge router will handle a datagram with TTL approx 240 sec's ( i.e min time required for msg to pass between earth = mars) ? what about jitters, latency ,dropped packets, icmpv6 err msg well whatever Well, back to UUCP, then :-) *nearly just kidding* -- Måns NilssonDNS Technichian +46 709 174 840 NIC-SE +46 8 545 85 707MN1334-RIPE
Re: Addresses and ports and taxes -- oh my!
"Rakers, Jason" wrote: When household appliances begin becoming IP addressable, I think we will see a move towards assigning an Internet IP address per household (much like today's street address). The household will perform NAT for all devices within (one street address can house many people, not just one). IMNSHO, NAT is evil. While most end-luser applications work "fine" with it, it does impose restrictions on what can be done as compared to possibilities in the end-to-end universe. *Designing* something to be NAT in a world that goes toward a larger address space is broken and should be avoided att all practical costs. I do sense that this has been discussed before and will now stop. -- Måns NilssonDNS Technichian +46 709 174 840 NIC-SE +46 8 545 85 707MN1334-RIPE
