Re: reqs for local addressing OR requirements for SL replacement? [Re:Accept hain/templin draft as wg item?]
Alain Durand wrote: This recent thread is stressing the fact that what is really needed is easy access to stable address space. Getting this address space from an ISP, a LIR or a RIR is just a minor variation. The point is that this can be solved by policy and does not require to put anything in the architecture to handle local addresses. Absolutely true. Indeed, draft-ietf-ipv6-unique-local-addr-00.txt doesn't put anything in the architecture (unlike FEC0::/10), and is the simplest way to get easy access to stable address space. That is also my response to Pekka's and Keith's last postings - yes, we can administer this usage of RIR space, but it will be simpler to administer if we have a separate chunk of space for this. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Pekka Savola wrote: ... Sure, but there are also other ways to obtain addresses. Really? Would you care naming one available today? a) talk to your ISP (or one of its upstreams), which his hopefully a LIR, or b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you address space even though you don't want physical connectivity at all. This simply doesn't fly. First of all, 100$/mo is far too much for a small office, school etc or for every Winnebago in the USA. Free, or $10 one-time fee, is more like it. Secondly, even if we get past that, it's the wrong answer. If I get a /48 from ISP A, and want to use it in private mode to set up VPNs to business partners who have their public connectivity from ISPs A, B and C, this /48 is going to cause various forms of head scratching for the operations people at all those business partners, and if it leaks, at all those ISPs. What is this /48 from ISP A doing on a site connected to B or C, or to a different part of A? Yes, this can all be configured to work, but it will be a much greater source of operational confusion than a /48 which by inspection can be seen to be private (not globally routeable) space. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
If I get a /48 from ISP A, and want to use it in private mode to set up VPNs to business partners who have their public connectivity from ISPs A, B and C, this /48 is going to cause various forms of head scratching for the operations people at all those business partners, and if it leaks, at all those ISPs. What is this /48 from ISP A doing on a site connected to B or C, or to a different part of A? Yes, this can all be configured to work, but it will be a much greater source of operational confusion than a /48 which by inspection can be seen to be private (not globally routeable) space. well, if advertising routes to your network's PA prefixes over your own private links is going to cause trouble, we need to fix that problem, rather than expect those private links to use PI addresses. because expecting every host to use the right prefix based on what links the traffic will use simply won't work. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
On Mon, 8 Sep 2003, Brian E Carpenter wrote: Pekka Savola wrote: ... Sure, but there are also other ways to obtain addresses. Really? Would you care naming one available today? a) talk to your ISP (or one of its upstreams), which his hopefully a LIR, or b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you address space even though you don't want physical connectivity at all. This simply doesn't fly. First of all, 100$/mo is far too much for a small office, school etc or for every Winnebago in the USA. Free, or $10 one-time fee, is more like it. It was just an example, I don't know how it would go in reality. One time fees don't fly in this context. They don't have the business model. See the thread with Michel. Secondly, even if we get past that, it's the wrong answer. If I get a /48 from ISP A, and want to use it in private mode to set up VPNs to business partners who have their public connectivity from ISPs A, B and C, this /48 is going to cause various forms of head scratching for the operations people at all those business partners, and if it leaks, at all those ISPs. What is this /48 from ISP A doing on a site connected to B or C, or to a different part of A? Yes, this can all be configured to work, but it will be a much greater source of operational confusion than a /48 which by inspection can be seen to be private (not globally routeable) space. I don't see anything problematic that didn't happen already here. Let's see. Let's say the non-routed address ia Enterprise A /48. ISP B or C doesn't know about Enterprise A. They don't see it unless it leaks. They only know the ISP A's aggregate. If they try to traceroute to the address, it goes to ISP A, and returns ICMP network unreachable (or something like that). Nothing peculiar there. ISP A, on the other hand, knows that the prefix is non-routed. If someone asks, they can tell as much. Or even register it in RIR DB as an unnumbered non-routed customer (if they don't want to reveal more information on that) .. no big deal there. The possible leakage could happen e.g. in the form of source addresses from Enterprise A coming to any of ISPs through the business partners. If ingress filtering is done, this is nothing paranormal. Packets just get dropped, or might trigger an alarm. If ingress filtering is not done, nothing special will be detected anyway. On the other hand, the business partners would never advertise w/ BGP Enterprise A's (private) address space; or if they tried, it would most likely be blocked by the ISP's BGP filtering. But even if it wasn't, this is no weirder than advertising more specifics today. The bottom line is, I don't see anything particularly disturbing here, especially if the special non-routable blocks are registered (at least anonymously or similar to domain names) in a database, like ones used today every day. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
-BEGIN PGP SIGNED MESSAGE- Michel Py wrote: Pekka Savola wrote: Sure, but there are also other ways to obtain addresses. Michel Py wrote: Really? Would you care naming one available today? a) talk to your ISP (or one of its upstreams), which his hopefully a LIR, or b) talk to any LIR, and pay him e.g. 100$/mo. He'll gladly give you address space even though you don't want physical connectivity at all. Is that what you call a solution available today? You have not been listening. 1. I don't want to pay for it. 2. I don't want that space to be reallocated to someone else if the LIR I got it from goes belly up. Hijacking is less risky. Basically the need is for the possibility to get a globally unique prefix directly from the RIR's without becoming a LIR and without paying money for it. The prefix received from the RIR would then not be allowed to be seen anywhere in the global routing table but just and only for private interconnects bypassing the internet. Also there should be a penalty for people leaking these prefixes. They could be stuck under the IX prefix assigments with the big warning that they are completely not globally routable. I would expect that the RIR's at least would require one to pay a registration fee and maybe a yearly fee so they can also easily check if the endsite using the space has not gone bellyup. Btw good assumption that RIR's won't go belly up :) Now, it a part of each LIR space was earmarked for that purpose and if there was a RIR policy that says that if LIR space is reallocated to a new LIR the new LIR has to honor address assignments made by the old one that would be another story. jj, where's your draft? Skip the LIR in this case and go directly to the RIR, maybe a sub-rir which sole purpose is 'distributing' these prefixes. One has to pay for domain names too, so these should not come for free either even where it only for the registration and administration costs. I think if you really want it for free, just hijack some 3ffe::/16 space, that won't be in use for years to come after 2006/6/6 :) Personally if I would require a /48 I would go to a friendly LIR and ask them a piece of the pie, I am aware of quite a lot of friendly ISP's who will do that for a case of beer :) (You can even get a /32 if you add some onions, but that is a different story :) Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP1yvsimqKFIzPnwjEQJvywCgq5D/U4znXR+o7solWYVUHz1uskAAnRiq M7Kro7/6+p1DJUvmJrzThXf5 =T/ia -END PGP SIGNATURE- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
-BEGIN PGP SIGNED MESSAGE- Pekka Savola wrote: ISP A, on the other hand, knows that the prefix is non-routed. If someone asks, they can tell as much. Or even register it in RIR DB as an unnumbered non-routed customer (if they don't want to reveal more information on that) .. no big deal there. And I bet you will get to that prospective 200 customers quite easily this way, making the RIR's happy too. Then again, just deploy a small GPRS service and you are applicable for a /31, because you should route a /48 to an endsite which might possibly have more than one network behind it. Greets, Jeroen -BEGIN PGP SIGNATURE- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / [EMAIL PROTECTED] / http://unfix.org/~jeroen/ iQA/AwUBP1yxlSmqKFIzPnwjEQKhAgCgmdHEhifKeOIcwKQxV2F1avYkkKgAnibP uBKjvOMLaq4V3kwxo/oyHhFX =TQYo -END PGP SIGNATURE- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
This recent thread is stressing the fact that what is really needed is easy access to stable address space. Getting this address space from an ISP, a LIR or a RIR is just a minor variation. The point is that this can be solved by policy and does not require to put anything in the architecture to handle local addresses. - Alain. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing ...
Alain Durand wrote: This recent thread is stressing the fact that what is really needed is easy access to stable address space. ... without any contingency on the existence or lack thereof of a 'higher level' address provider. Getting this address space from an ISP, a LIR or a RIR is just a minor variation. The point is that this can be solved by policy and does not require to put anything in the architecture to handle local addresses. The above clarification is the critical point that many people seem to miss. The value of local addresses increases as the deployment scenario gets SMALLER. An enterprise might choose to use local addresses so they can have a network numbering scheme that is independent of their ISP. However, they could probably buy this space from real global addresses if they wanted. Further, their 'network' as a whole is likely to be 'permanently' connected to the public internet. The networks that particularly benefit from local addresses are intermittently connected. Note that 'intermittent' doesn't mean a stable link that goes up and down, but that the 'logical' point of attachment (as defined by network prefix) may change, even on a daily or sub-daily basis. As it happens, the physical point of attachment may change as well. In a permanently attached network, the division between 'my inside world' and 'the outside world' is primarily a logical one. At some point (or points) we draw a line and say 'that side is in' and 'that side is out'. In a intermittently attached network this distinction is much more tangible. Inside is 'the stable bit'. Outside is 'the bit that changes and that I have no control over'. The home user / research ship / PAN wants their 'core' network to remain intact and independent of 'outside', but to have the ability to contact 'outside' if and when it exists. Side comment: Any 'inherent' security derived from local addresses is only as good as the default filtering in the internet, and it would be foolish to trust that implicitly. From a security standpoint, using a local address for internal traffic (and preventing some hosts from using any other address) is functionally equivalent to using a global for the same purpose. The core benefit of local addresses is independence from address allocation authorities (and thus a degree of stability). The price is non-routeability. -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing
Mark Smith wrote: I do like the idea of autoconfiguration, but in larger networks, it can start to work against you - your network can start doing things behind your back that make it terrible to diagnose faults. Indeed. Trouble is with all automated systems is that the engineer that troubleshoot will at some point make assumptions about what the automated system does, often based on the premise that it always does the same and that there might not be anything to check or do anyway. I'm not saying it's bad, but the common practice of autoconfiguration mechanisms is that they are not included in the engineer's team and don't talk to each other Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
That is what the hain/templin draft is about! The title of the draft is: Addressing Requirements for Local Communications within Sites Is the title supposed to be a pun? I.e., do you mean to find solutions to requirements for local communications .. or finding requirements for addressing mechanism to solve this problem ? The title says simply that there will be a need for local communications within sites and this need raises addressing requirements - nothing more. I have no idea how you could twist the meaning in the way you have; the english language isn't *that* ambiguous! :-) Addressing - Requirements for Local Communications within Sites -or- Addressing Requirements - for Local Communications within Sites IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing
On Wed, 27 Aug 2003 12:50:01 +1000 Andrew White [EMAIL PROTECTED] wrote: I agree with Brian - the security issues are not the driving force in local addressing. The requirements I want are simple: * I want to be able to create prefixes ex-nihilo (from nothing), without involving the user, the internet, or anything other than my router or collection of routers. * I want an acceptable level of uniqueness from these prefixes, so that I can connect (physically or via VPN) on such network to another without worrying about address collision. * I want internal applications to be able to keep communicating with each other regardless of the presense or absence of connections to the global internet or to other clusters of self-configuring routers. The 'filtering' requirement is not driven by security, but by a realisation that any self-created prefix is not going to fit within the aggregable PA architecture of the current internet. Thus, to protect the routing tables we need to filter the self-created space. Given these requirements, even the Hinden / Carpenter draft doesn't completely fulfil them, since it requires manual configuration of the prefix (via an algorithm, but it's still 'manual') and a mechanism to propagate that prefix within the local network. So far the best solution I've seen is to take a /12 prefix (I've been using fef0::/12, but fdf:://12 would work as well), append a MAC or EUI-48 (to /60) and still have four bits left over if you need to subdivide further (eg to generate prefixes for interfaces without an EUI-48 or MAC). The only drawback here is that each router generates a prefix that is only aggregable at the /60 (per-router) level and the /12 (universal) level, but since this is designed for self-contained ad-hoc networks with at the Why are you assuming an ad-hoc network with at the extreme a couple of hundred nodes ? I consider your requirements to be equally applicable to an architected enterprise (or other large) network supporting 1000s, 100 000s or even millions of nodes, which is likely to contain a larger number of routes such that route aggregation is attractive for network stability reasons, or even necessary to cope with equipment limitations. Only being able to aggregate within the network at between /60 - /64 really limits the usefulness of aggregation. I do like the idea of autoconfiguration, but in larger networks, it can start to work against you - your network can start doing things behind your back that make it terrible to diagnose faults. snip Regards, Mark. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing
Mark Smith wrote: Why are you assuming an ad-hoc network with at the extreme a couple of hundred nodes ? and then wrote I do like the idea of autoconfiguration, but in larger networks, it can start to work against you - your network can start doing things behind your back that make it terrible to diagnose faults. I think you just answered your own question. :) That said, I believe there are situations where local addressing is appropriate in a configured network, mainly to exploit the PI aspect of it. The difference between such networks and the ad-hoc ones I have in mind is that an architected network can partition their PI space in an aggregated manner, exactly as they would do for PA space. So requirements 2 and 3 are still applicable, but requirement 1 is not (as we both agree that someone is exercising at least some control over how the routers are configured). This still leaves the knotty problem of which address to use by default. I'm still of the opinion that the most sensible option is for the 'system' to suggest that the application by default use the smallest applicable common scope (known to the system), but make it easy for the application to override that recommendation if it thinks it knows better. There are three situations that readily come to mind where an application might want to override the default: * application uses address-based referrals. * particular addresses are known to have short lifetimes and the application plans a long-lived connection. * using link-local addresses in an environment where a device could move between links yet meaningfully keep a constant higher-level address. -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Leif Johansson wrote: Sigh. This is almost to dumb to respond to and I'll be kicking myself when the next stats come out ;-) It is possible to build a good car lock (I claim) and some day someone will find the economic incentive to do so. Since I'm so dumb explain me why isn't the good car lock installed on every car yet? It's not like the car lock problem is new. And why isn't your miracle security setup installed on every network? We have a word for people such as yourself that claim things that they don't have: vaporware. If you were an experienced network administrator you would have plenty of opportunities to appreciate how close the bullet passed and how this little extra step saved you precious butt big time. So far, all my car lock did for me is prevented me to get into my own car, but that's not a reason not to use it. Pray you don't get hacked, because when you do your senior management will get an external consultant to assess your network, and good security consultants will google your name and find your postings; in the US, you would be not only fired but sued by your former employer for negligence. The fact that the lock does suck is not an excuse not to use it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
On Sun, 24 Aug 2003, Tony Hain wrote: This document seems to take for granted that local-use addressing is needed. Moreover, it lists requirements for every possible case where local-use address could be applied to (and, not for example, those cases where the local-use addressing is really necessary). Necessity is both the perception of the network manager in trying to implement a local policy, and the availability of alternatives that actually fit all of the local constraints. It may not be our business to enhance misguided perceptions of the network managers, rather than correct them. Process questions: 1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? I don't understand the question. My original draft started from the premise that the WG should at least have the requirements for local addressing before deciding that any given technology is either acceptable or unacceptable. Site-local is a specific technology that meets many of the needs of local addressing, but creates other problems through its ambiguity. Getting rid of ambiguity does not remove the requirements for local addressing. The ambiguity was just one reason to get rid of site-locals, and I believe a non-ambiguous version is already being worked at. However, my point is that we should not be advocating local-use addresses. It is far from clear where they're actually needed, and where they're actually the best solution. I.e., I think there was some sort of consensus in the SF IETF meeting that there is a need to do at least *something* after we deprecate site-local addressing; there are some scenarios where SL's were being imagined to be used -- and now we should figure out how to address the needs of those scenarios *in general terms*, rather than jumping straight to the requirements for local addressing. It might just be that we don't need local addressing in all of those scenarios (actually, I'm certain of that). 2. Then if we see that local addressing is required to do X, see that this document covers X adequately? If the goal is to design specific approaches for every scenario, then this suggestion would be appropriate. The goal of the requirements document at the moment is to aggregate multiple needs under a single technical approach. If the WG decides that multiple approaches make more sense, then there will need to be multiple requirements documents. Agree. Note that I'm not really strongly advocating separate documents, but that we AT LEAST figure out why such-and-such requirements are there. I don't send in more detailed comments on the draft, because I pretty much disagree with everything it says. I understand your network does not have these requirements, and if we required everyone to implement local addresses I could understand some degree of concern. What I don't understand is why you believe it is appropriate to tell another network manager that his stated requirements are invalid. I do not want a cure that is worse than the disease. That is, if we make local-use addresses work too well, and applicable also in scenarios where it isn't needed -- people go for locals and not globals. That would be a serious disadvantage for IPv6. Just two notes: 3.1 -- Network managers have stated, and historical experience has shown, that there is a need for addresses that do not require public registration. == there is no supporting evidence of this expect vague statements. Please be more explicit as I don't see how we can take this for given. Chasing down quotes is not appropriate. If you want to see more text about people grabbing random space from documentation or currently using 1./8, I suspect we can come up with that. I fail to see how this leads to the requirement for non-publicly-registered addresses. What's the problem with public registration? Perhaps there is just a problem how that has been done with IPv4. [snip] -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
On Mon, 25 Aug 2003, Michel Py wrote: Pekka Savola wrote: What I'm trying to say is that we need to first figure out where we need local-use applications -- and, as an interim feature, maybe reword the current draft so that it's apparent which current perceived local-use scenarios require specific requirements. This appears to me the opposite of what is generally done within the IETF. First we write requirements then we look at specific scenarios, not the opposite. My point exactly! Why are we writing requirements for _local addressing_, and not writing requirements to solve the problems which people perceive exist in IPv6 after the elimination of site-locals?!!?!? which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? And what problems has this caused that are really, really problematic? NAT, in the first place. Please be a bit more specific on how that came to be. Do you mean that folks who hijacked the address space deployed NAT to be able to continue using their hijacked space inside their network but do one-to-one conversion at the border? On the other side, I fail to see the need to hijack a prefix for your running system. IPv6 addresses are quite obtainable nowadays if you're an equivalent of LIR. Doubly irrelevant to the discussion: first, you can't ask every network to become a LIR; second, the need for public addresses and local addresses is totally different, so even if one enterprise has become a LIR to obtain public addresses it does not remove the need for private ones. Sure, but there are also other ways to obtain addresses. So, what you're really saying that folks would hijack prefixes to be used internally (instead of trying to use them externally). I wonder if that was the case of prefix hijacking by-and-then. Sites could very well get another /48 for internal-only connections, and /48 for public ones, I guess. Easy to filter at the edges, doesn't need to be routed, etc. Shouldn't be a huge problem in getting through RIR policies. In addition, compared to the situation back in 1994 (and earlier), people actually use Routing Registries to check advertisements. You really cannot assume that you could hijack a prefix and have it work in the Internet. I have live examples that use NAT for that purpose and some other people have contributed the same here. You did not answer the question. The question is not why network administrators are wrong to use local addresses. Wrong or not, and whether you like it or not, they have, do and will use them. Putting your head in the sand or stating that there are no reasons to use local addressing is not going to change it. There are extremely large numbers of networks that currently use local addressing; RFC1918 is not what created this situation: to the contrary it is a by-product of their widespread use and created well-known prefixes for them. What makes you thing that the requirements of all these networks have changed? Given time, bogus requirements could be shown to be bogus. Perhaps SoBig and friends have enlightened some network managers to the fact that private addressing helps you not at all. I do not see the need to repeat IPv4's mistakes in IPv6. That's why we advocate dual-stack deployment. If you want to keep the broken designs, keep those IPv4-only. My (and others) goal is to show that the use of local addressing is not the right approach in many cases, and show some alternative means to achieve the same ends. If, in the end, the users wish to shoot them in the foot, we can't prevent that, but via these procedures I'd hope it's the 1% who do the shooting, not 99%. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SLreplacement?[Re: Accept hain/templin draft as wg item?]
The other point that's been missed here is that the security-by-hiding argument is only part of the story. Stable address space for intermittently connected networks, unambiguous address space for VPNs, and stable identifiers for multihoming, are also needed. Whatever your religion on the hiding argument, these other needs have to be met, and are not met by PA prefixes. Brian Hans Kruse wrote: I fear this discussion is headed in the wrong direction as far as the decisions in this group. You are of course right that filtering (by private or public addresses) at a border is not sufficient security. But it DOES remove some unwanted traffic. Is this relevant to local addressing -- probably not. However, I have become convinced that some form of local addressing is required to allow network managers enough flexibility to solve their design issues. I hope the WG can create these addresses, try to insure that they won't break things (as SL apparently did), and move on. You mileage may (probably will) vary --On Monday, August 25, 2003 20:36 +0200 Leif Johansson [EMAIL PROTECTED] wrote: By contrast your private address space does not protect your network from an attack which violates the basic assumption that there is an inside and an outside. The added twist from [EMAIL PROTECTED] and friends is that you no longer have to be a network security geek to appreciate this fact. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SLreplacement?[Re: Accept hain/templin draft as wg item?]
Brian E Carpenter wrote: The other point that's been missed here is that the security-by-hiding argument is only part of the story. Stable address space for intermittently connected networks, unambiguous address space for VPNs, and stable identifiers for multihoming, are also needed. Whatever your religion on the hiding argument, these other needs have to be met, and are not met by PA prefixes. And to be frank, Brian, I am not convinced that even this argument has been thought out well. For instance, how will systems be restricted from having both types of IP addresses? Will it be a host policy or a network policy? If it's a network policy, how does that work with stateless autoconfiguration? Eliot IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, Pekka Savola wrote: Do you mean that folks who hijacked the address space deployed NAT to be able to continue using their hijacked space inside their network but do one-to-one conversion at the border? Yes. Today it is extremely common to see this with RFC1918 addresses in the inside, but there still are a handful of networks that have hijacked non-RFC1918 space that don't see why they should bother renumbering, going by the rule if it ain't broke don't fix it. There is a chicken-and-egg argument on the timing, which is did people use NAT to do this because NAT was available or was NAT developed for that purpose but in the end the result is there. On the other side, I fail to see the need to hijack a prefix for your running system. IPv6 addresses are quite obtainable nowadays if you're an equivalent of LIR. Doubly irrelevant to the discussion: first, you can't ask every network to become a LIR; second, the need for public addresses and local addresses is totally different, so even if one enterprise has become a LIR to obtain public addresses it does not remove the need for private ones. Sure, but there are also other ways to obtain addresses. Really? Would you care naming one available today? So, what you're really saying that folks would hijack prefixes to be used internally (instead of trying to use them externally). I wonder if that was the case of prefix hijacking by-and-then. When I did hijack prefixes in the early 90's it was mostly a matter of convenience for internal use. My (and others) goal is to show that the use of local addressing is not the right approach in many cases, and show some alternative means to achieve the same ends. It does not work that way. First, network administrators for the most part don't read this. Second, you have not been an enterprise network administrator for any significant time so they're not going to listen to you anyway. Third, the reasons enterprise network administrators make decisions are for a significant part based on experience; in other words the reason to use local addresses is either because some day one did not use them and got shot, or because some day one did use then and it saved one's butt so one keeps using them. What you have is untested theories about network design, what they have is years of experience that built a sense of what works and what does not. I do not see the need to repeat IPv4's mistakes in IPv6. The mistake would be not to provide a local addressing solution and have to do RFC1597 for IPv6 again. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Pekka, Pekka Savola wrote: On Mon, 25 Aug 2003, Michel Py wrote: Pekka Savola wrote: What I'm trying to say is that we need to first figure out where we need local-use applications -- and, as an interim feature, maybe reword the current draft so that it's apparent which current perceived local-use scenarios require specific requirements. This appears to me the opposite of what is generally done within the IETF. First we write requirements then we look at specific scenarios, not the opposite. My point exactly! Why are we writing requirements for _local addressing_, and not writing requirements to solve the problems which people perceive exist in IPv6 after the elimination of site-locals?!!?! That is what the hain/templin draft is about! The title of the draft is: Addressing Requirements for Local Communications within Sites The title articulates the problem space which is perceived as requiring new solutions after the elimination of site-locals; it is not pre-judging what those solutions should be. If you think any of the requirements or scenarios in the document are invalid and/or leaning too strongly in favor of a particular solution alternative, please send specific comments to that effect. (I saw that you did provide some pointed comments earlier; thanks for those.) Fred [EMAIL PROTECTED] P.S. In case it is getting lost in the noise, the document ID is: http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
On Tue, 26 Aug 2003, Fred Templin wrote: Pekka Savola wrote: My point exactly! Why are we writing requirements for _local addressing_, and not writing requirements to solve the problems which people perceive exist in IPv6 after the elimination of site-locals?!!?! That is what the hain/templin draft is about! The title of the draft is: Addressing Requirements for Local Communications within Sites Is the title supposed to be a pun? I.e., do you mean to find solutions to requirements for local communications .. or finding requirements for addressing mechanism to solve this problem ? The title articulates the problem space which is perceived as requiring new solutions after the elimination of site-locals; it is not pre-judging what those solutions should be. If you think any of the requirements or scenarios in the document are invalid and/or leaning too strongly in favor of a particular solution alternative, please send specific comments to that effect. (I saw that you did provide some pointed comments earlier; thanks for those.) As said, I disagree with pretty much all of the document, if it is *supposed* to be the requirements how to find solutions for IPv6 sites which seem impaired by IPv6 after SL's are dead. About the only non-solution specific thing about the document seems to be the title (depending on whether you take it for a pun or not..) The document assumes we need local addressing. That's already solutionism. Having a document which explores local addressing requirements may be OK -- but at least state it clearly and DON'T pretend otherwise! :-) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SLreplacement?[Re: Accept hain/templin draft as wg item?]
Michel Py [EMAIL PROTECTED] writes: Since I'm so dumb explain me why isn't the good car lock installed on every car yet? It's not like the car lock problem is new. And why isn't your miracle security setup installed on every network? We have a word for people such as yourself that claim things that they don't have: vaporware. Because people still think of outside and inside. There is no inside or outside. There is a many outsides. Private addresses, by themself, gives you no more security the using non-private addresses, they still have to filtered somewhere. Will you trust your isp to not attack you ? Love BTW, acls are very nice vaporware, I use them every day. pgp0.pgp Description: PGP signature
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Pekka Savola wrote: On Tue, 26 Aug 2003, Fred Templin wrote: Pekka Savola wrote: My point exactly! Why are we writing requirements for _local addressing_, and not writing requirements to solve the problems which people perceive exist in IPv6 after the elimination of site-locals?!!?! That is what the hain/templin draft is about! The title of the draft is: Addressing Requirements for Local Communications within Sites Is the title supposed to be a pun? I.e., do you mean to find solutions to requirements for local communications .. or finding requirements for addressing mechanism to solve this problem ? The title says simply that there will be a need for local communications within sites and this need raises addressing requirements - nothing more. I have no idea how you could twist the meaning in the way you have; the english language isn't *that* ambiguous! Fred [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SLreplacement?[Re: Accept hain/templin draft as wg item?]
Eliot Lear wrote: Brian E Carpenter wrote: The other point that's been missed here is that the security-by-hiding argument is only part of the story. Stable address space for intermittently connected networks, unambiguous address space for VPNs, and stable identifiers for multihoming, are also needed. Whatever your religion on the hiding argument, these other needs have to be met, and are not met by PA prefixes. And to be frank, Brian, I am not convinced that even this argument has been thought out well. For instance, how will systems be restricted from having both types of IP addresses? Some scenarios actually want both. Why do you assume that having both is a problem? Will it be a host policy or a network policy? That needs to be a local decision. The IETF is not in the business of telling people how to run their networks. If it's a network policy, how does that work with stateless autoconfiguration? If the goal is only to allow local, then only put a local in the RA. If it is only to allow global, likewise. If there are to be a mix on the same wire, it is a host policy by definition. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka Savola wrote: The document assumes we need local addressing. That's already solutionism. Having a document which explores local addressing requirements may be OK -- but at least state it clearly and DON'T pretend otherwise! :-) There is no intent to pretend. Maybe what you are trying to say is that the document needs to do a better job of documenting the requirement from the Application space that they be able to identify any non-globally accessible addresses so they can ignore them. This has been stated many times on the list, but is probably not well documented in the current draft. I suspect this is the core of your argument about why we don't need any local use addresses. In the abstract, any prefix can be kept out of the global routing system, and satisfy most of the scenarios in the draft. The issue comes when one wants to have some nodes with global access, while others are limited to local access. Mixing a single prefix in this environment creates a bottleneck single point of failure in any edge access control, and assumes that the nodes are static in their attachment to the local topology. That set of constraints is unacceptable to many network managers, so their response will be to use nat to absolutely protect the nodes that need to be. An alternative is to use 2 prefixes in the network, where one is in the global routing system and the other is not. From a routing perspective there is no particular requirement that the restricted one be identifiable from the global one. Again, any prefix that is not in the global routing system achieves the protection goal. This brings us back to the requirements Keith and others have expressed, in that any address which is not globally accessable have a flag so they can choose to ignore it when referring literal topology attachments to others. At the same time, there are other scenarios where the application wants to know how to avoid global exposure. We can and should use the Bellovin/Zill approach to indicate which prefix is local, but we should also make the local flag well-known so that service providers put them on the bogon list. This helps reinforce the expectation that the prefix stays local, and removes the possibility of a single error exposing systems that should not be. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, Pekka Savola wrote: 1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? Do you mean that the Hain/Templin draft is too generic, or not specific enough? 3.1 -- Network managers have stated, and historical experience has shown, that there is a need for addresses that do not require public registration. == there is no supporting evidence of this expect vague statements. Please be more explicit as I don't see how we can take this for given. Maybe you are too young to remember but network administrators have hijacked addresses for ages, which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
On Sun, 24 Aug 2003, Michel Py wrote: Pekka Savola wrote: 1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? Do you mean that the Hain/Templin draft is too generic, or not specific enough? Yes. It takes for granted that we need local-use addressing, and lists a lot of requirements for local-use addressing (some of which are most probably redundant if you'd apply local-use addressing only to *specific* scenarios). What I'm trying to say is that we need to first figure out where we need local-use applications -- and, as an interim feature, maybe reword the current draft so that it's apparent which current perceived local-use scenarios require specific requirements. 3.1 -- Network managers have stated, and historical experience has shown, that there is a need for addresses that do not require public registration. == there is no supporting evidence of this expect vague statements. Please be more explicit as I don't see how we can take this for given. Maybe you are too young to remember but network administrators have hijacked addresses for ages, yep.. which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? And what problems has this caused that are really, really problematic? If you have a disconnected network which you don't plan to connect without renumbering (which has to be done anyway), it doesn't matter if you hijack a prefix. On the other side, I fail to see the need to hijack a prefix for your running system. IPv6 addresses are quite obtainable nowadays if you're an equivalent of LIR. In addition, compared to the situation back in 1994 (and earlier), people actually use Routing Registries to check advertisements. You really cannot assume that you could hijack a prefix and have it work in the Internet. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, Pekka Savola wrote: What I'm trying to say is that we need to first figure out where we need local-use applications -- and, as an interim feature, maybe reword the current draft so that it's apparent which current perceived local-use scenarios require specific requirements. This appears to me the opposite of what is generally done within the IETF. First we write requirements then we look at specific scenarios, not the opposite. Besides, at this stage of things it is generally admitted that a broader view is useful in describing the problem in context. which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? And what problems has this caused that are really, really problematic? NAT, in the first place. On the other side, I fail to see the need to hijack a prefix for your running system. IPv6 addresses are quite obtainable nowadays if you're an equivalent of LIR. Doubly irrelevant to the discussion: first, you can't ask every network to become a LIR; second, the need for public addresses and local addresses is totally different, so even if one enterprise has become a LIR to obtain public addresses it does not remove the need for private ones. In addition, compared to the situation back in 1994 (and earlier), people actually use Routing Registries to check advertisements. You really cannot assume that you could hijack a prefix and have it work in the Internet. I have live examples that use NAT for that purpose and some other people have contributed the same here. You did not answer the question. The question is not why network administrators are wrong to use local addresses. Wrong or not, and whether you like it or not, they have, do and will use them. Putting your head in the sand or stating that there are no reasons to use local addressing is not going to change it. There are extremely large numbers of networks that currently use local addressing; RFC1918 is not what created this situation: to the contrary it is a by-product of their widespread use and created well-known prefixes for them. What makes you thing that the requirements of all these networks have changed? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Pekka, We are talking about the way enterprise network managers think about their networks. These are people who *will* get fired if their network is seriously penetrated. In fact, I expect quite a few will be fired in the near future because of inadequate protection against the current virus pandemic. These are people who *will* insist on every single way of limiting access. They will agree that security by obscurity is only a partial solution, but they add it to all the other partial solutions. They will *not* tolerate a solution in which misconfigured ACLs in border routers could expose the RPC ports on individual Windows boxes to packets from outside the enterprise. That's in addition to compelling all employees to install the MS03-26 patch and a personal firewall. In this context, some form of private address space is not even slightly optional. Even when RFC 1597 was published, the above pressures were there. They are 100 times greater now. So it's simply inevitable that enterprises will use private (i.e. non-PA, non-routeable) space. Our challenge is to make it as good as we can. Brian Pekka Savola wrote: On Sun, 24 Aug 2003, Michel Py wrote: Pekka Savola wrote: 1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? Do you mean that the Hain/Templin draft is too generic, or not specific enough? Yes. It takes for granted that we need local-use addressing, and lists a lot of requirements for local-use addressing (some of which are most probably redundant if you'd apply local-use addressing only to *specific* scenarios). What I'm trying to say is that we need to first figure out where we need local-use applications -- and, as an interim feature, maybe reword the current draft so that it's apparent which current perceived local-use scenarios require specific requirements. 3.1 -- Network managers have stated, and historical experience has shown, that there is a need for addresses that do not require public registration. == there is no supporting evidence of this expect vague statements. Please be more explicit as I don't see how we can take this for given. Maybe you are too young to remember but network administrators have hijacked addresses for ages, yep.. which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? And what problems has this caused that are really, really problematic? If you have a disconnected network which you don't plan to connect without renumbering (which has to be done anyway), it doesn't matter if you hijack a prefix. On the other side, I fail to see the need to hijack a prefix for your running system. IPv6 addresses are quite obtainable nowadays if you're an equivalent of LIR. In addition, compared to the situation back in 1994 (and earlier), people actually use Routing Registries to check advertisements. You really cannot assume that you could hijack a prefix and have it work in the Internet. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Brian E Carpenter wrote: Pekka, We are talking about the way enterprise network managers think about their networks. These are people who *will* get fired if their network is seriously penetrated. In fact, I expect quite a few will be fired in the near future because of inadequate protection against the current virus pandemic. These are people who *will* insist on every single way of limiting access. They will agree that security by obscurity is only a partial solution, but they add it to all the other partial solutions. They will *not* tolerate a solution in which misconfigured ACLs in border routers could expose the RPC ports on individual Windows boxes to packets from outside the enterprise. That's in addition to compelling all employees to install the MS03-26 patch and a personal firewall. In this context, some form of private address space is not even slightly optional. Even when RFC 1597 was published, the above pressures were there. They are 100 times greater now. So it's simply inevitable that enterprises will use private (i.e. non-PA, non-routeable) space. Our challenge is to make it as good as we can. I am a network manager. The fact I might not get fired as the result of a big compromise is more a function of Swedish management culture than anything else. I have had the perverse pleasure of watching large coorporations and agencies in Sweden crash and burn during the last two weeks while we kept afloat. Here comes the punchline: ACLs (in whatever form) do not help as much as most people think against current viruses and woms. Why you ask? Because someone invariably will bring their laptop to work and kaboom. The added protection you get from a private address space is isn't worth the bits the configuration is stored in. Could we please stop talking about scoped addressing as a solution to security problems? It is not and furthermore even the guys in the trenches who pipeline firewalls for extra protection are waking up to this fact. Very uncomfortably. These are real honest-to-god experiences from the real world. Lately when coming to the IETF I keep hearing that participation from operators and network managers are important. The SL/LL/scope debate on this list has convinced me that it is not only important but imperative. Cheers Leifj IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Leif Johansson wrote: The added protection you get from a private address space is isn't worth the bits the configuration is stored in. Exactly the same as saying that car locks are not worth having because they're so easy to open that they don't stop anybody. It is true indeed that any amateur with a coat hanger will open a car in a matter of seconds. As a matter of fact, I locked my keys in my car a while ago and I had to call AAA to let me back in. It took more time to the driver of the AAA truck to fill the paperwork than it did to open the door. Guess what: cars have locks anyway and nothing you can say about car locks being a joke is going to change it. If you don't like it, you can leave your car open. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
Leif Johansson wrote: Sigh. This is almost to dumb to respond to and I'll be kicking myself when the next stats come out ;-) It is possible to build a good car lock (I claim) and some day someone will find the economic incentive to do so. So there should be no locks on cars until someone finds the economic incentive to build something better than what is there? By contrast your private address space does not protect your network from an attack which violates the basic assumption that there is an inside and an outside. You appear to presume that to be useful a technology must solve all known problems. Address space that is not routed to the world does provide protection from direct attacks. It does not prevent indirect attacks through nodes that have a route. The added twist from [EMAIL PROTECTED] and friends is that you no longer have to be a network security geek to appreciate this fact. Any node that can be reached directly or indirectly from outside the perimeter can bring undesireable content into the protected area. The more layers of protection there are, the more opportunity there is to isolate and contain any problems. Having address space that is not routed provides an extra layer which protects against failures in the firewall/access controls. If your network doesn't require that extra level, there is no need to deploy it. At the same time, there are network managers that insist on having that capability. Tony IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SLreplacement?[Re: Accept hain/templin draft as wg item?]
I fear this discussion is headed in the wrong direction as far as the decisions in this group. You are of course right that filtering (by private or public addresses) at a border is not sufficient security. But it DOES remove some unwanted traffic. Is this relevant to local addressing -- probably not. However, I have become convinced that some form of local addressing is required to allow network managers enough flexibility to solve their design issues. I hope the WG can create these addresses, try to insure that they won't break things (as SL apparently did), and move on. You mileage may (probably will) vary --On Monday, August 25, 2003 20:36 +0200 Leif Johansson [EMAIL PROTECTED] wrote: By contrast your private address space does not protect your network from an attack which violates the basic assumption that there is an inside and an outside. The added twist from [EMAIL PROTECTED] and friends is that you no longer have to be a network security geek to appreciate this fact. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? even that seems to me to be asking the question in terms of an assumed answer. I want to see the questions asked in terms of real problems, not in terms of assumed solutions. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka Savola wrote: Hi, As some others have also commented, I have serious concerns about the hain/templin draft. Thank you for providing constructive text, rather than simply complaining. An observation: This document seems to take for granted that local-use addressing is needed. Moreover, it lists requirements for every possible case where local-use address could be applied to (and, not for example, those cases where the local-use addressing is really necessary). Necessity is both the perception of the network manager in trying to implement a local policy, and the availability of alternatives that actually fit all of the local constraints. Process questions: 1. Shouldn't we first see the requirements for site-local replacement (and other issues) and not jump straight to the requirements for local addressing? I don't understand the question. My original draft started from the premise that the WG should at least have the requirements for local addressing before deciding that any given technology is either acceptable or unacceptable. Site-local is a specific technology that meets many of the needs of local addressing, but creates other problems through its ambiguity. Getting rid of ambiguity does not remove the requirements for local addressing. 2. Then if we see that local addressing is required to do X, see that this document covers X adequately? If the goal is to design specific approaches for every scenario, then this suggestion would be appropriate. The goal of the requirements document at the moment is to aggregate multiple needs under a single technical approach. If the WG decides that multiple approaches make more sense, then there will need to be multiple requirements documents. 3. Not consider those not listed in the sum-of-all-X at all? (or at least, make the separation what scenarios require specific features clearer)? I am not sure what you are trying to say, but I think this is a continuation of 2. I don't send in more detailed comments on the draft, because I pretty much disagree with everything it says. I understand your network does not have these requirements, and if we required everyone to implement local addresses I could understand some degree of concern. What I don't understand is why you believe it is appropriate to tell another network manager that his stated requirements are invalid. If we explicitly make the decision that local-use addressing is needed in some scenarios, I might accept that and review it again with that in mind. See 2 above. Just two notes: 3.1 -- Network managers have stated, and historical experience has shown, that there is a need for addresses that do not require public registration. == there is no supporting evidence of this expect vague statements. Please be more explicit as I don't see how we can take this for given. Chasing down quotes is not appropriate. If you want to see more text about people grabbing random space from documentation or currently using 1./8, I suspect we can come up with that. 3.2 Applications require addresses that remain stable during intermittent connectivity, site mergers, ... == it is not clear what you mean with stability, i.e. what the _real_ requirement is. Connection survibability, or something else? See my note this morning about solving the right problem. Applications frequently fail if the addresses are changed out from under them. This is not a requirement, but a fact supported by empirical evidence. The real requirement is that local applications continue to function even if the external connectivity is intermittent or changing. I know you have offered ways to mitigate the problem, but they all come with constraints that, while appropriate for your network environment, do not meet the needs of other networks. It appears you would rather do targeted engineering for individual scenarios. We can take that approach, and will likely end up with a variety of technologies that people then need to figure out which one(s) apply. At the same time it is very likely that there will be a suppression of many requirements, because the participants are either not vocal enough, or don't represent a large enough segment of the community to deserve valuable WG focus. Forgive me if I consider suppression of requirements to be in direct conflict with providing solutions. Tony On Fri, 22 Aug 2003, Fred Templin wrote: Folks - do we have consensus to accept this document as an IPv6 wg item (see below)? Fred [EMAIL PROTECTED] Subject: I-D ACTION:draft-hain-templin-ipv6-limitedrange-01.txt From: [EMAIL PROTECTED] Date: Thu, 14 Aug 2003 10:27:13 -0400 To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Addressing Requirements for Local Communications within Sites
