Fwd: Re: Visa for IETF meeting
Email below is from Mr. Sang Yoo, in the visa office of the Korean consulate in Washington DC. It should put to rest the question of visas for the upcoming IETF meeting in Seoul. Gene Gaines [EMAIL PROTECTED] This is a forwarded message From: ¹Ì±¹ <[EMAIL PROTECTED]> To:[EMAIL PROTECTED] Date: Tuesday, January 13, 2004, 4:55:40 PM Subject: Visa for IETF meeting for MR. YOO =Original message text=== Hi, Mr.Yoo said that you don't need visas for the conference and can stay up to 30days in Korea. But he pointed out one wrong thing in your email. That is the following. You wrote; - This applies only to private U.S. citizens. Government employees and citizens of other countries need to contact their local Korean embassy for a determination in their case. Ken, in your case, if you are a government employee, you will need a visa. But the right information is that it applies to all U.S.citizens. And even though when government employees go to Korean for official purpose, then they need official visas. But when they go to Korea just for tour or non-profit conference, they don't need visas. If you have more questions, then please write us back. Thank you. -- [ ¿øº» ¸Þ¼¼Áö ] -- º¸³½ »ç¶÷ : "Gene Gaines" ³¯Â¥ : 2004-01-13 06:15:07 Á¦¸ñ : Visa for IETF meeting for MR. YOO Sang Yoo, Thank you for speaking with me today. I described what you told me in the email below, sent to the email list used by the people that will be attending the Internet engineering meeting in Seoul 29 February - 5 March 2004. Gene Gaines President Gaines Group Sterling, Virginia [EMAIL PROTECTED] 703-433-2081 COPY OF MESSAGE SENT BELOW From: Gene Gaines <[EMAIL PROTECTED]> To: Ken Hornstein CC: [EMAIL PROTECTED] Date: Monday, January 12, 2004, 3:18:21 PM Subject: Visa for South Korea =Original message text=== Ken, As it happens, I attended a dinner Saturday that was addressed by Ambassador Han, the Korean Ambassador to the U.S. Taking up the Korean visa issue today, I spoke with an official in the Washington DC visa section. I believe I can state the visa regulation as it applies to U.S. citizens. - Individuals traveling to Korean to attend the IETF meeting do not need a visa, as they are traveling to attend a non-profit conference. They can stay in Korea up to 30 day for such purpose and for tourism. - If you travel to Korea for business purposes, such as meeting customers or other business purposes, then a visa is needed. - This applies only to private U.S. citizens. Government employees and citizens of other countries need to contact their local Korean embassy for a determination in their case. Ken, in your case, if you are a government employee, you will need a visa. - Another consideration concerning visa. People attend IETF meetings as individuals, not directly representing their company -- and clearly a private individual traveling to attend a nonprofit technical meeting clearly does not need a visa. Warning. I am only relaying what was told to me today by a responsible embassy official. I am not attending the Seoul meeting, but if I was, I would want to have an official statement from an Korean official regarding the visa request. One official who can handle such a request at the visa section in Washington DC is Mr. Sang Yoo. I am copying this email to him. A member of the meeting committee might want to put a formal query to him, and email his answer to the list. For Mr. Yoo, details of the meeting: 59th IETF Meeting, Seoul, South Korea, 29 February - 5 March 2004. For information about the IETF (Internet Engineering Task Force) see: http://www.ietf.org/overview.html Gene Gaines [EMAIL PROTECTED] On Monday, January 12, 2004, 12:12:27 PM, Ken wrote: >>I d be interested in answers people get from other consulate/embassy >>staff both from locations other than Boston and with different >>phrasings of the question. > Well, I finally was able to talk to someone at the Washington, DC, embassy. > Their answer? "We re not sure, but you might need one". -- snip -- > --Ken -- ==End of original message text=== -- Gene [EMAIL PROTECTED] Embassy of the Republic of Korea http://www.koreaembassy.org ==End of original message text=== Hi, Mr.Yoo said that you don't need visas for the conference and can stay up to 30days in Korea. But he pointed out one wrong thing in your email. That is the following. You wrote; - This applies only to private U.S. citizens. Government employees and citizens of other countries need to contact their local Korean embassy for a determination in their case. Ken, in your case, if you are a government employee, you will need a visa. But the right information is that it applies to all U.S.citizens. And even though
Re: Death of the Internet - details at 11
At 18:39 13/01/04, John C Klensin wrote: --On Tuesday, 13 January, 2004 15:41 +0100 jfcm <[EMAIL PROTECTED]> wrote: Gentlemen, let agree IETF is lacking formal interfaces with the real world of users and the real world of operators. John Klensin's official participation to the ICANN BoD is a first good step towards formal links with operators. Sigh. Whatever that relationship constitutes, "formal links with operators" isn't one of them -- there are even fewer actual operators represented and actively participating in ICANN than there are in IETF. Please, at least, get your facts right. Sigh. When will you think in network users terms? In the operator - designer - user scheme I discuss, the operator (whatever the layer) is someone who operates something the user uses. These people ICANN claims to gather (and is partly doing). If this is the way you think, oh, Boy! we better off to subscribe directly to ITU. Thomas, I understand your martyrdom with ICANN. jfc
RE: Death of the Internet - details at 11
> From: John C Klensin <[EMAIL PROTECTED]> > ... > (1) As others have pointed out, the knowledge/skill level of a > typical ISP seems to be on a rapid downslope with no end in > sight. ... > ... > * The difference between those "business rates" and > whatever you are paying are mostly determined by a "what > they can get away with" mentality -- we know what the > marginal operational costs are. If those prices stay > high, it is either because there is no alternate > provider, or because there is (illegal) price-fixing > going on, or because no one sees a business opportunity > by operating a business service at a lower margin. The second segment seems to ignore the implications of the first segment. The marginal cost difference between "business" and "residental" is zilch only if you have the same people running things and interacting with customers. Front line tech-support droids that are dumber than the Windows boxes of residential customer cost a lot less than humans. If your front line support people know have a clue about the LSRR IP option, then either your rates are higher than $30/month or you have customers like us who do most of our own support (and cost our employers or ourselves a lot more than $30/month for that support). > Many > of us can remember when the solution to "no viable > Internet dialup service" was "go form a consortium with > a few friends"... There are some surviving ISPs that were started and still run that way least in geographical areas I know about. Their prices seem to be higher than the organizations in that race to maximum stupidity. It is not a coincidence that they have very few internal spam problems. They are never blacklisted, not even by the second tier spam blacklists, even when they rent straight modem dial-up ports. (Third tier DNS blacklists are kooky 32-bit random number generators.) > perhaps it is time to do something > similar with DSL. I know people who have done that sort of thing with DSL and 802.11. However, I fear that idea is generally killed for now by the fact that IP bandwidth pricing is set by those outfits racing for ultimate stupidity. They see IP bandwidth as a loss-leader. > Or maybe we would rather whine than > do something, perhaps because what we have been fed is "good > enough". Until people like the individual complaining here that his cable-modem is listed as a dynamic address are willing to pay for the costs of real IP service, including the costs of doing more against your spamming customers than asking blacklists to list your own addresses, there's not much hope. We could accept the fact that people who are not willing pay more than $10-30/month are not interested in the Internet and stop listen to their whining. Detroit laughs as people who expect to get Mercedes for Chevrolet prices. Why can't we laugh at people who expect to get real IP service for $10-30/month, or least stop taking their demands literally? If cable-modem IP is good enough for you, then you're not interested in multihoming or even running your own VoIP system. You might be happy to have your phones connected to the email and web browser demark/appliance maintained by your telco/cableco, but you're not really interested in the Internet. You lack the interest to be allowed to run your own servers for anything. Vernon Schryver[EMAIL PROTECTED]
Re: Death of the Internet - details at 11
"J. Noel Chiappa" wrote: [..] > (Yes, I know, "the support situation has improved and we expect wide-scale > deployment in the next year" - I think I've heard that same mantra every year > for the last N years. I really ought to go back through my email folders and > create a web page of IPv6 predictions. In fact, I think that's a good idea - > it will help make plain how hollow such claims are. My task for today! :-) Not trying to be facetious, but it would be useful to supplement this with a list other technologies that didn't taken off and reach world-dominating acceptance within 10 years of being partially spec'd out. Then note their ultimate market penetration/impact. cheers, gja
Re: Death of the Internet - details at 11
John C Klensin wrote: Noel, I'm slightly more optimistic along at least two other dimensions... ... (2) The "no servers unless you pay business rates", and its close relative, "you don't get to run VPNs, or use your own email address rather than ours" nonsense you and many others are experiencing is sort of an old story. In a competitive market, it is also a pretty simple matter of economics: * You don't "want" the server and address capability enough to pay for it, because you consider it excessively more expensive than the cheap "client" service. I go ahead and pay for it, both because I have a higher perception of need and because it is still lots cheaper, and offers better performance most days, than a dedicated DS0 from any plausible ISP I've been able to find. That's a specious argument; you declare it nonsense that ISPs charge business rates, but you admit that's what they do, and in fact endorse it by paying those rates. * The difference between those "business rates" and whatever you are paying are mostly determined by a "what they can get away with" mentality -- we know what the marginal operational costs are. If those prices stay high, it is either because there is no alternate provider, or because there is (illegal) price-fixing going on, or because no one sees a business opportunity by operating a business service at a lower margin. Or because it will cut into their "business" business, which is more to the point. The telcos are maximizing a pair of profits - business and consumer, not just consumer. The difference in rates is their attempt to create two markets, with the simplest amount of effort on their end. These arguments could be used to justify any status-quo. Some economics environments evolve because of a shared perception, whether that perception is complicit or not. Joe
RE: Death of the Internet - details at 11
--On Monday, 12 January, 2004 22:03 -0500 Noel Chiappa <[EMAIL PROTECTED]> wrote: ... IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's just not enough better to make it worth switching - and you can flame all day about how NAT's are preventing deployment of new applications, but I can't run an SMTP or HTTP server in my house because my provider blocks incoming SMTP connections unless I pay for business service, and I personally find that a lot more problematic than the limitations of NAT. IPv6's only hope of some modest level of deployment is, as the latter part of your message points out, as the substrate for some hot application(s). Somehow I doubt anything the IETF does or does not do is going to have any affect on whether or not that happens. Noel, I'm slightly more optimistic along at least two other dimensions... (1) As others have pointed out, the knowledge/skill level of a typical ISP seems to be on a rapid downslope with no end in sight. There are lots of ways in which that is not surprising, but the only realistic solution for someone who needs high reliability in that environment is multihoming, and there seems to be no hope for multihoming of small-scale networks with IPv4. The bad news, of course, is that the IPv6 multihoming ideas that don't cause immediate routing catastrophes seem to be about as ready/ mature/ deployed today as they were a decade ago, which is to say... Not. And that _is_ an IETF problem. (2) The "no servers unless you pay business rates", and its close relative, "you don't get to run VPNs, or use your own email address rather than ours" nonsense you and many others are experiencing is sort of an old story. In a competitive market, it is also a pretty simple matter of economics: * You don't "want" the server and address capability enough to pay for it, because you consider it excessively more expensive than the cheap "client" service. I go ahead and pay for it, both because I have a higher perception of need and because it is still lots cheaper, and offers better performance most days, than a dedicated DS0 from any plausible ISP I've been able to find. * The difference between those "business rates" and whatever you are paying are mostly determined by a "what they can get away with" mentality -- we know what the marginal operational costs are. If those prices stay high, it is either because there is no alternate provider, or because there is (illegal) price-fixing going on, or because no one sees a business opportunity by operating a business service at a lower margin. Many of us can remember when the solution to "no viable Internet dialup service" was "go form a consortium with a few friends"... perhaps it is time to do something similar with DSL. Or maybe we would rather whine than do something, perhaps because what we have been fed is "good enough". And, of course, if enough of those sorts of things happen, it starts to put pressure on the address space, and that means IPv6 unless someone comes up with another viable alternative _really_ soon. No, that doesn't make me a lot more optimistic. But some... john
Re: Death of the Internet - details at 11
On 1/13/2004 1:24 PM, Joe Touch wrote: > Eric A. Hall wrote: > Other than conserving addresses, NAT "features" are basically poison > resold as bread. Heck, I don't even like the conservation feature. Misguided allocation policies created a false demand. We would have been better off to run out of addresses than to let gateways 'rescue' us from our false shortage. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
On Tue, 13 Jan 2004 10:46:17 PST, Paul Hoffman / IMC <[EMAIL PROTECTED]> said: > At 12:48 PM -0500 1/13/04, [EMAIL PROTECTED] wrote: > >On Tue, 13 Jan 2004 07:21:53 EST, [EMAIL PROTECTED] (Mike S) said: > > > > > As I said, fascist. > > > >Godwin. > > Valdis, you have confused two protocols that produced similar results > but used different underlying transports and different signalling. Call it a pre-emptive first strike. Rate we're going here, it'll be Godwin time soon enough ;) pgp0.pgp Description: PGP signature
RE: Death of the Internet - details at 11
Tony, > Tony Hain wrote > Like it or not, we are at the end of the IPV4 road I think that's where you missed it. We are not. The truth is that the end of the IPv4 road is in sight; how far away we don't really know, as looking through the NAT binoculars does not seem to make it closer. How fast we will be there we don't know either, as the Ferrari we were driving 3 years ago has run out of gas and we're now traveling in a much slower bus. > Anything that comes out of rearchitecting the > Internet will be at least another 10 year process. If it's designed as a protocol, likely. If it's designed as a product with a migration roadmap, not necessarily so. The very flaw in IPv6 is that it's never been designed as a product that needs to be adopted. Michel.
Re: Death of the Internet - details at 11
On 1/13/2004 1:06 PM, Dan Kolis wrote: >>Yup, it needs a killer app or feature. Bigger address space was that >>feature, but one made moot by NATs. > > VoIP and multimedia via SIP without having a resident network engineer in > your attic. > Enough said? "in your attic" implies end-user benefit. As I said, I think the hurdles are in the carrier and equipment space, not the end-user benefits. Keep in mind that "larger address space" was beneficial towards ISPs, and not just end-users. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Death of the Internet - details at 11
Eric A. Hall wrote: On 1/12/2004 9:03 PM, Noel Chiappa wrote: IPv6's only hope of some modest level of deployment is, as the latter part of your message points out, as the substrate for some hot application(s). Somehow I doubt anything the IETF does or does not do is going to have any affect on whether or not that happens. Yup, it needs a killer app or feature. Bigger address space was that feature, but one made moot by NATs. There are other features (security, etc), One man's bread (security by defeating outside 'calls' to your address) is another man's poison (failed apps. because you defeated outside 'calls' to your address). Other than conserving addresses, NAT "features" are basically poison resold as bread. Joe
Re: Death of the Internet - details at 11
>Yup, it needs a killer app or feature. Bigger address space was that >feature, but one made moot by NATs. VoIP and multimedia via SIP without having a resident network engineer in your attic. Enough said? Dan
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 12:48 PM -0500 1/13/04, [EMAIL PROTECTED] wrote: On Tue, 13 Jan 2004 07:21:53 EST, [EMAIL PROTECTED] (Mike S) said: > As I said, fascist. Godwin. Valdis, you have confused two protocols that produced similar results but used different underlying transports and different signalling. --Paul Hoffman, Director --Internet Mail Consortium
RE: Death of the Internet - details at 11
Noel Chiappa wrote:
> ...
> IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's
> just
> not enough better to make it worth switching - and you can flame all day
> about
> how NAT's are preventing deployment of new applications, but I can't run
> an
> SMTP or HTTP server in my house because my provider blocks incoming SMTP
> connections unless I pay for business service, and I personally find that
> a
> lot more problematic than the limitations of NAT.
This sounds more like a point to raise with a regulatory agency than a
technical discussion. Your ISP would make you a prime candidate for a
tunnel-broker that will get you past the blockage:
http://www.freenet6.net/
>
> IPv6's only hope of some modest level of deployment is, as the latter part
> of
> your message points out, as the substrate for some hot application(s).
> Somehow
> I doubt anything the IETF does or does not do is going to have any affect
> on
> whether or not that happens.
You may be right, but that only argues that the IETF is irrelevant to the
development of applications. If that is true, why do we have an applications
area full of working groups? My question was really why they are not
recognizing that at this point IPv4 is a dead end, and stopping any work
that assumes an IPv4 substrate? Yes apps are supposed to be agnostic, but we
all know that apps insist on hooks down the stack, because the app developer
believes he can do a better job of managing the network than the OS.
>
> Of course, that still doesn't get you to the "general replacement for
> IPv4"
> stage. I don't think that goal is reachable - IPv6 just isn't enough
> better
> (i.e. more functionality) than IPv4. It's ironic that one of IPv6's big
> concept points ("the IPv4 architecture is fine, we just need to fix a few
> details") turns out to be IPv6's Achilles' heel. (Although some of us
> predicted that at the time IPv6 was adopted)
As you may recall, I really don't care about the bit pattern in the header,
as long as it has enough bits. I have been the pragmatist focused on getting
whatever is implemented actually deployed (we could have had TUBA deployed
long ago, as some of us had the routing infrastructure up before the IPv6
decision). IETF internal conflict has had more to do with any delays than
the market could have.
>
>
> Now if basic IPv6 (and basic IPv6 applications) were reworked so that it's
> IMPOSSIBLE to tell, from looking at the packet, what kind of service it's
> going to - e.g. by using random TCP ports for applications servers, and
> having
> the ICP include a service name (the field for which is encrypted so
> middle-boxes can't read it) to do the rendezvous - that would be the kind
> of
> thing that might interest a few more people.
As I recall, several people including Peter Ford were arguing that the
transport layer should be reworked at the same time, because making the
stack and application changes would be a big enough job that people would
only want to do it once. There was a vast outcry in the IETF to make the
minimum number of changes and keep the architecture exactly the same. Now we
find continuing efforts to rework the architecture because various groups
didn't get the 'minor' tweak they wanted.
>
> And while we're at it, you probably want to make it impossible for the ISP
> to
> even tell if it's a TCP SYN, otherwise they'll probably just filter them
> *all*
> out incoming...
See tunneling comment above.
>
>
> > Continuing work on IPv4 only creates the illusion that it is a
> viable
> > protocol for application developers to rely on for future income.
>
> Continuing work on IPv6 only creates the illusion that it is a viable
> protocol
> for the network as a whole to rely on for the provision of ubiquitous
> datagram
> substrate service.
>
> In anything even vaguely like its current form, that goal is completely
> unreachable for IPv6, and the continued chanting of "IPv6 is the future"
> only
> prevents work on *feasible* upgrades that will allow the continued
> provision
> of ubiquitous datagram substrate service.
Clearly work on IPv6 is not preventing work on changing the fundamental
Internet architecture (see multi6). Turning your earlier argument around,
there is nothing the IETF does or does not do that precludes the IETF from
doing something else. What the IETF can influence is public perception (read
that average developer on the street) by where it places a clear focus. From
the outside, the IETF is continuing to work on IPv4, therefore the IETF
doesn't believe it is a dead end. The average developer is not going to take
the time to learn something different unless it is clear the market is going
away from what he already knows. We can debate all day about how much
influence the IETF has on the market, but given the current abundance of
vendor participants, there is a clear path from standards focus to products
available to the marketplace.
Like it or not, we are at the end
RE: Death of the Internet - details at 11
On Tue, 13 Jan 2004, Michel Py wrote: > IPv6 is currently not worth the price of dual-stack, which is the very > reason it is not being deployed. Some think it's worth the price. In many cases, the price (in terms of money, at least) is zero. In any case, the users are given the opportunity to run applications which leverage IPv6, with or without support from their ISPs or sites. If they don't want to, that's another issue.. > As of transition mechanisms, they're not good enough to run an > IPv6-only network, which in turns makes dual-stack mandatory. No problem, because IPv6-only networks don't make sense anyway. However, the transition mechanisms that have been deployed seem to be good enough to enable dual-stack deployments. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Death of the Internet - details at 11
On 1/12/2004 9:03 PM, Noel Chiappa wrote: > IPv6's only hope of some modest level of deployment is, as the latter > part of your message points out, as the substrate for some hot > application(s). Somehow I doubt anything the IETF does or does not do > is going to have any affect on whether or not that happens. Yup, it needs a killer app or feature. Bigger address space was that feature, but one made moot by NATs. There are other features (security, etc), but they are end-user oriented and don't really hold promise to ISPs or the equipment manufacturers (the simple cost-of-goods factor means that the vendor community has negative motivation to offer IPv6 in low-end gear). There has to be some kind of effort to get past these hurdles -- development of a routing service that makes multi-homing simpler for everybody at a magnitude higher scale, or convincing vendors that IPv6 in the cheapest gear is in their best interests, and so forth. Since the engineers in the IETF tend to hold these kind of marketing efforts in relatively low regard, the likelihood of any of this changing is close to nil. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Death of the Internet - details at 11
On Tue, 13 Jan 2004, Pekka Savola wrote: > On Tue, 13 Jan 2004, J. Noel Chiappa wrote: > > The upgrade path (replace the entire internet layer in one fell swoop) IPv6 > > adopted clearly isn't working. Time to try something rather different. > > Exactly. As we have been saying for years not, we must aim for ^^^ Oops: s/not/now/ > co-existence of IPv4 and IPv6, not replacing IPv4 with IPv6. .. but this was probably understandable. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Death of the Internet - details at 11
> Pekka Savola > Exactly. As we have been saying for years not, > we must aim for co-existence of IPv4 and IPv6, > not replacing IPv4 with IPv6. IPv6 is currently not worth the price of dual-stack, which is the very reason it is not being deployed. As of transition mechanisms, they're not good enough to run an IPv6-only network, which in turns makes dual-stack mandatory. Michel.
Re: Death of the Internet - details at 11
On Tue, 13 Jan 2004, J. Noel Chiappa wrote: > The upgrade path (replace the entire internet layer in one fell swoop) IPv6 > adopted clearly isn't working. Time to try something rather different. Exactly. As we have been saying for years not, we must aim for co-existence of IPv4 and IPv6, not replacing IPv4 with IPv6. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
On Tue, 13 Jan 2004 07:21:53 EST, [EMAIL PROTECTED] (Mike S) said: > As I said, fascist. Godwin. pgp0.pgp Description: PGP signature
Re: Death of the Internet - details at 11
On Tue, 13 Jan 2004 08:23:10 PST, Michel Py <[EMAIL PROTECTED]> said: > And as of the DoD requirements, those of us that are old enough will > remember the ADA language. GOSIP. pgp0.pgp Description: PGP signature
Re: Death of the Internet - details at 11
--On Tuesday, 13 January, 2004 15:41 +0100 jfcm <[EMAIL PROTECTED]> wrote: Gentlemen, let agree IETF is lacking formal interfaces with the real world of users and the real world of operators. John Klensin's official participation to the ICANN BoD is a first good step towards formal links with operators. Sigh. Whatever that relationship constitutes, "formal links with operators" isn't one of them -- there are even fewer actual operators represented and actively participating in ICANN than there are in IETF. Please, at least, get your facts right. john
Re: Death of the Internet - details at 11
Noel Chiappa writes: > Now, can we all agree that almost 10 years after it was formally adopted by > the IETF, IPv6 is has clearly not succeeded in becoming the ubiquitous > replacement for IPv4, and needs to be moved to "Historic", so we can turn our > energy and attention to things that *will* succeed? What leads you to believe that an alternate solution set isn't the empty set? Isn't entropy the easiest and most likely outcome? Mike
RE: Death of the Internet - details at 11
> Hayriye Altunbasak wrote: > Should not you first investigate the reason why > IPv6 is not successful in terms of deployment > (yet)? So that, we won't make the same mistakes > if the world decides to sth else These reasons are well-known and two-fold: 1. It's an investment without any foreseeable ROI: - Scarcity of IPv4 addresses? Not any time soon and certainly not soon enough to justify any investment within the next n years. - Ease of renumbering? A myth. - Auto-configuration? Not fundamentally a breakthrough over DHCP. In other words: what is IPv6 going to buy me or my business in the next n years? Nothing I don't already have with IPv4; why should I invest in it (especially given the tight finances these days) ? 2. It does not even provide what IPv4 does: - No multihoming. - No PA addresses. - Ni private addresses. Michel.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > > You might be ignorant instead of dishonest. > > How very kind of you to consider two possibilities, thank you. My original words that you felt labelled you dishonest explicitly included that possibility. Most people have strong opinions about spam, but have not really looked at it, and are quite wrong about it. > ... > (And, by the way, I consider *any* false positives unacceptable if > there's no suitable mechanism for detecting and correcting them.) That wisdom applies to a lot more than spam defenses. However, it is worth noting that many and perhaps most email users value avoiding false negatives more than avoiding false positives in their spam defenses. That is one reason why the blunt, high false positive blacklists are popular. One also must not try to reduce false positives from spam filters much below the error rate of SMTP in the real world (e.g. not just bounces but blackholes). > This discussion is going nowhere, so I'm going back to more serious > work on comprehensive spam control. That's fine, but it would be wise to recognize the overall situation while developing those comprehensive controls. Railing against the evil conspiracy of big monopolistic ISPs using blacklists against themselves isn't productive. Except for organizations that run their own private blacklists, public anti-spam blacklists will remain quite popular. MAPS used to claim 45% of the Internet used the RBL. I suspect that at least that much uses the RBL+, CRL, XBL, SBL, and/or SPEWS. Public blacklists are here to stay, because they work. The only likely tactic for reducing the use of blunt blacklists such as those listing dynamic IP addresses is to convince ISPs to take network abuse seriously. As long as big ISPs make listing their own IP adddresses "dynamic" lists their main response to their own bad customers, those blunt, high false positive blacklists will remain popular. Talk about transition plans to IPv6, comprehensive spam controls, the evils of NAT, the evils of blacklists, media conglomerate ISPs distributing NAT boxes to break VoIP, and monopolisitic ISPs using blacklists is one thing. Actually doing something is something else. Vernon Schryver[EMAIL PROTECTED]
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 10:45 PM 1/12/2004, Vernon Schryver wrote... >Mr. Sauve could rent an IP address that is not on dial-up or dynamic >blacklists and run his systems there. Proven wrong, Vernon now changes his tack to one of trying to rationalize interference with legitimate email and attempting to place the burden on those who wish to use the Internet as designed, not as damaged by his beloved blacklists. As I said, fascist. He has learned to use whois and Google, though, and seems very self-impressed at his ability to learn such simple things. He has apparently not, however, discovered dictionary.com. "In the design of ... software tools, 'the fascist alternative' is the most restrictive and structured way of capturing a particular function;"
RE: Death of the Internet - details at 11
> From: "Tony Hain" <[EMAIL PROTECTED]>
> You seem to have missed the point. ... You will never hear a consumer
> demanding IPv6 .. You won't hear ISP's demanding IPv6 unless their
> customers are demanding apps that run over IPv6 (even then the consumer
> is more likely to use an automated tunnel and make the clueless ISP
> irrelevant). You won't get new apps unless the development community
> sees a viable path to personal riches.
Tony, I think you're the one missing the point - although you're half-way
there in your later comments above.
IPv6 simply isn't going to get deployed "as a replacement for IPv4". It's just
not enough better to make it worth switching - and you can flame all day about
how NAT's are preventing deployment of new applications, but I can't run an
SMTP or HTTP server in my house because my provider blocks incoming SMTP
connections unless I pay for business service, and I personally find that a
lot more problematic than the limitations of NAT.
IPv6's only hope of some modest level of deployment is, as the latter part of
your message points out, as the substrate for some hot application(s). Somehow
I doubt anything the IETF does or does not do is going to have any affect on
whether or not that happens.
Of course, that still doesn't get you to the "general replacement for IPv4"
stage. I don't think that goal is reachable - IPv6 just isn't enough better
(i.e. more functionality) than IPv4. It's ironic that one of IPv6's big
concept points ("the IPv4 architecture is fine, we just need to fix a few
details") turns out to be IPv6's Achilles' heel. (Although some of us
predicted that at the time IPv6 was adopted)
Now if basic IPv6 (and basic IPv6 applications) were reworked so that it's
IMPOSSIBLE to tell, from looking at the packet, what kind of service it's
going to - e.g. by using random TCP ports for applications servers, and having
the ICP include a service name (the field for which is encrypted so
middle-boxes can't read it) to do the rendezvous - that would be the kind of
thing that might interest a few more people.
And while we're at it, you probably want to make it impossible for the ISP to
even tell if it's a TCP SYN, otherwise they'll probably just filter them *all*
out incoming...
> Continuing work on IPv4 only creates the illusion that it is a viable
> protocol for application developers to rely on for future income.
Continuing work on IPv6 only creates the illusion that it is a viable protocol
for the network as a whole to rely on for the provision of ubiquitous datagram
substrate service.
In anything even vaguely like its current form, that goal is completely
unreachable for IPv6, and the continued chanting of "IPv6 is the future" only
prevents work on *feasible* upgrades that will allow the continued provision
of ubiquitous datagram substrate service.
Noel
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 10:45 PM 1/12/2004, Vernon Schryver wrote... >Mr. Sauve could rent an IP address that is not on dial-up or dynamic >blacklists and run his systems there. Proven wrong, you now change your argument to one of trying to rationalize interference with legitimate email, and attempting to place the burden on those who wish to use the Internet as designed, not as damaged by your beloved blacklists. As I said, fascist.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:50 PM 1/12/2004, Vernon Schryver wrote... >Instead of paying the extra cost to hire an ISP that cares >enough to not have spamming customers, people complain about the evils >of blacklists. Feh. Once again with the incorrect assumptions. I don't spam. I would preferentially route email direct for two main reasons: 1) privacy - routing via my ISP's outbound SMTP gives them the right to intercept and read my email, according the ECPA; 2) control - sending from my own system allows me to control retry attempts and times, instead of being forced to wait 4 days for my ISP to bounce an undelivered back to me, assuming they don't just silently lose it. I can't do so because my IP address is on a blacklist. I have cable modem, but the world thinks I'm a dial-up. For that reason alone, having nothing whatsoever to do with spam, I'm forced to give up privacy and control of my communications. "Anti-spam" initiatives that are based on such blacklists are quite simply the failed results of irrational, fascist thought. Regardless of your exact definition of spam, all reasonable ones I've heard have one thing in common - it's based on CONTENT, not IP address. Blacklists couldn't care less about content - legitimate email or spam, out it goes, to the detriment of communications. They also, quite clearly, don't work to eliminate spam.
Re: Visa for South Korea
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes: >>> What I'm really looking for is some form of official >>> government communication on the subject (unless of course the >>> hosts are the ones who are manning the passport control desks >>> at the airport). >>> >> So call the nearest Korean consulate/embassy. Answering this >> kind of question is part of their job. Ken> I actually already had put a call in to them; the relevant Ken> person was out of the office, but I left a message. We'll Ken> see what they say. I did as well and here is what I got. The phone was answered. I asked to speak to someone about Visa information. I was transferred to someone who answered in Korean; I did not understand the greeting. "Hi. I'm an American citizen traveling to Seoul in late February to attend a meeting of a professional society. Do I need a visa?" She asked again for my citizenship and then said that I did not need a visa. I chose to describe IETF as a professional society because saying standards development organization when referring to something non-ISO-based might confuse a government official. Similarly, I was concerned that conference might map to academic conference. I'd be interested in answers people get from other consulate/embassy staff both from locations other than Boston and with different phrasings of the question.
Re: [isdf] Re: www.internetforce.org
Dear Wawa, John, and colleagues, Talking about approaching questions in a societal forum like the ISDF... I am following your discussion but don't feel certain I should write to the IETF mailing list, so I will only respond in the list where I am subscribed - the ISDF. veni At 19:09 09.1.2004 'г.' Conve -0600, Wawa Ngenge wrote: Thank you. This does answer the question, and is a good example of how to approach questions in a societal forum like ISDF where even rhetorical questions may hide a cry for information. Once again, thank you. w
Re: dire outlook on internet and NAT
Pardon me if I'm missing something obvious here, but couldn't one just use either XMPP or Simple for presence, associate your "server name" with a Jabber/Simple ID, and automatically have your "server" findable via these general presence protocols? Why isn't that a reasonable approach to peer to peer in a NAT world? I would contend that it's even better in a mobile world -- your laptop might change IP address a dozen times per day, but if it keeps reconnecting with your presence server you could base a stable "host" identity on the IM ID to enable peer to peer applications, couldn't you?
Re: Death of the Internet - details at 11
> From: "Tony Hain" <[EMAIL PROTECTED]> > Like it or not, the IETF must stop wasting time and effort building new > structures on a crumbling framework. I agree completely. Now, can we all agree that almost 10 years after it was formally adopted by the IETF, IPv6 is has clearly not succeeded in becoming the ubiquitous replacement for IPv4, and needs to be moved to "Historic", so we can turn our energy and attention to things that *will* succeed? Noel
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:41 PM 1/9/2004, Vernon Schryver wrote... >Could you point to significant amounts of real mail, as opposed to >theoretical examples, that might reasonably have consider legitimate >by its targets but that was rejected as the result of a MAPS RBL >listing? Note that the validity of mail is determined not its senders >but by its targets. Yes. For a lengthy period, all mail.com SMTP servers were included in the RBL, blocking significant numbers of legitimate, private, non-spam emails from reaching willing recipients.
Re: [isdf] Re: www.internetforce.org
I suspect that any approach that was chosen was the result of negotiations and discussions among those who took part in the discussion at that time. Any solution would raise questions in a societal setting, since unanimity is not the norm in a democratic process. The RFC process has extended so deep and so far that change may be difficult, though not impossible. wawa On Thu, 8 Jan 2004, jfcm wrote: > Could it not be useful to have a "List of Comments" (LOC) for each RFC? > Where experience about the RFC reading, testing and implementation could be > listed by the authors (or a successor) from experience and questions > received. It would avoid the same questions to be debated again and again > and it would help further thinking. These comments could start with a > summary of the WG debated issues, explaining the whys of some options. I > suppose the implementation would be easy enough since it would follow the > same numbering scheme and titles. Such a LOC being an updated appendix > could be reviewed and help preparing replacements. > jfc > -- Wawa Ngenge (Ph.D.) Internet Society Trustee Emeritus WorldComputerExchange.org Director www.worldcomputerexchange.org/board_staff/ngenge-resume.htm [EMAIL PROTECTED]
RE: Death of the Internet - details at 11
> J. Noel Chiappa wrote: > Anyway, the point is that successful networking > technologies don't take 10 years to succeed. They > either catch on, or they don't, and after 10 > years this one has not caught on. And as of the DoD requirements, those of us that are old enough will remember the ADA language. > The upgrade path (replace the entire internet layer > in one fell swoop) IPv6 adopted clearly isn't > working. Time to try something rather different. Ack Michel.
Re: [isdf] Re: www.internetforce.org
Thank you. This does answer the question, and is a good example of how to approach questions in a societal forum like ISDF where even rhetorical questions may hide a cry for information. Once again, thank you. w On Thu, 8 Jan 2004, John C Klensin wrote: > --On Thursday, 08 January, 2004 12:50 -0600 Wawa Ngenge > <[EMAIL PROTECTED]> wrote: > > On Mon, 5 Jan 2004, Mark Smith wrote: > >> On Sat, 03 Jan 2004 07:53:04 -0500 > >> Because that is not how they are updated. > >> The RFC faq would a place to seek your ansers. > > The original question is : "Why do they not operate that way", > > if they are indeed REQUESTS? > Hi. > A better answer would have been "the term 'request for comment' > is historical, dating from a time when the preferred way to make > a formal comment on a document involved writing another > document, which then was numbered into the series". That > mechanism is still available, although usually very slow. But > documents that become RFCs are now first posted as Internet > Drafts (see http://www.ietf.org/ID); comments on those are both > solicited and, usually, handled very quickly. > > Today, the RFC Series, despite retention of the original name > and numbering series, acts as a permanent, archival, repository > of information, decisions taken, and standards published. As > such, documents in the series are subjected to review and > editing processes (which differ somewhat depending on the type > of document and are appropriate for conventional references from > conventional documents. Running conversations, logs of > comments, etc., are not well suited for that archival and > reference role, regardless of their other advantages and > disadvantages. > > regards,
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
On Tuesday, January 13, 2004, at 10:42 AM, Vernon Schryver wrote: You might be ignorant instead of dishonest. How very kind of you to consider two possibilities, thank you. Are you calling me and those who point out that some blacklists detect 70-90% of spam with false positive rates below 1% liers? Calling someone a liar is simply not my style, nor did I use any words that were remotely close to doing so. If I could see anything in my words that could possibly be construed that way I would apologize for it. (And, by the way, I consider *any* false positives unacceptable if there's no suitable mechanism for detecting and correcting them.) This discussion is going nowhere, so I'm going back to more serious work on comprehensive spam control. -- Nathaniel
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
> From: Nathaniel Borenstein <[EMAIL PROTECTED]> > ... > > Mr. Sauve could rent an IP address that is not on dial-up or dynamic > > blacklists and run his systems there. > > In other words, because some ISP with whom he has NO relationship has > deemed his own ISP spam-friendly, he should abandon his ISP, whether > *he* thinks they are spam-friendly or not. The words that come to mind > to describe this sort of arrangement are "cartel," "blackmail," and > "extortion." It is also a perfect example of an assertion I made > before, which is that blacklists are being used by the large ISP's as a > tool for consolidation in the ISP market. When RoadRunner blocked my > ISP, the *only* thing they were helpful about was offering to help me > get "better" Internet service by changing ISPs. Exactly the same charges can be made about taxis, pizza delivery services, and so forth that refuse to deliver to "bad" parts of the real world. Perhaps in some cases you are right, but in the vast majority you are wrong. Is a simple, undeniable fact that the sources of spam are concentrated in a small fraction of the IPv4 address space. For example, the last numbers I saw about SPEWS had it listing a tiny fraction of 1% of the IPv4 address space. There are other problems with your theory. The biggest is the link between the big ISPs and the blacklisters. Besides the undeniable spammers (e.g. the ROKSO members), it is the big ISPs that are most likely to be blacklisted, particularly in "dialup" or "dynamic" blacklists. According to your theory, Charter Communications is part of a conspiracy of big outfits to drive away their own customers by blacklisting their own IP addresses. How sane and honest is that? If you are saying that blacklists and boycotts are dangerous weapons, then you're certainly right. That's why contrary to my naive reading of the U.S. Constitution, there are federal laws that limit or outlaw boycotts in some circumstances that I don't understand. See http://www.google.com/search?q=%22secondary+boycott%22 Exactly what do you want? - a U.S. Federal law against IP address blacklists? - a test for social responsibility and good sense given prospective IP address blacklist opererators administrated by the IESG? - a U.N. regulation prohibiting stupidity and foolishness by users and ISPs while choosing blacklists? Pardon me, but it seems you want the IETF to declare that all blacklisting and spam rejecting by IP address wrong and nasty. As far as I can tell, you would require me to accept mail from 69.6.0.0/18 because you fear I might refuse mail from you. Or perhaps you would allow me to reject Wholesalebandwidth spam provided I not tell anyone. > >> Blacklists also, quite clearly, don't work to eliminate spam. > > > > No honest person who actually looks at spam agrees with that. > > As I've made clear, *I* agree with that. Given the exchanges that > preceded this, it sounds like you are asserting that I -- and all the > other people who have argued against you in good faith on this list -- > are dishonest. Is everyone who disagrees with your conclusions > necessarily dishonest? If so, why are you wasting time talking with > us? You might be ignorant instead of dishonest. If you have not looked any blacklists except those that have affected your mail, then you have not, in my words, really looked at spam. Are you calling me and those who point out that some blacklists detect 70-90% of spam with false positive rates below 1% liers? It your words could be read that way. Vernon Schryver[EMAIL PROTECTED]
Re: Death of the Internet - details at 11
Just a small comment: Should not you first investigate the reason why IPv6 is not successful in terms of deployment (yet)? So that, we won't make the same mistakes if the world decides to sth else At 09:39 AM 1/13/2004 -0500, J. Noel Chiappa wrote: > From: Paul Robinson <[EMAIL PROTECTED]> > of course, if after a couple of years it isn't working, there is nothing > stopping the IETF rescinding, and supporting IPv4 once more due to > "customer pressures". :-) Hello? That's where we are *now*. May I remind you that IPv6 has been available December 1995, when the first set of IPv6 specification RFC's came out, and now, almost 10 years later, deployment is still minimal. The customers have "voted with their feet" for IPv4. (Yes, I know, "the support situation has improved and we expect wide-scale deployment in the next year" - I think I've heard that same mantra every year for the last N years. I really ought to go back through my email folders and create a web page of IPv6 predictions. In fact, I think that's a good idea - it will help make plain how hollow such claims are. My task for today! :-) Anyway, the point is that successful networking technologies don't take 10 years to succeed. They either catch on, or they don't, and after 10 years this one has not caught on. The upgrade path (replace the entire internet layer in one fell swoop) IPv6 adopted clearly isn't working. Time to try something rather different. Noel
10 Years
>Anyway, the point is that successful networking technologies don't take 10 >years to succeed. They either catch on, or they don't, and after 10 years >this one has not caught on. Ho boy. Good point there. Its like "boy oh boy! POP3 is dead use IMAP". blablabla IPv6 oddly though is sort of a hmmm behind the scenes thing a little. slightly different. But I think your right if 10 years of waiting doesn't get an internet innovation adopted much its at least sick and maybe dead. regs Dan Dan Kolis - Lindsay Electronics Ltd [EMAIL PROTECTED] 50 Mary Street West, Lindsay Ontario Canada K9V 2S7 (705) 324-2196 X272 (705) 324-5474 Fax An ISO 9001 Company; /Document end
Re: Death of the Internet - details at 11
At 07:37 13/01/04, Joe Abley wrote: The operational cost of supporting both v4 and v6 from the network perspective not great, based on our experience (although the support load for v6 clients to content hosted in our network is currently much lower than for v4 clients, as you'd expect). I'd be very happy to share more details about what we're running with people who have interest. Gentlemen, let agree IETF is lacking formal interfaces with the real world of users and the real world of operators. John Klensin's official participation to the ICANN BoD is a first good step towards formal links with operators. However, the lack of relation of ICANN with users (@large) and the US oriented nature of ICANN (the problem is not the USA but a single country), leads world towards ITU. I support the principle of this move as a multilateralism American structures have some difficulties with, but not a move towards ITU-T. We need an ITU-I where IETF may very well fit through a good and fruitful MoU or more. Each "sector" (ICANN/NICs, @large, IETF/IAB, ITU/GAC) in this chain suffers from its imperfections and its lack of cooperation. For too long each said "the fault is with the other". IMHO the fault is with every of us and we all are to cooperate. When ICANN started the ERC process, I made sure in calling on everyone (Vin may recall that he contributed) that there was a consensus about the need to reform ICANN (read Governance) and that the solution had to be consensual to succeed. The solution is not consensual and we saw Geneva WSIS positions as a result. We now have 2 years to correct that, before UN says "I take over". White House identified the weaknesses of the system too. One of their answers is IPv6. http://whitehouse.gov/pcipb asks all the US administrations to move to IPv6. And DoD is obeying the Chief. In France, the Research Ministry switched to IPv6 and the research network for France (Renater) is the IPv6 leader (the same for Europe (Geant) as far as I understand). We all know what Asia is doing for IPv6. So, IPv6 could be a uniting factor to reorganize the Governance, the "Technicance" and the Brainware (the ways users use the system) in a concerted way, instead of bickering each other. As a user/brainware person for a long, I see several issues where I need the Technicance and the Governance to help. Not to commit anyone I will say a popous "I", but it is actually several "we"s I currently see(share in) structuring 1. I am not technical enough on this to comment about IPv6 as an architecture and as a system. But I do not trust a system the architecture of which is to be dig into hundredth of RFCs and confused closed discussion lists. I need first an Internet architecture document (equivalent to what the W3C published) to understand what is the Internet network system application and how it relates with other network system applications such as telephone, television, OSI, etc. so I am sure everyone understands what we want to do together. 2. I am not a government but I have a IQ high enough to understand that Govs will not buy IPv6 the way it is proposed today for two main reasons. - IPv6.001 (001 numbering plan) is unique and IPv6 is to support up to 6 numbering plans. If IPv6 is to be deployed (real life tested) with only one numbering plan, we will face a Y2K potential threat since no one will be able to warranty the world a new numbering plan will be compatible with the then existing equipment base or even if IPv6 can support it. Nor that it will not endanger existing world operations. We have that exact example with the DNS. To introduce a new TLD is considered as a potential technical threat (while it should be able to support millions of it). - IPv6.001 is flat. Both in routing and in addressing (and confuses both - some wanting to add identification/authetification). As such it offers no control nor surety to countries. Also, it creates many identification, bandwidth, recovery and economical problems. I need a second numbering plan (IPv6.010) to be accepted in the RFCs and discussed. And I do propose this plan to be defined and maintained by ITU. For several reasons. (1) to enforce the ITU-I concept and protect us from the Telcos [to aggregate the Telephone and X.121 numbering plan the ITU-I will have to talk with ITU-T] (2) to get the support of the Govs and show them what is possible and what is not in term of international Technicance. (3) to get a good PR for IPv6. The TF IPv6 submitted a document to the French Research Minister to promote IPv6: I tried to make them understand that technical arguments were low interest, what was of interest was to propose tax cuts for corporations switching to IPv6 to compensate for the equipment upgrade/change. If Govs are involved, they will understand better why to advertise IPv6 and to support to the change. Also, I miss words like dynamic routing, anonymous network presence, domot
Re: Death of the Internet - details at 11
On 13-jan-04, at 15:39, J. Noel Chiappa wrote: > of course, if after a couple of years it isn't working, there is > nothing stopping the IETF rescinding, and supporting IPv4 once > more due to "customer pressures". :-) Hello? That's where we are *now*. May I remind you that IPv6 has been available December 1995, when the first set of IPv6 specification RFC's came out, That's ridiculous. Any IPv6 implementation from before around 2000 is really too immature to be usable (just look at those early specs), and there are still problem areas that must be solved before IPv6 can be considered a decent alternative to IPv4. and now, almost 10 years later, deployment is still minimal. The customers have "voted with their feet" for IPv4. Not yet. (Yes, I know, "the support situation has improved and we expect wide-scale deployment in the next year" - I think I've heard that same mantra every year for the last N years. I really ought to go back through my email folders and create a web page of IPv6 predictions. In fact, I think that's a good idea - it will help make plain how hollow such claims are. My task for today! :-) But you are doing the exact same thing by claiming premature defeat. If IPv6 were really as dead as you say, how is it possible that so many vendors have been implementing so many new IPv6 features the past year alone? Anyway, the point is that successful networking technologies don't take 10 years to succeed. They either catch on, or they don't, and after 10 years this one has not caught on. It would be interesting to compare the first 5 years of ARPANET with the first 5 years of IPv6 availability. I wouldn't be surprised if there are more systems running IPv6 today than systems connected to the ARPANET in 1974. The upgrade path (replace the entire internet layer in one fell swoop) IPv6 adopted clearly isn't working. Time to try something rather different. If this is what you really want I think you should make your case based on technical merit of the new approach over IPv6 rather than a perceived marketing failure.
Re: Death of the Internet - details at 11
> From: Paul Robinson <[EMAIL PROTECTED]> > of course, if after a couple of years it isn't working, there is nothing > stopping the IETF rescinding, and supporting IPv4 once more due to > "customer pressures". :-) Hello? That's where we are *now*. May I remind you that IPv6 has been available December 1995, when the first set of IPv6 specification RFC's came out, and now, almost 10 years later, deployment is still minimal. The customers have "voted with their feet" for IPv4. (Yes, I know, "the support situation has improved and we expect wide-scale deployment in the next year" - I think I've heard that same mantra every year for the last N years. I really ought to go back through my email folders and create a web page of IPv6 predictions. In fact, I think that's a good idea - it will help make plain how hollow such claims are. My task for today! :-) Anyway, the point is that successful networking technologies don't take 10 years to succeed. They either catch on, or they don't, and after 10 years this one has not caught on. The upgrade path (replace the entire internet layer in one fell swoop) IPv6 adopted clearly isn't working. Time to try something rather different. Noel
Re: Your all complaining about NAT mostly
>Actually, I'm told by ISP people that they don't make money off their address >charges, that they basically just cover their own costs. >Noel Bell Canada here charges $10 or so for a few fixed IP's per month. They are bought for $0.60 US as a one time cost. A pretty "good cover". Regs, Dan Dan Kolis - Lindsay Electronics Ltd [EMAIL PROTECTED] 50 Mary Street West, Lindsay Ontario Canada K9V 2S7 (705) 324-2196 X272 (705) 324-5474 Fax An ISO 9001 Company; /Document end
Your all complaining about NAT mostly
I'm making a product from scratch shortly and think the tide has turned to support IPv6 as much as possible. I haven't looked. Are Docsis Cable modems 2.0 IPv6 aware? How about MS operating systems? If ISP's and cable ops didn't ration fixed IP's NAT wouldn't be so popular. Its a way to evade an cost which is arguably illegitimate in the first place. The operators caused this, and not it reduces there income. They did it to make money; (and also were too busy to notice what they were doing). Can be fixed in a number of ways. -Dan K >Almost all via dual-stack.Those who have done so have >found the extra cost minimal where the v6 capability is introduced as part of >a normal procurement cycle. The UK academic backbone JANET is one example >in your context. Remember it's not about migrating in most circumstances, >it's about parallel capability to enable v6 to operate now as the first phase >of a (very long) transition. But some networks are emerging ipv6-only, >particularly in Asia. >Tim
RE: dire outlook on internet and NAT
> Admittedly I can't remember where I read it, but I've come across > a suggestion that enterprise networks adopting IPv6 is likely to > happen before ISPs provide it in any big way, as enterprise > networks have more to gain from the technology (well, possibly, > assuming they can be convinced that "proper" address space is > better than NAT). => I'm a bit confused as to why enterprises would be interested in v6. There are even prorietry solutions that allow for VPN access behind a NAT. And enterprises are not known for encouraging p2p apps for their employees. So this business case doesn't seem like a winner to me. My hope has been that p2p apps will one day be "needed now" and force people to turn v6 on in their networks. Once enterprises have it, they will then ask > for it from their ISP. => Sure, but it's not clear that they'd be early adopters. Autoconfig of addresses will not be enough, if they ever use it. Hesham I'd agree that expecting the drive for it > to come from ISPs is probably incorrect. > > Maybe the focus needs to be to work on IPv6 protocols that > enterprises need. Anybody want to work on NetBIOS over IPv6 ? > After all, File and Print would have to be the "killer" > application for enterprise networks - it's the application that > got networks into most enterprises in the first place in > the last 10 years. > > Regards, > Mark. >
Re: Death of the Internet - details at 11
On Tue, Jan 13, 2004 at 06:43:43AM -0600, Randall R. Stewart (home) wrote: > Something about this thread confuses me :-0 Now maybe it > is just me having my head down in the sand.. I work in the > transport area mainly and last I checked: > > 1) TCP/SCTP and UDP all run over IPv6, in fact SCTP > (which I most work with :->) will setup an association >with BOTH IPv4 and IPv6 addresses in the association, >I don't even have to choose, I get them both as long as >I open an AF_INET6 socket. :-> Yes, I see what you're saying. I think the point was, we should be actively dissuading any further work around IPv4 protocols (where they occur), NOT actively encouraging IPv6. By saying IPv4 is "officially" dead, we might push forward the replacement for it (IPv6) and the takeup with both vendors and service providers, particularly when it comes to consumer end-points. Several people have been citing their providers as offering dual-stack services, and how IPv6 peering with Tiscali happens, etc. but they are completely missing the point. What we're discussing is the need for IPv6 to be pushed out to the edge of the network to broadband users as the DEFAULT, and not an option for those hosting servers near the core of the network, who get it when they ask for it, which is what we mostly have now. I'm not advocating re-drafts where we stick IPv6 Requirements into everything in sight, however. :-) -- Paul Robinson
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
I'm sorry, I know I said I wasn't going to be lured into another exchange in this thread, but I can't help it... On Monday, January 12, 2004, at 10:45 PM, Vernon Schryver wrote: Mr. Sauve could rent an IP address that is not on dial-up or dynamic blacklists and run his systems there. In other words, because some ISP with whom he has NO relationship has deemed his own ISP spam-friendly, he should abandon his ISP, whether *he* thinks they are spam-friendly or not. The words that come to mind to describe this sort of arrangement are "cartel," "blackmail," and "extortion." It is also a perfect example of an assertion I made before, which is that blacklists are being used by the large ISP's as a tool for consolidation in the ISP market. When RoadRunner blocked my ISP, the *only* thing they were helpful about was offering to help me get "better" Internet service by changing ISPs. Blacklists also, quite clearly, don't work to eliminate spam. No honest person who actually looks at spam agrees with that. As I've made clear, *I* agree with that. Given the exchanges that preceded this, it sounds like you are asserting that I -- and all the other people who have argued against you in good faith on this list -- are dishonest. Is everyone who disagrees with your conclusions necessarily dishonest? If so, why are you wasting time talking with us? -- Nathaniel
Re: Death of the Internet - details at 11
Paul Robinson wrote: I think if we say "From the middle of next year, no more IPv4 RFCs or drafts please", then vendors and application developers will have to sit up and take notice. Remember, the protocols take between 6-36 months to be deployed for real, so what we'd actually be saying is "we don't think IPv4 is worth deploying from scratch after the middle of 2007". We'd be saying to application developers "Look, IPv4 isn't where you're going to make serious cash with innovative applications in the future, come play with IPv6". Paul: Something about this thread confuses me :-0 Now maybe it is just me having my head down in the sand.. I work in the transport area mainly and last I checked: 1) TCP/SCTP and UDP all run over IPv6, in fact SCTP (which I most work with :->) will setup an association with BOTH IPv4 and IPv6 addresses in the association, I don't even have to choose, I get them both as long as I open an AF_INET6 socket. :-> 2) I can't remember any transport area document in recent history (course I don't read them all) that is just IPv4... Most of the things popping around are the congestion control work for high speed and things for false fast retransmit... and other fun transport area stuff :-> No IPv4 specifis there 3) I cannot, in writting an RFC, make the user of the socket interface do "s = socket(AF_INET6, SOCK_STREAM, IPPROTO_SCTP);" At least I don't know how to specify that in a draft.. What I am saying is that a large part of the work in the IETF is rather ambivilant to what the IP infrastructure is that is beneth it... is this not a good thing? Maybe y'all are refering to another area that I don't keep up on (which is most since I can barely keep up in transport) :-> R -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone)
Re: Death of the Internet - details at 11
On Tue, Jan 13, 2004 at 11:21:33AM +, Paul Robinson wrote: > > Not around me it isn't. In the UK, even with cable modem providers, I have > non-NAT - as they are known in the European ISP industry "RIPE addresses" - > and although I've installed NAT myself to enable quick and easy WiFi access > using the one IP address, there is nothing stopping me taking that box out > and having proper IPv4 direct to my NIC. Which is one of the drivers. Most ISPs still only give 1, often dynamic, IPv4 address. As soon as you have multiple home devices (I now have 11 different MAC addresses observed on my home router since last summer) you hit the problem. > In addition, many, many broadband ISPs in the UK will not only provide IP > addresses, but will happily route subnets providing you fill in the form > explaing why you want the addresses, so they can give the justification to > RIPE if they need to apply for more address space. I don't think it's that many. And as you say, the big ISPs like BT who will only give 1 IP (and indeed who will flat out refuse to support you if you replace your USB DSL modem with a "real" DSL router) are the ones that make up the vast majority of UK broadband. Yes some people can go to smaller ISPs and find those that give subnets (I found one that gives a /29 for free), but these are the minority. One beauty of IPv6 is not having to go back to RIPE to ask for more addresses; you get enough to start with to avoid the paperwork cycles; that's some saving in its own right. I think protocols should continue to be developed that are as far as possible IP independent. This will help transition; stopping work on IPv4 seems inapprpriate given IPv4 will be here for 20+ years still. But there are specific IPv6-only properties that are very interesting, like CGA, or resilience to port scanning, that should be taken advantage of asap. Tim
Re: Death of the Internet - details at 11
On Tue, Jan 13, 2004 at 10:30:05AM +, Tim Chown wrote: > It is prevalent wherever there is broadband. And that is where (with the > extra bandwidth and always-on) connectivity into the network is desirable. Not around me it isn't. In the UK, even with cable modem providers, I have non-NAT - as they are known in the European ISP industry "RIPE addresses" - and although I've installed NAT myself to enable quick and easy WiFi access using the one IP address, there is nothing stopping me taking that box out and having proper IPv4 direct to my NIC. In addition, many, many broadband ISPs in the UK will not only provide IP addresses, but will happily route subnets providing you fill in the form explaing why you want the addresses, so they can give the justification to RIPE if they need to apply for more address space. There are a few big players who do NAT - BT OpenWorld is the biggest I know - and yes, they are aiming for a consumer market that as yet does not see the advantage of non-NAT network access. There are two ways people will address the issue when the time comes: 1. Demand non-NAT network access 2. Use protocols that work around NAT restrictions > IPv4+NAT will coexist with IPv6 for many years. A home router can easily > offer v4/NAT and v6 together. This allows v6 apps to be used opportunisticly > between homes or other networks that would otherwise have NAT and need some > 3rd party broker. I am not advocating a policy of insisting that IPv4+NAT gets withdrawn from the Internet. What I am suggesting is that there is an official withdrawal of support for continuing the development of IPv4 protocols - that we should be saying to the world "Look, very nice, but we're about 3 years ahead of you on the technology curve, and we're not providing life support for something we know you won't want in 3 years time when we can be using that time dreaming up the support for the apps we know you will want"... > That's rather insane :) More like July 31st 2025 before we remove IPv4, > and even then it'll hang around... remember no-one *has* to install IPv6, > it's just an option if you want the functionality. Users want features not > protocols. I'm not saying we remove IPv4. Just we push market demands by removing continued RFC support for protocols replying on it. This is exactly the technique the author of Speak Freely used to bring this issue to our attention. It's what MS, Sun, Cisco, everybody does. If you're happy with IPv4, fine, keep it, but we're not going to carry on pumping resources into something that quite frankly, is not a suitable use of our time. This to me seems a reasonable approach. I think if we say "From the middle of next year, no more IPv4 RFCs or drafts please", then vendors and application developers will have to sit up and take notice. Remember, the protocols take between 6-36 months to be deployed for real, so what we'd actually be saying is "we don't think IPv4 is worth deploying from scratch after the middle of 2007". We'd be saying to application developers "Look, IPv4 isn't where you're going to make serious cash with innovative applications in the future, come play with IPv6". And of course, if after a couple of years it isn't working, there is nothing stopping the IETF rescinding, and supporting IPv4 once more due to "customer pressures". :-) -- Paul Robinson
Re: Death of the Internet - details at 11
On 13-jan-04, at 10:36, Paul Robinson wrote: Continuing work on IPv4 only creates the illusion that it is a viable protocol for application developers to rely on for future income. Are you suggesting then, that all RFCs based on IPv6 should be... stopped? I think that one should read IPv4... By the sounds of it, what you're looking for is for us as a community to refuse to deal with IPv4 any more, that we wash our hands of it, and make vendors realise that they are going to be unable to support IPv4 for more than a few years? Hm, didn't they try something along those general lines at Coca Cola a while ago? It's brutal, but I can see the point. Thinking about a cut-off date for IPv4 would indeed provoke some interesting discussion, but I think a lot of people still want to hang onto IPv4. Even so, how does July 31st 2005 sound to everybody? Why don't we start by making *.ietf.org only reachable over IPv6 starting 04-04-04?
Re: Death of the Internet - details at 11
On Mon, Jan 12, 2004 at 08:13:02PM +, Paul Robinson wrote: > > IPv6 will not take off any time soon because neither the end-user nor the > service provider sees the need. The moment AOL, Wanadoo, Tiscali, World > Online et al shout out "we *need* IPv6" it will happen. Quickly. IPv6 is taking off now because of specific high-profile demands like those of the US DoD. There have been many significant advances in the past 12 months in terms of stability of standards and hardening of implementations (including h/w support from key vendors such as Juniper and Cisco). Most users will use IPv6 without knowing it, which is part of the beauty but also a little sad for those who have worked hard to make IPv6 happen. > And out of curiosity, how many people here have migrated their entire > network to IPv6 already to set a good example and show how it's done? Yes, > thought so. Many networks have, almost all via dual-stack.Those who have done so have found the extra cost minimal where the v6 capability is introduced as part of a normal procurement cycle. The UK academic backbone JANET is one example in your context. Remember it's not about migrating in most circumstances, it's about parallel capability to enable v6 to operate now as the first phase of a (very long) transition. But some networks are emerging ipv6-only, particularly in Asia. Tim
Re: Death of the Internet - details at 11
On Tue, Jan 13, 2004 at 09:36:07AM +, Paul Robinson wrote: > Are you suggesting then, that all RFCs based on IPv6 should be... stopped? That's what happens when you write e-mails and then don't check them before sending them... s/IPv6/IPv4 - obviously. :-) -- Paul Robinson
Re: Death of the Internet - details at 11
On Tue, Jan 13, 2004 at 09:36:07AM +, Paul Robinson wrote: > > But that app has to be something particularly splendid. And in Europe at > least, NAT is not as prevalent as some think it is. It is prevalent wherever there is broadband. And that is where (with the extra bandwidth and always-on) connectivity into the network is desirable. > Are you suggesting then, that all RFCs based on IPv6 should be... stopped? > By the sounds of it, what you're looking for is for us as a community to > refuse to deal with IPv4 any more, that we wash our hands of it, and make > vendors realise that they are going to be unable to support IPv4 for more > than a few years? IPv4+NAT will coexist with IPv6 for many years. A home router can easily offer v4/NAT and v6 together. This allows v6 apps to be used opportunisticly between homes or other networks that would otherwise have NAT and need some 3rd party broker. > It's brutal, but I can see the point. Thinking about a cut-off date for IPv4 > would indeed provoke some interesting discussion, but I think a lot of > people still want to hang onto IPv4. Even so, how does July 31st 2005 sound > to everybody? That's rather insane :) More like July 31st 2025 before we remove IPv4, and even then it'll hang around... remember no-one *has* to install IPv6, it's just an option if you want the functionality. Users want features not protocols. Tim
Re: Death of the Internet - details at 11
On Mon, Jan 12, 2004 at 02:29:24PM -0800, Tony Hain wrote: > You will never hear a consumer demanding IPv6; that is technology plumbing. > The most they will demand is an app that only works because IPv6 provides > direct access between endpoint peers. You won't hear ISP's demanding IPv6 But that app has to be something particularly splendid. And in Europe at least, NAT is not as prevalent as some think it is. > unless their customers are demanding apps that run over IPv6 (even then the > consumer is more likely to use an automated tunnel and make the clueless ISP > irrelevant). You won't get new apps unless the development community sees a > viable path to personal riches. You won't get the development community to > pay attention to the simplicity afforded by IPv6 until the IETF stops > wasting time trying to extend a dead protocol. Continuing work on IPv4 only > creates the illusion that it is a viable protocol for application developers > to rely on for future income. Are you suggesting then, that all RFCs based on IPv6 should be... stopped? By the sounds of it, what you're looking for is for us as a community to refuse to deal with IPv4 any more, that we wash our hands of it, and make vendors realise that they are going to be unable to support IPv4 for more than a few years? It's brutal, but I can see the point. Thinking about a cut-off date for IPv4 would indeed provoke some interesting discussion, but I think a lot of people still want to hang onto IPv4. Even so, how does July 31st 2005 sound to everybody? -- Paul Robinson
