Re: Regarding call Chinese names
On 10-Jul-13 19:04, Hui Deng wrote: > We submitted two drafts to help people here to correctly call chinese > people names: > > http://tools.ietf.org/html/draft-deng-call-chinese-names-00 > >http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 > While "first name" and "last name" may be useful for many Western readers, they tend to produce confusing statements like "put his/her Last name first, and first name last." I would prefer the order-neutral terms "given name" and "family name", which results in the more sensible "put his/her family name first and given name last." Also, the section on tones (which BTW belongs in the pronunciation document, not the names document) is a good example of how allowing UTF-8, rather than just US-ASCII, would be useful. "Lao3ban3" (Wade-Giles) requires memorizing what the various tone numbers mean, whereas "Lǎobǎn" (Pinyin) provides a visual representation of the proper tone, which will be more accessible to most readers. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Regarding call Chinese names
On 11-Jul-13 08:58, Simon Perreault wrote: > I have a question: I think I've seen Chinese names written in both > orders. That is, sometimes "Hui Deng" will be written "Deng Hui". Am > I right? Does this happen often? What is the most common order? Is > there a way to guess what order a name is written in? Sometimes it's > not easy for non-Sinophones to know which part is the given name and > which part is the family name. It is more common for the given name to come first when written in Pinyin, following the rule for other languages written in Latin characters, but exceptions are frequent enough that one can't rely on it. A useful and growing convention is to write the family name in all caps. Using the above example, if "Deng" were the family name, you might see: Hui DENG or DENG Hui whereas if "Hui" were the family name, you might see: Deng HUI or HUI Deng Also, most family names have a single syllable; all of the top 100 are, which accounts for 85% of the population of China. So, if exactly one of the names has multiple syllables, it is reasonably safe to assume that is the given name, absent a more definitive clue. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Variable length internet addresses in TCP/IP: history
On 15-Feb-12 08:42, Dave CROCKER wrote: > As I recall, there was essentially no experience with variable length > addresses -- and certainly no production experience -- then or even by > the early 90s, when essentially the same decision was made and for > essentially the same reason.[1] > > It's not that variable length addressing is a bad idea; it's that it > didn't get the research work and specification detail it needed, for > introduction into what had become critical infrastructure. What I > recall during the IPng discussions of the early 90s was promotion of > the /concept/ of variable length addressing but without the > experiential base to provide assurance we knew how it would operate. The problem with variable-length addressing that, in practice, one needs to specify a maximum length. The result, therefore, is that you don't have variable-length addresses at all but rather fixed-length addresses with a shorthand encoding for unused bits. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: terminology proposal: NAT+PT (or NAT64 ?)
Thus spake "Keith Moore" <[EMAIL PROTECTED]>
Rémi Després wrote:
Keith Moore wrote :
... it shouldn't be assumed that there's any direct relationship
between the interior and exterior addresses across a v6<>v4
translator.
I don't see why, as far as the session acceptor is concerned.
Using an IPv4 mapped addresses as destination address when
an IPv6-onlyhost transmits to an Ipv4-only host does make sense.
"IPv4 mapped" addresses (those of the form :::{ipv4 address})
should never appear on the wire. Embedding an IPv4 address
within an IPv6 address might make sense in certain cases, but it
doesn't work in general.
Agreed. That was my first thought when I had independently developed the
NAT-PT concept, but I quickly realized that a v4-mapped source address was
unworkable because it wouldn't ensure that the return path came back to the
same NAT-PT box (which is, unfortunately, necessary).
The traditional NAPT model which can only permit outgoing
sessions is not sufficient for an effective transition from v4 to v6.
Here we differ. I find that to be good enough for the vast majority of
cases, and in those cases where it doesn't work one can deploy native access
so that the NAT-PT box is avoided entirely.
Given that the vast majority of users are behind NAPT boxes today, either
provided by their ISP or purchased at a store, I have a problem with anyone
saying that providing the equivalent (poor) level of functionality via
NAT-PT is insufficient. If we give v6-only users NAT-PT to access v4-only
hosts and native (non-NAT) v6 access, that is better than they have today.
The only other option is multi-layered v4 NAT, which is arguably worse from
an e2e standpoint and certainly from an administrative one.
As a matter of fact, I like your choice of "NAT-XY" to describe the
general mechanism you are working on (if I got it right). This IMHO
shows the expressive power of generalizing Alain's approach,
introducing a dash, as you did, to separate IP versions
identifications from "NAT". What about NAT-XX, NAT-XY, NAT-44,
NAT-64, NAT-46 ? I would be very happy if this debate, introduced
by Ran Atkinson, would end up with such a step against confusion.
To me NAT-64 and NAT-46 are even more confusing, because I
can't tell which end is which. If sessions can be initiated from either
the v4 or the v6 side (which IMO is a necessary condition for the
translation box to be effective), what's the significance of the first
digit vs. the second?
I find the distinction mostly useless since any NAT-PT box will necessarily
need to translate a given flow in both directions because of the state
involved.
However, there is a potentially-useful distinction between deployment types.
For instance, a NAT-PT box at an eyeball site that allows local IPv6-only
hosts to access remote IPv4-only hosts will look somewhat different than a
NAT-PT box at a content site that allows remote IPv6-only hosts to access
local IPv4-only hosts. (And ditto for reversing the versions for each
case...) We may need to distinguish between roles, because the expectations
and configurations will differ, but the core technology and
protocol-mangling is the same for all of them.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: terminology proposal: NAT+PT
Thus spake "RJ Atkinson" <[EMAIL PROTECTED]> NAT, NAPT, and NAT-PT have been used for some while now to refer to various sorts of address/port translation within an IPv4-only network. I have never seen NAT-PT used to refer to that; the common terms are NAT and NAPT, though at least one vendor I'm aware of prefers PAT for the latter. Recently, there has been some discussion of network address with IPv6::IPv4 protocol translation. Some have referred to that as NAT-PT also, which can be confusing to some. That is what RFC 2766 defines NAT-PT to be, so if there's any confusion, the people using that acronym incorrectly need to be informed of that so they can stop. I'd like to suggest that when talking about the concept of translating protocol versions (IPv6 <-> IPv4) in addition to, or instead of, altering port number or IP address, we use the short-hand notation "NAT+PT". Why invent a new notation when we already have a correct one? It's not like we have two currently competing proposals that are vying for the same name, as with the CD and DVD wars; the naming issue for this scenario was settled nearly eight years ago. If one doesn't like the name that was picked, perhaps because it's confusingly similar to names of other things, the time to correct that is long past. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Thus spake "Tony Li" <[EMAIL PROTECTED]> On Oct 9, 2007, at 11:29 AM, David Conrad wrote: On Oct 9, 2007, at 9:43 AM, Tony Li wrote: Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. 32 bit AS numbers. Fortunately, the legacy BGP implementations don't need to recognize the new part of the namespace. They only see the legacy space, including AS_TRANS. The new namespace is translated (with major amounts of information loss) into the old namespace for their benefit. This still doesn't provide a mechanism for legacy systems to interact directly with new systems. For example, you can't have a legacy system directly peer with a system using a 32 bit AS number. Instead, it has to be remapped to AS_TRANS. So, it's just NAT for BGP. ;-) Does that mean the IETF is going to deprecate 32-bit ASNs like was done to NAT-PT? ;-) Perhaps, if the folks hadn't been so dogmatically against NAT at the time, the v4-to-v6 transition model would have worked similarly and we'd be done with it by now... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 to IPv6 transition
Thus spake "John Day" <[EMAIL PROTECTED]> If IANA had any resolve there are at least 25 -30 Class A blocks that should be reclaimed and are not or should not be part of the public Internet address space. AFAIK, IANA does not have any reclamation procedures, nor have any every been assumed to exist. In any event, the legacy assignments were transferred to their respective RIRs during the ERX process, so it's the RIRs' problem now. I don't know what has been going on in the other RIRs, but in ARIN it's been (heatedly) discussed many times what to do with legacy assignments. Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation. Counsel also stated, however, it is unclear that ARIN could assign those same numbers to someone else later. There's quite a bit of history there, including the possibility that assignments made during the ARPAnet days (particularly to universities and defense contractors) were "Government Furnished Equipment" and thus only the government can take them back. There's a counter-theory that numbers cannot be property at all and ARIN can do whatever it wants. Nobody's really sure, least of all the lawyers who'd inevitably be arguing the issue in court when one (or more likely all) of those /8 holders sued ARIN for trying to reclaim them. It doesn't matter who's right in the end; ARIN would be bankrupted just trying to defend itself against several dozen Fortune 100 companies' legal departments... We're working on policy proposals to address the issue the best we can, though, and if you wish to contribute please subscribe to PPML (and read the archives to get up to speed). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 21:19, Stephen Sprunk wrote: Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work Yes, hotels are the worst. In Chicago two months ago they used a NAT timeout in my hotel that was so short that my SSH, IMAP and IM sessions timed out every few minutes. Same problem with most WiFi hotspots; I think they use the same all-in-one boxes for HTTP-interception, DNS, DHCP, etc. There are few vendors in that space whose boxes _aren't_ broken in myriad different ways. Operators don't care because they've already gotten your money by the time you discover the brokenness. because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? Anyone from Microsoft listening? I suppose, in theory, a DNS query over v4 might return an record that _is_ accessible via one of my link-local addresses or the loopback address. As long as v6 is _enabled_ on a Windows box, it does queries, even if it has to send them via v4. I'm told WinXP isn't even capable of doing DNS over v6. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. That complaint doesn't resonate so well when you're writing in a language whose "rules" are defined by whatever people do and if enough people do something "wrong" it gets reclassified as "right". There's a difference between de jure and de facto standards. That's not to say that de jure standards are not needed -- they obviously are -- but when the majority of people are ignoring them, you can't just stick your head in the sand and ignore the de facto reality. That _should_ be a sign that the de jure standards need rewriting after one reviews _why_ the de facto standard has diverged. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 21:10, Stephen Sprunk wrote: First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. So? The RIRs and ICANN have deep pockets. SCO had "deep" pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, AT&T, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. I'm confident that the RIRs' membership would oust any leaders that knowingly got them engaged in significant litigation of this sort. But there are other approaches than simply revoking the address space. For instance, setting up a policy that governs who gets to keep legacy space that takes into consideration various types of use and cost of renumbering makes sense. I'm sure some legacy space is used in a way that's fairly reasonable, while other space isn't used at all. I have proposed policy for ARIN to head in that direction. We'll see if it passes next month. Obviously the elephant in the room is the US government that has about 5% of all address space, which seems excessive even for legacy holders. We don't know what the US DoD is doing with their addresses since that's classified; besides, it was their network to begin with so they do have some special priviledges. The remainder of the USG's address space appears reasonable given the number of hosts/employees/etc. I'm sure you're aware that different size assignments were made to different organizations. I was specifically talking about the /8s, where you get a decent bang for your reclaiming effort buck. But even that isn't enough anymore to bother at this point... Those /8s are held by orgs with significant financial resources and are all at least partially still in use. There are thousands of /16s and tens of thousands of /24s that can be reclaimed with less effort, time, and cost than a single /8 could be, because those smaller blocks aren't in use anymore. There's also a fair amount of squatting on LIR-issued blocks that were justified at the time but aren't anymore. Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), What would that be, $0.25 per address? Big deal. ARIN gets a _maximum_ of $0.034 per address from the "Xtra Large" ISPs that are consuming 80% of ARIN's address space. In reality, they would get $0 per address because those ISPs have already topped out on the fees they pay; once you pass a /14, you pay _nothing_ for additional addresses. My pleas to correct the fee schedule's indirect encouragement of massive waste have apparently fallen on deaf ears. IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Progress in various aspects of IPv6 has been slow because it didn't need to be faster. I see no solvable issues with IPv6 deployment that can't be solved in those 2 years. The single biggest thing we need now are consumer CPE boxes that understand v6 and have 6to4 on by default. The host issue will take care of itself over the next couple of years as non-Vista machines wear out and are replaced. We also need specialty boxes like load balancers, firewalls, NMS, etc. to gain v6 support, but that problem is a few orders of magnitude smaller in scope and could be solved within 2 years by operators beating on their respective sales droids _today_. (No, we still won't have routing that will take us to the next century by then, but I suggest we don't wait for that.) No offense to the ISPs, but fixing the DFZ is a relatively small problem _to deploy_ compared to upgrading a billion end-user sites. It's a much harder problem to come up with a solution for, though -- and the sort of problem the IRTF and IETF seem to be best at. Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. If we had done this two years ago it could have been in Vista and in an XP update, so the space would have been usable by 2010 or so when the older Windows versions and other implementations that don't accept the
Re: ideas getting shot down
Thus spake "Keith Moore" <[EMAIL PROTECTED]> At the same time, IETF needs to understand that optimizing for deployability first and scalability second often succeeds whereas the reverse often fails. We need to understand how to design protocols that can be deployed quickly and yet be upgraded gracefully as the real requirements for long-term widespread use of the protocols become apparent. This is the true failing of the IPng effort: all the attention was focused on the end result, with virtually no effort towards a viable transition model. A contributing factor was that the IETF designed IPng in a vacuum and tossed it over the wall to operators, and completely ignored (and is still ignoring) feedback on why people aren't deploying it. A large part of this hubris comes from the success of IPv4 itself. There were dozens of different L3 protocols in use in the 80s and early 90s, so operators had little problem adding yet another one to their networks -- and IPv4 was so much better than the others that the remainder faded away rather quickly in the mid 90s. It seems to have been assumed that operators would have no problem going back to the dual-stack model to get IPv6 and would drop IPv4 relatively quickly. However, since v6 isn't much better than v4 (arguably worse, if one considers the number of hosts reachable, equipment replacement, staff retraining, etc.), it just hasn't happened. Add to that a transition model that _requires_ that every host be dual-stacked before the first v6-only node appears and you've got a horrible chicken-and-egg problem where nobody has any incentive to create a critical mass of dual-stacked hosts. Also add in how long it took MS to ship an OS with v6 on by default; that should have happened by 1998 or 2000 -- not 2007. NAT-PT was a reasonable solution to this (with a few tweaks), since it could make hosts _appear_ to be dual-stacked with little effort, but it offended the purists and was killed despite there being nothing to replace it. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mini-cores (was Re: ULA-C)
Thus spake "Keith Moore" <[EMAIL PROTECTED]> Well, a start would be a "connectbyname()" API call that takes care of name-to-address mapping and trying different addresses until one works. Most IPv6-capable apps seem to implement that logic now. And in my experience, it sucks. Really hard. The app can take a very long time to establish a very poor connection. The specific reason tends to be that the destination and source both have IPv4 and IPv6 addresses, and the IPv4 address works better than the IPv6 address (maybe because of 6to4 relay routers or whatnot), even though the v6 address is chosen first. Don't forget that you may have a half-dozen or more IPv6 PA addresses that _all_ have to be tried before the host is going to give up and try the v4 address(es). ULAs and LLAs also fit in there somewhere, as do 6to4 addresses, Teredo addresses, VPN connections, etc. Worse, the other host has just as many addresses as you do, with the same variable connectivity for each. You can _easily_ end up with 100+ combinations to probe. Murphy's Law says that the only address pair that works will be the last one that your "address selection" algorithm determines, no matter what algorithm you pick. If you fix the algorithm, fate will respond by changing reachability so that the new "last" pair to probe is again the only one that works. But this is just an instance of the general case that some source-destination address pairs work better than others. Address selection heuristics don't do a good job solving this problem - to solve this problem the network actually needs to tell the host which source-destination address pairs will work well. (and that's pretty ugly) Yes, it's ugly, and it's not the only solution. Another is for the client to initiate connections from every possible source address to every possible destination address at the same time, and for the transport protocol to support adding and removing L3 addresses from the connection over its lifetime as each host gains/loses prefixes. Good luck deciding which of the N*M paths to send payload packets over for optimal throughput, latency, reliability, and cost (among which the stack will likely have no indication of prioritization from the app). And, of course, that'll entail a substantial rework of TCP and most TCP stacks, which means it's at least a decade away. What are we supposed to do until then? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 19-sep-2007, at 17:48, Stephen Sprunk wrote: All of those things are broken, of course. That doesn't change the fact they exist and folks in the operational community will not be impressed with a "solution" that ignores those problems. Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. For instace, we accomodate multi-faced DNS because most "major" web sites would become inaccessible if it weren't. If you are proposing a new protocol that would not accomodate it, forcing users to choose between that protocol and being able to access Google, Yahoo, CNN, MySpace, etc., it's obvious which the masses will choose. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 18:33, Stephen Sprunk wrote: ARIN's counsel has told ARIN that it is unclear if they have legal standing to revoke legacy assignments. First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. We did see 46/8 come back earlier this year, but unless I'm mistaken, that was the first legacy /8 to be returned this century. Return is different than revocation. ARIN is working on policy changes that would encourage/incent voluntary return, as well as community outreach. And, for the record, there are over 50,000 of them, not less than 50. Clarification: 31,386 in ARIN's region. I haven't seen stats for the other RIRs. 5 organizations holding nearly 0.5% of the IPv4 space each? I'm impressed! With that kind of address compression technology we don't need IPv6 after all. I'm sure you're aware that different size assignments were made to different organizations. Also, projections show that even if we reclaimed _every_ legacy assignment (many of which are still in use and even justified under current policy), it would only delay exhaustion six months to a year; it is felt that doing so is not generally worth the effort and would certainly cost an absurd amount in legal fees, and the litigation is likely to last beyond the exhaustion date anyways (with no solid guess as to who would win in the end). I mostly agree with that, but a few years ago it looked like reclaiming, say, half of the legacy /8s would buy us 2 - 5 extra years of IPv4 lifetime and there was enough time to do it at that point. Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), it wouldn't have a material effect. We're going to run out in a few years no matter what we do, the DFZ is going to explode because big ISPs will be getting e.g. hundreds of /20s instead of a single /12 for each request, and IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. The situation is different with v6 because all PI assignments are subject to a contract that allows ARIN to revoke them at any time with a policy change. If a viable alternative emerged, ARIN could stop making new PI assignments, deprecate the existing ones, and drop them after a few years' transition period. I don't believe that for one second. Maybe the RIRs have contracts with all new PI holders, but that doesn't automatically give ARIN the authority to reclaim address space after a policy change. Again, I don't know about all RIRs, but that is _explicitly called out_ in ARIN's Registration Services Agreement and AFAIK has been since day one. That, in fact, is one of the many reasons that the legacy holders do not want to join the RIRs: they believe that their addresses can't be revoked as-is but they could be if they signed an RSA. I don't know of a precedent of any RIR EVER reclaiming ANY address space without the cooperation of the holder, despite the holder not complying with policies. ARIN does so today on a regular basis for certain reasons. There is a proposal that would grant them more policy authority to do so in more cases. The language enabling such policy is in the RSA. As a non-lawyer, I would judge the chances in court for reclaiming IPv4 /8s higher than those for reclaiming IPv6 PI space: in the first case, it's the benefit the continued operation of the IPv4 internet, in the latter case, it's going to look highly arbitrary. I'd suggest you review the comments by ARIN's counsel at the last meeting WRT revoking legacy assignments. It's more complicated than it appears at first glance, particularly to someone not used to our legal system. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: mini-cores (was Re: ULA-C)
Thus spake "Paul Vixie" <[EMAIL PROTECTED]> As mentioned above "PI" blocks can be used for this. As such organizations who can convince all ISPs in the DFZ that they are important enough to have their own routing slot can cough up the dough and be there, others will just have to do with this mechanism to get around. by what method do you expect the dfz to start resisting new routes unless new fees are paid? there is no historical precedent for such fees, nor for a transition from no-fees to fees where all decisionmakers are third parties. absent such a method, the network operators who dominate the bottom-up RIR policy process are almost certainly going to make PI hard to qualify for. In the ARIN region, one can qualify for PI today with as few as 256 hosts, and there was a recent proposal that would have indirectly dropped that to 64 hosts. I cannot justify calling that "hard"; it's arguably "too easy". However, the fact is that small PIv4 assignments have had virtually no uptake -- a few hundred /21-22 blocks assigned according to ARIN staff recently. The DFZ has not exploded, and in fact it's growing slower than Moore's Law. If you're worried about the DFZ and/or exhaustion, go look at the few dozen big ISPs that are putting hundreds to thousands of routes each in the DFZ and consuming over 80% of the RIR IP space. The tiny PI players are a negligible factor compared to the massive deaggregation done by the bigger players due to some combination of TE and incompetence. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 19-sep-2007, at 16:40, Stephen Sprunk wrote: [provider independent addresses] However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. And that would be the same kind of consideration that has gone towards "deprecating" the holding of nearly 0.5% of the total IPv4 address space by a single organization? Despite the fact that we're quickly running out of available IPv4 space and the number of organizations involved is less than 50, visible efforts have yet to materialize. ARIN's counsel has told ARIN that it is unclear if they have legal standing to revoke legacy assignments. And, for the record, there are over 50,000 of them, not less than 50. Also, projections show that even if we reclaimed _every_ legacy assignment (many of which are still in use and even justified under current policy), it would only delay exhaustion six months to a year; it is felt that doing so is not generally worth the effort and would certainly cost an absurd amount in legal fees, and the litigation is likely to last beyond the exhaustion date anyways (with no solid guess as to who would win in the end). So I doubt anything is going to happen once a few tens of thousands of organizations have cast their IPv6 PI addresses in stone. Those prefixes will be around for a _long_ time. The situation is different with v6 because all PI assignments are subject to a contract that allows ARIN to revoke them at any time with a policy change. If a viable alternative emerged, ARIN could stop making new PI assignments, deprecate the existing ones, and drop them after a few years' transition period. OTOH, the alternative that appears may be some novel idea that allows widespread use of PI without injecting routes into the DFZ, in which case it won't be necessary to deprecate it but rather to make it easier to get. Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable Curious how so many people know exactly that so many transitions will take a decade or more, without ANY precedents to base this on. Any transition that requires a change to the _host protocol stack_ can be expected to take that long, based on how long it took to get core v6 support implemented and enabled by default in Windows. It's still unusable for the vast majority of consumers because they're behind CPE NAT devices without 6to4 support. Kudos to Apple for being the first to ship a usable v6 CPE box; hopefully other vendors will follow within a few years. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Thus spake "Mark Andrews" <[EMAIL PROTECTED]> >>>>> "Keith" == Keith Moore <[EMAIL PROTECTED]> writes: >> Fourth, lots of folks (me included) happen to find it >> convenient to use NAT between my site/house/office and my >> upstream provider. Keith> do you also find it "convenient" that NAT has effectively Keith> thwarted the deployment of huge numbers of new Keith> applications, significantly raised the cost of deploying Keith> others, and harmed the reliability of all applications? I find the tradeoffs work in favor of NAT; I expect this to be true both for V4 and V6. Try tftp booting two devices from behind a NAT w/o a tftp ALG. Yes this is a obscure case but is is a perfect example of why NAT is evil. Things that just should work fail and there is no end user fix. With a plain firewall you can add rules to let the reply traffic through. With a NAT you have to choose which device gets to boot as you can't port forward both sets of replies. It works just fine; I have thousands of customers that do it every day behind cheap CPE NAT boxes. Perhaps they have TFTP ALGs, but I doubt it given they can't even handle FTP or DNS right in many cases. I agree NA(P)T is an evil hack, and I'd love to see it go away, but this is not a valid example of its evilness. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce afterall]
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 29-aug-2007, at 22:21, Bill Manning wrote: "the" RIRs are membership organizations, with members consisting of the operational community. they have to try and work with whatever the IETF gives them.. and when what the IETF provides is not operationaly feasable, they can and will make changes so that an operational network exists. In the IETF, you need rough consensus to make decisions. I'm not entirely sure how this works in all the RIRs, but I think at least for ARIN, there is some form of voting involved. ARIN operates on consensus as well. The Advisory Council is tasked with judging consensus similar to the IETF's WG chairs, as well as ensuring the process is followed. Technically the Board votes on policy changes but, with a few notable exceptions, they rubber-stamp the AC's recommendation. The AC and BoT are filled by elections, which may be what you're thinking of. There are five RIRs, but the decisions they make often have global impact, and once one RIR has taken a course of action, the others often feel the need to follow. Many folks participate in multiple RIRs and propose the same ideas in each, and the RIRs do observe each others' actions and determine if they're appropriate to adopt as well. There's major differences, though, which are catalogued on the NRO web site. Case in point is provider independent address space for IPv6. For a decade, this wasn't possible because the IETF was first studying, and after a _lot_ of effort to get things rolling, working on, mechanisms to provide multihoming benefits without injecting a prefix into the global routing table for each multihomed site. Then, with something workable within reach but not quite finished, The spec wasn't even finished; widespread implementation was at least a decade away, based on experience, and a solution was needed before IPv4 exhaustion -- currently projected for 2012 or so. Also, the operational community appears to have nothing but complete scorn for the alternatives the IETF has proposed to date. Folks pushing the IETF proposals concentrated on telling the operators they were wrong instead of asking why they thought what they did. As a former manager told me, "your customers may not always be right, but they're never wrong". ARIN saw fit to allow PI for IPv6 anyway, with potentially very harmful long-term results. Note that part of the motivation for PIv6 was the IETF's discussion of ULA-C. The other part is that there is no time left to deploy any alternative, no matter how great it may be, before IPv4 exhaustion happens. A viable multihoming solution was/is _mandatory_ for IPv6 to get deployed and, lacking a hammer, ARIN decided to pound their nails with a screwdriver rather than watch IPv6 continue to flounder. The IETF leadership never saw fit to say something about this during the ARIN process, and the ARIN process mostly consisted of "I'm not worried about the future and I want my PI block". Lots of folks came over from the IETF (I won't accuse them of being "leaders") to complain during ARIN's policy debates and they, with the help of large ISPs, managed to stall the adoption of PI for over a year. Even the proponents of PI are worried about the future, but we are forced to support the lesser of two evils. Without PI, we wouldn't have any IPv6 routing tables to explode in the first place because IPv6 would become even more irrelevant than it is today. The RIR policy mechanisms are simply not capable of rejecting policy changes that benefit a subset of the community, especially any subset that is well-versed in RIR matters, if such a change is against the interest of the community at large. I suggest you take a closer look at the debates that occur. Many proposals are shot down because they're believed to harm the community; many ideas don't even make it to the proposal stage because of that. Some proposals pass, despite obvious harm to the community, because not passing them would result in worse harm. The IETF isn't immune to this, but does a lot better than the RIRs because it has a technically capable leadership rather than an administratively capable leadership. I'm not familiar with the organization of the other RIRs, but ARIN has two distinct "leadership" groups, one technical and one administrative. (Maybe that also explains the differences in the financial situation between the RIRs and the IETF...) The RIRs charge people for output but allow free input. The IETF charges for contributing but gives its output away. The financial results are predictable for both, as is the community that each is responsible to: the IETF caters to vendors and the RIRs to operators. S Stephen Sprunk "God d
Re: IPv6 addresses really are scarce after all
Thus spake "John C Klensin" <[EMAIL PROTECTED]> Second, the notion that RIRs set addressing policy is one that has not been in place forever. Indeed, it has evolved very slowly and mostly by assertion by the RIRs that they have that authority --assertions that, in other contexts, might look a lot like either filling a vacuum or turf grabs depending on one's perspective. While they have always (since there have been RIRs) had broad discretion within their own regions, and it has always been recognized some coordination discourages forum-shopping and other bad behavior, global address policy was historically set by IANA in conjunction with the IAB, not by the RIRs (although I assume their advice was certainly welcomed). My understanding of the current process is that IANA policy is dictated by getting all RIRs to pass equivalent policies telling the IANA what to do. The NRO fits in there somewhere, as does US DoC. I also believe that the RIRs have some obligation to consult the IETF before making a major policy change and to pay careful attention to anything rational the IETF has to say. The RIRs do look to the IETF for guidance. However, they apparently feel free to declare the IETF's guidance not "rational", to use your word, and go out on their own when needed to meet the community's needs. There is a key difference between advice and authority. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]
Thus spake "Keith Moore" <[EMAIL PROTECTED]> The RIRs do not limit the discussion of operations experience to a narrow few sources, rather the the discussion is open to all and an array of perspectives are offered. The RIRs do not per se discuss operations, the discussion is over policies that are reflective of real world operational experience. what I meant was that users' operations are arguably as important as ISPs operations, and I presume that because of their membership the RIRs are only considering the latter. The RIRs are definitely biased towards ISPs, because IP addressing policy is a core business concern to ISPs but "overhead" to other companies. The IETF has more vendors but still few end users. However, there is adequate proof the RIRs can respond to end users' concerns when anyone cares enough to show up: PIv6 wouldn't have happened without end-user operators coming out of the woodwork to support it, overwhelming ISP and IETF resistance. The periodic flamefests about how to treat legacy space are also demonstrations of end-user input, though it seems to amount to no more than "leave us alone" vs "kill them all" in most cases. perhaps, but if IETF has the problem that it's not willing to assert its ownership over its own protocols, that problem is better addressed in IETF than in ARIN. It's not a matter of ownership but whether the engineering solution is still germane to real world needs. they are separate problems. if the recommendations we made are not viable, then we need to know that so we can fix it. When you've got people in the RIRs talking about "routing around the failure" in reference to the IETF, that's a pretty clear indication. I know the RIRs send liaisons to the IETF; does the IETF send liaisons to the RIRs and various NOGs? Is anyone actually feeding information back and forth officially, or do we just have a few people rehashing the same arguments on different mailing lists? IPv6 (as I first understood it) did have a business model assumed - that one ISP would be all that an enterprise customer would need, I don't know anybody who assumed that. I think it was instead assumed that multihomed sites could make do with multiple (prefixes,addresses) per (net,host) and that applications could somehow tolerate having multiple source and destination addresses, be able to pick a reasonable pair from among those available, and fail over to another source or destination address when one end or another renumbered or the connection failed. (All of which I find rather dubious, but it's not the same thing as assuming that there would be one ISP for an enterprise.) The operational community heard that message, deemed it not a viable solution, and responded by passing PIv6. Heck, people think NAT (and we all know the IETF's head-in-the-sand attitude on that part of reality) with ULAs is more viable than multiple parallel PA assignments. Okay, maybe I'm stretching the point here. I am not sure why I am bothering to post. I guess I've become disappointed in the amount of disrespect displayed in this thread. well, I'm disappointed in the amount of disrespect displayed by RIRs. Perhaps that's true. Or perhaps the RIRs are trying to get the message across that how they assign addresses is up to their communities, not the IETF. Frankly, short of the IETF telling IANA to pull the RIRs' allocations, I don't see what practical authority the IETF has over address policy. I also fail to see why the IETF thinks it _should_ have any authority over that or any other operational matters. In my view, the IETF develops tools and it's up to operators to determine if/how to use them. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Thus spake "Tony Finch" <[EMAIL PROTECTED]> On Tue, 28 Aug 2007, Thomas Narten wrote: As a data point, ARIN (in the last year) adopted a IPv6 PI for end sites doing multihoming policy. Such end sites get a /48. FWIW, technically the PI policy also covers folks that are single-homed, though the bar is higher for them to get a block. It's not expected that many single-homed sites will bother getting one, though; if so, and it becomes an operational problem, we'll raise the bar even higher. I thought that routes in the IPv6 DFZ were not supposed to be more specific than /32. Back when the IETF was trying to stuff the operational world into TLAs and NLAs, completely ignoring the need of folks to multihome or do BGP-based TE (i.e. intentional deaggregation), that was the supposition. The reality is that routes longer than that (I've seen /128s, for that matter) are accepted, up to /48 in general practice. ARIN compromised at /48 for PI because (a) that's what a "site" is supposed to get according to the IETF, and (b) it makes it easy to filter them all out if they ever become a problem for the DFZ. The IETF conveniently told vendors that they should not wire specific prefix lengths into hardware, so this hasn't resulted in any problems like we saw when CIDR was introduced. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On Sep 13, 2007, at 20:52 , Keith Moore wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Disconnect current session, reconnect. Many proprietary protocols do not have the ability to checkpoint a connection and resume it on a different socket. It is not uncommon to require human intervention to retry a connection, or to have to redo all the work from scratch. It is also not uncommon for server applications to crash if their IP address is changed out from under them, or refuse to load with a new IP address. Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Since when is it the job of applications to manage DNS TTLs? It's not. However, many applications are coded to ask DNS once for each name and cache the result forever; this is a problem for long-lived processes, particularly servers, though it can even be seen in common web browsers. Some OSes include a caching resolver that has similar bugs. Some ISPs have caching nameservers that increase TTLs. All of those things are broken, of course. That doesn't change the fact they exist and folks in the operational community will not be impressed with a "solution" that ignores those problems. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thus spake <[EMAIL PROTECTED]> The fact that the filtering recommendations of ULA-C and ULA-G have the same flaws as RFC 1918 is a not sufficient reason to reject them wholesale. Actually, the flaws are different because ULA-C/G leaks will not collide with each other. This means that, unlike RFC1918 which is _impossible_ for ISPs to route for multiple customers, ULA-C/G routes _can_ be routed publicly. Any prohibition on doing so by the IETF or RIRs can (and IMHO, will) be overridden by customers paying for those routes to be accepted. The IETF has zero enforcement capability. Since some RIRs have PI, the odds of that happening have been reduced (which was a major motivation for PI being accepted), but many folks who are asking for ULA-C/G are ones that do not qualify under current PI policies and/or are served by RIRs that haven't adopted PI at all. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Michael Richardson" <[EMAIL PROTECTED]> I have an application where I will have approximately 2000 hosts (many of them virtualized) in a cabinet, and I will eventually have hundreds of such cabinets spread around the world. ... Site-local addresses could be used, but they are distasteful to me for all the reasons that they were deprecated, and all the reasons in rfc1627. (ARIN has suggested that I might consider site-local addresses) I hope you misunderstood; ARIN should have been referring to ULAs, RFC 4193. ARIN has asked told me: (2) In order to receive an initial IPv6 assignment, you must qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. That is correct. Well, the answer would be, for this use would be "use 10.x" network for IPv4. That's why I asked for IPv6. (none of the other rfc1918 spaces are big enough for my use, btw) That is not. ARIN policy is that private addresses are preferred, but public addresses can be assigned for private use if there's a decent justification. Also note that actually _requesting_ PIv4 space is not required to get PIv6 space; only _qualifying_ is required. You appear to qualify based on the limited information provided. I am very disappointed. I don't expect anyone to go and fix ARIN. I am simply posting to express myself. You appear to qualify for a PI /48 (or more than one) under existing policy. If you are unhappy with the policy or need a better explanation, please join [EMAIL PROTECTED] and ask for help. If you do not believe ARIN is following the existing policy, please contact [EMAIL PROTECTED] S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]> > From: "Stephen Sprunk" <[EMAIL PROTECTED]> > _understand_ why PI is necessary, however much they dislike and/or fear > it. Most (all?) of us understand and accept that multi-homing, vendor independence, etc are very desirable *capability* goals. However, whether PI is the right *particular engineering mechanism* to reach those goals remains questionable. You can question it, of course. I question it as well. However, it is the only solution available today that the operational folks consider viable. The IETF promised something different and has yet to deliver, so PI was passed and deployed. If the IETF does eventually deliver something viable, the RIRs will consider deprecating PI. Keep in mind that, for any solution that requires host changes, "deliver" includes being implemented and on by default in Windows. The IPv6 core protocol has only recently achieved this after a decade of waiting, and many other pieces still aren't available (firewalls, load balancers, consumer CPE boxes, management apps, etc). Those who propose shim6 or similar solutions need to expect it'll take another decade after the ink is dry for their solutions to be considered viable -- if ever. Those running networks have to do _something_ in the meantime, however, and the fact that what is available offends someone's sense of architectural purity is completely irrelevant. See also: NAT. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Spencer Dawkins" <[EMAIL PROTECTED]> My apologies for intruding, because I haven't been following the technology during the past couple of years, but V6OPS did an informational RFC on renumbering without a flag day (http://www.ietf.org/rfc/rfc4192.txt) in 2005. I thought the document was helpful when I last looked at it (prepublication). It's helpful in that it documents how to solve maybe a quarter to a half of the technology problems with renumbering. It doesn't solve a lot of other ones, including _any_ of the human problems. The human problems are easily 90% of the effort involved in renumbering. That many of those problems are self-imposed is irrelevant, since they are political problems, not technical problems, and thus outside the scope of the IETF's work. Perhaps better tools would make it easier to solve those political problems, but telling people that change control processes or security rules are "wrong" is just going to get you ignored. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]> > From: Jeff McAdams <[EMAIL PROTECTED]> > In the enterprise world, where I live now, IPv6 is just flat out a > non-starter without PI space. Its just not even a discussion that's > even useful to have, because the answer to IPv6 without PI is just "No." Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. The ISPs fought it, but in the end they've accepted PI because the enterprises are the ones paying their bills. If supporting PI raises their costs, it'll raise _everyone's_ costs and the enterprises will continue to pay. Just out of curiousity, how do the enterprises expect to exhange bits without ISP's? Lots of business associations _do_ operate private networks -- not connected to the public Internet or any ISP -- to exchange bits with each other reliably. Those folks generally do not participate in the IETF/RIR process, so many forget they exist. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thus spake "Tony Hain" <[EMAIL PROTECTED]> Jari Arkko wrote: Right. Or we can try to label it, but that labeling may not correspond to what is actually done with it. If you don't label it there is no clearly agreed way to filter these out if you don't want them. If they're truly "local" prefixes, they won't need to be filtered in the first place because they won't be advertised. If they're getting advertised, they're not "local" prefixes and presumably you don't want to filter them because there's someone at the other end who wants you to talk to them. If you don't like PI routes at all, the RIRs have made it easy to filter them by assigning PI out of specific blocks and in much smaller sizes than LIR blocks. To channel Randy for a moment, I encourage my competitors to do this. The people that are fighting having ULA-C are the same ones that don't want PI, and they are trying to force ULA-C == PI so they can turn that argument around and say 'we told you PI was a bad idea' when there is no way to filter out what would have been ULA-C. I am a vocal supporter of PI and vocal detractor of ULA-C/G. In fact, the first time that ULA-C was proposed, I saw it for what it was (an end-run around the RIRs) and became a PI proponent; before that, I didn't really care either way. Do not stuff words into people's mouths, particularly when they're watching. If you really believe there is going to be a routing system problem, then you absolutely have to support ULA-C because it is the only way to enforce keeping private space private. I believe there will be a routing system problem at some point, and it pains me that I was still forced to support PI anyways because the IETF has utterly failed to produce an alternative that is viable _in the views of the operational community_. However, I do not believe the "problem" will be due to "local" routes at all; it will be due to the massive numbers of legitimate routes that having PI causes. However, without PI, there would be no routes at all because IPv6 would be ignored. PI is, unfortunately, the lesser of two evils. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Eliot Lear" <[EMAIL PROTECTED]> Providing PI to enterprises who move now is a nice bonus, not not necessary in the long run. That comment shows how completely out of touch you are with the enterprise operational world. Unfortunately, that is rather common with the ivory-tower vendor folks commenting in this thread. Even the ISPs in the operational community could _understand_ why PI is necessary, however much they dislike and/or fear it. I should also note that you're commenting from an enterprise that side-stepped the RIR rules somehow and got PI space by pretending to be an LIR. The world must look a little different when the rules you're a proponent of magically don't apply to _you_. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Jun-ichiro itojun Hagino" <[EMAIL PROTECTED]> > Let me see if I understand this. Without PI, the enterprises say > no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. At a former employer, we had POPs in various sites around the globe, each with three to seven ISP connections. We'd typically change out one or two of those ISPs at each POP each year, based on pricing changes, traffic shares, service levels, and general arm-twisting of salespeople. I've seen similar elsewhere with folks I've consulted for: they want at least three providers, and they swap out one per year as the typical three-year contracts expire. In fact, it's been alleged in other fora that multihoming in this manner (i.e. with PI) has become mandatory in the US for public corporations, though I've never seen a citation. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 18-sep-2007, at 17:50, Jeroen Massar wrote: I don't think ULA-C makes sense. We have a RIR system in place. These RIRs are supposed to provide address space for people/organizations who can justify a need for that address space. That's like selling train tickets at the airport. Except for the fraction of a promille of all IP users that have their own portable address space, RIRs don't even talk to IP users who are _connected_ to the internet, let alone those who aren't! It just doesn't make sense to involve the RIRs here. The RIRs talk to anyone who submits the appropriate forms. They'll even help you fill out the forms if you can give them enough information to do so. You could even do it by phone or snail mail if you've been living under a rock and still don't have Internet service. ARIN policy, at least, explicitly allows for direct assignments to end sites even if they're not connected -- just like IANA assigned Class A/B/C blocks to disconnected orgs back in the good ol' days. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ppml] IPv6 addresses really are scarce after all
Thus spake <[EMAIL PROTECTED]> In my experience Ethernet bridges and switches are not designed with security as a goal. When they fail to transmit all incoming frames on all interfaces, it is to prevent segment overload or broadcast storms. There are many cases where people have found ways, sometimes quite simple ways, to receive Ethernet frames that are not addressed to them. Given this backdrop, I am suggesting that a homeowner may have several reasons for inserting routers (and router / firewalls) into their home network, thus requiring the ability to have multiple /64 IPv6 subnets. Architecture aside, this is a pragmatic response to an information security issue. Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO? Sorry, but that's the wrong response to the wrong problem. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake "Keith Moore" <[EMAIL PROTECTED]> Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. That depends on the definition you're using. Many hosts are v6-capable, though I'd still debate whether it's the majority. Very, very few of those hosts have working v6 connectivity because there's some device(s) or provider(s) between the host and the DFZ that are v4-only. agreed, but you were talking about hosts. I do not consider a host dual-stacked, regardless of whether it's v6-capable, unless it can actually talk to remote hosts via v6. That may be imprecise on my part, but it's all that matters in the end. It's humans and software, not hardware, that is generally the problem getting v6 deployed. agreed about humans - mindshare is the hardest thing to overcome. the software/hardware question is a distinction without a significant difference. if the products (you think) you need to secure your network aren't shipping, it doesn't matter much whether what you need is new hardware or a software upgrade. often, that's just a matter of packaging. Ah, but there is a difference. Hardware is purchased in a 3+ year cycle, and generally involves significant capital outlay. Most hardware is v6-capable by this point, though apparently there's still issues in the load-balancer space that are preventing major content sites from dual-stacking. OTOH, v6 software is still not available from the majority of vendors, but if they do release it, it could be a free update (perhaps within the terms of a service contract) and deployed at any time. The distinction is moot, I'll agree, in parts of the market like consumer CPE where the vendors have a history of only releasing new software on new hardware, so a v6 upgrade will require hundreds of millions of people to buy new boxes even though their existing boxes would do v6 just fine if the vendors bothered to release new code for them. There's a lot of focus on NAT-PT for v6 sites to access remote v4-only sites; I'm focusing on the case of v4-only sites using NAT-PT to access remote v6-only sites. that's certainly an important case, but there are better ways than NAT-PT for v6-only sites to provide services to v4-only users. Perhaps. However, every other model I've seen assumes that all of those v6-only sites should pay the cost of making their services v4-accessible. That puts the cost in the wrong place, since it's v4-only sites that should be penalized for being laggards -- not the v6 early adopters, and also assumes that v4 addresses will remain available for them to implement those solutions. In a few years, that will no longer be true. There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. No, the second incentive remains. Fully deploying v6 is still a good idea because it removes the problems inherent to NAT-PT, which I've already acknowledged. yes, but everyone else's NAT-PT boxes still keep you from getting most of the benefit from your upgrade to full IPv6. In the short term, yes. OTOH, if everyone deploys NAT-PT today, then tomorrow it will _appear_ that the entire Internet is v6-capable, and I can convince management that deploying v6 "for real" is worth the effort. Today, there is virtually nobody I can reach with v6, so management isn't interested, resulting in a chicken-and-egg problem. IETF is useless if it doesn't try to describe what will work well in the long term. We all agree on the long-term vision. What we disagree on is what is the best method to get there from where we are today. I think that NAT-PT is no less evil than the v4 NAT we're using now and will get us to a NAT-free v6-only Internet faster than other strategies proposed. The shorter the transition is, the better things will be for all of us in the end. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake "Keith Moore" <[EMAIL PROTECTED]> Stephen Sprunk wrote: Thus spake "Keith Moore" <[EMAIL PROTECTED]> NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: [arguments about NAT-PT avoiding the need to dual-stack hosts deleted] Dual-stacking hosts is a non-problem. For the majority of deployed hosts, it is already done. That depends on the definition you're using. Many hosts are v6-capable, though I'd still debate whether it's the majority. Very, very few of those hosts have working v6 connectivity because there's some device(s) or provider(s) between the host and the DFZ that are v4-only. Even with Vista supporting v6 by default, the vast majority of Vista machines are behind NAT boxes that only support v4. In the case of enterprise networks, the internal network is also v4 only, limited by one or more of hardware, software, and motivation. Many ISPs, particularly consumer ones, don't offer v6 service at all, though that's improving daily and one can work around it with 6to4. Dual-stacking a network, even a home network, is _not_ a non-problem. Adapting existing networks to IPv6 is somewhat painful, but most of the deployed hardware supports it. It's humans and software, not hardware, that is generally the problem getting v6 deployed. On the other hand, adapting existing security policies, traffic filters, network intrusion detection systems, explicit and interception proxies is much harder. In some cases the products or upgrades don't even exist for IPv6, and when they do, they're not mature. So put the NAT-PT device on the outside of those security boxes. Presto, instant access from your v4 network to every v6-only host out there and vice versa, without any compromise of security. There is a compromise of functionality, but it's no worse than what you've got for v4 connectivity because you're behind a NAT for that too... There's a lot of focus on NAT-PT for v6 sites to access remote v4-only sites; I'm focusing on the case of v4-only sites using NAT-PT to access remote v6-only sites. That is the case that's going to go critical in 2-4 years when exhaustion hits. After that, folks can deploy real v6 internally (or even flash cut) when they see that a significant fraction of their outbound traffic is v6 -- or when the slower vendors finally get around to fixing their products. If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. That's like saying that if you are a IPv4 software developer and your applications won't work at your customers' sites because they have NATs, all you have to do is get rid of your own NAT and your customers' problems will go away. That's not the same thing at all. It simply doesn't work that way. NATs create problems even for people who don't use them. Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. I must have ESP (and not the IPsec kind), because I already responded to that point... There are basically two incentives to support IPv6: one is more addresses, the other is a better behaved network that is capable of supporting a wider range of applications at lower cost. If NAT-PT is widely deployed, the second incentive is removed. No, the second incentive remains. Fully deploying v6 is still a good idea because it removes the problems inherent to NAT-PT, which I've already acknowledged. However, the alternative is worse. If you're still stuck on v4 because your vendors and/or management won't allow you to deploy v6, and v6-only sites start appearing, you can't contact those folks _at all_. Connectivity to those sites via NAT is better than no connectivity at all. Do _you_ want to be the first v6-only site on the Internet, unable to talk to 99% of other hosts out there? And, as Phillip says, it's a moot point because vendors are shipping NAT-PT anyways. The IETF can deprecate whatever it wants, but the market will provide what is needed. The IETF hasn't been very successful at eliminating v4 NAT either... S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
Thus spake "Keith Moore" <[EMAIL PROTECTED]> NAT-PT really needs to be wiped off the face of the earth. It provides all of the disadvantages of IPv4+NAT with all of the transition costs of IPv6. Indeed it does. However, it has significant benefits as well: 1) It eliminates the need for all sites to dual-stack their hosts between the time v4 exhaustion hits and the last v4-only site disappears, which could be a decade or more. There's also no sign this will actually happen in time without NAT-PT, leading to fragmentation of the Internet into v4-only and v6-only parts that can't talk to each other. 2) It may eliminate the need to dual-stack entirely; NAT-PT allows a site to flash cut from v4 to v6 without a long transition period. This would provide substantial cost savings to leaf site operators, many of whom are not deploying v6 today due to the perceived cost of dual-stacking. We remember the days of having to manage IP(v4), IPX, AppleTalk, DECnet, etc. all on the same network and aren't looking forward to returning to that mess. 3) Deployment of NAT-PT would instantly provide hundreds of millions of hosts that _appeared_ to be dual-stacked, accelerating the deployment of v6 and bringing forward the day we can turn off v4 in the DFZ (even if individual leaf sites are still v4-only internally). If there is ever any significant penetration of NAT-PT, then the pseudo-IPv6 network will not be able to support any more kinds of applications than the NATted IPv4 does today. In the beginning stages, yes. However, unlike v4 NAT, if one has a problem with NAT-PT and how it affects applications, all one has to do is deploy v6 and they go away. Well, at least those that aren't actually caused by having a stateful firewall... Besides, nearly everyone is behind a v4 NAT today, so things aren't going to get any worse for v4 traffic, and they'll gradually improve for v6 traffic as folks deploy it and start to bypass their NAT-PT devices. All of this "applications for v6 aren't designed to cope with NAT" stuff is bunk. Applications are designed to use both v4 and v6 because there's no market for v6-only apps. Apps have already paid the cost of dealing with NAT (if it affects them) and so will future apps until we can manage to drop v4 entirely. If NAT-PT allows us to drop v4 sooner, it's that much sooner app developers can stop paying that cost, and that's good for everyone. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A new transition plan, was: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
Thus spake "Mark Andrews" <[EMAIL PROTECTED]> You will still see consective addresses with IPv6. Until you put a *dedicated* router at the end of the DSL line or on the cable modem etc. there will still be lots of addresses handed out where the next address is managed by someone else. That's not necessary, though it's the ideal scenario once v4 is dead in a decade or two and it's feasible for consumer-grade ISPs to reorganize their L2 networks. In the meantime, what I've been expecting to see is that ISPs would use a /64 for the "shared" access subnet and then the CPE devices (a stateful firewall) would use DHCP PD to get a /64 for each customer's site. This is entirely compatible with using PA v4 space on the access subnet and having the CPE NAT to RFC1918 space (typically 192.168.1/24). Thanks to RFC 3041, you may never see two connections using the same IPv6 address and have to block a /64 at minimum for blacklists to have any effect. Fortunately, that's entirely compatible with most deployment scenarios, as each customer will be on their own /64 (or shorter). S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-historic-00.txt
Thus spake "Melinda Shore" <[EMAIL PROTECTED]> I have a lot more trust in the simplicity of a basic NAT in a consumer firewall then I do in any firewall which has to examine each packet for conformance to complex policy rules. "Drop all inbound traffic" is complex? AFAIK, there's exactly one consumer CPE device on the market that does IPv6 and it has a configuration option cleverly labelled "Block incoming IPv6 connections" which is checked by default. Perhaps he means Apple is overestimating users' intelligence by giving them a checkbox at all? Leaving it at the default setting is rather complicated, after all... Or perhaps he meant that an IPv4 NAT which has to do stateful packet inspection plus mangling both the packet headers and occasionally mangling packet payloads is less complicated than a IPv6 firewall that just has to do stateful inspection and either drop the packet or forward it without any mangling at all? S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ppml] Can the RIRs bypass the IETF and do their own thing?
Thus spake "Stephen Sprunk" <[EMAIL PROTECTED]> ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. That should be "don't already solve". S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Can the RIRs bypass the IETF and do their own thing?
Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]> Fred, the point is that ULAs should be unambiguous, so that if they happen to meet (e.g. via a VPN, or following a merge of two previously separate networks) there is no collision. Currently ULAs include a pseudo-random prefix, which leaves open a theoretical possibility of collision. Centrally-allocated ULAs would not have this issue. The chance is negligible until you have a number of organizations interconnecting that approaches the AS count on the public Internet. Those who are uncomfortable with those odds can get PIv6 space. ULA Central does not solve any problems that the existing tools already solve, and it creates new problems of its own. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Proposed Experiment: Normative Format in Additionto ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Thus spake "Carl Malamud" <[EMAIL PROTECTED]> As for traditional mathematical notation, I think resorting to it for all but the simplest formulas, e.g. "y =(m * x) + b)", often does a grave disservice to all readers who are not mathematicians. "RFC authors MUST NOT use calculus or matrix algebra. Addition and subtraction MAY be expressed as formulas but authors SHOULD NOT use formulations sufficiently complex to make a reader's head hurt." IMHO, this would be a very good rule; the IETF is supposedly about running code, and complex equations that the average programmer cannot understand without digging up a college math book are unimplementable in the real world. Pseudocode is far, far more valuable than pretty equations. IMHO, a direct result of the above is that any math that cannot be described adequately in ASCII text does not belong in an RFC. This is similar to the view that diagrams that cannot be represented in ASCII art are too complex to be meaningful to the reader. Every time this debate comes around, I am struck by the notion that normative formats other than ASCII are a solution in search of a problem. About the only argument I've read to date that makes sense is to allow UTF-8 to access characters that do not exist in ASCII, such as for authors' names or better line-drawing characters. Everything else seems to fall into the "our specs aren't as pretty as other SDOs' specs" category. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why not PDF: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Thus spake "Julian Reschke" <[EMAIL PROTECTED]> Carroll, Diana C schrieb: I think that whatever format is chosen, file size is an important consideration. If you don't live/work in a major metropolitan area, high-speed Internet connections are not available, and it can take ridiculous amounts of time to download a single large .pdf or .doc file. The IEEE standards are a good example, even on a high-speed connection, downloading a single 200-page document takes several minutes. ASCII is widely used because it is easy to generate, has very small file sizes, and is viewable regardless of operating system or platform. Any successor to ASCII needs to have similar qualities in order to be successful. GIF and PNG files are widely supported, but they also tend to be very large files. At best, if these files are going to be included, they need to be optional. ... -rw-r--r-- 1 jre Kein 313253 Jun 18 20:38 rfc3253.xml -rw-r--r-- 1 jre Kein 406626 Jun 18 20:42 rfc3253.html -rwxr-xr-x 1 jre Kein 160576 Jun 18 20:56 rfc3253.chm -rwxr-xr-x 1 jre Kein 413732 Jun 18 20:56 rfc3253.pdf -rw-r--r-- 1 jre Kein 285569 Jun 19 18:18 rfc3253.txt ...by that measure we'd need to move to Microsoft Compiled Help Format, right? [EMAIL PROTECTED]:~> ls -l rfc3253* -rw-r--r--1 sprunk users 245514 Mar 4 2002 rfc3253.txt -rw-r--r--1 sprunk users 47077 Mar 4 2002 rfc3253.txt.gz CHM files, like PDFs, are precompressed, so that's the amount you have to actually send over a slow dialup line. HTML, XML, and TXT compress very well, so just looking at file sizes is not a fair comparison in most cases. Even if the access line doesn't support compression, hopefully most archives of standards have something similar to Apache's mod_gzip so that the content is sent compressed from the server itself. Still, this is illuminating; I expected the PDF form to be a lot more than 69% larger than the uncompressed ASCII. Still, there's only a few rather simple figures in that example, so it doesn't show how completely bloated IETF specs may get if we allow complicated diagrams in the PDF (or whatever) version but don't require them in a normative ASCII version too. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
t and you're effectively wasting 100% of the address space anyways, so none of this matters until that's gone) This gives us 36 bits = 68 billion /48s. That's several per person inhabiting the earth, and each of those / 48s provides 65536 subnets that have room to address every MAC address ever assigned without breaking a sweat. What happens when MAC addresses go away? How are you providing for the future when you allocate address space based on the past? Why not just leave the address space alone, and allocate only the minimum slice required to handle current requirements? If EUI-64 addresses somehow go away, and there's no sign they will, we already have another mechanism ready for how to assign addresses within a subnet. In fact, it appears it's even the default in the next Windows. If/when it ever matters how much address space we assign to subnets, we already know how to determine the necessary size and assign just that. Until we do need to do that (if ever), we can use the /64 convention without concerns. It's no big deal to change later if needed. In fact, we may end up not using that convention at all once IPv6 is actually rolled out to a significant part of the 'net. That's another problem of engineers: they think they can predict the future, and they are almost always wrong. See above. What was the problem again? And that's the third problem. Remember also: any encoding of information into the address field (including anything that facilitates routing) exponentially reduces the total number of available addresses. So it might look like 2^128 addresses, but in reality it may be 2^40, or some other very small number, depending on how much information you try to encode into the address. Again, the current identifier/location conflation combined with the routing paradigm leaves us no choice but to encode information into the IP address. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Thus spake "Keith Moore" Now of course this ISP does have a T&C that prohibits running a server, but "server" is a pretty vague term, and you don't have to be running any kind of server to suffer from NAT brain-damage. My ISP has ingeniously defined a "server" as any application that does not work through NAT without port forwarding. Bingo, problem solved (from their perspective). Of course, they don't actually enforce this unless a user's upstream bandwidth usage consistently exceeds total POP upstream bandwidth divided by the number of users at the POP (in my case, about 300kB/s). Go above that and you get an email asking you to turn down the speed on your P2P client ;-) p.s. fwiw the workaround in my case was to tell the modem to work in "passthrough" mode and configure my local router to run PPPoE. Under those conditions, I'm happy to report, 6to4 works just fine. Alas, I've been unable to find a consumer-grade router that will run native IPv6, 6to4, or even pass through IPinIP (excluding open-source hacks which are not supported by the vendor -- that's not a solution for real consumers). If anyone knows of one, please let me know off-list. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
d /48 are not the default allocation and assignment sizes, respectively. That is also another convention that we could easily dispense with, but it saves us a lot of paperwork to abide by it as long as it doesn't cause problems. Engineers should build stuff that still works reasonably well even if they get their predictions wrong. Engineers don't like to think that they've left anything out or that they are less than omniscient in assessing what must be done, so many of them are allergic to anything that is simply "reserved for future use." I had the same trouble when I first started in computers, but I grew out of it. The folks who designed IPv4 definitely suffered from that problem. The folks who designed IPv6 might also have suffered from it, but at least they were aware of that chance and did their best to mitigate it. Could they have done better? It's always possible to second-guess someone ten years later. There's also plenty of time to fix it if we develop consensus there's a problem. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PI space (was: Stupid NAT tricks and how to stop them)
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]> > From: "Michel Py" <[EMAIL PROTECTED]> >> We aren't *ever* going to give everyone PI space (at least, PI space >> in whatever namespace the routers use to forward packets) ... >> Routing (i.e. path-finding) algorithms simply cannot cope with >> tracking 10^9 individual destinations (see prior message). > I think you're dead wrong on this. This reasoning was valid with > 10^8 Hz processors and 10^8 bytes of memory it's no longer true > with 10^11 or 10^12 Hz processors and memory (we're almost at > 10^10 cheap ones). The last time I heard, the speed of light was still a constant. And the current routing architecture is based on distributed computation. I.e. router A does some computing, passes partial results to router B, which does some more computing, and in turn passes the partial results to router C. After some amount of this back and forth across the network, the route is eventually computed and installed. Needless to say, the real-time taken for this process to complete - i.e. for routes to a particular destination to stabilize, after a topology change which affects some subset of them - is dominated by the speed-of-light transmission delays across the Internet fabric. You can make the speed of your processors infinite and it won't make much of a difference. Nothing has changed here. The propogation of an individual route is limited by the speed of light (in fiber or copper), yes, but faster CPUs and bigger memories mean that more of those routes can be propogating at the same time with the same or less effect than a few years ago. The IPv4 core is running around 180k routes today, and even the chicken littles aren't complaining the sky is falling. Compare to how many routes were around pre-CIDR and the resulting chaos. Routers have gotten much, much better since then, and in most cases they're using technology 5+ years behind the PC market (200MHz CPUs, SDRAM, etc.). We'd have to seriously screw up to run afoul of today's limits, and the vendors can easily raise those limits if customers demand it (though they'd much prefer charging $1000 for $1 worth of RAM that's too old to work in a modern PC). S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF65 hotel location
Thus spake "lconroy" <[EMAIL PROTECTED]> Seriously, folks, I try to avoid driving on the wrong side of the road, so is there a problem in walking about in this area of Dallas at this time of year? Most major roads in Dallas are divided and/or have heavy traffic, so I wouldn't be worried about driving on the wrong side, but I understand the concern. In any case, the weather is decent in March, but rather unpredictable. It could be anywhere from 40F to 90F on any given day, and rapid same-day temperature changes of 30F+ are not uncommon in Texas. Pack a everything from shorts and T-shirts to jeans and a good jacket. Also, businesses in Texas tend to be excessively air-conditioned, so you may want a light sweater or jacket indoors even if it's 80F outside. In general, that part of town isn't pedestrian-friendly, nor is there anything you'd be interested in walking to other than neighboring hotels. That's safe enough (and just across well-lit parking lots), but I'd recommend against aimless wandering away from the hotels at night. Also, will the Agenda give longer breaks for Lunch? - it would seem that it will take some time to get to an external food joint, eat, and get back. If you have a car, there are dozens of restaurants close enough to eat and return over a standard hour-long break. If you rely on cabs, make sure to arrange for one ahead of time so you'll get back promptly. Or just eat at the Anatole; the place is monstrous and handles crowds ten times the size of the IETF. On 28 Jan 2006, at 18:02, Marshall Eubanks wrote: BTW, the last time I was in Dallas my wife and I walked all over downtown, including over to Dealy Plaza. It was hot, we were the only pedestrians except for some street people (except at the Plaza itself), and we never saw a cab (except at a hotel we went by). Flagging a cab on the street is almost unheard of in Dallas; idle cabs gravitate towards hotels and sit there until called by a dispatcher. The better taxi companies have GPS-based dispatching, though, and you can get a cab in 5-10 minutes in that part of town (email me off-list for numbers if needed). My advice is, if you really want to get around, rent a car. Since the meeting isn't downtown or otherwise near the rail system, I have to agree, unfortunately. However, for those who don't want to or can't rent a car, cabs are an acceptable and possibly cheaper alternative, and are often more convenient since you don't have to figure out the local roads in yet another city. If one isn't particularly in a hurry or is short on cash, there is a train (the TRE) that runs from Ft Worth past DFW airport and the Anatole to downtown Dallas. Dallas Union has decent connections to other parts of the city, but the other TRE stations are inconveniently located (Centreport/DFW Station requires a 20-minute bus ride to/from the airport terminals, and Market Center Station is a half-mile or so from the Anatole). The train fare is a paltry $2.25 for the trip, though, versus about $35 for a cab. S, Dallas resident Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to "consensus"
Thus spake "Sandy Wills" <[EMAIL PROTECTED]> Gray, Eric wrote: "It is much more likely to hear from the very vocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change." While I can't speak for everyone else, this seems correct to me. "Do I have anything useful or enteresting to add?" and "Do I think that my input will change the output?" must both evaluate to "Yes" before I post to any discussion. I occasionally post for humor or interest, but generally I follow the discussion and stay out of it unless I believe it to be going badly awry. I think this thread long ago passed into "badly awry", hence the volume of responses. The current process requires weighing of voices, not weighing of the supposed opinions of the silent. Yes, _but_ anyone who agrees will not argue. You will only get argument from those who disagree with the post. Unless you want to change the culture here to require an answer from every reader, on every question, thus adding significantly to our daily workload. I'd rather not. Very true for the original post, but once one person (or, in the instant case, a couple dozen) has argued with the OP, there is no way to determine which side the silent majority agrees with. It is possible that there are thousands of people agree with Yakov but have cultural prohibitions on backing him, or it could be that there are thousands that don't agree but have no new points to add -- or both. All we can measure are the people who do speak up. Right now it looks like there is a very strong consensus against MS Word as an output format, a weaker one against it as an input format, and no real consensus yet about other options like HTML, OpenDoc, PDF/A, etc. IMHO, the normative output text should remain the ASCII version, perhaps with UTF-8 to allow authors to add a native rendering of their name. Any other output versions should be optional and explicitly non-normative. Input forms should remain the same as today plus optional UTF-8. I think that's about as "progressive" as we'll likely build consensus for any time soon. The bad artwork that this saddles us with is, IMHO, a feature and not a bug. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
Thus spake "wayne" <[EMAIL PROTECTED]> > In <[EMAIL PROTECTED]> Robert Elz <[EMAIL PROTECTED]> writes: > > Anycast does not work (or perhaps more correctly, in some > > circumstances when there is routing instability, will not work) with > > fragmented UDP packets (the size of the packets is irrelevant, only > > whether they are fragmented), when sending those fragments *to* > > an anycast address. > > In order for anycast DNS to fail, either due to the use of TCP or in > cases where the UDP DNS query was fragmented, doesn't the network > routing instability have to be such that retries also fail? A single > failure isn't fatal, after all. The routes would have to be flapping > pretty badly to most of the root servers (anycast or not) for this to > cause any problems, in which case, I think we would be far more > worried about other things. The issue is when a network, usually at neither the client nor server end of the path, uses PPLB such that packets from the same TCP query or fragments of a single large UDP query will consistently arrive at different anycast server instances. The IETF and network operators have long understood that this is a Bad Thing(tm) in general, and is one of a long list of reasons why PPLB is strongly discouraged and sees little use today [1]. > > It is anycast at the root name servers that you seem to be > > complaining about. If the root servers are going fine grained load > > balancing, then it would not only be routing instability that would > > result in a switch of server. I am by no means convinced that even > > that would be any kind of a serious problem for the root servers (or > > those sending legitimate queries to them [...] > > I'm not sure I see any problem at all here, serious or not. Even if a > root server is doing fine grained load balancing, all the packets will > still end up at the destination address, where fragments can be > reassembled and out of order reception can be resolved. Anycast in the face of PPLB has been accepted (by most of us, at least) specifically for the root servers because current queries to the roots do not need to be fragmented and do not use TCP. It appears that Dean is alleging that DNSSEC will cause queries to the roots to be fragmented or to be transmitted over TCP, thus invalidating the exception which allows root server operators to use anycast. While I admit to not having followed the DNSOP list, I've seen no substantiated claims so far that indicate DNSSEC will cause queries to exceed the minimum MTUs for IPv4 and/or for IPv6 [2]. > Right now, it looks like in theory, the use of anycast DNS servers > can't be a significant problem. So far, I have seen no demonstrations > of practical problems. To the best of my understanding, this has been > the state of the debate for years now. If Dean (or someone else) shows that the above problem case will indeed occur in real-world situations, the criticism of DNSSEC and/or anycasting is valid and one of the two needs to be fixed. > This looks like a tempest in a teapot to me. Based on the messages to the IETF list so far, it appears so. For the record, I support a PR action against Dean due to his consistent provocation of flame wars, particularly as they form a long-term pattern of harassment of a particular company or persons. Note that I consider it irrelevant whether his position in this or any past instance turns out to be correct: it's the form, not the content, of his efforts that is the problem. S [1] Many modern routers, particularly ones used in the Internet core, do not even have the ability to enable PPLB, and the places where I've seen it used in the last five years have exclusively been topologies that will always re-merge the balanced traffic further upstream. [2] I have seen misguided operators set MTUs below 200 bytes, but my position is that these people deserve what they get in such cases. We cannot cater to deliberately broken implementations. Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: OFF TOPIC - Bail money for IETF 64?
Thus spake "Lee Mahan" <[EMAIL PROTECTED]> There are a number of states in the US with the same sort of law last I remembered Texas is one Texas law was recently amended to exempt anyone whose official job title includes the word "engineer", regardless of their degrees, certifications, bonding, or registration with the state. Even though I benefit from this change, I disagree with it in principle because there are too many people out there running around calling themselves "engineers" who don't have a clue. If/when there are a non-trivial number of schools offerring degrees in network engineering, systems engineering, software engineering, etc. I (and many others) will be lobbying to have the exemption repealed. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)
Thus spake "Stephen Kent" <[EMAIL PROTECTED]> Boy are you in for a shock when you try to connect to an ethernet with 802.1x. I have yet to do so. I do have the facility on my Mac, but I've never had to turn it on. You need to get out more. Authentication is being built into the NIC cards. At some point in the future it will not be possible for any device to connect to an Intranet without first authenticating itself. It could happen, but then too it might not. It's already happening. There is a large (and growing) number of corporate networks where 802.1x is mandatory -- if you don't do it, you simply can't connect. I've also run into a fair number that require registering MAC addresses (default is to deny or sandbox) due to vendors who don't yet do 802.1x. End-to-end is a great goal, but it doesn't reflect the real world today. Not that it's an excuse to _require_ middleware in protocols, but we need to design with the knowledge that they _may_ exist. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Port numbers and IPv6
Thus spake "Noel Chiappa" <[EMAIL PROTECTED]> > From: Ned Freed <[EMAIL PROTECTED]> Let me make sure I understand you here: > IMAP4 has the characteristic that you often have a huge number > of incoming connections, only a few of which are active at any > given time. Designing servers to accomodate huge numbers of > connections is a bit tricky, but workable: ... > The 65536 limit, OTOH, has to be dealt with by using multiple > server IP addresses, which in turn usually require multiple > interfaces ... > ... that doesn't mean nobody is hitting the 65536 limit imposed by > source port numbers. They are, it causes problems You're saying that there are servers which have close to (or more) than 65K connections to a *single client IP address* (i.e. it may be a NAT, with a number of hosts behind it)? (If a server is talking to a number of different client IP addresses, it can have up to 65K connections to *each*.) That assumes the client is directly talking to the IMAP server. Some servers are behind an "SSL accelerator" such that all connections come from a single IP address, so only 64k clients are possible. Other servers may be behind a webmail application, with the same effect. The number of folks experiencing this has to be pretty low, but it'd be a severe problem for them. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF onsite networks; discussion, cash, knowledge
Thus spake "Pekka Savola" <[EMAIL PROTECTED]> > I agree that the wired drops in each room are probably more trouble > than they're worth, especially considering the fact that the jabber > scribes and other important people (excluding the chairs) are > typically littered all over the room. If wired drops are to be eliminated (and I don't oppose that), then the wireless network reliability needs to be improved to the level of wired connections. As a strawman I would propose: IPv4 unicast coverage of the meeting rooms is mandatory. All other services (IPv6, multicast, coverage of restaurants and bars, etc.) are highly desirable but can be disabled if needed to preserve the mandatory service. During setup, a rock-solid "mandatory service" network shall be deployed first so that roll-back can be achieved quickly if necessary; only after that is working perfectly should the network staff attempt to activate "desirable" services. Having separate networks for "mandatory" and "desirable" services doesn't seem necessary yet, but future experience may prove me wrong. I hope it doens't come to that; if so we really need to look at the deployability of the protocols we're developing. > We should only provide power sockets and a switch port in the terminal > room. Scrap everything else. No computers, no printers, nothing. > Simple and easy. No need for a guard to stand by. Printers are needed; as John Klensin noted, being able to print drafts and other documents helps comprehension of the material. It also keeps people productive when the network is unavailable... > Why do we need anything more? Just so that the IETF tourists can read > their email? Doesn't seem worth the trouble. Let's not forget that the (vast?) majority of IETF attendees are there at the expense of their employers; access to email keeps them in touch and reduces the impact of their absence. Checking in at night from a hotel room isn't enough. > When the meeting is hosted by someone, let's not expect them to > provide the terminal room. I don't think the host should be providing PCs, but IMHO a place to sit with a wireless laptop (and recharge it) and print out the occasional document is underrated. Wired connections for laptops are debatable; perhaps a few tables near the network equipment, but certainly not the entire room. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Excellent choice for summer meeting location!
Thus spake"Dassa" <[EMAIL PROTECTED]> > |> -What kind of small city of such population has a large > |> corporation willing to sponsor an IETF event? > |> -How does making a big event take place in a small town help > |> attendance? > > Large corporations also deal with the regional cities, PR coverage > would still be effective and possibly more positive. I'm not sure > that sponsors would take the location into too much account but > may be influenced by a lower spend. It is an outreach geasture > that may attract interest and additional participation. If the IETF's goal for meetings was to attract the press or general public, that might be a valid point; AFAIK, it is not. A sponsor might find that hotels and meeting rooms may be cheaper in a smaller city, but that has to be balanced against the cost of attendees' flights, availability of venues, and other suitability factors. > |> As for a couple of your propositions: > |> > |> -People usually get paid less outside of large cities > |> because the cost of living is less so I don't see how that > |> has any bearing, other than forcing everyone, including > |> people living in other small towns to travel extra, and > |> certainly guaranteeing that more people have to travel > |> rather than less. > > No, that is the perception that is often quoted and the reason > given but is not always fact. I would normally travel less than > most people working in a captial city. During the meeting, that might be true, but the concern is getting _to and from_ said city. Unless the meeting is held in SJ or DC, it's reasonable to assume that 99% of regular attendees are from out of town. Most major world cities are airline hubs with nonstop international flights; that means most attendees can get there in one hop and the remainder can usually get there in two. For a small city, you are automatically adding another flight to nearly all attendees, and typical airline pricing means flying to a "small" city will double (or more) the cost of tickets. And that's assuming that city even has enough air service to meet the sudden demand; there are places in the US with 100k+ residents that have 150 seats/day (or less) of air service -- assuming they have an airport at all. In such cases, nearly all attendees would end up flying to a major city and then drive down, adding two days to the trip. > The benefit would be those with sub-standard connections would > have the opportunity to participate where otherwise they might > not have the opportunity. Only for those people actually living in that small city, which not statistically likely to include any IETF members other than those employed by the sponsor. However, those IETF members who cannot attend (particularly since you've increased the cost of doing so) might not be able to participate if the venue doesn't have sufficient bandwidth to support streaming the meeting. > It would also assist with focusing on the issue of increasing > broadband uptake and opportunities. It would certainly be a > good PR exercise. It's not the goal of IETF meetings to do PR exercises, nor would one week of demand be enough to convince the local telco or regulators that increased deployment of broadband is necessary. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Conflict of Interest Clause?
Thus spake "Leslie Daigle" <[EMAIL PROTECTED]> > Margaret Wasserman wrote: > > I was thinking more of ongoing contracts... For instance, let's > > say that we contract with Margaret's Meeting Management > > (MMM -- and no, I am not considering a new career :-)) for > > our meeting planning. Would it be reasonable for someone > > who works for MMM to be an IAOC member? Would > > he/she need to recuse him/herself from every decision having to > > do with meetings? > > I think it would be sensible for the IAOC member to resign if > it was a problem. If they didn't resign, and the rest of the IAOC > thought it was a problem, there are recall measures (because it could > be construed as abrogation of IAOC duties). We can require that the IAOC establish rules for dealing with conflicts of interest, and if a member does not follow them (or perhaps does so too frequently) they can be recalled; if that fails, particular decisions can be appealed by the community. IMHO, this is enough. We cannot predict every possible conflict or the most appropriate action in each case -- nor should we try to codify such details in the BCP even if we could. The BCP overall has evolved a tone of general guidance and public oversight, not micromanagement, and that seems appropriate here too. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: As an ISP did you always get the IP chunk you wanted? (was Re: The gaps that NAT is filling)
Thus spake "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> That the affirmation that no RIR has ever refused an IPv4 chunk is wrong, and that its documented here while when it was made no one objected. You see, a user only cares about what he realy gets. A partner of mine was unable to get an IPv4 address in 2 years. Same for chunks. I do not think there is any other need to document why there are NATs and no IPv6. NAT is seen as an alternative to IPv6. While IPv6 should be an alternative to IPv4. In blocking IPv4 XIRs block IPv6. Basic marketing. We do not know why M. Dupont's request was denied by RENATER, nor is the latter an RIR. LIRs may have their own policies which do not match those of their corresponding RIR, and applicants are free to pick another LIR (or become their own) if necessary. There have been no clearly documented cases, AFAIK, where an RIR has denied a request that met with their policy requirements. One may argue that the policies have unreasonable requirements, but those policies were approved by open process involving the community they serve and (for IPv4) based on the global consensus supporting RFC 2050. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Thus spake "Tim Chown" <[EMAIL PROTECTED]> I didn't say that your mother could do this, but given that some amateurs have already modified the Linksys to do v6 then it would not be difficult for Cisco/Linksys to do so in a short timeframe, if they chose to. The interesting question is why Cisco/Linksys has not done so yet. IMHO, this is the single biggest _logistical_ barrier to IPv6 deployment. As for NAT, then v4+NAT dual-stack IPv6 will be very common. I'd be perfectly happy to run IPv6 on my home network, and let my Linksys do 6-to-4 NAT, real 6to4, IPv6 tunnels, etc. as appropriate. Of course, if my monopoly broadband provider were to wake up and offer native IPv6, I'd want real IPv6 connectivity... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: The gaps that NAT is filling
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> I'm starting to be convinced (see recent NANOG discussions) that the operator community isn't all that impressed with the multi6 efforts to make multihoming possible with provider-derived addresses. It looks like the RIR address policy forums will soon face the question of whether to (de facto) allow provider independent address space for end-users. It'll be coming up on ARIN PPML this week (sorry). So _if_ IPv6 PI space is going to be a reality, we should do what we can to limit the damage. The only way to do this is to make it possible to filter out the PI prefixes at least in certain parts of the network without getting in the way of reachability. That's not the only solution -- just the most obvious one. Clearly, if IPv6 PI space spirals out of control like many operators think will happen, we need to find a way to make BGP (and possibly forwarding) performance not dependent on the number of prefixes in the table. There's many ways to skin that cat, and maybe it's time we start looking at that in parallel to the work on multi6 and HIP. Worst case is we'll end up eliminating IP addresses as locators and build another layer beneath IP (and thus transparent to TCP) that actually handles routing, at least in the DFZ. In some sense we already have a foundation for that with MPLS, but we'd need to hack/replace BGP to make the new layer scale across ASes. Or perhaps we'll find a way to route based on ASNs in the DFZ, and the mapping from destination IP to ASN will be made only at the edge of the DFZ. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> Actually in IPv6 you are well-protected against random scanning withough the need for any device in the middle: a /64 subnet is so large, that scanning it is completely infeasible. Now of course someone who knows your address doesn't have to scan, so this protection isn't complete. But for TCP it's entirely trivial to only allow sessions to be set up in one direction. Full stateful firewalling is of course also possible. However, both these options bring back some of the downsides of NAT: in order to make incoming sessions possible, there must be configuration of some sort. IMHO a firewall function, probably stateful, is necessary in nearly all cases. However, this has gotten so mixed up with NAT that many people (even at vendors) don't realize they're different things. With v6 we have the ability to fix this; through some magic function, users should be able to get a PA (at a minimum) subnet behind their local router/modem/whatever and have a decent interface to configure inbound filters, similar to how they can configure evil NAT port-forwarding today. A default filter that rejects packets for services that are generally intended for local use only would probably be good enough for a residential IPv6 router. Other services are either not enabled and/or firewalled in the host anyway, or the user actually wants them to work. (It would be incredible helpful to have all these local-use services in a fixed range of port numbers for easy filtering...) Default filters are a pain, because inevitably they end up blocking something that's useless today but a critical need tomorrow... For instance, my @#%#^& Linksys not only doesn't understand native IPv6 (hello, wake up Cisco!) but it even blocks IP-in-IP packets so I can't use an IPv6 tunnel. At a minimum, vendors should document _everything_ the default filter does and allow the user to disable it if necessary. You don't need to load the gun for them, but if someone wants to shoot themselves in the foot, it's not your duty to prevent them, because they might have a perfectly good reason to. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
Thus spake "Kai Henningsen" <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Stephen Sprunk) wrote on 20.11.04 in <[EMAIL PROTECTED]>: ISTR that the local competition (the one who's laying down cables like crazy, pretty much every time a street is dug up) That's also a major difference; our local competition re-uses the cable plant of the incumbent carrier. Streets being torn up is largely due to long-haul carriers (which mostly lay their own fiber, or swap strands on different routes) putting new fiber down; nobody here lays new copper when there's old copper still available. started with offering ISDN *only* (not sure if they ever changed). Interesting. Deregulation of the local market here happened after ISDN was dead and DSL was starting to appear. Anyway, back when ISDN was rolled out, I was under the impression that the US generally had digital exchanges, and Germany still had lots of pre- digital ones - tone dialling was only just becoming available and certainly not everywhere, whereas from what I heard pulse dialling in the US was essentially dead for a good while. (I have never heard that you can do Caller ID on analog lines over here, either. People who want that use ISDN.) Digital switches had been added long before digital lines were available to customers; the two had little to do with each other. However, one can still find a rural exchange here or there that has an analog switch. Caller ID, Call Waiting, Three-Way and other "extra services" were added to POTS lines here quickly after ISDN was available or even at the same time, so there was little incentive for non-data users to switch to ISDN at all. The failure of ISDN was mostly due to the tariffs not being comparable to two POTS lines since it was viewed as primarily a "data" service. However, even where it was "available" and people tried to order it, telcos found that loads, amplifiers, taps, and other analog cruft had been added to far more lines than commonly thought and getting a pair "conditioned" for ISDN use took much time and money. DSL succeeded largely because it doesn't require conditioned lines (or new phones for the voice part) or changes to the switch linecards. So this says to me that the rollout of the basics here was *later* than in the US - not earlier. But I also remember many tales of woe about battling ISDN standards in the US, and every phone company having their incompatible own. Possibly that had quite a bit to do with the differing results ... It was that each switch vendor had their own signalling, and which you needed to configure your equipment for depended on the particular switch used in your exchange. The NI-1 (for BRI) and NI-2 (for PRI) standards came much later, long after ISDN was effectively dead. No, I don't think it was a question of monopoly. Rather, it looks a lot like the good old OS/2 marketing problem - you *can* market a technology to death. I don't recall ISDN _ever_ being marketed to consumers here; if it was, it ended before the early 90s when I got into telecom. BRIs did (and still does) see a fair amount of use in businesses for WAN backups, and PRIs have finally taken over for voice trunks, though CT1s are still in widespread use since they're cheaper. Whereas here an ISDN line still costs at least twice as much as two analog lines, plus often carries per-minute tolls even for local calls which are toll-free with analog. Well, ours aren't toll-free either way. Ah. Most (all?) US POTS lines have free local calling within their exchange, usually to neighboring exchanges, and in many states (each regulates differently) across entire cities. ISDN subscribers pay tolls for "data" calls and sometimes even "voice" calls regardless of distance, though that may have changed recently in some areas. Long-distance toll rates were also typically higher for ISDN calls, even voice ones, for reasons I've never been able to figure out -- it's a single channel either way. My general impression is that nobody in the phone company business here likes providing POTS. Well, our telcos have tens of millions of POTS linecards already purchased, so why would they scrap all that equipment and convert customers to ISDN for no perceived benefit to either party? Perhaps if we hadn't already recently converted from analog to digital switches (before ISDN was available), the conversion would have been less expensive. Trends show nobody likes buying POTS here either; mobile phones are rapidly becoming the primary phone system, and VoIP over broadband is seing explosive growth for those who aren't ready to give up a landline. POTS is finally dying -- we're just skipping the ISDN step for something better. I should perhaps add that as far as I can tell, the vast majority of DSL is via phone (pretty much none per tv cable - f
Re: How the IPnG effort was started
Thus spake "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> apart from a general analysis confusion between what is a "name" and what is an "address" (which may concern users as well as objects), and an obvious US nexus of the IETF analysed in RFC 3774, which too often leads the debate to be based on US examples only (i.e. on 1/192 of the number of the world's legal cultures and technical and commecial experiences - look at the US only comments on ISDN). But even in the USA each citizen has a SSN. Even in the USA streets are given a name, and houses a nr. The SSN analogy isn't perfect; technically US citizens aren't required to have an SSN, and a million or so do not. Street names and numbers are a perfect example of what we're discussing, though; do you propose that we completely redesign the mail and road system such that people can take their addresses with them when they move? That's exactly what you're talking about doing to IP. The confusion comes from a lack of anlysis of the real world, of a good model that everyone will accept, understand and use. No, you're the only one that's confused. The IETF has a well-defined model and definitions for names and addresses, and you are willfully ignoring those definitions to hide the fact your arguments make no sense. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
Thus spake "Kai Henningsen" <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Michel Py) wrote on 16.11.04 in <[EMAIL PROTECTED]>: I think you missed the point. As of today, IPv6 is in the same situation ISDN has always been: I Still Don't Need. ^ ^ ^ ^ Whereas I have used ISDN for over a decade now, and so have enough Germans that it's been very many years that pretty much every BBS switched to support ISDN. State-supported monopolies have an advantage in rolling out technologies widely before there's enough demand to justify them, solving the chicken-and-egg problem. We choose to put the cost of new technology where (in our opinion) it belongs: on the people that are using it. Different deployment rates (and subsidy rates) result which are appropriate for each culture. I hear you still use 56k Modems in the US. When people switched to ISDN 64k over here, "fast" typically was 14.4k. It's been quite a while since I last used a modem ... 80's tech. ISDN which 10 years ago was supposed to be the digital miracle that would save us from the analog crap and take over the world ... well, over here that is pretty much exactly what happened ... And most parts of the world still don't have analog phone lines, much less ISDN or broadband. 9600bps modems are still futuristic technology in those places. Over here, a standard ISDN line (two channels, three numbers) costs pretty much exactly the same as two analog lines (two channels, two numbers), and always has. Makes for a slightly different cost equation. Whereas here an ISDN line still costs at least twice as much as two analog lines, plus often carries per-minute tolls even for local calls which are toll-free with analog. the majority of phones and dial-up still are analog and now ISDN costs _more_ than DSL or cable for low-end data. That's just ridiculous. But that's the situation in the US... DSL/Cable are significantly cheaper and faster than ISDN, often by a factor of 10x or more per kbps. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
com, jefsey.org, jefsey.net. My email address ([EMAIL PROTECTED]) would work just fine if I were to move to France or Korea; in fact I've used it from France myself and one of the other users in that domain has lived in Korea and Thailand. Worked perfectly, and there was no need for government-issued IDs or mangling of IP addresses. This means that everyone has an address for his web/mail, for broadcasting TV or cognitive radio, etc. You can discuss international agreements, establish treaties on content, on address-back (feed back on an address?) payment authentication, establish usage warranties and insurances, etc, etc. We are in regalian (Government role) business. We already have universal addresses for these functions; SMTP, SIP, etc. all have DNS-based addressing schemes that allow users to keep their identity(ies) with them when they change network-level providers. Obviously there are objections. And these objections are what has to be worked on to sell "IPv6". 0. there is no more way to make money worldwide because I have been given an Excel table to fill. IDs will be allocated by Govs the way they want. What will be paid to RIR, NIR or LIR will be their real service with QoS control. This calls probably for a new economic model. I'm sure if a national govt came to IANA (or an RIR) and asked for a /32 to address everything in their country, and arranged for a national-level routing infrastructure to use those addresses exclusively and efficiently, it would happen. They'd then have 96 bits to do whatever they wanted locally without interference. 1. there is no room enough in /64 as actually (if I understand well) /128 addresses are just /32 addresses extended to /64 with a user subaddress payload. User addresses will probably requires /80 or /96. Less than half in the routing tables. But structuring may permit clever thinking. Enumerating all the humans on the planet only takes 33 bits today, and even with 9 bits for a country code and a few bits for multiple devices per user, we still have nearly two dozen bits left unused. Please explain why you think /80 or /96 will _ever_ be needed to count people. 2. there are much more needs to address virtual objects than just computer ports. So wee need to establish a numeric root of the numbering schemes accessible through the network, to give them an addressing capacity (this is what we called the Uninum proposition) of an unlimited size (their purpose is not necessarily to number network entities, but to number entities which can be reached through the network). They may eventually be supported by numeric names. These addresses will become more and more important as unique lingual and time independent references. But this is another aspects of the changes we needs. Why do you think people want numeric names for things? We already have a textual naming system that meets all of your requirements of unlimited length, country (and often province) identification, use for multiple purposes, etc. Even you state your theoretical numbering system will be conveyed in alphanumeric representation, so why not use the naming system _that already does that today_? We're already seeing a move away from numeric (i.e. address) based phone systems towards textual (i.e. name) based communication systems; we're only a few years away from users not having phone numbers at all, but rather SIP URIs that look the same as email addresses. Users don't like numbers, and they shouldn't be expected much less forced to remember tham, particularly long ones. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: How the IPnG effort was started
Thus spake "Robert Elz" <[EMAIL PROTECTED]> | which is that a large part of the Internet is going | to continue to be IPv4-only. It simply cannot be. Either it dies (or atrophies, which is essentially the same thing), or IPv4 is replaced by something. It is possible that hosts with existing IPv4 connectivity will continue to use it and never upgrade to IPv6 -- only new hosts would use the latter. With NAT, it's possible that many end sites (even new ones) may use IPv4 internally and NAT to IPv6 for external communication. IPv4 is dead. Long live IPv4. No matter what we do, there is not enough IPv4 address space for the core network to use to reach future end sites. Arguably there is not enough IPv4 address space to meet current needs, but we're hiding that problem with the use of NATs. Some places are so starved for addresses they're even using multiple layers of NATs. Good luck figuring out how many IP-connected hosts are really out there now; I doubt it's up to a billion yet, but it'll probably be there soon (and 25% efficiency is the norm for IPv4). The future is obviously bad for IPv4, as it doesn't even have enough addresses for each human on the planet, much less for the dozens of "connected" devices per person that have been theorized. And, of course, those are absurd assumptions (flat routing /28 indeed!) Why mess with /28s? If we're going to mess up routing, we might as well assign /32s to each host and route those. Nope, still not enough addresses. The core network, the part that needs to be able to identify end sites, simply needs more addresses - and there's no way to fake it via layers of NAT, end nodes from any random point on the net still need to be able to indicate that it is my site (forget even about host), and not yours, that they want to contact. That means that we have to have different addresses (identifiers). IPv4 simply cannot last. That's why several years ago we moved from just the IP identifying the host to using port numbers as well (aka NAT). 2^48 hosts is doable, though messy. Oh, and that doesn't include the hosts that aren't talking externally and thus don't use any address+port resources at all... Of course, end user sites could keep using IPv4, and use something like NAT to translate, to whatever the code network is using. And for a while, no doubt some will continue. But why would that do that indefinitely, it makes no sense? The translation is just an extra cost/management burden that they don't really need - after all, all (at least if it is IPv6 that the core switches to), all the end-user equipment that counts already supports IPv6, switching end sites now is easy (and relatively painless). The cost of IPv4 NAT is apparently perceived to be lower than the cost of IPv6 and 6to4. | So, what's the functional difference between: | | - A host which has an IPv6 only address, which it cannot use (without | "borrowing" a global IPv4 address) to comunicate directly with IPv4-only | hosts out on the global Internet. | | - A host which has an IPv4 local-only address, which it cannot use (without | "borrowing" a global IPv4 address) to comunicate directly with other IPv4 | hosts out on the global Internet. short term, of course, nothing. But the former has the possibility, even expectation, of the "borrowing" simply ending, most likely even in the not too distant future (though certainly beyond the end of the financial year, and so way out of scope of many people's thoughts...) The former does have an obvious path to a full IPv6 deployment, but (a) there is a serious "first mover" problem, and (b) the costs of taking that path will be paid twice. Even now, with Windows finally supporting IPv6, it's still tough to find SoHo/consumer FW devices that will pass IPv6 traffic (even tunneled) and many corporations are forced with swapping out every L3 switch they own to get models that support IPv6. There is substantial economic cost to the former scenario over the latter today, even before you calculate the training cost of millions of MCSEs and CCNAs that don't know anything about IPv6 and see no reason to learn. I predict things will continue roughly as they are now, and when the IPv4 space is approaching true exhaustion the prices of PI and PA space will rise so much that it will exceed the cost of converting to IPv6. Then IPv6 will take off, and not before. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
Thus spake "David Kessens" <[EMAIL PROTECTED]> > On Fri, Jun 18, 2004 at 07:28:40PM -0500, Stephen Sprunk wrote: > > While I disagree with Dean in general and also with most of his current > > argument, I think it is a reasonable request that IETF "officials" be given > > an @ietf.org email alias and that those aliases be published for use in > > situations such as this. > > I like this idea (for other reasons) but I am not sure whether this > really addresses this particular problem: Dean's problem is that he sends mail from an open relay, which isc.org's servers block completely (with good reason, sorry Dean). ietf.org's servers apparently don't since we all receive his rants, and presumably isc.org doesn't block mail from ietf.org, so this would solve the immediate problem. > Even if I would have an @ietf.org account, I would still want to use my > anti-spam filters. I just get too much spam and generic accounts like > this are bound to attract an enormous amount of spam. Unfortunately, > the cost of miscategorizing a mail has become lower than the cost of > checking all my mail manually. I don't object to those aliases pointing to systems with content-based anti-spam systems; if Dean's mail looks like spam, individual people could whitelist him without also being subjected to any spam passing through his open relay. Though, of course, the odds are slim any of us would do that. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
Thus spake "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> > I have replied that I do not see the merit to your complaint, and have NOT > asked Rob Austein to change his address, have NOT asked ISC to change their > antispam policies, and have NOT asked SORBS to change ther listings - > having concluded that none of these is the IETF's business. > > (the alternative - declaring that every antispam function of every system > that is used by an IETF participant is a matter for the IETF to have an > opinion on, and possibly work to have changed, every time it causes a > message to bounce or be dropped - is simply not workable.) While I disagree with Dean in general and also with most of his current argument, I think it is a reasonable request that IETF "officials" be given an @ietf.org email alias and that those aliases be published for use in situations such as this. It's probably going too far to require sending mail from those aliases; despite Dean's faults, he's smart enough to use the published alias if he gets a bounce from someone's personal or work address. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Thus spake "Dean Anderson" <[EMAIL PROTECTED]> > These are not proposals to put URI method functionality into domain names, > but to qualify general business types, such as telephone companies, and > mobile phone companies. This is no different from using .museum for > museums and .aero to represent aerospace companies. .aero was a waste of time, as the number of "aerospace" companies is so small that most users won't even realize it's a valid TLD. Ditto for "telephone" and "mobile" company TLDs. These are all far too specialized for the cost of their introduction and use to be outweighed by any benefits to the community as a whole. Now, a single gTLD which would contain SLDs for particular industries might be a worthwhile plan, but adding tens of thousands of gTLDs, one for each industry niche, is plainly not scalable. > So what is the _technical_ problem with having .tel and .mobi TLDs? More importantly, in light of the human problems with that scheme in general, what is the technical benefit of having them? It won't reduce the overcrowding in .com and .net, which IMHO is the only valid reason for adding new gTLDs. Either foo://tel.verizon.com or foo://www.verizon.com/tel is far more expressive semantically than foo://www.verizon.tel. The proposal _loses_ information expressed in the hierarchy: how is a user to know foo.tel, foo.net, and foo.org are all the same company, and foo.com, foo.mobi and foo.aero are a second company with no relation to the first? > A technical problem, for example, would be similar to the problem with > edu.com, which if you recall, was created back in about 1994 or so. > ... > I see no such problems with creating .tel and .mobi TLDs. Of course there is; you risk collisions like tel.com, mobi.com, com.tel, mobi.tel, tel.mobi, etc. With a small, fixed number of TLDs the problem is manageable because most operators will naturally avoid registering such SLDs; each new TLD makes this increasingly more difficult. > It is not the case that URI methods can't share names with TLDs. It would > be fine to have a URI method of, say museum: if you could attach some > sensible meaning to such a method. True, there's no technical conflict, but one must consider the consequences in light of the humans using them. Imagine a world with a "www" or "com" method, or a "http" TLD -- user error would increase exponentially. Users cannot be expected to know why com://yahoo.http has no relation to http://yahoo.com, and we should not put them in the position of needing to unless there is no alternative. > I don't think you understand the proposal for the TLDs. .mobi is not for > mobile _clients_. Its for mobile _Companies_ Equally bad, just for different reasons... .tel and .mobi are exceptionally bad in combination since the two would end up with nearly the same contents, given how the markets are so closely related. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ietf] New .mobi, .xxx, ... TLDs?
Thus spake "Dean Anderson" <[EMAIL PROTECTED]> > On Thu, 22 Apr 2004, jfcm wrote: > > ".tel" and ".mobi" are technically inconsistent propositions. They confuse > > what belongs to the scheme (protocol/application) with what belongs to the > > naming (users group). The same as was ".web" did in 2000. > > ... > > I have to digest the rest of this further, but I would say right away that > if I connect to http://ibm.tel, I'd probably expect to reach the VOIP > portal, where I could sign up for VOIP services from IBM. I'd expect that > a voip connection to tel://ibm.com would get me to the headquarters > switchboard, and that tel://ibm.tel gets me to the VOIP switchboard (ie > VOIP customer service). You're confusing URI methods, protocols, and TLDs disastrously. The "tel" URI method is for dialing using E.164 numbers, e.g. "tel:+18005551212", which will probably be translated to a different URI via ENUM. For telephones using user/domain names, use the "sip" URI method, e.g. "sip:[EMAIL PROTECTED]". There is no need for a .tel TLD, and adding one ignores existing, logical solutions. Likewise, there is no reason for a .mobi TLD; either mobile clients should use the standard "http" method to negotiate the content/format/encoding with servers as needed via HTTP's existing mechanisms, or if necessary a new method/protocol should be defined, e.g. "wap://www.example.com/". S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: DARPA get's it right this time, takes aim at IT sacred cows
Thus spake "Scott Michel" <[EMAIL PROTECTED]> > On Tue, Mar 16, 2004 at 07:09:12PM -0600, Stephen Sprunk wrote: > > When you add in the (assumed) requirements of backwards compatibility > > with existing routers and hosts that don't implement a proposed extension, > > it gets messy real quick. > > The immediate handwave would be "Tunnel it." I'm not denigrating > backwards compatibility, but a lot of good work has relied on tunneling in > the past, e.g., Mbone and v6-v4. I'm currently waiting with baited breath > the day that service providers provide v6-to-v4 as the special case to > v4-only hosts. The Mbone and 6bone are different beasts, as they're about tunneling traffic from capable hosts across an incapable core. In the case of an identity layer between IP and TCP, we would need to be backwards-compatible with non-capable hosts and applications (not just non-capable routers) and so tunnels don't seem a workable solution. > > HIP is a good start, but it's still only a BOF and the involvement is > > nowhere near what one would expect for (IMHO) the most significant > > IETF project since IPv6. > > Must find more copious free time. Must find more copious free time. Ditto... > > While that's certainly interesting in its own right, what I think DARPA (and > > the IETF) is looking for is something between the network and transport > > layers, not something above transport. > > You never know until you submit a proposal what DARPA **really** wants > even after you get through the program-speak. All too true. We do, however, know many of the IETF's needs in the identifier/locator arena, e.g. for Mobile IP and IPv4/6 multihoming. That may be a good starting point to determine what, if any, additional requirements DARPA has. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: DARPA get's it right this time, takes aim at IT sacred cows
Thus spake "Scott Michel" <[EMAIL PROTECTED]> > As one other responder said, there is a need to accomodate different > addressing styles that separate identity from location. I agree with the > sentiment. So, [erhaps it is only necessary and sufficient to extend or > redefine IP's addressing? When you add in the (assumed) requirements of backwards compatibility with existing routers and hosts that don't implement a proposed extension, it gets messy real quick. HIP is a good start, but it's still only a BOF and the involvement is nowhere near what one would expect for (IMHO) the most significant IETF project since IPv6. > Or perhaps it's only necessary and sufficient to design a universal > application-level forwarding layer? (Warning: plug for my own research > called FLAPPS, http://flapps.cs.ucla.edu/) While that's certainly interesting in its own right, what I think DARPA (and the IETF) is looking for is something between the network and transport layers, not something above transport. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: DARPA get's it right this time, takes aim at IT sacred cows
Thus spake "Scott Michel" <[EMAIL PROTECTED]> > If one reads the article with a little more care and not as a manifesto, > DARPA is interested in a protocol suite where static (wired) networks > are a special case. What exists is a network system where the dynamic > (mobile/unwired) network mgmt is grafted onto the static network, > treating the dynamic network as a special case. DARPA wants to > change the way protocols are designed, where the network is primarily > designed for dynamic nodes (and all of the overhead that entails). This sounds to be heading back into the recurring debate about separating locators and identifiers... Too bad it's probably too late to add that into IPv6. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: digital signature request
Folks, I think this thread has deviated enough from its original intent that the best place to continue it is on the ASRG list -- there's no point in bothering the entire IETF with yet another anti-spam discussion. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 25 February, 2004 04:50 Subject: digital signature request > this is a request for this list to be digitally > signed by the list processor. > > to all list members. if after reading this post > you would like the list processor to digitally > sign all posts please say so (and tell the list > owner) so that the level of interest can be > gauged. thanks. > > i'm making this request because i need a way to > positively id the messages from this list. i'm > spending way too much of my time culling spam from > my real email even though i'm employing the latest > spam filtering tools. please give me the one > simple tool i know of that will allow me to > positively differentiate the mail from this list > from all others - a digital signature. > > signing all list messages won't be detrimental to > list recipients not interested. it will however > allow folks wishing to implement anti-spam > measures around digital signatures to do so. > mailing lists often require that recipients > confirm their email address as an anti-spam > measure for the list. please help list recipients > implement their own anti-spam measures by allowing > the list messages to be positively identified. > > to be clear, this is a limited scope spam > solution, but it works. and it will continue to > work provided the underlying cryptography is sound > (unlike many other anti-spam technologies that are > simply clever hacks in an escalating spam/anti- > spam arms race). > > some folks say that there will be no spam solution > as long as email is free. i say there will be no > spam solution as long as you expect anyone to be > able to send email to you without first proving > they are not a spammer. > > part of finding a solution is to revision what > email is. i argue that email can no longer be a > method of unfettered *initial* contact. once that > is accepted then this solution doesn't seem > painful. i suspect that there won't be a solution > until email is seen from this perspective. as > noted above, mailing lists are essentially > adopting this perspective (to better manage spam > on the list side), it would be helpful if they > took an additional small step that would enable > list recipients to better manage spam on their end > too. > > there's no need for a larger web of trust other > than one that is personally maintained when using > digital signatures to defend against the onslaught > of spam. your personal web of trust (a.k.a. your > keyring) is your unspoofable anti-spam whitelist. > this is where the revisioning of email occurs. > instead of email being the way you initially make > contact with an entity, with digital signatures it > can serve as a reliable communications channel > *once* contact has been established. > > my intention is to implement a procmail recipe at > the mail server level. the procmail recipe will > be used to check incoming mail for whitelisted > digital signatures that have been uploaded from > each individual user. > > mailing lists could use the same recipe, no > messages would be handed over to the listserv > software unless it was signed by a whitelisted > signature. again, this won't stop machines from > being compromised but as soon as a machine is > compromised that entity will be *immediately* > notified by their peers. in the case of a mailing > list *many* people will suddenly know who's > compromised and the list can even have a mechanism > that allows a whitelisted key to be removed once > it becomes compromised. this would also serve the > dual function of indirectly alerting the owner of > the compromised host since they will investigate > why they are no longer receiving list traffic. > > regarding whether to utilize inline or mime GPG, i > say use either. the preferred solution will self- > select over time. it is possible to create a > procmail recipe that can handle both methods. > > Two key benefits of this anti-spam technology: > > 1. it works and will likely continue to work > beyond the foreseeable future > > 2. it can be implemented without the consensus, > from the bottom up &
Re: digital signature request
Thus spake <[EMAIL PROTECTED]> > > > apologies to the folks whose comments i'm replying to for > > > not referencing their names (i didn't have the time). > > > > You ask us to take the time to implement a new mechanism of dubious > > value. > > the value in having the list processor sign all posts > is simple. guaranteed identification of the list > traffic for any recipient who decides to verify > signatures. You have yet to demonstrate the problem you are trying to solve even exists. I've gotten over 2700 spams this month, and zero of them have "ietf" anywhere in them, either header or body. Thus, I see no compelling reason for the ietf's list software to sign anything when a simple MUA filter on the Sender: line already achieves 100% accuracy. S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: Propose some information retrieval protocols for Internet
Thus spake "wang liang" <[EMAIL PROTECTED]> > > I believe you are talking about information *indexing* service, > > not "information *retrieval* service" > > DRIS will build the information retrieval infrastructure for Internet, but > not the final search engines. Many intelligent search systems can apply DRIS > as their data source and provide high quality of personal search service. Why do we need DRIS if we already have HTTP/FTP/etc? Put another way, how are HTTP et al insufficient for retrieving information once its location (i.e. URL) has been determined? Your original post presents several arguments against the current crop of search engines and proposes a new distributed search engine system, but this is an _indexing_ function, not a _retrieval_ function. > The architecture of DRIS is organization level-sub country Internet > level-country level-whole Internet level. Can you demonstrate why country-level databases are a technical advantage, other than providing certain governments the ability to restrict the information their citizens can access? > You could find more information about our project in > http://202.114.9.200/English/main.htm > More content will be translated in these days. It appears your site isn't accessible many places outside CERNET/ChinaNet; can you post your papers somewhere with better reachability? S Stephen Sprunk"Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
Re: Tag, You're It!
Thus spake "John Stracke" <[EMAIL PROTECTED]> > Modifying the Subject: line is a Bad Thing; it invalidates digital > signatures. We're never going to get widespread use of signed email as > long as we have pieces of mail infrastructure munging messages to make > signatures useless. Signed email already gets mangled by the ietf mail servers (AFAICT), so what's one more bad idea in the mix? I can't believe this topic is even being debated. Filtering has been a standard feature of every MUA I've used for over 10 years, including my current PDA and webmail systems. IMHO, the problems (listed by others) with this proposal grossly outweigh the complaints of a couple people who refuse to use a modern MUA or can't figure out how to configure said MUA to filter on the Sender header. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME cryptographic signature
Re: Ietf ITU DNS stuff III
Thus spake Dan Kolis: > The general idea surely of the ITU came about exactly in the context of > limited frequencies and power, etc. So, fine. Coordination of this is > reasonable. Well, when a nation makes laws and treaties obliging both its citizens and itself to follow certain rules and standards, the nation expects a certain degree of control over the development of said rules and standards. The structure of the ITU (and ISO) is a reasonable design for that scenario. By and large, compliance with Internet standards is voluntary and self-motivated; this requires (allows?) a very different organizational structure. However, in passing S. 877, the US Congress has for the first time referenced "Internet Engineering Task Force Standards" (Sec 11.2) in a law. For now, it is only as a suggestion to the FTC for rulemaking, not directly mandating compliance, but if this is a sign of things to come... Thus spake Franck Martin > Well to come back to my original comment, is that IETF, IANA and > ICANN by being "individual members" organisations do not have the > front of ITU, which is unfortunate as the Internet is not being done in ITU. > Governments have to understand that and for that dissociate themselves > from the old telco concept... If the Internet _were_ done in the ITU, it would look like the phone system, and we'd still be stuck in the 1970's. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: fun with base stations...
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> > What I'm missing is guidance on how to make use of the available > frequency space in the best way possible. Obviously doing everything on > channel 6 as we saw yesterday (but has changed now) isn't the best > approach. Using the non-overlapping channels 1, 6 and 11 is much > better, but from what little I know about radio and encoding schemes I > strongly suspect that controlled use of overlapping channels would lead > to the best results in situations like these meetings. Testing has shown that using channels 1, 4, 8, and 11 doesn't lead to performance impact either; the minor overlap is not enough to cause packet loss. Should this move to NANOG, perhaps? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: Appeal to the IAB on the site-local issue
Thus spake "Leif Johansson" <[EMAIL PROTECTED]> > Been there. Done that. Didn't work. This vast Moral Majority of the > Site-Locals either don't exist or live entierly behind NATs or other > boxes which prevent them from receiving the call to arms to participate > in the debate. ;-) Or we all just got sick of the bickering and accepted defeat (unlike Tony). For the record, I can't support deprecating site locals until we have something else approved to replace them -- at which point I say good riddance. There are several drafts in the WG to that end which haven't gained any momentum thus far. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: primary purpose of firewalls
Thus spake "Keith Moore" <[EMAIL PROTECTED]> > you know, I'm happy to say that I don't really know enough about Windows > internals (for any version of Windows) to know for sure whether it provides > those facilities or not. my honest guess is that recent versions do provide > them, and that the reason Windows boxes are insecure is because of poor > application implementation more than poor OS implementation. Perhaps. Most "server" applications on any commercial OS run as the superuser, which by its nature can't be contained in the event of a security breach. The obvious next question is, why do most daemons run as superuser, and is there a way to either configure or rewrite portions of those daemons such that they can run as containable "normal" users and still provide 100% of the functionality? I also wonder if such containment even has much use. Generally any sensitive information a hacker wants to capture or destroy will be stored inside the containment area of the hacked application. Containment only protects one application from another on the same machine, while large servers typically have one or more machines dedicated to each application; in many cases containment will only protect the OS from damage while the sensitive _data_ is freely captured or destroyed. > for instance, "doing the right thing" often means being able to > know which applications are enabled on a host, and to decide whether an > application peer has valid credentials, etc. and the firewall simply can't do > that. the app has to protect itself. The biggest problem I've seen in Enterprise environments is that people running Internet-accessible servers (e.g. in the DMZ) often have no interest or motivation to follow security policy; security is secondary to functionality. US DoD defines a trusted system as any system which is capable of breaking your security policy. Placing trusted systems in the hands of people you don't or can't trust (in the normal sense) is a recipe for disaster, IMHO. If you don't trust the owner, you have no reason to trust the machine, and a trusted firewall is the only place left to enforce security policies. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)
Thus spake "James Seng" <[EMAIL PROTECTED]> > The question: smart terminal or smart network? > > I believe in smart terminal. Nothing there suggest you should not run > your firewall or any other filtering software on your end-terminal. > > End-machine are vulnerable? Then fixed the end-machine. It isnt rocket > science. Perhaps it _is_ rocket science, since I have yet to see an OS and suite of applications which are capable of meeting modern productivity needs while providing even rudimentary security. Surely if it were simple, someone would be selling it and get rich... Humans are lazy and cheap. It is significantly easier, not to mention more effective, to manage a single firewall accessible by a handful of highly trained security experts than it is to ensure the security of thousands, possibly tens of thousands, of hosts that are managed by users who are neither skilled at nor interested in evaluating and compensating for application security flaws. End to end is good, and dumb networks are good. But at the edge (by that I refer to all non-transit AS's) it's more cost effective to create a strong perimeter and give up on anything inside that perimeter. Perhaps it's not the strongest solution in the end, but the people paying the bill rarely care. Of course, we all know the oft-quoted figure that 80% of electronic crime is committed by insiders. I'm pretty sure this is a direct effect of the above trend, but corporate types seem to feel punishing insiders after the fact is good enough, and prevention only applies to strangers. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: myth of the great transition (was US Defense Department formally adopts IPv6)
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> > For any particular application and group of users, and in order to > switch over seamlessly, it is necessary that all servers become dual > stack, then clients can switch (without the need to run dual stack) and > after that the servers can drop IPv4. That is one scenario; there are others. > And for peer-to-peer, _everyone_ is a server so _everyone_ has to > run dual stack before it's possible to drop IPv4. Out of curiosity I sniffed my own P2P applications and found that over 50% of the hosts my client tried to contact weren't available, presumably due to NATs, firewalls, or other connectivity impediments. In spite of this problem, the P2P networks work well enough nobody cares about the problem. I conclude, therefore, that as long as a sizable minority of P2P users are dual stack, the majority can safely speak only v4 or only v6. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: authenticated email
Thus spake "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> > I thought I'd try this > > is there any particular disadvantage or centralization of power > implied in me signing this message with my PGP key? > > If not, is there any particular reason that I shouldn't do this all the > time? > > It's not a solution, but is there a downside? Yes. Automated responders, such as Majordomo, don't understand MIME at all, and therefore all the nasty MIME markup confuses them. The problem gets even uglier when you send MIME to trouble ticket systems. On top of this, you have a great divide between PGP and S/MIME, with many clients supporting either one or the other. For instance, my client sees PGP-signed email as a blank message with the original body as a text attachment -- PGP-only clients have similar problems with S/MIME. If I didn't worry about such problems, I'd have my client automatically sign all outgoing email. Of course, I'm not sure whether I'd do it with PGP or S/MIME... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME cryptographic signature
Re: authenticated email
Thus spake "Michael Thomas" <[EMAIL PROTECTED]> > It depends on what you mean by signing. Signing a message in and > of itself ought not hurt anything modulo software bugs, etc. But the > real question is what does the receiving program (MTA, MUA) do > with that signature? At the very least it could verify the signature, > but then what? If it doesn't verify do you drop it? (transitive trust > comes into play, but most likely). Does it do anything beyond that? Well, if you use a score-based anti-spam system, the lack of a signature could "cost" a message a few points, but that's about it. The root problem here is we're trying to define an authentication system without also defining the authorization or accounting systems to use it. > Let me ask something in return: do you think that > just the act of signing mail -- with no trust > roots implied -- could help? It does, at least until spammers start signing their email too. Does my signature on this message make you trust it more than, say, the ten ads you got this morning for Viagra? Why or why not? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking smime.p7s Description: S/MIME cryptographic signature
Re: IMAP v. POP
Thus spake "Dan Kolis" <[EMAIL PROTECTED]> > Lots of users don't like you have to be connected to IMAP to do > routine things fulltime. > > If your paying by the minute for CDMA2000, (for instance), getting > frozen out of doing anything when your not connected turns people off. Perhaps those folks should use an implementation that can manipulate mail offline and then sync with the server later. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Thus spake "Eliot Lear" <[EMAIL PROTECTED]> > 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. I've dealt with many companies interconnecting where both use RFC1918 space -- NAT is the first thing discussed. You forget, these people are connecting for a _business reason_ and there is real money to be lost if they mess up. It's a totally different engineering model than the public Internet. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Thus spake "Christian Huitema" <[EMAIL PROTECTED]> > The specifics of the site local issue should be debated on the IPv6 WG > list, not on the global IETF list. Let me however respond to your point > regarding the quality of the debate, as I was the note taker during that > session. Issues most often move to the IETF list when a vocal minority object to a declaration of consensus by the WG chairs. If the WG chair would like to reopen the debate, I'm sure everyone will move back there. > In short, it was not a hasty discussion, there was an informed debate, > opinions evolved during the discussion, and a consensus was reached. I > believe that if you had been in the room you would feel closer to that > consensus. I haven't seen anyone argue in favor of site-local addressing for the purposes of having explicitly scoped addresses, so you are correct in one sense. What I am seeing is debate over private address space and NAT, which many of us had expected site-locals to be useful for -- this email thread (and the one on routing-discussion) belies any claims of consensus on that. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: Fw: Welcome to the InterNAT...
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? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking
Re: DNSEXT WGLC Summary: AXFR clarify
Thus spake <[EMAIL PROTECTED]>: > On the other hand, if Olafur is in fact making a living doing BIND9 > development and coding for ISC or one of their clients, that might be > called a "conflict of interest" when the issue at hand is that a specific > document is "too BIND9 specific". > > Personally, I'm OK with Olafur making money doing BIND. I'm even > OK on him possibly making more if the draft becomes an RFC in its > current state. I admit I've looked through RFC2026 and found > nothing about disclosure of conflict of interest(*). That Olafur has been paid for BIND work is obviously public knowledge, so no disclosure is necessary. Most, if not all, IETF and IESG members have some conflict of interest due to past, present, or future employers. Thus, the question at hand is if this disqualifies the IESG from making decisions they've been tasked with making. Pragmatically, how are we to find competent people who _aren't_ tainted in some way? IETF tradition (policy?) is that members are individuals and not representatives of their employers; IMHO that implies that we are to trust the professionalism of our members -- and especially the IESG -- to act in the interests of the Internet community. S
Re: namedroppers, continued
Thus spake <[EMAIL PROTECTED]> > Authentication: Yes, you seem to be Jeffrey Dahlmer. > Authorization: You say you'd like to borrow a steak knife? > > Usually clears up the confusion in all but the most sluggish mind.. ;) That's a very clear example, thanks. > However, "authorization" usually implies "authentication" beforehand. > Does anybody have a reference on an authorization scheme that > doesn't imply any authentication? In a sense: the IETF lists (and most others) use a null authentication method, i.e. you trust whatever is in the message. After that (null) step, we apply weak authorization, i.e. whether the sender is on the approved list. I've seen lots of proposals to improve the former-- hardly difficult -- but none for the latter. Perhaps using precise terminology will help focus efforts in the right area. S
Re: namedroppers, continued
Paul Vixie wrote: >> - many ISPs won't let you forward or submit mail through someone >> else's SMTP server, even if you have permission to do so. so you >> can't forward your mail through your "home" ISP's mail server to >> allow the "mail from" check to work. > > in that case you'd be wise to not insert a MAIL-FROM MX for your > domain. The vast majority of users do not have the ability to make that decision. The curious thing is that it is in an ISP's best interests _not_ to implement this draft, since doing so will likely mark nomadic users' email as suspect and potentially lose a customer. Most companies only support the "public good" to the extent it doesn't cost them any revenue. S
Re: namedroppers, continued
Vernon Schryver wrote: > It's been years since it was possible to be amused by the number of > people who assume that spammers are more ignorant and less competent > than they are, and so propose spam "solutions" predicated on spammers > being unable to register as many names, keys, identities, or whatever > as needed or as many as everybody else can. The problem I've seen repeatedly, including in an off-list discussion I'm having about this topic, is people confusing authentication with authorization. Even if you can authenticate every sender of every piece of email, that gains us virtually nothing -- not to mention it's a reasonably well-solved problem, e.g. PGP, S/MIME. As Vernon notes, spammers can create authentic credentials just as easily as anyone else. The devil is in determining what senders are authorized once we've authenticated them. My fear is the only effective solution may turn out to be closed lists with permission grants, such as the IM services introduced to keep spammers out. That will greatly reduce the utility of email. S
Re: naming debates
Thus spake "Mark Harris" <[EMAIL PROTECTED]> > Being relatively new to IETF discussions... > > I have a few questions concerning your comment: > > When over a dozen people make comments of interest, regarding a topic on the > list, would it not seem that some people are not tired of it? > > What is the process, within the IETF, if a group sees interest in pursuing a > topic, while not burdening others, like yourself? The IETF is organized into WGs that deal with individual issues; by your argument, all of the WGs should conduct their business on the main IETF list. Clearly this doesn't scale. There are lots of DNS lists out there, and this argument certainly isn't new. I apologize for wasting everyone's bandwidth/time this round and won't continue to do so; I hope others follow suit. S
Re: new.net (was: Root Server DDoS Attack: What The Media Did Not Tell You)
Thus spake "Einar Stefferud" <[EMAIL PROTECTED]> > In case you have not noticed, one possible solution is to eliminate all > TLDs other than .COM, which is the only one that you say so may people > believe exists. > > At which point someone will notice that all addresses have a > redundant .COM (because all the other TLDs have been removed, and > so the browsers and mail systems will offer to append (or just assume) > the redundant .COM suffix for you, and voile!... No, keep the ccTLDs and let each country do with them as they wish. Most countries have a hierarchical namespace within their ccTLD, though a few are flat. Either way, I'll take 250+ flat namespaces (ccTLDs) over one flat namespace (the root). COM is a failed experiment and needs to be closed and/or eliminated. > All all solved for the minor cost of forcing all non .COM domain name > owners to find and register a new non-colliding domain name under > .COM! While international trademark law is a joke at best, each country does have a framework in place which can be used to resolve conflicts within their own ccTLD. This is a lot easier than trying to manage a single global namespace using the WTO's trademark "rules". S
Re: new.net (was: Root Server DDoS Attack: What The Media Did Not Tell You)
Thus spake "Eric A. Hall" <[EMAIL PROTECTED]> > on 12/2/2002 11:13 AM Stephen Sprunk wrote: > > > Okay, so when every foo.com. applies to become a foo., how will you > > control the growth? > > 1/ no trademarks allowed Every combination of characters is trademarked for some purpose in some jurisdiction. If you find some exceptions, I'll find some VC money and take care of that; problem solved. > 2/ competitive rebidding every two years IBM is not going to like potentially losing IBM. every two years to someone with more cash. VeriSign's customers *really* won't like every registration under VERISIGN. going away if VeriSign loses a bid. > 3/ mandatory open downstream registrations (no exclusions) A hierarchy without any kind of classification? That just means everyone will register their under every possible TLD and we'll get a million copies of the same flat namespace. Look at COM. vs NET. today, most SLDs from one exist in the other, and VeriSign even offers a package where they'll register your SLD in every single TLD that exists for one price. > 4/ high entry fees Well, that'll certainly be needed, since the root registrar will need a few hundred DNS servers to handle the volume of new queries in the root now that you've made a flat namespace. > > IMHO, the only solution to this problem is the elimination of gTLDs > > entirely. > > There isn't enough demand to support more than a few dozen popular TLDs. Au contraire. There are several dozens of popular ccTLDs, but only one popular gTLD (out of what, 9 now?). > Generic TLDs are user-driven, with the market deciding which ones they > want to use. Geographic TLDs are completely arbitrary and favor the > functionary instead of the user. That depends on the local functionary. Many ccTLDs are completely free to residents of the respective country. And every one I've worked with has better customer service than the registry for COM. S
Re: new.net (was: Root Server DDoS Attack: What The Media Did Not Tell You)
Thus spake "Joe Baptista" <[EMAIL PROTECTED]> > I disagree. The current arrangement of increasing registrars looks alot > like a multi level marketing scam. Basically the goal is to squeeze every > penny out of the dot.com universe. It' don't wash. > > Users want *.choice in their tlds. The whole idea behind tlds are to > establish simple nameing conventions which give users of domains > an internet precense. unfortunately there's not much choice in the > existing USG root infrastructure. Users are by their nature creative when > it comes to naming concervtions and i'm sure they would have more fun in > the alt.universes then they do in the USG system. Unfortunately the USG > is not very creative in this regard. I'm not sure it's been demonstrated anyone other than the _registrars_ actually want more gTLD's. biz and info have been up for quite a while and I can only think of one web site I've been to in either of them. Despite the heated arguments and bureaucratic infighting, demand simply hasn't materialized when we increased supply. End users expect everything to be in .com, period (no pun intended). I still get multi-year Internet users (admittedly of the AOL variety) who don't believe my personal email address in .org is real -- they've never noticed anything but .com and .net out there, and they're confused enough about the minor difference between those two. They don't need another few thousand TLDs. S
Re: trying to sweep namedroppers mismanagement under the rug
Thus spake "Dean Anderson" <[EMAIL PROTECTED]> > I would agree the problem is solved if Bush adds the proper addresses to > the approved subscribers list, as publicly requested. > > But since it has taken so much discussion to arrive at that solution (and > I'm not sure we have yet), list management is clearly a problem, and has > been a chronic problem. List management is not a problem; there is a policy statement and it is followed. If individuals refuse to follow the documented process because they wish to be a martyr, that is not the IETF's or IESG's problem. If someone has a problem with the process, that needs to be directed at the IESG in a general form, not as a personal attack against a list maintainer as long as said maintainer is following the IESG's policy. S
Re: new.net (was: Root Server DDoS Attack: What The Media Did Not Tell You)
Thus spake "Marc Schneiders" <[EMAIL PROTECTED]> > Since .com was running _on_ the root-servers.net until recently > without problems, what are we talking about? > > Naturally there won't be 1 million TLDs all at once. We could start > with a couple of hundreds. That would merely double the size of the > root. Okay, so when every foo.com. applies to become a foo., how will you control the growth? What is to keep the root from becoming a flat namespace within a few weeks? It won't take long for the masses realize that an SLD is not as prestigious as their own personal TLD... IMHO, the only solution to this problem is the elimination of gTLDs entirely. S
Re: namedroppers mismanagement, continued
Thus spake "Michael Froomkin - U.Miami School of Law" <[EMAIL PROTECTED]> > I have just run into an example of this (POISSON) when I was unable to > find the archive. I was surprised -- and puzzled. Surely the storage > costs for archiving ALL IETF lists, especially in their spamless form, > can't be that great? What sort of volume are we talking about ? Depends on the list; the main IETF list is over 1.5MB/mo in my personal archives. Given that the WG lists are maintained by volunteers, it would be a significant cost to provide several years of archives out of the list maintainer's pocket, especially when you add in the trolls and spam which are not part of the list's relevant content. > > 2. The volume of spam in a bounced-messages archive would quickly > > change your mind. > > Here, you could well be right. But would that have to be held beyond the > life of the group? If you consider the bounced messages to be legitimate content worth archiving, then their archive should be kept as long as the non-bounced archive. > > 3. All of this would be easily solved by someone (e.g. IETF secretariat) > > providing list service for all WGs with a consistent policy. > > Agree. But I'd like to also suggest that part of this policy is keeping > the (unspammed) archives around, if only for the sake of people (like > me) who try sometimes to write the history of decision-making in some > of these areas. I agree. I've petitioned several times for centralized lists and archives, and have even offerred to provide them free to all WGs, but so far the IESG has taken no action. My guess is there's nobody we all trust to be such a central manager -- right now one of the IESG members is being accused of list mismanagement. S
Re: namedroppers mismanagement, continued
Thus spake "Keith Moore" <[EMAIL PROTECTED]> > > The list moderator asked him to add his email address to the list, and > > indicated that as a result of doing so his mail would be unmoderated. Is it > > so hard to do? > > frankly, it's ridiculous to expect people to subscribe to every list to which they > wish to contribute. Frankly, it's ridiculous to expect either (a) all WG members to receive dozens of spams per day due to no filtering, or (b) the WG chair to read and manually approve any emails (among the dozens of spams) which are relevant. We have the least-bad technical solution in place today. We'd all like open lists, but the community's inability to control spam has made that a moot point. S
Re: namedroppers mismanagement, continued
Thus spake "Keith Moore" <[EMAIL PROTECTED]> > > isn't moderating the list randy's perogative as WG chair? > > excluding relevant input is not the perogatie of the chair. I've seen no claims to date that Randy has dropped any posts from anyone who has followed the documented process. If DJB refuses to follow the opt-in policy for namedroppers, it is not the IETF/IESG's problem -- it's DJB's. I think it was an error in Randy's judgement for him to have manually forwarded some of DJB's posts; he should have dropped them all until DJB chose to follow the process like everyone else on namedroppers. S
Re: namedroppers mismanagement, continued
Thus spake "Michael Froomkin - U.Miami School of Law" <[EMAIL PROTECTED]> > [cc's trimmed] > > Regardless of the specifics of this case, I think a good rule would be to > say that all bounced messages on any IETF list MUST be archived on a > separate 'bounced' list. To whom would this suggestion best be directed? 1. Many WG lists themselves aren't archived, but you want to force bounced messages to be? Are you ready to pay for this? 2. The volume of spam in a bounced-messages archive would quickly change your mind. 3. All of this would be easily solved by someone (e.g. IETF secretariat) providing list service for all WGs with a consistent policy. S
Re: Root Server DDoS Attack: What The Media Did Not Tell You
Folks, please don't feed the trolls. S Thus spake "Joe Baptista" <[EMAIL PROTECTED]> > let put this back in public. You've made a very good point. > > On Mon, 25 Nov 2002, [ISO-8859-1] Mns Nilsson wrote: > > > So why are you using a real domain name for email? Try eating your own dog > > food and don't bother the rest of us. We have a working Internet to run. > > Backward compatibility. It's as simple as that. Now if the ietf is will > to resolve .god on their mailservers I would be pleased to start posting > with [EMAIL PROTECTED] We could call it a test of some sort. Should > we vote on that. I'm all for it. > > regards > joe baptista > >
