Re: eating our own dogfood...Re: IPv4 Outage
On Wed, 19 Dec 2007, Mark Andrews wrote: Only B is playing up at the moment. That is not an IPv6 problem. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ PORTLAND PLYMOUTH: EAST 5 OR 6, OCCASIONALLY 7. MODERATE OR ROUGH. MAINLY FAIR. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
On 19 dec 2007, at 6:27, Bill Manning wrote: I point to the the RSSAC(*) meeting minutes from Chicago and Vancouver for the ICANN statements as to why the records for the root servers have not been added to date. http://www.rssac.org/meetings/04-08/RSSAC28.pdf : 4 - support - David The report was received and the technical issues are not an issue - this is a policy issue and no one from the 2 policy group is here. The question is raised, what else does the IANA need and when can it ask? The IANA GM does 3 not have the right questions to ask internally. Who are we/IANA waiting on? We are waiting on the executive staff at 4 ICANN. Not clear if there are other hurdles to jump after that is done. 5 http://www.rssac.org/meetings/04-08/rssac29.pdf : IPv6 status: (Bill Manning) 2 Not much has changed since our last meeting. At least four of the root server operators have demonstrated IPv6 3 capability and have formally requested that ICANN add them to the root. This is based on the RSSAC/SSAC joint 4 recommendation that said that this is OK to do. At the last meeting, the IANA general manager said that it's in 5 ICANN's executive/policy committee. We'd really like some feedback from either IANA or ICANN about when the 6 requests will be processed. A formal request will be sent from RSSAC to ICANN asking for the requests to be 7 processed. This will not be a public announcement. 8 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Yes, right now IPv6 deployment isn't good enough that we can't do this without using all sorts of workarounds. OK, let's document those workarounds and make them available to the attendees. If it means that the IETF network provider has to hijack the root, then let them hijack the root on the IETF network, and document that fact. If there needs to be NAT-PT bridges to allow IETF'res to get back to their home networks connected to ISP's that don't yet offer IPv6 connectivty, then let there be NAT-PT bridges --- and document them. If various Windows, Macintosh, and Linux laptops need special configuration so to work around other problems, then document what the workarounds should be, and give people early warning and access to them. This is the best suggestion that I have seen in this whole thread. Build it, test it, get it ready for production and then unleash it on the IETF themselves. All documented so that any network operator who claims that it is impossible can be given a copy of the recipe book. IPv6 could have been ready to go years ago, but people got used to pushing it down the priority list thinking that it was a long term thing and it would be easier to deal with it later. That was true to a point, but now IPv4 exhaustion means that IPv6 is no longer a long term thing that can be repeatedly deprioritised. We have to deal with it now, even if everything isn't as ready as we had hoped. (Or maybe the IPv4 network can be made available over the wireless on a separate SSID with a fee attached, That sounds a bit draconian. Since it is pretty straightforward to tunnel IPv4 over IPv6, give them the IPv4 SSID and a walled-garden web server where they register for free use of the tunneling service. Then monitor your outgoing traffic (100% IPv6) and record how much of it uses this tunnel service. For this to work, it needs to be virtually painless for all users including those who have a pure IPv4 environment and no capability to use IPv6 in any form whatsoever. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
Wow, that is a rather lackadisical attitude being shown by the ICANN, isn't it? I can't help thinking that if Jon Postel were still around, things would be moving a tad bit faster --- i.e., measured in minutes rather than at least months. Hmm, perhaps years; on an IANA page I see a paper authored Ronald van der Pol and some other RIPE folks indicating that they had shown it was safe to add records to the root zone, published October 2003. One would hope that they will act by the December 18th ICANN board meeting, and that any other bureaucratic hurdles would be addressed sooner rather than later. But if not, as ugly as it would have to be for the IETF to have to substitute root zone records just for the purpose of adding records for IPv6 DNS root zone servers for the March 2008 meeting, and as unfortunate as a precedent as that might set, it will have meant that ICANN will have dithered for NINE MONTHS over what seems to be a simple issue of adding IPv6 records, which means something is seriously wrong over at ICANN, and we should just fix the problem the way engineers know how to fix the problem, and let the political problem fix itself... whenever. After all, if waiting at least 9 months hasn't helped, is there any evidence that waiting another 9 months would help any more? At the end of the day, either we're serious about IPv6 or we're not. - Ted P.S. Funny, looking at the ICANN board, I have to say that I'm surprised. The board contains names like Harald Alvaestrand, Steve Crocker, Thomas Narten, in addition to the usual Lawyers and VC's. P.P.S. Obviously, this is me speaking as an individual, not with any IETF hat on, or on behalf of my employer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
On Wed, Dec 19, 2007 at 07:27:55AM -0500, Theodore Tso wrote: But if not, as ugly as it would have to be for the IETF to have to substitute root zone records just for the purpose of adding records for IPv6 DNS root zone servers for the March 2008 meeting Let me make it clear that I would only be suggesting this on the IETF conference network, and not making any more public than that. i.e., doing what is necessary to make a fully functional IPv6 network. This is really no different than what many companies do to the DNS for their intranet --- which maybe is a horrible idea from a BIND perspective, but is in fact quite common (where www.example.com or w3.example.com might look very different inside or outside the intranet). And if it causes some embarassing articles about ICANN to show up in the trade press, I guess at this point I wouldn't mind, terribly. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF71 hotel noise warning on Marriott web pages
On Tue, Dec 18, 2007 at 01:45:24PM -0500, John C Klensin [EMAIL PROTECTED] wrote a message of 57 lines which said: Between this and apparent efforts by the IAOC, IESG, and sponsor to deliberately disrupt the network, this is beginning to sound like the meeting to miss. I am not old enough to have personal experience of the oldest IETF meetings but I've heard that there was no Internet connectivity at all at these times and yet the IETF was able to work. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
At Tue, 18 Dec 2007 12:39:32 -0800, David Kessens wrote: Basically, anybody who cannot survive without 60 minutes of network connectivity during an IETF and who has not taken measures to provide for backup connectivity during *any* outage cannot be taken serious. Of course one can survive 60 minutes of network outage. I could also survive a broken finger, but I'm still carefeful when I use a hammer. Just because people could survive an outage is no reason to inflict one on ourselves. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, Dec 19, 2007 at 07:30:31AM -0800, ext Eric Rescorla wrote: At Tue, 18 Dec 2007 12:39:32 -0800, David Kessens wrote: Basically, anybody who cannot survive without 60 minutes of network connectivity during an IETF and who has not taken measures to provide for backup connectivity during *any* outage cannot be taken serious. Of course one can survive 60 minutes of network outage. I could also survive a broken finger, but I'm still carefeful when I use a hammer. Just because people could survive an outage is no reason to inflict one on ourselves. This issue will only develop into an outage if you bring the wrong survival tools: I suggest you leave your hammer home and make sure that you can use ipv6 only. There is no rocket science here. People have done this before. David Kessens PS If there is a need for hammers in order to break fingers or to make ipv6 working, I suspect one can easily borrow one from the construction crews --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, 19 Dec 2007, David Kessens wrote: PS If there is a need for hammers in order to break fingers or to make ipv6 working, I suspect one can easily borrow one from the construction crews --- OK, since we're so close to the holidays and so far off topic already: Clearly you've never dealt with construction crews. Easily is not a concept they are familiar with ;-) Ole ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
At Wed, 19 Dec 2007 08:07:10 -0800, David Kessens wrote: On Wed, Dec 19, 2007 at 07:30:31AM -0800, ext Eric Rescorla wrote: At Tue, 18 Dec 2007 12:39:32 -0800, David Kessens wrote: Basically, anybody who cannot survive without 60 minutes of network connectivity during an IETF and who has not taken measures to provide for backup connectivity during *any* outage cannot be taken serious. Of course one can survive 60 minutes of network outage. I could also survive a broken finger, but I'm still carefeful when I use a hammer. Just because people could survive an outage is no reason to inflict one on ourselves. This issue will only develop into an outage if you bring the wrong survival tools: I suggest you leave your hammer home and make sure that you can use ipv6 only. There is no rocket science here. People have done this before. Absolutely they have, but I don't see why we should be put into a situation where I need to have survival tools. Again, what is the value of this experiment? Since I seem to be into analogies this morning, let me try another one. When we were in YVR, there were water turbidity issues and people were told not to drink the water out of the tap. The hotel supplied bottled water. If we were to hear tomorrow that due to the renovations the hotel water was to be unpotable, would your answer be that they should fix that or that each IETFer should bring a survival tool in the form of a water filter? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, Dec 19, 2007 at 08:17:17AM -0800, Eric Rescorla wrote: Absolutely they have, but I don't see why we should be put into a situation where I need to have survival tools. Again, what is the value of this experiment? Since I seem to be into analogies this morning, let me try another one. When we were in YVR, there were water turbidity issues and people were told not to drink the water out of the tap. The hotel supplied bottled water. If we were to hear tomorrow that due to the renovations the hotel water was to be unpotable, would your answer be that they should fix that or that each IETFer should bring a survival tool in the form of a water filter? If water problems occur regularly, it seems prudent to bring a waterfilter. If you are traveling and experience frequent problems with connectivity and you believe that 60 minutes without it could lead to fatalities it might be wise to bring backup gear. However, this is really beside the point: there is not going to be any break in connectivity, there will be plenty of ipv6 available. And on another topic, I would hope that (members of) the IAB will spend the same amount of time and energy as used on this discussion on more important topics like to get ICANN to have ipv6 and DNSSEC root service available before the next IETF meeting. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
Ted, We're serious about IPv6. Unless something really unexpected occurs (e.g., the Internet breaks when we insert s into the root hints), IPv6 addresses will be available for root service via the normal mechanisms significantly before the next IETF. Regards, -drc On Dec 19, 2007, at 4:27 AM, Theodore Tso wrote: Wow, that is a rather lackadisical attitude being shown by the ICANN, isn't it? I can't help thinking that if Jon Postel were still around, things would be moving a tad bit faster --- i.e., measured in minutes rather than at least months. Hmm, perhaps years; on an IANA page I see a paper authored Ronald van der Pol and some other RIPE folks indicating that they had shown it was safe to add records to the root zone, published October 2003. One would hope that they will act by the December 18th ICANN board meeting, and that any other bureaucratic hurdles would be addressed sooner rather than later. But if not, as ugly as it would have to be for the IETF to have to substitute root zone records just for the purpose of adding records for IPv6 DNS root zone servers for the March 2008 meeting, and as unfortunate as a precedent as that might set, it will have meant that ICANN will have dithered for NINE MONTHS over what seems to be a simple issue of adding IPv6 records, which means something is seriously wrong over at ICANN, and we should just fix the problem the way engineers know how to fix the problem, and let the political problem fix itself... whenever. After all, if waiting at least 9 months hasn't helped, is there any evidence that waiting another 9 months would help any more? At the end of the day, either we're serious about IPv6 or we're not. - Ted P.S. Funny, looking at the ICANN board, I have to say that I'm surprised. The board contains names like Harald Alvaestrand, Steve Crocker, Thomas Narten, in addition to the usual Lawyers and VC's. P.P.S. Obviously, this is me speaking as an individual, not with any IETF hat on, or on behalf of my employer ___ 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
Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
I have resisted adding anything to this debate about the IPv4 outage because people have already stated many of the good points. I particularly agreed with the points made that from a PR point-of-view this was not a great idea. Let me, though, add another perspective. What about all the newbies? What are they going to do during this time? At IETF 70, there was a question raised in one of the plenaries asking How many of you are here for the first time? and a significant number of hands went up. So let's look at this proposed IPv4 outage *during the plenary* from their perspective. Now, these newcomers may or may not have been subscribed to IETF mailing lists. They may or may not have attended the Sunday intro to IETF for newcomers session. They may or may not in fact be technical folks. They are probably still trying to figure out how all this works and why these people are humming, etc. So now we go into one of the plenary sessions and it is announced that we will now shut down IPv4 and use only IPv6. The newcomer notices that: 1. A good percentage of the audience now dive into their laptops and become engrossed in diagnosing how their system works with IPv6. Side conversations are starting everywhere and occasional shouts of Aha! emerge from random groups. 2. Another percentage gets up and leaves in search of cookies. 3. Some percentage who missed reading the emails are suddenly upset because they lost their IPv4 connectivity. 4. Some percentage pops in their EVDO/EDGE/whatever cards and continues along as they were before doing their work and completely ignoring the plenary speakers. 5. Some percentage never showed up at the plenary because they went to join Richard Shockey at a local steak house. 6. Non-technical users or others who did not subscribe to IETF mailing lists are sitting there dumbfounded with a deer-caught-in-the- headlights look wondering what the heck is going on and if this has anything to do with the hums. 7. NO ONE is paying attention to the speaker(s) in front of the room during this part of the plenary. Now maybe the newcomer is all excited about IPv6 and so plunges into the technical troubleshooting. Maybe they go look for cookies or steak. Maybe they sit there dumb-founded. Probably they are left wondering what the point of this IETF plenary session really was. I don't dispute that such an exercise could be an interesting experiment in IPv6 connectivity (and one in which I would join), although in many cases I think we can already know the outcome. I just question the wisdom of doing it during the *plenary*. It would seem to me to be a great exercise to do at some other point during the week when the people who care can attend and identify issues, work through them, etc. Or we do as Ted suggested and just run an entire event with only IPv6 wireless. (and count how many people are using EVDO/EDGE cards!) It goes back to a more fundamental question - what is the purpose of the plenary? What information do we want to get across to attendees to the session? (And if we *do* plan an IPv4 outage, what is going to be talked about during the time of the outage?) My 2 cents, (now worth less than when I lived in Canada) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Let's look at it from an IETF oldie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
Here is my understanding: 1. The shortage of IPv4 addresses will increasingly cripple the communication effectiveness of the Internet, either directly or indirectly through ubiqitous NATting. 2. As a replacement for IPv4, IPv6 is the only game in town. We did it. 3. Unless we want the ITU to eat our dogfood, the IETF needs to get serious about discovering and solving the remaining technical problems implicit in IPv6 deployment. 4. In recent years, a large fraction of IETF activity has moved from our original and core concern, the network and transport layers, to (more profitable?) issues at the application layer and layer 2.5. It is time to take the network layer seriously again. 5. The recent messages containing reasoned calls for advance planning and coordination of an IPv6 connectathon are all important and need to be heeded. 6. There is a social engineering as well as a technical engineering problem here. 7. This discussion has already been useful. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On 19 dec 2007, at 17:17, Eric Rescorla wrote: Again, what is the value of this experiment? The value is that it exposes IETF-goers who don't normally run IPv6- only to this type of network configuration. At the very least this forces people to formulate their objections to this treatment, which may give us valuable information in and of its own, and hopefully, it will show one or more of the following: - how easy it is to run IPv6 - where the problem areas are with running IPv6 - what still needs to be done in standards, implementation and operation There was a suggestion to rate limit IPv4 or NAT it heavily rather than turn it off. That completely misses the point. As long as there is IPv4, you don't see what's missing from IPv6. Another suggestion was to charge more for IPv4. I love that idea. Give everyone who only needs IPv6 access a discount on the meeting fee. :-) But I think what we really need is to get some people together to define the parameters of this experiment and to work out what's needed to prepare for it. In the mean time, I'm interested to hear about jabber clients that can work in an IPv6-only environment (even though jabber.ietf.org doesn't have an IPv6 address). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
What if someone took the initiative to organize a new newbie training session on Sunday in Philadelphia, entitled something like getting your laptop ready for the planned IPv4 outage experiment on Wednesday night ? Would that reduce the potentially negative perspectives that newbies would take home after the meeting? Just a thought ... Regards, Ed Juskevicius [EMAIL PROTECTED] From: Dan York [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary I have resisted adding anything to this debate about the IPv4 outage because people have already stated many of the good points. I particularly agreed with the points made that from a PR point-of-view this was not a great idea. Let me, though, add another perspective. What about all the newbies? What are they going to do during this time? At IETF 70, there was a question raised in one of the plenaries asking How many of you are here for the first time? and a significant number of hands went up. So let's look at this proposed IPv4 outage *during the plenary* from their perspective. Now, these newcomers may or may not have been subscribed to IETF mailing lists. They may or may not have attended the Sunday intro to IETF for newcomers session. They may or may not in fact be technical folks. They are probably still trying to figure out how all this works and why these people are humming, etc. So now we go into one of the plenary sessions and it is announced that we will now shut down IPv4 and use only IPv6. The newcomer notices that: 1. A good percentage of the audience now dive into their laptops and become engrossed in diagnosing how their system works with IPv6. Side conversations are starting everywhere and occasional shouts of Aha! emerge from random groups. 2. Another percentage gets up and leaves in search of cookies. 3. Some percentage who missed reading the emails are suddenly upset because they lost their IPv4 connectivity. 4. Some percentage pops in their EVDO/EDGE/whatever cards and continues along as they were before doing their work and completely ignoring the plenary speakers. 5. Some percentage never showed up at the plenary because they went to join Richard Shockey at a local steak house. 6. Non-technical users or others who did not subscribe to IETF mailing lists are sitting there dumbfounded with a deer-caught-in-the-headlights look wondering what the heck is going on and if this has anything to do with the hums. 7. NO ONE is paying attention to the speaker(s) in front of the room during this part of the plenary. Now maybe the newcomer is all excited about IPv6 and so plunges into the technical troubleshooting. Maybe they go look for cookies or steak. Maybe they sit there dumb-founded. Probably they are left wondering what the point of this IETF plenary session really was. I don't dispute that such an exercise could be an interesting experiment in IPv6 connectivity (and one in which I would join), although in many cases I think we can already know the outcome. I just question the wisdom of doing it during the *plenary*. It would seem to me to be a great exercise to do at some other point during the week when the people who care can attend and identify issues, work through them, etc. Or we do as Ted suggested and just run an entire event with only IPv6 wireless. (and count how many people are using EVDO/EDGE cards!) It goes back to a more fundamental question - what is the purpose of the plenary? What information do we want to get across to attendees to the session? (And if we *do* plan an IPv4 outage, what is going to be talked about during the time of the outage?) My 2 cents, (now worth less than when I lived in Canada) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Let's look at it from an IETF oldie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
On Wed, 19 Dec 2007, Bob Braden wrote: Here is my understanding: 1. The shortage of IPv4 addresses will increasingly cripple the communication effectiveness of the Internet, either directly or indirectly through ubiqitous NATting. 2. As a replacement for IPv4, IPv6 is the only game in town. We did it. 3. Unless we want the ITU to eat our dogfood, the IETF needs to get serious about discovering and solving the remaining technical problems implicit in IPv6 deployment. 4. In recent years, a large fraction of IETF activity has moved from our original and core concern, the network and transport layers, to (more profitable?) issues at the application layer and layer 2.5. It is time to take the network layer seriously again. 5. The recent messages containing reasoned calls for advance planning and coordination of an IPv6 connectathon are all important and need to be heeded. 6. There is a social engineering as well as a technical engineering problem here. 7. This discussion has already been useful. What he said! As an old multicast warrior and a long time NOC volunteer I'd point out that we've been eating our own dog food for years. The world didn't end and the network never melted completely ;-). All the fine folks involved in *hard* technologies like DNSSEC, DKIM, mobility, multicast, new routing solutions, etc. should be following this discussion with a mixture of dread and befuddlement. Why are we crafting new technologies and advanced solutions to Internet architectural problems if we're unwilling to use them ourselves? I, for one, am ready to leave all the polyhedral turnings required to add one more frill to v4 behind and move on to the next billion net. It will take v6 to get there. http://www.georgehart.com/virtual-polyhedra/turnings.html - Lucy Bob Braden ___ 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: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
Good idea, I will be happy to work on that session and I¹m sure other folks from the EDU team will like the idea. Regards, Jordi De: Ed Juskevicius [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 19 Dec 2007 13:16:59 -0500 Para: Dan York [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], ietf@ietf.org Conversación: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary Asunto: RE: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary What if someone took the initiative to organize a new newbie training session on Sunday in Philadelphia, entitled something like getting your laptop ready for the planned IPv4 outage experiment on Wednesday night ? Would that reduce the potentially negative perspectives that newbies would take home after the meeting? Just a thought ... Regards, Ed Juskevicius [EMAIL PROTECTED] From: Dan York [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary I have resisted adding anything to this debate about the IPv4 outage because people have already stated many of the good points. I particularly agreed with the points made that from a PR point-of-view this was not a great idea. Let me, though, add another perspective. What about all the newbies? What are they going to do during this time? At IETF 70, there was a question raised in one of the plenaries asking How many of you are here for the first time? and a significant number of hands went up. So let's look at this proposed IPv4 outage *during the plenary* from their perspective. Now, these newcomers may or may not have been subscribed to IETF mailing lists. They may or may not have attended the Sunday intro to IETF for newcomers session. They may or may not in fact be technical folks. They are probably still trying to figure out how all this works and why these people are humming, etc. So now we go into one of the plenary sessions and it is announced that we will now shut down IPv4 and use only IPv6. The newcomer notices that: 1. A good percentage of the audience now dive into their laptops and become engrossed in diagnosing how their system works with IPv6. Side conversations are starting everywhere and occasional shouts of Aha! emerge from random groups. 2. Another percentage gets up and leaves in search of cookies. 3. Some percentage who missed reading the emails are suddenly upset because they lost their IPv4 connectivity. 4. Some percentage pops in their EVDO/EDGE/whatever cards and continues along as they were before doing their work and completely ignoring the plenary speakers. 5. Some percentage never showed up at the plenary because they went to join Richard Shockey at a local steak house. 6. Non-technical users or others who did not subscribe to IETF mailing lists are sitting there dumbfounded with a deer-caught-in-the-headlights look wondering what the heck is going on and if this has anything to do with the hums. 7. NO ONE is paying attention to the speaker(s) in front of the room during this part of the plenary. Now maybe the newcomer is all excited about IPv6 and so plunges into the technical troubleshooting. Maybe they go look for cookies or steak. Maybe they sit there dumb-founded. Probably they are left wondering what the point of this IETF plenary session really was. I don't dispute that such an exercise could be an interesting experiment in IPv6 connectivity (and one in which I would join), although in many cases I think we can already know the outcome. I just question the wisdom of doing it during the *plenary*. It would seem to me to be a great exercise to do at some other point during the week when the people who care can attend and identify issues, work through them, etc. Or we do as Ted suggested and just run an entire event with only IPv6 wireless. (and count how many people are using EVDO/EDGE cards!) It goes back to a more fundamental question - what is the purpose of the plenary? What information do we want to get across to attendees to the session? (And if we *do* plan an IPv4 outage, what is going to be talked about during the time of the outage?) My 2 cents, (now worth less than when I lived in Canada) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 !
RE: Let's look at it from an IETF oldie's perspective... Re: IPv4Outage Planned for IETF 71 Plenary
On the contrary, from the perspective of the ISPs, slamming their customers behind a NAT is a perfectly acceptable solution. The oldie perspective of 'take it or leave it' is not going to work here. I have gamed the dynamics of IPv4 exhaustion quite extensively and the mere fact that there are no more IPv4 addresses left to be allocated does not provide the forcing function people imagine. IPv4 is a party with a limited number of tickets. The number of tickets is much larger than the number of tickets for the superbowl but the same market dynamics apply. Folk who have tickets have no need of a bigger stadium. In fact they are perfectly OK with the situation since their ticket now has a resale value. The approach this is predicated on is akin to telling superbowl fans without a ticket to 1) Build a stadium 2) Persuade the teams to play in the (empty) new stadium rather than the old one that is full. In the real world superbowl fans buy a ticket from a scalper instead. The situation is not hopeless, far from it. There are approaches to managing the transition that will work. Telling the word that IPv6 is the only game in town and expecting them to bow to this wisdom is not going to work. We have to have an economic model for this transition. From: Bob Braden [mailto:[EMAIL PROTECTED] Sent: Wed 19/12/2007 1:11 PM To: ietf@ietf.org Subject: Let's look at it from an IETF oldie's perspective... Re: IPv4Outage Planned for IETF 71 Plenary Here is my understanding: 1. The shortage of IPv4 addresses will increasingly cripple the communication effectiveness of the Internet, either directly or indirectly through ubiqitous NATting. 2. As a replacement for IPv4, IPv6 is the only game in town. We did it. 3. Unless we want the ITU to eat our dogfood, the IETF needs to get serious about discovering and solving the remaining technical problems implicit in IPv6 deployment. 4. In recent years, a large fraction of IETF activity has moved from our original and core concern, the network and transport layers, to (more profitable?) issues at the application layer and layer 2.5. It is time to take the network layer seriously again. 5. The recent messages containing reasoned calls for advance planning and coordination of an IPv6 connectathon are all important and need to be heeded. 6. There is a social engineering as well as a technical engineering problem here. 7. This discussion has already been useful. Bob Braden ___ 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: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
Why not do this for the entire meeting ? In fact, why not do it for the entire meeting even if there isn't a plenary outage ? Regards Marshall On Dec 19, 2007, at 1:47 PM, JORDI PALET MARTINEZ wrote: Good idea, I will be happy to work on that session and I’m sure other folks from the EDU team will like the idea. Regards, Jordi De: Ed Juskevicius [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 19 Dec 2007 13:16:59 -0500 Para: Dan York [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], ietf@ietf.org Conversación: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary Asunto: RE: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary What if someone took the initiative to organize a new newbie training session on Sunday in Philadelphia, entitled something like getting your laptop ready for the planned IPv4 outage experiment on Wednesday night ? Would that reduce the potentially negative perspectives that newbies would take home after the meeting? Just a thought ... Regards, Ed Juskevicius [EMAIL PROTECTED] From: Dan York [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:54 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary I have resisted adding anything to this debate about the IPv4 outage because people have already stated many of the good points. I particularly agreed with the points made that from a PR point-of- view this was not a great idea. Let me, though, add another perspective. What about all the newbies? What are they going to do during this time? At IETF 70, there was a question raised in one of the plenaries asking How many of you are here for the first time? and a significant number of hands went up. So let's look at this proposed IPv4 outage *during the plenary* from their perspective. Now, these newcomers may or may not have been subscribed to IETF mailing lists. They may or may not have attended the Sunday intro to IETF for newcomers session. They may or may not in fact be technical folks. They are probably still trying to figure out how all this works and why these people are humming, etc. So now we go into one of the plenary sessions and it is announced that we will now shut down IPv4 and use only IPv6. The newcomer notices that: 1. A good percentage of the audience now dive into their laptops and become engrossed in diagnosing how their system works with IPv6. Side conversations are starting everywhere and occasional shouts of Aha! emerge from random groups. 2. Another percentage gets up and leaves in search of cookies. 3. Some percentage who missed reading the emails are suddenly upset because they lost their IPv4 connectivity. 4. Some percentage pops in their EVDO/EDGE/whatever cards and continues along as they were before doing their work and completely ignoring the plenary speakers. 5. Some percentage never showed up at the plenary because they went to join Richard Shockey at a local steak house. 6. Non-technical users or others who did not subscribe to IETF mailing lists are sitting there dumbfounded with a deer-caught-in- the-headlights look wondering what the heck is going on and if this has anything to do with the hums. 7. NO ONE is paying attention to the speaker(s) in front of the room during this part of the plenary. Now maybe the newcomer is all excited about IPv6 and so plunges into the technical troubleshooting. Maybe they go look for cookies or steak. Maybe they sit there dumb-founded. Probably they are left wondering what the point of this IETF plenary session really was. I don't dispute that such an exercise could be an interesting experiment in IPv6 connectivity (and one in which I would join), although in many cases I think we can already know the outcome. I just question the wisdom of doing it during the *plenary*. It would seem to me to be a great exercise to do at some other point during the week when the people who care can attend and identify issues, work through them, etc. Or we do as Ted suggested and just run an entire event with only IPv6 wireless. (and count how many people are using EVDO/EDGE cards!) It goes back to a more fundamental question - what is the purpose of the plenary? What information do we want to get across to attendees to the session? (And if we *do* plan an IPv4 outage, what is going to be talked about during the time of the outage?) My 2 cents, (now worth less than when I lived in Canada) Dan -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web
Re: Let's look at it from an IETF newbie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary
Why not do this for the entire meeting ? In fact, why not do it for the entire meeting even if there isn't a plenary outage ? Good idea!, except perhaps 71 is too soon. How about the plenary outage as planed for 71, and the entire IETF after that? (Perhaps support IPv4 in the terminal room only, for individuals who don't have enough leverage to move their home institutions.) The point is not to cause people to debug during the IETF, but to cause people to notice deployment problems and to have them fixed by the following IETF. Thanks, --MM-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Pete Resnick wrote: On 12/18/07 at 1:32 PM -0500, John C Klensin wrote: Reporters come to our meetings and attend plenaries. There are members of the reporter community, or their editors, who like only those stories that they can sensationalize. For them, this little outage results in one of two possible headlines: (i) Not even IETF can get IPv6 to work seamlessly. (ii) IPv6 is so complicated that only the IETF experts, struggling mightily, can get it to work in a drop-in environment. Simply reporting on this thread would lend itself to some interesting headlines, with minimal sensationalization: Proposal that the IETF use IPv6 exclusively for 60 minutes causes widespread panic I really don't have a strong opinion on the proposal itself; I can live without network connectivity for an hour (or I can cheat and use my EVDO card for an hour :-) ). But this entire conversation has been exceedingly informative: Exactly my thoughts as I read the thread (though I have made a point of having in my host file for the things I care about, so I am not worried). It is really bizarre to watch the reaction to the thought that we might 'need to be serious about using IPv6'. If we could only get the IESG to get serious about killing off working groups that are still focused on IPv4 ... ;) a) As an Apps guy, this talk does not bode well for how seriously IPv6 has been taken in getting basic infrastructure issues solved such that applications can run. While you are concerned about infrastructure, I am -much- more concerned about lack of app support. If is fairly easy to fix a handful of root servers, but it is much more difficult to find apps that are capable of working in an IPv6-only environment, let alone get them widely distributed. b) As a user who runs my own little corner of the network, this doesn't make me sanguine about being able to get my basic services up and running under IPv6 anytime soon. I'm somewhere between depressed and amused. I have all but given up on any kind of smooth transition. The ongoing stand-off between the ISP's and Content Providers over who will move first ensures that this will be an ugly last-minute fiasco. The lack of wide-spread app support further ensures that there is no way to avoid having the consumer be very aware of which version of the protocol they are running, and what each product supports. Here again this thread is very instructive. If the app community had built agnostic apps years ago, the agnostic stacks in the current laptops would transparently deal with the outage (assuming the roots get fixed). Instead there is a panic by people (scanning the list mostly in the apps community) that should have been serious in the past, but have procrastinated. So for that I applaud the announced outage for disturbing the cozy corner of ignorance that people have been hiding in, but ... as much as I want to see IPv6 in wide-spread use, I have to agree with John, Dave, and Eric, this is not the right experiment. It is not right because it does nothing positive, other than the threat -maybe- spurring some action. A more realistic experiment would be to run the entire week with a double-nat for IPv4 (and nats between the access points to simulate consumer-to-consumer configurations), where the most public one has absolutely no provision for punching holes (because realistically an ISP is not going to punch inbound holes for its customers, or allow them to). Also make sure that there is only 1 public IPv4 address so the issues of port overloading exhaustion are completely exposed. The IPv4-forever crowd will see the failings of their claim that; n-layers of nat will just work because n=1 does for a limited subset of applications when the end user has control over hole punching. The resulting headline would be something like: The IETF tried to live in the upcoming world of multiple layers of IPv4 nat and failed ... Those that didn't want to suffer that fate used IPv6 enabled apps and moved into a better future. I am not opposed to doing an IPv6-only network, but that should be well planned (~ 1 year in advance), and have the expected outcome of IPv6 as a success, rather than the known outcome of the upcoming meeting where more than half would just be cut off without IPv4. It should have happened a couple of years ago so the IESG would know the state of the world, but better late than never so tell people now that Fall-08, or Spring-09 will have a significant portion of the network as IPv6-only, giving them sufficient time to do real preparation, rather than just panic work-arounds. Leave IPv4 up only for the external audio feeds, and one AP near the support desk for dealing with a day-job crisis. With enough time to do real prep, the result of the experiment will have some meaning. Otherwise it is just going to create negative headlines. Tony ___ Ietf mailing list
Re: Opportunity Re: IPv4 Outage Planned for IETF 71 Plenary
I also think that we must think positive about this. We do need to try things out. I think we started our very first experiments with Wireless LAN at IETF 46 in Washington (I am just trying to find a museum to take the plug-in card Nortel sold(?) me that was never any use afterwards (the old 1Mbps not 802,11b 'standard') ). It has taken us more or less 23 meetings to get to the point where essentially Wi-Fi 'just worked' measured by traffic on the attendees mailing list - it was sometimes a sore trial when 17 ad hoc networks stopped you connecting to the outside world, but we have learnt how to do it - and the vendors and operators have (I suspect) learnt a good deal in parallel. Also one or two ISPs have actually embraced IPv6. Mine (a smallish outfit in the UK) has done so. To my shame I haven't exploited their capabilities yet - my New Year's resolution is to fix this situation. I could run native IPv6 if I find an ADSL modem/router that handles it but in the meantime I can run a tunnel into my firewall box and go native IPv6 elsewhere. Ot will be an interesting experiment and I should be ready to handle any experiments at IETF. Have a look at http://www.aaisp.net/aa/aaisp/ipv6.html Regards Elwyn Jari Arkko wrote: I agree with Leslie on this. It is important to approach this in the right light. Not an interop event; that would be for the implementors of the products. Not a demonstration that IPv4 is still required for most things; we know that already. Not a one hour session where thousand people try to install something new at the same time without a network; there needs to be better model for that. But I think we should still do something. I viewed Russ' call as an opportunity for the IETF community to take a challenge and see what we can make happen by IETF-71. As a personal note, I've had IPv6 turned on my equipment, home site, and company site for years but during the last few months I have tried create a situation where most of own communications would be on IPv6. We converted the company mail servers and gateways that I use to dual stack; some of my own web systems got records too; I ensured that the tools that I use have the right capabilities and defaults to use IPv6; I've contacted the admins of the remaining IETF web sites that still are IPv4 only to ask if they can be converted to dual stack. A significant part of my communications go over IPv6 today, and I have a hope to get this to cover most of my work-related communications. And yes, there's pain. I'm typically the first one to experience the firewall config bug or routing issue on the IPv6 side. But I'm willing... So, I would suggest that we focus on the positive opportunities that Leslie mentioned. Get more things to work. Challenge sponsors to do so as well. Solve some of the remaining problems. Educate ourselves both by doing and by seeing what others do or where they fail. See what works in IETF-71 (but the format of that is less important). Obviously, this needs planning -- Russ' mail is not the plan but rather a call for us to figure out what would make sense. Much work needed... I'm also somewhat surprised by the reluctance of people to try things out. Where's our sense of adventure and eagerness to do new things? We are engineers after all, tinkering with network setups should be fun, no? Boldly go where no group of thousand has ever been... Or at the very least, lets change something for the better. Jari ___ 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: IPv4 Outage Planned for IETF 71 Plenary
And on another topic, I would hope that (members of) the IAB will spend the same amount of time and energy as used on this discussion Amen, but lets make that apply to the rest of us too. on more important topics like to get ICANN to have ipv6 and DNSSEC root service available before the next IETF meeting. Actually, I have some trust on the fine people in the ICANN board and I would expect them to get their stuff in order soon. In any case, we don't make those decisions on this list. Focusing a little bit on what we can have an effect on: what would it take for IETF work -related communications to be possible via IPv6? And what can we do to increase the number of participants that can deal with IPv6? Here are some items, send mail if you have something to add or change: - IETF web sites to fully IPv6 capable (not all are; I have a list somewhere) - Same for the related websites (iab.org, iesg.org, iana.org, rfc-editor.org, maybe some tools if not all of them are there yet) - Datatracker (no enabled at this time, but should be doable) - Jabber to work on IPv6 (I have no idea what it takes to do this) - Training for the IPv6 newbies - What each of us can do in our own organizations for our VPN, mail etc Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Dec 19, 2007, at 11:39 AM, Tony Hain wrote: If we could only get the IESG to get serious about killing off working groups that are still focused on IPv4 ... ;) Suggestions of WGs? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Tony == Tony Hain [EMAIL PROTECTED] writes: Tony the right experiment. It is not right because it does Tony nothing positive, other than the threat -maybe- spurring Tony some action. A more realistic experiment would be to run the Tony entire week with a double-nat for IPv4 (and nats between the Tony access points to simulate consumer-to-consumer Tony configurations), where the most public one has absolutely no Tony provision for punching holes (because realistically an ISP Tony is not going to punch inbound holes for its customers, or Tony allow them to). I strongly support this experiment and believe it would be a really good idea to run. I do think behave-compatible nats should be used, but besides that, I think the experiment you propose is far more valuable than the v6-only experiment. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Suggestions of WGs? mipv4 mipshop netconf (should be high level, but ID examples are all IPV4) nea (should be agnostic, but clearly has the IPv4 mindset of a single address/interface) syslog (should be high level, but ID examples are all IPV4) behave midcom nsis (because most of the group is focused on nat signaling) there are probably more, but closing these would be a good start and set an example Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
+1 The press reaction is likely to be better as well. The only point to doing the IPv6 only approach is if you want to demonstrate that it is entirely impractical and drill it into folks heads that we need to be more realistic in our approach here. The double NAT approach is much closer to what the actual transition is going to look like. The only difference is that I think we might just be able to work out a viable means of punching holes so that video-conferencing works if we actually set our minds to it. From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wed 19/12/2007 3:19 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED]; 'Pete Resnick'; 'IETF Chair'; [EMAIL PROTECTED]; 'John C Klensin'; [EMAIL PROTECTED] Subject: Re: IPv4 Outage Planned for IETF 71 Plenary Tony == Tony Hain [EMAIL PROTECTED] writes: Tony the right experiment. It is not right because it does Tony nothing positive, other than the threat -maybe- spurring Tony some action. A more realistic experiment would be to run the Tony entire week with a double-nat for IPv4 (and nats between the Tony access points to simulate consumer-to-consumer Tony configurations), where the most public one has absolutely no Tony provision for punching holes (because realistically an ISP Tony is not going to punch inbound holes for its customers, or Tony allow them to). I strongly support this experiment and believe it would be a really good idea to run. I do think behave-compatible nats should be used, but besides that, I think the experiment you propose is far more valuable than the v6-only experiment. ___ 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: IPv4 Outage Planned for IETF 71 Plenary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With all due respect, firewall traversal and protocol translation look like they are going to be interesting/important topics, at least in the near term. You might consider Alain's slides from v6ops/nanog in that regard. Closing an application working group because the examples in its documents are IPv4 seems a little presumptuous. Closing a working group because we disagree with what appear to us to be their assumptions seems a bit presumptuous. I'm all for closing working groups that are moribund. If a working group is in process and is supporting a constituency that addresses a business requirement, I'm not sure I see the wisdom. On Dec 19, 2007, at 12:56 PM, Tony Hain wrote: Suggestions of WGs? mipv4 mipshop netconf (should be high level, but ID examples are all IPV4) nea (should be agnostic, but clearly has the IPv4 mindset of a single address/interface) syslog (should be high level, but ID examples are all IPV4) behave midcom nsis (because most of the group is focused on nat signaling) there are probably more, but closing these would be a good start and set an example Tony -BEGIN PGP SIGNATURE- iD8DBQFHaYiAbjEdbHIsm0MRAk+0AJ9pU9tC69Shq69V/kRXrIOkk9WHzgCeLGHo DnzVVMhB4hqJcQcw8B0Xa/k= =afRV -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Sam, While I understand the virtue in behave-compatible nats, how realistic is it to believe that any service provider is going to allow a consumer to directly signal their infrastructure? This assumption was the failing of RSVP as an endpoint qos tool. There is lots of noise about ISPs just putting up massive nat farms to push their customers out, but when it comes right down to it there is no way that will work for anything but the most trivial client apps. All of the assumptions about nat working today are built around local control of the mappings. When that mapping function has to move to a third party, all bets are off. Worse, when that third party has strong disincentives which keep them from allowing their customers to punch holes, there is no chance that apps will work. ISPs are disincented by even the simple issue of after-the-fact diagnostics being more complicated by dynamic mappings, let alone the problem of conflict resolution between customers. Behave compatible nats are a nice concept for enterprises with multiple levels of internal nat, but third-party trust issues will kill any real deployment of a signaling based approach. Tony -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:19 PM To: [EMAIL PROTECTED] Cc: 'IETF Chair'; ietf@ietf.org; [EMAIL PROTECTED]; 'John C Klensin'; [EMAIL PROTECTED]; 'Pete Resnick'; [EMAIL PROTECTED] Subject: Re: IPv4 Outage Planned for IETF 71 Plenary Tony == Tony Hain [EMAIL PROTECTED] writes: Tony the right experiment. It is not right because it does Tony nothing positive, other than the threat -maybe- spurring Tony some action. A more realistic experiment would be to run the Tony entire week with a double-nat for IPv4 (and nats between the Tony access points to simulate consumer-to-consumer Tony configurations), where the most public one has absolutely no Tony provision for punching holes (because realistically an ISP Tony is not going to punch inbound holes for its customers, or Tony allow them to). I strongly support this experiment and believe it would be a really good idea to run. I do think behave-compatible nats should be used, but besides that, I think the experiment you propose is far more valuable than the v6-only experiment. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
What Fred said. Also, MIPSHOP is not for IPv4. Just the first line of the charter mentions IPv6 twice. Jari Fred Baker wrote: With all due respect, firewall traversal and protocol translation look like they are going to be interesting/important topics, at least in the near term. You might consider Alain's slides from v6ops/nanog in that regard. Closing an application working group because the examples in its documents are IPv4 seems a little presumptuous. Closing a working group because we disagree with what appear to us to be their assumptions seems a bit presumptuous. I'm all for closing working groups that are moribund. If a working group is in process and is supporting a constituency that addresses a business requirement, I'm not sure I see the wisdom. On Dec 19, 2007, at 12:56 PM, Tony Hain wrote: Suggestions of WGs? mipv4 mipshop netconf (should be high level, but ID examples are all IPV4) nea (should be agnostic, but clearly has the IPv4 mindset of a single address/interface) syslog (should be high level, but ID examples are all IPV4) behave midcom nsis (because most of the group is focused on nat signaling) there are probably more, but closing these would be a good start and set an example Tony ___ 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: IPv4 Outage Planned for IETF 71 Plenary
Hallam-Baker, Phillip wrote: The double NAT approach is much closer to what the actual transition is going to look like. The only difference is that I think we might just be able to work out a viable means of punching holes so that video-conferencing works if we actually set our minds to it. Since you are the one that is routinely taking the operator's position, why should we allow punching holes in the IETF nat when that will never happen in a real ISP? No ISP is going to trust their customer base to modify the configuration of their infrastructure, so whatever the IETF experiment ends up being has to mimic that reality. The only exception I would make is to route the audio streams around the nat so people that can't attend are not completely cut off. Other than that, if you are there you are living the future. IPv6 plus multiple layers of IPv4-nat, with trust boundary issues included. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Tony == Tony Hain [EMAIL PROTECTED] writes: Tony Hallam-Baker, Phillip wrote: The double NAT approach is much closer to what the actual transition is going to look like. The only difference is that I think we might just be able to work out a viable means of punching holes so that video-conferencing works if we actually set our minds to it. Tony Since you are the one that is routinely taking the Tony operator's position, why should we allow punching holes in Tony the IETF nat when that will never happen in a real ISP? No Tony ISP is going to trust their customer base to modify the Tony configuration of their infrastructure, so whatever the IETF Tony experiment ends up being has to mimic that reality. I think that real ISPs will ship NATs that comply with behave. If you think that address independent and endpoint independent mapping behavior with endpoint dependent filtering behavior counts as punching holes then I disagree with you. Why will ISPs support this? Because their customers voip phones and games will want it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Tony == Tony Hain [EMAIL PROTECTED] writes: Tony Sam, While I understand the virtue in behave-compatible Tony nats, how realistic is it to believe that any service Tony provider is going to allow a consumer to directly signal Tony their infrastructure? The behave documents I've read don't talk about signaling a NAT. Are we talking about the same working group? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Tony Hain wrote: Sam, While I understand the virtue in behave-compatible nats, how realistic is it to believe that any service provider is going to allow a consumer to directly signal their infrastructure? This assumption was the failing of RSVP as an endpoint qos tool. (Here's the problem with taking one result, and attempting to apply it to another problem space: RSVP was necessarily an in-band protocol, and tied intrinsically to the local provider's network.) There is *nothing* in IPv6-IPv4 that is *strictly* tied to the provider of IPv6 services. It may be the case that ISPs try to scare their customers into believing otherwise, but that is not a technical issue. So, while the third party problem is a concern where the third party has a de-facto monopoly, the counter-argument under the IPv6 access model exists. If you can get anywhere on the IPv6 Internet, you can get to *any* third-party IPv6-IPv4 gateway, limited only by the ability to reach interest of the third party, e.g. someone offering it as a service. Since IPv6 access is no-NAT to/from the IPv6 DFZ, unlike much of IPv4, there is a level playing field for network-facing services, such as IPv6-IPv4 access, and IPv6-oriented ALGs. Mail relaying, for instance, via MX-IPv4 to SMTP-IPv6. The rest of your argument falls off the rails, as soon as the third party changes from _the_ third party, to _a_ third party. In an IPv6 world, ISPs can once again be differentiated to include ISPs-lite, Internet Access Providers. I'd suggest that for the experiment planned for IETF-71, that interested folks set up *competing* IPv6-IPv4 services, kind of like a mock marketplace, and including mock advertising on a special (IPv6-only) web site for just this purpose. Then the results would have multiple dimensions, comparative results much like an actual ba*k o*f. Brian Dickson There is lots of noise about ISPs just putting up massive nat farms to push their customers out, but when it comes right down to it there is no way that will work for anything but the most trivial client apps. All of the assumptions about nat working today are built around local control of the mappings. When that mapping function has to move to a third party, all bets are off. Worse, when that third party has strong disincentives which keep them from allowing their customers to punch holes, there is no chance that apps will work. ISPs are disincented by even the simple issue of after-the-fact diagnostics being more complicated by dynamic mappings, let alone the problem of conflict resolution between customers. Behave compatible nats are a nice concept for enterprises with multiple levels of internal nat, but third-party trust issues will kill any real deployment of a signaling based approach. Tony begin:vcard fn:Brian Dickson n:Dickson;Brian org:Afilias Canada adr:;;;Toronto;;;Canada email;internet:[EMAIL PROTECTED] title:Internet Operations Specialist tel;work:+1 416 673 4121 url:www.afilias.info version:2.1 end:vcard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Some points: 1) Winning a battle with the ISPs is hard but it is much easier to persuade the consumer that when they buy a NAT box they should get one that BEHAVEs, if we win the battle at the WiFi/Cable router stage we can push out the requirement as an expectation for ISP deployed NAT farms. 2) Branding is the key. Consider the case that the following Internet service levels are defined: Internet 2: Restricted Internet 2: Basic Internet 2: Advanced Even before I state what the requirements for the levels are it is pretty clear that an ISP that offers only Restricted service is at a sales disadvantage to an ISP that offers Basic. The Mappings I would propose are: Restricted - IPv4 service only through dumb NAT with no means of accepting inbound service connections. Basic - A full /96 IPv6 subnet or better plus legacy IPv4 service, either a publlic IPv4 address or through an intelligent NAT with punchthrough. Advanced - Same as Basic but a /88 plus a static IPv4 address and the ability to accept unrestricted inbound services. The point of defining restricted is not to promote its use but to deprecate that level of service. Most users would opt for the Basic level of service in preference to advanced which is also what we want as we want to graceously manage the depletion of the IPv4 pool. That is my bottom line, the problem in my view is not how we manage the IPv6 transition, its how we manage the depletion of the IPv4 pool in a manner that achieves the end result that benefits everyone. Deployment of IPv6 is a consequence, not the stakeholder's actual objective. From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Wed 19/12/2007 4:10 PM To: 'Sam Hartman' Cc: ietf@ietf.org; [EMAIL PROTECTED]; 'Pete Resnick'; 'IETF Chair'; [EMAIL PROTECTED]; 'John C Klensin'; [EMAIL PROTECTED] Subject: RE: IPv4 Outage Planned for IETF 71 Plenary Sam, While I understand the virtue in behave-compatible nats, how realistic is it to believe that any service provider is going to allow a consumer to directly signal their infrastructure? This assumption was the failing of RSVP as an endpoint qos tool. There is lots of noise about ISPs just putting up massive nat farms to push their customers out, but when it comes right down to it there is no way that will work for anything but the most trivial client apps. All of the assumptions about nat working today are built around local control of the mappings. When that mapping function has to move to a third party, all bets are off. Worse, when that third party has strong disincentives which keep them from allowing their customers to punch holes, there is no chance that apps will work. ISPs are disincented by even the simple issue of after-the-fact diagnostics being more complicated by dynamic mappings, let alone the problem of conflict resolution between customers. Behave compatible nats are a nice concept for enterprises with multiple levels of internal nat, but third-party trust issues will kill any real deployment of a signaling based approach. Tony -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 19, 2007 12:19 PM To: [EMAIL PROTECTED] Cc: 'IETF Chair'; ietf@ietf.org; [EMAIL PROTECTED]; 'John C Klensin'; [EMAIL PROTECTED]; 'Pete Resnick'; [EMAIL PROTECTED] Subject: Re: IPv4 Outage Planned for IETF 71 Plenary Tony == Tony Hain [EMAIL PROTECTED] writes: Tony the right experiment. It is not right because it does Tony nothing positive, other than the threat -maybe- spurring Tony some action. A more realistic experiment would be to run the Tony entire week with a double-nat for IPv4 (and nats between the Tony access points to simulate consumer-to-consumer Tony configurations), where the most public one has absolutely no Tony provision for punching holes (because realistically an ISP Tony is not going to punch inbound holes for its customers, or Tony allow them to). I strongly support this experiment and believe it would be a really good idea to run. I do think behave-compatible nats should be used, but besides that, I think the experiment you propose is far more valuable than the v6-only experiment. ___ 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: IPv4 Outage Planned for IETF 71 Plenary
There is a difference between 'taking the operators position' and deciding which battles to fight. The battle to fight here is to maintain the ability to exchange peer-to-peer audio and video conferencing streams. That is a battle that I beleive can be won given the right marketting approach. From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Wed 19/12/2007 4:19 PM To: Hallam-Baker, Phillip; 'Sam Hartman' Cc: ietf@ietf.org; [EMAIL PROTECTED]; 'John C Klensin'; 'IETF Chair'; [EMAIL PROTECTED]; 'Pete Resnick'; [EMAIL PROTECTED] Subject: RE: IPv4 Outage Planned for IETF 71 Plenary Hallam-Baker, Phillip wrote: The double NAT approach is much closer to what the actual transition is going to look like. The only difference is that I think we might just be able to work out a viable means of punching holes so that video-conferencing works if we actually set our minds to it. Since you are the one that is routinely taking the operator's position, why should we allow punching holes in the IETF nat when that will never happen in a real ISP? No ISP is going to trust their customer base to modify the configuration of their infrastructure, so whatever the IETF experiment ends up being has to mimic that reality. The only exception I would make is to route the audio streams around the nat so people that can't attend are not completely cut off. Other than that, if you are there you are living the future. IPv6 plus multiple layers of IPv4-nat, with trust boundary issues included. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Sam Hartman wrote: I think that real ISPs will ship NATs that comply with behave. If you think that address independent and endpoint independent mapping behavior with endpoint dependent filtering behavior counts as punching holes then I disagree with you. Establishing persistent state on an ISP infrastructure device is punching a hole. It doesn't matter if that is a nat, or a STUN relay, the fact that a customer locked it down will raise the potential for contention, and in fact creates a routing entry that is not under the ISP's control. Why will ISPs support this? Because their customers voip phones and games will want it. They are more likely to want to force the phone traffic through a call control point so they can count bits and bill minutes. I am willing to conceded on the behave point because client side actions really don't matter, but I want to see multiple people running mta's and independent web servers on the nat'd IETF network, with active connection attempts to them from the outside. Nobody can physically configure the most public nat, and no signaling of it is allowed because it is operated by a third party that doesn't trust you. If you want a real indication of future problems, run real services from behind the magic solution and document its complete failure. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Tony == Tony Hain [EMAIL PROTECTED] writes: Tony I am willing to conceded on the behave point because client Tony side actions really don't matter, but I want to see multiple Tony people running mta's and independent web servers on the Tony nat'd IETF network, with active connection attempts to them Tony from the outside. Nobody can physically configure the most Tony public nat, and no signaling of it is allowed because it is Tony operated by a third party that doesn't trust you. If you Tony want a real indication of future problems, run real services Tony from behind the magic solution and document its complete Tony failure. I think this would be fun and educational. I do something similar for my own infrastructure. And yes there are problems. Some things do work though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv4 Outage Planned for IETF 71 Plenary
Contention is certainly an issue, hence my proposal to regard well known port assignments as an obsolete arrangement and instead consider DNS and SRV the cannonical service discovery mechanism. From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Wed 19/12/2007 5:03 PM To: 'Sam Hartman' Cc: ietf@ietf.org; [EMAIL PROTECTED]; 'John C Klensin'; 'IETF Chair'; [EMAIL PROTECTED]; 'Pete Resnick'; [EMAIL PROTECTED] Subject: RE: IPv4 Outage Planned for IETF 71 Plenary Sam Hartman wrote: I think that real ISPs will ship NATs that comply with behave. If you think that address independent and endpoint independent mapping behavior with endpoint dependent filtering behavior counts as punching holes then I disagree with you. Establishing persistent state on an ISP infrastructure device is punching a hole. It doesn't matter if that is a nat, or a STUN relay, the fact that a customer locked it down will raise the potential for contention, and in fact creates a routing entry that is not under the ISP's control. Why will ISPs support this? Because their customers voip phones and games will want it. They are more likely to want to force the phone traffic through a call control point so they can count bits and bill minutes. I am willing to conceded on the behave point because client side actions really don't matter, but I want to see multiple people running mta's and independent web servers on the nat'd IETF network, with active connection attempts to them from the outside. Nobody can physically configure the most public nat, and no signaling of it is allowed because it is operated by a third party that doesn't trust you. If you want a real indication of future problems, run real services from behind the magic solution and document its complete failure. Tony ___ 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: Last Call: draft-ietf-dnsext-2929bis (Domain Name System (DNS) IANA Considerations) to BCP
At 11:50 04/12/2007, Sam Weiler wrote: This draft does not address at least one issue raised in WGLC. It also contains substantial changes made after the close of WGLC that have received too little attention from the WG. Accordingly, I continue to oppose publication of this document[1]. I suggest that the IESG refer it back to the WG and, once a new document is advanced, issue a new IETF last call. Sam, most of the changes are results of the allocation experiment that was conducted. The working group was fully aware of them and the changes made to the document see: http://psg.com/lists/namedroppers/namedroppers.2007/msg00190.html An example of an issue raised in WGLC (in August 2006) that I think should be addressed: The document continues to use IETF Consensus as an allocation metric. That term is deprecated in 2434bis and should be replaced. The editor appears to have agreed to make that change[2], and I've seen no follow-up discussion saying that shouldn't happen. Yes this is an oversight on the editors part and mine as well, sorry. And an example of one of the changes that I think has received too little review: The document allows templates to create IANA registries. Is that altogether desirable? Has the expert been given enough guidance to review such requests? This is an excellent IETF wide question it is outside the DNSEXT WG expertize to judge this issue. At this point there is no specific guidance to the expert(s) on what to do in this case. I have not attempted to do an exhaustive review of the 2929bis discussion, but I suspect there are other items in the above categories also. I hope there are not any more skeletons in the closet :-) On the positive side, I'm pleased that the document provides for permanently archived templates which can, in and of themselves, serve as adequate documentation of a typecode assignment. good. [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01208.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01410.html -- Sam Olafur ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF71 hotel noise warning on Marriott web pages
Expectations of support infrastructure change as technology evolves. In those days, we got along just fine without cell phones as well. Based on new technology our co-workers expect a level of internation not previously possible. We are also used to immediate access to reference material and as one person noted, they may take advantage of local laptop access to the presentation material to be able to read it. ... How things were done in the past really has little bearing on how we do then now. On Wed, 19 Dec 2007, Stephane Bortzmeyer wrote: On Tue, Dec 18, 2007 at 01:45:24PM -0500, John C Klensin [EMAIL PROTECTED] wrote a message of 57 lines which said: Between this and apparent efforts by the IAOC, IESG, and sponsor to deliberately disrupt the network, this is beginning to sound like the meeting to miss. I am not old enough to have personal experience of the oldest IETF meetings but I've heard that there was no Internet connectivity at all at these times and yet the IETF was able to work. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 18, 2007, at 12:39 PM, Hallam-Baker, Phillip wrote: In the same way that there is a difference between a bricklayer and an architect there is a difference between an engineer and a network admin. On Dec 19, 2007, at 8:07 AM, David Kessens wrote: This issue will only develop into an outage if you bring the wrong survival tools: I suggest you leave your hammer home and make sure that you can use ipv6 only. There is no rocket science here. People have done this before. David, I think you missed Phillip's point. The average engineer at the IETF meeting isn't in control of significant aspects of his IT infrastructure, such as whether his IT department has enabled IPv6 access to his mail server. Sure, I have IPv6 running on my Mac (it defaults on and I dont turn it off) and someone with IPv6 in their network can presumably get web pages from www.ipv6.cisco.com. That's not the same as being productive. -BEGIN PGP SIGNATURE- iD8DBQFHabRWbjEdbHIsm0MRAit2AJ0Us7mvymBd4OekFOi0MMWL1eMAwACgmjSS biGsa0y13iHsDJaB9s9mlRs= =St0Y -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF71 hotel noise warning on Marriott web pages
But the IETF network has for as long as I've attended (12 years) been a proving ground for new technology. DHCP, multicast, wireless, IPv6, etc. I'm quite happy to see more testing of future technology / configurations on the network. I'd like to see DNSSEC validation deployed on the recursive DNS servers advertised by DHCP to the network. I'd like to see IETF.ORG signed. I'd like to see SIG(0) deployed on the recursive DNS servers. The IETF net should be a actively hostile network from a security perspective once we have the technology to detect and mitigate the attacks. If you ask a plain DNS question you should expect to get a compromised answer. Most of us don't harden our systems nearly enough. We should be able to do work with hardened system otherwise we have failed as engineers. Mark Expectations of support infrastructure change as technology evolves. In those days, we got along just fine without cell phones as well. Based on new technology our co-workers expect a level of internation not previously possible. We are also used to immediate access to reference material and as one person noted, they may take advantage of local laptop access to the presentation material to be able to read it. ... How things were done in the past really has little bearing on how we do then now. On Wed, 19 Dec 2007, Stephane Bortzmeyer wrote: On Tue, Dec 18, 2007 at 01:45:24PM -0500, John C Klensin [EMAIL PROTECTED] wrote a message of 57 lines which said: Between this and apparent efforts by the IAOC, IESG, and sponsor to deliberately disrupt the network, this is beginning to sound like the meeting to miss. I am not old enough to have personal experience of the oldest IETF meetings but I've heard that there was no Internet connectivity at all at these times and yet the IETF was able to work. ___ 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
Back to the proposed IPV6 experiment [was: Re: IETF71 hotel noise warning on Marriott web pages
As longs as I've attended meetings (13 years) and followed the feedback on the IETF list re. meeting network support, the expectation has always been that there would be a very high priority set on creating and maintaining a smoothly operating network to support the meeting. New technologies were deployed along side of the production network and not in lieu of it. It is really absurd to disrrupt the master network to conduct an experiment. I spend a high percentage of my professional life configuring and debugging network hardware and software. There is no way I'll risk any configuration change to my 'production' laptop to attempt to adapt to an experiment/demonstration. The risk of system corruption is too high and I don't have the time or inclination to bring along an image backup/restore to make it safe. Find the funding to staff and equip an experimental lab and network. Make it available in the plenary if you wish as an alternative, but primarily provide it in a dedicated space for those with the time and inclination to experiment. Provide the software and system pre-req guildance ahead of time. Make sure you have Windows/Linux/Apple network experts in the room and we might have a really useful experiment. I for one would consider bringing an extra laptop which could be used on the experimental net and which I would willingly install software, etc. Otherwise forget it ... the direct and indirect cost incurred by each attendee dictates that the IETF make sure their time is well used. This experiment doesn't meet that objective. Dave Morris On Thu, 20 Dec 2007, Mark Andrews wrote: But the IETF network has for as long as I've attended (12 years) been a proving ground for new technology. DHCP, multicast, wireless, IPv6, etc. I'm quite happy to see more testing of future technology / configurations on the network. I'd like to see DNSSEC validation deployed on the recursive DNS servers advertised by DHCP to the network. I'd like to see IETF.ORG signed. I'd like to see SIG(0) deployed on the recursive DNS servers. The IETF net should be a actively hostile network from a security perspective once we have the technology to detect and mitigate the attacks. If you ask a plain DNS question you should expect to get a compromised answer. Most of us don't harden our systems nearly enough. We should be able to do work with hardened system otherwise we have failed as engineers. Mark Expectations of support infrastructure change as technology evolves. In those days, we got along just fine without cell phones as well. Based on new technology our co-workers expect a level of internation not previously possible. We are also used to immediate access to reference material and as one person noted, they may take advantage of local laptop access to the presentation material to be able to read it. ... How things were done in the past really has little bearing on how we do then now. On Wed, 19 Dec 2007, Stephane Bortzmeyer wrote: On Tue, Dec 18, 2007 at 01:45:24PM -0500, John C Klensin [EMAIL PROTECTED] wrote a message of 57 lines which said: Between this and apparent efforts by the IAOC, IESG, and sponsor to deliberately disrupt the network, this is beginning to sound like the meeting to miss. I am not old enough to have personal experience of the oldest IETF meetings but I've heard that there was no Internet connectivity at all at these times and yet the IETF was able to work. ___ 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
With all of this layer 10 discussion of V4 V6 outages...which bores me to no end.
It's useful to have a holiday season reminder of why we are doing any of this at all. http://www.nytimes.com/2007/12/19/education/19physics.html?emex=1198213200; en=f1969a5703b764c9ei=5087%0A If there was ever a reason to reflect on why we argue about dancing packets on the head of a pin this is it. It is a ongoing privilege to make things like this happen. This article BTW is the Number One emailed article currently on the NY Times web site. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
It the outage happens at the last plenary session then everyone will have the whole week before the plenary to set up their laptop to IPv6 as IETF now has the 2 stacks on its network. Reading the threads: -David said there will be records in the root well before the event -seems that jabber.ietf.org is not IPv6 but that can be fixed before the event -some IETF sites/mailing lists are not IPv6, what is the list, and how to fix that before the event? -an IPv6 room seems to be needed, where there will be volunteers ready to help configure delegates machines to IPv6 -... I think a TODO list is needed, and each item actioned as to reduce the unpleasantness of the experience. Get also your corporations/organizations to assess if they will be visible or not on IPv6 before the event. Get them to join the experiment and get ready, I think it will do some good PR for the ones that are ready. Not a small feast, but most of it doable. -- Franck Martin ICT Specialist [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Dec 19, 2007, at 7:22 PM, Franck Martin wrote: It the outage happens at the last plenary session then everyone will have the whole week before the plenary to set up their laptop to IPv6 the laptop is the trivial part. It is the supporting infrastructure at the home corporation that is an issue. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Which is why I said get your corporation to support the experiment. Will Cisco be visible on IPv6 only? Can you continue to work like nothing happened? Who else expect no problem during the experiment? Raise the hand ;) Fred Baker wrote: On Dec 19, 2007, at 7:22 PM, Franck Martin wrote: It the outage happens at the last plenary session then everyone will have the whole week before the plenary to set up their laptop to IPv6 the laptop is the trivial part. It is the supporting infrastructure at the home corporation that is an issue. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Franck Martin ICT Specialist [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
Fred Baker wrote: On Dec 19, 2007, at 7:22 PM, Franck Martin wrote: It the outage happens at the last plenary session then everyone will have the whole week before the plenary to set up their laptop to IPv6 the laptop is the trivial part. It is the supporting infrastructure at the home corporation that is an issue. Rhetorical question. Does your vpn client policy file use dotted quads or a hostname? If you had access to a nat64 translator would your vpn client assuming it supports ipv6 cope? No need to answer but it's worth exploring for those of us who develop/deploy vpn platforms should think about. ___ 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 71 - Early Arrival Alert
Please take note of the early arrival alert posted on our microsite and on the IETF website: If you are considering arriving on the Saturday before IETF 71 (March 8, 2008), please be aware that the Philadelphia Flower Show is taking place next door at the Philadelphia Convention Center. This is a very popular show which attracts over 250,000 people each year. It is run by the Pennsylvania Horticultural Society, and is the largest indoor flower show in the world. That show ends on the Sunday that IETF 71 begins, so most people will be checking out the same day that most IETF people will be checking in. Thus, if you plan to arrive early, contact the hotel ASAP to make your reservation and understand that the Saturday rate may be higher (or unavailable) due to high demand. http://ietf71.comcast.net/?page_id=5 Regards Jason Livingood Comcast ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF 71 Microsite
FYI - We have setup a small website regarding IETF 71 at http://ietf71.comcast.net for attendees This site includes additional hotel recommendations, information about traveling to the city, the social event, and will include important information about such topics as where to get a good drink or where to eat. :-) You can get updates via RSS feed too. Regards Jason Livingood Comcast -Original Message- From: IETF Secretariat [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 18, 2007 10:59 AM To: IETF Announcement list Cc: [EMAIL PROTECTED] Subject: 71st IETF - Registration 71st IETF Meeting Philadelphia, PA, USA March 9-14, 2008 Registration is now open for the 71st IETF Meeting! You can register on line at: http://www.ietf.org/meetings/71-IETF.html REGISTRATION INFORMATION: Early-Bird Registration - USD 635.00 If you register and pay for your attendance to the IETF-71 before 17:00 ET-US (22:00 UTC/GMT), Friday, 29 February 2008, you will pay the early-bird price of USD 635.00. After Early-Bird cutoff - USD 785.00 You can still register and pay online at USD 785.00 until 17:00 ET-US (22:00 UTC/GMT), Friday, March 7 2008. Full-time Student Registrations - USD 150.00 Full-time students with proper ID are eligible to receive a special USD 150.00 student rate. Student rate is not subject to any late-fees. Students will also be able to register on-site at the special student rate. Failure to provide valid student ID on-site will revoke the special student status. CANCELLATION: The cut-off for registration cancellation is Monday, 3 March at 17:00 ET-US (22:00 UTC/GMT). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. ON-SITE REGISTRATION: You can register onsite at the meeting in Philadelphia, PA, USA starting Sunday, 9 March at 12:00 noon (local time - ET). The IETF meetings start Monday morning and run through Friday lunchtime, with late scheduling changes. Most training session take place on Sunday afternoon 9 March. Participants should plan their travel accordingly. The IETF Secretariat ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
UPDATED Last Call: draft-ietf-ippm-storetraceroutes (Information Model and XML Data Model for Traceroute Measurements) to Proposed Standard
The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Information Model and XML Data Model for Traceroute Measurements ' draft-ietf-ippm-storetraceroutes-07.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 substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-01-15. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14961rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
