RE: NATs as firewalls
Recovering three-quarters of an /8 delays the moment of truth by less than a month. Work hard and you might gain a year or even more, but would that year really make a difference? And that is why there will never be a market for IPv4 addresses. Any trading activity can only ever buy a few months of time for the buyer. After that, they have to migrate to IPv6 like everyone else. Eventually, some companies will shut down IPv4 infrastructure and release IPv4 addresses, but that is only going to happen once IPv6 is well and truly proven in their network. In order to shut off a network, 100% of the traffic has to be shifted to a replacement infrastructure. How many of you know of X.25 networks still in operation? --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: NATs as firewalls
[EMAIL PROTECTED] wrote: Can you show me real examples of an RIR repossessing address space? If so, what is stopping them from reclaiming some of those /8s? ARIN regularly repossesses address space according to their treasurer. http://lists.arin.net/pipermail/ppml/2007-March/006129.html This fact is well known to those who regularly attend ARIN meetings and hear the reports on ARIN activities. I think there is a difference between repossession and surrender. Yes, ARIN has policies on the books that nominally cover this case, but quite frankly they can't enforce those policies because they are not the SP who is taking money from a customer. And so a market can and does exist for IPv4 address space, albeit not in the open. I say this having acquired a company in which we viewed their space as an asset, and promptly appropriated it for other uses. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs
Basavaraj Patil wrote: Alex, On 3/14/07 11:47 AM, ext Alexandru Petrescu [EMAIL PROTECTED] wrote: Basavaraj Patil wrote: Hello, A slightly revised version of the I-D is now available at: http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt This revision incorporates changes based on some of the comments made by the directorate. It will be submitted to the ID repository as soon as the gates are opened. Raj, is there a plan to deal with the interoperability issue where the AP tells the Station to auto-configure statelessly and the AR tells it statefully? The AP may send REG-RSP telling the Station to use DHCP. The AR may send an RA telling the Station to use SLAAC. The issue arises when we consider managed and unmanaged hosts as defined by 802.16. Managed hosts are the ones that may use the secondary management connection. Secondary management connection is optional and as we have discussed in the past this is an option in the .16 specs that exists but very likely unused. I can tell you that in the case of Mobile WiMAX the secondary management connection is not used. Ok. I'm wondering whether IEEE can mention to Mobile WiMax that the secondary management connection seems mandatory. Sure that's not IETF matter, but IETF does IPv6, and for IEEE IPv6 config happens only on the SMC (secondary management connection)... complicated. I agree that a BS and the AR should be synchronized in terms of what method is indicated to the MS for address configuration. There may be an interoperability issue, if the two indicators are different. Yes. This issue can of course be considered as a network management issue, where advice could be given to network deployers of AR and AP to configure their networks correctly. Correct. A deployment should be able to ensure that the indication to the MS in the REG-RSP and RA are synchronized. I can add some text in the I-D to ensure that this issue is noted in the address configuration section. Right, this is what I meant. I think it's a good way forward for the IPv6-CS draft until Mobile WiMax and IEEE figure out. And this is a time when both 802.16 is changing (Corrigendum 2 under discussion but still allows AP to indicate to MN what autoconf method to use) and the RA definition is changing (draft-2462bis indicates 'M' flag may not be used, but an 'autonomous' flag instead). What do you think? Do I get this issue correctly? Or is the issue important, less important, etc. This is a valid issue but I think it can be clarified in the I-D itself by recognizing it and recommending that the indication by the BS and AR are synced. We can also mention it to IEEE but that is about the scope of things that we can do. I agree. I have a list of such issues that could be mentioned to IEEE. I'm not talking put requirements to IEEE, just mention the potential issues. Alex __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Warning - risk of duty free stuff being confiscated on the wayto Prague
Maybe they should sell the liquor in small transparent baggies. dbh -Original Message- From: Mark Andrews [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 7:40 PM To: [EMAIL PROTECTED] Cc: IETF discussion list Subject: Re: Warning - risk of duty free stuff being confiscated on the wayto Prague Eric Burger wrote: Guys - This is true (or, supposed to be true) in ALL countries. You go between two sterile environments, and ALL the rules get reset. This isn't a Europe thing, a U.S. thing, or a foobar thing. It's the way airport security works. Sure. But while folk like us probably ought to think of the issuebefore we buy something in Duty Free -- because, after all, we *always* forsee the full range of interaction effects, when making changes to complex systems -- it's not reasonable to expect average travellers to. No warnings. Nothing. At least the last time I bought duty free alcohol, Febuary, the staff warned me before I completed the transaction that I would not get it through security. I luckily have the option of purchasing it when I leaving and picking it up just before immigration and customs. The pre-departure price is also less than the pre-arrival price. Mark They get inside a security perimeter and think they are safe to buy the liquids they could not take through the perimeter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ 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
Game theory and IPv4 to IPv6
The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. An actor can be in one of several states: Unconnected IPv4 connected with own address IPv4-NAT connected with NAT address IPv4/IPv6 connected Dual stack IPv4-NAT/IPv6 connected Dual stack IPv6 connected There are certain costs associated with the various transitions. The benefit of being in the IPv4 or IPv6 network is proportional to the size of the networks. I don't have time to run full simulation runs but my preliminary trials suggest that IPv6 is not relevant to the IPv4 exhaustion issue. The reason is that the participants are all going to cluster into IPv4/IPv6 or IPv4-NAT/IPv6, there is no incentive I can see to transition to the pure IPv6 state and release the IPv4 addresses. Unless you assume that there is a very considerable value to IPv4 over IPv4-NAT all that happens during address exhaustion is that larger and larger proportions of the net disappear behind NATs. In effect you end up with the two speed Internet we want to avoid. Rather than fight the dynamics of a market with a billion participants I believe that we should embrace them and remember that taking IPv4 to end of life is not exactly an unacceptable outcome. The key is to channel people into IPv4-NAT/IPv6 rather than IPv4-NAT. The way that I would go about this is to introduce a gold standard for next generation gateways that provide other features that the consumer is likely to consider desirable. Like being maintenance free, working without the complaints and setup time that current devices require. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 6:26 AM To: ietf@ietf.org Subject: RE: NATs as firewalls Recovering three-quarters of an /8 delays the moment of truth by less than a month. Work hard and you might gain a year or even more, but would that year really make a difference? And that is why there will never be a market for IPv4 addresses. Any trading activity can only ever buy a few months of time for the buyer. After that, they have to migrate to IPv6 like everyone else. Eventually, some companies will shut down IPv4 infrastructure and release IPv4 addresses, but that is only going to happen once IPv6 is well and truly proven in their network. In order to shut off a network, 100% of the traffic has to be shifted to a replacement infrastructure. How many of you know of X.25 networks still in operation? --Michael Dillon ___ 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: Game theory and IPv4 to IPv6
On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. An actor can be in one of several states: Unconnected IPv4 connected with own address IPv4-NAT connected with NAT address IPv4/IPv6 connected Dual stack IPv4-NAT/IPv6 connected Dual stack IPv6 connected Unfortunately most of the rats cannot choose certain states, so the game is fundamentally flawed. The ISPs are keeping the cheese to themselves. Squeak. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Game theory and IPv4 to IPv6
Interesting angle here ;-) The ISPs are keeping the cheese to themselves. But, the current kind of cheese is running out, and is a little stinky in ways. The new kind of cheese is very abundant, but unfortunately comes at an opportunity cost to get to it from here. Looking at this from game theory angle, looks like a setup for a long period of holdoff (protect interests) followed by a massive and rapid flood to the other camp (fight for the new pie ... er ... cheese). (caveat, armchair game theorist ;-) -- Peter Tim Chown [EMAIL PROTECTED] 15.03.07 10:53 To: ietf@ietf.org cc: Subject:Re: Game theory and IPv4 to IPv6 On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. An actor can be in one of several states: Unconnected IPv4 connected with own address IPv4-NAT connected with NAT address IPv4/IPv6 connected Dual stack IPv4-NAT/IPv6 connected Dual stack IPv6 connected Unfortunately most of the rats cannot choose certain states, so the game is fundamentally flawed. The ISPs are keeping the cheese to themselves. Squeak. -- Tim ___ 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: Game theory and IPv4 to IPv6
Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. Yes, because of latency, No because of NAT's. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. [ postgrad hat on ;) ] There is a reason why companies like Demonware (http://www.demonware.net/) exit, they exist solely to provide for a cleanup of the IPv4 mess with NAT's by providing a stable stack that allows them to get around most NAT issues by using mechanisms like STUN. Note that MS has given a very lucrative way of solving this problem by providing Teredo support; games and other programs simply use IPv6, all the NAT issues get solved automagically by Teredo. There are certain costs associated with the various transitions. Latency being the number one problem. Every millisecond extra causes annoyance to users. Unfortunately due to the state of deployment of Teredo relays and other similar techniques these are not usable (yet). The quake approach: client-server works though. P2P is out of the question in many of those cases though. The benefit of being in the IPv4 or IPv6 network is proportional to the size of the networks. I don't have time to run full simulation runs but my preliminary trials suggest that IPv6 is not relevant to the IPv4 exhaustion issue. IPv4 will run out either way. IPv6 won't slow it down for a even a day. Most, if not all, people using IPv6 also have IPv4 connectivity. IPv6 connectivity in general is non-NATted, while IPv4 is behind a NAT. Want to connect to that box behind the NAT? Just use IPv6 and problem solved. Some people tend to just throw around VPN's to those places though. The reason is that the participants are all going to cluster into IPv4/IPv6 or IPv4-NAT/IPv6, there is no incentive I can see to transition to the pure IPv6 state and release the IPv4 addresses. The whole idea of transition is dual-stack. Some people will be on IPv4, others on IPv6. Servers and gateways (SMTP style) will connect them. For instance if you have a IPv6 enabled Quake server (thanks Viagenie) then IPv4 players can also connect to it. Unless you assume that there is a very considerable value to IPv4 over IPv4-NAT all that happens during address exhaustion is that larger and larger proportions of the net disappear behind NATs. In effect you end up with the two speed Internet we want to avoid. No, there is no considerable value of IPv4 over IPv6. There is a considerable value of IPv4 over IPv4 NAT though due this the simple concept called End-To-End, which with IPv6 gets restored so that hosts at least get their own IP address again, avoiding all the rattraps introduced by NAT's. Then again, firewalls can block those people off also again, but that is then the network policy, not because they can't at all do it. (Don't play games at work folks ;) Rather than fight the dynamics of a market with a billion participants I believe that we should embrace them and remember that taking IPv4 to end of life is not exactly an unacceptable outcome. The key is to channel people into IPv4-NAT/IPv6 rather than IPv4-NAT. It also depends on game companies. They should make their games IPv6 compliant so that they at least support it. I am explicitly not saying that they should do IPv6 per default as that will hurt performance in all the cases where quality IPv6 connectivity is unavailable. A toggle to enable it though would be a great step forward. Servers supporting it on the public Internet will then be a second step. The way that I would go about this is to introduce a gold standard for next generation gateways that provide other features that the consumer is likely to consider desirable. Like being maintenance free, working without the complaints and setup time that current devices require. Greets, Jeroen (hoping that Enemy Territory - Quake Wars supports IPv6...) signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Game theory and IPv4 to IPv6
From: [EMAIL PROTECTED] followed by a massive and rapid flood to the other camp (fight for the new pie ... er ... cheese). I thought the whole point of the new cheese was that there was going to be enough of it that there would never be any reason to fight over it... :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Game theory and IPv4 to IPv6
So the rational choice actors here are the ISPs not the end-users. Build that constraint into the model. -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 10:53 AM To: ietf@ietf.org Subject: Re: Game theory and IPv4 to IPv6 On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. An actor can be in one of several states: Unconnected IPv4 connected with own address IPv4-NAT connected with NAT address IPv4/IPv6 connected Dual stack IPv4-NAT/IPv6 connected Dual stack IPv6 connected Unfortunately most of the rats cannot choose certain states, so the game is fundamentally flawed. The ISPs are keeping the cheese to themselves. Squeak. -- Tim ___ 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
Non-priority baggage handling (Re: Warning - risk of duty free ...)
So, one of the perqs in flying business class that I find useful is to have my baggage get that extra, spiffy 'priority' tag. Often saves 30-60 minutes. Just arrived in Praha and from what I could see, all the bags labeled that way came off *last*. Some residue of the previous regime? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Game theory and IPv4 to IPv6
An actor can be in one of several states: You rigged the list of states. There is more than one possible state that include IPv6 connected as the baseline. For instance, IPv6 connected with access to 6/4 web proxy and 6/4 smtp forwarder. There are other possibilities. Consider a large community of users (community meaning they communicate a lot with each other) who have such an IPv6 service. They can freely use IPv6 supporting applications with no NAT worries. Access to the v4 Internet is restricted but no more so than in the average v4 corporate network. Now what if that large community of users is a country where people do not speak one of the world's top ten languages. The game is too complex for game theory to analyze since it is too hard to get the right list of states. Rather than fight the dynamics of a market with a billion participants I believe that we should embrace them and remember that taking IPv4 to end of life is not exactly an unacceptable outcome. The key is to channel people into IPv4-NAT/IPv6 rather than IPv4-NAT. I would be slightly less specific and say that we should channel people into IPv6-gateway-IPv4, meaning that they get IPv6 connectivity but some sort of gateway support services to access IPv4 hosts. Those gateway support services will probably be a whole smorgasbord of things including Teredo and simple dual-stack proxy servers. Perhaps the pioneers will be those ISPs who currently offer some sort of managed/restricted service such as Family Safe Internet or Christian Net. It doesn't matter who takes the first steps. Once the technical principle is shown to be workable and profitable, others will adopt it. The way that I would go about this is to introduce a gold standard for next generation gateways that provide other features that the consumer is likely to consider desirable. Like being maintenance free, working without the complaints and setup time that current devices require. I agree that those are desirable goals for the gateway standard. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Warning - risk of duty free stuff being confiscated on thewaytoPrague
Maybe the airlines should simply shut down the duty free shops and send every passenger a discount coupon for $10 off a bottle of booze bought in their local liquor store. The policy is not specific to duty free. I was caught by it last month during a domestic trip in France. I had bought Armagnac from a local producer in the South of France, and was flying bag to Paris. Luckily, the registration mentioned the policy, and gave me time to stuff the bottle in my checked-in suitcase. The rule is simple: you cannot bring a container greater than 100 cc, about 3 oz, in an airplane through security. You can bring several containers of lower capacity than 100 cc, but the combined capacity of these container is limited; they have to all fit in a 1 liter plastic bag. The theoretical rationale for the rule imagines terrorists mixing products in a bottle. Each of the products is supposedly harmless, or at least not detected by airport security machines, but the combined result is explosive. By limiting the capacity of the container, the security folks hope to limit the potential of any device fabricated aboard the plane. Those of us who have toiled through chemistry labs may find the all idea somewhat theoretical. You may remember the dire warnings of the teachers about what happens if you fail to control a reaction, if you let it overheat, or if you shake it a little too much. You may consider the improbability of repeating the experience in the shaky cramped space of an airliner's toilet. But then, you would not have the same mindset as the airline security folks. Given the rationale, I am still puzzled by the fact that bottles bought after the security check are allowed on board. Probably has to be a compromise between air traffic security and airport economics. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-priority baggage handling (Re: Warning - risk of duty free ...)
I get the priority tag, because I'm Premium level. The only airport I've seen actually honor that tag is Singapore. San Francisco doesn't care, and neither did Paris nor London. Neither, come to think of it, did Frankfurt. On 3/15/07, Dave Crocker [EMAIL PROTECTED] wrote: So, one of the perqs in flying business class that I find useful is to have my baggage get that extra, spiffy 'priority' tag. Often saves 30-60 minutes. Just arrived in Praha and from what I could see, all the bags labeled that way came off *last*. Some residue of the previous regime? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-priority baggage handling (Re: Warning - risk of duty free ...)
Clint Chaplin wrote: I get the priority tag, because I'm Premium level. The only airport I've seen actually honor that tag is Singapore. San Francisco doesn't care, and neither did Paris nor London. Neither, come to think of it, did Frankfurt. You mean they marked but have only a single queue? What sort of SLA were you given? ;-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Game theory and IPv4 to IPv6
Not sure I'm phrasing this correctly in this context, but I don't think that service providers are the rational choice actors in this scenario - any more than equipment vendors are. It seems to me the main actors in applying gaming to this problem are still the end users. It is the case that their actions are limited by multiple levels of indirection, since end users affect service provider choices (via service selection), which then affects vendor choices (via equipment purchases). In the actor mix are equipment vendors (who must justify RD expenses in terms of their customer willingness to spend money), service providers (who likewise need to justify the amortization of capital expenses and the expected additional operating costs in terms of their own customer's willingness to spend money) and end users (whose willingness to spend money on both services and equipment is somewhat vaguely assumed). On the flip side, the services that a service provider may offer are limited by the capabilities of the equipment that vendors provide and - obviously - the services end users may choose are limited by what's offered to them by service providers. I suspect that what makes this hard to use predictively in general is an entirely subjective guess that has to be made with respect the degree of flexibility the actors have in accepting choices presented to them by other actors. At what point will end-users choose no services over any of the service options presented to them? At what point will service providers, end-users, or both, choose not to buy any equipment over the equipment choices presented to them? -- Eric Gray Principal Engineer Ericsson -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:58 AM To: Tim Chown; ietf@ietf.org Subject: RE: Game theory and IPv4 to IPv6 So the rational choice actors here are the ISPs not the end-users. Build that constraint into the model. -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 10:53 AM To: ietf@ietf.org Subject: Re: Game theory and IPv4 to IPv6 On Thu, Mar 15, 2007 at 07:37:26AM -0700, Hallam-Baker, Phillip wrote: The problem is that until IPv6 has critical mass it is much better to be on IPv4 than IPv6. If there are any grad students reading the list take a look at the game theory literature and apply it to the transition. Assume that it's a rat-choice world and that each actor follows their best interest. An actor can be in one of several states: Unconnected IPv4 connected with own address IPv4-NAT connected with NAT address IPv4/IPv6 connected Dual stack IPv4-NAT/IPv6 connected Dual stack IPv6 connected Unfortunately most of the rats cannot choose certain states, so the game is fundamentally flawed. The ISPs are keeping the cheese to themselves. Squeak. -- Tim ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IASA related reports available
All - Please see: http://iaoc.ietf.org/ and watch this site for updates. See you in Prague! - Lucy _ llynch @civil-tongue.net llynch on jabber.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Non-priority baggage handling (Re: Warning - risk of duty free ...)
There is no SLA regarding the priority tags on bags. I've found that most airports ignore them, so I'm always pleasantly surprised when the priority bags come out first. For the most part, my experience has been that bags tend to show up in LIFO order, so you're being rewarded for checking in late. :-) Cheers, Andy On 3/15/07, Eliot Lear [EMAIL PROTECTED] wrote: Clint Chaplin wrote: I get the priority tag, because I'm Premium level. The only airport I've seen actually honor that tag is Singapore. San Francisco doesn't care, and neither did Paris nor London. Neither, come to think of it, did Frankfurt. You mean they marked but have only a single queue? What sort of SLA were you given? ;-) ___ 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: Game theory and IPv4 to IPv6
Hallam-Baker, Phillip wrote: there is no incentive I can see to transition to the pure IPv6 state and release the IPv4 addresses. Just FYI, INTERNET DRAFT M. Ohta draft-ohta-address-allocation-00.txt Tokyo Institute of Technology Geoff Huston Telstra Corporation Masaki Hirabaru Merit Network, Inc. Jun Murai Keio University May 2000 Usage Based Address Allocation Considered Harmful The More Restricted Assignment Plan No IPv4 address space should be allocated to an ISP, unless the ISP support fully operational fully transparent IPv6 service with at least 64K IPv6 subnets to all the end users. Masataka Ohta PS Your mistake is insisting on release of IPv4 addresses, even though exhaustion of IPv4 addresses is an incentive for IPv6 transition. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Non-priority baggage handling (Re: Warning - risk of duty free...)
Let us assume that there is no special truck to take the baggage from the plane to the collection point. If there is only one truck the best-case benefit of a prioity tag is limited to the time it takes for the guy to put the bags on the belt. From: Andrew G. Malis [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 4:19 PM To: Eliot Lear Cc: IETF discussion list; [EMAIL PROTECTED] Subject: Re: Non-priority baggage handling (Re: Warning - risk of duty free...) There is no SLA regarding the priority tags on bags. I've found that most airports ignore them, so I'm always pleasantly surprised when the priority bags come out first. For the most part, my experience has been that bags tend to show up in LIFO order, so you're being rewarded for checking in late. :-) Cheers, Andy On 3/15/07, Eliot Lear [EMAIL PROTECTED] wrote: Clint Chaplin wrote: I get the priority tag, because I'm Premium level. The only airport I've seen actually honor that tag is Singapore. San Francisco doesn't care, and neither did Paris nor London. Neither, come to think of it, did Frankfurt. You mean they marked but have only a single queue? What sort of SLA were you given? ;-) ___ 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
Protocol Action: 'RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)' to Proposed Standard
The IESG has approved the following document: - 'RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) ' draft-ietf-rohc-tcp-16.txt as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-16.txt Technical Summary This document specifies a ROHC (RObust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. Working Group Summary This document has been in the workings for several years. It first appeared as an official WG draft in January 2002, and has since then changed shape a couple of times. It has now been rather stable for a long time, it has been carefully reviewed by both the WG and externals, and there is WG consensus that the document should now be published as an RFC. Protocol Quality The document has been both manually reviewed by several parties with different perspectives, and checked by automated tools. During WGLC, the document was reviewed by the committed WG reviewers Joe Touch and Ted Faber, as well as by Sally Floyd, who provided a review at the request of the Transport Area Directorate. Personnel Document Sheperd for this document is Lars-Erik Jonsson, and Magnus Westerlund is the Responsible Area Director. Note to RFC Editor Please update reference [RFC2001] to use RFC 2581 instead. Section 6.1.3: OLD: 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. The design rationale behind this is the possible use of the full- functionality option of section 9.1 of [RFC3168]. *** NEW: 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of all IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. When there is only one IP header present in the packet (i.e. no IP tunneling is used), this compression behavior allows the compressor to handle changes in the ECN bits by adding a single octet to the compressed header. The reason for including the ECN bits of all IP headers in the compressed packet when the control field is set is that the profile needs to efficiently compress flows containing IP tunnels using the full- functionality option of section 9.1 of [RFC3168]. For these flows, a change in the ECN bits of an inner IP header is propagated to the outer IP headers. When the limited-functionality option is used, the compressor will therefore sometimes send one octet more than necessary per tunnel header, but this has been considered a reasonable tradeoff when designing this profile. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'XML Pipelining with Chunks for the Information Registry Information Service' to Proposed Standard
The IESG has approved the following document: - 'XML Pipelining with Chunks for the Information Registry Information Service ' draft-ietf-crisp-iris-xpc-06.txt as a Proposed Standard This document is the product of the Cross Registry Information Service Protocol Working Group. The IESG contact persons are Ted Hardie and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-xpc-06.txt Technical Summary This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transfered between clients and servers using chunks to achieve pipelining. Working Group Summary There was consensus in the working group for publication of this document. There were IETF Last Call comments and the document has been updated as a result. Protocol Quality This document was reviewed for the IESG by Ted Hardie. April Marine is the Shepherd. Note to RFC Editor In Section 7: OLD 7. Idle Sessions An XPC session may become idle between request/response transactions. This can occur when a server honors a client's request to keep the TCP connection running (see the keep-open or KO flag in the block header (Section 5)). Servers are not expected to allow XPC sessions remain idle between requests indefinitely. Clients MUST use the keep-alive feature of TCP to keep the connection active during idle periods. If a server has not received a request block after sending a response block (either RSB or CRB) and the TCP connection fails to keep-alive, it SHOULD do the following: 1. Send an unsolicited response block containing an idle timeout error (see 'idle-timeout' in Section 6.4) with the keep-open (or KO) flag in the block header (Section 5) set to a value of 0. 2. Close the TCP connection. NEW 7. Idle Sessions If a server needs to close a connection due to it being idle, it SHOULD do the following: 1. Send an unsolicited response block containing an idle timeout error (see 'idle-timeout' in Section 6.4) with the keep-open (or KO) flag in the block header (Section 5) set to a value of 0. 2. Close the TCP connection. The document also currently has the following normative reference: [10] Kirkpatrick, S., Stahl, M., and M. Recker, Internet numbers, RFC 1166, July 1990. This reference is an informative reference to the origin of a format, and is not needed to implement or understand the format. Please create an Informative references section, and move this reference there. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Extensions to OSPF for Advertising Optional Router Capabilities' to Proposed Standard
The IESG has approved the following document: - 'Extensions to OSPF for Advertising Optional Router Capabilities ' draft-ietf-ospf-cap-10.txt as a Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-10.txt Technical Summary It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or AS). Working Group Summary There was WG Consensus to advance this document. Protocol Quality Bill Fenner and Rohit Dube (PROTO shepherd) have reviewed this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service' to Proposed Standard
The IESG has approved the following document: - 'A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service ' draft-ietf-crisp-iris-lwz-08.txt as a Proposed Standard This document is the product of the Cross Registry Information Service Protocol Working Group. The IESG contact persons are Ted Hardie and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-lwz-08.txt Technical Summary This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. Working Group Summary There was consensus in the working group to publish this document. There were comments during IETF Last Call, and the doucment has been updated. Protocol Quality This document was reviewed for the IESG by Ted Hardie. April Marine is the document Shepherd. Note to RFC Editor Reference [10] in the document, to RFC 1166, documents the origin of the convention cited in the text, but it is not needed to implement this document or understand the convention. Please create an INFORMATIONAL references section in the draft and move it there. In Section 4: OLD If a client does not know the path MTU or does not use the packet size recommendations above, the client MUST allocate or have allocated dedicated network resources that will ensure fairness to other network packets and avoid packet fragmentation. For retransmission of requests considered to be unanswered, a client SHOULD retransmit using a timeout value initially set to 1 second. This timeout value SHOULD be doubled for every retransmission, and it a client SHOULD not retransmit any request once the timeout value has reached 60 seconds. If the next query the client sends is to the same server, it SHOULD start with the last timeout value used. NEW For retransmission of requests considered to be unanswered, a client SHOULD retransmit using a timeout value initially set to 1 second. This timeout value SHOULD be doubled for every retransmission, and it a client SHOULD not retransmit any request once the timeout value has reached 60 seconds. Also in Section 4: OLD Finally, if a client intends multiple requests to the same server in a short amount of time, this protocol offers no real advantage over IRIS-XPC [9]. In such a case, IRIS-XPC should be used as it would be similarly effecient and would offer greater reponse sizes and allow better security. NEW Finally, if a client intends multiple requests to the same server in a short amount of time, this protocol offers no real advantage over IRIS-XPC [9]. In such a case, IRIS-XPC is RECOMMENDED to be used as it would be similarly or more efficient and would offer greater reponse sizes and allow better security. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A Common Schema for Internet Registry Information Service Transfer Protocols' to Proposed Standard
The IESG has approved the following document: - 'A Common Schema for Internet Registry Information Service Transfer Protocols ' draft-ietf-crisp-iris-common-transport-05.txt as a Proposed Standard This document is the product of the Cross Registry Information Service Protocol Working Group. The IESG contact persons are Ted Hardie and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-common-transport-05.txt Technical Summary This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. Working Group Summary The working group came to consensus to publish this document. There were comments during IETF Last Call, and the document has been updated. Protocol Quality This document was reviewed for the IESG by Ted Hardie. The document Shepherd is April Marine. Note to RFC Editor In the IANA Considerations section, please add the following text before the Schema: Updates or changes to this Schema require a document that UPDATES or OBSOLETES this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A URN Namespace for GEANT' to Informational RFC
The IESG has approved the following document: - 'A URN Namespace for GEANT ' draft-kalin-geant-urn-namespace-01.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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kalin-geant-urn-namespace-01.txt Technical Summary This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European RE networks, its projects, activities, working groupsand other designated subordinates.(What does this protocol do and why does the community need it?) Working Group Summary This document was not produced by an IETF working group. Protocol Quality The document was reviewed by the URN NID list. The Responsible area director is Ted Hardie. Note to RFC Editor OLD: other = ( / ) / + / , / - / . / = / @ / ; / $ / _ / ! / * / ' NEW: other = ( / ) / + / , / - / . / = / @ / ; / $ / _ / ! / * / ' Please also update: [2] Crocker, D. and P. Overell, Augmented BNF for Syntax Specifications: ABNF, RFC 2234, November 1997. to RFC 4234. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4791 on Calendaring Extensions to WebDAV (CalDAV)
A new Request for Comments is now available in online RFC libraries. RFC 4791 Title: Calendaring Extensions to WebDAV (CalDAV) Author: C. Daboo, B. Desruisseaux, L. Dusseault Status: Standards Track Date: March 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 107 Characters: 206801 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-dusseault-caldav-15.txt URL:http://www.rfc-editor.org/rfc/rfc4791.txt This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the calendar-access feature of CalDAV. [STANDARDS TRACK] 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A URN Namespace for GEANT' to Informational RFC
The IESG has approved the following document: - 'A URN Namespace for GEANT ' draft-kalin-geant-urn-namespace-01.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 Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kalin-geant-urn-namespace-01.txt Technical Summary This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European RE networks, its projects, activities, working groupsand other designated subordinates.(What does this protocol do and why does the community need it?) Working Group Summary This document was not produced by an IETF working group. Protocol Quality The document was reviewed by the URN NID list. The Responsible area director is Ted Hardie. Note to RFC Editor OLD: other = ( / ) / + / , / - / . / = / @ / ; / $ / _ / ! / * / ' NEW: other = ( / ) / + / , / - / . / = / @ / ; / $ / _ / ! / * / ' Please also update: [2] Crocker, D. and P. Overell, Augmented BNF for Syntax Specifications: ABNF, RFC 2234, November 1997. to RFC 4234. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4790 on Internet Application Protocol Collation Registry
A new Request for Comments is now available in online RFC libraries. RFC 4790 Title: Internet Application Protocol Collation Registry Author: C. Newman, M. Duerst, A. Gulbrandsen Status: Standards Track Date: March 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 26 Characters: 55591 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-newman-i18n-comparator-14.txt URL:http://www.rfc-editor.org/rfc/rfc4790.txt Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS TRACK] 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. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Informational RF
The IESG has approved the following document: - 'PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering ' draft-ietf-pce-pcecp-interarea-reqs-05.txt as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-05.txt Technical Summary This document lists a detailed set of requirements for the Path Computation Element Communication Protocol for support of inter- area TE-LSP path computation. This specifically applies to paths that cross multiple areas within a single IGP routing domain. It complements the generic requirements for a PCE Communication Protocol. Working Group Summary no dissent reported. Protocol Quality Ross Callon has reviewed this spec for the IESG. As a requirements document, it inherently isn't implemented, but there is ongoing work to update the PCE Communications Protocol to handle inter-area path computation consistent with these requirements. Note to RFC Editor The email address for Nabil Bitar (in section 11 contributors' addresses) should be [EMAIL PROTECTED] Please replace the second paragraph of section 5 (Manageability Considerations) as follows: Old Text (one paragraph to be removed): A built in diagnostic tool MUST be defined to monitor the performances of a PCE chain, in case of multiple-PCE inter-area path computation. It MUST allow determining the minimum maximum and average response time globally for the chain, and on a per PCE basis. New Text (two paragraphs to be added): It is really important, for diagnostic and troubleshooting reasons, to monitor the availability and performances of each PCE of a PCE chain used for inter-area path computation. Particularly it is really important to identify the PCE(s) responsible for a delayed reply. Hence a mechanism MUST be defined to monitor the performances of a PCE chain. It MUST allow determining the availability of each PCE of the chain as well as its minimum maximum and average response time. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
68th IETF - Agenda Changes
The following changes have been made since the agenda was printed. The web version of the agenda is up to date. CANCELLED rpsec - was scheduled on Tuesday at 1740-1840 2nd Hour CANCELLED tcpm - the second hour ONLY was cancelled on Tuesday at 1850-1950 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
