Re: IPv6, interNAT, Wi-Fi (not mobile)
Tastes much like a MANET network to me. --On tirsdag, mars 25, 2003 18:03:51 -0500 John Stracke [EMAIL PROTECTED] wrote: S Woodside wrote: In addition I recently had to cope with the hassles of setting up an H.323 connection (with ohphoneX) from behind a firewall at both ends and immediately concluded that people on any kind of wireless mesh that uses NAT are going to be severely limited since they aren't truly a part of the internet. Right. The problem is that what I've seen in the past is that wireless-mesh proponents want to be able to do massive multihoming, with all participants with external links sharing those links, and all the traffic from the outside finding the shortest way in. I won't say it's impossible, but last I heard nobody knew how to do it; the route flap would be horrible.
Re: slide fonts
--On tirsdag, mars 25, 2003 21:35:11 -0500 Donald Eastlake 3rd [EMAIL PROTECTED] wrote: That's because the price was suddenly jacked up to a totally absurd figure. Cost recovery basis. FIRST the number of participants ordering them fell. THEN the price went up. Repeat until the current situation - 8 people sharing 2000 dollars of printer's bills. The secretariat has proposed making the CD contain printer ready proceedings - one or more PDF files that will create printed proceedings at the touch of a button. Made sense to me. Harald
Re: WG Action: Differentiated Services (diffserv) to conclude
good question. I suspect that the person writing the template 10 or more years ago didn't check for matching tenses. --On onsdag, mars 12, 2003 08:57:27 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003, The IESG wrote: The Differentiated Services (diffserv) Working Group in the Transport Area of the IETF has concluded. Out of curiousity, is there a particular reason why the subject line says to conclude but the body of the messages has concluded. This is not specific to diffserv, I believe, of course. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Daniel Senie wrote: SNIP No. It does not imply NAT. It implies traffic to hosts which are used for purposes which do not communicate to the public network. Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. Today such hosts are numbered in RFC 1918 space WITHOUT NAT and are connected to corporate networks. It's likely, given the line of argument you're proposing, that many corporations will just laugh at the IETF, and continue to use IPv4 for their private network space. What you are implying here is that using some $random unroutable address space makes these private hosts secure. Why don't you just use firewalls and configure your routers at the correct places? BTW if a network does IPv6 it will most likely also be doing RA's, how are you going to configure those 1 printers to not be using this RA? Taking into account that DHCPv6 is not completely crystal clear yet. If DHCPv6 where there you would be configuring all your hosts that need to use those printers with site local and global IP addresses. How and foremost *why* should an application differentiate between those addresses? I think at least I won't like the answer... Greets, Jeroen
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Could we PLEASE leave NAT out of the equation? Not all hosts in the world want or need to be connected outside of the corporate network they belong to. true. but they still need unique addresses.
RE: Fw: Welcome to the InterNAT...
Eliot, The only relationship SL has to renumbering is the ability to have connections persist while a network is intermittently attached to the public network. Renumbering is already solved in terms of the simplicity of moving hosts from one address space to another. The complex issues to work on are the places like firewall router configurations that have explicit addresses in them. What is not fixable is the fact that apps will break if you change an address out from under them. This is a fact the app developers complaining about the complexity of scoped addresses continually overlook. The assertion is that all a network needs to do is change the addresses in use when connecting. Never mind that every local use app will break on every one of those events. That is not an acceptable approach. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eliot Lear Sent: Wednesday, March 26, 2003 12:59 PM To: [EMAIL PROTECTED] Cc: 'The IETF' Subject: Re: Fw: Welcome to the InterNAT... Tony Hain wrote: Trying to use SL for routing between sites is what is broken. But that's not all... The space identified in RFC 1918 was set aside because people were taking whatever addresses they could find in documentation. Not as I recall. Jon Postel received several requests for extraordinarily large chunks of address space, particularly from Europe. I believe Daniel Karrenberg might have more information. This forced his hand. In addition, people such as Paul Vixie were trying to do the best they could to make random address space sork, which is admittedly a trick in a small name space. Recall at the time that CIDR was a new thing. You couldn't simply use a portion of network 10, for instance. The same cannot be said for IPv6. SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. Any address space can be unrouted address space. Fix the underlying problem, Tony. Making renumbering easy. If we don't do that, IPv6 is no better than Ipv4 (with the possible exception of MIPv6). It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL. Fix the renumbering problem and this isn't an issue. Eliot
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Its not that 'we don't want to change because its to much work'. Its that the Internet architecture assured us that the hour glass model applied, that the network topology would remain abstracted within what to us is an opaque address space. One of the number one reasons its so easy for new application layer technologies to be deployed is that a developer doesn't need to know or care about any layer below TCP (or, in rare cases, UDP). If the lower layers want to change that hour glass model then we're talking about a serious breach of contract with the layers above it and a dangerous blow to the hour glass model. This is a good sounding story, except that it's never really been true. You could choose to ignore the topology of the network, and ignorance works much of the time. Way back in the dark ages, it was not uncommon to have multi-homed HOSTS: one leg on the ARPANET, the other arm on some local LAN segment. The application and/or network stack on that machine was left with a decision to choose which interface address it ought to use when binding some local association endpoint address. It's easy when the other end is on the same network; e.g., directly attached. The Internet architecture never gave the end system some mechanism to help it make this binding decision when trying to communicate with non-local peers. There are hacks in implementations; like the local resolver having some sorting policy for the A records returned when doing a DNS query, with the assumption that the application was going to try them in turn. But that was just a hack. There was no protocol to ask the network which of address should I use to talk to this remote end system? So here we are today, a couple of decades later, with the promise of a different type of end-system multi-homing (having multiple addresses on a single) interface due to IPv6 multi-provider multihoming with provider specific addresses, and still no means to decide which of the alternatives are preferable when deciding to launch some traffic into the network. Adding one more site-local address doesn't make this problem any harder to solve, I think. louie
...they didn't hide the fact that they were representing their employers... ?
http://www.ietf.org/mail-archive/working-groups/ipr-wg/current/msg01004.html From: [EMAIL PROTECTED] (Bruce Perens) I just spent two years at W3C solving this very problem. At the table were many of the same folks on this WG, except there they didn't hide the fact that they were representing their employers. You may be missing two key points... 1. Many of the I* society participants are funded directly or indirectly by the U.S. Government. 2. It is against the U.S. Federal laws for federally funded people to work on telecommunication protocols. That forces people to lie. Once they learn to lie, it becomes a big game. They then move that game to their non-profit, corporate boards, where they are Directors but tell people that they stand in the hallway at meetings, and therefore are not involved. In summary, they (the I* society liars) have spent years gaming every U.S. funded system. You are their prey. Jim Fleming http://www.IPv8.info
Re: IPv6, interNAT, Wi-Fi (not mobile)
Fred Baker wrote: Using it as ad hoc, I think you want to not relay route flaps to your providers. Rather, you want to advertise your prefix (however obtained) to them en mass, and handle the routing issues internally. This may mean providing wired connectivity between your various points of attachment to your providers, to mask the internal motion. Or, failing that, some more firmly nailed-up wireless connectivity. If you can get line-of-sight between your attachment points, then two high-gain antennas and two UPSes would be cheaper than most wired connections, and probably almost as reliable. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Yes, there was mention of site local as a license to NAT, but there where many other arguments: leakage through IP, DNS or application; the lack of practicality of several restrictive models for site locals; the possibility or not to use other solutions for isolated sites; and the complexity of handling scoped addresses in applications. At the end, the tally shows 20 hands rising in support of site locals, 102 hands rising for their elimination. In short, it was not a hasty discussion, there was an informed debate, opinions evolved during the discussion, and a consensus was reached. This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. How many of your 22 speakers had implementation and deployment experience to report?
U.S. DOD to Select the French GSM over CDMA ?
http://www.interesting-people.org/archives/interesting-people/200303/msg00387.html
We have learned that planners at the Department of Defense and USAID are
currently envisioning using federal appropriations to deploy a
European-based wireless technology known as GSM ('Groupe Speciale Mobile' --
this standard was developed by the French) for this new Iraqi cellphone
system, Mr. Issa wrote to Defense Secretary Donald Rumsfeld.
=
Jim Fleming
http://www.IPv8.info
...handwaving arguments that something bad might happen... ?
- Original Message - From: Matt Crawford [EMAIL PROTECTED] This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen Imagine how much hand-waving 418 clueless people can do... http://register.icann.org/cgi/attendees.cgi ...fortunately, 99.9% of the rest of the world can route around them via the InterNAT... Jim Fleming http://www.IPv8.info Note: .GOV employees can make **purchasing decisions** about telecommunication protocols, they just can not spec them and develop them and therefore warp the free markets in the United States of America.
Re: ...they didn't hide the fact that they were representing their employers... ?
- Original Message - From: [EMAIL PROTECTED] To: Jim Fleming [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, March 27, 2003 9:33 AM Subject: Re: ...they didn't hide the fact that they were representing their employers... ? Okay, Jim. I'll bite. ... Can you please identify the specific laws that lead you to this assertion? It is quite a surprize to me who has spent a couple of decades as a private sector representative attempting to collaborate with very visible US Governement employees in the specification telecommunications protocols. On 27 Mar 2003, at 8:58, Jim Fleming wrote: 2. It is against the U.S. Federal laws for federally funded people to work on telecommunication protocols. Greg Ratta, Vice-Chairman, T1S1: Services, Architectures and Signaling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, [EMAIL PROTECTED] === Are you a U.S. Citizen ? ...keep in mind that U.S. Citizens are restricted by Federal Law from certain conversations... http://www.google.com/search?hl=enie=UTF-8oe=UTF-8q=Foreign+Espionage+Act 18 USC 90 - Economic Espionage Act of 1996 ... PROTECTION OF TRADE SECRETS Cite as the Economic Espionage Act of 1996 ... Economic espionage. ... knowing that the offense will benefit any foreign government, foreign ... www.tscm.com/USC18_90.html NCIX - Economic Espionage Act of 1996 This Act may be cited as the Economic Espionage Act of 1996.. ... Economic Espionage. ... or knowing that the offense will benefit any foreign government, foreign ... www.ncix.gov/pubs/online/eea_96.htm First Foreign Economic Espionage Indictment; Defendants Steal ... ... also charges a violation of The Economic Espionage Act against Okamoto ... with transporting, transmitting and transferring in interstate and foreign commerce, DNA ... www.cybercrime.gov/Okamoto_SerizawaIndict.htm Economic Espionage Act of 1996 -- Protection of Trade Secrets -- ... ... This Act may be cited as the Economic Espionage Act of 1996.. ... Economic Espionage. ... or knowing that the offense will benefit any foreign government, foreign ... www.aurorawdc.com/espact96.htm [ncdnhc-discuss] Fw: [Diffserv] diffserv PIB: a question to the ... ... December 13, 2001 9:00 AM Subject: Re: [Diffserv] diffserv PIB: a question to the WG http://www.google.com/search?q=foreign+espionage+act THE ECONOMIC ... www.icann-ncc.org/pipermail/discuss/ 2001-December/001018.html Espionage Law ... copied from Annual Report to Congress on Foreign Economic Collection and Industrial Espionage, June 1997, and brochure The Economic Espionage Act of 1996: A ... rf-web.tamu.edu/security/SECGUIDE/T1threat/Legal.htm THE ECONOMIC ESPIONAGE ACT OF 1996: THE THEFT OF TRADE SECRETS IS ... ... goods, wares or merchandise were transported in interstate or foreign commerce and ... of the primary reasons for enacting the Economic Espionage Act of 1996 ... my.execpc.com/~mhallign/crime.html
RE: ...they didn't hide the fact that they were representing their employers... ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Fleming Sent: Thursday, March 27, 2003 9:59 AM To: 'The IETF' Subject: ...they didn't hide the fact that they were representing their employers... ? Jim, Why is it against federal law for federally funded people to work on telecom protocols? This is news to me and I have been fairly active in various protocol forums for many years. When I represented govt. interests, this federal affiliation has never been kept secret and I have spoken about it many times. What law are you referring to? As I remember it, when the IETF was started, most of the people were federally financed including the the IAB chair, Phil Gross. In view of the fact that the DOD financed the Internet at a time when it was not economically competitive (early 80's) and has been a leading early adopter whose business financed a lot of development, meeting the DOD peculiar requirements was not that unreasonable. You may be missing two key points... 1. Many of the I* society participants are funded directly or indirectly by the U.S. Government. 2. It is against the U.S. Federal laws for federally funded people to work on telecommunication protocols. That forces people to lie. Once they learn to lie, it becomes a big game. They then move that game to their non-profit, corporate boards, where they are Directors but tell people that they stand in the hallway at meetings, and therefore are not involved. In summary, they (the I* society liars) have spent years gaming every U.S. funded system. You are their prey. I have no idea what this is referring to. When I represented the DOD, they would have been quite dissatisfied if I has not been active in the meetings. Steve Silverman Jim Fleming http://www.IPv8.info
Re: Financial state of the IETF - to be presented Wednesday
Mark Allman wrote: Self-funded is problematic, though: how do you tell the difference between someone who really is paying his own way and someone who's going to expense it? And what about a consultant with his own small business; if he owns the business outright, and the business pays the way, is that self-funded or not? Maybe a bit -- but, if you're self funded then you have no affiliation on your badge. So I could pass for self-funded by not telling putting down a company name on my registration? I think other organizations make this kind of distinction work by giving more rights to people who pay more; that would be the opposite of what we want to do here. I was specifically thinking of SIGCOMM's student travel grant program -- in which the above is not the case. But student is a well-defined class, with a moderately good means to check. Self-funded is neither. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: IPv6, interNAT, Wi-Fi (not mobile)
Harald Tveit Alvestrand wrote: Tastes much like a MANET network to me. Well, yes. Internally, that's fine; and a MANET community wireless network is a great idea. It's just that, externally, you don't want that ad hoc network exposing its internal structure, or its routing updates will be horrific. A solution to that would probably be a solution to the general problem of route flap. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |God does not play games with His loyal servants. Whoo-ee,| |where have you *been*? --_Good Omens_ | \/
Re: Last Call: Fast Reroute Extensions to RSVP-TE for LSP Tunnels to Proposed Standard
Shahram, I'll follow up with the WG chairs on the issues you brought up here, and will inform you and the list about the results. Thank you for reviewing the document. -- Alex Tuesday, March 25, 2003, 2:45:35 PM, Shahram Davari wrote: Since today is the last day of commenting, I just wanted to ask what is the resolution to the comments raised. Thanks, Shahram Davari PMC-Sierra The IESG has received a request from the Multiprotocol Label Switching Working Group to consider Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-3-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fa streroute-02.txt
RE: Fw: Welcome to the InterNAT...
Pekka Savola wrote: Who said the addresses are *completely* revokated when the network connectivity is intermittent? More likely than not, those address advertisements have a lifetime longer than the duration of the downtime (both preferred and valid in RFC2461 terms!) -- and whoops, everything works like a charm still! You continue to ignore the fact that when the connection to the public network reestablishes with a different prefix, all existing internal connections will be dropped. The fact that multiparty apps can't blindly pass around addresses is not a valid justification for removing a technology which prevents disrupting internal use applications. Tony
Re: Financial state of the IETF - to be presented Wednesday
On Thu, 27 Mar 2003, John Stracke wrote: Self-funded is problematic, though: how do you tell the difference between someone who really is paying his own way and someone who's going to expense it? And what about a consultant with his own small business; if he owns the business outright, and the business pays the way, is that self-funded or not? Maybe a bit -- but, if you're self funded then you have no affiliation on your badge. So I could pass for self-funded by not telling putting down a company name on my registration? Yes. I think other organizations make this kind of distinction work by giving more rights to people who pay more; that would be the opposite of what we want to do here. I was specifically thinking of SIGCOMM's student travel grant program -- in which the above is not the case. But student is a well-defined class, with a moderately good means to check. Self-funded is neither. Former might still apply, to some extent. Of course self-funded price should probably be higher than student price, for obvious reasons. Certainly, I'd have qualified for student myself, but have always made my company pay the full price: the IETF needs the money more than my company, I've gathered. If the difference would be like 100-200 dollars, or whatnot, would people bother? Without company in the nametag, it would be for all to see, too. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Fw: Welcome to the InterNAT...
On Thu, 27 Mar 2003, Tony Hain wrote: Pekka Savola wrote: Who said the addresses are *completely* revokated when the network connectivity is intermittent? More likely than not, those address advertisements have a lifetime longer than the duration of the downtime (both preferred and valid in RFC2461 terms!) -- and whoops, everything works like a charm still! You continue to ignore the fact that when the connection to the public network reestablishes with a different prefix, all existing internal connections will be dropped. [...] Not so. (If you build your system in an optimal fashion -- which really does need a bit fleshing out, though.) Such prefixes would then reach valid lifetime=x, preferred lifetime=0, be set deprecated and not be used for new connections anymore. Nothing requires connections be killed using such deprecated addresses. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. Well Matt, this may happen in various groups, but the IPv6 WG has been actively debating this issue since Atlanta. I object to the characterization of the discussion as an exchange of handwaves. How many of your 22 speakers had implementation and deployment experience to report? From looking at the names, I would say at least 18. I suggest that this discussion resumes on the IPv6 mail list after the minutes are published. -- Christian Huitema
RE: Fw: Welcome to the InterNAT...
Pekka Savola wrote: Not so. (If you build your system in an optimal fashion -- which really does need a bit fleshing out, though.) So the intent is to dictate to everyone how they build their networks? Such prefixes would then reach valid lifetime=x, preferred lifetime=0, be set deprecated and not be used for new connections anymore. Nothing requires connections be killed using such deprecated addresses. Get real! If the prefix is not imediately invalidated, it will be impossible to connect to nodes that now have a valid right to use that prefix. If the router does not have a current prefix allocation, it must set valid lifetime to 0. It is not reasonable to expect an automated process to figure out when you want it to keep a prefix around and when you want it to go away. Even if it could do that, one set of machines on the local network may want the opposite state from another set of machines. Tony
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
On Thu, Mar 27, 2003 at 06:51:01PM -0500, Keith Moore wrote: I suspect that most people there, who voted for the elimination of site-locals, would still be favor of enabling the features that site-locals were intended to offer. Perhaps the majority position could be paraphrased as against site-local, but sorry to see them go. I agree. I think there was a general understanding that we need to provide the capabilities that SLs were supposed to provide, but to do so in other ways. Agree absolutely. Erik made good points in SFO about desirable addressing properties for customer networks (e.g. stable addressing). That is one side of the issue. The ipng list should be identifying the scenarios where networks require addressing that would have otherwise have been supplied by site-locals, and present viable alternatives. For example, manets, intermittently connected networks, and community networks with partial yet varied uplinks. If these can be addressed (sic), then I think objections will diminuish. As a side-note, a fifth SL option was presented out of the blue in SFO, namely exclusive SL/global addressing (one or the other only), which, because it was rather a broken idea, I think perhaps added to the room sentiment that site-locals are broken (rightly or wrongly :) Tim
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
At 03:49 PM 3/27/2003 -0800, Tony Hain wrote: Margaret Wasserman wrote: No active IPv6 WG participant (whether or not he attends IETF meetings) could credibly claim that he was unaware that this discussion was taking place, The discussion has been about potential usage limitation, or BCP's identifying application issues. The point of deprecation came out of nowhere, and only occurred in the room in SF. This has not had valid discussion. There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. Margaret
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Margaret Wasserman wrote: There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. The agenda for SF was: Site-Local Addressing Impact of site-local addressing -- Margaret Wasserman (20 min) http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t Limited Usage Summary -- Margaret Wasserman (5 min) [See appendix of draft-wasserman-ipv6-sl-impact-02, above.] Moderate Usage Proposal -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt Nowhere in that or the mail preceding the meeting is elimination mentioned. Tony
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hi Tony, I am not sure what your point is exactly, or why you want to make this point on the full IETF list... Are you suggesting that the options open to the IPv6 WG should be constrained by the drafts that Bob and I list on the agenda? By Thursday, the agenda had actually changed to a joint presentation by me and Bob on the trade-offs between different site-local usage options. We also had a discussion section listed (on both the published and final agendas) that you omitted, and during that discussion the WG members in the room chose to reject the recommendations that Bob and I had made, and they chose to deprecate site local addresses. Frankly, I was as surprised as you were. Like all consensus reached in WG meetings, this consensus _will_ be confirmed on the list. You will get your chance to express your opinion there. You have your chance, right now, to make any arguments on the list that you think will persuade people not to deprecate site-local addresses. Unless you think that there is an issue here that is of wider IETF interest, perhaps we could move this discussion to the IPv6 WG mailing list? Margaret At 05:26 PM 3/27/2003 -0800, Tony Hain wrote: Margaret Wasserman wrote: There have been people calling for the complete removal of site-local addressing all along. And, elimination/deprecation was quite clearly raised as an option in Atlanta. At that time, we called for opinions on the following options: elimination, limited, moderate or full usage, and each of the four options had some support in that WG meeting. And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. The agenda for SF was: Site-Local Addressing Impact of site-local addressing -- Margaret Wasserman (20 min) http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t Limited Usage Summary -- Margaret Wasserman (5 min) [See appendix of draft-wasserman-ipv6-sl-impact-02, above.] Moderate Usage Proposal -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt Nowhere in that or the mail preceding the meeting is elimination mentioned. Tony
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Ted, Ted Hardie wrote: I think we then to consider whether the current need is for: non-routed globally unique space or for something else. If the answer is non-routed globally unique space, then the follow-on question is Why not get globally unique space and simply decide not to route it?. Michel Py wrote: Because such thing does not exist, it's called PI and is not available to IPv6 end-sites. And if it ever is, it will cost money or other annoyances to obtain. Ted Hardie wrote: I don't think something needs to be provider independent to fit this bill. Getting a slice of the global address space from some provider and choosing not route a portion of it (even if that portion is 100%) seems to me to create non-routed globally unique space. Does not work if you change providers and your former provider allocates this address space to someone else; the space then ceases to be globally unique. See below for a detailed technical case scenario. The collision risk is way too high. Here's the topology. Replace SL addr with non-routed globally unique space if you wish; talking about which you could also have a look at this: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt (disclaimer: unpublished unfinished text, but it's not like I never thought about it before). I used this topo before as an example of a utility company that has IP-enabled control devices. This is a fairly common topology. Global Addresses -- SL addr -- +-+ | ISP |: +--+--+: ! : +--+-+ +--+ +--+ +--+ | Router A : +--| Firewall+--+--| Firewall+--+--+ Router B +---+ ++ +--+ | +--+ | +--+ | : || | : +---+--+ +--+---++++ : | DFZ | | Host || Control | : | Host | +--+| Device | : +--+ +-+ ---Site --:-- Site - : - Router A is the SBR. - DFZ hosts need to be able to talk to hosts between the internal firewall and router B, but not to the control devices. - DFZ hosts need to be able to talk to the outside. - Hosts between the internal firewall and router B need to be able to talk to everybody. - Control devices are accessible only from hosts between the internal firewall and router B. The name of the game here is not renumbering the control devices if the ISP changes. There can be scores of them; this is not even open to discussion. Even NATv6 will be chosen over renumbering if need be and this includes developing the NATv6 code in-house if required. Argument heard a thousand times: You don't care about the prefix you use for these because it's not routable. Rebuttal given a thousand times: Wrong. You do route this prefix inside the site. If the prefix is being used both inside and outside you're SOL as hosts between the internal firewall and router B won't be able to talk to both. What is the risk? A LIR gets a /32, a site gets a /48. That's 64k sites per LIR at most. On a large LIR, the collision risk might be 1/3 or 1/4, not the kind of chance I take. OTOH, if I use a random /48 out of a private /24 block, the collision risk to the outside is zero and the collision risk if I have to merge with another site is 1 out of 16 Million (2^24) and this is the kind of odds I'm willing to take. I would prefer site-locals as it's a /10 that can make the collision risk for site mergers zero, but I'd deal with a /24. PA re-used addresses just don't cut it. Are you concerned that doing so has some impact on the routing system that needs to be considered? No. I am concerned about impacts on the routing system but this is an unrelated issue. Money and other annoyances are certainly concerns we all face. In that spirit please understand that keeping site local costs different money and creates different annoyances. This is irrelevant. Let's look at the situation: - You want to deprecate site-locals. - What does it cost me? Nothing. If SLs go away I can hijack any prefix of my own choosing to replace them, these days I have my eyes on a hole in the 6to4 space: 2002:0A00::/24. - What can you do about me hijacking a prefix? Nothing. - What do I gain: Actually, hijacking is more flexible than the exclusive model that Bob and Margaret have compromised on (I support it for the sake of compromise not because I like it). Someone said that a compromise is something that pleases no one, and to this regard the exclusive model is a very good one. - What problems have we (as engineers) solved by having me hijack a prefix instead of using site-locals? None. We have put an embarrassing issue under the carpet for now. - What is the impact for app developers that
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Michel, What you say is possible, and has happened. But dumb things happen. Those dumb things could happen with non site-local addresses as well. But look. Ultimately I think we as a community do need to own up to better tooling, which can lead to better expectations. Also, I don't see any reason why an IP v6 prefix allocation can't linger for a very long time after a contract ends. The tools need to set expectations, and perhaps some of the DHCP prefix delegation code can help here. Regards, Eliot
Re: Fw: Welcome to the InterNAT...
I second Tony's key point. SL's are just 1 form of IPv6 addresses with a limited scope. As soon as operations folks put up firewall or router filters, global addresses have the same scope limitations. they don't have the same set of problems that SLs do. SL addresses are ambiguous. if you can't reach a host using its SL address, you don't know whether the problem is that you're in a different site or whether the host is down or whether there is a link failure or this is prohibited by policy. so a multiparty app ends up needing to implement various hacks to deal with ambiguous addresses (proxies, tunneling, etc), in order to function across site boundaries (and apps *will* be expected to function across site boundaries). with globals, if an app can't reach the host using a global address, it's either a host failure, a network failure, or a policy decision. to a large degree this can be disambiguated using ICMP. but in many cases the app can treat these as 'out of its control' since there's no way to work around them. SLs thus break a clean separation of function between the apps and the network. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. uh, no. 102 people finally understood just how comprehensively broken SLs are, and managed to finally overwhelm the 20 or so who were still in compete denial about it. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Hello folks, I was there, and it wasn't so black and white. It's not fair to characterize it so. I suspect that most people there, who voted for the elimination of site-locals, would still be favor of enabling the features that site-locals were intended to offer. Perhaps the majority position could be paraphrased as against site-local, but sorry to see them go. My own vote was for elimination, but I think it will be a mistake if there isn't a way for people to get unique prefixes practically for free. Regards, Charlie P. Keith Moore wrote: This is so typical of the modern IETF -- 102 people were persuaded by handwaving arguments that something bad might happen if a new and useful technique were deployed, and they are being allowed to overwhelm the 20 who were willing to dig in and find and solve any real problems. uh, no. 102 people finally understood just how comprehensively broken SLs are, and managed to finally overwhelm the 20 or so who were still in compete denial about it. Keith
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
You are mixing cause and effect. In IPv4 the vast majority of nodes are limited to a single address at a time. Well, I don't know about windows boxes, but real operating systems have supported virtual hosting in IPv4 for many years. Having multiple addresses on a node, even a node with a single network interface, is nothing new. Network managers that want some of their nodes in private space find it simpler to also put the nodes with public access in the same space rather than deploy multiple subnets to each office and route between them. There are easier ways to solve the problem than having multiple subnets, that doesn't require use of SL. Any bit in the address can be used for filtering, it doesn't have to be in the subnet mask. During the IPV6 meeting in SF, we did discuss several options for limiting the use of site-local addressing, but all of those options had some sorts of problems associated with them. So rather than address any problems, the needs of the (mostly absent) network managers were simply dismissed as irrelevant. Nope. The problems couldn't be solved. The group responsibly decided to fix the architecture by deprecating site locals and to solve the network managers' problems in other ways, because the solutions to the network managers' problems without SLs are simpler than the solutions to everyone's problems with SLs. (especially because the latter do not exist) Site-local is nothing more than a well-known prefix for filtering. No, it's more than that. SLs impose burdens on hosts and apps. SLs break the separation of function between apps and the network that is inherent in the end-to-end principle. (2) RFC 1918 addresses are most commonly used behind NATs. In this case, there is a middle box that performs translation of those addresses into global addresses at the site boundary, both in IP headers and at the application layer (through ALGs). In IPv6, we hope to avoid NAT. Site-local addresses were expected to be used on globally connected networks without any translation. Why do you continue to equate SL with NAT? Why do you continue to accuse people of equating SL with NAT even when they carefully explain just how they are similar and how they are different? It doesn't require address selection rules or ALG's. The only way an application should receive a record with a SL is if it is in the same address zone as the target. Standardizing split DNS is both insufficient and unacceptable. What we should not do is stick our heads in the sand and believe that simply because we don't want to have limited scope addresses they will magically disappear. What we should not do is stick our heads in the sand and believe that simply because some sites will have limited scope addresses that it's okay to burden hosts, DNS, routing, and large numbers of applications with having to deal with them. Rather than force people to create a bunch of ad-hoc solutions to the problem, we should in fact provide an architected approach that creates a level of consistency (actually we have, but some want to see it deprecated). Actually we are working toward an architecture that provides a level of consistency. But this requires that we deprecate SL. Exactly. There are many of these applications defined within the IETF, by other standards bodies, and/or developed by private enterprises. In fact, the applications area folks assure me that there are more of these types of applications deployed than there are simple client- server applications (that was news to me). IETF applications that fall into this category include FTP, SIP and (in some uses) HTTP. And they will continue to fail when the network administrator puts in routing filters, only nobody will be able to figure it out because we removed the hint of a well-known prefix. No, it will be easy to figure out, because it will be clear that the network administrator is to blame, unlike the current situation with where the app vendor is blamed for the problems caused by the NAT. This moves the problem to a place where it's more easily fixed. This is a huge improvement. Maybe... There has been a great deal of reticence from application developers to rely on DNS look-ups for this type of referral, and it is not all based on DNS reliability. There are many, many nodes that either do not have a DNS entry or do not know their own DNS name, and many applications need to work on those nodes. Rather than fix the problem, shoot the feature that exposes it ... Rather than fix the problem, force another broken layer on every app. It won't solve anything but it will provide another layer of delay, complexity, and unreliability. The network will be even less functional than it is today, but at least we'll have something to blame it on. The borders exist. Either we create a tool that allows people to easily manage which nodes are on
RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
You are mixing cause and effect. In IPv4 the vast majority of nodes are limited to a single address at a time. Well, I don't know about windows boxes, but real operating systems have supported virtual hosting in IPv4 for many years. Having multiple addresses on a node, even a node with a single network interface, is nothing new. My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4 addresses. The sky is not falling. -- Christian Huitema
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
And in Atlanta we all agreed to take elimination off the list, and it has not been discussed since. what's changed is that we had a chance to look at various ways of limiting usage of SL, and found that none of them would make SLs tolerable.
Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)
As a side-note, a fifth SL option was presented out of the blue in SFO, namely exclusive SL/global addressing (one or the other only), which, because it was rather a broken idea, I think perhaps added to the room sentiment that site-locals are broken (rightly or wrongly :) well, it was something that hadn't been suggested yet, so I don't blame them for trying. but what became clear after looking at all of the different ways of limiting usage of site local side-by-side is that every way of restricting site locals still leaves us with a mess. the only set of restrictions that avoids leakage and/or requiring apps to be aware of network topology is to use SLs only on isolated networks, and experience with RFC 1918 strongly indicates that this doesn't work well in practice.
