Re: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Brian E Carpenter [EMAIL PROTECTED] ``Router manufacturers MUST ensure that said black hole cannot be deconfigured, turned off, or otherwise overridden in toto;'' |It's very simple. No sane router vendor would do this. I pointed out in my original comments that most router vendors have little incentive to abide by such a rule. So far. But that doesn't mean that they won't find some reason in the future. Moreover, entities building appliances with incidental router functionality may be unfamiliar with the issues and might follow the rule as written. The result is that the new addresses become devalued because you can't count on being able to configure all your network devices to use them. Why do we want to make a rule that no sane router vendor should follow? |The MUST can only apply to default configuration. But that's not at all what the language actually says. Why do we need to play such word games? It reminds me of politicians who say: ``We really need a law against common behavior x. But don't worry. It doesn't really mean that we will stop you from doing x. And besides, such a restriction would be unenforceable.'' Then after the next election: ``It's really hard to enforce the law against x. We really need to ban y and z to make sure people can't do x. After all, some previous set of elected politicians decided to make a law against x, so we have a duty to enforce it.'' Dan Lanciani [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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Andrew White [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | There is a huge difference between requiring a /48 and allowing anything | greater than /8. The former ... | while the latter means that you can bypass the black hole with 2 or 4 | route additions. | |Of course you can bypass it. The proposed wording is: ``Router manufacturers MUST ensure that said black hole cannot be deconfigured, turned off, or otherwise overridden in toto;'' How do you reconcile this with ``Of course you can bypass it.''? |But remember that your bypass is only useful |if all intermediate routers have ALSO agreed to the bypass, and that the BGP |routers by default ignore updates to local prefixes. Your reasoning would apply equally well to a black hole that *can* be turned off by the owner of the router. The proposal to make the black hole not only the default but a default that cannot be changed by the owner of the router is unprecedented. It relegates these new addresses to permanent second-class- citizen status even within a private network. |So yes, it's trival to modify your system so that the next router in the |chain discards the packet instead. Not with the proposed wording. |More usefully, you can redirect |particular known routes to VPNs or other directly connected networks and |still have the gateway router drop other (unknown) local packets. I don't want to direct only particular routes to VPNs. I want to direct all packets destined for otherwise unknown prefixes to a tunnel server which will try to dynamically establish a tunnel to the target network. The proposed restriction would make this kind of overlay network impossible. Maybe that's the idea. Dan Lanciani [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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Andrew White [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | Andrew White [EMAIL PROTECTED] wrote: | | |Dan Lanciani wrote: | | | | There is a huge difference between requiring a /48 and allowing anything | | greater than /8. The former ... | | while the latter means that you can bypass the black hole with 2 or 4 | | route additions. | | | |Of course you can bypass it. | | The proposed wording is: | | ``Router manufacturers MUST ensure that said black hole cannot be | deconfigured, turned off, or otherwise overridden in toto;'' | | How do you reconcile this with ``Of course you can bypass it.''? | |The immediately preceding context was Alan stating that his reading was that |only /8 routes are to be discarded and that anything more specific would be |forwarded. This was the culmination of a thread with more context. In any case, I can't see how the text can be read to mean that. It clearly states that the black hole cannot be overridden in toto. So how about we stop dancing around and answer the question: Can I completely disable the black hole on my own router or not? N.B., an answer of the form, ``you can disable it in ways that support what we consider to be appropriate uses of local addresses'' is not an answer. |You seemed to be saying that having an easy workaround |invalidated the value of the filter, which Alan and Christian (and I) seem |to disagree with. No, I said that having an easy (or any) workaround is contrary to the proposed wording. As an aside, I don't think this is a very productive way to come up with a spec. We are debating the meaning of proposed text when we should be debating the actual restrictions. Once we agree on the restrictions we can come up with text. There can be no legitimate reason to argue against clarifying the text, especially if the claim is that it does not mean what it plainly says. |I object to the proposed wording also, if only because routers must be able |to be configured for 'inside' work at which point local addresses are |in-scope and should not be filtered. It should be possible to disable the |filtering or refine it. That was my point from the beginning. The proposed wording forbids this. But that appears to be its intent. So object to the intent as well... |With such a restriction, I don't see much incentive for an ISP (or other |user) to disable the filters in a general manner. Since most routers will |filter anyway, they can only route the local packets to other people who've |disabled the filters, and anyone disabling the filters (and only those |people) needs to cope with potential routing table increases for their OWN |tables. There need be no routing table growth in an overlay network using dynamic tunnels. Only the existence of absurd restrictions on routing to the entire local prefix could create artificial bloat by forcing multiple /48's (or whatever) where a single default would have worked. Dan Lanciani [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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
for his own internal site. Backdoor connections between links will |also work, if a /48 route is announced for the backdoor. But I don't want to route only to a handful of specific /48s. I want to route all (or at least most) of the GUPI space to a tunnel server that will (try to) dynamically create a path to the target network using some out-of-band lookup mechanism. If I can do that by installing 4 /9's then I'm happy, but you haven't accomplished much beyond making the black hole turn-off switch slightly more complicated than it needs to be. If you are going to require something as specific as a /48 to escape the black hole (and that's exactly where this proposal seems to be going) then you are creating an artificial barrier to an overlay network by forcing unnecessary routing table growth in interior routers. Dan Lanciani [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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Alan E. Beard [EMAIL PROTECTED] wrote: | |in the case you propose above, even if the black hole is | |universally implemented, two 'permit' statements, each for a /8 block | |(assuming we use the Hinden proposed address space block) would solve this | |problem. | | This is inconsistent with your requirement that ``Router manufacturers | MUST ensure that said black hole cannot be deconfigured, turned off, or | otherwise overridden in toto;'' You are now saying that all it takes to | override the black hole in toto is two more specific routes for the two | halves of the address space. As soon as this is pointed out someone will | insist that the overriding routes must have some absurdly large prefix length, | e.g., /48. | | |The language concerning what may be required to configure partial override |for the black hole was quite deliberately crafted so that several |interpretations are possible; We aren't talking about a partial override. We are talking about a complete override which your wording clearly prohibits. If that isn't what you mean then change the wording. Dan Lanciani [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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Alan E. Beard [EMAIL PROTECTED] wrote: [...] |Additionally, such a suggestion, if implemented, would effectively |prohibit one of the chief *legitimate* uses of GUPI address address |allocations: routing between private networks on private (or VPN) links |under bilateral agreements between the end networks. [...] |* Manufacturers of routers MUST include in router code a routing black |hole for the entire unique-local address block. Router manufacturers MUST |ensure that said black hole cannot be deconfigured, turned off, or |otherwise overridden in toto; Please don't do this. I don't want to have to special-case all my interior routers (that could otherwise get by with simple default routes for much of the outside world--including tunnels to other GUPI address space) for each tunnel that might be available at the edge routers. This will be even more of a problem once we start to set up dynamic tunnels so that a large set of GUPI-using-sites can communicate in a cooperative overlay network. There is no way to know whether a router will be used at the edge where you *might* have some business enforcing such a black hole or deep inside where you have absolutely no business complicating my routing. |however, manufacturers MAY provide a |configuration facility to punch through the black hole for |user-specified prefixes within the unique-local block. But I will probably want to send the *whole* unique-local block to a tunnel router of some sort. |Router |manufacturers SHOULD include in user documentation language to the effect |that routing of unique-local prefixes beyond site boundaries contravenes |IETF recommendations, Above you said that routing between private networks was legitimate. This certainly involves routing beyond site boundaries. We need to make it clear that beyond site boundaries does not equate to on the public internet. Dan Lanciani [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: Solving the right problems ...
Jeroen Massar [EMAIL PROTECTED] wrote: |The stack/API then maintains a list of routing IP's that |are associated by that IdentifierIP and then replaces it |before it enters the network with the routing IP that is |to be used for actually routing the packet. I've made this proposal several times over the past few years. It was generally met with violent objections that we have no idea (and--it seems-- can have no idea) whether the mapping infrastructure is even a design target or a research project. Most recently I believe the objection was that hosts have no business computing routes (and that is what you are talking about-- your mapping is just another way of looking at source-based routing) since they do not have full knowledge of the entire network topology. Of course, I consider the latter a huge advantage because distributed routing scales so well: the resources available (including both CPU power and aggregate bandwidth) increase with the increasing number of nodes which in turn grows with the number of identifiers. The last time I tried to point out the desirability of such a scalable solution, I believe it was dismissed with something along the lines of, ``the application sees zero bandwidth while its host is trying to compute a route to the destination''. In any case, I wish you better luck with the approach than I've had. But I don't think you will get very far for the simple reason that a working identifier scheme destroys the economic value of stable addresses and would allow customers to switch ISPs too easily. Tony Hain [EMAIL PROTECTED] wrote: |So you prove my original point, 'there is a sacred invariant, and we must |avoid messing with the app / transport interface at all costs'. As a practical matter, this is probably true. Dan Lanciani [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: IPv6 Link-Local Use Issue for Applications
Hans Kruse [EMAIL PROTECTED] wrote: |I think the following rules should go with this approach: | |- Assume DNS returns both PA and PUPI, then | if my node only has PUPI, I select the advertised PUPI, | if my node has a PA, I select the PA being advertised. I assume that the only above implies that if you have both PUPI and PA addresses you wish to select the PA address? If so, this defeats the goal of quasi-automatic connection stability in the face of changing PA addresses. It would require setting up separate DNS entries with only PUPI addresses in order to force a stable connection. |- Obviously, if DNS only returns PUPI and I have both, I use PUPI, | and use PA if DNS only returns PA and I have both. | |- If there is no match (I have only PUPI and DNS returns PA, or vice |versa), I would suggest to fail the connection by default (even though it |might work), but I am not sure. As long as this default can be changed without the cooperation on the applications (i.e., a global option for the stack) it would be ok... Dan Lanciani [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: Real life scenario - requirements (local addressing)
Pekka Savola [EMAIL PROTECTED] wrote: |On Thu, 7 Aug 2003, Andrew White wrote: [...] | Real example: My ISP's DSL connection decides to drop the connection and | reconnect (with a new IPv4 address, and thus 6to4 prefix) every 1-3 hours. | I'd rather not subject my internal network to that if I don't have to. | |Switch ISP or complain to them. I certainly wouldn't bear with that kind |of behaviour. It isn't clear that there will always be another ISP to switch to... |If that kind of ISP techniques are commonplace, we may need to do |something. But I'm not sure if that's the case. Experiences? I've brought up the notion of getting ISPs to change this business model before. Since the IETF can't mandate business models, any pressure would have to come from the technical side. |Note: consider how many of these techniques are used to prevent people |from keeping servers at their home systems (i.e., does the ISP consider |the changing address a bug or feature). Given that forcing the address changes often requires extra work on the part of the ISP (and you occasionally see requests from ISP folks for better ways to shorten the address cycle :() I would assume that most of this activity is designed either to discourage servers or simply to create additional artificial levels of service. |Also consider how the situation |would change (if any) with IPv6 provided by the ISP. Why should it change at all? Similarly, why should the number of addresses provided change? ISPs that currently seek to detect and prevent NAT activity are not doing so out of a sense of architectural purity. Dan Lanciani [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: Moving forward on Site-Local and Local Addressing
Bound, Jim [EMAIL PROTECTED] wrote: |The hinden draft has no impact because of scoping at all technically |for implementation that was the point. So the problem is far simpler |and why it is good solution. | |What scoping issue do you see? I didn't say I see a scoping issue. I see an issue with removing site-locals without first providing a replacement that offers the same (or greater) capabilities. This is particularly important because there is no clear agreement on what capabilities site-locals currently offer. Many site-local detractors argue that site-locals don't provide any legitimate capabilities at all, presumably because scoped addressing is not itself legitimate. If site-locals are removed before we see their replacement, I have every expectation that some folks will argue (loudly) that the correct replacement is no replacement. In the less extreme case, it seems that subtle combinations of the random restrictions being suggested for replacements may thwart one or more of the uses that I expected for site-locals. Finally, I'm concerned that any solution might be seen as necessary only for the mythical enterprise and thus be cost- prohibitive for the small business and home user. We really need so see the replacement first... Dan Lanciani [EMAIL PROTECTED] |/jim | | -Original Message- | From: Dan Lanciani [mailto:[EMAIL PROTECTED] | Sent: Monday, August 04, 2003 3:52 PM | To: [EMAIL PROTECTED] | Subject: Re: Moving forward on Site-Local and Local Addressing | | | |C) Deprecate Site-Local addresses after an alternative is defined, | |standardized, and in operational practice. This would mean | not advancing a | |deprecation document until there was operational evidence that the | |alternative was working and shown to be an improvement over | Site-Local | |addresses. | | | |Note: In the above choices Deprecate Site-Local addresses means | |publishing an RFC that does the formal deprecation. | | | |Please respond to the list with your preference, or if there is an | |alternative approach that is an improvement from the ones I | outlined. I | |hope that many of you will respond. | | I vote for C. Given the disagreement on the legitimate | uses of site local addresses (and scoped addressing in | general) it will be difficult to be sure that a replacement | actually solves all the problems that everyone concerned | expected site-locals to solve, and does so in a way that is | not prohibitively difficult/expensive to deploy. | | Dan Lanciani | [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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= [EMAIL PROTECTED] wrote: |On lördag, apr 5, 2003, at 22:24 Europe/Stockholm, Dan Lanciani wrote: | | -When (and how) did site-locals become the main obstacle standing in | the | way of solving the routing/identifier problem? | | -When (and how) did all the other reasons that have been advanced to | stymie | any work on the routing/identifier problem evaporate? | |rant | From my point of view, as an apps person, people stopped looking at |these alternatives when they found out they can force applications to |have clue about routing topologies, force applications to use this clue |to do clever source address selections, and more people started |thinking Site Local was not only a solution to this, but also the magic |pixie-dust which solves other problems as well. |/rant I understand why you might think that (especially given the recent discussions) but if you review the archives for the past few years I think you will see that site-locals did not play a significant role in discouraging the development of real routing/identifier solutions. Frankly I find it really disturbing that the issues are being coupled this way. Dan Lanciani [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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= [EMAIL PROTECTED] wrote: |On lördag, apr 5, 2003, at 00:37 Europe/Stockholm, Dan Lanciani wrote: | | Great. Let's make this PI space available FIRST and THEN we can get | rid | of site-locals with little trouble. | | |Yes, aggregation can not happen, | |but, so what? I claim the number of routes today is still manageable, | |and the _real_ problem is that an IP address is both for addressing | and | |routing. | | Great. Let's work on that problem now. | |Yes, of course we should. But, I think we can not get real force behind |such work before we _first_ agree Site Local is not solving this |problem, and we therefore agree Site Local should go away. Please help me to understand something. I have been trying to get people to look at the portable identifier/routing problem for _years_. Such attempts have been consistently shot down, often on grounds similar to the ones being used to attack site-locals, e.g., that we don't understand the problem well enough to even know whether research or engineering is required. (And no, I don't really understand why this--even if true--is a reason to not look at a problem. But that's a different question.) In fact, I believe some of the same people who want to deprecate site-locals are making the same arguments they used against solving the routing problem. Now, in all those years, nobody ever raised the claim that site-locals were an obstacle to working on the routing problem. Explain two things: -When (and how) did site-locals become the main obstacle standing in the way of solving the routing/identifier problem? -When (and how) did all the other reasons that have been advanced to stymie any work on the routing/identifier problem evaporate? Dan Lanciani [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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
Mika Liljeberg [EMAIL PROTECTED] wrote: | Great. Let's work on that problem now. | | Yes, of course we should. But, I think we can not get real force behind | such work before we _first_ agree Site Local is not solving this | problem, and we therefore agree Site Local should go away. | |Forgive me for being cynical, but another way to phrase the above is |that the intent is to deny an existing solution to people who are |content with it in order to force them to work on a new one. You aren't being cynical enough. Once site-locals are gone there is absolutely no reason to believe that there will be any work on a new solution. We have had years and years to work on the routing/identifier problem and it has gone nowhere. The new solution for stable internal connections is going to be the same as the recently proposed solution for multi-homing: send more money to your ISP and they will make their links more reliable and refrain from renumbering you as frequently. Dan Lanciani [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: Why I support deprecating SLs
Leif Johansson [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | |What makes you think that the apps people who say it *will not work* are |correct? Especially when they are talking about models that are already in |use? | | | |Which models would that be exacly? Please re-read the message to which you initially responded. |I hope you are not talking about the lets |run-everything-over-http-model... I see no mention of such a thing anywhere in this thread. |The bottom line is that lots of |applications |are impossible to deploy on the Internet today because of rfc1918. Hardly. There are a few (not lots of) applications that are more difficult (not impossible) to deploy on the Internet today because of a restrictive address assignment policy (not because of rfc1918). Think about it. If there were no private address space and the nodes that currently use rfc1918 addresses had *no* addresses at all would they be able to run your hypothetical applications any better? Private address space and NAT are the effects--not the causes--of a restrictive address allocation policy. Would you deprive people of the address space they need to run the applications they need to run just to make it easier to write some other super-apps that those users don't care about? Dan Lanciani [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: Why I support deprecating SLs
Leif Johansson [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | |the causes--of a restrictive address allocation policy. Would you deprive |people of the address space they need to run the applications they need to |run just to make it easier to write some other super-apps that those users | | | |No I want people to have global addresses! That may be what you want, but that is not what you have been saying. You are advocating taking away private address space. Contrary to recent popular (yet incomprehensible) thought these actions are not equivalent. How about you FIRST give people global addresses and THEN AFTER those people see that those addresses have the properties that they need in order to use their networks you can take away their private addresses? I'm sure that most people will willingly give up their private address space AFTER they have globals with the same (or better) level of stability. Dan Lanciani [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: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
of the network, there is no reason why |they need to be ambiguous. The ambiguity of site-locals creates a great |deal of complexity, and imposes unnecessary limitations on their use. Personally, I have no need for ambiguity. In fact, I would be happier with completely unique locals because then I can build a layer of routing on top of them with auto-tunnels. But again, I don't think that unambiguous addresses actually relieve you of the scoping problem. |-When (and how) did all the other reasons that have been advanced to stymie |any work on the routing/identifier problem evaporate? | |I never once suggested that there is a reason not to work on this |problem. In fact, I think that it is vitally important to solve |this problem, and people are working on it (in the IRTF and the |multi6 WG, among other places). If you have a viable proposal to |solve this problem, I'd love to see it. Check the archives. Dan Lanciani [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: Why I support deprecating SLs
Leif Johansson [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | |That may be what you want, but that is not what you have been saying. You |are advocating taking away private address space. Contrary to recent popular |(yet incomprehensible) thought these actions are not equivalent. How about |you FIRST give people global addresses and THEN AFTER those people see that |those addresses have the properties that they need in order to use their |networks you can take away their private addresses? I'm sure that most people |will willingly give up their private address space AFTER they have globals |with the same (or better) level of stability. | | |I was not aware that there was a problem getting global v6 addresses! |Please explain. |Or perhaps you are thinking about global addresses with certain |properties I think you know exactly what I am thinking about. |(provider |independence perhaps)? Please make the distinction for the sake of clarity. Re-read what I wrote above. Give them globals with the same (or better) level of stability as their private addresses. |BTW There is a flaw in your reasoning; people never give up any type of |addresses, |private or global. So how exactly do they hang onto non-portable global addresses they got from an ISP when they switch to another IPS? |Once products are shipping with support for v6 |private addresses |thats it. Private addresses won't go away if we let the cat out of the |bag now. Really? What happened to all those wonderful new applications that depend on eliminating private address space? You are saying that people will go on using private address space even if they have suitable globals? I guess that implies that they didn't really want those new applications after all... Dan Lanciani [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: Why I support deprecating SLs
Margaret Wasserman [EMAIL PROTECTED] wrote: |So, it is certainly safe to say that we don't have _any_ |proposal on the table for the usage of site-local addresses |that currently has WG consensus. So, what is it that you |think we are taking away? | |The proposal is to deprecate a prefix in the addressing |architecture for which we have found no suitable use. My mistake. I thought we were voting on something more meaningful, i.e., site-locals themselves. Now I understand that site-locals do not exist as such and we were just voting on the deprecation of the prefix itself. This actually makes it all the more amazing that anyone would claim that the mere existence of that prefix in an undeprecated state is the stumbling block preventing us from solving the routing problem that has been around for a decade or so. As I'm sure the prefix will indeed be deprecated, I look forward to seeing serious discussions of those routing solutions very soon. Dan Lanciani [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: Why I support deprecating SLs
[This response was apparently lost, so I'm resending it.] Thomas Narten [EMAIL PROTECTED] wrote: |Dan Lanciani [EMAIL PROTECTED] writes: | | I can't speak for others, but to me it is very interesting (and | important) to have internal connections that are not at the mercy of | my ISP's renumbering policy. | |I agree that this is a very desirable property to have. But wanting |this doesn't mean we know how to achieve it. We know how to achieve it. You may not like the way we achieve it because it doesn't meet your standards for architectural purity, but until you have a better approach, how about letting use keep our impure solutions? | |The tough question is, how do we get applications in general to prefer | |SLs for local communication. | | If an application wants to maximize the stability of its connection | it always uses the addresses of smallest scope that will do the job. | |How do applications get addresses? In my experience, a lot of them get |them out of the DNS. But, if we put SLs into the DNS, we have to have |split DNS... As I explained below, you don't have to use split DNS. But people do use split DNS and if they are satisfied with the result, who are we to tell them to stop? This notion of giving up critical functionality today so that perhaps in the future we will get back some subset of that functionality in a more pure form just doesn't fly in the real world. | I believe that your assumption is false. If the 30% consists of a few | critical builds running over a remote file system, security information, | etc., while the 70% represents much less important traffic then there | could still be significant benefit. | |Fine. How do you ensure that the critical applications do in fact use |SL addresses? By configuring them to do so |How do you even know which ones are critical? Isn't |critical in the eye of the user? How do you know which machines need uninterruptible power supplies? How do you know which switches need redundant links to the backbone? You seem to be suggesting that a solution is no good unless the protocol automagically makes decisions about which applications are critical. In the real world, people make these decisions all the time. In the real world, people probably don't even _want_ your protocol to be making these decisions for them. | Well, personally, I'm getting a little tired of worrying about what | is and is not blessed. People will use what works. | |I take it from the above that you believe that making split DNS work |is trivial and obvious, so folks can and will just use it no |problem. I can't imagine why you would take it that way. Believe it or not, in the real world, people are sometimes capable of doing things that are _not_ trivial and obvious. Especially when they have no alternative. |My point is that the community doesn't seem to be in complete |agreement about that, which means there are almost certainly |subtleties and potential gotchas that can and will get in the way. The community is never in complete agreement about _anything_. There are always subtleties and potential gotchas. This is a characteristic of all but the most trivial systems. It is not an adequate reason to abandon a useful solution, especially when you offer no alternative. | That said, I see no need to use split DNS in order to benefit from | site-local's stable internal connections. As an example, my own | network already uses separate names for the automation services that | are accessed internally. Currently these are aliases for the global | v4 addresses of the hosts which support the services. Under v6 I | could change them to the site-local addresses of those same | machines. | |So, in your system you have two names for the same service, one for |the global address, one for the internal address? No, I have only one name for a given service and the services are available only internally. I have other names for the hosts that happen to run the services. Those names would continue to point to a global address in my v6 scenario (unless of course the machine had no global address at all). I would use the same name to, e.g., telnet to the machine from inside or outside. Telneting to the machine is not the kind of critical, long-term connection that I feel I need to protect from renumbering. Other sites might have different ideas about which connections are critical and they would configure accordingly. |And if you are |inside your site, you use the internal name, and when you are outside |you use the external name? No, because these services are internal-only. That's the whole point. |If this is the basic idea, I suspect most users won't like this |approach and will not consider it to have solved the problem |acceptably. I suspect that you suspect wrong. People are using these (or worse) models in conjunction with NAT. These models are well understood. If you do not wish to support them cleanly in v6 with scoped addresses people will use NAT
Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
Patrick wrote: [...] |An application *should*always* use the hostname when communicating, and |that imply it should not cache the IP address of the peers or itself |between the flows are initiated which it needs. Yes, applications fail |regarding this, and IP stacks are too bad at keeping the local IP |address which happen to be assigned at the time a listen call is |made. Application should be better at this, and I claim they _are_ |getting better as computers more and more move around already today |(due to DHCP, 802.11b etc). Ok, so let's fix all the IP stacks to use names in the packets and in their APIs. Then we can fix the DNS to track renumbering events. Once that is done we can get rid of site-locals for good. |The broken 5-tuple is not much we can do anything about, BUT, |site-local is not solving this problem either. Yes, I know the idea is |that when two nodes can share the site local scoping to minimize the |risk for the 5-tuple to break You are the third person in the last 24 hours to assert that site-locals cannot provide for stable internal connections. Such assertions (which are obviously based on unstated assumptions about how perfectly any such solution must work) are very disturbing. The deprecation of site-locals supposedly came with some vague assurance that we would look at alternate ways to provide the functionality that was being removed. It is far too convenient to say that in retrospect site-locals never did provide for stable internal connections and thus we need not consider a replacement (or, as others have claimed, that we don't even know how to provide a replacement). Moreover, I'm concerned that stable internal connections will join the growing list of features (including the high availability that should have come from multi-homing) whose recommended implementation reduces to: send your ISP more money. [...] |I rather see (in my possibly naïve view) sites like |this really getting PI address space. Great. Let's make this PI space available FIRST and THEN we can get rid of site-locals with little trouble. |Yes, aggregation can not happen, |but, so what? I claim the number of routes today is still manageable, |and the _real_ problem is that an IP address is both for addressing and |routing. Great. Let's work on that problem now. [...] |What one have to remember when talking about all of these problems is |how the Internet should work. Not how it is implemented today, because |things like NAT etc do exist, and yes, we will continue to see it for a |while. | |First of all, we have one big mistake regarding addressing, and that is |the overload of use of the IP addresses. We use it both as a unique |identifier of an endpoint and for routing. addressing != routing I have made proposals over the years for portable identifiers. Did you support them? |This has created the problems we have with the routing protocols of |today, as the Internet is no longer hierarchal. It is a mesh, a |complete mesh. And, when navigating a mesh, one need different |algorithms and mechanisms than when navigating a hierarchy. Site Local |will not solve this problem. Great. Let's fix the routing problem FIRST and THEN nobody will care about site-locals. |Secondly, the 5-tuple we use for flow identification is rigid, and we |don't accept a change of any of the 5 values without having an |interrupt in the flow. Maybe we should have some ICMP which say please |redirect flow to this address? How to secure it? Will Site Local solve |this problem? Don't think so... I can't imagine why you would even ask if site-locals would address this hypothetical issue in a hypothetical solution... [...] |Just Say No to Site Local. Why not try a more positive approach like, ``Just say yes to PI space.''? All of the things that you suggest have been proposed many times over the years. They are consistently shot down as impossible. In fact, it is common knowledge that merely talking about PI space can cause the immediate death of the net as we know it--unless of course you talk about PI in conjunction with the deprecation of site-locals. The it's ok because we know that once site-locals are gone we can forget about PI again... Dan Lanciani [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: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing)
Brian E Carpenter [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | Brian E Carpenter [EMAIL PROTECTED] wrote: | | |I think we should clear the desktop first, by getting rid of ambiguous | |site-local address space, and then discuss possible new solutions. | | Could you explain why you think this is the correct order? | |Because I can't see any other way of getting the WG out of |its perpetual discussion loop on this topic. Let me suggest a very simple way to do just that. Stop trying to eliminate site-locals and scoped addressing. Instead, apply your efforts to defining and standardizing the new/better mechanism(s) that will provide the same functionality. Once those new mechanisms have reached a level in the standards process sufficient to make folks comfortable that they are not just temporary diversions you will probably find it much easier to eliminate site-locals. |If we can agree to deprecate ambiguous SLs, we can then |invent a non-ambiguous replacement for the next version of the |addressing architecture. Agreeing to deprecate site-locals is neither necessary nor sufficient to allow us to invent a replacement. By implying this condition you are perpetuating the discussion loop that you seek to break. Dan Lanciani [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: Charge for traffic, not IP addresses (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
Jeroen Massar [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | Jeroen Massar [EMAIL PROTECTED] wrote: | | |[EMAIL PROTECTED] wrote: | | | | NO - Do NOT Deprecate Site-Local Addressing. | | | | There are reason to use site-locals, and reason NOT to use | them. But | | FORBIDDING people will only alienate them and lead them to | | find ways to do it anyway. | | | | Perfect example, when (or should I say IF) my home ISP goes | | to IPv6, they charge per IP. Always have, and always will. | | Sure, they will gladly give me a range of IPs, as well as | | gladly charge me as if each were a PC. Also, | | when I get tired of putting up with the abuse from this | | particular ISP and decide to choose another ISP to abuse me, | | I will still have the same issue. | | | |Very good example that you don't get it at all. | |ISP's should be charging for traffic, not for IP's. | | So why don't you make the ISPs work the way you think they should? | Then NAT would go away and you wouldn't have to try to ban it. NAT | is the effect, not the cause. | |That's the IPv4 world. The ISP's will have to get inside |their heads that IP space is not 'scarce' anymore. I'm sorry, but you simply do not understand the business model used by the vast majority of ISPs in (at least) the US. ISPs do not charge for IP addresses because of their (largely artificial) scarcity. ISPs use the number of addresses as a surrogate measure of bandwidth. ISPs use the stability of addresses to control what they perceive as higher-use (= higher cost) activity such as running a server. Many ISPs also charge for addresses simply because they can. |Fortunatly most RIR's will tell them that when they |request an allocation and I even suspect that when an ISP |get 'caught' for not passing out the correct bits down |to their clients that they can be requested to return |their allocation as they are not using it anyways. Now I really have to wonder if you are joking... |The IPv4 mentality should go. IPv6 != IPv4 fortunatly ;) Charging for addresses has nothing to do with an IPv4 mentality. It has to do with a business model. There is absolutely nothing in IPv6 that would cause this business model to change. Dan Lanciani [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: Why I support deprecating SLs
Thomas Narten [EMAIL PROTECTED] wrote: | |Thomas Narten [EMAIL PROTECTED] wrote: | | | | - Site-locals should be retained as a means for internal | | connections to survive global prefix renumbering. | | | |4) This is strikes me as a nice requirement, but something we don't | | have a solution for, even with SLs. We need to accept that we have | | no solution and SL is doesn't really seem to be a help here. | | Please explain why you feel that internal connections using site-locals will | not survive global prefix renumbering. | |Internal connections using SLs will survive renumbering. But that is |the easy part and by itself is largely uninteresting. I can't speak for others, but to me it is very interesting (and important) to have internal connections that are not at the mercy of my ISP's renumbering policy. |The tough question is, how do we get applications in general to prefer |SLs for local communication. If an application wants to maximize the stability of its connection it always uses the addresses of smallest scope that will do the job. Hasn't this been the idea behind scoped addressing from the beginning? I realize that there have been suggestions recently that you should always use a global address if one is available, but that's not a problem with scoped addressing--it's a way to deliberately break scoped addressing. |Note that it is not enough for a handful |of applications to use SLs and survive renumbering, my assumption is |you want pretty much all intra-site communication to use SLs. I.e., if |only 30% of your intra-site traffic is using SLs, and a renumbering |takes place, 70% of your traffic is still potentially impacted. That |doesn't seem like much of a real solution to me. I believe that your assumption is false. If the 30% consists of a few critical builds running over a remote file system, security information, etc., while the 70% represents much less important traffic then there could still be significant benefit. |I have yet to see what I believe is a credible approach to getting |applications to prefer SLs across the board. Some people suggest we |need to do split DNS. But their is no real consensus in the community |for doing this. For example, I'll note that the DNS community has |never been willing to officially bless split DNS behavior. They |understand folks use it, but there are problems with the approach, and |the DNS community has never had consensus that the benefits outweighed |the problems. Hence, no IETF spec officially advocates split DNS, |AFAIK. So, approaches that rely heavily on split DNS being even more |widely deployed that it is already (e.g., in homes and other places |with no clueful operations support) seems like an uphill fight at best Well, personally, I'm getting a little tired of worrying about what is and is not blessed. People will use what works. That said, I see no need to use split DNS in order to benefit from site-local's stable internal connections. As an example, my own network already uses separate names for the automation services that are accessed internally. Currently these are aliases for the global v4 addresses of the hosts which support the services. Under v6 I could change them to the site-local addresses of those same machines. All my automation services would then be protected from ISP renumbering. I can do something similar with file servers. And please let's not get into a debate about the impurity of using different names to reference different addresses on a single machine. We were doing that long before the DNS existed. |So, IMO, the notion that SLs protect a site agains the impact of a |renumbering event is one of those IPv6 myths for which there is no |real story to back up the desire. I wish it were otherwise. It is true that site-locals do not by their mere existence automatically protect a site against renumbering, but that is a straw man. Site-locals allow a site that cares to protect connections that it cares about. This is an important capability. Do not be so quick to dismiss it. Dan Lanciani [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: Why I support deprecating SLs
Margaret Wasserman [EMAIL PROTECTED] wrote: |I realize that there |have been suggestions recently that you should always use a global address if |one is available, but that's not a problem with scoped addressing--it's a |way to deliberately break scoped addressing. | |It is also a way to avoid breaking Mobile IP. In a killing-ants-with-cannons sort of way... |It is true that site-locals do not by their mere existence automatically |protect a site against renumbering, but that is a straw man. Site-locals |allow a site that cares to protect connections that it cares about. This |is an important capability. Do not be so quick to dismiss it. | |Do you really need site-local addresses as currently defined |(ambiguous, scoped address) to achieve this? It is clear to me that nothing I would want from site-locals requires ambiguity. The scoping question is more difficult to answer. You need to be able to be sure that both ends of the internal connection use the stable addresses. You can control the destination address by using different name for different addresses; however, without scoping and without access to the application source code you may not be able to control the source address. The intuitively obvious choice of source address (closest match to destination) works, of course, but I would be concerned that this might not happen exactly because of thinking like yours above. That is, someone will do something ``to avoid breaking Mobile IP'' or such and in the process break local connections. |Or would it be |better to have your own globally-unique, provider-independent |prefix (perhaps assigned by a registry) that wouldn't require |any special treatment from hosts, applications, etc. and that |you could choose to filter at your firewalls? Give me that prefix and tell me how source address selection works and I'll let you know. In the meantime, site-local addresses as currently defined are the only solution that is currently defined... Dan Lanciani [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: Why I support deprecating SLs
Thomas Narten [EMAIL PROTECTED] wrote: |Dan Lanciani [EMAIL PROTECTED] writes: | | I can't speak for others, but to me it is very interesting (and | important) to have internal connections that are not at the mercy of | my ISP's renumbering policy. | |I agree that this is a very desirable property to have. But wanting |this doesn't mean we know how to achieve it. We know how to achieve it. You may not like the way we achieve it because it doesn't meet your standards for architectural purity, but until you have a better approach, how about letting use keep our impure solutions? | |The tough question is, how do we get applications in general to prefer | |SLs for local communication. | | If an application wants to maximize the stability of its connection | it always uses the addresses of smallest scope that will do the job. | |How do applications get addresses? In my experience, a lot of them get |them out of the DNS. But, if we put SLs into the DNS, we have to have |split DNS... As I explained below, you don't have to use split DNS. But people do use split DNS and if they are satisfied with the result, who are we to tell them to stop? This notion of giving up critical functionality today so that perhaps in the future we will get back some subset of that functionality in a more pure form just doesn't fly in the real world. | I believe that your assumption is false. If the 30% consists of a few | critical builds running over a remote file system, security information, | etc., while the 70% represents much less important traffic then there | could still be significant benefit. | |Fine. How do you ensure that the critical applications do in fact use |SL addresses? By configuring them to do so |How do you even know which ones are critical? Isn't |critical in the eye of the user? How do you know which machines need uninterruptible power supplies? How do you know which switches need redundant links to the backbone? You seem to be suggesting that a solution is no good unless the protocol automagically makes decisions about which applications are critical. In the real world, people make these decisions all the time. In the real world, people probably don't even _want_ your protocol to be making these decisions for them. | Well, personally, I'm getting a little tired of worrying about what | is and is not blessed. People will use what works. | |I take it from the above that you believe that making split DNS work |is trivial and obvious, so folks can and will just use it no |problem. I can't imagine why you would take it that way. Believe it or not, in the real world, people are sometimes capable of doing things that are _not_ trivial and obvious. Especially when they have no alternative. |My point is that the community doesn't seem to be in complete |agreement about that, which means there are almost certainly |subtleties and potential gotchas that can and will get in the way. The community is never in complete agreement about _anything_. There are always subtleties and potential gotchas. This is a characteristic of all but the most trivial systems. It is not an adequate reason to abandon a useful solution, especially when you offer no alternative. | That said, I see no need to use split DNS in order to benefit from | site-local's stable internal connections. As an example, my own | network already uses separate names for the automation services that | are accessed internally. Currently these are aliases for the global | v4 addresses of the hosts which support the services. Under v6 I | could change them to the site-local addresses of those same | machines. | |So, in your system you have two names for the same service, one for |the global address, one for the internal address? No, I have only one name for a given service and the services are available only internally. I have other names for the hosts that happen to run the services. Those names would continue to point to a global address in my v6 scenario (unless of course the machine had no global address at all). I would use the same name to, e.g., telnet to the machine from inside or outside. Telneting to the machine is not the kind of critical, long-term connection that I feel I need to protect from renumbering. Other sites might have different ideas about which connections are critical and they would configure accordingly. |And if you are |inside your site, you use the internal name, and when you are outside |you use the external name? No, because these services are internal-only. That's the whole point. |If this is the basic idea, I suspect most users won't like this |approach and will not consider it to have solved the problem |acceptably. I suspect that you suspect wrong. People are using these (or worse) models in conjunction with NAT. These models are well understood. If you do not wish to support them cleanly in v6 with scoped addresses people will use NAT (unless you give them PI addresses). If you also manage
Re: alternatives to site-locals? (Re: CONSENSUS CALL: DeprecatingSite-Local Addressing)
Brian E Carpenter [EMAIL PROTECTED] wrote: |I think we should clear the desktop first, by getting rid of ambiguous |site-local address space, and then discuss possible new solutions. Could you explain why you think this is the correct order? To me it seems completely wrong. Eliminating site-locals will probably require changes in much the same areas that any new solution will require. Why edit everything twice? Once site-locals are gone there will be very little incentive for those who dismiss their uses to look at alternate solutions since they do not recognize the associated problems as problems. Dan Lanciani [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: CONSENSUS CALL: Deprecating Site-Local Addressing
NO -- Do not deprecate site-local unicast addressing. Dan Lanciani [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: avoiding NAT with IPv6
I've noticed a common theme in many of these anti-NAT dissertations: the stupid NAT user is using NAT for stupid reasons and if we merely educate him and/or force her to stop using NAT the world (and the particular user) will be oh so much better off. You will not eliminate NAT by repeatedly telling its users that they are misguided idiots. A new generation of NAT-hostile peer-to-peer applications is neither necessary nor sufficient to eliminate NAT. Many users couldn't care less about these wonder-apps and for those who have a legitimate need, the market will provide a NAT-friendly alternative. MUST NOTs in RFCs are not going to stop NAT. Eliminating NAT is actually very simple. All you have to do is give users that which by its lack drove them to use NAT in the first place: plentiful, free, stable address space. I conclude from the effort that folks are putting into discussing other (pointless) ways to mandate NAT away that they in fact agree with my prediction that v6 ISPs will not magically change their business models and offer such address space freely. As long as address space and stability remain profit centers, you will not be able to eliminate NAT. |These enterprises apparently don't want/require/need global |reachability for their hosts. Otherwise they would not NAT. Is that really apparent? They might be using NAT exactly because they want global reachability for their hosts but cannot afford to rent enough global IP addresses. Or perhaps their ISP won't offer them additional global IP addresses at any price. Or perhaps they cannot cope with constant changes in the ISP's dynamic addressing disrupting their internal connections. Or perhaps they simply want to be able to change ISPs without the extreme pain of renumbering. Or perhaps they implement a poor-man's multi-homing solution to provide higher availability (though not connection survival). |IMHO the real solution to this and some other problems we |are currently seeing in IPv6 is really one thing which |must be solved before anything else: IPv6 Multihoming I wouldn't count on this for much help. The multi group was in effect tasked with solving the multi-homing problem without solving the portable identifier problem in general. Even if they fail and are forced to solve the portable identifier problem (assuming they solve anything) their solution can easily be restricted to sites paying for connections to multiple ISPs. In any case, don't you think it's a little late in the game to keep putting off solving the problem in hopes that a solution will appear as a side-effect of some other effort? Especially when that effort is stalled? |Another solution could be a good document outlining all |the problems along with possible solutions when a network |gets renumbered. IP renumbering isn't that much of a problem |but renumbering the configuration items which contain IP's is. So in other words, IP renumbering *is* that much of a problem... Dan Lanciani [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: Enforcing unreachability of site local addresses
Alan E. Beard [EMAIL PROTECTED] wrote: |Yes, I think you are probably right in speculating that any technically |sound mechanism which preserves the virtues of provider independence, |portability, and stability in configuration of end-user-network devices |will satisfy the functional requirements of the end-user community. It |seems to be up to us to architect the mechanism(s). Any thoughts on how we might jump start some activity in this area? Over the years I've tried the bottom-up approach by suggesting some possible mechanisms, and I've tried the top-down approach by suggesting that we try to reach consensus on how much overhead we are willing to accept in return for the solution. The former generally provokes protests that the solution is too complicated to sketch and the latter usually results in silence. How can we get some serious discussion going? If we do stick our heads in the sand (again) and pretend that provider-based hierarchical address allocation is temporary (again) then history will likely repeat itself. There will be a little v6 swamp to accommodate some edu sites and those enterprises that are big enough to demand real multi-homed support, but the rest of us will be stuck with the same kind of unstable/non-portable addresses we have today in the post-aggregation v4 world. IMHO, any solution that attacks the problem by slightly shifting the demarkation point so that enough large enterprises can have PI space to make v6 appear commercially viable is a sham. We cannot afford to defer support of the small- and home- office environment forever. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Brian E Carpenter [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: |... | |I wasn't around then, but from what I have been told and read I think | |everyone was very aware of the scaling issues. But decided to put them | |forward and buy time. | | Well, I was around and I don't recall any major concern. | |This is hard to reconcile with some of the words in RFC 1380, |or what I remember when I first arrived in late 1992. IMHO, by the time 1380 was published in 1992, RFCs were not quite the reflection of community feeling that they had once been. RFC1380 was an attempt to highlight the problem and encourage the concern as much as it was an expression of that concern. Note that while 1380 does brief lip service to other possible solutions (including a distributed one!), it quickly concludes without proof that aggregation must be part of any long-term solution. At least that's the most obvious reading of a sentence that isn't quite English... |My recollection |is of a consensus to buy time with CIDR. There was a consensus to use provider-based hierarchical allocation as a temporary fix for a projected problem. Unfortunately, there was some confusion about how much time we were trying to buy and exactly what we were buying that time for. Initially the plan was presented as just that: hierarchical *allocation* by providers to end users. The addresses so allocated were to be portable and were to belong to the end user. The theory was that this would slow routing table growth, but would ultimately put us right back where we started once enough people changed providers and took their addresses with them. This scheme was perfectly consistent with the notion of buying time and it was not going to be a serious burden for end users. Very soon the allocations from providers turned into loans (or, at the low end, rentals). It was quickly pointed out that the original notion of letting users take their addresses with them didn't scale. Suddenly we weren't just buying a little time, we needed to buy indefinite time until some new routing mechanism could be implemented. But since provider control of addresses worked out so well (at least for everyone but new end users) we never saw much effort go into developing that new routing mechanism. Eventually it turned out that what had really been meant by buy time was to put off the problem until a new next generation protocol suite could be built. There had never been any intention to return to portable v4 addresses. At least not in retrospect. Now here we are a decade later deploying the next generation of IP and we just need to buy some time with provider-based hierarchical address loans. What have we done with all the time we already bought? We didn't do anything to restore portable v4 address allocations. We have a new protocol suite, but it suffers from exactly the same limitation in this respect as v4. What will we do with more time? Some people are quick to point out that we don't have a clue how to solve the problem and that we don't even know how we should be approaching it. If this is true then we might as well be honest and admit that we aren't just buying time anymore: IPv6 really is just IPv4 with more address bits. |(Just as PA addressing in IPv6 |buys time; this was in fact strongly debated during the formative |stage of IPng in 1993/94.) Yes, it was strongly debated. Given how long it has taken for v6 to go anywhere, the arguments that there just wasn't time to do anything better initially look less than convincing. In retrospect. I would like to know specifically for what we are buying time with PA addressing in v6, and just how much time we are trying to buy. Absent a visible plan it seems that we will merely repeat the v4 scenario. We will buy time with PA addressing until there is no longer any possibility of getting rid of it. Contrary to the popular quip, it is not easier to go from aggregated to non- aggregated than the reverse--especially if the transition requires any change in the deployed code. | We were aware | that there might ultimately be a problem but we were much more open-minded | about solutions relying both on faster hardware and on new protocols. I | think that's why some (a lot?) of us were more than a little annoyed at | being sandbagged by the CIDR two-step. What was supposed to be a temporary | fix quickly evolved into the effective extinction of new portable addresses. | Since then, hierarchical allocation has become so ingrained that some people | have trouble even conceptualizing other solutions. | |It's true that RFC 1380 assumed hierarchical allocation. But it also |clearly expressed the distinction between interim solutions (specifically |CIDR) and the long term. It made a distinction between the solutions and then asserted without evidence that any long-term solution had to involve aggregation. By strange coincidence that was the short-term solution as well. I'm sure we could argue the exact
Re: Enforcing unreachability of site local addresses
Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: | But, doing this would put research efforts to a halt. 10 years down the | |On the contrary. It will buy us time and give us experience. And besides, a looming deadline might accelerate rather than halt research. Currently solutions to the renumbering/allocation/aggregation problem get very low priority exactly because of dependency on the PA hack. Hmm, for that matter, where is all this research that we are worrying about halting? | 10 or 15 years ago, we gave away swamp space to anyone that wanted it | because nobody thought that it would ever have a scalability issue. 4 | |I wasn't around then, but from what I have been told and read I think |everyone was very aware of the scaling issues. But decided to put them |forward and buy time. Well, I was around and I don't recall any major concern. We were aware that there might ultimately be a problem but we were much more open-minded about solutions relying both on faster hardware and on new protocols. I think that's why some (a lot?) of us were more than a little annoyed at being sandbagged by the CIDR two-step. What was supposed to be a temporary fix quickly evolved into the effective extinction of new portable addresses. Since then, hierarchical allocation has become so ingrained that some people have trouble even conceptualizing other solutions. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Tony Hain [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | Tony Hain [EMAIL PROTECTED] wrote: | | |Suspend disbelief for a moment, and consider a name | resolution service | |where the consumer edge widget was responsible for both tracking | |topology changes, and updating a branch of the name tree to keep it | |aligned. Said widget would need a secure mechanism to graft | itself to | |the name tree after an address change, but otherwise might | look like a | |typical DNS server. [...] | | It's not much of a suspension. I've been saying for years | that exactly such a mechanism is necessary to push the | routing task out to the end nodes where ample resources will | be available. If it isn't done at some other level it will | have to happen in the DNS. However, I believe that the DNS | is the wrong place for it. | |There is an important difference between pushing all the way to the end |system, vs. the edge router. While architecturally there is little |difference, when the mapping function is in the end system the level of |churn on the registration infrastructure is substantially higher. Why? The level of churn is determined by how often you renumber, not by where you translate the identifier to the locator. |Moving |that to the consumer edge/set top provides both a platform that is |generally more stable in its availablity, as well as an aggregation |point for the bulk of the device churn. My proposal works equally well in end nodes or in edge routers. Obviously you get somewhat more benefit from a shared cache on the edge router, but you seem to be saying something more significant is going on. | |Given that as a | |starting point, there is no obvious reason that using name | strings as | |the identifier is more difficult than any other approach. | | Using name strings may be no more difficult with respect to | the implementation of the name service, but it leverages far | less existing code than would a fixed- length binary | identifier. | |Existing code is not a reasonable argument to justify the architectural |change of inserting an additional name service into the system. Is existing code a reasonable argument for sticking with the current system? Inertia seems to be the justification for much of what we have. Any new system that required wholesale changes in higher layers would be shot down for just that reason. You can't have it both ways. | Consider the advantages of using an identifier | that has exactly the same format as what we currently call an | address, i.e., 128 bits. With translation happening near the | bottom of the IP layer, no changes would be necessary in tcp | or in applications. | |Unless the application was trying to associate the source address of the |packet with something it knows about. This doesn't make any sense. The applications never see anything but the portable identifiers. |If there is a 'transparent' |mapping function in the system, apps that expect that service will |break. Applications won't expect anything. If this system were implemented it would simply replace what we currently call addresses with portable identifiers. |If such a mapping service is to work with said apps, there needs |to be a mechanism to distribute the mapping table with some level of |authenticity. Not the table, just the entries that are of interest to particular consumers. Why do you believe that this is any more difficult than what DNS is currently expected to do? |If you are talking about essentially in-line encaps like |8+8, every routing edge would need to map the source locator as well as |destination. Yes, of course the source has to be mapped as well. There are different ways to handle this, perhaps avoiding the overhead of explicitly carrying around both values. See my original notes in the Sep. 99 archives for some possibilities. | The problem of tcp connections | (not) surviving renumbering would disappear. The DNS would | work just the way it is, so no duplicate effort would be | required. | |Wait, a string to string translation happens in the DNS, then you claim |another string to string translation is not a duplicate effort !?!?! No, you are completely missing the point. If the fast-changing mappings are handled in a separate 128b-128b transformation (one perhaps optimized just for this purpose) then there is no need to fix the existing DNS to deal with fast-changing mappings. The DNS would continue to hold long-term mappings (from name to portable identifier) which could continue to be updated with the existing semi-manual process. The duplicate effort that is avoided is that of enhancing the DNS to deal with fast-changing dymanic mappings. |The request/response is not the problem. Explain how it handles a |scalable, secure update as nodes move between 802.11 hotspots of |different providers. You are introducing a different problem. I proposed only to fix the aggregation/allocation/renumbering mess. I said
Re: Enforcing unreachability of site local addresses
David Conrad [EMAIL PROTECTED] wrote: |On Friday, January 31, 2003, at 11:27 PM, Dan Lanciani wrote: | |Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?. | Sure, this has been proposed before, but I think the main complaint was | that 64 bits is no longer enough for the wasteful allocation policies | we | have adopted. | |Given there is no need for hierarchy, there is no need for wasteful |allocation policies (the end point addresses could be allocated |sequentially FCFS or even randomly). I have a bit of trouble believing |18,446,744,073,709,551,616 sequentially assigned addresses would be |insufficient for the foreseeable future. I was actually referring to the practice of inserting 48-bit (or even 64-bit) hardware identifiers into the address in the name of easy configuration. | |No translation would be necessary. | You have to translate somewhere, if not at the bottom of the host's | stack | then at what you are calling edge routers. | |I guess it is a question of terminology: there is no translation done |on the end point identifiers, thus they can be encoded into higher |layer protocols (e.g., ftp) without need of NAT gymnastics. The only |translation done would be the zeroing out of the high order 8 bytes |on reception at the destination edge router which would presumably be |faster than a table lookup. Even if you don't consider the zeroing a translation (and I would probably debate this if it made any difference), the mapping of (0, 64-bit identifier) to (64-bit locator, 64-bit identifier) is certainly a translation as much as the mapping of (128-bit identifier) to (128-bit locator). The property of being able to encode the identifier into higher-layer protocols without the need for NAT gymnastics is a function of hiding the translation from all the higher layers, not of the simplicity of the translation function. My proposal also hides the locator and thus has the same property. | | With a little care, multi-homing could be supported. | |Multi-homing would be trivial. | Some care would be required to get failover to work. This isn't | completely | trivial, but it need not be a big deal. | |I would assume the edge router would 'know' the reachability of the |prefixes returned by the DNS query allowing for failover to be handled |the same way it is handled today (more or less). Simple AS hop games |can be played to pick the 'best'. I would not want to depend on the edge router's having that kind of knowledge of the locator routing system just to make multi-homing work for other sites. (It would be one thing to require multi-homed sites to do this, but you are talking about making everybody do it.) I think it would be better to explicitly track only those targets that are being used. Hopefully icmp messages could do most of the work along with something akin to stale route discovery. | I proposed to short-circuit the timeout by having nodes try where | possible | to give a hint to known peers that a renumbering event had occurred. | This | can also be handled either at the end points or at the edge routers. | |Right (I think -- I had suggested the edge routers act as forwarding |agents for a TTL, is this what you mean by short-circuiting?) I'm not sure what you meant by forwarding. I simply meant that a node or edge router that is renumbered can send an alert to its known peers suggesting that they dump their cached data even though its TTL has not expired. |In any event, from my perspective the big problem with this approach, |regardless of whether the DNS is used or not, is the need for edge |routers at both ends to be involved. This results in a chicken and egg |problem that I'm not sure how to get around. My proposal can definitely work (and was originally intended to work) directly on end nodes. It can be pushed into edge routers as well, but it doesn't have to be. But it isn't obvious to me why your version can't work on an end node too. |Oh yeah, and traceroute |from the end points would be useless. If the translation happens at the end nodes I would obviously propose an escape mechanism in the API to deal with locators instead of identifiers. Obviously we would want to discourage use of this escape by other than debugging programs. :) |However, this (and similar) approaches have the advantage that we |continue to use known technology (CIDR,BGP4+,etc) in the core where it |matters... That advantage makes for a good thought experiment, i.e., to show anyone with an open mind that it can be done. Whether we really want to help perpetuate the current archaic routing system by building a layer like this is still open to debate. Clearly adding a layer is better than doing nothing; however, I'd like to think that we can ascertain a pure routing solution that is isomorphic to the split solution. Again, we are really talking about source routing and there are quite a few ways to implement source routing
Re: Enforcing unreachability of site local addresses
David Conrad [EMAIL PROTECTED] wrote: |On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote: | I was actually referring to the practice of inserting 48-bit (or even | 64-bit) | hardware identifiers into the address in the name of easy | configuration. | |One allocation mechanism is pretty much as good as any other. Doesn't |matter how those 48 or 64 bit numbers are allocated, the EUI registry |would be fine. That isn't clear. There are certainly cases where we will want to number an interface for which we do not already have an EUI from the hardware. If the entire identifier space is already taken up with EUIs then there is no room for someone to get a block of identifiers for non-EUI applications. I admit I haven't looked into this; what does it take to get an EUI-64 allocation? I assume that to get any EUI-48 space you still have to buy an OUI at a fairly high price (or else buy old Ethernet cards to hold as tokens). | I would not want to depend on the edge router's having that kind of | knowledge | of the locator routing system just to make multi-homing work for other | sites. | |Hmmm. Multiple ways to solve this, of course. E.g.: the source edge |router does a lookup, gets back a bunch of locators. A naive |implementation could simply pick one and forward to the core via |default. Getting back a network unreachable could trigger the naive |implementation to pick a different locator. The more elaborate the |edge router gets in terms of routing system knowledge, the more |effective the multi-homing would be. Again, I'm not thrilled with making the effectiveness of multi-homing depend on the participation of other sites' routers in the low-level routing (locator) system. I would prefer to add more at the identifier level, but this is really a minor quibble. | I'm not sure what you meant by forwarding. | |The old destination edge router gets a packet for an end point |identifier that has left the network the old edge router is responsible |for. The old edge router does a lookup of the destination identifier, |gets the new locator (if it doesn't already have it), and forwards to |the new edge router. It would need to do this for the TTL of the old |locator. Yes, definitely not what I meant by short-circuiting. :) |It would. The reason I favor the edge router approach is that I wanted |something that would work with IPv4 as a transition aide... I'm still not sure I see why it wouldn't work. | Whether we really want to help perpetuate | the current archaic routing system by building a layer like this is | still open | to debate. Clearly adding a layer is better than doing nothing; | however, I'd | like to think that we can ascertain a pure routing solution that is | isomorphic | to the split solution. | |Baby steps... Perhaps, but this is really what got us into the mess we are in today. What was meant as a crutch to keep memory-address-bit-deficient hardware viable for a few extra months/years has become a serious dependency problem. By turning addresses into almost-routes aggregation has allowed routing protocols that were obsolete years ago to remain in use, but end users pay the terrible price of having their addresses tied to topology. Like any addiction, this problem will only get worse as we continue to feed it. So, yes, I'm all for a translation layer if it is the best that we can do and if we can do it at all. But since we almost certainly can't do it all in the face of current politics, I might as well dream about fixing routing... Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Tony Hain [EMAIL PROTECTED] wrote: |Suspend disbelief for a moment, and consider a name resolution service |where the consumer edge widget was responsible for both tracking |topology changes, and updating a branch of the name tree to keep it |aligned. Said widget would need a secure mechanism to graft itself to |the name tree after an address change, but otherwise might look like a |typical DNS server. [...] It's not much of a suspension. I've been saying for years that exactly such a mechanism is necessary to push the routing task out to the end nodes where ample resources will be available. If it isn't done at some other level it will have to happen in the DNS. However, I believe that the DNS is the wrong place for it. |Given that as a |starting point, there is no obvious reason that using name strings as |the identifier is more difficult than any other approach. Using name strings may be no more difficult with respect to the implementation of the name service, but it leverages far less existing code than would a fixed- length binary identifier. Consider the advantages of using an identifier that has exactly the same format as what we currently call an address, i.e., 128 bits. With translation happening near the bottom of the IP layer, no changes would be necessary in tcp or in applications. The problem of tcp connections (not) surviving renumbering would disappear. The DNS would work just the way it is, so no duplicate effort would be required. With a little care, multi- homing could be supported. I suspect that mobile IP would be a lot easier as well. In contrast, if we fix the DNS to track the topology, names would have to replace addresses in tcp control blocks (and packets and many other places) before we would start to see the aforementioned benefits. I have proposed a simple, scalable mapping service that is vaguely like the DNS in structure but whose purpose is to map 128-bit identifiers into 128-bit locators (where these locators correspond to what we currently use as addresses and treat more as routes) in a flexible way. A request to the root of this mapping service would be of the form, ``tell me about this 128-bit identifier.'' A response would either be a referal to other servers along with a mask to indicate what other requests should go to that same set of servers or an answer in the form of a mapping from identifier (with possible wildcard bits indicated by a mask) to locator (also with possible wildcards to be filled in from the identifier). The latter final response is assumed to come from a server under the control of the owner of the identifier. Obviously, responses would also include the usual TTL values and such much as a DNS response does. The mapping service actually scales a lot better than the DNS because it can increase the depth of the tree as necessary by splitting on arbitrary bit fields in the identifier. This should be transparent (think unix DBM). Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
David Conrad [EMAIL PROTECTED] wrote: |Again, in the vein of willing suspension of disbelief... | |On Friday, January 31, 2003, at 04:55 PM, Dan Lanciani wrote: | Using name strings may be no more difficult with respect to the | implementation | of the name service, but it leverages far less existing code than | would a fixed- | length binary identifier. | |Right. | | Consider the advantages of using an identifier that | has exactly the same format as what we currently call an address, | i.e., 128 | bits. | |Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?. Sure, this has been proposed before, but I think the main complaint was that 64 bits is no longer enough for the wasteful allocation policies we have adopted. I used 128 bits in my original proposal just to avoid the objection that we would be giving anything up in that respect. | With translation happening near the bottom of the IP layer, no changes | would be necessary in tcp or in applications. | |No translation would be necessary. You have to translate somewhere, if not at the bottom of the host's stack then at what you are calling edge routers. | With a little care, multi-homing could be supported. | |Multi-homing would be trivial. Some care would be required to get failover to work. This isn't completely trivial, but it need not be a big deal. |The lower 64 bits of the destination would be put into an |in-addr.arpa-like tree, I like my specialized mapping service, but sure... |Renumbering thereby becomes merely an exercise in modifying the end |point 64 bit in-addr.arpa-like entry and waiting for the cache entry to |time out. I proposed to short-circuit the timeout by having nodes try where possible to give a hint to known peers that a renumbering event had occurred. This can also be handled either at the end points or at the edge routers. There is an infinite variety of these mapping schemes, most any one of which would solve the portable identifier problem. Unfortunately, proposing one always provokes someone to claim that: (a) solving the portable identifier problem is equivalent to solving the non-aggregated routing problem and (b) we do not know how to solve the non-aggregated routing problem therefore (c) the portable identifier problem cannot be solved so easily. Of course (a) is likely true in the sense that the solutions are isomorphic in some abstract way. We are really talking about source routing with an extra level of indirection to make the route look more like an address. That's not entirely unreasonable given that the locator addresses we use in a hierarchical allocation system are really close to being routes. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Brian E Carpenter [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: | | Michel Py [EMAIL PROTECTED] wrote: |... | |One billion routes in the global routing table = does not scale. | | This is the main fallacy in your statement. You are assuming that a billion | PI address blocks has to equate to a billion routes in some global routing | table (or even that there has to *be* a global table). That would be the case | only if we insist on remaining with a full-knowledge centralized routing model. | Such models are outdated. We can do better. | |We tried (NIMROD) to develop alternatives to full-knowledge flat |routing; but that attempt failed. I'm not familiar with the specific constraints placed on the attempted solution, so I can't say whether it really had a chance. Nevertheless, I wouldn't read too much into the failure. There are clearly distributed approaches that will work. They have their various tradeoffs, advantages, and disadvantages. As I've pointed out over and over through the years, we really need to decide up front what cost we are willing to pay for a solution. As long a significant number of people argue that the cost must be zero because the benefit is worth zero or is even negative, any solution will be deemed a failure. |However, as Noel would have told us |for the N'th time if he was watching this thread, any such alternative |requires a method of abstraction and summarization of routes, a.k.a. |aggregation. No, this is exactly the fallacy that leads to failure. There is no need for summarization of routes because there is no need for any given node to have a complete picture (even summary) of the topology. The whole point of distributing the routing task is to make the resources available for routing grow in aggregate at least as quickly as the consumers of those resources. As soon as you start looking at summaries of the whole table you focus resource usage for the whole net on individual nodes again. |Today, the only way we know how to do that is |by shorter and shorter prefixes on binary numbers. And that's the trap. As long a you start with the false requirement for summarization you end up back at aggregation. But we've been over and over this through the years and it always comes down to the same hand-waving arguments that it can't be done. Exposing the specific assumptions behind those arguments is like pulling teeth, and ultimately any proposal can be shot down with the cost-must-be-zero argument. It's starting to get really boring, IMH(historically inaccurate)O. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
|Pekka Savola [EMAIL PROTECTED] wrote: | |Would you mind collecting the old ideas (which you mentioned went back to |1999), Actually, 1999 was just the most recent time I had brought this up. |honing them perhaps a bit (if they need a polish) and putting them |out as a short Internet-Draft? I'm not sure that would be a good use of my time. The main point of the proposal I outlined in 1999 was to show that portable identifiers could work and scale with minimal retrofits to the end nodes and no changes at all to the routing backbone. It was not necessarily the implementation I would choose if I were free to change the existing structure more. As such, the proposal is subject I'm sure to a raft of aesthetic complaints that would confuse the issue. There is also the problem that Toshiba seems to have patented a subset of the my approach... I think the descriptions in the archives serve their purpose well enough. |I'm interested at the proposal, but I'd really like to see the definite |picture of it, and I think that's the only way we can do it. Until we get past the strong assertions that it can't be done I have trouble investing a lot of effort in specific implementation details. What do you think it would take to effectively dispel the summarization/aggregation requirement myth? Could we perhaps consider strict source routing as a simple counter example while realizing that a hybrid approach would probably be better in practice? Or is the jump from strict source routing to hybrid too big to make the case? Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Michel Py [EMAIL PROTECTED] wrote: | Michel Py wrote: | PI = Does *NOT* scale. | | Dan Lanciani wrote: | Please define PI. | |ftp://ftp.ripe.net/ripe/docs/ripe-185.txt This is a rather long document and I was hoping you would provide the part of the definition that you are actually using. This document does claim that one attribute of PI addresses is that they are expensive to route. If you are relying on this as part of the definition then yes, your statement is a truism. The trouble is that this document makes the same implicit assumptions that you seem to be making. | Please define scale. | |One billion end-sites. This is the baseline number for multihoming |solutions. Smaller numbers have been deemed insufficient. Quoting a number does not tell me what you mean by scale. For example, you might say that you require the size of the core routing tables to be at worst O(log) in the number of end sites. Or you might say that it has to be O(constant). I might say that O(linear) is ok. Then we can talk about the table growth versus the increases in hardware performance over time. You are merely invoking a possible future endpoint that you think will have enough shock value when compared to current hardware to make your point. |One billion routes in the global routing table = does not scale. This is the main fallacy in your statement. You are assuming that a billion PI address blocks has to equate to a billion routes in some global routing table (or even that there has to *be* a global table). That would be the case only if we insist on remaining with a full-knowledge centralized routing model. Such models are outdated. We can do better. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Michel Py [EMAIL PROTECTED] wrote: | Michel Py wrote: | One billion routes in the global routing table = does not scale. | | This is the main fallacy in your statement. You are assuming | that a billion PI address blocks has to equate to a billion | routes in some global routing table (or even that there has to | *be* a global table). That would be the case only if we insist | on remaining with a full-knowledge centralized routing model. | |Assuming? Hello? This exactly what PI is. If there is no central routing |it's not PI anymore. PI is what we have _today_. You are confusing the portability attribute of the address with the implementation of its routing. By the definition you chose, PI is a type of address. It is not a routing mechanism. You have also declined to define what you would consider acceptable scalability. You seem to be saying that you aren't happy with a solution unless it allows yesterday's archaic routing protocols running on today's hardware to handle the projected growth of the next decade. Such a requirement constrains the solution beyond any hope of progress. | Such models are outdated. We can do better. | |Why don't you write something about it? I have written about it, most recently in 1999. Why don't you read about it in the archives? |The entire world is waiting for |it. The world, perhaps. But it is never a popular topic on this list... Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Michel Py [EMAIL PROTECTED] wrote: | Dan Lanciani wrote: | You are confusing the portability attribute of the address with | the implementation of its routing. By the definition you chose, | PI is a type of address. It is not a routing mechanism. | |This is not the way PI is being understood in the realm that deals |with them, the RIRs. PI in the context of these discussions has always meant simply that the address is provider independent. |PI does not only mean portability, it also means |the routing mechanism that is (and always has been) in use, which is to |announce the prefix in the global routing table, making it grow. This is exactly why I asked you to provide your definition for PI. |I'm sorry I quoted the wrong document; my bad. |This is what I meant to quote: |http://www.ripe.net/ripe/docs/pi-pa.html |It is clear that PI is associated with an entry in the global routing |table. It is clear now, after three rounds, that you have found a definition that suits your PI = Does *NOT* scale assertion. Combined with your implicit assumption that linear growth of the routing tables does not scale you have a truism. And you have found a way to suggest that provider-independent addressing does not scale, even though you are really talking about something completely different. Other than creating FUD, how is this helpful? | You have also declined to define what you would consider | acceptable scalability. | |1 billion sites is the lowest figure being considered. _Lowest_. 1 billion sites does *NOT* (see, I can use all caps too) express anything about scalability. It is the wrong data type. I've already explained this once. Either you really don't understand the meaning of scalability or you aren't serious about discussing it. | You seem to be saying that you aren't happy with a solution | unless it allows yesterday's archaic routing protocols running | on today's hardware to handle the projected growth of the next | decade. | |If you donate, let's say, US$100 billion to telcos to build a completely |new architecture and backbone to support IPv6, you would have solved a |great deal of an issue. Credit card number, please. Obviously you aren't serious about discussing the actual scaling issues. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Margaret Wasserman [EMAIL PROTECTED] wrote: |But, if we do allocate PI addresses soon, we will need to do that without |any certainty that we can come up with a scalable PI routing scheme. Do you really think that there is any question of whether we could if we actually wanted to? The arguments that it is impossible always come from people who start with the two assumptions that (a) routing must be done with the same centralized full-knowledge model that we use now and (b) hardware absolutely cannot keep up with the mild linear growth of routes in users. This is an obviously self-fulfilling prophecy, but it has been used to justify trading linear route growth in users for exponential address usage in height of provider chain. I think this was a very bad trade to make and that it will guarantee a perpetual shortage of address space no matter how many (fixed) bits we start with at the top of the chain. Previously I proposed (in some detail) a mechanism to retrofit portable identifiers to IPv6. I suspect that it is isomorphic to some distributed routing schemes, but keeping the addressing mechanism separate from the routing mechanism makes it easier to evaluate certain characteristics of the solution. I'm not claiming that this is the right scheme to implement (especially given that a patent seems to have been issued for a subset of the method over a year after I described it) but it does have a property that makes it worth thinking about, at least in the abstract. Although there is no obvious way to prove that my method ultimately scales in the face of increasing renumbering, my method makes no more demand on its mapping infrastructure than does the DNS. Thus if my method is doomed then so is the DNS, or, looking at it differently, we would have to solve the same problem for the DNS to keep it working in the face of renumbering. |But, I've been told by ISPs who lived |through the CIDR transition in IPv4 that this _really_ isn't something |that we want to repeat for IPv6. I wonder what they meant by that? The CIDR(*) transition was terrible for end users but ultimately a great boon to ISPs. Recall that we were promised that CIDR addresses would be _portable_ because the whole exercise was just a temporary stopgap measure until the hardware caught up. We were supposed to be able to take our ISP-assigned CIDR block and move it to a different ISP, with the assumption being that this would happen slowly enough that CIDR would keep the table growth under control until the hardware caught up. How long did that promise last? A couple of months? As soon as the economic benefits of binding addresses to ISPs became obvious all those CIDR blocks became non- portable and have remained so ever since, massive advances in hardware capacity notwithstanding. This particular history is part of the reason that I'm so skeptical about the claims of ready availability of stable global addresses to end users under v6--economic considerations often trump technical ones. (*) I use the term CIDR because it is popular, but CIDR itself isn't the problem. CIDR is just a slightly different way of looking at netmasks. The problem is the hierarchical address allocation required to make route aggregation pay off. |Some folks have argued that easy renumbering would eliminate the need |for enterprises to have provider-independent addressing, but I don't |agree. Addresses are stored in many places in the network besides |the interfaces of routers and hosts, such as access control lists, |configuration files, .hosts files, DNS configurations, ACL lists, etc. |In many cases, addresses are stored in nodes on other subnets. So, |being able to renumber the interfaces of hosts and routers on a |particular network or subnet doesn't even solve half of the problem. Those who earnestly argue that easy renumbering would eliminate the need for PI address space (and please don't confine the need to enterprises-- the stability of my home network is more important to me than that of any enterprise) are typically talking about a complete solution that would pervade all the areas that you mention and would require massive interaction with a variety of tools. IMHO this is not impossible, but those that claim that it is an easier problem than the PI route problem or even the site local semantic problem are way off base. |So, what do we do? | |Choices seem to be: | | (A) Continue with PA addressing, and accept that enterprises will | use IPv6 NAT to get provider-independence. Sufficiently large enterprises will get their own address space by (if necessary) claiming to be higher-level ISPs. [...] |I'm not sure that we'll ever reach anything resembling IETF consensus on |that choice, though. Given the strong voices that oppose anything that would change the economic status quo, you are almost certainly correct. Dan Lanciani ddl@danlan.*com
RE: Enforcing unreachability of site local addresses
Michel Py [EMAIL PROTECTED] wrote: |This is the semantics police speaking: |PI = Does *NOT* scale. Please define PI. Please define scale. (If your usage in unconventional, please define *NOT*.) Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Brian E Carpenter [EMAIL PROTECTED] wrote: |Dan Lanciani wrote: |... | Please explain *specifically* what new mechanism v6 supports for providers to | realize their service differentiation without limiting IP addresses, and show | why providers will be inclined to make the switch. | |Today, ISPs experience a cost advantage when they limit the number of |addresses or provide only dynamic addresses. That cost advantage is |a result of scarcity, and will therefore not exist in IPv6. If there |is no cost advantage, there can be no differentiation. No. ISPs use address counting as a surrogate for bandwidth measurement. They also limit address stability to discourage server operation. The supposed scarcity of addresses cannot explain the use of short DHCP leases for always-on connections and the attempts to ban NAT. Beyond this there is the obvious cost advantage of being able to collect a monthly fee for each address. This cost advantage is not going to go away just because the ISP has more addresses at its disposal. Why would you expect an ISP to give up this revenue stream? Your theory that the ISP's cost advantage in limiting the number and stability of addresses is solely (or even mostly) a result of scarcity is not consistent with the ISP industry as it currently exists. |We aren't here to provide methods of differentiation; I'm not asking for such methods. I'm merely asking for some specifics to back up the repeated assertions that ISPs are going to change their business models and give everyone all the addresses they want. Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Brian E Carpenter [EMAIL PROTECTED] wrote: |We're getting way outside IETF territory here. Come on. Understanding the availability of global addresses from ISPs is critical to analyzing the need for various kinds of local addressing solutions. It is unreasonable to assert such availability as a justification for removing local address space and then claim that discussion of the assertion is out of bounds. |Dan Lanciani wrote: | | Brian E Carpenter [EMAIL PROTECTED] wrote: | | |Dan Lanciani wrote: | |... | | Please explain *specifically* what new mechanism v6 supports for providers to | | realize their service differentiation without limiting IP addresses, and show | | why providers will be inclined to make the switch. | | | |Today, ISPs experience a cost advantage when they limit the number of | |addresses or provide only dynamic addresses. That cost advantage is | |a result of scarcity, and will therefore not exist in IPv6. If there | |is no cost advantage, there can be no differentiation. | | No. ISPs use address counting as a surrogate for bandwidth measurement. | |Some of them in some regions of the world, perhaps. Some, as in pretty much every consumer- and small-business-level ISP in the US. |There are plenty who |measure bandwidth consumption explicitly. If you count ISPs that use bandwidth caps as an *additional* safeguard beyond address limiting then this might rise to the level of plenty. | They | also limit address stability to discourage server operation. The supposed | scarcity of addresses cannot explain the use of short DHCP leases for always-on | connections and the attempts to ban NAT. | |Agreed. But here we are getting into potential regulatory territory and |outside the IETF's scope for sure. The IETF defines the addressing architecture. The addressing architecture has a dramatic effect on the market economics. You cannot refuse to consider those effects on the grounds that they resemble regulation. This should be especially true when you are discussing a new limitation on addressing flexibility that by its very nature will give ISPs a huge financial benefit at the expense of end users. | Beyond this there is the obvious | cost advantage of being able to collect a monthly fee for each address. This | cost advantage is not going to go away just because the ISP has more addresses | at its disposal. Why would you expect an ISP to give up this revenue stream? | |Because one of their competitors decides to do so, forcing them to do |so as well. Absent scarcity, charging for something that has zero cost |simply isn't sustainable in a competitive market. That's what they said about the phone companies, yet I still pay lots of monthly fees for certain bit settings in the switch. I even pay for DTMF service even though it costs less for the phone company to support than dial service. | Your theory that the ISP's cost advantage in limiting the number and stability | of addresses is solely (or even mostly) a result of scarcity is not consistent | with the ISP industry as it currently exists. | |That industry grew up post-CIDR in a climate of scarcity. This is |changing. The only scarcity that matters in this context is the lack of availability of IP addresses to end users. IPv6 does not improve this situation at all. As long as address allocation is controlled by the ISP there will be artificial scarcity for the end user because this situation provides the ISPs with a financial advantage. Most ISPs are in business to make money. Dan Lanciani ddl@danlan.*com 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: Let us embrace NAT6, was Re: Proposal for site-local clean-up
Quality Quorum [EMAIL PROTECTED] wrote:
|It seems to me that stability and security of internal enterprise
|addressing is a very serious requirement.
And why just enterprise? The stability of my home network is more important
to me than the stability of any enterprise network.
|Frankly, I do not see any way
|to avoid NAT6.
Without some other kind of local address space it does seem inevitable. It's
unfortunate that folks are considering ways to make applications NAT-hostile
to force us to depend on global addresses allocated by ISPs.
|Second isssue, which will IMHO force NAT6 is relative scarcity of global
|routing prefixes. In the current scheme of things we have only 25 bits to
|express routing topology (the rest is taken by admin and local) and
|it may prove to be too small.
Given the hierarchical allocations required by strict address aggregation,
pretty much any fixed number of bits is too few. Hierarchical allocations
are incredibly wasteful because they consume address space exponential in
the number of providers in the chain. They also tend to make the structure
of the market inflexible and require pre-definition of various types of
providers--something that would have been better left to that market. I
suspect that regardless of the intent, many consumer-level ISPs will operate
at the bottom of the chain (likely below the point that the architecture
considers suitable for ISPs). This will virtually guarantee an artificial
address scarcity at the end-user level. I've noticed that even the optimists
are no longer talking about /48s for dialup. Soon I expect that the reduced
claims of /64s will degenerate into /{128-n}s where n is directly related to
the level of service.
It's really a shame that IPv6 took the path that it did. Originally it was
to be a clean and simple solution to the address shortage. Fixed-length
addresses and (supposedly initial) hierarchical allocation were virually
mandated by the simplicity requirement. The two alternatives that would
have provided far greater flexibility (*variable*-length hierarchical
addresses or fixed-length portable identifiers) appeared too complicated.
Over the years IPv6 has acquired the every-feature-but-the-kitchen-sink
syndrome, and the relative complexity of a more powerful addressing scheme
looks quite low in retrospect--but now it's too late to retrofit one. At
the same time we are discovering that merely increasing the (fixed) number
of address bits while perpetuating the allocation and routing procedures
that were originally intended as a temporary hack to keep old hardware running
doesn't offer the panacea we expected. The problem was never just (or even
mostly) the number of bits in an address. It was (and is) a complex combination
of techincal routing issues and market economics.
|I hope that by addressing this problem head on early in the process we can
|do implementations much less painful and better prerforming.
The problem was addressed early on with site-locals, but now they are being
restricted into uselessness. I have strong doubts that the discussion of
globally unique identifiers is anything more than a passing diversion. Every
time this has been discussed in the past it was shot down on the grounds that
it could subvert the all-important MLM^H^H^H hierarchical addressing scheme.
Dan Lanciani
ddl@danlan.*com
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: Proposal for site-local clean-up
Tim Hartrick [EMAIL PROTECTED] wrote: |Brian, Dan, | | | | |Because one of their competitors decides to do so, forcing them to do | |so as well. Absent scarcity, charging for something that has zero cost | |simply isn't sustainable in a competitive market. | | That's what they said about the phone companies, yet I still pay lots of monthly | fees for certain bit settings in the switch. I even pay for DTMF service even | though it costs less for the phone company to support than dial service. | | |Brian's argument would be correct if the act of moving from one ISP to |another ISP was free of cost to the end user. It isn't clear that even this is sufficient to make the argument correct. First, to state the obvious, the end user would need access to more than one ISP that could accommodate her requirements. Many home and small-business users are lucky to have one high speed provider available in their service area. Less obvious, even if there are alternative providers, they would need to be truly independent. The hierarchical service model makes it not unlikely that two supposedly competitive providers share an upstream provider and are constrained by contracts with that one higher-level ISP. I haven't looked at this in detail in a long time, but it used to be common practice to enforce fairly anti-competitive-sounding terms with peering agreements and similar address/routing resale contracts. Even in the case of two large and relatively independent providers (say, a cable company and a telco-operated DSL service to take a typical situation) it isn't clear that the oligopoly would indeed be competition-driven. Each provider would know that it remained in its own interest to preserve the revenue stream from address rental charges and there would be very little incentive to compete. This seems to be more-or-less what happens when you have an ILEC and one big CLEC. In order for Brian's argument to be correct in practice, then, I think we need (in addition to painless renumbering) a reasonable number (say, 5) or truly independent ISPs competing for the business of the end user in question. I just don't see this happening for the majority of users any time soon. Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Tim Hartrick [EMAIL PROTECTED] wrote: | Designing tools that yield the desired results only when applied to a | competitive environment (assuming there is no valid technical reason | for the limitation) is at best bad engineering. Doing so when there | is good evidence that the competitive environment will not exist begins | to look disingenuous. | | |Sure, if one doesn't accept that routing aggregation is important then |of course we can go back to PI space just like good old IPv4. If in fact |aggregation isn't important then it would be disingenuous to continue down |a design path that puts ISPs in the driver's seat to the detriment of end |users. I don't follow the research in this area well enough to know whether |or not there are serious alternatives to routing aggregation techniques like |CIDR. If there are then I would be very happy to forget all about site-local |addresses and PA address space. Life would be a lot simpler. I was actually referring to the design decision to limit site locals on the grounds that they are not needed in a competitive environment that will supposedly result in greater global address availability. Portable identifiers and provider-independent address space (which are both PI :) are a different kettle of fish. There are certainly ways to attack the problem, but I've found that attempts to discuss them result in even more negative response than was elicited in the recent site-local debate... Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Erik Nordmark [EMAIL PROTECTED] wrote: | This does not answer the question of why you assume that ISPs will change | their business models under v6. | |I said: | |The ISPs business model is about service differentiation. | |And I agree that they most likely will continue with service differentiation. | | |But I think they can change the *realization* of service differentiation |from using IP addresses to using something else, just as long as the |new mechanism provides what they need. In general, businesses do not like to change from known/understood models to new ones unless they believe that the new model will bring some significant new benefit. But this is all rather abstract. Limiting the number and stability of IP addresses works very well for providers now. We agree that providers use this as a means of service differentiation. Previously, you (and other contributors) have dismissed with some certainty my concern that providers will continue to limit addresses under v6. This has been the basis for claiming that site local addresses are unnecessary to answer the simple question: how does my internet-connected PC talk to my network printer without my paying my provider for a second address? Please explain *specifically* what new mechanism v6 supports for providers to realize their service differentiation without limiting IP addresses, and show why providers will be inclined to make the switch. Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Erik Nordmark [EMAIL PROTECTED] wrote: | |Sorry for the delayed response - didn't see me in the to: or cc: fields. | | I try to keep all the mail to the list just to the list... | |As long as you don't ask me direct questions and expect me to answer |than would be fine. This time it took almost 2 months... This is really meta-discussion, but I find it confusing when a piece of a thread doesn't make it to the list until after several rounds have occurred in private. I think that those of us who actually read the entire thread appreciate the opportunity to see each response as it is generated and to comment on those responses before the subsequent rounds. For these reasons I think it is not only reasonable but desirable to send each message through the list (only) even if it contains questions addressed to others list readers. | |You seem to be assuming flash renumbering without overlap. | | Yes, that is the only reasonable assumption to make. Just as ISPs now use | short DHCP leases and related dynamic adderssing techniques to discourage | what they perceive as bandwidth hungry server activity they will use | frequent renumbering to achieve the same goals. Without site locals they | will have the added advantage of being able to disrupt not only your | server's accessibility from the internet, but your stereo and your tv as | well. At least they will be able to do this until v6 NAT appears. | | Please explain why you assume that ISPs will change their business models | under v6. | |The ISPs business model is about service differentiation. |They can and do use various techniques in IPv4 to accomplish this - short |DHCP leases, 1 vs. multiple IP addresses, port filtering, access line bandwidth |etc. They will AFAIK continue to need to do service differentiation. |But the actual form of service differentiation doesn't need to be |the same. | |Will v6 make the ISPs that do port filtering stop doing so? |Not uness there is some other means to provide service differentiation. | |Will v6 make the ISPs that use short leases stop doing so? |Not uness there is some other means to provide service differentiation. This does not answer the question of why you assume that ISPs will change their business models under v6. In fact, it sounds like you are now agreeing that they will not do so, at least not unless some other as-yet-unspecified change occurs. Given that without such a change we agree that ISPs will limit both the number and stability of v6 addresses just as they now do with v4 addresses, and given that you haven't offered a reason why flash renumbering won't be used to make the situation worse (well, worse for customers, better for ISPs), how exactly have we obviated the need for site-locals and scoping? |If we can provide some other means for them to do so, we can avoid having to |warp the addressing architecture to try to route around the ISPs desire. I don't think that it is desirable to create additional means for ISPs to charge for services that consist largely of not disrupting their customers' internal networks. That kind of service differentiation is always going to be artificial. If v6 ever reaches the penetration that some of us originally hoped it would (and that is becoming less and less likely IMHO) we could depend on it for all sorts of internal communications between, e.g., appliances, televisions, alarm systems, light controllers, etc. Designing such a system to operate correctly independent of the actions of external service providers is arguably best practice and sound engineering. It is not simply an attempt to route around the ISP's desire to collect monthly service fees for allowing a local network to operate. If the intended architecture does not provide a clean way to do what the vast majority of users are going to see as an obvious given (i.e., operate a stable local network) then NAT will route around the blatant deficiency. While you can define the protocol to favor the ISP's desires, the free market will eventually serve the user's desire for a working local network. Dan Lanciani ddl@danlan.*com 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: Enforcing unreachability of site local addresses
Margaret Wasserman [EMAIL PROTECTED] wrote: |I think that we should stop calling these addresses site-local, |as that is prone to confusion. We would create a separate set |of globally-unique/provider-independent (GUPI? Pronounced |guppy or goopy, depending on how much you like them? :-)) |addresses for use as local addresses in Internet connected sites. | |We could still have site-local addresses (FECO::/10), which can be |used for disconnected networks (and perhaps other cases -- we |haven't really decided how widely to use them yet). If we limit |them to disconnected sites, they could be treated exactly like |global addresses by all nodes. If we also allow them to be |used on connected networks (for intermittently attached networks, |for example), we probably want to change the default address |selection rules to prefer globals (of both sorts) over SLs. I trust that it goes without saying that these GUPIs will have to actually be available *before* this change to the default address selection rules is made. Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
Tim Chown [EMAIL PROTECTED] wrote: |On Mon, Nov 18, 2002 at 10:49:42PM -0500, Dan Lanciani wrote: | | We have always been told that stable global v6 addresses will not be available | to end users, or at least will not be available to end users at a low cost. | |Told by who? Folks on this list every time provider-independent global addresses or stable identifiers are brought up... |I can see ISPs wanting to charge for extra services where they |can, and thus for a static /48 as they do now for a static single IPv4 |address. But I would hope that enough ISPs would offer free static /48's |to take custom from those who charge. Given that this is not happening now for single static v4 addresses, your analogy would seen to suggest the opposite. |The only snag is that such ISPs |with 10M customers would need a lot more than a /32, esp. taking into |account the HD-ratio. This isn't just a snag. The hierarchical addressing architecture consumes address space exponential in the number of providers in the chain. This makes it very difficult to break away from the limited business models currently contemplated. In order to be the kind of provider you suggest the ISP probably has to move up a level in the chain. Suddenly that huge address space is looking a lot smaller... Erik Nordmark [EMAIL PROTECTED] wrote: |If the ISP provide the disservice of unstable IP addresses I think we have |a large class of problems. The fact that site-local addresses might ameliorate |some of those problems doesn't magically make such ISP disservice useful. No, but the existence of an alternative may help to avoid the disservice in the first place. By taking away the alternative you give the ISPs a huge lever to charge whatever the market will bear, at least until NAT is available. By reducing the need for (and thus the perceived value of) stable addresses you may be able to reduce their cost. Keith Moore [EMAIL PROTECTED] wrote: | We have always been told that stable global v6 addresses will not be available | to end users, or at least will not be available to end users at a low cost. | |I think this depends on what you mean by stable. For some reason the |community has been reluctant to specify a number here, and the result |is that people have widely varying ideas about what we can expect in practice. The community has been reluctant to specify a number because it isn't clear that stability is other than a binary attribute. The worst part of keeping this whole stability issue in limbo is that it's always possible to argue that things will be stable enough that we don't have to solve the renumbering problem. This in turn means that lack of stability will always be an encumbrance and thus stability will command a premium. |I don't think we want to let the reliable operation of applications be |an accident, nor do I think we want to trust market forces to sort this |out. I agree. This is exactly why we desperately need scoped addressing or a comparable mechanism that allows users to control the stability of their networks. | Unless you are proposing to revise the whole address allocation architecture | *and* have a way to force ISPs to change their business models I think we must | accept this as a given. | |I don't think it's necessary to force anything, and casting things in these |terms makes them seem more difficult than they really are. I am merely observing current business practices and projecting a reasonable continuation of those practices. You on the other hand keep implying that there will be a significant change in the business models, but you decline to provide any plausible justification for your expectations. Repeatedly asserting that everything is going to be copacetic will not make it so. | I think you have made an unreasonable leap by dropping the stable qualifier. | The value/importance of _stable_ local communication is almost certainly much | higher than the value/importance of _stable_ global communication. | |No. You erroneously assume that different applications are used for local |and global communications, No. The assumption is that people have different expectations and needs for local versus global connectivity. This is not my assumption but the assumption of the v6 addressing architecture. This assumption, while aesthetically unappealing, is clearly correct for many users. This assumption is behind the compromise of giving up portable globals in exchange for a local solution that is better integrated than NAT. |and you are over-generalizing the case for |stable global communications from two very specific cases. Too many people |think that the Internet only needs to support web and email. If that were |the case we wouldn't need IPv6 at all. | |The 'local' versus 'global' distinction is a false one. These would be great points if you were arguing for (and I were arguing against) a return to user-owned portable global/stable addresses. But I've never seen you
Re: unique enough generation
Pekka Savola [EMAIL PROTECTED] wrote: |I'm assuming that for the intents and purposes of replacing |local site-locals, nearly unique site-locals would be enough. [...] |It appears to me that we have a very obvious and clear solution here, not |even requiring any IANA/IESG action to get kickstarted. A solution to which problem exactly? I'm all in favor of unique site locals, but I don't see how they eliminate the need to deal with scopes. They are extremely attractive in that they will allow us to interconnect sites with dynamic tunnels, bypassing ISP restrictions on address count and stability. By treating native aggregated addresses in effect as routes we can easily build a distributed routing layer that scales indefinitely and hides all the problems of unstable addresses from the applications. Dan Lanciani ddl@danlan.*com 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: unique enough generation
Pekka Savola [EMAIL PROTECTED] wrote: | I'm all in favor of unique site locals, | but I don't see how they eliminate the need to deal with scopes. | |I'm not sure why we'd have to be able to kill scopes. Fine by me. It's just that dealing with scopes seems to be the problem that most people are complaining about rather than the existence of the addresses themselves. | They are | extremely attractive in that they will allow us to interconnect sites with | dynamic tunnels, bypassing ISP restrictions on address count and stability. | By treating native aggregated addresses in effect as routes we can easily | build a distributed routing layer that scales indefinitely and hides all the | problems of unstable addresses from the applications. | |I don't see any significant problems which would prevent this, even though |we may still want to prevent the use of these site-locals to disconnected |or semi-disconnected sites. Then I propose the same thing I (and others) have proposed in the past. Pick a prefix xx from the SL space at random and append the hex to some well known string, e.g., mysiteprefix giving mysiteprefixxx. Register mysiteprefixxx.com as a domain name. If it already exists, pick a new random number and try again. This provides the uniqueness without involving a new registry service and the nominal fee will discourage people from over- consuming. To move to the next step (assuming you want outside connectivity), register an ISP-provided global as the address for this domain (or a sub-domain; there are some optimizations that can be made). This is your tunnel destination. When another site wants to send packets to you, their router recognizes the prefix as a site-local-unique address and, if the tunnel destination isn't already cached, performs a DNS lookup of mysiteprefixy.com. If (as some folks claim) the dynamic DNS will be good enough to handle the instability of that ISP-provided global for host name lookups then it will be good enough for this as well. If (as is more likely) the DNS won't be up to the task the situation can be improved by having tunnel end points send hints to recent partners when their addresses are renumbered. Dan Lanciani ddl@danlan.*com 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: globally unique site local addresses
Michel Py [EMAIL PROTECTED] wrote: |I agree with Charlie. | |There could be another model, where the end-site would request the block |to one of their ISPs and the ISP access the IANA or RIR web site on |behalf of the customer. Let's not encourage ISPs to be in the address allocation business any more than necessary. :) Besides, what if you don't have an ISP? |I think that RIRs would be more comfortable with |this. We need to get them back in the habit of dealing with consumers. :) |Also, there is nothing that says that we can't have both Pekka's almost |unique *and* something like what I proposed which is completely unique |at the same time. Absolutely. What's the point of all these wonderful prefix bits if you don't use them? Dan Lanciani ddl@danlan.*com 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: Proposal for site-local clean-up
will just encourage yet another round of kludges. |So let's not loose sight of the fact that the goal is a robust network. I think that the goal is a useful network--useful not only for ISPs and application vendors but for consumers. Dan Lanciani ddl@danlan.*com 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: Naming and site-local addresses
Keith Moore [EMAIL PROTECTED] wrote: | |Neither does it scale to expect all hosts to maintain | |enough information to let them do routing. | | On the contrary, distributed host-based routing is one of the few solutions | that does scale well. The availability of resources to deal with the routing | grows directly in proportion to the consumers of those resources. | |that incorrectly assumes that the only 'resource' in question is cpu time No. Apart from all the resources provided by the host itself (including not only cpu time but also temporary and long-term storage) the aggregate bandwidth of the network grows as well. Dan Lanciani ddl@danlan.*com 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: Address allocation schemes (Re: Naming and site-local)
Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: |--On søndag, november 10, 2002 15:25:56 -0500 Dan Lanciani |[EMAIL PROTECTED] wrote: | | As long as we are stuck with a totally non-scalable address allocation | system (remember, provider-based aggregated addressing consumes address | space *exponentially* in the number of providers in the service chain) | end users need some way to provision local systems with stable addresses. | So far, nobody has proposed a viable alternative to scoped addresses. | |metro addressing? Perhaps. I'd have to hear the details (in particular the costs). |btw, my current naive prediction of the way the Internet will evolve is |that unless new invention occurs, the default-free zone will eventually be |flat-routing on the number of ISPs in the world, and that this number will |have 5 digits. Sadly, I think that you are correct, at least to a first approximation. There will probably also be a few routes for companies big enough to demand and get true single-prefix multi-homing (though I guess they could just declare that they are ISPs). The rest of us will have to make do without such luxuries. I suspect that arguments similar to those against application support for site-locals will render multi-prefix multi-homing less than wonderful. |stable addresses for the lifetime of your ISP service contract seems like a |not too terrible deal, It's certainly not as good a deal as provider-independent addresses. The extent to which the deal is not too terrible would depend on how much you have to pay for the privilege. |if renumbering is easy. easy for the customer as opposed to easy for the ISP... Michael Thomas [EMAIL PROTECTED] wrote: |Harald, | |I think this probably boils down to something |completely non-technical: do people view IP |addresses as addresses ala street addresses, |etc, or do they view them as possessions like |(now) phone numbers and email addresses. Though |the net was designed for addresses, Which net? IP addresses have always been treated as possessions. The big paradigm shift came when they went from being possessions of end users to possessions of ISPs, with ISPs renting them back to end users. Remember, even when the provider-allocated aggregation hack was originally proposed as a temporary work-around for limited memory expandability in certain routers, the promise was that space so allocated would still belong to the end user and be portable. (Supposedly by the time enough people had switched ISPs to expand the tables the hardware would have caught up.) That promise lasted what, two months? It's a little like the promise of site- local addressing. If global/routable IP addresses really worked like street addresses I think you would see a lot less demand for other stable address space. People know that there is a certain overhead associated with a physical move, and switching IP addresses along with phone numbers, street addresses on business cards, etc., would not be a big deal. But IP addresses like that aren't really available. It is unreasonable to claim that an IP address is like a street address in the sense that it tells which ISP you currently live at. |I suspect |that they are viewed more as possessions which is |an obvious problem. Why is it a problem? Dan Lanciani ddl@danlan.*com 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: Naming and site-local addresses
Keith Moore [EMAIL PROTECTED] wrote: |Neither does it scale to expect all hosts to maintain |enough information to let them do routing. On the contrary, distributed host-based routing is one of the few solutions that does scale well. The availability of resources to deal with the routing grows directly in proportion to the consumers of those resources. It is traditional centralized routing that suffers from issues of scale, though these are variably exaggerated and minimized depending on the case that is being argued. Personally I would have liked to see routing confined to the stack and hidden from applications with portable identifiers or a similar indirection mechanism. Unfortunately, this would have conflicted with the address allocation business model as currently envisioned, so the functionality (or, rather, a subset of the functionality) was percolated up to the application layer. So it goes. Dan Lanciani ddl@danlan.*com 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: Naming and site-local addresses
Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: |This seems to lead me to one of two conclusions: | |- Address lookup is significantly more complex in the presence of |site-local than if only global-scoped addresses are used | |- I missed something. | |Comments? I don't think you missed something. If anything, site-locals are even more complex to support than you suggest. But site-locals (or, more generally, scoped addresses) are what we got in the face of the questionable assertion that provider-independent global/routable addresses are too difficult to even think about supporting. As long as we are stuck with a totally non-scalable address allocation system (remember, provider-based aggregated addressing consumes address space *exponentially* in the number of providers in the service chain) end users need some way to provision local systems with stable addresses. So far, nobody has proposed a viable alternative to scoped addresses. Dan Lanciani ddl@danlan.*com 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: (ipv6) globally unique private addresses
Michel Py [EMAIL PROTECTED] wrote: |You don't have NAT and you are not going to write yourself. Forget it. I write tcp/ip stacks and associated drivers for a living. Some of my OEM customers use these components to build NAT products. I assure you that if I want v6 NAT I will have it. Even if I don't want it I will probably have it. The way things are going, it looks like everyone will have it. If they have v6 at all. | There seems to be a persistent notion that ISPs are going to | change their business models just because the IP header | version field increases by 2. I don't buy it. Show me proof. | |The IID is 64 bits, please read the addressing architecture draft. Same |as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can |not give you less than ONE /64. I'm sorry, but you are wrong. Many ISPs run their networks as big bridged segments. They can and they will use a single /64 for such segments, allocating customer addresses out of that chunk on a pay-per-address basis. It could even be argued (and I'm sure they will argue) that this is the most natural arrangement: what was a single v4 subnet will become a single v6 subnet. Dialup providers will almost certainly use a /128 because that is the closest to what they are doing now. It doesn't matter what a draft (or any other document) says. Such papers are not binding on ISPs. Remember, many ISPs use addresses as a substitute for bandwidth. That's why some of them are so hot to detect and eliminate v4 NAT. Dan Lanciani ddl@danlan.*com 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: Limiting the Use of Site-Local
Margaret Wasserman [EMAIL PROTECTED] wrote: |What makes you think that you will rent individual addresses from |your ISP in IPv6? What makes you think that the current business model will change? There are two aspects of the current model. ISPs charge per address because they can use this as a surrogate measure of bandwidth, and they charge what the market will bear because customers have no choice but to rent addresses. Nothing in v6 changes either of these aspects. In fact, some features of v6 makes things worse for the customer here. Functional site-locals might have had a chance to at least constrain the price since an end user would be paying only for the incremental feature of global access. Without working site-locals the basic functioning of each networked device will depend on the ISP's address allocation and thus we will be back to whatever the market will bear. This in turn will encourage NAT. |The idea is that every customer site should |receive a /48 allocation, That's a nice idea for the customer, but not such a nice idea for the ISP. Given that the provider controls the allocation, what do you think will happen? |and individual nodes (at the end of |point-to-point links, etc.) should receive a /64. Funny, it seems like only months ago someone was assuring me that dialups would get a /48. We've already lost 16 bits. You have to realize that in practice dialups will get a /128 unless they pay for special treatment. |So far, the ISPs who have deployed IPv6 (there are only a few |right now), have been allocating a /48 or a /64 to every customer. Do you honestly think that this is a valid indication of anything? V6 addresses are virtually free at this time because they have virtually no commercial value. V4 addresses were free in the good old days (yes, I was there) when they had little perceived commercial value. They were even provider-independent. It took some fancy footwork to get from that to where we are today, with each market step sold as a temporary technical hack that (a) would require us to give up nothing in the long term and (b) was vital to prevent the immediate collapse of the net as we knew it. Of course, all the address restrictions became permanent even though their dubious technical justifications ceased to exist long ago. If and when v6 addresses gain commercial value their price will increase as well. Dan Lanciani ddl@danlan.*com 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: Limiting the Use of Site-Local
Michel Py [EMAIL PROTECTED] wrote: |I support the idea that a _subnet_ should not have both site-local and |global addresses, not a site. Please also read what I posted earlier |concerning deprecation. Could you clarify this position? Let's say I have an Ethernet segment with 20 workstations and 5 printers. I determine that two of the workstations need access to the Internet so I rent 2 global addresses from my ISP. Are you saying that at this point for all the workstations to continue using the printers I have to either: 1. Rent an additional 23 global addresses from my ISP making the entire subnet global -or- 2. Interpose a router between the 2 globally connected workstations and the remaining 18 workstations plus 5 printers, forcing the 2 globally connected workstations to use their global addresses to talk to site-locals on the printers (thus making such connections depend on the ISP). In order to change which workstations have global access I would have to move them between subnets. Or are you saying that site-local and global addresses should not appear in packets on the same subnet at all (rather than as addresses of a single machine on a subnet) in which case only #1 would work? | In this situation, why/how would Router B ever route any | packets? The control device(s) will only have site-local | addresses, so they can't send packets that will be routed | by Router B, nor can any systems to left of Router B | (outside the site?) send packets to the control devices... I believe Margaret is implying a restriction here that connections cannot be made between a site-local address and a global address. That would invalidate solution #2 above. I think that a number of constraints on site-local addresses are being bandied about without much thought as to their impact. Any one of these constraints probably makes site-locals useless for the purposes originally promised. Given subject of these messages I suppose that could be the idea, but it's going to cause a lot of confusion... Dan Lanciani ddl@danlan.*com 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: Limiting the Use of Site-Local
agree with the business driver |assertions in draft-hain-ipv6-pi-addr-use-03.txt ? We can disagree about |the approach in the PI format, but the fundamental reasons should be |consistent. I'm not sure I understand the question. What is the business aspect? I have nothing in particular against geographic addresses, especially if they are the only kind of routable portable addresses I can get. The big questions will be whether ISPs feel they can charge a premium for supporting such addresses and whether there will be some other entity who will want to collect a (possibly recurring) fee to allocate them in the first place. (Granted the latter will seem a bit funny. Why should I have to pay to allocate address space defined by the land I own? But weirder things have happened.) I did notice some wording in your draft that implied a need-based usage, e.g., for multi-homed customers. I hope there will be nothing to allow ISPs to classify such addresses as a premium service because of their association with what are perceived to be activities limited to big/rich companies. |Non-routable global addresses are by definition local. The only thing |they bring to the table over SL is ambiguity in the scope of |routability. They may help with site merger. My only point is that they don't remove the need to deal with scopes, so they aren't in any sense an alternative--just a variation. Thus the argument that we don't have to worry about scopes if we wait for non-routable globals seems specious. Dan Lanciani ddl@danlan.*com 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: Limiting the Use of Site-Local
|for special-purpose devices) than to solve the SL addressibility problem. So we are coming full circle? We have the renumbering problem because the portable address/identifier problem was declared by fiat to be too hard to even think about solving. We are stuck with site-local addressing because the renumbering problem turned out to be too difficult to solve in practice. I've noticed an unfortunate trend towards the following kind of argument: ``X is bad, unaesthetic, and hard. I don't like x. The world will be much better if we eliminate x now and replace its functionality with y at some point in the future. Y is easier, cleaner, and more aesthetic. As soon as someone manages to implement y everybody will see this. I don't have an implementation of y right now, of course. But it will happen.'' Site-locals are already at least a third-order compromise. You aren't even proposing a new y... If you think that the renumbering problem is easy solve, can I make a suggestion similar to the ones I received when I proposed portable identifiers? Go make it work. Bring back a few sample implementations that demonstrate transparent renumbering. Write it up. Get the necessary changes made in whatever standards are affected. With renumbering solved I think you will see less resistance to elimination of site-locals, though there is still the address cost issue. Now in my opinion, renumbering is a very hard problem to solve--much harder than either portable identifiers or scope propagation. (At least, renumbering is hard to solve if you don't introduce a level of indirection that is equivalent to portable identifiers.) But I'd be happy to be proven wrong. |second, I don't buy that we're stuck with provider-based addresses anyway. Can you expand on this? If you know a way to get unstuck from provider-based addresses I'd love to hear about it. With a mechanism for end users to own portable routable global addresses the need for site-locals would be greatly reduced. But if you are just talking about a hypothetical future utopia then it is unreasonable to use this as a reason to deprecate site-locals. The ipv4 address aggregation hack was supposed to be a temporary stopgap until the hardware caught up. The hardware caught up a long time ago. You still can't get portable v4 address space in any reasonable way. I see no reason to believe that v6 addresses will fair any better. If you are talking about non-routable global addresses then this is a step in the right direction, but it isn't clear that it removes the need to deal with scopes and DNS hacks. If you are talking about 6to4 space then you have found an illusory solution. |third, I don't buy that every company wants to set up its own infrastructure |to network to remote devices when they can take bids from competing providers |who already have infrastructure - or even use a mixture of providers. |(for instance, you can combine wired, wireless, satellite depending on |where your devices are) Do you buy that most companies want to set up their own infrastructure to network to *local* devices without depending on their ISP? Should access to my local network printer really depend on an address assignment from my ISP? Even for remote devices accessed via third-party infrastructure the increased use of VPNs may well mean that those remote devices will have addresses local to the the owner. |fourth, I don't buy that the existence of provider-based addresses is a |compelling reason to burden us with SLs. See #1. Dan Lanciani ddl@danlan.*com 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: Limiting the Use of Site-Local
I think it's great the folks are starting to consider the difficult problems associated with site-local addresses in particular and scoped addresses in general. In the past these have been glossed over with hand-waving arguments that scopes would ``just work'' with minimal application involvement and a little DNS magic. Before you try to solve the problems by effectively reducing scopes to a degenerate case of one and restricting site-local addresses to sites with no global addresses (or even with no external connectivity), please keep in mind that site-local addresses have been offered up as the solution to a number of other problems which themselves were difficult to hand-wave away. For example, the ability to have long-term tcp connections within a site in the face of global address renumbering has--given the lack of any protocol or application support for that renumbering--been pushed onto site-local addressing. (The problem is hardly confined to tcp, but that's the usual example cited.) Any language that reduces site-local addresses to second-class citizens (or, worse, implies that they should not be used concurrent with global addresses) will give stack and application vendors an excuse to fail to support such configurations. I don't think you want to open such a huge can of worms as it will entail revisiting every problem that has been ``resolved'' with an admonition to simply use site-local addresses. Dan Lanciani ddl@danlan.*com 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: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd)
Michel Py [EMAIL PROTECTED] wrote: | Dan Lanciani wrote: | An obvious reason would be that the one who wishes to subnet | the /64 is not the same one who should have used a /48, with | the former one having little control over the latter one. | |A dial-up connection gets a /48. It's not clear how you can make (let alone enforce) that generalization. Consider multiple dial-up connections to a system whose connection to its upstream provider is itself a dial-up connection. Your definition is self-contradictory in such a case. You can't hand out multiple /48s if all you have is one. Dan Lanciani ddl@danlan.*com 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: I-D ACTION:draft-savola-ipv6-127-prefixlen-00.txt (fwd)
Michel Py [EMAIL PROTECTED] wrote: [much snipped] |and I still fail to see a valid reason to subnet |a /64 when one should have used a /48 and subnet using the SLA |bits. An obvious reason would be that the one who wishes to subnet the /64 is not the same one who should have used a /48, with the former one having little control over the latter one. Dan Lanciani [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: DNS query over anycast
Robert Elz [EMAIL PROTECTED] wrote: |Date:Sun, 03 Jun 2001 20:18:55 -0700 |From:Randy Bush [EMAIL PROTECTED] |Message-ID: [EMAIL PROTECTED] | | | while one can not measure all dns transactions, a significant number of | | them use just such a 'misconfiguration'. please excuse our stupidity in | | wishing to continue to offer our customers better service. | |For v4 there is probably no other way. For v6 we're still early enough |in the grand scheme of things that we could easily change the DNS |spec (actually just the DNS clarifications - 2181) and require that |v6 based resolvers ignore the source address of a reply, and match the |reply to the query using the query ID and question alone. | |Using the IP address doesn't gain much really - it certainly doesn't |offer any protection against bogus replies - in reality it is little |more than one extra field to check. | |The requirement in 2181 is there not because the DNS protocol requires |it, but because the vast majority of resolvers deployed happened to |be implemented to expect it - that is, servers must send their answers |that way, or they will be ignored. | |For v6, there are essentially no deployed resolvers yet (almost all v6 |name resolution that is currently done is done using the v4 DNS), so |changing the v6 resolvers to simply omit that check on the replies |they receive (via v6), and process anything would not be a very difficult |change to make. One minor clarification. Existing sockets-based resolvers don't check the source address in some futile attempt to avoid bogus replies. In fact, they don't generally check the source address explicitly at all. The check is happening in the kernel as a side effect of the resolver's using a connect()ed socket. The resolver is using a connect()ed socket so that it can get a quick indication that the server is not running via a UDP port unreachable. This is important both in the case of a single server on the loopback address (in order to avoid having to time out during boot when the name server is not yet running) and in the multi-server case to quickly move on to another server in a list if the current one is not running (though the latter might better be accomplished by sending out requests in parallel). The original sockets API offers no other way to accomplish this interaction with UDP port unreachables. Fancy new APIs may allow the same thing to be accomplished by other means, but in any case you are talking about slightly more (structurally) than simply removing a check on the reply. Dan Lanciani [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: AAAA/A6 thing
the results. None of this can happen if IPv6 imposes exactly the same constraints as (current) IPv4. Dan Lanciani [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: AAAA/A6 thing
for NAT'ed addresses... | | Rather than attempt to solve the routing problem, IPv6 as currently | | envisioned simply redefines the temporary hack as a feature of the | | routing architecture. | |Yes. That's absolutely true. But it isn't a design aim of IPv6 |to do that, Could have fooled me... |it is just that no-one has yet proposed any other good |solution to the routing problem. My proposal was apparently good enough for the companies who applied for the patent (at least according to their posting to this list they applied). I just wish they had referred to my prior art... | | It expands the address space bit-wise, but preserves the economics | | of address allocation. | |I know what you mean (given the context) - but that isn't quite true. |There's another issue here that does change, radically. With IPv4 |you not only pay for stable addresses if you want them (really for the |ability to run a server) and even more for portable addresses - but you |also pay for the number of addresses you want allocated. The last of |those will vanish with v6 - there's simply no rational way for an address |block smaller than 2^64 (other than perhaps 1) to be allocated. Don't count on it. The ISPs will simply filter out all but the number of addresses that you have paid for. They won't care if they are wasting (2^64 - [number of paid-for addresses]) per customer. The big advantage (to ISPs) of IPv6 over NAT is that they can do this automatically. With NAT they have to use fairly subtle algorithms to try to detect and block extra hosts--so subtle in fact that it isn't really practical. With IPv6 all they have to do is populate a table with the first n 64-bit IDs and block any others. Perhaps if they are nice they will clear the table periodically so you can move IDs around. (Don't expect to be able to use rolling IDs for privacy.) If they are less nice they will tell you which IDs you can use. |But that doesn't mean that someone can't |go and make all of this work redundant by figuring out some smart way to |route to billions (of billions) (like 2^48 at least, 2^64 potentially) |individual addresses with no topological significance at all. If there's |someone out there with the solution all ready just waiting, then please, |let us know (even patent it, and then let us know). Discussions of the addressing issue always seem to end up here. It reminds me of an episode of the Simpsons where the father keeps saying, ``I'd like to do something, but there is nothing I can do'' while the daughter keeps telling him about the easy thing he could do... Others have presented solutions. I have presented a solution. A version of my solution has been patented unfortunately (or at least the companies claim to have applied for a patent). If anyone were serious about implementing a solution I'd be happy to argue prior art to invalidate the patent. I understand why you feel that it is necessary for packets to carry routing hints (and that's exactly what topological addresses are--routing information). As you said, FUD works, and a distributed routing model might be too radical a departure from existing practice to be easily accepted at this time. However, we do not have to foist these routing hints off on the end user as addresses. A portable identifier that is independent of the topological address solves a variety of problems. At some level the result must be isomorphic to distributed routing, but the extra level of indirection allows the solution to be more clearly visualized. And perhaps that's the important thing as far as FUD goes. | | Of course NAT will be used with IPv6. Why pay a per-address fee and then | | an additional fee to keep the address stable (at least in the short term) | | when you can maintain your own internal addresses with NAT? | |The keep the address stable part isn't helped at all by NAT. Sure it is. Sites care about internal stability as well as external. Site local addresses are yet another IPv6 hack that recognizes this fact and tries to partially mask the problem. |The |only advantage to stable addresses (aside from the problem of renumbering |your site) is where it is known to others. So you are saying that the only advantage of stable addresses (aside from internal use) is external use. Yes, I agree. :) |For most sites renumbering internally is already cheap - You must be very lucky; I have yet to encounter such a site. Dan Lanciani [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: AAAA/A6 thing
David Terrell [EMAIL PROTECTED] wrote: |On Tue, May 08, 2001 at 05:02:26AM -0400, Dan Lanciani wrote: |It's relevant unless you eliminate 6to4 and any other scheme that |generates portable v6 address space from v4 space. 6to4 is actually |rather interesting in that it has the potential to overtake native |v6 addressing (especially considering Microsoft's treatment of 6to4 |as a first-class citizen). Once 6to4 has served its purpose of |jump-starting IPv6 deployment and the time comes to kill it off in |favor of native aggregated addressing, the task may be more difficult |than was anticipated. If the bulk of users are on the 6to4 side, |simply severing ties to the native backbone won't do the trick since |that would hurt the native users more than the 6to4 users. It would |instead require action on the v4 backbone to block the encapsulated |6to4 traffic, and that might raise some eyebrows. | |Simply shutting down the 6to4 translators would have a similar |effect. Similar to what? Shutting down the public translators (I assume you mean the routers that have both a 6to4 address and a native v6 address) is exactly severing the tie between the 6to4 space and the native backbone. If most of the users are on the 6to4 side, this is not much of a threat (to the 6to4 users anyway). Communications between two 6to4 nodes does not require any public translator, and you won't be able to shut down the private translators within sites. As I said, you would have to block the encapsulated v6 traffic on the v4 backbone, and even that might become tricky if the 6to4 users band together and adopt some sort of encryption... Dan Lanciani [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: Wade through the archives (was Re: another renumbering question)
Nathan Lutchansky [EMAIL PROTECTED] wrote: |First, I can see a lot of advantages to having unique, non-routable site |prefixes. One big advantage I can see is that VPNs can be created between |arbitrary sites without worry of renumbering either site. If we can find |a way to implement site IDs in a reasonable manner, it would be a big win |for IPv6. [...] |Why not leverage the global DNS system to do this? DNS can be used to |assign ownership and do duplicate detection, and can also solve the |two-faced DNS problem. Here's how: [...] |VPNs between arbitrary companies could easily be created. [...] |The only possible unfortunate side effect that this may have is that, as |Steve pointed out, some unscrupulous ISP may begin advertising site-local |prefixes into the global routing tables. Or, turning this into a positive, when the (supposed) routing problem is solved and large routing tables can be accommodated, such advertising could be allowed. This would make for a smooth transition away from non-portable address space at some later time. |This system is probably the most flexible and low-overhead of all those |proposed in the last week, and requires relatively few changes in existing |code. My apologies if this scheme has been proposed already, but I'm on a |slow link and searching the archives is rather painful. -Nathan I don't know if your specific scheme has been proposed but, with a little tweaking to support automatic VPNs, it becomes essentially equivalent to my proposal for identity addresses (addresses that you can actually own without depending on the ISP not to pull the rug out from under you). I think your proposal exposes a bit more of the implementation to the application (or at least application-level resolver code), but I'd happily support it anyway. Either approach sidesteps the large-routing-table issues by pushing the initial lookups onto the DNS (a system which must be able to handle the load if IPv6 is to work at all) and distributing the rest of the routing decisions. I'm not sure that your approach would help with multi-homed sites as much as mine would, but that's probably a small price to pay for keeping the addresses in a form which could later simply be injected into the core routers when/if that becomes supportable. In the past there has been strong objection to allowing end users to own any kind of global (provider-independent) unique address (or address-like object) even if it is not directly routable. Perhaps now that 6to4 has let the genie out of the bottle it will be more palatable to allow users not fortunate enough to own any IPv4 space to play as well... Dan Lanciani [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: 6over4 for KAME (FreeBSD)
|i'm not sure if this is what you mean, but:
|
|http://www.kfu.com/~nsayer/6to4/
I think that might not be what he meant. :) However, speaking of 6to4,
how accepting are the 6bone sites of 0x2002 prefix addresses? At first
glance, www.6bone.net and www.kame.net are happy to respond to packets
from 6to4 addresses, but some of the public IPv6 "tool" web sites don't
have a route to any 6to4 relay at all (or at least that seems to be the
case). IMHO, 6to4 is a great way to encourage IPv6 deployment (especially
with Microsoft pushing it), but the addresses need to be treated as more
than a temporary hack if people are to commit. (Alternately, I suppose
6to4 addresses could simply overtake "real" addresses. :)
Dan Lanciani
[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: (NAT) IPv6 and NAT
| I've sometimes wondered why IPv6 doesn't have some number space that is
| "globally unique but not globally routable" that could be used for packets
| internal to a site.
|
|How do you get people to do even epsilon paperwork to request such
|space?
People seemed so willing to do such paperwork for non-routable v4 address
space that is was supposedly necessary to make the process hard/expensive to
discourage them from consuming it all. Offer the v6 space on the terms that v4
space was once available (i.e., free with nominal justification documentation)
and I'm sure people will use it. Try to make these allocations another cash
cow with yearly fees and, naturally, people will pick (poorly) random addresses
that will later hurt them.
The same argument applies to NAT. If ISPs make it expensive to get extra v6
addresses (based on the justification that addresses used to be scarce?) then
people will use NAT with IPv6. If ISPs make "stable" v6 addresses (i.e., ones
that they do not deliberately renumber frequently) a premium service then
people will use NAT. Although the standard claim is that NAT breaks the end-
to-end model we all like (and note that I have personally never liked NAT),
NAT shines at preserving the stable-address model that is deeply embedded in
many protocols and applications. NAT has already proved itself: many useful
applications work just fine in spite of the loss of the end-to-end model. The
renumbering model has yet to be proven, let alone retrofitted to many existing
applications.
I happen to think that ISPs will charge a premium for multiple and/or stable
v6 addresses because that is the status quo and because the market will bear
it. Thus, I suspect that NAT will remain quite active if/when IPv6 is deployed.
I think this is unfortunate--again, I'm no fan of NAT--but it's probably too
late to do anything. While it certainly would have been possible to structure
IPv6 in such a way that end users could allocate identity addresses independent
of their providers (I even made a hand-waving proposal to allow for this with
relatively minor protocol modifications) there never seemed to be much interest.
So the market pressures will continue to operate in an IPv6 environment just as
they have in the IPv4 one. All IMHO, of course...
Dan Lanciani
[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]
