Re: About cookies and refreshments cost and abuse
On Wed Mar 29 03:08:59 2006, Brett Thorson wrote: I think it interesting that the great minds of the IETF are discussing in depth something that is probably just slightly more important than the outcome of this week's American Idol contest. Oh well, here are my two cents... There's several important issues here, not least that Cookies are deprecated, and we should be using Cookie2. However, RFC2965 section 3.3.3 should clearly explain how to deal with the problems in general, and section 3.5 of the same document should help to explain the initial complaint raised. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Cookies seem to be a scarce resource, so why not bring your own darn cookies to the meeting, and you wouldn't have a problem. Seriously, stop by a local grocery store, and plop down $3 and buy whatever kind of cookies make you the most happy. Aggravation avoided. That's a very community-based approach. An alternative that may better fit our institutional style is to use edible RFID tags in the cookies: http://www.gizmodo.com/archives/nec-resonantware-tomorrows-future-tomorrow-008958.php As a valuable extra, these are DRM-enabled. And, you won't have to worry about Richard Stahlman showing up at the meeting and scarfing down all the cookies. Carl P.S. My $0.02: I have full faith in the IAOC and IAD resolving this issue without our help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
On Tue, Mar 28, 2006 at 06:47:46AM -0800, Dave Crocker wrote: [EMAIL PROTECTED] wrote: ah yes, the IETF as a FormulaOne race car. I'll approach CocaCola Visa for branding rights if that would help (esp for those folks denied a 770) ah yes, the ad absurdem form of argumentation. testing the boundaries of an assertion is occasionally wise. The reality in having a host is that we already experience quite a bit of marketing from that host. we do. My suggestion was cast in terms of permitting that level to continue, not in permiting every attendee eye-blink to experience a new injection of promotional material. i was more concerned wiht Jordi's suggestion that we aquire sustaining sponsors. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Hi Julien, I guess is a question of planning. I tend to book my flights at least 3 months ahead. Then a flight Madrid-Europe-Madrid, for example, could be so law as 80 Euros (replace Europe with Munich, London, Paris, Brussels, or any other preferred EU destination). For the same period (a week, including Saturday night), Madrid-Dallas-Madrid is about 550 Euros. This typically works also just purchasing 5-6 weeks ahead of the flight departure. Regards, Jordi De: Julien Laganier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 29 Mar 2006 14:13:40 +0200 Para: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the size of the available address space. So if what you say is true, and we manage to use up an exponential resource in linear time, then we can change our approach and try again with the second 1/8 of the space, without having to go through the upgrade pain that is the v4-v6 transition again. I suspect even arrogant engineers can get it right in 8 tries. :) -Scott On 03/29/06 at 6:15am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Thomas Narten writes: This is FUD. Care to back up your assertions with real analysis? Sure. The consistent mistake engineers make in allocating addresses is that they estimate capacity in terms of sequential and consecutive assignment of addresses--but they _assign_ addresses in terms of bit spans within the address itself, which exhausts addresses in an exponential way. They do this in part because they attempt to encode information directly into the address, instead of just using it as a serial identifier. An address of n bits contains 2^n available addresses _only_ if they are assigned serially and consecutively; dividing those bits into any arrangement of smaller fields reduces capacity exponentially. For example, if you have a 16-bit address field, at first it looks as those it has 65,536 addresses. And it does ... if you assign addresses as 0001, 0010, and so on. But if you allocate addresses by dividing those 16 bits into fields, you dramatically reduce the total address space available. If you reserve the first eight bits for a vendor, and the second eight bits for a product, you've cut the address space by 99.6%, not by 50%. You will run out of addresses in record time, and yet you'll never use more than a tiny fraction of the theoretical capacity of the address space. All because you wanted the short-term convenience of encoding information into the address itself. Engineers make this mistake over, and over, and over. I don't know if they are just too stupid to understand the above concepts, or if they are so arrogant that they think they can somehow short-circuit information theory and do the impossible. I tend to vote for arrogance, since I think (and hope) that engineers aren't really that stupid. And further evidence for pure arrogance is that engineers try to allocate address spaces now for a future that they are unable to imagine. They allocate /64 fields out of 128 bits for purposes that they understand now, even though the real need for addresses is likely to be completely different (and unforseeable) by the time addresses actually start to run short. I know I'm wasting my breath; if engineers were that easy to persuade, they would not have made the same mistake over and over for nearly a hundred years. I'm sure others have tried to point out their errors time and again, especially in recent years as more people have caught on to the problem. But they can't be told. They are convinced that it won't happen to them, even though it happened to everyone else. A 128-bit address seems like more than the universe will ever need, and it definitely is ... but only if addresses are assigned serially from the address space, without any information encoded into the address itself. As soon as you reserve any portion of the field in any way, there are multiple exponential reductions in capacity, which can exhaust the address space entirely in a very short time. The mistakes have already been made with IPv6. Someone decided to allocate bit spans out of the address, instantly invalidating the very vast majority of all possible addresses in the address space, and thereby reducing address capacity exponentially. Nobody really knows how addresses will be used 20 years from now, so why do people try to guess and sacrifice the capacity of IPv6 in the process? Don't they ever learn? Is there a safe and conservative way of allocating IPv6 address space? Yes. Set the first 96 bits to zero, and set the remaining 32 to the current IPv4 addresses. When that runs out, set the first 95 bits to zero, set the 96th bit to one, and use the remaining 32 bits for another IPv4 address space. And so on. A space of 128 bits will last for eternity in this way, and most of the space will remain available for any conceivable future addressing scheme, even those we cannot dream of today. In other words, don't allocate bit spans within the address field, allocate address _ranges_ out of the full 128 bits. But I know that won't happen. However, perhaps this message will remain archived somewhere so that I can say I told you so when the address space finally runs out (I'm pretty sure I'll still be around--we all will). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf
Re: Making IETF happening in different regions
Jordi, You are speaking about low cost flights. I am sure they are readily available from/to any capital like Madrid, but what about other places. When I want to go from a secondary french city to a secondary city in germany without over the week-end stay (say monday-thursday) the prices can start at 500 euros or more, even if booked three months in advance. What I tried to say is that w.r.t. price, the continent location seems to matter more or less the same than the number of airlines going there. A major city with lot of connecting flights (Minneapolis ;) is much more cheaper to flight to than a secondary city. You seems to agree since you mentioned below European flights between European capitals. --julien On Wednesday 29 March 2006 14:49, JORDI PALET MARTINEZ wrote: Hi Julien, I guess is a question of planning. I tend to book my flights at least 3 months ahead. Then a flight Madrid-Europe-Madrid, for example, could be so law as 80 Euros (replace Europe with Munich, London, Paris, Brussels, or any other preferred EU destination). For the same period (a week, including Saturday night), Madrid-Dallas-Madrid is about 550 Euros. This typically works also just purchasing 5-6 weeks ahead of the flight departure. Regards, Jordi De: Julien Laganier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 29 Mar 2006 14:13:40 +0200 Para: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- julien -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 04:12:24PM -0500, Noel Chiappa allegedly wrote: locators are a lot easier to deal with if they're location-independent Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? I really was talking about locators, not identifiers. Now that I understand what you actually meant, I'm not freaked out! However, you phrased your point in a way that almost guaranteed confusion! You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. This is a problem for PIP-like schemes and mobility. At any point in the network, the locator to use to reach a particular target is unique. However, the locator to use to reach a particular target is different at every point. That would be okay except that when *I* move, the way I address a target changes. That's more of a problem than having to adjust as my target moves. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. This is a problem for PIP-like schemes and mobility. At any point in the network, the locator to use to reach a particular target is unique. However, the locator to use to reach a particular target is different at every point. That would be okay except that when *I* move, the way I address a target changes. well, no. it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 16:17, Keith Moore wrote: it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. - DNS is often out of sync with reality - DNS is slow and unreliable. DNS servers and the links to them do not share fate with the hosts whose RRs they serve. DNS lookup delay is often considerably longer than the RTT to the host. - many networks use other ways of doing name to address mapping for local hosts. - there's no good way for hosts to know their own DNS names - more generally, there's no good way for a host or an app to know what a DNS name means. a DNS name is not irrevocably bound to a particular host for all time, but rather, associates some role or service name with a particular address. a single host may support more than one such role or service at any particular time, but the set of roles or services supported on a host will change over time. - furthermore a single role or service with a single DNS name might be supported on multiple hosts, and DNS be used to specify which hosts are providing that particular service. this might be sufficient on an initial connection when any one of those hosts will do; but this is not sufficient when an app needs to know how to contact a process on a particular one of those hosts. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
We could ask the IEEE, since the relationship between the WiFi folks and IEEE 802.11 seems to be somewhat similar. One of the problems I see is that many of the industry associations (SIP Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus on service providers, not consumers. But an organization such as the SIP Forum could provide a VoIP-optimized label for NAT boxes and maybe even ISPs. Thus, I think we need a separate organization (or work with a separate organization) that does branding and certification. It's hard to buy a non-WiFi device in stores today; the equivalent consumer assurance needs to be true for core consumer and small-business network devices, and possibly services. I don't know how this would work, but if it could be made to work, that might be very helpful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 16:43, Keith Moore wrote: it would be okay if the only apps you needed to run were two- party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. Since when is that any kind of argument? The real questions are whether it CAN work well for this and whether there's something else that can do it better/easier. - DNS is often out of sync with reality Dynamic DNS updates are your friend. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. - there's no good way for hosts to know their own DNS names Again, dynamic DNS updates. When IPv6 materializes where it's impossible to pre-populate the reverse tree and systems generate their own addresses, traditional DNS management will be out the window anyway. - more generally, there's no good way for a host or an app to know what a DNS name means. This one can be problematic but it's not a fundamental problem but rather a local management problem: apps should be able to obtain the local hostname that they can use for referral purposes. This isn't necessarily the same hostname that you'd get from a reverse lookup. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. I wouldn't have a problem with that except that people somehow think that IP addresses DO fulfill all the requirements for being stable references. In traditional IPv4 they did to a large degree, but then NAT came along. With IPv6 a single host routinely has multiple addresses (of more than one scope), and with MIP and shim those addresses change from time to time. IP addresses are what get the packets from point A to point B. That's hard enough. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
it would be okay if the only apps you needed to run were two-party apps. in other words, it's not just users and hosts that need addresses to be the same from everywhere in the network - apps need stable addressing so that a process on host A can say to a process on host B, contact this process on host C at address X and port Y Isn't this the kind of stuff the DNS was invented for? not really. and even to the extent DNS was invented for this, it doesn't work well in practice. Since when is that any kind of argument? The real questions are whether it CAN work well for this and whether there's something else that can do it better/easier. - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. - there's no good way for hosts to know their own DNS names Again, dynamic DNS updates. Doesn't solve the problem, especially when DDNS is done by some DHCP server rather than the host itself. - more generally, there's no good way for a host or an app to know what a DNS name means. This one can be problematic but it's not a fundamental problem but rather a local management problem: apps should be able to obtain the local hostname that they can use for referral purposes. There's no standard way to do this - and the right name can vary from one app to another on the same host. IMHO, DNS is best used as a sort of bootstrapping mechanism - a way for an app to get an initial contact point for some service. After that initial contact is made, DNS is contraindicated. I wouldn't have a problem with that except that people somehow think that IP addresses DO fulfill all the requirements for being stable references. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. In traditional IPv4 they did to a large degree, but then NAT came along. With IPv6 a single host routinely has multiple addresses (of more than one scope), and with MIP and shim those addresses change from time to time. IP addresses are what get the packets from point A to point B. That's hard enough. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. I wasn't talking about stable references - I was talking about references that are valid, for a short time, from anywhere in the network. Stable references are a different problem. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Hi Julien, Well, that's not the case in Spain. If instead of Madrid I'm in small city like Valencia, Murcia, Bilbao, etc., typically the cost different will be only 10-15 Euros more. The companies make the money from the big hop, and if necessary subsidize part of the small one to sell more seats. At the end in any case is not so easy, because it will depend on agreements among airlines, from and to, etc. For example, Minneapolis is more expensive for me, because I need to fly to Amsterdam to get a cheaper fare. Instead Latinamerican cities or a couple of US locations, can be below 400 Euros and even a single hop from Madrid. Definitively, from Europe, for me seems the most expensive Australia, then Asia Pacific/Africa, but may be is only the case of if the from is Spain, because typically I will need to fly first to Amsterdam, London, Paris or Frankfurt. Regards, Jordi De: Julien Laganier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 29 Mar 2006 15:52:09 +0200 Para: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Jordi, You are speaking about low cost flights. I am sure they are readily available from/to any capital like Madrid, but what about other places. When I want to go from a secondary french city to a secondary city in germany without over the week-end stay (say monday-thursday) the prices can start at 500 euros or more, even if booked three months in advance. What I tried to say is that w.r.t. price, the continent location seems to matter more or less the same than the number of airlines going there. A major city with lot of connecting flights (Minneapolis ;) is much more cheaper to flight to than a secondary city. You seems to agree since you mentioned below European flights between European capitals. --julien On Wednesday 29 March 2006 14:49, JORDI PALET MARTINEZ wrote: Hi Julien, I guess is a question of planning. I tend to book my flights at least 3 months ahead. Then a flight Madrid-Europe-Madrid, for example, could be so law as 80 Euros (replace Europe with Munich, London, Paris, Brussels, or any other preferred EU destination). For the same period (a week, including Saturday night), Madrid-Dallas-Madrid is about 550 Euros. This typically works also just purchasing 5-6 weeks ahead of the flight departure. Regards, Jordi De: Julien Laganier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 29 Mar 2006 14:13:40 +0200 Para: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- julien -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the
RE: Stupid NAT tricks and how to stop them.
Jeroen Massar wrote: I guess you missed out on: http://www.iana.org/assignments/ipv6-address-space I declined to co-author it, as a matter of fact. It started as GUSL (Globally Unique Site Locals), did you miss that season? Read the dark side stuff I will post later... Austin Schutz wrote: The limitations of NAT you mention make little difference to most of the NAT users I am familiar with. These are typically end users or small organizations. They generally don't know what they are missing, and NAT works adequately well for their purposes. I don't foresee them switching or enhancing unless there is some killer application as yet unsurfaced which demands it and won't work adequately well with a limited amount of bizarre hacks and workarounds. Point made many times, and the proof is in the pudding: if they're using it so widely it means it works for them. Tim Chown wrote: We have deployed IPv6 in our enterprise (throughout). Michel Py wrote: Could you have done it if you did not have the research dollars^H^H^H^H pounds? While we ironed out many issues with research funding assistance in 6NET, I would say the deployment we have now could be done as part of a natural evolutionary procurement process. I don't see much of this out of the academic community though, save for some in Japan. I note Phillip's extremes of view on IPv6 and DNSSEC. It's interesting to compare how critical these two elements are, and his views on them. Point well taken. And there's always IPv8 ;) Dang, I forgot about this. Why are we deploying IPv6 when Jim has already provided us with the perfect solution :-D Noel Chiappa wrote: Since this old canard has resurfaced again, it's clearly time to drag out some old messages, which I resend every couple of years, and send them around yet again. The executive summary is: The issue with routing table size (and why big ones are Very Bad) is really not the size of the memory needed to hold the table (which is a static thing), but the dynamics - i.e. things like stabilization time after topology changes (and we have real problems there, as all the fancy BGP route-flapping and dampening stuff attests). I know; I made this very point myself in several public presentations. In general, all of these (including extra addresses) have the attribute that you plug this box in at the edge of the network, and don't have to change anything else. *That* is what really sold NAT. Which is why I have said many times that getting rid of NAT requires giving PI. We aren't *ever* going to give everyone PI space (at least, PI space in whatever namespace the routers use to forward packets), any more than we are going to let them take their street addresses with them when they move. Routing (i.e. path-finding) algorithms simply cannot cope with tracking 10^9 individual destinations (see prior message). Noel, I think you're dead wrong on this. This reasoning was valid with 10^8 Hz processors and 10^8 bytes of memory it's no longer true with 10^11 or 10^12 Hz processors and memory (we're almost at 10^10 cheap ones). I'm not saying it's elegant or good engineering or anything, but it will happen. Anthony G. Atkielski wrote: BTW, giving out /64s is one reason why the IPv6 address space will be exhausted in barely more time than was required to exhaust the IPv4 address space. Thomas Narten wrote: This is FUD. Care to back up your assertions with real analysis? FUD it is, don't bother. We all ran the numbers; although retrospectively there could be some good reasons to have more than 128 bits (such as embedding a locator in the address or embedding some crypto, or giving a few more bits to Tony for his GeoPI) we have enough IPv6 for a period of time long enough for me. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29-mrt-2006, at 18:34, Keith Moore wrote: - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. But there is no fundamental reason why it can't be set up correctly and be kept in reasonable sync if people care to do so. DDNS is a great tool for that, and as I wrote in my previous message, almost a requirement with IPv6, but there are other ways to do it as well. - DNS is slow and unreliable. It doesn't have to be, running a decent DNS service isn't rocket science. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. Stable identity needs to happen at a higher level, and rejecting DNS names for this because of a few simple operational difficulties is a bad idea. I wasn't talking about stable references I wasn't talking about long-term stable either, just stable enough to make referrals work. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Point made many times, and the proof is in the pudding: if they're using it so widely it means it works for them. Actually, no. The world is full of examples of practices and mechanisms that are widely adopted and entrenched that work very poorly. You only have to look at any day's newspaper to find evidence of this. The assumption that people have the wisdom to reliably realize what is in their best interests (as individuals or as a group of any size, in the short-term or long-term) is demonstrably false. And the more complex the system, the harder it is for people to use it wisely. Using past mistakes to justify future mistakes is pure foolishness. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
- DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. Of course a big part of the reason that distributed apps (not just p2p apps) don't consistently use DNS is that it doesn't work well. But it's not quite a chicken and egg problem. DNS cannot really work well for referrals. Core design assumptions in DNS no longer apply. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) I'd argue that DNS is NOT good enough for the web, and maybe not good enough for email. When you click on a link and it takes seconds before the page even starts loading, that's probably DNS. Email is less delay sensitive, but when you send mail and it bounces because the MX records were out of sync with reality, DNS is implicated there also. Some p2p apps are unreliable because they are trying to layer over a network that imposes arbitrary restrictions on its use (unlike the IP design that assumes best effort) and on top of hosts that appear and disappear at a whim. Even then, they sometimes work better than client-server apps that try to serve the same purpose. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But by expecting distributed apps to use DNS, you would be imposing the operational constraint that all of those hosts be listed in DNS. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. adding complexity that makes your app less relable is usually not a good way to go. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. no. DNS is just an app that lets other apps find out certain kinds of information about certain resources on the network. It's nowhere nearly flexible enough to be a control plane. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. What I'm saying is that if IP addresses won't be stable enough for referrals in distributed apps, they won't be stable enough for referrals in DNS either. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
Are you saying that ENUM is a dead end? F. -- [EMAIL PROTECTED] 819 692 1383 On Wed, 29 Mar 2006, Keith Moore wrote: - DNS is often out of sync with reality Dynamic DNS updates are your friend. From an app developer's point-of-view, DDNS is worthless. DDNS is far from universally implemented, and when it is implemented, it's often implemented badly. DDNS can actually makes DNS a less reliable source of information about the host. In network operations you always see that stuff that isn't really used is a big mess, because nobody cares to set it up correctly in the first place and/or maintain it after that. Since current peer to peer applications (the applications that use referrals) don't bother with the DNS and for non-servers its only other purpose is looking pretty, it's no surprise that DNS info isn't very good. Of course a big part of the reason that distributed apps (not just p2p apps) don't consistently use DNS is that it doesn't work well. But it's not quite a chicken and egg problem. DNS cannot really work well for referrals. Core design assumptions in DNS no longer apply. Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism. If it's good enough for the web and email, why wouldn't it be good enough for p2p? (Which in itself is often very unreliable.) I'd argue that DNS is NOT good enough for the web, and maybe not good enough for email. When you click on a link and it takes seconds before the page even starts loading, that's probably DNS. Email is less delay sensitive, but when you send mail and it bounces because the MX records were out of sync with reality, DNS is implicated there also. Some p2p apps are unreliable because they are trying to layer over a network that imposes arbitrary restrictions on its use (unlike the IP design that assumes best effort) and on top of hosts that appear and disappear at a whim. Even then, they sometimes work better than client-server apps that try to serve the same purpose. - many networks use other ways of doing name to address mapping for local hosts. Not sure what you mean here. Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS. Because there is little reason for them to be. But by expecting distributed apps to use DNS, you would be imposing the operational constraint that all of those hosts be listed in DNS. But even if that's something that continues to be so, it would still be better to use the DNS when available and use the address otherwise, rather than ignore the DNS completely. adding complexity that makes your app less relable is usually not a good way to go. Using DNS names as identifiers for referrals has problems. Using IP addresses as identifiers for referrals has a different set of problems. But IP addresses are a lot closer than DNS names. With the difference that the DNS is the control plane where you have time to think about stuff, while IP is the data plane where you need to perform millions of lookups per second. no. DNS is just an app that lets other apps find out certain kinds of information about certain resources on the network. It's nowhere nearly flexible enough to be a control plane. But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used. If we can agree which problem should be solved where, then consensus on the details becomes a lot easier. What I'm saying is that the IP address wont be an identifier stable enough to handle referrals in the future, so any protocols that make this assumption won't work very well. What I'm saying is that if IP addresses won't be stable enough for referrals in distributed apps, they won't be stable enough for referrals in DNS either. Keith ___ 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: Stupid NAT tricks and how to stop them.
Iljitsch van Beijnum wrote: ...including the RIR reserves which are at an all time high of nearly 400 million) Also, keep in mind that the RIRs are not the only ones to have reserves. The address space itself has reserves, class E for example. ISPs have reserves, and customer have reserves too (many have been stockpiling). Besides all this, there is a huge waste out there. Last month I ran some interesting numbers; the sample is 115 so I'm not saying this is statistically significant, but I don't think it's too much far off reality either. Here it is: Out of my 115 small business consulting customers (5-300 employees, aDSL/T1/DS3) - Only one has ISDN (leaves in the middle of nowhere; no DSL, cable but no static IP). - 100% use NAT with RFC1918 addresses. - I had to renumber one customer because they merged with another one and both were using 192.168.0.0/24. - 192.168.0.0/24 or 192.168.1.0/24 is the address being used inside 75% of the time. - 50% have basic NAT boxes (generally the smaller ones), the other half have boxes that have some packet inspection/content awareness capabilities. - Out of this half, more-than-basic firewalling is enabled in only 20% even though the box is capable of. - Only one uses a non-NAT proxy server (going away soon) for HTTP surfing. The others who filter content use a content-aware NAT box (typically, a PIX or SonicWall querying a Websense server). It appears that NAT has far less issues than proxy servers. - 90% use a single IP. - 100% have been allocated more than a single IP (/29 being the smallest, /23 the largest) - The average IP use is 1.2 IPs per customer. (a) - The average allocation is 18 IPs per customer. (b) My 115 customers use 146 IP addresses out of the 2104 allocated to them. 93% waste. Just to make it clear: I'm not in denial and v4 exhaustion is not FUD, but the Internet is not going to stop the day after we allocate the last bit of v4 space either. BTW, Michel, you said you were about to return from the dark side in true Star Wars fashion. What gives? :-) If you only knew the power of the dark side ;-) Stay tuned. Michel. (a) This could be reduced to 1.1 by better configuration. Out of the dozen who use more than one IP, half really need only one. There this guy who runs 2 physically different web servers because he has two domain names, ignoring that he could bind multiple IPs to the same machine, run a virtual server, or use HTTP headers like everyone else who hosts thousands of sites on a single machine with cpanel. Also there appears to be a widely spread phenomenon with PIX boxes that use a public IP for each inside host (even though the ports are different); talking with the guys that configured them it looks that PDM makes it easier that way. (b) Multiple factors contribute to this. First, the smallest allocation is a /29; with many ISPs you can't get a single static you have to waste a /29 to use only 1 IP out of it (90% of the sample). Also, I have seen multiple occurrences where the T1 link is on a /30 and the customer is allocated a /28 for the LAN side. However, the way it's configured is that the router NATs out using the address of the T1 interface and the customer block, if used at all, is configured in a loopback for the sole purpose of allowing the ISP's level 1 support to ping it. In several cases the /28 is not even configured anywhere. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why DNS sucks for referrals (was Re: Stupid NAT tricks and how to stop them.)
Francois Menard wrote: Are you saying that ENUM is a dead end? F. -- [EMAIL PROTECTED] 819 692 1383 ENUM is a dead born child. ENUM is supposed to be good for VoIP. Well, I do have VoIP but my VoIP does work allthough ENUM does not. My router could use ENUM - but which one should I ask, e164.arpa or e164.org? Neither of them does know any of my phone numbers. cynikal I am told I could buy the domain that corresponds to one of my phone numbers but I would have to bring in a birth certificate of both me and my landlord to proove legal ownership of that phone number. The gouvernement of germany would hold an election about the matter and if everything was allright I might put my phone number on my tombstone finally. /cynikal In the meantime you can call me on If your VoIP provider talks to sipgate.de +49(6252)750-308 If your phone allows to do that sip:[EMAIL PROTECTED] or via no-ip.com dynamic DNS sip:[EMAIL PROTECTED] Please allow for my local time. It is Québéc + 6 hours or Paris time :) cynikal I guess, right now ENUM could not do that no-ip.com trick. I would have to ask parliament every time my ip changed, to update my A record. /cynikal Hope I was not too cynical. Kind regards Peter et Karine -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
PI space (was: Stupid NAT tricks and how to stop them)
From: Michel Py [EMAIL PROTECTED] We aren't *ever* going to give everyone PI space (at least, PI space in whatever namespace the routers use to forward packets) ... Routing (i.e. path-finding) algorithms simply cannot cope with tracking 10^9 individual destinations (see prior message). I think you're dead wrong on this. This reasoning was valid with 10^8 Hz processors and 10^8 bytes of memory it's no longer true with 10^11 or 10^12 Hz processors and memory (we're almost at 10^10 cheap ones). The last time I heard, the speed of light was still a constant. And the current routing architecture is based on distributed computation. I.e. router A does some computing, passes partial results to router B, which does some more computing, and in turn passes the partial results to router C. After some amount of this back and forth across the network, the route is eventually computed and installed. Needless to say, the real-time taken for this process to complete - i.e. for routes to a particular destination to stabilize, after a topology change which affects some subset of them - is dominated by the speed-of-light transmission delays across the Internet fabric. You can make the speed of your processors infinite and it won't make much of a difference. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote: Now, consider that in that city one does go by street numbers but by building names. As we did for a very long time and many still do. So our building is named by the City Registry Innovation House - and if a day it is scrapped and rebuilt eleswhere everyone will keep calling it (the new) Innovation House (like for Scotland Yard for example). Now, the Room 125 is in Innovation House on _both_ streets. Obviously the zip code is not changed. Your analogy breaks here on the assumption that this is, and indeed needs, to be true for anything but a small number of highly specialized service addresses. A company can change address. As as a minor aside, whilst Scotland Yard, London, will probably arrive at the HQ of the Met, their building is New Scotland Yard. Also, my parents happen to have a house which is formally on two streets, both under two numbers, and indeed has multiple postcodes. (Four, I think). Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Brian E Carpenter wrote: Keith Moore wrote: It will also be a more open process. Today, in my opinion, having to negotiate with each possible sponsor in secret, is a broken concept, and against our openness. I'm a lot more concerned about openness in IETF protocol development. some kinds of negotiations really do need to be done in secret. IMHO, having protocol engineers who know next to nothing about meeting logistics try to dictate such terms is a broken concept. Amen to that. This is a balancing act. How much a host/sponsor is willing to contribute depends on many factors, and I don't believe there is any single formula that will cover all cases. So I think each case will be a special case for a long time to come, and BTW we do have people paid to work on this for us now. Brian Each venue's costs and each Host/Sponsor's ability and willingness to make an additional contribution to a meeting's cost is different. The meeting room costs for Vancouver, Dallas and Montreal were/are zero. The meeting room costs for Paris were well north of 150.000 euros which if that had not been picked up by sponsors could have resulted in a registration fee increase of about $150 per person. Fortunately, we have had such Hosts and Sponsors. It may not always be the case. Ray IAD ___ 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: Stupid NAT tricks and how to stop them.
At 01:28 30/03/2006, Dave Cridland wrote: On Thu Mar 30 00:06:25 2006, JFC (Jefsey) Morfin wrote: Now, consider that in that city one does go by street numbers but by building names. As we did for a very long time and many still do. So our building is named by the City Registry Innovation House - and if a day it is scrapped and rebuilt eleswhere everyone will keep calling it (the new) Innovation House (like for Scotland Yard for example). Now, the Room 125 is in Innovation House on _both_ streets. Obviously the zip code is not changed. Your analogy breaks here on the assumption that this is, and indeed needs, to be true for anything but a small number of highly specialized service addresses. A company can change address. I proposed this to get that response. The main error IMHO of all the IPv6 numbering is to consider eveything has to be the same for everyone. Six global numbering systems have been foreseen. RIRs have one. ITU has said they assume one. Four others can be used. One for space? One for geography? The main reason why all this does not move is that there is no competition between those two and may be others. The role of ICANN is to foster competition in common interest. IPv6 deployment and numbering is now out of IETF, hence to ICANN. If the WSIS has asked ITU to take the lead, it is because ICANN has been unable manage ITU - and possibly create competition. RIRs are in the same situation as NSI when they sold domain names $100 a piece for two years. Would IPv6 addresses be much, much cheaper and easy to get, I am sure many points of this debate would have been already addressed to permit it. As as a minor aside, whilst Scotland Yard, London, will probably arrive at the HQ of the Met, their building is New Scotland Yard. You just confirm what I said above. Addresses can physically move - in the image of street/IPv6 this is equivalent to a change of ISP. Also, my parents happen to have a house which is formally on two streets, both under two numbers, and indeed has multiple postcodes. (Four, I think). You just describe multihoming. All the best. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
At 20:46 29/03/2006, Michel Py wrote: Just to make it clear: I'm not in denial and v4 exhaustion is not FUD, but the Internet is not going to stop the day after we allocate the last bit of v4 space either. The issue is not so much when we will be prevented from doing what we currently do. It is since when are we prevented from doing what we could have done. I think it is a very, very long time ago. Actually http.1.1. is virtual NAT. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: PI space (was: Stupid NAT tricks and how to stop them)
Thus spake Noel Chiappa [EMAIL PROTECTED] From: Michel Py [EMAIL PROTECTED] We aren't *ever* going to give everyone PI space (at least, PI space in whatever namespace the routers use to forward packets) ... Routing (i.e. path-finding) algorithms simply cannot cope with tracking 10^9 individual destinations (see prior message). I think you're dead wrong on this. This reasoning was valid with 10^8 Hz processors and 10^8 bytes of memory it's no longer true with 10^11 or 10^12 Hz processors and memory (we're almost at 10^10 cheap ones). The last time I heard, the speed of light was still a constant. And the current routing architecture is based on distributed computation. I.e. router A does some computing, passes partial results to router B, which does some more computing, and in turn passes the partial results to router C. After some amount of this back and forth across the network, the route is eventually computed and installed. Needless to say, the real-time taken for this process to complete - i.e. for routes to a particular destination to stabilize, after a topology change which affects some subset of them - is dominated by the speed-of-light transmission delays across the Internet fabric. You can make the speed of your processors infinite and it won't make much of a difference. Nothing has changed here. The propogation of an individual route is limited by the speed of light (in fiber or copper), yes, but faster CPUs and bigger memories mean that more of those routes can be propogating at the same time with the same or less effect than a few years ago. The IPv4 core is running around 180k routes today, and even the chicken littles aren't complaining the sky is falling. Compare to how many routes were around pre-CIDR and the resulting chaos. Routers have gotten much, much better since then, and in most cases they're using technology 5+ years behind the PC market (200MHz CPUs, SDRAM, etc.). We'd have to seriously screw up to run afoul of today's limits, and the vendors can easily raise those limits if customers demand it (though they'd much prefer charging $1000 for $1 worth of RAM that's too old to work in a modern PC). S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Iljitsch van Beijnum writes: So how big would you like addresses to be, then? It's not how big they are, it's how they are allocated. And they are allocated very poorly, even recklessly, which is why they run out so quickly. It's true that engineers always underestimate required capacity, but 128-bit addresses would be enough for anything ... IF they were fully allocated. But I know they won't be, and so the address space will be exhausted soon enough. We currently have 1/8th of the IPv6 address space set aside for global unicast purposes ... Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or 42,535,295,865,117,307,932,921,825,928,971,026,432 addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way? It doesn't matter how many bits you put in an address, if you assign them this carelessly. ... with the idea that ISPs give their customers /48 blocks. Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose. Remember, trying to encode information in the address (which is what you are doing when you reserve bit spans) results in exponential (read incomprehensibly huge) reductions in the number of available addresses. It's trivially easy to exhaust the entire address space this way. If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides. Why is this so difficult for people to understand? That gives us 45 bits worth of address space to use up. You're doing it again. It's not 45 bits; it's a factor of 35,184,372,088,832. But rest assured, they'll be gone in the blink of an eye if the address space continues to be mismanaged in this way. It's generally accepted that an HD ratio of 80% should be reachable without trouble, which means we get to waste 20% of those bits in aggregation hierarchies. No. It's not 20% of the bits, it's 99.9756% of your address space that you are wasting. Do engineers really study math? This gives us 36 bits = 68 billion /48s. That's several per person inhabiting the earth, and each of those / 48s provides 65536 subnets that have room to address every MAC address ever assigned without breaking a sweat. What happens when MAC addresses go away? How are you providing for the future when you allocate address space based on the past? Why not just leave the address space alone, and allocate only the minimum slice required to handle current requirements? That's another problem of engineers: they think they can predict the future, and they are almost always wrong. What was the problem again? And that's the third problem. Remember also: any encoding of information into the address field (including anything that facilitates routing) exponentially reduces the total number of available addresses. So it might look like 2^128 addresses, but in reality it may be 2^40, or some other very small number, depending on how much information you try to encode into the address. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Making IETF happening in different regions
Title: Re: Making IETF happening in different regions Definitively, from Europe, for me seems the most expensive Australia, thenAsia Pacific/Africa... ... and for those of us on the "outskirts" of Europe, the ratio in flight prices to the US as compared to the EU can easily exceed a factor of two. However, other expenses may be larger in Europe due to the strength of the Euro. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Title: Re: Making IETF happening in different regions these days, many IETFer are from asia. Asia cities also should be a choice. actually, the accommodations in many asia cities are very cheap while the flight price to ASIA is not much different from the price of flight to america or europe. we can eat better in asia. Yao Jiankang - Original Message - From: Yaakov Stein To: [EMAIL PROTECTED] ; ietf@ietf.org Sent: Thursday, March 30, 2006 1:00 PM Subject: RE: Making IETF happening in different regions Definitively, from Europe, for me seems the most expensive Australia, thenAsia Pacific/Africa... ... and for those of us on the "outskirts" of Europe, the ratio in flight prices to the US as compared to the EU can easily exceed a factor of two. However, other expenses may be larger in Europe due to the strength of the Euro. Y(J)S ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 29/03/2006, at 5:10 AM, Scott Leibrand wrote: On 03/28/06 at 7:00am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Agreed, but they reduce the amount of money you must pay to your ISP each month by a factor of ten or more. Your ISP charges you 9 times as much for IPv4 addresses as they do for bandwidth? I'd recommend switching ISPs. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. Not if you don't live in the US. There are no options here that are at all cheap. Usually you get a flat we don't do that. And they don't do v6 either. And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ' draft-ietf-pkix-cert-utf8-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-cert-utf8-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'JavaScript Object Notation (JSON)' to Informational RFC
The IESG has approved the following document: - 'JavaScript Object Notation (JSON) ' draft-crockford-jsonorg-json-04.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Technical Summary JavaScript Object Notation (JSON) is a light-weight, text-based, language-independent, data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document describes the JSON format and includes a media type registration template. Working Group Summary This document is the work of an individual submitter. It was subjected to MIME-types review, but it is has not been reviewed by an IETF working group. MIME-type review comments have been incorporated into the document. Protocol Quality Scott Hollenbeck has reviewed this document for the IESG. The document includes a no derivative works clause. Note to RFC Editor Please change the title of the document. OLD: JavaScript Object Notation (JSON) NEW: The application/json Media Type for JavaScript Object Notation (JSON) Section 6, OLD: Type name: text NEW: Type name: application ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0' to Draft Standard
The IESG has approved the following document: - 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 ' RFC 2613 as a Draft Standard This document is the product of the Remote Network Monitoring Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this RFC is: http://www.ietf.org/rfc/rfc2613.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. Working Group Summary The RMONMIB WG has consensus to publish this document as a Draft Standard. Protocol Quality This document has been reviewed by the RMONMIB WG and implemented by several vendors in network switching equipment. Bert Wijnen has reviewed this document for the IESG. Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/RFC2613-Implementation.txt NOTE: this document was IETF Last Called back in 2003. That IETF Last Call uncovered thatr this document has a normative depency on RFC2021 which was at PS. RFC2021 has been obsoleted by a new revision, which has been approved as DS. This doc is now in RFC-Editor queue: http://www.rfc-editor.org/queue.html#draft-ietf-rmonmib-rmon2-v2 Since the previous IETF Last Call was so long ago, this new IETF Last Call is intended to make everyone aware that the doc is again on the IESG agenda. IANA Note No actions are needed by IANA. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Encapsulation Methods for Transport of Frame Relay Over MPLS Networks' to Proposed Standard
The IESG has approved the following document: - 'Encapsulation Methods for Transport of Frame Relay Over MPLS Networks ' draft-ietf-pwe3-frame-relay-07.txt as a Proposed Standard This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-07.txt Technical Summary This draft describes how a Frame Relay Pseudowire (PW) is used to carry Frame Relay packets over an MPLS network. This enables service providers to offer emulated Frame Relay services over existing MPLS networks. This document specifies the encapsulation of Frame Relay packets within a pseudo wire. Working Group Summary This work has been thoroughly analysed by the working group and there is consensus for the design. Protocol Quality There are many implementations of this protocol, and it is in operational service. Note to RFC Editor (1) Please replace in section 7.2 information field with bit/byte stuffing, frame relay header removed, and FCS removed. with: information field with the following components removed: bit/byte stuffing, frame relay header, and FCS. (2) Please add an informational reference to RFC 3032 at the end of the first sentence below (and an associated bibliographic listing in the references section). 7.7. MPLS Shim EXP Bit Values If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the EXP field of the PW MPLS label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' to Proposed Standard
The IESG has approved the following document: - 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) ' draft-songlee-aes-cmac-prf-128-03.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-prf-128-03.txt Technical Summary Some implementations of IP Security (IPsec) may want to use a pseudo- random function (PRF) derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-CMAC- PRF-128. Working Group Summary This document is an individual submission. It is not affiliated with any IETF Working Group. Protocol Quality AES-CMAC-PRF-128 is one of several choices for the IPsec PRF that can Be negotiated using IKEv1 or IKEv2. We believe that AES-CMAC has been implemented by at least INTEL, Runcom and SAMSUNG, and we believe that other vendors are developing AES-CMAC for their IEEE 802.16e products. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Roadmap for TCP Specification Documents' to Informational RFC
The IESG has approved the following document: - 'A Roadmap for TCP Specification Documents ' draft-ietf-tcpm-tcp-roadmap-06.txt as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt Technical Summary This document contains a roadmap to the RFCs relating to the Internet's TCP. This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. Working Group Summary The advancement of this document is supported by the TCPM WG. Protocol Quality This protocol was reviewed for the IESG by Mark Allman and Jon Peterson Note to RFC Editor OLD: (from section 3.1) Since TCP traditionally (in the absence of ECN) uses losses to infer congestion, there is a rather intimate coupling between congestion control and loss recovery mechanisms. NEW: TCP traditionally treats lost packets as indicating congestion-related loss, and cannot distinguish between congestion-related loss and loss due to transmission errors. Even when ECN is in use, there is a rather intimate coupling between congestion control and loss recovery mechanisms. === OLD: (from section 3.3) A draft that is currently in the RFC Editor's queue for publication [tcpmd5app] deprecates TCP MD5 for use outside BGP. NEW: RFC 4278 deprecates the use of TCP MD5 outside BGP [RFC4278]. Please change [tcpmd5app] to reference RFC 4278. === OLD: (from section 6.4) RFC 2452 S: IP Version 6 Management Information Base for the Transmission Control Protocol (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. NEW: RFC 2452 S: IP Version 6 Management Information Base for the Transmission Control Protocol (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. RFC 2012 is now obsoleted by RFC 4022. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4441 on The IEEE 802/IETF Relationship
A new Request for Comments is now available in online RFC libraries. RFC 4441 Title: The IEEE 802/IETF Relationship Author: B. Aboba, Ed. Status: Informational Date: March 2006 Mailbox:[EMAIL PROTECTED] Pages: 22 Characters: 49624 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iab-ieee-802-rel-05.txt URL:http://www.rfc-editor.org/rfc/rfc4441.txt Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. This memo provides information for the Internet community. This document is a product of the Internet Architecture Board. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4430 on Kerberized Internet Negotiation of Keys (KINK)
A new Request for Comments is now available in online RFC libraries. RFC 4430 Title: Kerberized Internet Negotiation of Keys (KINK) Author: S. Sakane, K. Kamada, M. Thomas, J. Vilhuber Status: Standards Track Date: March 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 40 Characters: 91261 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-kink-kink-11.txt URL:http://www.rfc-editor.org/rfc/rfc4430.txt This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS TRACK] This document is a product of the Kerberized Internet Negotiation of Keys Working Group of the IETF This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4450 on Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents
A new Request for Comments is now available in online RFC libraries. RFC 4450 Title: Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents Author: E. Lear, H. Alvestrand Status: Informational Date: March 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 11 Characters: 23822 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-newtrk-decruft-experiment-03.txt URL:http://www.rfc-editor.org/rfc/rfc4450.txt This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. This memo provides information for the Internet community. This document is a product of the New IETF Standards Track Discussion Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4443 on Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
A new Request for Comments is now available in online RFC libraries. RFC 4443 Title: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author: A. Conta, S. Deering, M. Gupta, Ed. Status: Standards Track Date: March 2006 Mailbox:[EMAIL PROTECTED], none, [EMAIL PROTECTED] Pages: 24 Characters: 48969 I-D Tag:draft-ietf-ipngwg-icmp-v3-07.txt URL:http://www.rfc-editor.org/rfc/rfc4443.txt This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS TRACK] This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
