Re: IPv6 will never fly: ARIN continues to kill it
because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. I prefer losing some bytes in all my packets between locations using different ULA-D prefixes to get an underlying VPN / tunneling infrastructure. This allows me to keep things flat, i.e. pure routing. itojun, let's just stop using the 3 letters word. It does not exist anymore. is it ULA, NAT, VPN or all of them :-) itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Paul Vixie wrote: http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it from all getting routed anyway. while that's not an unreasonable fear, i'm alone in considering it a manageable risk. I'm afraid I'll have to leave you alone there. [RIR-PI] makes [ULA-GLOBAL-00] somehow palatable, but not enough. In a nutshell, your argument is that since [RIR-PI] has been adopted, there is little risk that [ULA-GLOBAL-00] degenerates into free-for-all PI. That's a valid point, but IMHO the problem is that [RIR-PI] is not good enough in too many eyes; in other words there still are many remaining temptations to abuse [ULA-GLOBAL-00]. so while i harken to your concern that IPv6 will never fly, i think that the reasons for it are much larger than whatever part you think ARIN could do differently. Agree. Michel Py wrote: The real world would probably go for IPv6 NAT instead, but the IETF is deadlocked; instead of choosing between the lesser of two evils and sacrifice one of the features, they want to have the cake and eat it too. Paul Vixie wrote: ietf said don't do nat in v4. the market said screw you. The market won, and ietf ended up having to add nat support into various protocols, and started having nat oriented working groups, and so on. i expect the same with nat v6. I agree, but my point was that the market might prefer double-v4NAT to IPv6 NAT. The situation is quite different: IPv4 NAT solved most of the renumbering issue. IPv6 NAT does not bring anything to the table that IPv4 NAT does not already have. In other words: if you want NAT, no point upgrading to IPv6. i have more confidence in the ability of router vendors to bend moore's law and in backbone architects and routing protocol architects to bend graph theory, than i have for example in diesel-from-algae as a way to solve the world's carbon problem. so i'm not nec'ily hopeful, but i'm more hopeless about other things than i am about a 2M-route DFZ. Agree too, but as you said above the reasons are much larger. In other words, even if vendors promised a 10M DFZ capable routers and the RIRs gave PI to anybody who asks for it, we would still be nowhere near take off. Roger Jørgensen wrote: are they still refusing to put it into the queue or do anything? Even after several month? Well let really hope that will change now when/if IPv6-wg change the name to 6man and we can start working again! A few months are very little time in IETF time! Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 9/13/07, Jun-ichiro itojun Hagino [EMAIL PROTECTED] wrote: http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. IP address, or part of it, can never be an ID. so i'm against of all of the ID/LOC separation stuff. IP address can never be an identifier because: - you can switch from one IP version to another - once you have private address/ULA of some sort, you have conflicts it is a crazy thought that you have a unique ID in the lower 64 bit in an IPv6 address. MAC address is indeed not unique - some vendors do not keep the rules. go down to hongkong/akihabara and buy cheap NE2000 ethernet cards, and you'll know. if you need to identify some node/whatever, use ssh secret key, X509 certs, and alike. IP address is just to specify communication endpoint, nothing else. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. This perspective is soluble, but it's not the perspective that we seem to approach the problem from. We also don't have the solution in hand today, but work towards it would be greatly accelerated by backing away from our long-standing positions, terminologies and arguments and truly focusing on the problem at hand. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Roger Jørgensen wrote: did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. ID/LOC has been discussed for 11 years and canned several times. http://arneill-py.sacramento.ca.us/ipv6mh/draft-odell-8+8-00.txt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. One of the best ways to get these things fixed would be for the router/firewall/... companies to actually switch between prefixes on a regular (monthly initially) basis. This of course assumes that they are using their own products. Can my firewall be reconfigured just by adding/deleting a prefix? Can my router be reconfigured just by adding/deleting a prefix? Can my ... Similarly multi-home some sites out of PA space and regularly break connectivity on to one or more providors. Nothing like doing to work out the bugs is the system. Mark Tony ___ 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
Re: IPv6 will never fly: ARIN continues to kill it
Michael, Here's a decision table for you: 1. Do you need addresses that are routable from the global Internet, from anywhere? (Its not clear to me that you do, because you only need to do that within your own network and a couple of well known external sites perhaps.) a. If not, maybe you should look at ULAs. RFC 4193 allows you to get these addresses randomly, and you do not need to ask permission from anyone to do it. You could have your addresses today if you wanted to. b. Proposals have been floated about non-random ULAs as well. Right now we do not have one, but I'm not sure you need this for your particular case. 2. If you do need addresses that are routable, is it sufficient for you to work with provider-aggregated addresses that you get from your ISP (not from ARIN)? If yes, get the addresses and use them! 3. If you do need addresses that are routable AND you have multiple ISP connections and want to stay away from an address renumbering if you need to change ISPs, then you need PI. You are starting to get PI space, but as numerous PI items in the global routing table cause pain for routers, this will likely be available only for larger enterprises. There is ongoing work to try to design a better routing system that would be capable of keeping tens of millions of prefixes or more, in the IRTF. If and when that work succeeds, it would be possible to allocate everyone their own PI prefix. We are not there yet. In any case, FWIW, I think it would make sense for RIR address allocation rules to allow IPv6-only operations and not just those that need both IPv4 and IPv6 address space. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark, Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. You must have access to technology that at least I'm not aware of. We can automate some parts of the process, like hosts can get new addresses via RA, DHCP, and we have some tools for renumbering routers. But what about addresses embedded in firewall configs, applications, DNS, etc? Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Thu, Sep 13, 2007 at 04:05:09PM +0900, Jun-ichiro itojun Hagino wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. OK, I'll bite. Never, and never (in nearly 20 years). Although we in effect have IPv4 PI as being an older university we came online when getting an old Class B was easy, before IP allocations were made from the NREN space. We have renumbered our IPv6 networking as part of experimental/research work (and would from that experience certainly say fully automated renumbering is not possible today), but that was just an academic (and very interesting) exercise. If IPv6 PI were available to us we'd use it because it costs us no extra to do so. -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-aboba-sg-experiment-02.txt
Jari Arkko wrote: Alexey, I am looking for a lightweight process that doesn't introduce as much delay as a typical WG does. I'm not sure the SG process is what you are looking for. Hi Jari, I think your reply just confirmed that. FYI: Depending what you do, you may have different alternatives, too besides creating a BOF, then WG, and completing your document there. Some of the alternatives include - Adding a work item in an existing WG. Rechartering for something that is clearly needed uncontroversial should not be a big problem. - Some areas have area WGs that process topics, bug fixes, etc. that do not fit in other WGs. - Individual submission process. Submission to the AD, last call on the IETF main list. For the case I was thinking about (i.e. a draft which was a common dependency between 2 WGs), the 3rd alternative proved to be the quickest. Luckily the document wasn't as controversial as I thought it would be. Option 2 was not available due to lack of any such WG in the Apps Area. Option 1 might have worked, but it could have lead to a discussion about which WG should take it, which is a distraction in itself. There is also a perception than rechartering is sufficiently painful, so many WG don't bother unless they are forced to. See http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html But if you are just generally unhappy with the speed of WGs, that's a tougher problem to solve. Agreed. My message was partially motivated by a recent thread on apps mailing list regarding Individual Submissions versa WG documents. Some of the problems, like lack of author cycles or contentious topics might follow you to whatever process you try to employ. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Roger, On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it are they still refusing to put it into the queue or do anything? Even after several month? Well let really hope that will change now when/if IPv6-wg change the name to 6man and we can start working again! For the record, we had a series of discussions among authors, Paul, experts, etc on the ULA topic right after IETF-69 to try to see if we can sort out what the problems are and move forward. For background, we already have ULAs than can be allocated by the sites themselves. These are defined in RFC 4193. The question on the table (and also part of 6man charter) is whether we need an additional type of ULAs, one that is centrally allocated. Such addresses might be useful for a couple of reasons. One reason is that we could guarantee uniqueness, which might be important, e.g., for a company that is running a lot of small company networks as a business, and wants to ensure the address spaces do not collide. But another, more important stated reason was that we should have a way give people address space that is different from PI in the sense that those addresses are not recommended to be placed in the global routing table. Arguments against such address space relate to the following issues: - The costs for any centrally allocated space are likely going to be the same, so what is the incentive for the customers to allocate ULA-C instead of PI? - There is no routing economy that would push back on advertising more than the necessary prefixes, so what is the incentive that keeps the ULA-C out of the global routing table as years go by? (When the companies that allocated ULA-C grow, merge, need to talk with other companies, etc.) The end result of our discussions was that we clearly do not have agreement on the way forward, and we settled for writing a draft about the issues instead. That is still in the works. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. I don't believe that for a millisecond. There are way too many places that IP addresses creep into the configuration of components from layer 3 all the way to layer 7 (and beyond). The idea that people shouldn't do that is just religion, and not a widely-held religion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. Bank issues a SecurID token (or SD chip with onetime pad) and requires a six-digit PIN to be entered which cannot be reused. In order to get to the bank in the first place, user must enter a URL that is printed on their monthly statement. It changes every month and you may not use any other URL. So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. My bank requires my surname, a customer number that is not the account number, a 5 digit pin code typed in, and a challenge response where the challenge is two random letter positions from my secret word, and the response is two letter selections from two dropdown boxes. No protocols needed. It would be interesting if someone submitted a best practices draft for banking services over the Internet, which documented how banks could prevent, or avoid phishing. Such a draft could say something like, never send customers an email with URLs for a site which requires login. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Hear, hear. We're making binary claims in a grey-scale world of economics. Put the costs on the table and let the enterprises and ISPs fight out PI/PA. - Ralph On Sep 13, 2007, at Sep 13, 2007,5:27 AM, Jun-ichiro itojun Hagino wrote: my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun ___ 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: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. itojun Hear, hear. We're making binary claims in a grey-scale world of economics. Put the costs on the table and let the enterprises and ISPs fight out PI/PA. - Ralph The only problem I have with that is that the market tends to not be very foresighted - it will happily lead itself into a corner from which escape is quite difficult. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark Andrews wrote: On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? I think you forgot to set your alarm clock and are living in that dream world that I mentioned previously. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. OK, I'll bite. Never, and never (in nearly 20 years). Although we in effect have IPv4 PI as being an older university we came online when getting an old Class B was easy, before IP allocations were made from the NREN space. i would like to hear more opinion from organizations that have connected to the internet more recently. the problem i'm seeing in the ietf is (of course there are exceptions): - vocal people have class B/C for their own use so they are not really feeling the pain of NAT (and they are contributing to the bigger size of the routing table) - vocal people are not using IPv6 daily itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Noel Chiappa wrote: In the enterprise world, where I live now, IPv6 is just flat out a non-starter without PI space. Its just not even a discussion that's even useful to have, because the answer to IPv6 without PI is just No. Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. Just out of curiousity, how do the enterprises expect to exhange bits without ISP's? They will find ones that will, or they will start ones that will, or ones will start independently that will. And, yes, the entrenched ISP interests really should perceive that to be a business threat, because it is one. (I just realized that I mentioned nanog in my previous message...I'm so used to this discussion happening over there that I just assumed that was there this message was coming from. Regardless, the sentiments against PI space in IPv6 are very ISP-centric and just as ill-fated whether they're on ietf or nanog.) -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark, Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. You must have access to technology that at least I'm not aware of. We can automate some parts of the process, like hosts can get new addresses via RA, DHCP, and we have some tools for renumbering routers. But what about addresses embedded in firewall configs, applications, DNS, etc? For the DNS use UPDATE to update the address records. For firewall configs. See your firewall vendor. Very very applications need raw addresses. Use the DNS. Jari ___ 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
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 3:05 AM, Jun-ichiro itojun Hagino wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? i have never got any reasonable answer from anyone. Based on the high volume, fairly small enterprises I deal with, roughly every 2 - 3 years. If the Internet and its costs are truly critical to an enterprise, then either cost of service or quality of service perturbations mean that switching is fairly likely with time (or, at least, this has been the case in the past). The biggest barrier to switching is typically legal, not technical. (Switching may require breaking contracts paying penalties.) I don't claim a representative sample, but it's a data point. Regards Marshall itojun ___ 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: IPv6 will never fly: ARIN continues to kill it
Mark Andrews wrote: On Sep 13, 2007, at 12:05 AM, Jun-ichiro itojun Hagino wrote: I believe that a more constructive assessment is that enterprises ar= e unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing= subsystem. my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, =20 enterprises are not willing to buy into vendor lock. Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. I think you forgot to set your alarm clock and are living in that dream world that I mentioned previously. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- 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
Renumbering
On Thu Sep 13 12:39:52 2007, Jeff McAdams wrote: Mark Andrews wrote: Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? Welcome to the IETF, where dreams are made reality. I particularly agree with Mark's final sentence, there - if renumbering is a problem, let's solve it. FWIW, I'm pretty sure that the vast majority of renumbering activity *is* automated, we've simply forgotten that it's already done. We've got autoconf, we've got DHCP, we have oodles of technology that's deployed already. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Hello, Jun-ichiro itojun Hagino [EMAIL PROTECTED] writes: because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. I prefer losing some bytes in all my packets between locations using different ULA-D prefixes to get an underlying VPN / tunneling infrastructure. This allows me to keep things flat, i.e. pure routing. itojun, let's just stop using the 3 letters word. It does not exist anymore. Cheers, a+ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Oy, [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) writes: is it ULA, NAT, VPN or all of them :-) Good point. The answer is in my mail address ;-) a+ -- Arnaud Ebalard EADS Innovation Works - IW/SE/CS - IT Sec Research Engineer PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026 pgp3oWUYmj6f3.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 12, 2007, at 19:07 , [EMAIL PROTECTED] wrote: nevertheless i hope that you will help fix ARIN if it's broken. but in this case i think what's broken is bigger than ARIN. the community badly needs a way to allocate addresses, which as in your example, are unlikely to appear in the global routing table (sometimes called DFZ). these addresses should have whois, in-addr, and so on, so that they can be used in ubiquitous manet's and ad-hoc wireless. given that the internet core can't handle growth of PI, and no large internet entity in their right mind would use PA, it is past time to end what i call the tyrrany of the core. http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it from all getting routed anyway. You have my support for the most part, for whatever that's worth. The only part I disagree with is the involvement from the RIRs: those cater to ISPs 99% of the time and are as such in a bad position to sell addresses that aren't related to internet service provision. Selling these prefixes fits much better with the way domain registrars operate. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. OK, how is it possible to automate the renumbering of my firewall entries which contain IPv6 addresses and prefixes? How is it possible to automate the renumbering of my extranet business partner firewalls who also contain some of my IPv6 addresses and prefixes? How do I automate the renumbering of router ACLs in my own IPv6 network? These are purely theoretical questions, but I do know of many instances where these kinds of things do need renumbering when an IP address prefix changes. Please don't say DEN, WBEM, etc. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Dave Cridland wrote: On Thu Sep 13 12:39:52 2007, Jeff McAdams wrote: Mark Andrews wrote: Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? Welcome to the IETF, where dreams are made reality. I particularly agree with Mark's final sentence, there - if renumbering is a problem, let's solve it. FWIW, I'm pretty sure that the vast majority of renumbering activity *is* automated, we've simply forgotten that it's already done. We've got autoconf, we've got DHCP, we have oodles of technology that's deployed already. Yes, automated technologies handle 80% or 90% or even 99% if you've been draconian in designing your provisioning systems. Its that remnant that makes the process infeasible, and that's not going to be fixed with better protocol designs or technology implementations. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Mark Andrews wrote: If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. Yep, dream-world. -- Jeff McAdams They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Dear Jari; On Sep 13, 2007, at 4:24 AM, Jari Arkko wrote: Michael, Here's a decision table for you: 1. Do you need addresses that are routable from the global Internet, from anywhere? (Its not clear to me that you do, because you only need to do that within your own network and a couple of well known external sites perhaps.) a. If not, maybe you should look at ULAs. RFC 4193 allows you to get these addresses randomly, and you do not need to ask permission from anyone to do it. You could have your addresses today if you wanted to. b. Proposals have been floated about non-random ULAs as well. Right now we do not have one, but I'm not sure you need this for your particular case. 2. If you do need addresses that are routable, is it sufficient for you to work with provider-aggregated addresses that you get from your ISP (not from ARIN)? If yes, get the addresses and use them! 3. If you do need addresses that are routable AND you have multiple ISP connections and want to stay away from an address renumbering if you need to change ISPs, then you need PI. You are starting to get PI space, but as numerous PI items in the global routing table cause pain for routers, this will likely be available only for larger enterprises. I do not really agree with this. First, the routing tables do not care if you have PI or PA space, just whether it is announced or not. If you are already announcing PA space, and getting into the DFZ, it does not harm the tables if you change to PI space. Second, one of reasons I helped to write and push through ARIN 2002-3 (micro assignments) was that I felt that small multi-homers (i.e., enterprises that were multi-homed but did not need large address allocations) did not constitute a threat to the routing tables, and that has been borne out by experience. Neither the growth nor the bloat in the routing tables is being driven by small multi- homers. This has been discussed at great length on ARIN PPML and other lists. Yes, I gave numbers to Vince Fuller about millions of multi-homers, but that was to set an upper bound on the process. I do no believe that every small business will rush out and multi-home, no matter how automated BGP becomes. The small businesses that I know that multi- home (mostly high traffic volume companies providing network services, such as video streaming) have a business need to do so, and it is not realistic nor in my opinion proper to assume that they will not be able to do so, one way or the other. There is ongoing work to try to design a better routing system that would be capable of keeping tens of millions of prefixes or more, in the IRTF. If and when that work succeeds, it would be possible to allocate everyone their own PI prefix. We are not there yet. In any case, FWIW, I think it would make sense for RIR address allocation rules to allow IPv6-only operations and not just those that need both IPv4 and IPv6 address space. I fully agree here. In fact, I would say that IPv6 will have truly succeeded when business requests start coming in that do _not_ want IPv4 space. This should be encouraged, not discouraged. Jari Regards Marshall ___ 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: IPv6 will never fly: ARIN continues to kill it
Marshall, I do not really agree with this. First, the routing tables do not care if you have PI or PA space, just whether it is announced or not. If you are already announcing PA space, and getting into the DFZ, it does not harm the tables if you change to PI space. Sure. But I understood Michael has nothing now, so from his point of view its a question of getting either PI from ARIN or PA from his provider. Second, one of reasons I helped to write and push through ARIN 2002-3 (micro assignments) was that I felt that small multi-homers (i.e., enterprises that were multi-homed but did not need large address allocations) did not constitute a threat to the routing tables, and that has been borne out by experience. Neither the growth nor the bloat in the routing tables is being driven by small multi-homers. This has been discussed at great length on ARIN PPML and other lists. Yes, I gave numbers to Vince Fuller about millions of multi-homers, but that was to set an upper bound on the process. I do no believe that every small business will rush out and multi-home, no matter how automated BGP becomes. The small businesses that I know that multi-home (mostly high traffic volume companies providing network services, such as video streaming) have a business need to do so, and it is not realistic nor in my opinion proper to assume that they will not be able to do so, one way or the other. Ok, I stand corrected. I did not realize this option was available to the smaller entities. (But is that for IPv4, or does it apply to IPv6, too?) There is ongoing work to try to design a better routing system that would be capable of keeping tens of millions of prefixes or more, in the IRTF. If and when that work succeeds, it would be possible to allocate everyone their own PI prefix. We are not there yet. In any case, FWIW, I think it would make sense for RIR address allocation rules to allow IPv6-only operations and not just those that need both IPv4 and IPv6 address space. I fully agree here. In fact, I would say that IPv6 will have truly succeeded when business requests start coming in that do _not_ want IPv4 space. This should be encouraged, not discouraged. Yep. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 9:04 AM, Jari Arkko wrote: Marshall, I do not really agree with this. First, the routing tables do not care if you have PI or PA space, just whether it is announced or not. If you are already announcing PA space, and getting into the DFZ, it does not harm the tables if you change to PI space. Sure. But I understood Michael has nothing now, so from his point of view its a question of getting either PI from ARIN or PA from his provider. Second, one of reasons I helped to write and push through ARIN 2002-3 (micro assignments) was that I felt that small multi-homers (i.e., enterprises that were multi-homed but did not need large address allocations) did not constitute a threat to the routing tables, and that has been borne out by experience. Neither the growth nor the bloat in the routing tables is being driven by small multi-homers. This has been discussed at great length on ARIN PPML and other lists. Yes, I gave numbers to Vince Fuller about millions of multi-homers, but that was to set an upper bound on the process. I do no believe that every small business will rush out and multi-home, no matter how automated BGP becomes. The small businesses that I know that multi-home (mostly high traffic volume companies providing network services, such as video streaming) have a business need to do so, and it is not realistic nor in my opinion proper to assume that they will not be able to do so, one way or the other. Ok, I stand corrected. I did not realize this option was available to the smaller entities. (But is that for IPv4, or does it apply to IPv6, too?) That was 2005-1, which was also adopted. It's not quite the same, but close. Regards Marshall There is ongoing work to try to design a better routing system that would be capable of keeping tens of millions of prefixes or more, in the IRTF. If and when that work succeeds, it would be possible to allocate everyone their own PI prefix. We are not there yet. In any case, FWIW, I think it would make sense for RIR address allocation rules to allow IPv6-only operations and not just those that need both IPv4 and IPv6 address space. I fully agree here. In fact, I would say that IPv6 will have truly succeeded when business requests start coming in that do _not_ want IPv4 space. This should be encouraged, not discouraged. Yep. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Symptoms vs. Causes
At Thu, 13 Sep 2007 12:21:48 +0100, [EMAIL PROTECTED] wrote: and IMHO, any solution that doesn't let the user type his password into some Web form is a non-starter, both for reasons of backward compatibility and because sites (quite legitimately) want to provide a visually attractive interface to users which is consistent across all platforms (for support reasons). This may well be true. However, I'm not aware of any technique which both meets this constraint and is phishing resistant. Bank issues a SecurID token (or SD chip with onetime pad) and requires a six-digit PIN to be entered which cannot be reused. In order to get to the bank in the first place, user must enter a URL that is printed on their monthly statement. It changes every month and you may not use any other URL. Sorry, my fault for remembering to mention the constraint that you also don't have to carry a token around. Obviously, if people are prepared to carry tokens the problem is much easier. That said, this scheme is actually not very secure because it's susceptible to active MITM attacks on the connection to the bank. The schemes I mentioned are substantially more secure. So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. My bank requires my surname, a customer number that is not the account number, a 5 digit pin code typed in, and a challenge response where the challenge is two random letter positions from my secret word, and the response is two letter selections from two dropdown boxes. This is complicated, but actually not particularly phishing resistant-- something that is true of a lot of the mechanisms banks are currently adopting. First, it's vulnerable to the MITM attack mentioned above. Second, it doesn't take that many phishing attacks to extract most of the secret word. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
You must have access to technology that at least I'm not aware of. We can automate some parts of the process, like hosts can get new addresses via RA, DHCP, and we have some tools for renumbering routers. But what about addresses embedded in firewall configs, applications, DNS, etc? For the DNS use UPDATE to update the address records. For firewall configs. See your firewall vendor. Very very applications need raw addresses. Use the DNS. Bad idea. DNS fails a lot more often that IP addresses change. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. That helps, but understanding of IPv6 and mindshare is even harder than forklift upgrades. And you have to educate everyone who might need to configure an application, not just network admins. And if you start looking for technology that would let you automate renumbering your entire network, you might find that the technology that exists is incomplete and unproven. I have yet to see a reliable, standard way to transmit address-based access-control information to applications, for instance. (don't tell them to use DNS, because besides being too unreliable to use for this, I am not aware of a DNS record that can transmit a list of IP address prefix/netmask pairs to applications, or of a standard API that would allow applications to find such information. oh yes, and practical use of DNS security still seems to elude us. and yeah, we shouldn't be using IP addresses for access control - but the general purpose technology to replace that doesn't seem to exist yet, so for the time being people are making do with what they have.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. OK, how is it possible to automate the renumbering of my firewall entries which contain IPv6 addresses and prefixes? Ask your firewall vendor. It isn't rocket science to add support for multiple prefixes. If you all ask they will listen. How is it possible to automate the renumbering of my extranet business partner firewalls who also contain some of my IPv6 addresses and prefixes? Configure a secure channel to push that information to them. I do that today for IPv4 for my home network. My ISP changes my address and I automatically inform the people that need to know of the address change. I also get zero advance notice of the address change. I just wake up in the morning and find that it has changed at 3 am. Happens about once every 3 months. How do I automate the renumbering of router ACLs in my own IPv6 network? Talk to your router vendor. I was not kidding when I suggested that router and firewall vendors should renumber regularly. The only way to make this sort of thing work is to exercise the path until all the problems are gone. These are purely theoretical questions, but I do know of many instances where these kinds of things do need renumbering when an IP address prefix changes. Please don't say DEN, WBEM, etc. --Michael Dillon ___ 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
Re: IPv6 will never fly: ARIN continues to kill it
Except there really is no vendor lock anymore. It is possible to automate the entire renumbering process. If there are spots where it is not automated then they should be found and fixed. Oh man, that's rich. Do you actually believe that? If you design the network for IPv6 and not just copy the IPv4 model. If you use the technology that has been developed over the last 20 years, rather than disabling it, yes it is possible. That helps, but understanding of IPv6 and mindshare is even harder than forklift upgrades. I'll agree that it is hard. That's why the clue x 4 keeps having to be applied. And you have to educate everyone who might need to configure an application, not just network admins. The network admins are a early step. And if you start looking for technology that would let you automate renumbering your entire network, you might find that the technology that exists is incomplete and unproven. Which is why I keep saying. Run through the renumbering exercise. Find the problems. Report them to your vendors. Vendors being proactive would be a big help here. I have yet to see a reliable, standard way to transmit address-based access-control information to applications, for instance. (don't tell them to use DNS, because besides being too unreliable to use for this, I am not aware of a DNS record that can transmit a list of IP address prefix/netmask pairs to applications, It exists. or of a standard API that would allow applications to find such information. They also exist. oh yes, and practical use of DNS security still seems to elude us. It will as long as people don't actually sign there zones. Have you asked for cs.utk.edu to be signed? % dig dnskey cs.utk.edu ; DiG 9.3.4-P1 dnskey cs.utk.edu ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cs.utk.edu.IN DNSKEY ;; AUTHORITY SECTION: cs.utk.edu. 900 IN SOA dns01.cs.utk.edu. miturria.cs.utk.edu. 2007090900 10800 1800 604800 900 ;; Query time: 387 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Sep 14 00:46:21 2007 ;; MSG SIZE rcvd: 79 % and yeah, we shouldn't be using IP addresses for access control - but the general purpose technology to replace that doesn't seem to exist yet, so for the time being people are making do with what they have.) -- 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
Re: IPv6 will never fly: ARIN continues to kill it
That helps, but understanding of IPv6 and mindshare is even harder than forklift upgrades. I'll agree that it is hard. That's why the clue x 4 keeps having to be applied. That's a LOT of people to whack on the side of the head. And it pretty much has to be done in meatspace; the net doesn't help you out with this problem. And if you start looking for technology that would let you automate renumbering your entire network, you might find that the technology that exists is incomplete and unproven. Which is why I keep saying. Run through the renumbering exercise. Find the problems. Report them to your vendors. Vendors being proactive would be a big help here. Yes they would. But basically everyone can assume that this is Somebody Else's Problem. You want to make it the problem for the network admins, sysadmins, users, application writers, and firewall vendors to solve. Those people want to make it the problem for the carrier ISPs and router vendors to solve. And really, fixing the routing system so that it can provide stable global PI addresses to everyone (say, via something LISP-like) might be easier...especially that the need to renumber isn't the only problem that lack of stable global PI addresses causes. oh yes, and practical use of DNS security still seems to elude us. It will as long as people don't actually sign there zones. Have you asked for cs.utk.edu to be signed? I don't work there any more, so it's Somebody Else's Problem. :) And really, there's no way I'd trust DNS to do this. I've spent too many years watching it break. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. At the end of the day, phishing is a social problem, not a technical problem. It can't be solved by purely technical means. All technical solutions to phishing involve some form of behavior change. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. Remember, this is not like typical cryptography MITM attacks where the MITM receives an ecrypted stream and is able to decrypt it, modify it, and reencrypt it. In this case, the user asks the MITM to provide a web page and associated Javascript. While the look of this page will be identical to the bank's page, the functionality does not need to be identical. It can send everything cleartext to the MITM who them emulates the human user. To defeat MITM you need a secure channel, but how can you establish a secure channel to a human being who has already defeated the bank's security system by enlisting the phishing organization as their agent? I would rather see the focus of effort go to building simple embedded computer systems that one can plug into a USB port and rely on to establish an encrypted channel to the bank. That way, the human user does not play any significant role in establishing the channel of communication and cannot subvert the process. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
This is a constructive and helpful posting, Tony. Thank you. Am I correct in presuming that both Noel and you believe that the possible technical solutions to this problem are currently being considered in the RRG / RAM discussions? -Original Message- From: Tony Li [mailto:[EMAIL PROTECTED] On Sep 12, 2007, at 10:57 PM, Noel Chiappa wrote: Let me see if I understand this. Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. This perspective is soluble, but it's not the perspective that we seem to approach the problem from. We also don't have the solution in hand today, but work towards it would be greatly accelerated by backing away from our long-standing positions, terminologies and arguments and truly focusing on the problem at hand. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
That helps, but understanding of IPv6 and mindshare is even harder than forklift upgrades. I'll agree that it is hard. That's why the clue x 4 keeps having to be applied. That's a LOT of people to whack on the side of the head. And it pretty much has to be done in meatspace; the net doesn't help you out with this problem. And if you start looking for technology that would let you automate renumbering your entire network, you might find that the technology that exists is incomplete and unproven. Which is why I keep saying. Run through the renumbering exercise. Find the problems. Report them to your vendors. Vendors being proactive would be a big help here. Yes they would. But basically everyone can assume that this is Somebody Else's Problem. You want to make it the problem for the network admins, sysadmins, users, application writers, and firewall vendors to solve. Those people want to make it the problem for the carrier ISPs and router vendors to solve. I've spent a lot of time adding support to make renumbering easier in the places that I can change. I will continue to do that. I can't however fix every problem. And really, fixing the routing system so that it can provide stable global PI addresses to everyone (say, via something LISP-like) might be easier...especially that the need to renumber isn't the only problem that lack of stable global PI addresses causes. oh yes, and practical use of DNS security still seems to elude us. It will as long as people don't actually sign there zones. Have you asked for cs.utk.edu to be signed? I don't work there any more, so it's Somebody Else's Problem. :) And really, there's no way I'd trust DNS to do this. I've spent too many years watching it break. It breaks much less often once you allow it to be automated. We could in theory have all nameservers update the parent servers with appropriate glue. This is not technically hard to do. Similarly NS RRsets. Keith -- 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
Re: Symptoms vs. Causes
At Thu, 13 Sep 2007 16:14:47 +0100, [EMAIL PROTECTED] wrote: So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. (1) No, this technique is still easily phished by someone who impersonates the image map. (2) It's easy to write keyloggers that would capture mouse clicks. Nobody does it because the imagemap technique is not widely used. If it were, that would change. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. That's far from clear, but even if it were so, the phisher can force multiple trials on the same phishing email, as if you had mistyped, thus recovering significant portions of the secret word. And of course, this either requires multiple secret words or a strong password equivalent on the server side. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. I suppose it depends on what you mean by cleartext inputs. See: [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, A Convenient Method for Securely Managing Passwords, In Proceedings of the 14th International World Wide Web Conference (WWW 2005) [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
And really, there's no way I'd trust DNS to do this. I've spent too many years watching it break. --Keith i suspect that you're measuring the wrong thing, or that you're not paying attention to the what that you're measuring. in a every distributed system of sufficient size, there is always something broken somewhere. the sysadmins at ISC were for example concerned when the trend of broken f-root hosts got to the 1-a-day level until someone pointed out that once you've got more than 100 systems at least one will always have something wrong with it and it's a good thing we put two in every POP and have a lot of POPs isn't it? yes, DNS is always broken. so is the routing table. so is the airline system and most road systems and the stock market. and it always will be broken, since in systems of sufficient size, entropy and human error are signigicant enough to be noticed. if you don't want to use something that will break, you ought to start by pulling the power cord out of all your servers and routers. it's just not reasonable to demand 100% uptime from a million-node distributed system where most of the nodes are operated by other people. doesn't matter if the nodes are BGP routers, web servers, DNS servers, or botted home PC's. odell's 8+8 relied on DNS for location-routing mapping and that could be one of the reasons it had so little support. but in the decade+ since then, DNS has scaled better than the routing system. odell had a reasonable design but it lacked the architectural purity of... whatever it is we're using instead. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Okay, let me say this more precisely. I've seen too many occasions over the years where DNS was broken so badly that the only way to get things fixed, or to get work done, or to keep applications operating, was to bypass DNS - either by typing in an IP address somewhere. And of course those alternative mechanisms also break - but the combination of mechanisms work better than DNS alone. And of course one of the reasons that the combination works better is that the addresses of important hosts rarely change. I'm not saying that DNS can't be improved to be more reliable - clearly it can. I'm not saying that DNS hasn't been improved - clearly it has, though old habits die hard and users are slow to change what works for them. But putting _all_ addresses in DNS makes DNS failures a lot more critical than they are now, and there are good reasons for being reluctant to do that. And really, there's no way I'd trust DNS to do this. I've spent too many years watching it break. --Keith i suspect that you're measuring the wrong thing, or that you're not paying attention to the what that you're measuring. in a every distributed system of sufficient size, there is always something broken somewhere. the sysadmins at ISC were for example concerned when the trend of broken f-root hosts got to the 1-a-day level until someone pointed out that once you've got more than 100 systems at least one will always have something wrong with it and it's a good thing we put two in every POP and have a lot of POPs isn't it? yes, DNS is always broken. so is the routing table. so is the airline system and most road systems and the stock market. and it always will be broken, since in systems of sufficient size, entropy and human error are signigicant enough to be noticed. if you don't want to use something that will break, you ought to start by pulling the power cord out of all your servers and routers. it's just not reasonable to demand 100% uptime from a million-node distributed system where most of the nodes are operated by other people. doesn't matter if the nodes are BGP routers, web servers, DNS servers, or botted home PC's. odell's 8+8 relied on DNS for location-routing mapping and that could be one of the reasons it had so little support. but in the decade+ since then, DNS has scaled better than the routing system. odell had a reasonable design but it lacked the architectural purity of... whatever it is we're using instead. ___ 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: IPv6 will never fly: ARIN continues to kill it
my persistent question to the enterprise operator is this: how frequently do you plan to switch your isp, or how many times did you do that in the past? That's actually irrelevant. Regardless of the real answer, enterprises are not willing to buy into vendor lock. if the management needs to be convinced by the cost, i would suggest ISPs to price PI advertisement like hell ($$$), so that we can make the worldwide routing table smaller. it will help ISPs use smaller peering routers in the end. that's not how business economies work. many isp's are hoping that other isp's adopt the pricing model you propose above, because it will drive sales toward the isp's who don't adopt it. the middle quote above is perfectly correct: that's actually irrelevant. as the cost of renumbering slider moves upward, so will the price gouging by ISP's. nobody wants to leave money on the table. a business who knows it will be difficult to renumber also knows that whatever ISP they choose will use that difficulty as leverage whereby their service level will be low and their pricing will go higher. PI is counter-leverage. without it, you get NAT, with small islands of PA on the outside and probably IPv4 on the inside. telling ISP's what they should do when it will mean making less money is a waste of your time and theirs. telling enterprises what they should do when it means paying more money is likewise a waste of everybody's time. this is not a managed economy. imagine cisco using verizon-provided PA space to number every workstation and wireless LAN and router and server in the company. would they be so foolish? (i'm not picking on verizon here, as far as i know they run a fine network.) now imagine ford motor company. or toyota. or wal-mart. or any bank. is it only the large companies who can't afford the risk of price lock-in? so, imagine home depot or norwegian cruise lines. if i were the CIO of any of those companies, i'd say PI or NAT, exclusively and if i didn't, then i'd expect the board and shareholders to hunt me down and kill me once the bills started coming due. (i'm signing off for the day, having reached what i think is a reasonable quota for one mailing list in one day-night cycle, and i've delete-paragraphed a whole rant tying this back to the Tyranny of the Core and ula-global.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Symptoms vs. Causes
You are both wrong. Mouseclick loggers are commonplace. They have been around for at least four years, about six months after banks in Brazil started to use mouse based keyboards. Some of them capture the screen area round the mouse pointer at the time of the click. From: Eric Rescorla [mailto:[EMAIL PROTECTED] Sent: Thu 13/09/2007 11:27 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Symptoms vs. Causes At Thu, 13 Sep 2007 16:14:47 +0100, [EMAIL PROTECTED] wrote: So much for typing. How about selecting password letters from dropdown boxes, or from an image map with scrambled letters that was sent to the browser. Sorry, what about these? They have essentially the same security properties as cleartext passwords. One would hope that all communication from the browser to the server is encrypted as in SSL regardless of whether passwords go in cleartext or whether there is some Javascript to encrypt them first. In that case, the big issue is keylogging software that has been widely installed by malware distributed by Phishing organizations. Key-stroke loggers do not look at mouse-clicks. (1) No, this technique is still easily phished by someone who impersonates the image map. (2) It's easy to write keyloggers that would capture mouse clicks. Nobody does it because the imagemap technique is not widely used. If it were, that would change. Second, it doesn't take that many phishing attacks to extract most of the secret word. Depends on length of said word/phrase. Also, I can see how naïve people are fooled by the first email, but surely the percentage who would click on each successive email, decreases. That's far from clear, but even if it were so, the phisher can force multiple trials on the same phishing email, as if you had mistyped, thus recovering significant portions of the secret word. And of course, this either requires multiple secret words or a strong password equivalent on the server side. You've mentioned man-in-the-middle attacks. Such attacks cannot be prevented if the user interface requires cleartext inputs. I suppose it depends on what you mean by cleartext inputs. See: [0] J. Alex Halderman, Brent Waters, and Edward W. Felten, A Convenient Method for Securely Managing Passwords, In Proceedings of the 14th International World Wide Web Conference (WWW 2005) [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. -Ekr ___ 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: IPv6 will never fly: ARIN continues to kill it
On Sep 13, 2007, at 5:33 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OK, how is it possible to automate the renumbering of my firewall entries which contain IPv6 addresses and prefixes? How is it possible to automate the renumbering of my extranet business partner firewalls who also contain some of my IPv6 addresses and prefixes? How do I automate the renumbering of router ACLs in my own IPv6 network? As a practical matter, these things are quite doable. Sane network management practices store the configuration for such devices in offline management stations. By then writing these configurations in a parameterized form, you can then use the current variable definitions to expand out a concrete configuration. The tools for this are not rare. Languages such as Perl, or macro processors such as cpp or m4 are more than adequate to the task. Loading the results of these tools into devices is also trivial. See rancid, for example. For larger cases, one can also integrate a SQL database to help provide organized scalability. This is not theoretical, I've worked with all of the above. Regards, Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
I particularly agree with Mark's final sentence, there - if renumbering is a problem, let's solve it. How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
From: Dave Cridland [EMAIL PROTECTED] FWIW, I'm pretty sure that the vast majority of renumbering activity *is* automated, we've simply forgotten that it's already done. We've got autoconf, we've got DHCP, we have oodles of technology that's deployed already. My apologies for intruding, because I haven't been following the technology during the past couple of years, but V6OPS did an informational RFC on renumbering without a flag day (http://www.ietf.org/rfc/rfc4192.txt) in 2005. I thought the document was helpful when I last looked at it (prepublication). There may be additional types of devices that have become more widely deployed during the past couple of years, that would be affected by renumbering - I'm thinking about SBCs, or Session Border Controllers, as one example - but I think the document addresses these devices in a generic way - the extreme form of caching addresses is sticking them in configuration files, but this is a difference of degree, not of kind, from the caching discussion in the document. I'm copying the v6ops chairs, so perhaps they can clarify something... This RFC identified a couple of opportunities: 4. Call to Action for the IETF The more automated one can make the renumbering process, the better for everyone. Sadly, there are several mechanisms that either have not been automated or have not been automated consistently across platforms. 4.1. Dynamic Updates to DNS Across Administrative Domains 4.2. Management of the Reverse Zone Have these holes been filled in during the past couple of years? Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
{A few short comments rolled into one...}
From: Tony Li [EMAIL PROTECTED]
As a practical matter, these things are quite doable.
Tony, my sense is that the hard part is not places *within one's own
organization* where one's addresses are stored, but rather in *other
organizations*; e.g. entries in *their* firewalls. Can those with
experience confirm/deny this?
From: Jeff McAdams [EMAIL PROTECTED]
the sentiments against PI space in IPv6 are very ISP-centric
If the system routing (which is not, after all, the property of any one
organization) collapses, it's not just the ISP's who will suffer.
From: Marshall Eubanks [EMAIL PROTECTED]
the routing tables do not care if you have PI or PA space, just
whether it is announced or not. If you are already announcing PA
space, and getting into the DFZ, it does not harm the tables if you
change to PI space.
Yes, but the whole point of PA space is that generally organizations using
them *don't* each have a separate entry in the DFZ; with PI space, *every*
organization *does*.
From: [EMAIL PROTECTED] (Arnaud Ebalard)
let's just stop using the 3 letters word. It does not exist anymore.
Yes, those shelves upon shelves of 3-letter boxes at all my local
electronics stores don't exist. And all the millions of them deployed in
the network don't exist either. Speaking of living in that dream
world :-)
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: IPv6 will never fly: ARIN continues to kill it
From: Tony Li [EMAIL PROTECTED] Without PI, the enterprises say no, and with PI, the ISP's say no. Got it. I believe that a more constructive assessment is that enterprises are unwilling to pay non-trivial costs to renumber, and ISPs are unwilling to pay non-trivial costs to support a non-scalable routing subsystem. Tony, your version is more diplomatic, and quite correct, but the bottom line is exactly the pithy, blunt version I gave. From: Paul Vixie [EMAIL PROTECTED] if i were the CIO of any of those companies, i'd say PI or NAT, exclusively It's really unfortunate that we still have an architecture where these are the only two choices to respond to the situation you have portrayed, with lock-in (which I agree is not acceptable). However From: Michel Py [EMAIL PROTECTED] ID/LOC has been discussed for 11 years and canned several times. Yes, unfortunately - see previous two comments. From: Fleischman, Eric [EMAIL PROTECTED] possible technical solutions to this problem are currently being considered in the RRG / RAM discussions? It's unfortunate that only now are solutions to the Hobson's choice portrayed in the first two comments being seriously explored. Alas, it looks like the solution will involve a major kludge, in order to provide the second namespace that wasn't there (and should have been, all along). In other words, IPv6 is already obsolete, before it's even deployed. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
sorry to add more chaff, i know i'm over quota for the day, but... In other words, IPv6 is already obsolete, before it's even deployed. Noel do you mean that IPv6 was too little, too soon ? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Thu, 13 Sep 2007, David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Tony Finch wrote: On Thu, 13 Sep 2007, David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch to expect apps to do so. And for that matter, a DNS name is not a host name, and hasn't reliably been a host name since at least the mid 1980s. Just because you get address A1 from doing a lookup on a name at time T1 and an address A1 from doing the same lookup at time T2, doesn't mean that those addresses will connect to the same (layer 3 or higher) stack. So even if we somehow magically changed our existing transport protocols to be able to support changes to endpoint addresses on the fly, DNS names as they are currently used are not suitable as endpoint identifiers for such a purpose. At best, existing DNS names serve as identifiers for the initial contact only. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Keith Moore wrote: And for that matter, a DNS name is not a host name, and hasn't reliably been a host name since at least the mid 1980s. Just because you get address A1 from doing a lookup on a name at time T1 and an address A1 from doing the same lookup at time T2, doesn't mean that those addresses will connect to the same (layer 3 or higher) stack. sorry, typo. I meant to say ...an address A2 from doing the same lookup at time T2, ... Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Sep 13, 2007, at 11:43 AM, Tony Finch wrote: On Thu, 13 Sep 2007, David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Then pretty much every IP-aware application ever written is broken. If you had a separation between locator and identifier, the application could bind to the identifier and renumbering events could occur on the locators without impacting the identifier. Long running critical applications wouldn't even notice. You could even get stuff like simple multi-homing and transparent mobility for free. People would live in peace and harmony for ever and ever. Etc. But we don't have that separation. We are burdened with an architecture that was designed before we had how this whole Internet thing was going to work beaten into the operational community's heads with large sticks. We had an opportunity to fix that, but we blew it. We kept the same architecture, just making it bigger and ignoring the operational problems that architecture imposed (and some people at the time argued this was a good thing). But hey, at least we weren't saddled with that evil OSI TP4/CLNP stuff. We showed them, didn't we? We appear to now be at a point where more folks have realized that we have to either come up with IPngng or backfit some kludge onto IPng to address the operational problems that existed in IP and were carried over into IPng because it is just IP with more bits. Unfortunately, we're now looking down the barrel of exhaustion of the IPv4 free pool (2 to 3 years, based on current projections), so we don't even have the luxury of time to bicker about it anymore. Doesn't mean we won't bicker, of course. I suspect we have 3 alternatives: a) IPv4+NAT b) IPv6 with aggressive prefix length filters and highly indeterminate reachability for longer prefix PI address holders. c) IPngng (maybe IPv6 with some sort of locator/id split hacked onto it) The default will be (a). Choose wisely. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Call for action vs. lost opportunity (Was: Re: Renumbering)
David, We had an opportunity to fix that, but we blew it. I think everyone agrees that having that flexibility (ease of renumbering, no routing explosion in the core etc) would be good. But I would suggest that instead of playing the what if or I told you so games, we collectively focus on solving the problem. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. And we have a place for that work to happen in the IRTF. There's a lot of promising work, but they don't have a final solution yet; the details do matter (and I suspect that they also mattered back at the time IPv6 was being designed). Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
I suspect we have 3 alternatives: a) IPv4+NAT b) IPv6 with aggressive prefix length filters and highly indeterminate reachability for longer prefix PI address holders. c) IPngng (maybe IPv6 with some sort of locator/id split hacked onto it) The default will be (a). Choose wisely. it's not at all clear that these are mutually exclusive. IPv4+NAT is here and it's not going away anytime soon. Even if an ideal solution using IPv6 were to surface tomorrow, we'd still be dealing with IPv4+NAT for 10 years or so. The most popular applications that exist today will be the last ones to move to IPv6 (or to stop supporting IPv4) because those are the ones that have the most investment in IPv4 and NAT workarounds. To put it another way, IPv4 is part of the critical infrastructure for those applications. They might start supporting IPv6 in addition to IPv4, but IPv4 support will be the necessary condition for interoperability of those applications until IPv6 is as ubiquitous as IPv4. Meanwhile there will be a need to host applications on IPv6-only networks that still have access to the global IPv4 infrastructure - and the solution to this probably ends up looking a bit like a NAT (though one in which apps are explicitly aware of and control the bindings rather than something like NAT-PT that tries to fool apps into thinking it isn't there). IPv6 with PI addresses seems likely - the only question is how big you have to be to get a PI address prefix. In the near term, scalability is not an issue, but if IPv6 is at all successful the growth in routing table sizes, updates, etc. could be quite steep. Prefix length filters might not be the mechanism used to decide which prefixes get routed and which ones don't, but there will be some mechanism for this. Lots of versions of LOC+ID split have been talked about over the years. A lot of people believe in the concept, but the devil is in the details. Still, my impression is that newer proposals in this area are more realistic than those I saw a few years ago, both in actually being implementable and in accommodating the diverse set of interests that is the Internet. I think it will still take a few years for a standards-quality solution to emerge. Meanwhile, we'll be using some mixture of the above. We might or might not get a good LOC+ID solution in place before the routing scalability limitations of PI addresses result in another crisis. But I really don't think we have the luxury of choosing one of these over the other. We need to work on all of these, and more. We need to think of them as complementary approaches rather than competing ones, even while we recognize that some of them have much better long-term viability than others. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? ... If you had a separation between locator and identifier, the application could bind to the identifier and renumbering events could occur on the locators without impacting the identifier. For a long time I've suggested that we begin to look anew at the idea of an association as an abstraction over transport. Yes, I know that this smacks if ISO/OSI, but there were a few granules of good ideas there. The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Then, if the underlying transport goes away, perhaps due to movement in a mobile network or renumbering, then the association is reconstructed on a new transport that is built in accord with the current addressing and routing conditions. Reconstruction does not, as some have assumed, require that the network remember anything or hold any state. Rather, taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. Basically whenever applications establish a transport they say Ahem, where were we when we last spoke. One answer is We did not last speak Another answer is we last agreed on the checkpoint named 'foo'. How they recover from 'foo' is entirely application dependent. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) (I'm also thinking of TCP based applications, not UDP based ones. For them I don't see renumbering as much of a problem, but I may not be seeing enough.) This is not something that can readily be transparently back-ported into existing protocols; it's not something of trivial import. But it can be deployed for new applications and not invalidate either existing applications or existing application protocols. And consider, for example, how something like this might have obviated the need for the IP layer triangulation in mobile IP. --karl-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Offhand I don't know why it should be necessary to build a mechanism that spans several transport lifetimes. I would much prefer that we re-engineer our transport protocols to let them work in terms of endpoint IDs. In particular, checkpoints would seem to make life more complicated for applications by lowering the level of service from transport protocols - because I think it would be hard to implement transport-independent and application-independent checkpointing in a way that made sense. I do however think that there might be a place for a mini layer in between IP and transport that accomplished a few things that we seem to need in all transports. e.g. management of ID-LOC mapping, management of multiple LOCs per endpoint ID, striping of traffic across multiple paths, management of RTT and other estimators, congestion control, peer authentication, encryption, and explicit interaction with layer 3 intermediaries. Keith For a long time I've suggested that we begin to look anew at the idea of an association as an abstraction over transport. Yes, I know that this smacks if ISO/OSI, but there were a few granules of good ideas there. The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Then, if the underlying transport goes away, perhaps due to movement in a mobile network or renumbering, then the association is reconstructed on a new transport that is built in accord with the current addressing and routing conditions. Reconstruction does not, as some have assumed, require that the network remember anything or hold any state. Rather, taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. Basically whenever applications establish a transport they say Ahem, where were we when we last spoke. One answer is We did not last speak Another answer is we last agreed on the checkpoint named 'foo'. How they recover from 'foo' is entirely application dependent. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) (I'm also thinking of TCP based applications, not UDP based ones. For them I don't see renumbering as much of a problem, but I may not be seeing enough.) This is not something that can readily be transparently back-ported into existing protocols; it's not something of trivial import. But it can be deployed for new applications and not invalidate either existing applications or existing application protocols. And consider, for example, how something like this might have obviated the need for the IP layer triangulation in mobile IP. --karl-- ___ 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: Renumbering
On Sep 13, 2007, at 20:52 , Keith Moore wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Disconnect current session, reconnect. Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Since when is it the job of applications to manage DNS TTLs? Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch to expect apps to do so. Right. And for that matter, a DNS name is not a host name, and hasn't reliably been a host name since at least the mid 1980s. Just because you get address A1 from doing a lookup on a name at time T1 and an address A1 from doing the same lookup at time T2, doesn't mean that those addresses will connect to the same (layer 3 or higher) stack. So even if we somehow magically changed our existing transport protocols to be able to support changes to endpoint addresses on the fly, DNS names as they are currently used are not suitable as endpoint identifiers for such a purpose. At best, existing DNS names serve as identifiers for the initial contact only. This falls under the heading of nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away. Giving in to this logic means that it's impossible to change ANYTHING. As the saying goes, in an infinite universe, everything that's possible, does indeed exist. The internet is pretty much an infinite universe these days. As for renumbering, on a Cisco router, I can make the following configuration: ! interface Ethernet1 ipv6 address autoconfig ipv6 dhcp client pd dhcpv6prefix ! interface Ethernet2 ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64 ! This way, the router obtains an IPv6 prefix dynamically from a DHCPv6 prefix delegation server and then sends out router advertisements using that prefix. So you can renumber the router and all the hosts connected through it by changing one entry in a DHCPv6 server config. However, I don't think this method applies everywhere (such as in filters) but obviously that's something that would be possible if desired. Even with the current state of the art I'd say that renumbering clients is not a big deal. Renumbering servers is more difficult, though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Sep 13, 2007, at 23:00 , Karl Auerbach wrote: The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Wouldn't that be the OSI session layer (that IP doesn't have)? taking a cue from ISO/OSI, the trick is that the association layer is merely a means for the applications to reliably exchange checkpoint names. What those checkpoint names mean is up to the applications - thus what to do if a rebinding to a new transport requires going back to a checkpoint is something entirely within the application and its networking library code, not some state that is stored in the net. We already do that today at the TCP layer. Rather than reinvent TCP in all individual applications (all those checkpoints will be great for performance!) it's much easier to hide changes in IP connectivity from TCP. We also pretty much have that today, in the form of shim6. Note thought that none of that solves renumbering, rather, it really needs better renumbering support to work well. (I have not really considered the security implications - in the absence of some form of shared secret or other authentication on association re-establishment there would probably be a race condition in which an intruder could jump in.) Seperating location and identity requires some pretty hefty security, otherwise anyone can impersonate anyone. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Disconnect current session, reconnect. Uh, not unless your application has some sort of retry or checkpoint-restart capability. SMTP is pretty resilient in the face of connection breakage, and for some interactive applications you just hit retry or the equivalent, which has caused some people to think that somehow it's okay if the network changes a host's IP addresses out from under it. But it doesn't work in general. And for that matter, a DNS name is not a host name, and hasn't reliably been a host name since at least the mid 1980s. Just because you get address A1 from doing a lookup on a name at time T1 and an address A1 from doing the same lookup at time T2, doesn't mean that those addresses will connect to the same (layer 3 or higher) stack. So even if we somehow magically changed our existing transport protocols to be able to support changes to endpoint addresses on the fly, DNS names as they are currently used are not suitable as endpoint identifiers for such a purpose. At best, existing DNS names serve as identifiers for the initial contact only. This falls under the heading of nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away. No, it just means that people shouldn't assume that existing DNS names (i.e. the ones we're already using to identify hosts and services) will work as endpoint identifiers for the purpose of connection restart. People are using DNS names to name things that aren't hosts (e.g. services or groups of hosts) for valid reasons and any solution that destroyed this functionality would be a non-starter. As for renumbering, on a Cisco router, I can make the following configuration: [deleted for brevity] This way, the router obtains an IPv6 prefix dynamically from a DHCPv6 prefix delegation server and then sends out router advertisements using that prefix. So you can renumber the router and all the hosts connected through it by changing one entry in a DHCPv6 server config. That's the least of the problems with renumbering. A few years ago I was involved in renumbering of a class B IPv4 network. DHCP and DNS doesn't even begin to cover it. Even with the current state of the art I'd say that renumbering clients is not a big deal. Renumbering servers is more difficult, though. The distinction between client and server is fairly meaningless. It's certainly not something you want to assume in a renumbering architecture. Every host is a server in some sense. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Sep 13, 2007, at 2:34 PM, Iljitsch van Beijnum wrote: The idea is this: An association is an end-to-end relationship between a pair of applications that potentially spans several transport lifetimes. Wouldn't that be the OSI session layer (that IP doesn't have)? Not necessarily. A 'session' in the OSI verbiage (at least as far as I can understand it ;-), spans across individual transport connections. The de-facto session layer that we have today in IP is an ssh tunnel, with applications tunneled across it and some very poor security within that tunnel. A key question here is whether the 'association' is a single connection or not. While the association may span the change of underlying infrastructure, the real question is whether it presents a single concatenated transport abstraction or if it's multiple connections. I think we need the former. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Sep 13, 2007, at 23:42 , Keith Moore wrote: Disconnect current session, reconnect. Uh, not unless your application has some sort of retry or checkpoint-restart capability. SMTP is pretty resilient in the face of connection breakage, and for some interactive applications you just hit retry or the equivalent, which has caused some people to think that somehow it's okay if the network changes a host's IP addresses out from under it. But it doesn't work in general. I think the way IPv6 handles this by deprecating the current address but keeping it alive for some time is entirely reasonable. So if you're doing a large file transfer or something like that, you can finish it, then disconnect and reconnect using the new address. Assuming that you can keep a session alive for weeks or months without the ability to recover from disconnects is not a smart idea, to say the least. This falls under the heading of nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away. No, it just means that people shouldn't assume that existing DNS names (i.e. the ones we're already using to identify hosts and services) will work as endpoint identifiers for the purpose of connection restart. Huh? What ARE DNS names good for, if not that? Obviously if people put a bunch of hosts in the DNS under a common service name, the idea is that all of the hosts provide the service in question. I also don't feel responsible for keeping the host/service distinction. If a certain protocol needs to talk to individual hosts and not services, then the people creating DNS names for use with that protocol should take that into account and not whine. People are using DNS names to name things that aren't hosts (e.g. services or groups of hosts) for valid reasons and any solution that destroyed this functionality would be a non-starter. Like I said, EVERYTHING is a non-starter today so we don't start anything anymore. The assumption that everything that works today will continue to work forever is broken. That's the least of the problems with renumbering. A few years ago I was involved in renumbering of a class B IPv4 network. DHCP and DNS doesn't even begin to cover it. You have to design to be renumberable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Jari, On Sep 13, 2007, at 1:05 PM, Jari Arkko wrote: We had an opportunity to fix that, but we blew it. I think everyone agrees that having that flexibility (ease of renumbering, no routing explosion in the core etc) would be good. So would world peace, motherhood, and apple pie. What are you willing to give up for it? But I would suggest that instead of playing the what if or I told you so games, we collectively focus on solving the problem. And I would suggest by ignoring history we are doomed to repeat it. I am not engaging in I told you so because I didn't -- you'll note I used we. I am merely pointing out that we're either at or very quickly approaching a crossroads and the choices we have are constrained by the reality of the Internet today and past decisions we, the IETF, have made. IPv6 _is_ IPv4 with more bits and it is being deployed that way. One can argue that it shouldn't be that way and that there should be a paradigm shift in the enterprises, ISPs, and grandmothers of the world, but commercial reality makes such a shift very, very hard. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. Do you believe IPv4 (or ANY other successful large scale technology), when it was designed, had all the little details worked out? As I have said elsewhere, I've come to believe that one of the fundamental failures of the IETF is that it permits or even encourages protocol design to be directed by corner cases. In this particular case, it isn't even clear to me there is agreement on what the problem we're trying to solve actually is. And we have a place for that work to happen in the IRTF. Actually, I suspect if the work were to happen in the IRTF, it would be doomed. The IRTF is, after all, focused on research. I can imagine the people in the IRTF contributing towards a solution but that isn't where a solution will come from. Given real world constraints, a solution will come from engineers (protocol, network, hardware, and/or software), singly or working together, coming up with an approach that meets real world requirements (not what researchers believe are real world requirements). It almost certainly won't be architecturally pure and it probably won't be pretty, but it will probably meet commercial and operational needs. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Sep 13, 2007, at 9:26 PM, Spencer Dawkins wrote: This RFC identified a couple of opportunities: 4. Call to Action for the IETF The more automated one can make the renumbering process, the better for everyone. Sadly, there are several mechanisms that either have not been automated or have not been automated consistently across platforms. 4.1. Dynamic Updates to DNS Across Administrative Domains 4.2. Management of the Reverse Zone Have these holes been filled in during the past couple of years? No. While some might point to existing renumbering RFCs, speaking from the perspective of my employer, Cisco doesn't think it makes operational sense. What it handles is the special case in which an administration - wants to change its /48 ISP prefix for another /48 ISP prefix, - both are exactly 48 bits long (no /56 prefixes or any other length allowed), and - in which there is no intent to change the subnet part of the prefix. In our opinion, changing between a /48 and a /56 (or a /56 and a /52, or any other combination) is a pretty reasonable thing to want to do. Further, whenever Cisco renumbers its IPv4 network (which it does with some regularity it seems), we change the allocation of subnet prefixes. we recover what we can, re-organize, and re-deploy. So we think the current solution is operationally useless. To my knowledge, we haven't heard from our customers that they want it. As such, we have no current plan to implement it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Tony Li wrote: A key question here is whether the 'association' is a single connection or not. While the association may span the change of underlying infrastructure, the real question is whether it presents a single concatenated transport abstraction or if it's multiple connections. I think we need the former. Wow, I wasn't expecting so much feedback in so few minutes. My motivations were these: Although I'd as a writer of applications like to have a reliable, sequenced data stream to my peer application(s), I figured that to do that inside TCP would be to reinvent TCP. And since I don't believe many of us think TCP is broken, reinventing TCP would not be a good use of our efforts. So I figured, OK, how can we keep our investment in TCP and existing applications and provide a tool that could be of use to people figuring out new applications. Sort of the way that BEEP is. And having long ago stuck more than an arm into ISO/OSI, and after seeing Marshall Rose's implementations of ISO session over TCP, I realized that what the OSI people were trying to do at the session layer was something simple wrapped up in an amazing amount of complexity. All they were trying to do was give applications a way of putting stakes into the ground so that they could go back to an agreed upon status if something went wrong and give it another try. To my mind it would be very wrong to require that the network in some way preserve application data for re-presentation; first off that makes the network too complicated and second, as several have pointed out, how each application recovers varies from application to application. Keith is very right that we don't want the network (including most of the stack code in clients and servers) to do what an application should do for itself, particularly with regard to buffering of data. That's why, to my mind, the association mechanism should be limited to merely letting the applications agree on a name or number, nothing more, and leaving it to the applications to figure out what to do if they need to go back to that name/number. And Keith is right in that what I am suggesting would not be a mechanism that would be transparent to existing applications. I've wrestled with the idea of pushing all of this down into the transport layer and, yes it could be done. But I have doubts that given the size of the net that it would be broadly adopted or be deployable. So I mentally punted and said How about an optional layer above TCP that newly designed applications could use? As Iljitsch points out, the checkpoint mechanism could become a lot of overhead for not a lot of benefit - although I sense that the overhead of establishing a checkpoint would involve perhaps one-to-two packet exchange/round trip times and might be able to occur in parallel with ongoing data flow (remember I'm suggesting only the establishment of a name, not any buffering of data except in the applications themselves.) And a well designed application protocol should only use a the checkpoint mechanism when it really needs to. It would be silly, for example, to checkpoint a DNS-over-TCP connection, but it might make sense for some mobile database access application to do it after each database update. But, as Iljitsch also suggests, we can get a lot of this if applications simply close the TCP connection then re-open it. But isn't that really a somewhat similar to I've suggested in that it requires the applications to go back to some point in the past and resume? I know that I'm walking close to the edge of a cauldron of worms, but I've seen these ideas of some sort of persistent relationship between application layer entities pop up in many contexts, such as mobile IP, VoIP, HTTP cookies, etc, that it occurred to me that maybe it is something that needs some coherent, rather than ad hoc, consideration. --karl-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Disconnect current session, reconnect. Uh, not unless your application has some sort of retry or checkpoint-restart capability. SMTP is pretty resilient in the face of connection breakage, and for some interactive applications you just hit retry or the equivalent, which has caused some people to think that somehow it's okay if the network changes a host's IP addresses out from under it. But it doesn't work in general. I think the way IPv6 handles this by deprecating the current address but keeping it alive for some time is entirely reasonable. So if you're doing a large file transfer or something like that, you can finish it, then disconnect and reconnect using the new address. Yeah, right. And then every application protocol has to implement its own checkpoint/restart capability on top of TCP. Actually if there were some specification for how long the minimum overlap period should be, and it were long enough (a day, perhaps, but not an hour), then the only applications that would need such capability would be those which expected to have very long session times. and that might be acceptable. but it's easy to think of apps that need to be able to maintain associations for days: file transfer, remote terminal, file access, event logging all come to mind immediately. Assuming that you can keep a session alive for weeks or months without the ability to recover from disconnects is not a smart idea, to say the least. Assuming that you can change addresses out from under applications without breaking them is even less smart. This falls under the heading of nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away. No, it just means that people shouldn't assume that existing DNS names (i.e. the ones we're already using to identify hosts and services) will work as endpoint identifiers for the purpose of connection restart. Huh? What ARE DNS names good for, if not that? Initial binding of a name to an address where _an instance of_ the host or service or application peer associated with that name can be reached. Once there is a relationship between the parties to a connection, the DNS name can no longer be relied on to reach the other party. Obviously if people put a bunch of hosts in the DNS under a common service name, the idea is that all of the hosts provide the service in question. It might be obvious but it's an oversimplification at best. I also don't feel responsible for keeping the host/service distinction. If a certain protocol needs to talk to individual hosts and not services, then the people creating DNS names for use with that protocol should take that into account and not whine. Yes, and somehow all of the applications and users that need to know about the specific purpose of each of those DNS names will magically find out. People are using DNS names to name things that aren't hosts (e.g. services or groups of hosts) for valid reasons and any solution that destroyed this functionality would be a non-starter. Like I said, EVERYTHING is a non-starter today so we don't start anything anymore. The assumption that everything that works today will continue to work forever is broken. You are taking a very narrow case that I cited and exaggerating it way out of proportion. That's the least of the problems with renumbering. A few years ago I was involved in renumbering of a class B IPv4 network. DHCP and DNS doesn't even begin to cover it. You have to design to be renumberable. It might be a good idea, but having standards protocols, APIs, and tools to do that are a lot further behind the curve than, say, IPv6. If we started in earnest now to develop those protocols, APIs, and tools, we might have such things in place 10 years from now. That doesn't mean we shouldn't do it, but it does mean that statements of the form you have to design to be renumerable are essentially saying that you have to be able to adapt every host stack, router, firewall, ALG, traffic filter, traffic monitor, and application in your network to accommodate your particular mechanism for doing that. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Thu, Sep 13, 2007 at 11:05:22PM +0300, Jari Arkko wrote: David, We had an opportunity to fix that, but we blew it. I think everyone agrees that having that flexibility (ease of renumbering, no routing explosion in the core etc) would be good. But I would suggest that instead of playing the what if or I told you so games, we collectively focus on solving the problem. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. And we have a place for that work to happen in the IRTF. There's a lot of promising work, but they don't have a final solution yet; the details do matter (and I suspect that they also mattered back at the time IPv6 was being designed). Jari the old PIER wg had some useful ideas on the scope fo the renumbering problem... if the IRTF wants to revisit the problem that might be a good place to start. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Iljitsch, On Sep 13, 2007, at 3:01 PM, Iljitsch van Beijnum wrote: Disconnect current session, reconnect. Uh, not unless your application has some sort of retry or checkpoint-restart capability. I think the way IPv6 handles this by deprecating the current address but keeping it alive for some time is entirely reasonable. There is no real difference between how IPv4 handles this and how IPv6 handles it. Applications, regardless of whether they are IPv4 or IPv6, know the address of the remote side of the conversation, it is cached in application data space. If the address changes, the application needs to be made aware of that somehow. This is usually done by a connection reset, often causing the program to terminate. Unless you're going to rewrite pretty much every Internet aware application on the planet, IP addresses (both IPv4 and IPv6) are assumed to be stable. Assuming that you can keep a session alive for weeks or months without the ability to recover from disconnects is not a smart idea, to say the least. Is it smart? Nope. However, most applications were designed with this assumption and it works today if you have PI. Like I said, EVERYTHING is a non-starter today so we don't start anything anymore. The assumption that everything that works today will continue to work forever is broken. Yep. Question is, what's critical vs. important vs. nice-to-have? (I consider long term connections to be a nice-to-have, btw) Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: renumbering, was Re: IPv6 will never fly: ARIN continues to kill it
On Thu, 13 Sep 2007, Mark Andrews wrote:
For the DNS use UPDATE to update the address records.
Since when did that work for delegation changes?
The protocol has supported it from day 1. We've shipped
clients that supported it since 2000 (all version of BIND
9 support it). This was one of the architectual issues
that was addressed in BIND 9. We went to seperate databases
for each zone rather than a single database.
You can use UPDATE to update *any* record in a zone that
includes records that are occulted by the a delegating NS
RRset.
The only things you can't do with UPDATE (yet) are:
* provision a server to server a new zone.
* decomission a zone.
If we could get the TLD's to accept UPDATE packets I'd
write the code to do this whenever the master server
was updated (NS/glue changed) / restarted. This would
be a alternative method to going through EPP.
zone example.com {
type master;
file master/example.com.db;
update-parent yes;
update-parent-key keyname;
};
Mark
--
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
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. Probably not really. That sort of equivalence statement applies when the new version is a minor upgrade to the previous, rather than require massive changes to the infrastructure AND to client applications. Having to run parallel stacks, having substantial changes to administration and operations, and having major changes to the minimum required set of capabilities is more than just a few more bits. Deering's SIP qualified as such a minor upgrade (if an upward compatible addressing scheme had been chosen.) The current IPv6 suite probably does not. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
From: Tony Hain [EMAIL PROTECTED] David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. No it is not, No less a person than the IPv6 'architect' himself stated that IPv6 and IPv4 were architecturally identical, that IPv4 got it all basically right, and that IPv6 was nothing more than IPv4 with a little cleaned up engineering. Those aren't his exact words, but I don't feel like wasting the time to go find that email from him - but if you doubt that I have accurately captured the sense of what he said, I'll be happy to look for it. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. No it is not, and you need to stop claiming that because it confuses people into limiting their thinking to the legacy IPv4 deployment model. One can argue that it shouldn't be that way and that there should be a paradigm shift in the enterprises, ISPs, and grandmothers of the world, but commercial reality makes such a shift very, very hard. Transition requires that the technology meet people where they are, which is why you note that IPv6 is being deployed like IPv4. Then once they get over the basic education hump they can think about the different capabilities to move beyond the historical limitations. There are way too many arguments (even on this list of relatively smart people) where the fundamental difference of simultaneous use of multiple addresses is the key to thinking differently between the versions. Until people get their heads out of the IPv4 darkness they will keep insisting on making IPv6 deployments look the same. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. Do you believe IPv4 (or ANY other successful large scale technology), when it was designed, had all the little details worked out? If anyone doubts this point, note that the IETF still creates more IPv4 specific RFCs than IPv6 ones. Until the IESG/IAB get serious about stopping all work on the dead-end IPv4 protocol, people will continue to argue that IPv6 is not ready for deployment. As I have said elsewhere, I've come to believe that one of the fundamental failures of the IETF is that it permits or even encourages protocol design to be directed by corner cases. In this particular case, it isn't even clear to me there is agreement on what the problem we're trying to solve actually is. There are operational practices that originate from lack-of-memory/lack-of-reliable-resolution that end up embedding IP addresses in places that make it very costly to change them later. The work was done on the endpoint side to simplify renumbering, because touching the larger number of them was clearly a problem, but it was not done in the firewall/management system area. And we have a place for that work to happen in the IRTF. Actually, I suspect if the work were to happen in the IRTF, it would be doomed. The IRTF is, after all, focused on research. I can imagine the people in the IRTF contributing towards a solution but that isn't where a solution will come from. Given real world constraints, a solution will come from engineers (protocol, network, hardware, and/or software), singly or working together, coming up with an approach that meets real world requirements (not what researchers believe are real world requirements). It almost certainly won't be architecturally pure and it probably won't be pretty, but it will probably meet commercial and operational needs. If there is research to do towards this, it will be in the arena of social engineering. Once it is clear how to stop operators from deciding the most expedient thing to do is embed the current IP address into some configuration, then engineering can build the tool to enforce that. It is very difficult to get people to realize that the accumulation of short term cost savings will turn on them as a sizable cost when changes become necessary. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Sep 14, 2007, at 2:22 AM, David Conrad wrote: And I would suggest by ignoring history we are doomed to repeat it. I am not engaging in I told you so because I didn't -- you'll note I used we. I am merely pointing out that we're either at or very quickly approaching a crossroads and the choices we have are constrained by the reality of the Internet today and past decisions we, the IETF, have made. Well, yes. But I do find myself wondering what tool one might really want to use here and how it differs from what we do in IPv4. Correct me if I am wrong (but not here - let's have that discussion on v6ops). To my way of thinking, the process described in RFC 4192 can't really be automated start to finish, and it is nonetheless pretty much the right process. Parts of it can be, such as once an operator decides he wants to add a new prefix to every router interface in his network, the database he uses to manage such things can ssh to each router and add the prefixes, and similarly when he decides to later remove the old, the database can do that. But the big problem in renumbering isn't getting the addresses assigned. It is finding and fixing all the places where that address was used in numeric form to ensure that they now have the right new value. Since human screwup behavior isn't automated, fixing human screwups is difficult to automate. So we can have tools that help with the major steps, but a lot of the verification process can only be done by observation. Recriminations and rants aren't going to make that much different. What would be Really Nice would be to in some way ensure that applications never saw IP addresses at all - they *only* worked on names, and maintained no knowledge in the application of what address was used. To my small mind, forcing a new DNS lookup in the event of a TCP session failure and restart would be a good thing. The authors of RFC 4778 would take exception - they want to be able to log into the right place when everything is in flames. Apart from that, though, managing addresses through names would go a *long* way toward making renumbering easier. We already have many of those capabilities, though. We have to as an industry consistently use them that way. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Tony Hain wrote: Until people get their heads out of the IPv4 darkness they will keep insisting on making IPv6 deployments look the same. Perhaps, but there's such a thing as IPv6 darkness also. For instance, the assumption that existing applications can survive changes in the IP addresses of the hosts on which they reside without significant changes to those applications. Or the assumption that it's reasonable for applications to have to deal with multiple source and destination IP addresses without access to routing or topology information. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Noel Chiappa wrote: From: Tony Hain [EMAIL PROTECTED] David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. No it is not, No less a person than the IPv6 'architect' himself stated that IPv6 and IPv4 were architecturally identical, that IPv4 got it all basically right, and that IPv6 was nothing more than IPv4 with a little cleaned up engineering. I'm sure it started out that way. It didn't end up that way. A few changes here and there had rather significant (perhaps unintended) effects. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Fred Baker wrote: What would be Really Nice would be to in some way ensure that applications never saw IP addresses at all - they *only* worked on names, and maintained no knowledge in the application of what address was used. To my small mind, forcing a new DNS lookup in the event of a TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) The authors of RFC 4778 would take exception - they want to be able to log into the right place when everything is in flames. Apart from that, though, managing addresses through names would go a *long* way toward making renumbering easier. We already have many of those capabilities, though. We have to as an industry consistently use them that way. and yet, it's quite clear that DNS as it currently exists is not adequate for this. not the query protocol, nor the data caching model, nor the APIs, nor the security (at least as deployed), nor the names that we're currently using, and probably not even the replication mechanism. which might be why the industry hasn't started consistently using DNS for this. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Sep 14, 2007, at 6:03 AM, Keith Moore wrote: perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. well, this presumes that the application wants to get to the same instance of the peer, as opposed to getting to an instance of the peer. If the reason the session was lost was that the peer has gone out of service or is unreachable, insisting on the same instance of the peer has its down sides. So there is probably some solution, as you suggest, such as having the application accept a peer-specific name for the purpose - if it has to retry, it can try the instance-specific name first, and if that fails, try the more general name. Note that when I say name, I am not limiting myself to a DNS name. I'm quite happy to see some other form of name if the apps folks want to design one, for all the reasons you cite. IMHO, some form of true directory, with unicode directly supported, would be a wonderful thing. I'm not the first to suggest that, as you know well. I'm waiting for those who understand those issues better than I do to make the proposal. Haven't seen it yet. Have you ever used the term layer violation, or heard it used by someone else? Having the application know the network layer address is just slightly worse than having it know what it's Ethernet address is or what port it is attached to. There are a few cases in which it has a real need to know. In all except those few, believe me, every whine I hear about renumbering is in my ears a whine about the layer violation. Make it go away, and the renumbering problem will be *much* easier to solve. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Fred Baker wrote: What would be Really Nice would be to in some way ensure that applications never saw IP addresses at all - they *only* worked on names, and maintained no knowledge in the application of what address was used. To my small mind, forcing a new DNS lookup in the event of a TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. We already have the DNS hooks to distingish services from hosts. We had them for the last 8 years. Some services actually use these hooks. in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. The authors of RFC 4778 would take exception - they want to be able to log into the right place when everything is in flames. Apart from that, though, managing addresses through names would go a *long* way toward making renumbering easier. We already have many of those capabilities, though. We have to as an industry consistently use them that way. and yet, it's quite clear that DNS as it currently exists is not adequate for this. not the query protocol, nor the data caching model, nor the APIs, nor the security (at least as deployed), nor the names that we're currently using, and probably not even the replication mechanism. which might be why the industry hasn't started consistently using DNS for this. Keith ___ 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
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
To my small mind, forcing a new DNS lookup in the event of a TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. We already have the DNS hooks to distingish services from hosts. We had them for the last 8 years. Yes but SRV records weren't really meant to handle this case either. And they actually can make applications less reliable because they introduce a new dependency on DNS (another lookup that can fail, in a different zone and potentially on a different server, another piece of configuration data that can be incorrect.) What we'd really need is a RR type specifically intended to map service names onto instance ID+address pairs, and also a special query type that wasn't defined to return all of the matching RR records, but would instead return a random subset or a subset based on heuristics, and finally an instance ID to address mapping service. But arguably DNS isn't the right place to do that at all - there should instead be a generic referral service at layer 3 or 4. Of course, part of the reason that people started using A records to refer to multiple hosts was that a number of applications just worked when they did that. And I remember when people used to object loudly to such things, and insist that a DNS name and a host name had to be the same thing. Anyway, this kind of overloading of A records has been such a widespread practice for so long that I don't see it changing. And it's not as if we came up with a better way of doing things for IPv6 addresses. in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Mumble. Seems like the whole point of TCP was to recover from such failures at a lower level. And I remember how people used to say that TCP was better than X.25 VCs (in part) because TCP would recover from temporary network outages that would cause hangups in X.25. I also don't have a lot of faith in should be, not when I've seen DHCP servers routinely refuse to renew leases after very short times, nor when I've heard people say that a site should be able to renumber every day. I used to try to get people to specify a minimum amount of time that a non-deprecated address should be expected to be valid - say a day. Then application writers and application protocol designers would have an idea about whether they needed a strategy for recovery from a renumbering event, and what kind of strategy they needed. But the only people who seemed to like this idea were application area people. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. in other words, one design error can be used to justify another? sort of like the blind leading the blind? I see a significant difference between a design flaw in a particular application that cripples that application, and a design flaw in a lower layer that cripples all applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Renumbering
I remember Bill Clinton describing trying to develop an Internet standard like 'nailing jello to the wall'. From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Thu 13/09/2007 5:24 PM To: Keith Moore Cc: Tony Finch; IETF-Discussion Subject: Re: Renumbering On Sep 13, 2007, at 20:52 , Keith Moore wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Disconnect current session, reconnect. Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Since when is it the job of applications to manage DNS TTLs? Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch to expect apps to do so. Right. And for that matter, a DNS name is not a host name, and hasn't reliably been a host name since at least the mid 1980s. Just because you get address A1 from doing a lookup on a name at time T1 and an address A1 from doing the same lookup at time T2, doesn't mean that those addresses will connect to the same (layer 3 or higher) stack. So even if we somehow magically changed our existing transport protocols to be able to support changes to endpoint addresses on the fly, DNS names as they are currently used are not suitable as endpoint identifiers for such a purpose. At best, existing DNS names serve as identifiers for the initial contact only. This falls under the heading of nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away. Giving in to this logic means that it's impossible to change ANYTHING. As the saying goes, in an infinite universe, everything that's possible, does indeed exist. The internet is pretty much an infinite universe these days. As for renumbering, on a Cisco router, I can make the following configuration: ! interface Ethernet1 ipv6 address autoconfig ipv6 dhcp client pd dhcpv6prefix ! interface Ethernet2 ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64 ! This way, the router obtains an IPv6 prefix dynamically from a DHCPv6 prefix delegation server and then sends out router advertisements using that prefix. So you can renumber the router and all the hosts connected through it by changing one entry in a DHCPv6 server config. However, I don't think this method applies everywhere (such as in filters) but obviously that's something that would be possible if desired. Even with the current state of the art I'd say that renumbering clients is not a big deal. Renumbering servers is more difficult, though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Have you ever used the term layer violation, or heard it used by someone else? Occasionally :) Having the application know the network layer address is just slightly worse than having it know what it's Ethernet address is or what port it is attached to. The flip side to this is that an immense amount of additional complexity is required to truly make applications agnostic of lower layers. Classic TCP/IPv4 was a lot simpler and more deployable than it would have been with a genuine ID/LOC split. By making the assumption that an address was good enough as an endpoint identifier, made implementation on modest 1980s era hardware, not to mention slow networks, a lot more practical. And in the days before laptops and before the net got big enough to make prefix aggregation necessary, this was a reasonable assumption. It seems that a lot of successful protocols were originally optimized for deployability rather than optimized for longevity. I suspect that those protocols tend to be more successful, even in the long term, than those that are initially optimized for longevity over deployability :) IPv4 is one example, DNS is another, HTTP is a third, I suspect BGP is a fourth, and I'm sure there are many more. There are a few cases in which it has a real need to know. In all except those few, believe me, every whine I hear about renumbering is in my ears a whine about the layer violation. Make it go away, and the renumbering problem will be *much* easier to solve. Well, every time I hear a whine in IETF about how people should or should not do things a certain way, I ask myself whether this is really a reflection of the network architecture's failure to solve some important problem. After all, if there were a better way to solve the problem within the bounds of the architecture, people would probably find it sooner or later. Various practices that some of us might label as dubious, including NATs, using IP addresses as authentication tokens, using a single DNS name as a way to name a service that's actually implemented by a large pool of hosts, or layer violations in general, are all attributed to failures of the architecture or failures to implement key features in our core protocols in a timely fashion. So the reason people are writing applications that look at IP addresses is because the network doesn't give them the tools that they need to write good apps without looking at IP addresses. (And they need to do that even more in a NATted environment, or in an environment where hosts have multiple source and/or destination addresses with different characteristics, so it's not like the architecture is moving in a direction to discourage layer violations). It's a bit unrealistic to expect those applications to change in order to solve the renumbering problem, without providing those tools. The incentives all favor solving your own problem (or making your own customers happy) even at the risk of creating a problem for someone else, not to solve someone else's problem even though it makes your own product less functional, efficient, or reliable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
To my small mind, forcing a new DNS lookup in the event of a TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. We already have the DNS hooks to distingish services from hosts. We had them for the last 8 years. Yes but SRV records weren't really meant to handle this case either. And they actually can make applications less reliable because they introduce a new dependency on DNS (another lookup that can fail, in a different zone and potentially on a different server, another piece of configuration data that can be incorrect.) What we'd really need is a RR type specifically intended to map service names onto instance ID+address pairs, and also a special query type that wasn't defined to return all of the matching RR records, but would instead return a random subset or a subset based on heuristics, and finally an instance ID to address mapping service. But arguably DNS isn't the right place to do that at all - there should instead be a generic referral service at layer 3 or 4. Of course, part of the reason that people started using A records to refer to multiple hosts was that a number of applications just worked when they did that. And I remember when people used to object loudly to such things, and insist that a DNS name and a host name had to be the same thing. Anyway, this kind of overloading of A records has been such a widespread practice for so long that I don't see it changing. And it's not as if we came up with a better way of doing things for IPv6 addresses. in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Mumble. Seems like the whole point of TCP was to recover from such failures at a lower level. And I remember how people used to say that TCP was better than X.25 VCs (in part) because TCP would recover from temporary network outages that would cause hangups in X.25. I also don't have a lot of faith in should be, not when I've seen DHCP servers routinely refuse to renew leases after very short times, nor when I've heard people say that a site should be able to renumber every day. So, someone misconfigured something. Such misconfigurations usually get fixed fast. Getting the automation to the state where a daily renumber is possible is an achievable goal. If we were doing that the long running apps would have been fixed long ago. The fact that they aren't is more a matter of pressure than anything else. That's why I started with a large period when I was suggesting that router and firewall vendors actually renumber themselves periodically. It was to keep the problem in the management space rather than the application space. Have each vendor work on their part of the problem is the way to go. I used to try to get people to specify a minimum amount of time that a non-deprecated address should be expected to be valid - say a day. Then application writers and application protocol designers would have an idea about whether they needed a strategy for recovery from a renumbering event, and what kind of strategy they needed. But the only people who seemed to like this idea were application area people. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. in other words, one design error can be used to justify another? sort of like the blind leading the blind? No. People should work on making
Weekly posting summary for ietf@ietf.org
Total of 224 messages in the last 7 days. script run at: Fri Sep 14 00:53:02 EDT 2007 Messages | Bytes| Who +--++--+ 11.16% | 25 | 10.91% | 141457 | [EMAIL PROTECTED] 7.14% | 16 | 6.28% |81416 | [EMAIL PROTECTED] 3.57% |8 | 5.81% |75284 | [EMAIL PROTECTED] 4.02% |9 | 3.71% |48151 | [EMAIL PROTECTED] 4.02% |9 | 3.57% |46312 | [EMAIL PROTECTED] 3.57% |8 | 3.32% |42999 | [EMAIL PROTECTED] 3.57% |8 | 3.09% |40072 | [EMAIL PROTECTED] 3.12% |7 | 2.10% |27229 | [EMAIL PROTECTED] 2.68% |6 | 2.54% |32979 | [EMAIL PROTECTED] 2.68% |6 | 2.45% |31761 | [EMAIL PROTECTED] 1.34% |3 | 3.60% |46700 | [EMAIL PROTECTED] 2.23% |5 | 2.47% |31993 | [EMAIL PROTECTED] 2.23% |5 | 2.36% |30593 | [EMAIL PROTECTED] 2.23% |5 | 2.35% |30491 | [EMAIL PROTECTED] 2.23% |5 | 2.12% |27523 | [EMAIL PROTECTED] 2.23% |5 | 1.98% |25696 | [EMAIL PROTECTED] 2.23% |5 | 1.63% |21155 | [EMAIL PROTECTED] 2.23% |5 | 1.52% |19764 | [EMAIL PROTECTED] 1.79% |4 | 1.81% |23428 | [EMAIL PROTECTED] 1.79% |4 | 1.81% |23412 | [EMAIL PROTECTED] 1.34% |3 | 1.63% |21080 | [EMAIL PROTECTED] 1.34% |3 | 1.01% |13081 | [EMAIL PROTECTED] 0.89% |2 | 1.39% |18019 | [EMAIL PROTECTED] 0.89% |2 | 1.19% |15430 | [EMAIL PROTECTED] 0.89% |2 | 1.12% |14581 | [EMAIL PROTECTED] 0.89% |2 | 1.09% |14082 | [EMAIL PROTECTED] 0.89% |2 | 1.06% |13805 | [EMAIL PROTECTED] 0.89% |2 | 0.93% |12033 | [EMAIL PROTECTED] 0.89% |2 | 0.87% |11252 | [EMAIL PROTECTED] 0.89% |2 | 0.86% |1 | [EMAIL PROTECTED] 0.89% |2 | 0.85% |11059 | [EMAIL PROTECTED] 0.89% |2 | 0.83% |10762 | [EMAIL PROTECTED] 0.89% |2 | 0.80% |10400 | [EMAIL PROTECTED] 0.89% |2 | 0.80% |10378 | [EMAIL PROTECTED] 0.89% |2 | 0.73% | 9517 | [EMAIL PROTECTED] 0.89% |2 | 0.69% | 8901 | [EMAIL PROTECTED] 0.89% |2 | 0.64% | 8284 | [EMAIL PROTECTED] 0.45% |1 | 0.88% |11471 | [EMAIL PROTECTED] 0.45% |1 | 0.82% |10607 | [EMAIL PROTECTED] 0.45% |1 | 0.77% |10013 | [EMAIL PROTECTED] 0.45% |1 | 0.67% | 8676 | [EMAIL PROTECTED] 0.45% |1 | 0.66% | 8607 | [EMAIL PROTECTED] 0.45% |1 | 0.66% | 8568 | [EMAIL PROTECTED] 0.45% |1 | 0.58% | 7547 | [EMAIL PROTECTED] 0.45% |1 | 0.58% | 7461 | [EMAIL PROTECTED] 0.45% |1 | 0.57% | 7449 | [EMAIL PROTECTED] 0.45% |1 | 0.55% | 7164 | [EMAIL PROTECTED] 0.45% |1 | 0.53% | 6811 | [EMAIL PROTECTED] 0.45% |1 | 0.47% | 6141 | [EMAIL PROTECTED] 0.45% |1 | 0.45% | 5846 | [EMAIL PROTECTED] 0.45% |1 | 0.44% | 5677 | [EMAIL PROTECTED] 0.45% |1 | 0.42% | 5491 | [EMAIL PROTECTED] 0.45% |1 | 0.42% | 5402 | [EMAIL PROTECTED] 0.45% |1 | 0.41% | 5322 | [EMAIL PROTECTED] 0.45% |1 | 0.40% | 5220 | [EMAIL PROTECTED] 0.45% |1 | 0.40% | 5193 | [EMAIL PROTECTED] 0.45% |1 | 0.40% | 5123 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5120 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5119 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5109 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5101 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5080 | [EMAIL PROTECTED] 0.45% |1 | 0.39% | 5003 | [EMAIL PROTECTED] 0.45% |1 | 0.37% | 4803 | [EMAIL PROTECTED] 0.45% |1 | 0.37% | 4748 | [EMAIL PROTECTED] 0.45% |1 | 0.36% | 4633 | [EMAIL PROTECTED] 0.45% |1 | 0.36% | 4613 | [EMAIL PROTECTED] 0.45% |1 | 0.36% | 4608 | [EMAIL PROTECTED] 0.45% |1 | 0.35% | 4479 | [EMAIL PROTECTED] 0.45% |1 | 0.34% | 4352 | [EMAIL PROTECTED] 0.45% |1 | 0.34% | 4347 | [EMAIL PROTECTED] 0.45% |1 | 0.32% | 4131 | [EMAIL PROTECTED] 0.45% |1 | 0.31% | 4011 | [EMAIL PROTECTED] 0.45% |1 | 0.31% | 3967 | [EMAIL PROTECTED] 0.45% |1 | 0.30% | 3886 | [EMAIL PROTECTED] 0.45% |1 | 0.29% | 3739 | [EMAIL PROTECTED] 0.45% |1 | 0.28% | 3624 | [EMAIL PROTECTED] +--++--+ 100.00% | 224 |100.00% | 1296452 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
I also don't have a lot of faith in should be, not when I've seen DHCP servers routinely refuse to renew leases after very short times, nor when I've heard people say that a site should be able to renumber every day. So, someone misconfigured something. Such misconfigurations usually get fixed fast. In all of the cases where I've seen the DHCP thing happen, it was deliberate. And no, stupid network admins do not get fixed quickly. At least, not as a general rule. The Peter Principle applies here as to that profession as any other. address leasing is one of the fundamental design flaws of DHCP. Of course, that's also water under the bridge. Getting the automation to the state where a daily renumber is possible is an achievable goal. If we were doing that the long running apps would have been fixed long ago. And if we could make the sun run backwards then we wouldn't need streetlights. Never mind those people on the other side of the world... You want to make applications be slower, less reliable, and more complex in order to make routing easier. It's understandable that you might feel that way, but don't expect everyone else to go along with it. Now if you find a way to solve the problems you are concerned about, while also providing a truly viable solution for others, Then we might make some progress. But mere handwaving won't cut it. You have to make a convincing case that your solution is comprehensive. The fact that they aren't is more a matter of pressure than anything else. That's why I started with a large period when I was suggesting that router and firewall vendors actually renumber themselves periodically. It was to keep the problem in the management space rather than the application space. Yes, but firewall and router boxes are relatively easy to renumber, because there are a smaller number of vendors and a smaller number of interfaces. Apps are much harder because they are so diverse. Have each vendor work on their part of the problem is the way to go. Lots of apps vendors out there would have to come to some sort of agreement. Any purported solution had better be very versatile. Of course, a lot of the problem is a security problem. Find a decent (efficient, mostly reliable, easy to configure, and works across administrative domain boundaries) way for hosts and nets to quickly distinguish trustworthy traffic from untrustworthy traffic without using IP addresses and you'd probably decrease application configuration of addresses by an order of magnitude, maybe two. (and also note that any renumbering scheme can't been seen as weakening the relationship between IP address and trustworthiness - that relationship is already too weak as it is, but people will cling to it until there's something better) I used to try to get people to specify a minimum amount of time that a non-deprecated address should be expected to be valid - say a day. Then application writers and application protocol designers would have an idea about whether they needed a strategy for recovery from a renumbering event, and what kind of strategy they needed. But the only people who seemed to like this idea were application area people. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. in other words, one design error can be used to justify another? sort of like the blind leading the blind? No. People should work on making renumbering work efficiently. I don't disagree that it's worthy of further investigation. I just don't think that it's likely to succeed anytime soon, which is to say, within a decade or maybe two. Automated renumbering is not going to alleviate the need for PI space or for the routing system to be able to somehow handle large numbers of PI prefixes. Something else might, but not automated renumbering. At least, that's what my intuition says. That doesn't mean don't try, it means don't depend on that being the solution. I see a significant difference between a design flaw in a particular application that cripples that application, and a design flaw in a lower layer that cripples all applications. Reconnect is a reasonable strategy for most applications. Sounds very naive to my ears. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Thu, Sep 13, 2007 at 07:43:38PM +0100, Tony Finch wrote: On Thu, 13 Sep 2007, David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Tony. I know of one application that relied on long-lived DNS hostname to IP mappings and ignored DNS TTLs. Search engine crawlers cached the IP addresses for pages that had been fetched, and used those addresses even though the TTLs had expired. This resulted in pages from whatever content lived at those new IP addresses showing up unexpectedly (incorrectly) in search engine results. I don't know if this has been fixed, but it's an example of application usage that bypassed IETF recommendations for a presumably good cause (performance reasons). Another application with a similar reliance that is seeing some growth is the use of IP addresses for geotargeting. The geotargeting provider attempts to determine the physical location of the IP address for various purposes, such as to choose what ads to display. I imagine people on this list can see the flaws of doing this, but nevertheless it persists. I don't know how the geotargeting providers plan to handle IPv6, but it's another example of how people develop applications in ways that the IETF may not anticipate (because they discourage such applications), but make migration to IPv6 difficult because of the installed base that depends upon specific uses of IPv4 addresses. --gregbo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-mealling-epc-urn (A Uniform Resource Name Namespace For The EPCglobal Electronic Product Code (EPC) and Related Standards) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'A Uniform Resource Name Namespace For The EPCglobal Electronic Product Code (EPC) and Related Standards ' draft-mealling-epc-urn-02.txt as an Informational RFC 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 2007-10-11. 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-mealling-epc-urn-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13012rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
