Re: Finding information
On Jan 20, 2008, at 1:24 AM, Romascanu, Dan (Dan) wrote: Besides the suggestion already given, if you go to http://www.rfc-editor.org/rfcsearch.html start with a search on IMAP. RFC1730 will be one of the first (in chronological order) of the 47 entries, you will find out in the More Info columns that it was obsoleted by RFC2060 and RFC2061. RFC2060 will then be listed as obsoleted by RFC3501, which was updated by a number of RFCs (probably the extensions you look for) and also has an Errata you may want to look at. Or, you can google IMAP and come up with 3501 straight away... Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Westin Bayshore throwing us out
++; On Nov 27, 2007, at 11:47 AM, Yaakov Stein wrote: The Westin Bayshore just called me to tell me that they are undergoing renovations, and so unfortunately they are kicking me out of the room that I had reserved in early September. They offered to put me up in the Renaissance 5 blocks away, but, when asked, told me that the night time temperatures are close to, or below freezing. I am sure that many of you consider zero Celsius a reasonable temperature, but I don't. The hotel would not tell me how many people were being relocated in this fashion, but apparently there are many. I made travel plans based on a confirmation from the hotel that the IETF selected as venue, and less than a week before arrival the hotel throws me out with no recourse. I then asked the hotel if they were going to provide a shuttle service, and they said that they would have to consider it. I think that the IETF should insist on this as minimal compensation for those who are being downgraded in this fashion. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 9, 2007, at 8:49 AM, Ralph Droms wrote: is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Hi Ralph, I don't know about 'provable', but there's a strong argument as to why that's challenging. 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. And, I guess I'll stop here as I'm rehashing a train that long ago left the station... While the train has left the station, it seems like it can still be modified while in motion. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
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. ;-) Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote: 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. This perspective is soluble, but it's not the perspective that we seem to approach the problem from. We also don't have the solution in hand today, but work towards it would be greatly accelerated by backing away from our long-standing positions, terminologies and arguments and truly focusing on the problem at hand. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: 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? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 5:33 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, how is it possible to automate the renumbering of my firewall entries which contain IPv6 addresses and prefixes? How is it possible to automate the renumbering of my extranet business partner firewalls who also contain some of my IPv6 addresses and prefixes? How do I automate the renumbering of router ACLs in my own IPv6 network? As a practical matter, these things are quite doable. Sane network management practices store the configuration for such devices in offline management stations. By then writing these configurations in a parameterized form, you can then use the current variable definitions to expand out a concrete configuration. The tools for this are not rare. Languages such as Perl, or macro processors such as cpp or m4 are more than adequate to the task. Loading the results of these tools into devices is also trivial. See rancid, for example. For larger cases, one can also integrate a SQL database to help provide organized scalability. This is not theoretical, I've worked with all of the above. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Sep 13, 2007, at 2:34 PM, Iljitsch van Beijnum wrote: The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Wouldn't that be the OSI session layer (that IP doesn't have)? Not necessarily. A 'session' in the OSI verbiage (at least as far as I can understand it ;-), spans across individual transport connections. The de-facto session layer that we have today in IP is an ssh tunnel, with applications tunneled across it and some very poor security within that tunnel. A key question here is whether the 'association' is a single connection or not. While the association may span the change of underlying infrastructure, the real question is whether it presents a single concatenated transport abstraction or if it's multiple connections. I think we need the former. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Anyhow, you can see where this might lead... All practical address spaces are finite and thus must be used conservatively. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Keith, It seems likely that cable mso's similar will dole out /64's to customers one at a time, ... The issue is that IPv6 is architected to give sufficient addresses to end users, and by screwing with this ARIN is harming both deployability of IPv6, manaegability of IPv6, and usability of IPv6 by applications. First, there was never an architectural goal to give end users 'sufficient' addresses for arbitrary values of 'sufficient'. Second, one might reasonably expect 2^64 addresses to be sufficient. It allows anyone to embed 2^32 entire IPv4-sized Internets in their own house. If you have a problem with IPv6's routing architecture not allowing subnetting within the least significant 64 bits, well, that's water that's VERY much under the bridge. Third, I think you have your perpetrator's confused. ARIN is not limiting end users to /64's, that is the MSOs call. They are retailing service and as you might reasonably expect, their entry level product is just that: entry level. As I mentioned before, if you want more, fork over more sheckles. Most MSOs would VERY much like to sell you a service with a fraction of an IPv4 address today, but they really haven't figured out how they could do so technically. For v6, they will always sell a service with a minimal amount of address, regardless of ARIN policies. If they could figure out how to make that a /128, they would. This is just good business sense on their part: buy low, sell high. no, it's because they're screwing with protocol design decisions that have already been made, and which they aren't by any stretch of the imagination qualified to revisit. Exactly what decision are you claiming they violate? Please quote the RFC. I don't know which one you're on about. Thanks, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
a clever router/switch could certainly do a lot without subnetting. Indeed. If you Google around a bit for MAC table size, I think that you'll find it hard to find an advertised size less than 1K entries, and that's for a shrink-wrapped 8 port switch. I'll believe that entry level boxes are smaller than that, but then once you have more than a handful of systems, it would not be unreasonable to invest a teeny amount in a better switch. Just how big is your house/TARDIS anyway? one of the areas in which I think the IPv4 design failed is that it didn't really follow the catenet model. it was not possible to extend the network from any point. and this is part of what led to NATs, because there really was a need to be able to do that. IPv6 doesn't quite let you do that either, but having long addresses is probably good enough provided the prefixes given to supposed end users are still long enough to allow a couple of additional layers of network to be hung off of them. The only way to do what you want is to effectively have a variable length address. While there were a few crazy advocates of this many years ago, they were shouted down. Tony Li Lead Lunatic ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
Keith, perhaps, but one might also reasonably expect 2^0 networks to be insufficient. At the risk of repeating myself, I respectfully disagree. Given that you can reasonably build a flat subnet of 1000 hosts today, it does not seem like an unreasonable entry point. Mom Pop 6-pack have one computer. George Jane Jetson only have 6. Why does the entry point have to be more than two orders of magnitude above the common case? so are prefix allocations to users of less size than a /48. but if ARIN can't follow the specifications that everyone else uses, this should call their competence into serious question, and maybe IANA should find someone else to dole out IPv6 prefixes for that part of the world. Once again, that's the MSO's doing that, not ARIN. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
variable length addresses are a better idea than it appears at first glance. they do bring certain difficulties with them, especially when trying to do fiber-speed switching in hardware. Poppycock. Hardware for switching variable length addresses first showed up about 15 YEARS ago. This is Not Hard at all. it's hard to switch on arbitrary bit boundaries Hello, we've been doing that since CIDR. and it's harder to switch in hardware using prefixes of arbitrary length. You mean addresses of variable length. One way: when you parse the packet, stuff the length (in bits) of the address in a register. Have your hardware autodecrement this register every time it matches a bit in the lookup process. Store any intermediate result in a fixed, known location. If the number of bits remaining in the register hits zero before you match a prefix, then promote any intermediate result to the final result. overall it strikes me as a hell of a lot better than NAT. Please visit the appropriate parties with your time machine. Immediately after the Big Ten meeting would be a fine start. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
When they do, they are violating the premises on which they received their allocation. As such any ISP which is not willing to provide a /48* to an end-user should get their IPv6 allocation revoked by the RIR. Could you please site chapter and verse? Here's what I can find: http://www.arin.net/policy/nrpm.html#six54 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. ISPs should be charging based on *bandwidth usage* not on IP usage. Sorry, ISPs charge based on providing a *service*. Yes, that includes bandwidth (and generally flat bandwidth, not usage) and also other components (DHCP, addressing, DNS, email, web hosting, spam filtering, etc). Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Aug 17, 2007, at 4:05 PM, Keith Moore wrote: It seems likely that cable mso's similar will dole out /64's to customers one at a time, I suppose that's acceptable if not necessarily desirable and will probably still result in the use of nat mechanisms in end systems. that's COMPLETELY unacceptable. Interesting. Here we have a finite resource with clear, non-zero value that is being allocated by duly appointed numbering authorities based on need and then subsequently being allocated to end-users. Where's the issue? If you have a beef with only getting a /64, I'm sure that the MSO would be MORE than happy to give you more. For a price. If something is unacceptable here, its because your expectations aren't being met. Is it the policies that are unreasonable? Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Aug 17, 2007, at 5:54 PM, Steven M. Bellovin wrote: I'm not sure what your point is -- I took Keith's comment to mean that home NATs with v6 were completely unacceptable. /64's do NOT imply that there's NAT functionality involved, just that there's a single subnet, yes? Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6: Do you want to have more meetings outside US ?
On Jul 29, 2007, at 8:39 AM, Peter Dambier wrote: Is there any IPv6 activity inside the US? Some. NTT/America, for example, is a Tier 1 provider with v6 deployed. Comcast (cable-based ISP) is rumored to be working on v6. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-natpt-to-historic-00.txt
On Jul 2, 2007, at 9:43 AM, Christian Huitema wrote: In the old engineering attitude, working groups were created because several like-minded engineers wanted to develop some function, or protocol. It was important for them to get together, so they could voluntarily agree on the details. If they did not, each would develop their own version, and there will be no interoperability. The result was documented in a set of RFC, so that whoever wanted to develop a compatible product could. IANA registries are used to ensure that when options arise, the options are numbered in an orderly manner. In the policy making attitude, working groups are created to control evolution of a particular function. The working group members are concerned that someone else might be implementing something harmful to the Internet. Their goal is not so much to develop products as to ensure that non-conforming products do not get developed. IANA registries are used to control extensibility of the resulting protocols, to make sure that bad options never get a number. In short, the IETF evolved from an informal gathering where engineers will agree on how to do things, to a reactive body that mostly aims at controlling evolution of the Internet. Is that really what we want? Hi Christian, I'm not sure that we have much of a choice. If there is no control over how the technology is used, then forces that see an advantage in doing something harmful to the Internet will come into play. A fine example of this already exists with address space. We understand that address space, while large, is finite, and we've created policy (delegated to the RIRs) to ensure that address space requests are duly justified. We have created the ultimate Commons, and it is up to us to create the policy to prevent the associated tragedy. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
I don't see increasing the areas; I see splitting them down as a possible way. Leaving an AD at the top level with less work, and having sub-ADs report to them. It's well known that when dealing with a scalability issue, the way to address the issue is to install hierarchy. [Have you ever heard me say this before? ;-)] Adding another layer of management is therefore the obvious approach and a fine alternative to having co- ADs or more areas. The downside to this is increased inefficiency and disconnect from reality. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: chicago IETF IPv6 connectivity
On Jul 1, 2007, at 6:34 AM, Dave Crocker wrote: Jun-ichiro itojun Hagino wrote: maybe we can have the default IETF61 SSID be pro-IPv6, and SSID legacy be IPv4-only :-P Ahh, well. That moves the change from being coercive to being cool. No, that moves it to being pejorative. In any case, what is the need for separate SSID's? Do you truly intend to clutter the airspace further with another set of AP's? There are effectively only three channels and you really want to use all three already to provide overlapping non-interfering coverage... Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)
On Jun 28, 2007, at 12:18 AM, Brian E Carpenter wrote: On 2007-06-27 20:46, Tony Li wrote: I don't see increasing the areas; I see splitting them down as a possible way. Leaving an AD at the top level with less work, and having sub-ADs report to them. It's well known that when dealing with a scalability issue, the way to address the issue is to install hierarchy. [Have you ever heard me say this before? ;-)] Adding another layer of management is therefore the obvious approach and a fine alternative to having co-ADs or more areas. The downside to this is increased inefficiency and disconnect from reality. I think the other issue is that this layer would be hard to fill in our volunteer community. Being a WG Chair has its satisfactions, as does being an AD or IAB member; I'm not quite sure what the satisfactions in an intermediate position would be. That's why I'd rather push work and responsibility into the 120 WGs, where there should be compensating satisfaction in work well done. Some folks might choose to serve nonetheless. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
