Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote: [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt j...@apple.com core os networking
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
everyone-- My position on this draft remains unchanged. It is far too forgiving of the 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] proposal, which I regard as abominable. That reason alone, in my judgment, is sufficient grounds that it should not be published. I also share the concerns of most of the opponents of this draft. My recommendation regarding this draft, to the people inside Apple who implement customer-edge router functions, is to ignore it. It is too late to add the shared transition space to the list of special-use addresses excluded from use as 6to4 tunnel endpoints in all the units already deployed in the field. Such a disruption to existing customer configurations is generally unacceptable behavior for software updates. Also, while it might seem reasonable to add the new space to the list of special-use addresses only in *forthcoming* products that support a 6to4 tunnel router feature, that too is unlikely ever to happen. (Note well: we don't comment publicly about the features of unreleased products.) Shorter james: this draft is a bad idea; please don't publish it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
On Feb 7, 2012, at 11:03 , Tony Finch wrote: Actually TAI depends a lot on relativity as well as quantum physics. For example, it is supposed to match the rate of the SI second on the geoid (which is roughly mean sea level). NIST's lab in Colorado is about a mile high, so they have to apply a general relativistic rate correction to their atomic clocks because of their gravitational potential. I'm aware of that. The point I was trying to make so clumsily is that, outside of the physical contexts where relativity and quantum effects are significant, TAI is a comparatively stable and predictable timescale next to the UTC and the NTP timescales. It would be a perfectly good replacement as The Internet Timescale. so it should be good enough for most running code on the Internet. Except where that code needs UTC. ...or awareness any other timezone, for that matter. On Feb 7, 2012, at 11:12 , John C Klensin wrote: You obviously have not been in enough meetings in which proposals were put forth, by political types with the best of intentions, for regulations to improve the Internet... I said somewhat resistant not impervious didn't I? [I'm not going to recount any of the stories I know about various famous technology sector executives and their unhappy encounters with the laws of physics.] -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ITC copped out on UTC again
On Jan 23, 2012, at 10:03 , Marshall Eubanks wrote: And, of course, this is also orthogonal to the problem at hand, as UTC, GPS time, TT, all also experience from the same issues, and it has nothing to do with leap seconds. A point in favor of deriving the Internet time scale directly from TAI is that it fairly effectively reduces UTC to just another time zone, one that covers the entire surface of the Earth, but a timezone nonetheless. Just like every other time zone, its future divergence from TAI is unpredictable. The principle reason is that time zones are under the control of-- and subject to change at any time by-- various sovereign and treaty bodies. TAI has a fairly stable foundation in non-relativistic physics, which experience has shown to be somewhat resistant to the power of political bodies to modify at will, so it should be good enough for most running code on the Internet. Shorter james: +1 for switching to TAI. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 28, 2011, at 13:25 , Ronald Bonica wrote: […] I will submit the draft to the full IESG for its consideration at its December 1 teleconference. The draft will be published as a BCP if a sufficient number of IESG members ballot Yes or No Objection, and if no IESG member ballots Discuss. Before I get started, I should offer my deepest and most sincere apologies to the participants who have heard quite enough about 6to4 to last a lifetime. Nobody is more ashamed of The 6to4 Problem than me. I have reservations to this draft because it A) gives explicit advice to mitigate the addressing conflict it poses for 6to4 sites by recommending consideration of I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel, which I would contend is even more controversial than Shared CGN Address Space, and B) it mischaracterizes the advisory guidelines in RFC 6343 with respect to the IPv4 Special-Use Addresses in RFC 5375, which in fact are not referenced at all, and indeed the language in RFC 6343, section 4.2.3 IPv4 Prefix Issues and section 3 Problems Observed, would seem to contradict the language in this draft. I could support this draft if instead it were edited to update RFC 3056 directly to clarify the interpretation of its IPv6 Prefix Allocation requirement in section 2, which currently reads: Suppose that a subscriber site has at least one valid, globally unique 32-bit IPv4 address, referred to in this document as V4ADDR. This address MUST be duly allocated to the site by an address registry (possibly via a service provider) and it MUST NOT be a private address [RFC 1918]. I would like to see an explicit recognition that the phrase in RFC 3056, above, duly allocated to the site by an address registry (possibly a service provider), MUST NOT be interpreted to include the new Shared CGN Address Space defined by this document. In simpler terms, what I want is a document that clearly implies 6to4-PMT is not applicable with this new Shared CGN Address Space. No, I am not joking, and I'm very sorry that I had to bring up the topic of 6to4 again. -- j h woodyatt j...@apple.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 2, 2011, at 13:15 , Victor Kuarsingh wrote: […] I would like to point out that PMT has worked in a large production network with much success (as ugly as one may think it is). The reality is that it works, and works well […] In order to retain a semblance of professional composure, I must contain my response merely to expressing my hope that IESG pays very close attention to the language about 6to4-PMT in this draft, and the implications and consequences for the Internet engineering community, if it is published by IETF. This draft is not just about extending the life of IPv4 with NAT444 deployments. It is also about expressly recommending 6to4-PMT for IPv6 service. If this draft is published as is, then I will have a much more difficult time removing 6to4 router function from forthcoming products, as RFC 6343 recommends. Why? Because I don't want to break users who are forced by providers to get their IPv6 service from 6to4-PMT deployment. I hope IESG will think *very* carefully about whether it really wants to sign up for that. -- j h woodyatt j...@apple.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. As one of those implementers-- as in, it will probably be *my* commit to the repository that does rm $XNU/bsd/net/if_stf.c—- I now feel compelled to reiterate that I would prefer a more controlled phase-out plan than, equipment vendors and operators are free to commence the destruction of 6to4 at their individual convenience and without further warning to the user community. In the absence of a coherent instruction from IETF for a phase-out plan, declaring this protocol historic under the current proposed language, will do precisely that. Please please please, if IETF wants 6to4 to die, then publish a phase-out plan so that the current users of 6to4 can have fair warning before the relays go dark and forthcoming hardware/software upgrades rip the feature out from under them. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 27, 2011, at 11:12 PM, Michel Py wrote: According to this: http://www.pam2010.ethz.ch/papers/full-length/15.pdf Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig 3); about 90% MacOS hits is 6to4, which possibly means (to me) that this piece of 6to4 MacOS software of yours represents a third of global IPv6 traffic. Would you care to comment on the numbers? p1. Those numbers are badly outdated. p2. Hits originating from Mac OS X hosts with their 6to4 tunnels disabled probably account for much of that traffic when it was measured. At that time, Apple's operating systems were the most commonly deployed implementations with IPv6 stacks enabled and running in the stock install. That isn't true any more. p3. Recent measurements of hits originating from Mac OS X hosts on 6to4 prefixed networks are dramatically smaller than when those measurements were taken, because Apple has updated Mac OS X 10.6 and 10.7 with significantly different behavior that will avoid using broken or underperforming 6to4 links. p4. Yes, older gear remains in the field, and some of it doesn't even have a software upgrade path. That gear, no doubt, accounts for a substantial portion of admittedly not very large flows through public 6to4 relays at present. I think the measurements we've all seen at the technical plenary show that 6to4 is a small percentage of the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic. p5. We should all be mindful that we're talking about a very small, and as far as I can tell, a not very critical segment of anybody's user base. Which, nevertheless, is still somehow to blame for holding up the global roll-out of IPv6 content. (I'm not sure even the legendary Gnomes of Zürich could do that.) What else is there to say? Oh, I remember now. Those of you 6to4-haters with Lion installed now. Please open a Terminal.app window and type this command: $ sudo sysctl -w net.inet6.icmp6.nd6_accept_6to4=0 That will make the IPv6 stack treat all Prefix Information Options with 2002::/16 prefixed addresses in them as if the A bit is always zero. The system will not auto-configure any 6to4 addresses on any interfaces, even a stf interface. Oh, you want that all the time? Add a line to /etc/sysctl.conf. Done. No more 6to4 for you. Anywhere. Let me know if that changes anything noticeably to the better for you. (On the plus side, it should spare you from suffering any indignity at the hands of a 6to4-PMT service.) -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On Jul 25, 2011, at 10:30 AM, Ronald Bonica wrote: Please post your views on this course of action by August 8, 2011. I remain convinced that this document is unnecessary and publishing it would be silly, at best, and at worst, the simultaneous publication of 6to4-to-historic alongside 6to4-advisory, which implicitly contradict one another-- the latter says that 6to4 has an indefinite future and here's how to keep everything operational in its presence on the Internet; the former says 6to4 has no future, and it should not be used by anyone for any purpose-- may turn out to be an embarrassment for IETF. IESG should feel very nervous about claiming there is consensus to publish this draft. It does not appear to me like there is a rough consensus for it. That said, I won't complain too loudly if this draft is published. It would give me cover to ask my employers for 6to4 capability to be removed from forthcoming products that I mainly work to support. I don't like taking features away from users when there isn't a suitable upgrade path for them, but the truth is that fielding problems from the field resulting from 6to4 failure can be pretty tiresome, and I would welcome the cover from IETF to be able to say, Oh, you're still using 6to4? You should turn that off. It's deprecated by IETF now, and accordingly, we no longer support it. Get native IPv6 service. In other words, whether IESG means to convey this message or not, publishing 6to4-to-historic alongside the existing 6to4-advisory-- without any clear phase-out plan-- will pretty clearly imply to people like me that the official phase-out plan is to remove 6to4 from the Internet, starting as soon as vendors and operators are independently able to do so. Start the engines of destruction. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 18, 2011, at 24:36 , Roger Jørgensen wrote: My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... You mean, your wild guess is service providers will unilaterally implement the phase-out plan I proposed as a standards action. Why not just sign up for a standard phase-out plan? Don't we want 6to4 users to have any advanced notice that we plan to break their Internet? Or, is the idea that we don't believe we can achieve a tactical victory over 6to4 users unless we mount a surprise attack on them? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
On Jul 5, 2011, at 6:39 PM, Randy Bush wrote: what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame. By that I mean, I wrote up and circulated an Internet Draft to specify a phase-out plan for RFC 3056 and RFC 3068. I chose not to submit it when it was made clear to me that no such plan could be adopted as a working group item. On a related note, I much prefer Keith Moore's proposal to reclassify RFC 3056 and RFC 3068 as Experimental. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [homegate] HOMENET working group proposal
On Jun 30, 2011, at 09:36 , Keith Moore wrote: when the group can define something that is useful in IPv6, it shouldn't matter whether it's also useful for IPv4. please don't constrain home networks to work only within the confines of IPv4 brain damage. I suspect what Mr. Townsley and Mr. Arkko are aiming at here is that if FUN can come up with a scheme to make routed home subnetworks work with delegated IPv6 prefixes, then it is probably not too far-fetched that the same scheme could be trivially extended for assigning IPv4 subnets from the RFC 1918 private realm to support dual-stack routed home subnetworks. I'm not expecting home networks to be able to run IPv6-only with the IPv4 Internet mapped to 64:ff9b::/96 through NAT64 for several more years yet. There's a whole crapload of legacy IPv4-only devices in the average home theater system today that nobody wants to cut off from the Internet just yet. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Jun 30, 2011, at 18:46 , Martin Rex wrote: And that [false police report incident] is really among the mild unpleasant things... It's also not even remotely relevant. Under the regime where that incident happened, it's not even news anymore when the police do that without any provocation at all. There is nothing about NAT or dynamic subscriber IP assignment that provides any mitigation whatsoever of the risks entailed by living in a regime like that. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On Jun 24, 2011, at 09:08 , John C Klensin wrote: What I saw was what appeared to me to be some fairly strong arguments for looking at the problem in a different way -- a way that I've seen no evidence the WG considered at all. That would be to explore alternatives to the rather blunt instrument of making a protocol specification historic: explaining what needs to be done to get it right (your document does a lot of that) and then figuring out ways to warn against the uses and configurations that we all (or mostly) agree are bad news. That's not how it appeared to me when I was participating the WG discussions and WG last call. What I remember was that we had two drafts, the first, 6to4-advisory, aimed to do exactly what Mr. Klensin describes, and the second, 6to4-to-history, aimed at giving operators an excuse not to read the advisory, because hey-- 6to4 is history now. The working group considered the option of publishing one and not the other. That evaluation seemed to me to come to an end when the author of 6to4-advisory came out in support of publishing both documents. In the WG discussions leading to the adoption of both drafts as work items, I supported 6to4-advisory and strenuously argued against taking up 6to4-to-historic. When it became clear that I was on the losing side of that argument, and that WG consensus for publishing *both* would be achieved during LC, I analyzed my own reasons for opposing the 6to4-to-historic draft and concluded that I didn't really care that much if 6to4-to-historic were published, because the draft is clearly written to specify something other than what its authors and most of the WG were intending. The WG consensus is to throw 6to4 into the historic trash bin. The draft, however, doesn't do that. It just tells the IETF to stop worrying and learn to love the bomb, while all the vendors of 6to4-capable equipment keep on keeping on with exactly what they're doing today. I could live with that, and I said so. Nobody seemed to care about it, but the observation *was* on the table. I see that some of those in the opposition to 6to4-to-historic do not agree with me that the draft is utterly harmless and will be roundly ignored by industry. To the extent that I can see how 6to4-to-historic may divert its intended audience from reading the much more important 6to4-advisory draft, I sympathize, but I don't see that argument moving too many minds. I had kinda hoped that IESG would put a stop to this nonsense and kick the draft back to the WG with instructions to develop a phase-out plan for 6to4. Alas, that didn't happen. Oh well. I do, however, wonder if we can finally remove 2002::/16 from the default policy table in the next revision of RFC 3484 on the grounds that 6to4 is Historic now, just like 3ffe::/16 is... that would be *excellent*. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On Jun 24, 2011, at 17:10 , Joel Jaeggli wrote: Were it completely harmless I think it wouldn't meet the needs of the authors or supporters either. Clearly they would prefer that it be off as a result, or that the usage be limited to people who've deliberately turned it on and therefore can be expected to tolerate the limitations. Which the 6to4-advisory draft also says quite clearly. I pointed this out in the WG discussion. Everybody understands that 6to4-advisory is sufficient to send that message. No, the WG supporters of this draft are firmly convinced that 6to4-to-historic is also necessary because they mistakenly believe it does something else that 6to4-advisory does not say. The common thread tying together the sentiment expressed by practically all the supporters of 6to4-to-historic is that they want 6to4 not merely turned off by default in subscriber equipment, they also want IETF blessing for operators to ignore the recommendations in 6to4-advisory aimed at IPv6 content and network service providers for properly handling the presence of intentional 6to4 users. In shorter terms, they want to kill 6to4 dead dead dead starting yesterday. This, as others have observed, is a rather confusing message, but it's the one with rough consensus behind it. As I said before, I had hoped that IESG would take the opportunity to clarify this muddle and demand a phase-out plan for 6to4 before declaring it a historic curiosity. But no, it looks like 6to4 tunnel-router mode will be going into the same bucket as wired equivalent privacy (WEP), i.e. a technology that everyone knows is obsolete, and would like to see go away forever, but nobody wants to buy the phase-out plan for it, and so it will continue to be ubiquitous and kept in support forever. Because it works for some people with legacy gear and they don't want to change. Thanks ever so much, IESG! -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 10, 2011, at 09:38 , Lorenzo Colitti wrote: I fundamentally disagree. I really don't think that 6to4 is used by lots of people for applications that wouldn't just use (more reliable) IPv4 if 6to4 wasn't there. The same is often said about IPv6 in general. That's not meant to be snarky quip. When you limit the population under observation to just current IPv6 users and leave out the vast teeming masses of people who are routed IPv4-only, I suspect the data will show that a significant fraction of people are still using 6to4 as a general network-layer NAT-avoidance mechanism because it continues to work for them, setting up a manual tunnel-broker account takes an order of magnitude more effort, and who has time? Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 10:42 AM, Lorenzo Colitti wrote: We have data that clearly shows that Mac OS 10.6.4, which uses 6to4 by default... I don't want anybody to be misled by this statement. I think what Lorenzo meant to say is that Mac OS X 10.6.4 and earlier doesn't implement the policy table in I-D.ietf-6man-rfc3484-revise, which prefers IPv4 source addresses over 2002::/16 IPv6 source addresses. Mac OS X has *never* used 6to4 by default. The scenario Lorenzo is talking about is where a router is advertising a 6to4 prefix onto a native IPv6 link. On those links, Mac OS X 10.6.4 and earlier will treat 6to4 prefixes equivalently to any other IPv6 prefix when making address selection decisions. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 9, 2011, at 18:47 , Masataka Ohta wrote: james woodyatt wrote: I need *native* IPv6 into my home in San Francisco for my day job, Really? Very very very few people have day jobs that require native IPv6 service to their home network today. I'm an exception because I have a requirement that IPv6 and IPv4 provide more or less *equivalent* performance characteristics. The extra 20 milliseconds of queuing delay caused by the 6over4 tunnel endpoint should be acceptable to almost everyone else, but it's a deal-breaker for me. For reasons I'm not going to discuss here, I need IPv6 to be at least as good if not better than IPv4-- today, not three years from now--- and I'm forced to leave my ISP over it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 10, 2011, at 11:20 , Keith Moore wrote: Declaring 6to4 Historic certainly won't prevent people from implementing it. But the proposed action is clearly intended to discourage implementation of 6to4. It says so explicitly. Of course some vendors will ignore it, but some vendors will probably not ignore it. I would absolutely agree that the document would be improved if this pointless recommendation were removed. I expect some perfectly reasonable people will still oppose it with understandable concerns. Nevertheless, I do think this particular recommendation is inconsistent with the consensus in IETF that a phase-out plan for 6to4 is unwarranted. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 10, 2011, at 15:10 , Joel Jaeggli wrote: I think the two documents at present encourage: * vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations. * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from. I would say that I-D.ietf-v6ops-6to4-advisory suffices to encourage both those things with more precision and clarity than I-D.ietf-v6ops-6to4-to-historic does. In fact, I-D.ietf-v6ops-6to4-to-historic makes a more aggressive point on the first item, and sends, at best, a very mixed message about the second. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 9, 2011, at 7:37 AM, Keith Moore wrote: Clearly the intent of this draft and protocol action are to discourage use of 6to4, particularly in new implementations. You can't discourage use of 6to4 in new implementations without harming people who are already using it and depending on it. After it became clear to me that IETF will not be issuing a phase-out plan for 6to4, I recommended to all the relevant product managers at Apple that we should continue supporting 6to4 in new implementations for the foreseeable future (despite the non-RFC2119 'not recommended' line in section 1). I don't see why this draft should discourage anyone from continuing to support 6to4, which as you point out is a *uniquely* useful protocol that people depend on and find *irreplaceable*. Reclassifying it as Historic simply allows IETF working groups to operate on the fiction that 6to4 will eventually disappear someday in the indefinite and vaguely hopeful future. While I don't think that self-delusion will be a good thing for IETF in the long run, I have a hard time getting too bummed out about it. Pragmatism will find its way into deliberations. Yes, I think this draft is a pointless waste of time. The reason I support publishing it, however, is that I disagree with your assessment of the harm it could do. Also, it enjoys widespread support in the V6OPS working group and the opposition, while vocal, seems quite small. That looks like rough consensus to me, and if I can help get it off our agenda sooner by supporting it rather than opposing it, then I say let's print it. I confidently predict the reclassification to Historic will be roundly ignored not just by Apple product engineering but by the entire industry. We're smart enough to recognize that we're not the target audience for the RFC. The draft that matters is the companion advisory draft. It would be nice if the 6to4-to-historic draft could be spiked so as not to distract from its companion, but I don't see that as a likely outcome. Alas and alack. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
On Jun 9, 2011, at 11:24 AM, Keith Moore wrote: [...] But when the support people for a fairly well-established telco haven't even heard of IPv6, it's hard to believe that it's going to be available anytime soon. I have another anecdote to relate. When I contacted the support staff at the moderately sized regional ISP I use at home, to ask about whether they might move to providing native IPv6 service instead of their subscribers-only IPv6-in-IPv4 tunnel service, the support person was knowledgeable about IPv6, but unhelpful. I explained who I am, and what I do at Apple, and tried very hard without disclosing Apple Confidential information to explain that it's not just a hobby for me... I need *native* IPv6 into my home in San Francisco for my day job, and that I want to stay with my current provider rather than move to one of its competitors, which I named, and which I know to be rolling out native IPv6 service in my area in the immediate future. I hoped that might jog something loose. I'm quite willing and able to help them conduct a native IPv6 trial. The support person said, Let me pass along your information to our chief of network operations. A couple days later, I heard back from the support person. We have no plans to offer native IPv6. Meanwhile, 6to4 works fine on their network so long as remote IPv6 destinations have a working return path route to 2002::/16, i.e. they are complying with I-D.ietf-v6ops-6to4-advisory now. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote: From: Martin Rex m...@sap.com Classification of 6to4 as historic is [in]appropriate use of the IETF process, because it would be a political .. statement. Well, we've never done _that_ before, have we? Wouldn't want to set an unfortunate precedent. I see no reason for IETF to avoid setting standards for layer-9 protocols. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote: [...] And it unclear to me why IETF would want to take away a _transition_ technique from people for whom it is working... Let's be very clear. This proposed RFC would not take away the 6to4 transition mechanism. The working group considered and rejected the idea of publishing a phase-out plan. This draft sets no new requirements for most current vendors of 6to4-capable equipment. It is a purely procedural bill, not a technical one. As such, it will damage no one. This draft does redundantly make some recommendations that are also made in I-D.ietf-v6ops-6to4-advisory, which is the companion document with technical content intended for audiences other than the IETF itself. These recommendations mainly say that 6to4 SHOULD NOT be enabled by DEFAULT. Beyond that, the principle point of this draft is to flip a categorization flag that nobody outside IETF cares about. The practical effect of that will be to free the authors of future working group drafts from a procedural requirement to consider whether 6to4 poses any special problems for the subjects of future standards efforts. I'm okay with that, actually, but I have a hard time imagining how it helps them avoid being pragmatic about what's actually deployed in the real world. Reality must take precedence over public relations, as Professor Feynman said. After much consideration on this draft, I have concluded that every moment IETF spends arguing over it is one that would be put to better use discussing almost anything else... even which cute word we should use for the colon-separated fields in the IPv6 address presentation format. Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
On May 2, 2011, at 08:28 , Erik Kline wrote: I'm having a hard time thinking of adequate alternatives terms (but this purely a personal failing, I'm sure). Recommendations for other words? The word enclave springs to mind. We are talking about the use of DNS enclaves for serving resources rather than serving them to the public DNS horizon. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Oct 26, 2010, at 14:18, Fernando Gont wrote: Sorry, but I don't follow. If the problem with widespread deployment of IPsec was NAT traversal, why didn't we see widespread IPsec deployment (for the general case) e.g. once RFC 3948 was published? RFC 3498 really only made a variant of tunnel-mode ESP traverse NAT by encapsulating it in UDP, and the result was predictable: widespread deployment of tunnel-mode ESP for VPN applications where the client is behind NAT and the access concentrator is at a globally routed and reachable address. We still don't have much transport IPsec ESP (much less AH) in the public IPv4 Internet, and the main reason is the ubiquitous deployment of IPv4/NAPT for address amplification purposes, especially at residential gateways. And: Do you expect IPsec deplyment to increase dramatically as IPv6 gets deployed? If you drop the need for NAPT at residential gateways, then I predict you will see a lot more IPsec on the public Internet. Put another way, if you're looking for an effective way to discourage the use of IPsec over IPv6, then find a way to force residential gateways to require IPv6/NAPT functions, e.g. to provide IPv6 address amplification. There are probably other ways-- *better* ways-- but that's the historically proven way of doing it. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
can we please postpone the ipv6 post-mortem?
everyone-- IPv6 may have been born with a developmental disability, but we're not dealing with a corpse yet. The patient is still alive, getting better, and with a bit of love and proper care, might yet grow up to make better and brighter music than IPv4. Maybe I'm being overly sentimental and using anthropomorphism inappropriately here, but really folks-- isn't it a bit unseemly to be arguing over how we went so wrong with IPv6-- and how we could do ever so much better the *next* time we get to reinvent the Internet if we avoid all the killing mistakes we made in bringing IPv6 up-- while there are, today, more people than ever before taking what are perceived to be enormous risks actually making the v4-v6 transition start to happen? -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-cpe-simple-security-12.txt
On Sep 21, 2010, at 09:21 , Arnaud Ebalard wrote: I understand those comments are substantial but they address valid issues, were provided a long time ago, text was proposed for some of them and even picture clarify the issues. Chair has let me know that I shouldn't hesitate to post a new revision of the draft with the proposed amendments. Sorry for the confusion and the delay, and thank you very much for the reminder of the where to find the previous messages. That will save me the hassle of digging them out of my copious archives. I'll send Arnaud and Julien a preview of the forthcoming revision before I post it, just to be sure I've got it basically right. Hopefully, that revision will come out in the next couple of days-- after I'm done being viciously flensed-- figuratively speaking-- by the simultaneous, yet totally reasonable, demands of two competing product managers, each with their own existential crises officially assigned as my drop-everything ship-or-die top priority. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
another document categorization suggestion
everyone-- After just now finding the root cause of yet another stupid interoperability problem to be an interaction between a client not choosing a sufficiently unique host/session identifier and a server being overly clever about using said identifiers for purposes other than intended in the protocol specification... WHEREAS the IETF has no document category for dealing with material that is unfit for Standards Track, that does not in any way describe Best Current Practice, provides Information of questionable utility, which is neither yet limited to Historical interest nor of merely Experimental nature... BE IT HEREBY RESOLVED that IETF should create a new document category for Disinformation, and that RFC 2516 should immediately and with extreme prejudice be reclassified as such without further discussion. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Nov 19, 2009, at 06:14 , Dave Cridland wrote: There exist a few protocols based around mDNS and DNS-SD, in particular in combination, and the general high-level design of both protocols is essentially sound. These are sometimes standards-track specifications of the IETF - I seem to recall some of the SIP related protocols are DNS-SD/mDNS based. In other SDOs, there are also standards track specifications based around the combination, such as the XSF's XEP-0174 - http://www.xmpp.org/extensions/xep-0174.html - and these are also reliant on a stable, well-specified, protocol. To my mind, this implies that both specifications need to be standards track, if that status has any meaning at all - and I firmly believe it should and does. Chiming in to add another ongoing standards effort that would like to reference this document by its RFC number: the TC32-TG21 - Proxying Support for Sleep Modes program at ECMA International, which is now circulating a draft for TC postal vote. See http://www.ecma-international.org/memento/TC32-TG21-M.htm for more information about this effort. One reason to prefer a standards track document here would be to preempt procedural objections in ISO/IEC about references to informational category IETF documents, which have been known to arise from time to time in that body. There is some concern in TC32-TG21 about such objections to ancillary citations of RFC 4795, which is *also* an informational category document. It's possible ISO/IEC won't object to the informational status of either document, but we have a chance to preempt those objections now by publishing mDNS as standards-track. That said, having an RFC number for an informational mDNS document-- in a small number of weeks-- would be orders of magnitude more preferable than not having it, and having to wait an indefinite period of time for a standards track RFC to be published, if that's what IETF decides to do. To make the obvious explicit, I support publishing this document as an RFC without any further delay. If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent. However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document. It should have been published years go, fergawdzakes. Faster, please. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On Jul 3, 2009, at 08:07, Doug Ewell wrote: As always when this discussion occurs, there are at least three different issues swirling around: 1. ASCII-only vs. UTF-8 2. Plain text vs. higher-level formatting, for text flow and readability 3. Whether it is a good idea to include high-quality pictures in RFCs There are not the same issue, and it would help combatants on both sides not to mix them up. I admire the attempt to separate these issues into orthogonal concerns, but I don't think it can succeed. The common aspect of all these issues is the question of whether our archival format should A) continue to be limited to a string of ASCII characters formatted for printing with a fixed-width font, or B) if it should be expanded to include a document archival format that can preserve font, style and figures. There is a related but separable topic of discussion once option B) is open for debate: what precisely should be the set of primary natural languages used in IETF documents? Should it continue to be English only? I'd very much prefer to see *that* discussion vigorously deferred while our archival format continues to be the largest practical obstacle to multilingualism. I believe there are no reasonable candidates for archival formats that can preserve font, style and figures without also providing for localization. I don't know where the argument don't help authors prepare I-Ds using the tools of their choice, unless they are open-source fits into this picture. Compared to the previous two issues, this one is just not so much important. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF languages, was: something about RFCs
On Jul 9, 2009, at 10:01, Iljitsch van Beijnum wrote: There are two things that together make it completely impossible to adopt more working languages [...] My point wasn't to argue that we should consider working in non- English languages, but simply to explain why it's reasonable to rule that discussion out of scope while we get on with talking about archival formats: there is no reason to believe that expanding our archival formats would further limit our future options for adopting new working languages. (I'm thinking centuries into the future here.) -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Jul 5, 2009, at 05:02, Phillip Hallam-Baker wrote: On Jun 29, 2009, at 16:22, Phillip Hallam-Baker wrote: It is not the height of the barrier, it is the perception that people are making nit-picking objections for the sake of rubbing people's noses in the fact that they can decide where to put the bar. [my piquant comment elided for space] Lets unpack this argument: In the serious publishing world there are editors who review prose and nit pick. Therefore all nit picking is evidence of serious publishing and all criticism comes from 'unpublishable wankers'. I don't want to go that far. Let me revise my remarks: the perception of editors making seemingly arbitrary objections about *manuscript formatting*, primarily for the purpose of rubbing the noses of prospective authors in their own plebeianness, is a very common trait among unpublishable wankers. (Being an unpublishable wanker myself still, I'm speaking from experience *and* close observation of my peers.) Shorter james: I'll need to be convinced that perception is fair before I can join in the pillorying of our I-D submissions system maintainers. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Jun 29, 2009, at 16:22, Phillip Hallam-Baker wrote: It is not the height of the barrier, it is the perception that people are making nit-picking objections for the sake of rubbing people's noses in the fact that they can decide where to put the bar. In the more traditional publishing milieus of which I'm aware, that sort of perception is the shibboleth that separates the serious writers from the unpublishable wankers. Prospective authors who express a sense of entitlement to the submission of their manuscripts in formats that don't meet the requirements of the editors who review them are usually encouraged to start their own publishing outfits and see if they can do it all better by themselves. Occasionally, this encouragement is even delivered without the use of coarse language. We participants are our own acquisitions editors here, of course, so the height of the barrier is what we should be thinking about. It makes sense to me that we should be automating the mechanical screening of manuscripts coming into the slushpile so that they meet the machine-scriptable subset of the requirements of the RFC Editor as closely as possible. Are there any nitpicks the draft submission service enforces that aren't really RFC Editor requirements? What are they? Let's fix those. What I don't want to see is a lot of drafts start piling up without even coming close to meeting the *mechanical* requirements of the RFC Editor, much less the more difficult syntax requirements of the working natural language we've chosen. It won't help anyone if we allow authors to defer the process of cleaning up the formatting and boilerplate of a draft until late enough in the review cycle that major reformatting deltas look to the differencing tools like all-new content. If this was about really about quality or readability I would be a lot more sympathetic. But when a draft is rejected because xml2rfc produces a txt file that is rejected because some nit-picker does not quite like the exact TXT format then the whole process is bogus. For my part, I haven't any serious complaints about the status quo (plenty of unserious ones, but no serious ones). The process works well enough for me-- modulo the limitations imposed by our choice of archival format, and my general complaints about the open usability issues of XML2RFC on which I mostly agree with EKR, and on which I'm no more prepared to do anything about than either he or Iljitsch seems to be. So long as we are not discussing any proposals to *change* the set of approved archival formats, I'll continue to be happy-- nay, very impressed, actually-- with how well XML2RFC meets our needs, despite the its obvious warts. If we decide to open another discussion about new archival formats, then I'll be interested to follow along, but archival formats aren't on the table here-- at least, I hope not. - Shorter james: I'm far from convinced that changing the draft submission server to be more lenient is the best way to address the deficiencies in the software we're using, and I also think that opening a new discussion about archival formats will mean unleashing a yet another force-ten maelstrom of controversy that I'd prefer to observe from a very, very safe distance, i.e. one measured in parsecs. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Jun 29, 2009, at 15:01, Paul Hoffman wrote: The original thread is about Internet Draft submission, not RFC publication format. The two topics are completely disjoint in the IETF procedures. Disagree. The two topics are intimately related by their functions in IETF policy and process. Internet Drafts are our slushpile. It the manuscript format required by the RFC Editor does not closely match the manuscript format required for consideration as an Internet Draft, then we will only be making the task of reviewing the slush and preparing manuscripts for publication all the more difficult for ourselves. Do we really want to loosen *only* the I-D submission requirements and not the RFC Editor requirements as well? I don't think so. We would only want to do that because we think we're not getting enough slush to review, and we're worried that we might be losing valuable contributions because the barrier to submit is too high. Honestly, is that *really* the problem IETF is facing? (Note well: I am not expressing an opinion about whether IETF should or should not change its archival format. I'm still forming an opinion about that. This message is about editorial process.) -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-pantos-http-live-streaming-01.txt
On Jun 9, 2009, at 05:28, Dave Cridland wrote: To be fair: a) This one is *just* a poorly written draft [...]. ...as an individual contribution, ...in the Informational category. b) Apple are, at least, producing a public specification in a reasonable forum for discussion. Moreover, Mr. Pantos chose IETF rather than some slushpile with looser editorial standards. We should be happy when a company as secretive as Apple allows their employees to submit drafts to us, even-- especially-- when the manuscripts that land in our slushpile are not yet ready for immediate publication. If IETF doesn't think the information in this draft is worth compiling into a document worthy of sending to the RFC Editor, then that would be good for Mr. Pantos to know. It would probably save him a lot of effort and frustration. I'm sure he looks forward to whatever constructive feedback IETF participants can provide, and I can assure everyone here that nobody at Apple feels their employment status entitles them to any special consideration for their individual contributions. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Nov 25, 2008, at 15:11, Sam Hartman wrote: Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? No. RFC 3424 is the IAB Considerations document covering that problem. I'm tempted to copy and paste highlights from that ancient scripture here, but I don't think I'd know where to stop. As the kiddies say, Read The Whole Thing. The basic problem with NAT66 is that it introduces the possibility of more than one global IPv6 address realm. Where there is more than one, there is *any* number, not just the current realm and the single realm on the other side of the relevant NAT66 box. Fixing your self- address in whatever address realm any given communications peer happens to reside is the canonical problem that NAT causes for applications developers, and NAT66 is no exception to that. If we're going to go very far down this road toward standardizing on a NAT66 solution, then I would humbly suggest that it doesn't make much sense for there to be a single global DNS horizon where we have multiple global address realms. Do the proponents of NAT66 have any proposals for extending DNS appropriately to support the architecture that NAT66 implies? Do we really want to open the can of worms that multiple global DNS horizons represents? I should hope not. -- james woodyatt [EMAIL PROTECTED] member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [73attendees] Is USA qualified for 2.3 of draft-palet-ietf-meeting-venue-selection-criteria?
On Nov 18, 2008, at 00:24, YAO wrote: It seems that many IETFer are disallowed to enter USA for ietf meeting when ietf is held in USA this time or other times Has anyone been denied entry to the USA for IETF 73, without official explanation, despite their including an IETF invitation with their timely visa application to U.S. authorities? If so, then that might be something worth investigating. -- james woodyatt [EMAIL PROTECTED] member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT box spec? (RE: myth of the great transition)
On Wednesday, Jun 18, 2003, at 12:51 US/Pacific, Keith Moore wrote: [I wrote:] When customers of retail Internet service start demanding a NAT standard, then that's when the IETF might want to think about documenting the standard that the market seems to want. here's the only thing that a NAT standard should say: an intermediary MUST NOT alter the source or destination field in an IP header. an intermediary MUST NOT route an IP packet to other than its intended destination. an intermediary MUST NOT alter the payload of an IP packet. I don't dispute this. However, I will observe that customers of retail Internet service seem to rarely have much interest in whether their network intermediaries comply with this proposition. And, your list is incomplete. The NAT code I maintain does all of the things above that your proposal would explicitly forbid-- but it does a few other nasty things as well. For example, 1) it *should* be rewriting IP datagram identifiers (but I haven't coded it yet), and 2) it hides path-MTU discovery black-holes by rewriting TCP MSS fields. Basically, once you've committed to rewriting the forwarding information in an IP datagram, then it's open season on all manner of horrible opportunities for intermediaries to engage in Internet abuse. You want to know what made my blood run cold in the latest release of the product's firmware? I had to change it so that it would propose an impossible MRU in a PPPoE LCP negotiation. Apparently, a lot of PPPoE implementations are happily proposing an MRU of 1500 octets, because there are a lot of PPPoE servers out there that will refuse to negotiate down to the more realistic value of 1492. Consequently, when the product doesn't connect to a buggy PPPoE server, and every other product people try seems to work fine (as long as you don't stress test it), the customer blames the firmware that actually complies with the actual standard for refusing to work the way everyone else's non-compliant system works. So yeah-- I'm very excited about the prospects of the IETF proposing standards. I'm even more excited when they're standards that customers regard as actually valuable parts of their lifestyles. I have yet to see a proposal for a NAT box spec that would seem like a valuable addition to the RFC library. Including yours, Keith... no disrespect intended, honest. -- j h woodyatt [EMAIL PROTECTED] stop me before i rewrite your IP header again.
Re: Engineering to deal with the social problem of spam
everyone-- Here's a silly idea: let's try adding an option for hashcash to APEX. (Or has someone already done that?) If the problem with hashcash is that worms can steal CPU cycles to generate hashcash, then let's attack the problem of worms separately from the problem of spam suppression. If the problem with hashcash is that poor people are taxed more heavily than rich people for the utility of spam suppression, then-- well-- they should upgrade their CPU's, now shouldn't they? And as for those too poor to keep their CPU's current, Let Them Eat SMTP. They clearly have an unhealthy interest in paying to receive MAKE MONEY FAST spam, so we should encourage them to continue using SMTP anyway. The Internet interprets censorship as damage and routes around it. Let SMTP continue to serve the useful function it serves: carrying spam messages. -- j h woodyatt [EMAIL PROTECTED]
Re: Engineering to deal with the social problem of spam
On Tuesday, Jun 10, 2003, at 22:12 US/Pacific, [EMAIL PROTECTED] wrote: [...] There's a *large* number of people still in the 386 world, who are financially unable to upgrade. That same hashcash request that will not inconvenience my hardware will probably kill their box for the better part of an hour. You are concluding that they therefor have an interest in paying to receive spam??? Yup. I am. If anything, spam is a *bigger* problem for those on older hardware, simply because they have fewer computrons available to process it - so you're basically creating a regressive tax here. And I'm not going to apologize for proposing it. Look, the phenomenon of spam is already a regressive tax, in and of itself. I'm just looking for a way to get some useful work done in exchange for receiving it. And I certainly won't mind if someone else is interested in paying me for the option to use the result of whatever useful work your CPU has to do to get your message in front of my eyeballs. Just because the Internet routes around censorship doesn't mean that we have the moral right to censor those people who need it the most - those in underdeveloped countries with repressive regimes. Who's talking about censorship? I'm not proposing that we outlaw SMTP. -- j h woodyatt [EMAIL PROTECTED] that's my village calling... no doubt, they want their idiot back.
RFC 3271 and Internet abuse
friends-- As a statement of ideology, I generally like RFC 3271. However, I *do* have a criticism to contribute... (I know. I should have known about the draft and contributed my comments sooner.) Vinton Cerf writes in RFC 3271: Internet is for everyone - but it won't be if we are not responsible in its use and mindful of the rights of others who share its wealth. Let us dedicate ourselves to the responsible use of this new medium and to the proposition that with the freedoms the Internet enables comes a commensurate responsibility to use these powerful enablers with care and consideration. For those who choose to abuse these privileges, let us dedicate ourselves to developing the necessary tools to combat the abuse and punish the abuser. I'd like to see a more thoughtful statement about what kind of tools the Internet Society favors for countering Internet abuse. The final sentence in the paragraph above seems under-clear to me. As a personal statement of conviction, I would say that I favor tools that empower individuals cooperating in large numbers to make the decisions about who should be punished and to what extent. When such tools are efficacious, I think the Internet Society should favor them. It's much better when abusers are driven from the network because they can't attract buyers for their services, than when the cops have to run them off as a menace to the whole Internet. Unfortunately, I'm not sure I can suggest better language. The problem is difficult. Perhaps if others were to offer suggestions, I could try to offer further improvements. -- j h woodyatt [EMAIL PROTECTED]
Re: How many standards or protocols...
On Monday, April 15, 2002, at 10:34 PM, Harald Tveit Alvestrand wrote: [...] I'd like to hear the IETF community's input on the topic. [...] This is a matter of politics, philosophy and economics (PPE). Asking engineers to comment on such things is nice-- we're so often left out of such discussions. Here's what I think: asking this question is like asking, how many units of currency and instruments of payment does the world need? The answer depends on your theories of PPE. If I could measure the sovereignty of the IETF as a political organization, I'd say it's a function of 1) the value of the networks defined by the standard protocols it has produced to the present, and 2) the forecasted increase in value derived from the standards the world expects it will produce in the future. The obvious (but meaningless) answer is as many as needed. Please allow me to speculate that what the Chair meant to say was as many or as few as will serve to optimize the present and future value of the Internet. The more interesting question is whether the IETF process is well suited to finding the right number of standards or protocols for any given purpose. On *that* subject, I will demure to wiser and older hands than myself. For now, anyway. -- j h woodyatt [EMAIL PROTECTED]
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 08:42 AM, [EMAIL PROTECTED] wrote: [I wrote:] Also, I think it would be helpful to know how commonly twice-NAT is deployed, but I don't have any data there. I believe (at least) twice-NAT is fairly common. I have a NATting router between by cable access modem and my home's local area network, and my cable access provider has a NATting router between the cable access network and the public internet. [...] I should clarify that I was using the term twice-NAT as defined in section 4.3 of RFC 2663 NAT Terminology and Considerations which actually describes quite a different thing altogether. Begin excerpt: Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi- Directional NAT, where only one of the addresses (either source or destination) is translated. [...] Your scenario (which is in the same category as my scenario and the scenario in Appendic C) is not named anywhere I can find. If it has no name yet, I would propose compound NAT or something similar. I think it's important to distinguish that we're not talking about a type of NAT here, but rather a way of composing a topology of address realms using multiple instances of potentially different types of NAT. (Ick-- I feel dirty just writing that phrase.) -- j h woodyatt [EMAIL PROTECTED]
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 01:49 PM, Bill Strahm wrote: [...] I believe AOL for one does this and it wouldn't surprise me if most of the large cable providers do something silly like this at the low end (You can always pay more for a real IP address) I have also received several reports from multiple sources I find credible that at least one large ISP in Asia is doing this. I am, of course, unable to verify such reports. -- j h woodyatt [EMAIL PROTECTED]
Re: draft-iab-unsaf-considerations-01.txt
On Thursday, April 4, 2002, at 05:53 PM, Keith Moore wrote: [I wrote:] [...] I don't see how the presence of NA[P]T in a firewall substantially alters these requirements. [...] but I think the IAB were trying to say that it's important to make sure that measures used to circumvent NAT problems do not essentially end up violating site security policies. an application that's not allowed to talk through a firewall shouldn't be able to use the NAT-workaround to enable it to do so. (and if that's what they meant to say, perhaps it can be said more clearly?) If that's the case, then it wasn't clear to me in the draft. Perhaps one of the current members of the IAB would care to clarify this point before I offer to compose an alternative wording. (but IMHO neither should the mere presence of a NAT be taken to mean that there's a policy in place that prohibits incoming connections) I rather liked the language your wrote in draft-moore-nat-tolerance-recommendations-00.txt about that. Perhaps UNSAF proposals should be structured so that they make no assumptions about whether the presence of NAPT does or does not imply a policy permitting or prohibiting any particular class of incoming connections. I'm not sure how to say that in a meaningful way. 1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why short term fixes usually aren't. For example, I suggest extensions to Internet application protocols for UNSAF use (in an IPv4/NAT environment) should be preferred to application protocols generalized for UNSAF use (over both IPv6 and IPv4 transports). this seems like a overgeneralization, or maybe I don't understand you. I suspect I wasn't communicating clearly. the method that used to adapt an application to NATs will necessarily vary significantly from one application to another, depending on a wide variety of factors - the communications patterns, typical session duration, deployment model (can the user reasonably be expected to install a proxy?), consequences of failure, etc. of each application. at the same time, a generalized approach can be applied to a significant subset of applications, with a useful side effect of aiding a transition to IPv6. see draft-moore-nat-tolerance-recommendations-00 for a start. I was specifically thinking about UNSAF processes, and all I was trying to do was ask the IAB to make a specific recommendation against the use of UNSAF processes in applications of IPv6 transports. I've met too many people-- who are otherwise fairly smart-- who are absolutely committed to the notion that NAT devices will still be required to secure IPv6 networks. I don't understand them, and I think they're wrong about the security considerations of NAT, but I know they're out there. - Another thing that springs to mind: the IAB should probably encourage-- in no uncertain terms-- that any UNSAF process specified for use with IPv4 NAT should also be specified for use with RFC 2766 Network Address Translation - Protocol Translation (NAT-PT) as well. -- j h woodyatt [EMAIL PROTECTED]
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 03:25 PM, james woodyatt wrote: Another thing that springs to mind: the IAB should probably encourage-- in no uncertain terms-- that any UNSAF process specified for use with IPv4 NAT should also be specified for use with RFC 2766 Network Address Translation - Protocol Translation (NAT-PT) as well. I forgot to mention: I think that the dominant variant of NAT-PT will be the combination of Bidirectional-NAT-PT and NAPT-PT. I will admit, though, that my wording above was probably too strong. I'd like to revise my comment by suggesting that proposals for UNSAF processes applicable to IPv4 NAT should be reviewed in the light of RFC 2766 NAT-PT as well. -- j h woodyatt [EMAIL PROTECTED]
draft-iab-unsaf-considerations-01.txt
friends-- I have some commentary to offer on draft-iab-unsaf- considerations-01.txt, i.e. IAB Considerations for UNilateral Self-Address Fixing (UNSAF) which comes from my experience developing a consumer network appliance that combines the functions of an 802.11b access point with a NAT router for Internet access. From section 2: o there *is* no unique outside to a NAT -- it may be impossible to tell where the target UNSAF partner is with respect to the source; how does a client find an appropriate server to reflect its address? (See Appendix C). o specifically because it is impossible to tell where outside or public is, an address can only be determined relative to one specific point in the network. If the UNSAF partner that reflected a client's address is in a different NAT-masked subnet from some other service X that the client wishes to use, there is _no_ guarantee that the client's perceived address from the UNSAF partner would be the same as the address viewed from the perspective of X. (See Appendix C). These two paragraphs are confusing to me. The explanation in Appendix C helps to clarify the issue, but I would suggest rewriting them along the following lines: o a NAT may be a gateway between two or more private address realms, with another NAT optionally used to gateway to the public Internet realm; therefore, it may not always be possible to fix a transport address to the correct realm (or realms) for a given instance of an UNSAF process. (See Appendix C). o there is no system for identifying address realms; therefore, even if there were a mechanism for UNSAF processes to reflect their transport addresses correctly in all appropriate realms, the address of a service from the perspective of a client in one realm is not comparable with the address of the same service from the perspective of a client in another realm. Also from section 2: o absent middlebox communication (midcom) there is no usable way to let incoming communications make their way through a firewall under proper supervision: that is, respecting the firewall policies and as opposed to circumventing security mechanisms. The danger is that internal machines are unwittingly exposed to all the malicious communications from the external side that the firewall is intended to block. This is particularly unacceptable if the UNSAF process is running on one machine which is acting on behalf of several. I contend this is not a problem posed only by UNSAF processes. Firewalls that filter at the Internet and transport layers have performance requirements for enforcing access control policies on incoming communications even when only one address realm is involved. I don't see how the presence of NA[P]T in a firewall substantially alters these requirements. Again from section 2: o proposed workarounds include the use of ping-like packets as traffic to the target service in order to determine the source address from the perspective of the target. However, there is no guarantee that the address translation will be constant throughout the course of the communication between endpoints; aging of NAT UDP bindings varies widely. This is another paragraph that is confusing to me. I think it's because the word target is used in way that makes it hard to understand in context. I'd prefer to see this written as follows: o proposed workarounds include the use of ping-like address discovery requests sent from the initiator to the listener, to which the listener responds with the transport address of the initiator-- in the address realm of the listener; however, with connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF process must take care to react to changes in NAT bindings for a given application flow, since it may change unpredictably over time. From section 3, Practical Issues: From observations of deployed networks, there is a wide variety of practice in how different NA[P]T boxes implement the handling of different traffic and addressing cases. Some of the specific types of observed behaviors have included: [...] I would add the following to the list of observations: o most NAPT implementations with ALGs that attempt to translate TCP application protocols do not perform their functions correctly when the substrings they must translate span across multiple TCP segments; some of them are also known to fail on flows that use TCP option headers, e.g. timestamps. o many NAPT implementations include a connect on demand feature for dialup PPP (as well as PPPoE/DSL) to Internet service
S. 2048, CBDTPA (was: It's war, folks --- SSSCA formally introduced)
everyone-- Come on, folks. It's time to get our oop in a group. Read section 3. The text of S. 2048 is here: http://www.politechbot.com/docs/cbdtpa/hollings.s2048.032102.html If the CBDTPA passes (not terribly likely, but the possibility exists), then the FCC (the U.S. regulatory commission for radio and wired telecomm industries) will be empowered to determine (among other things) whether the IETF has reached agreement on a security system standard for use in the Internet, and whether that standard meets the requirements of the act. The CBDTPA envisions an Internet composed of hosts and routers that have a great deal of network-layer knowledge about illegitimate uses of copyrighted application-layer data flows. This would be a major break from the Internet architecture. Speaking only on behalf of myself, I'd like to see the IESG be proactive about it all, by quickly approving an informational RFC that basically tells the U.S. Senate that, if they don't like how the Internet works, then they can form their own engineering task force and require American Industry to build one that works the way they think it should. In other words, I think it might help the U.S. Senate to know that they won't have to wait a year for the FCC to make a negative determination according to Section 3.(c), i.e. they can go directly to requiring the vendors and users of digital media devices in the United States to adopt Internet standards of its own making rather than those of the IETF. Let's see how well Congress likes the taste of *that* medicine... -- j h woodyatt [EMAIL PROTECTED]
Re: Netmeeting - NAT issue
On Thursday, March 21, 2002, at 06:15 PM, [EMAIL PROTECTED] wrote: Of course, there is the possibility that if they were totally honest, and marketed their devices as Enabling appliances for selected Internet services that they'd STILL make money (and then you'd have no one to blame). Please read the warning below and keep NAT products away from kids and children who are not old enough to understand the risks of network address translation: INTERNET ARCHITECTURE BOARD WARNING: Using Network Address Translators Causes Loss of Routing Transparency and may Complicate Application Protocol Interoperability in the Internet. Thank you! -- j h woodyatt [EMAIL PROTECTED] please network responsibly.
Re: Netmeeting - NAT issue
everyone-- I know this is a frequent source of heated discussion, and that much has already been said that doesn't need to be repeated here, but I *just* *can't* *let* *this* *go* unchallenged. - On Tuesday, March 19, 2002, at 08:26 AM, Keith Moore wrote: [...] in a just world, the NAT vendors would all be sued out of existence for the harm they've done to the Internet. in the real world, if you can hire a famous personality to advertise your product on TV, then by definition it must work well. [...] The harm done to the growth potential of the Internet by the widespread deployment of NAT routers is not the fault of the people who make them. That there is a profitable business to be made in selling NAT appliances to non-technical Internet users is *not* the root cause of the problem. It's a symptom, and I think the IETF would do very well to think long and hard about how to solve the real problem illustrated by the ubiquity of NAT routers in residential settings: strategic opposition to the end-to-end architecture among large retail Internet service providers. The first thing I would suggest is to sit back and contemplate whether the situation bears any resemblance to other problems in which the user population engages in behavior that results in short-term personal benefit in exchange for long-term harm to the welfare of society. In fairness, I should disclose that I am currently employed by a company that sells-- among other fine products-- a home gateway appliance with a NAT routing function; also, my responsibilities include integrating the library of ALG implementations it offers. So, yes-- I've been having this debate with myself for years. I very much wish there were a profitable business to be made selling home gateway appliances with IPv6 and 6to4 support, but I also very much wish that Afghan farmers could make a living growing wheat instead of opium. Sadly-- there is not much business to be made that way today, and whether there will be a thriving business there in the near future remains a very open question. -- j h woodyatt [EMAIL PROTECTED]
Re: Netmeeting - NAT issue
On Tuesday, March 19, 2002, at 01:10 PM, Keith Moore wrote: [I wrote:] The first thing I would suggest is to sit back and contemplate whether the situation bears any resemblance to other problems in which the user population engages in behavior that results in short-term personal benefit in exchange for long-term harm to the welfare of society. granted there are numerous instances of this. but it seems disingenuous to blame the NAT problem on users when the NAT vendors are doing their best to mislead users about the harm that NAT does. I did not mean to imply that my employer's customers are to blame for the NAT problem, or to excuse the NAT vendors (including my employer) who mislead their customers about the harm caused by NAT routers. In the sentence immediately before the one you quoted, I expressed the following opinion (admittedly, as if it were fact): [...] the real problem illustrated by the ubiquity of NAT routers in residential settings: strategic opposition to the end-to-end architecture among large retail Internet service providers. I could be wrong about this, but I really believe this is the root cause of the NAT problem, not ignorant users or self-interested appliance vendors. -- j h woodyatt [EMAIL PROTECTED]
Re: Guidance for spam-control on IETF mailing lists
On Friday, March 15, 2002, at 09:53 AM, Keith Moore wrote: I dunno. I've received several complaints from people who've received spam with my address in the From field. I don't know if I'm being singled out by a spammer [...] You are not. I've seen this tactic used by spammers to circumvent access control on other lists to which I subscribe. In the last month, I've seen it used on three different totally unrelated lists. -- j h woodyatt [EMAIL PROTECTED]
