domain names as end-point identifiers?
Dave, I think this depends on what problem you're trying to solve. In the case of mobility and multihoming, you might want a stable identifier on a per-packet basis which is independent of the routing layer. This is the classic problem that mobile IP solves, and I believe is also the jist of what HIP was trying to address as well (or at least one of them). One might even be able to make a case that an IPsec SPI could serve the same purpose. In all of these cases, a domain name per se would not work well since it's too big. As you point out, domain name as some form of session establishment seems plausible, but it is clearly not suited to the per-packet job which we have in various forms these days. Mike Dave Crocker writes: > Honest. I'm really sorry to have to send this query. > > In looking over various archives and documents, on the matter of separating > node address from node identifier, I have not been able to find or develop a > clear summary of the reasons the identifier cannot be a domain name. > > There are plenty of notes assuming that a new name space is needed. And there > are plenty of statements that say a new name space is needed because it will > make certain things better. > > But I have not seen a clear summary of what will be made better nor a clear > argument against using domain names, as the stable, public, > address-independent end-point identifier. > > I recall seeing a note from Christian Huitema that raised some interesting > concerns about using domain names, but I haven't been able to recover it. > > If the identifier is used only occasionally, such as at the start of an > association and during occasional state changes, then it is acceptable to have > the string be a bit long. If it must be in every packet, clearly it needs to > be short. If the identifier needs to be in every packet, then why? > > The string must be globally assigned only if it is needed for some sort of > rendezvous or third-party validation effort. Otherwise, the string can be > local to the association context, in the manner of purpose-built keys. > > So a new, global identifier space seems to be needed only if every packet is > subject to some sort of rendezvous or third-party validation. > > What am I missing? > > /d > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > > 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] > 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: Fourth alternative [was Re: Moving forward ....]
Brian E Carpenter writes: > Eliot, > > That seems to me to be orthogonal. I agree that it would be good to see > renumbering support (maybe it's a v6ops item??). But that doesn't destroy > the value of Bob's proposal. I disagree. What we seem to be dancing around with here is an aversion to dealing with the actual requirements of people who deploy networks. Even though Bob's proposal polishes the site local turd, it's still a dangerous stopgap and doesn't address _why_ this requirement for stability in the here and now is so strong, and the fact that we don't have a credible answer. Mike 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]
inevitability of PI
Keith Moore writes: > not true. in order to understand whether there's a potential > address conflict you need to consider the transitive closure of all > connections available to all hosts on the network. if the same address > refers to different hosts anywhere in the network then it can still > cause problems for apps doing referrals even if the meaning of that > address is well-defined for every individual host. In trying to formulate an answer to this it occurs to me that there's a better question to ask: if it is inevitable that we need PI space for disconnected networks, then do you concede that we will end up with (a) NAT's and (b) route growth (due to advertizing /48's) for people who decide to get and (ab)use them? I've seen nothing which would dissuade me of that notion, and plenty of evidence in the here and now that that's exactly what will happen. Since IPv6 does not have an adequate solution for renumbering -- and any such solution being the path of least resistance is highly dubious -- are we not in the same situation as IPv4 with respect to the inevitabilty of NAT's since global PI is inherently self-limiting due to route growth? Mike 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: inevitability of PI
Keith Moore writes: > > In trying to formulate an answer to this it occurs > > to me that there's a better question to ask: if it > > is inevitable that we need PI space for > > disconnected networks, then do you concede that we > > will end up with (a) NAT's and (b) route growth > > (due to advertizing /48's) for people who decide > > to get and (ab)use them? > > I don't see either of these results as inevitable. > > I think that we can make rules that say "no NATs in IPv6" and > "advertisements of PI prefixes on the public Internet should be > filtered" and that those rules will have a useful effect. They might not > entirely prevent either practice, but they may make them rare enough > that they do not cause huge problems. Enforced by whom? Heck, forget enforcement. *Voiced* by whom? > In the case of NATs, I believe users will be less eager to deploy > NATs in IPv6 because (a) the absence of NATs in IPv6 allows the Internet > to support new kinds of applications that will drive deployment and (b) > IPv6 gives users better ways to solve some problems (renumbering, > attachment of a home network) whereas in IPv4 NATs were the > best tools available. If people really, really want PI space -- which they manifestly do to isolate themselves from PA address changes amongst other things -- why does it not follow that they'd like to make those nice unroutable PI addresses that we so kindly provide to not have reach farther than was intended? As in, why doesn't the experience of RFC 1918 directly apply here? Even if you can get a globally routable PA provided address, would the network adminstrators who desire PI even want to deal with them? Because they're still faced with the daunting task of renumbering PA addresses if they use them which was... sort of the reason that they like PI addresses. > In the case of advertising PI prefixes, I believe ISPs will understand > the wisdom of filtering them. They might not start filtering them > immediately, but if routers get overloaded, the price of advertising a > PI prefix will increase rapidly. Sure. Which leads directly to NAT's to get around the perceived meanness of the ISP. > Of course, we do need to provide better solutions for scalable routing > renumbering, and multihoming. We also need a better security > architecture. My impression is that we are devoting too much energy > to freaking out, when there are important problems we need to be > working on. I dunno, is it "freaking out" when the end result of this exercise looks like the current IPv4 deployment except for a larger IP header? > In particular, we need to get ourselves out of the habit of crying "that > will lead to NAT" or "that will lead to route explosion" and using these > as excuses to stop investigating a solution path. Even when there's ample existance proofs that it will? It's sort of disingenous to claim Chicken Littlism when the ipv4 sky has already fallen. Mike 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: inevitability of PI
Keith Moore writes: > Hitler. This is pointless. Bye. Mike 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]
disconnected
Keith Moore writes: > > Quick question - you have been nay-saying on local-use addressing for > > as long as I can recall, but do you truly have an alternate proposal > > that will work for intermittently-connected/disconnected sites, > > disconnected sites - should use some sort of PI space - either > globally-unique or probably-unique So I have a question: what does "disconnected" really mean? Does it mean people who do not have any internet access whatsoever and never will? Or does it mean people who want parts of their network to be either physcially or through firewalling to be disconnected from some or all of the net? If it's the former, maybe I'm heretical but do we really much care? Back in the bad old days that led to what what's been morphed now into the "documentation prefix", but 10 years ago disconnection from the Internet was pretty much the norm... today though? Should we really fall all over ourselves for individuals/organizations that don't want to pay $9.95/mo and get a PA /48 that they can use to number their disconnected network? If it's the latter... a /48 gives 16 bits of subnets. Surely that's enough to carve out a network or two for their disconnect networks. And even if they changed providers... so what? If it's a disconnected network using the old prefix certainly doesn't _hurt_ anything until... you want to connect it, but if you want to connect a disconnected network you needed to renumber anyway! What am I missing? Mike 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]
Moving backward [Re: Fourth alternative [was Re: Moving forward ....]]
Brian E Carpenter writes: > Michael, > > Sorry, but I think you are dead wrong, and you are moving us backward > and risking another year or two of wasted time. > > There is nothing new in this whole argument. As I pointed out > in the IAB architecture session in Vienna, these issues have been > around for 6 years at least. We know what we can do with today's > routing mechanisms, today's renumbering mechanisms, and today's > security mechanisms, and that leads *directly* to the requirements > in the Hain/Templin draft, and IMHO *directly* to the solution in > the Hinden/Haberman draft. Which leads *directly* to NAT's at "local" boundaries and /48's in the DFZ. And Fred's draft really shows how little we know about renumbering in the real world. > I think we are way past the point in history where it is fruitful to > make the sort of free-space wish-the-world-was-different analysis > you are advocating. Hinden/Haberman leads to simple, straightforward > changes to shipping code and that's all we can afford now. I'm having a very difficult time reconciling what you're saying here with your "Let's abolish" post. It's almost like you're saying we should do nothing at all. While nothing is often better than a bad something, in this case there's shipping product to fill the vacuum: NAT's. And they are well understood given their v4 deployment. Is that what you're ceding? Mike 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: Fourth alternative [was Re: Moving forward ....]
Fred Templin writes: > Mike, > > Let me see if I can understand your concerns better. It seems to me > that your main objection to the hain/templin draft is that you see it > as implying a particular solution genre, that being a limited range > addressing scheme to replace site-locals. If this is what you find > objectionable, then may I assume you are of the opinion that site > locals don't *need* to be replaced? If so, then it seems you would > favor an IPv6 addressing architecture that contains only link-local > and global unicast addresses, i.e., nothing in between? My inclination is that limited scope (excluding link local) is extremely problematic, but that's not really my larger point. The larger point is that there are a set of requirements that are driving people to use NAT's in ipv4 today, some of which are well addressed by ipv6, some of which are not as well addressed. And suspect that we all know that ipv6 will get NAT's if those bread and butter requirements cannot be met easily... NAT is the devil they know right now, for better or worse. However, limited scope addresses are but *one* way to deal with this set of requirements. What I think has been getting short-shrift here is that it seems to be a foregone conclusion amongst many people -- especially those who were not in favor of deprecation -- that the set of engineering tradeoffs amongst the options is well known and that local scoped addresses are the lesser of evils. I find that far from clear, and to my knowledge this working group has never formally evaluated those options or even enumerated them for that matter. I think it would be wise to take on that work, so that we can make an informed documented decision, and hopefully come to consensus with our eyes wide open. > The hain/templin draft discusses requirements for sites that frequently > change provider points of attachment, sites that are disconnected or > intermittently-connected to providers, sites that merge with other sites, > etc. I think your draft would make a fine starting point for the work I think needs done if it were morphed into something that didn't proceed from a solution and work backward as it seems to do now. > In these cases, we require local application stability independent of > any provider-assigned addressing. This requirement is not satisfied by > link-locals for medium/large sites that comprise multiple links. Thus, > all we have left are globals and the only way the "active" sites I described > above could use these would be if the global prefixes could be obtained > independent of any provider. Fine; so this just means that the sites would > get their own prefixes and tell providers which prefixes to advertise > instead of the other way around - right? > > This would all be fine were it not for the fact that it would lead to > immediate global routing table explosion on the order of the number > of sites that procure their own prefixes which could be quite large. > I'm willing to suspend disbelief and say that sometime down the > road we might have a solution for scalable global routing, but in > what timeframe can we expect to see something like that deployed? > 1yr? 5yrs? 10yrs? longer? > > Scalable global routing in a flat addressing space certainly seems > like a utopian scenario if it can be achieved. But, if the deployment > timeframe is looking like mid/long term, then we still need some > sort of replacement for site-locals in the near term - right? It's all of these questions and tradeoffs etc, which I think need to be *documented* and that we need to get rough consensus about the *problem* space itself. I don't believe after googlebytes of email on site locals we even have consensus on what problems must be solved in order to have a deployable IPv6 without NAT's being a necessary evil. Also: I think we are far away from actually determining that the principle alternatives (renumbering, PI) are dead letters, or that there aren't other more creative ways of solving for the problems/requirements. Brian thinks this is a waste of time, I respectfully disagree. Mike 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
Margaret Wasserman writes: > > At 05:25 PM 8/5/2003 +0200, Brian E Carpenter wrote: > >I'll go for B, or perhaps A.9 (i.e. a version of B in which > >we avoid recursive normative references between the two documents). > > If your version A.9 existed, I would have chosen it... > > I don't much care for the idea of gratuitous normative references, > but I do believe that it makes sense to deprecate SLs and publish > their alternative at about the same time. This assumes that the consensus will be found quickly for their replacement. I find that *highly* dubious. The net result, IMO, will be effectively ignoring the consensus in SF to deprecate. Years passing before we publish the deprecation document will effectively make it a dead letter. Oh, sigh me up for "A". Mike 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]
What to do with FEC0? [was Re: Moving forward on Site-Local and Local Addressing
Brian E Carpenter writes: > Zefram wrote: > ... > > I'm expecting, by the way, that the deprecation will leave fec0::/10 > > to be treated as global-scope unicast addresses, rather than making > > fec0::/10 addresses cease to function altogether. > > That's an interesting expectation. As co-author of the planned > deprecation draft, I'd been assuming a more classical deprecation > action, in which we would simply state the previous semantics of > FEC0::/10, state that the prefix SHOULD NOT be used, but leave it > permanently assigned by IANA. > > This would break nothing that runs today. > > What do people think? If you truly want to deprecate FECO::/10, I'd say that it shouldn't be reserved to IANA, but given to registries with explicit mandate to allocate it immediately. :-)/2 Mike 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 backward [Re: Fourth alternative [was Re: Moving forward ....]]
Brian E Carpenter writes: > Michael Thomas wrote: > > Which leads *directly* to NAT's at "local" > > boundaries and /48's in the DFZ. > > As has been said by various people, all this is somewhat orthogonal to > whether NAT's appear. If we provide > a) unambiguous provider-independent prefixes > b) good mechanisms for running with these *in parallel* with routeable > provider prefixes > c) site multihoming > d) renumbering tools > > we'll have done about all we can do, I believe, to make NAT unnecessary > and more painful than the alternative. But as usual, it's not the > IETF that decides what gets sold and used. It seems to me that in order to make "progress" you seem to be saying that I have to make a leap of faith that non-globally routable provider independent addresses will not be abused. That is, that people will not try to make the globally routable by either NAT'ing them, or getting providers to advertise the prefix. I'm sorry, but nothing that goes on today gives me any reason to make such a leap. > > And Fred's draft really shows how little we know > > about renumbering in the real world. > > > > > I think we are way past the point in history where it is fruitful to > > > make the sort of free-space wish-the-world-was-different analysis > > > you are advocating. Hinden/Haberman leads to simple, straightforward > > > changes to shipping code and that's all we can afford now. > > > > I'm having a very difficult time reconciling what > > you're saying here with your "Let's abolish" post. > > Why? My point about the existing notion of scope is > that it is not useful, so we can drop it. Well, I don't disagree. My larger point is the desire for scoped addresses are a symptom of requirements not being met (duh) but the heart of the problem is that they are ignoring other serious problems and/or requirements in their rush to make a stopgap. Having all of the requirements well know would be extremely helpful so that the deficiencies can be evaluated instead of swept under the rug. > No. I'm very frustrated at how slowly all this has developed, > but we should certainly get a) through d) above done. What do you propose? The sticking point is and has for a very long time been (a). You see it as resolved, I don't. Why should I believe that this will not result in NAT's, exponential route growth, or most likely both? Also: you I believe questioned the very premise of whether "local" applications (eg, could use non-globally routable addresses) were even particularly useful in real life. If that's true, then what problem is (a) solving? Mike 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: Fourth alternative [was Re: Moving forward ....]
Tony Hain writes: > Michael Thomas wrote: > > The problem is that this draft proceedes from the > > premise that the answer is consing up limited > > range addresses. > > It is not intended to. It is trying to point out the requirements that > network managers have. It uses examples where they have found limited range > addresses meet the need to explain it for those who don't believe their > requirements are real. Tony, quit patronizing me and everybody else. I've not seen one person here who is insensitive to the actual needs of network managers. What I've seen is differing opinions of how to weigh the conflicts and most especially what the long term implications are of any particular approach. Your trying to frame these conversations as a one-man crusade against the IETF ivory-tower is lame and insulting. Your draft is not helpful because it starts out with a conclusion and works back from there, much like yellowcake and WMD. The bias is in the title of the draft, for gawd sake. What we really need is something that lays out all of the requirements -- and local scope is not a requirement, it's a solution -- and tries to analyze the problem space without bias to a particular solution; laying out the good, bad and the ugly for each possible approach. > > > That's incorrect and not > > helpful. We need to start by determining what the > > *requirements* are, > > That is the point of the draft. It fails. See above. > Unfortunately some on this list want to > argue that some requirements are not real, rather than accept that different > situations create different requirements. Given that not everyone has > expierenced every situation, the draft needs to provide enough context > around a requirement so that others can see the issue. And now your patronizing the group again. Stop it. > > and only then outline what the > > range of solutions are, and what their problems > > and possible consequences are. Until we can get an > > consensus on what we need to do, and what the > > engineering tradeoffs are, we will never come to > > closure. > > Yes and no. There is no way to achieve a single optimal solution for the > diverse set of requirements, so we know the outcome will be a compromise. > Bob's draft (as did the others to randomize SL) meets the requirements in > the current draft. You mean the requirements of "do no harm wrt NAT and DFZ route pollution?" Oh, golly, I guess I didn't find those in the draft. Both of these requirement are downsides of limited scope addresses approach, btw. > > That in a nutshell is why I have a problem with > > the religiosity on both sides of this argument. > > My religion is that the deploying network manger is right, no matter what > the IETF decides. If the IETF decides to provide tools to make deployment > easy, that will be the path of least resistance. If not, the network manager > will demand ad-hoc tools to get the job done. Aside from the preposterous notion that you're the torch bearer of the poor under represented network manager (::snort::), this isn't helpful because what we need here is to balance out the conflicting requirements both in whose work load is affected, as well as the general architecture of the net. The network manager is *one* voice that needs to be considered, not the *only* voice. Mike 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: inevitability of PI = 3
Christian Huitema writes: > Hey, we can legislate whatever... I'm legally bound to Godwin's Law. Mike 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: site-local observations from the outside
Bound, Jim writes: > Even better yes. They "can't". So how does one accomplish this? Since there's plenty of $$$ to be made for !NEVER, am I to believe that the IETF has a new found ability to transport moral turpitude over IP? Mike > /jim > > > > > >-Original Message- > >From: Michel Py [mailto:[EMAIL PROTECTED] > >Sent: Saturday, August 09, 2003 3:12 PM > >To: Bound, Jim; [EMAIL PROTECTED] > >Subject: RE: site-local observations from the outside > > > > > >Jim, > > > >> Jim Bound wrote: > >> If we simply say these NEVER leave the site then all > >> is fine. Thats the bottom line. > > > >I'm ok with that. Not only never leave the site but making > >sure that they can't. > > > >Michel. > > > > > > > > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > 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: Fourth alternative [was Re: Moving forward ....]
Eliot Lear writes: > I'd like to put Fred on the spot (not having asked him) and propose that > his draft be adopted as a WG doc. I'd like to second that. Fred's document if nothing else shows how close we aren't to meeting the operational goal of renumbering without significant blood-letting. Also: Fred's document is aimed at a solution for somebody with enough leverage to join the providers BGP cabal. While that's a start, it doesn't explore this problem nearly enough, IMO, especially for BGP have-nots. Mike 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: Fourth alternative [was Re: Moving forward ....]
[EMAIL PROTECTED] writes: > If you think the document has a scoping issue (no pun intended), > then let's discuss that with a measured tone. Yes, I think it has scoping issues. A name change, for starters. It should first lay out requirements of network operators, etc in terms of what they need to accomplish not how they can accomplish it. Take as a very large for example, address stability. That's not the requirement, per se. What they want is for topology tweaking to not adversely affect running applications. However protocols such as TCP are incapable of sustaining sessions across address changes which is typically needed when you want to move topology around. That's the reason I say that "stability" is a solution, not a requirement. Keeping addresses the same is *a* way of keeping applications from breaking, but not the only one. Mobile IP obviously comes to mind, and there are other ways we could envision like Fred's attempt at operational renumbering. Another example is your "well known prefix". I'd think that the requirement is that certain services and/or classes of devices need to be isolated and/or invisible from the other parts of the net. A well known prefix is a way to do that, but it doesn't necessitate local scope and again isn't the only way to wall stuff off. I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. That's not what we need right now. We need something that tries to be unbiased about the ultimate compromises we're going to have to make by saying what we want (requirements), what the possible frameworks are for addressing the requirements, and most especially what their possible downsides are. We don't need boosterism which tries to paper over the warts; all possible solutions have problems, what we need is an honest evaluation so that we can decide which path is the least objectionable. Mike 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: apps people?
Christian Huitema writes: > > The few self-described apps people I've seen take > > a stand have to my recollection been strongly > > against dealing with locally scoped addresses . > > Let's be clear. Our group (Windows Networking) has received a lot of feedback from developers of applications on the Windows platform. The negative developers' feedback was mostly centered on the difficulty of identifying the scope of an address, specially when a node is connected to several sites (e.g. home network and VPN to the corporate network), or when a node moves from site to site. Which is to say, topology information which it didn't have to consider in the past and for which it has little information at its disposal from which to make decisions. Do you mean to imply that their negative feedback is overblown? Because requiring hosts to be topology aware seems like Pandora's box to me, and they have good reason to be uneasy about where this is leading. Mike 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]
apps people?
The few self-described apps people I've seen take a stand have to my recollection been strongly against dealing with locally scoped addresses . Have I missed anybody? It seems to me that people with strong app and/or host kernel background ought to be given a disproportionate voice in the consensus here as this is really their ox who's being gored. Mike 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: Fourth alternative [was Re: Moving forward ....]
Brian E Carpenter writes: > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Eliot, > > > > > > That seems to me to be orthogonal. I agree that it would be good to see > > > renumbering support (maybe it's a v6ops item??). But that doesn't destroy > > > the value of Bob's proposal. > > > > I disagree. What we seem to be dancing around with > > here is an aversion to dealing with the actual > > requirements of people who deploy networks. Even > > though Bob's proposal polishes the site local > > t***, it's still a dangerous stopgap and doesn't > > address _why_ this requirement for stability in > > the here and now is so strong, and the fact that > > we don't have a credible answer. > > "Why" is addressed in draft-hain-templin-ipv6-limitedrange-00.txt > That document may need more work, but it certainly attempts to > answer the question, convincingly to my mind. The problem is that this draft proceedes from the premise that the answer is consing up limited range addresses. That's incorrect and not helpful. We need to start by determining what the *requirements* are, and only then outline what the range of solutions are, and what their problems and possible consequences are. Until we can get an consensus on what we need to do, and what the engineering tradeoffs are, we will never come to closure. That in a nutshell is why I have a problem with the religiosity on both sides of this argument. Mike 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
Bob Hinden writes: > If this means globally routable provider independent addresses. Then it > is, of course, correct that this would solve many of the problems > too. Unfortunately, there is a big problem why this isn't a practical > choice we can make now. We don't have, IMHO, any idea how to make > globally routable provider independent addresses work at scale in the > Internet. There are a number of problem area. Bob, The issue I have is that there are a number of problems that are all interrelated in various ways: renumbering, multihoming, mobility, address stability, etc which we as IETF'ers need to take into consideration for building a net which will be useful 10 years from now. I suspect that there is no "right" answer aka silver bullet because of all of the conflicting requirements, so the ultimate answer is likely to be some form of picking palatable poison (ppp for short). You're certainly right that we have no good clues as to how to scale PI up to Internet scaling. On the other hand, we know that NAT's will step in the second that they are expedient and solve a problem -- inelegantly -- not feasible other ways. And we all know what a horrible hack NAT's are. Nor do I see how anybody can suggest with a straight face that there will not be NAT's which bridge local addressing domains with the global addressing domain. It wouldn't even surprise me that that even happens today; heck I probably know the product manager responsible for it. But I'm sorry, if NAT's become a de-facto necessity for v6 native networks (putting aside the need for v4/v6 NAT's), then I find the entire premise of ipv6's utility deeply undermined. Quite possibly fatally. So without trying to be too preachy, I think that we really should have a preponderance of evidence that we absolutely, positively cannot make either PI and/or renumbering based solutions work in a way that people can deploy and use them. I fully understand the compelling arguments of Moore's law and disaggregated addresses in the current internet. Obviously any PI solution could not be naive. However, it doesn't seem to me that there's been nearly enough work to develop a PI friendly Internet. And even though Fred's operational renumbering uncovered all kinds of other intractibilities -- especially as you want to scale it down to smaller networks, I still think the jury is out. Also: we can be pretty certain that any PI solution and/or renumbering solution if it exists will highly likely have serious warts. But this needs to be compared to alternative: NAT's. NAT's being required to deploy in real life basically says that the internet stupid-network/global addressing design was flawed. Are we really ready to make such a pronouncement? Are we ready to say that global transparency lost the argument? The market place pretty much says that, but are we ready? Maybe this train has long since left the station and the IETF is impotent change that, but it sure seems to me that if we cannot solve this in such a way that NAT's aren't the inevitable result (eg, the path of least resistance) then we should immediately change tacks and embrace addressing realms and ALG forwarders through those realms as an architectural principal. Thus, a lot is riding on this IMO, and my feeling is that the vehemence of the uncomfort with locally scoped addresses is that it tacitly concedes our inability to keep with the architectural principal of a dumb globally addressed network. And I also get the feeling that there is not anything approaching consensus to admit defeat on that architectural principle, so even these small sensible steps that you propose nonetheless seem grave in their global implications. So if we can't deal with requirements of address stability and/or renumbering, etc without non-global addressing realms, let's document it, reassess our architectural principles, and move on. Until then, we're just pushing off the inevitable confrontation: a confrontation which IMO will decide the shape of the net for years to come. Quite frankly the marketplace will decide for us with NAT's in the mean time, no matter how much myself or anybody else whines about it. Let's at least drive this to a conclusion one way or the other from an engineering standpoint to see if this is both technically and economically hopeless. Until then, we're just gnashing. Mike 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
FWIW, I wasn't there but I agree with Alain. I've never seen any compelling evidence that scope qua scope is what people actually need. And scope brings any number of architectural questions to the fore. I'd be much, much more comfortable having an up/down pronouncement on whether PI addressing is feasible before we march down this road. There are very wide implications of both and I think there's a tremendous amount of discomfort with the possibility that scope will result in a back door for NAT's to invade ipv6. I don't think that anybody wants that. Before we head that direction, I'd like to see PI addressing, in an RFC preferrably, pronounced a dead end. Mike Alain Durand writes: > > > Bob Hinden wrote: > > > [IPv6 working group chair hat on] > > > > I think the working group has been making good progress on replacing > > site-local addresses and wanted to get feed back from the working > > group on how we should move forward. This is not intended to directly > > relate to the ongoing appeal of the working groups decision to > > deprecate the usage site-local addresses, but to get feedback on how > > to proceed. I think it is very important that we move forward on this > > issue and not rehash what has happened in the past. > > > > We now have a combined local addressing requirements document > > , a specific alternative > > to site-local addresses draft > > (accepted as a working > > group item at the Vienna IETF), and will soon have a draft describing > > why site-local addresses are being deprecated and doing the formal > > deprecation (authors identified and outline discussed at the Vienna > > IETF). Note that all of these documents will proceed through the > > normal working group and IETF processes of last calls and review. > > > > I think legitimate questions have been raised about how the working > > group should go about deprecating site-local addresses given their > > maturity in the current specifications and use in deployed products. > > Specifically should they be deprecated independently from having an > > alternative solution available, at the same time an alternative is > > available, or sometime after an alternative is available. A forth > > alternative is to not replace site-local addresses in any form, but I > > think the working group has made it clear that this is not a > > reasonable alternative. > > I have a real problem here. As I commented in Vienna and is mentioned in > the minutes, > the entire process this wg is going through is wrong as it is based on a > flawed logic. > > We had site local addresses. After lengthy debates, the wg realized that > there were > a number of significant issues that outweighed the reported benefits, so > there > is an attempt to deprecate them. Until now, fine. > > Now, some people convinced the wg that SL addresses were having a role > that is not fulfilled by provider aggregated addresses. Fine again. > > Then, we have a 'requirement' document that pretend to explain why we need > 'local' addresses. If you read it carefully, and as acknowledged by one > of its main > author in Vienna, almost all of those requirements (if not all) would be > fulfilled > by provider independent addresses. Actually, there is nothing in it that > explain why we need 'local range' addresses. The essence of those > requirements is in the need for stable addresses that are > independent from ISPs. > > So using this document (I checked the new combined one, it is the same > issue) > to justify introducing "local" addresses and doing so without clearly > understanding the impact of those "ranged" addresses on the architecture > and the current implementation is a flawed process. > In particular, we need to understand the impact on address selection, > and the layer violation that would be created by coupling DNS views & > routing. > > IMHO, what need to happen is the following: > > -1. Make an in-depth study of the consequences of introducing > addresses with different ranges. > > -2. Realize that if the issue at stake here has more to do with getting > addresses > than with their actual scope/range, something probably can be > done working with the registries. It might be a cheaper path > than changing the protocols. After all, IPv6 addresses are plentiful, > we should have easy access to them! > > What to do with Site Local addresses in the meantime is a non issue for me. > > - Alain. > > > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] >
anti-SL == flat-earth society (was RE: avoiding NAT with IPv6)
Tony Hain writes: > Michael Thomas wrote: > > ... Scoped addresses as have been pretty well > > demonstrated take us down some pretty scary paths. > > This sums up the whole anti-SL campain, which is spread FUD [...] *plonk* Mike 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
Dan Lanciani writes: > 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. Sure, but until then what does IETF do? There seems to be a tacit game which is being played out here which is "don't encourage NAT" which see-saws between the architectural principles of the NAT-less internet, and the reality of NAT's being present. And NAT's will most likely exist going forward primarily because we don't have any assurance of stability of address space (eg PI). There are some who would like to embrace NAT as an architectural principle -- not necessarily here, but they clearly exist -- some who hate NAT's under any circumstance, and then many people in the middle who don't like NAT's and the implications of NAT's being an architectural principle (like the Thou Shalt Consider Security edicts from the IESG these days), but are more pragmatic about their existence. As in, what should we do to minimize the damage? The deal I personally have made with this devil is to realize that we're not going to stop their use until all of the reasons you enumerate are addressed, but in the mean time I'd assume we bide our time and not throw in the towel on a NAT-free world. What this pragmatically means is making NAT's a poor a relation as possible so that we aren't trapped in the quagmire of making it an architectural principle which must be addressed from the outset. It also means turning our back on things that are obvious problems and often let them get hacked on outside of the IETF context. Thus, the fundamental argument going on here is: how much do we allow ourselves to be sucked down the this rathole? My opinion is "the less, the better". Site locals will without any doubt in my mind be primarily used as a replacement for net 10 address space -- all of the other purported uses are marginal, redundant or false-secure. This is why I think pointing would-be site-local people to 6to4/net 10's is probably a good compromise since it shunts the problem off into legacy land, and allows us to postpone having to make decisions about the true implications of routing scope with traditionally routing-dumb hosts. This is obviously unsatisfying for those who would like a more long term solution, but... well, we ain't there. Until we've convinced ourselves we really have no choice but to embrace NAT as an architectural principle since we can't resolve your laundry list of reasons people use them, doing nothing -- or next to nothing -- looks like a pretty reasonable option, IMHO. Taking the *wrong* direction at this point could be extremely harmful. Scoped addresses as have been pretty well demonstrated take us down some pretty scary paths. Let's not go there... yet. Mike 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]
CONSENSUS CALL: Deprecating Site-Local Addressing
Yes, nuke site locals.
Mike
Margaret Wasserman writes:
>
> Hi All,
>
> At the IPv6 WG meetings in SF, we reached consensus on several
> points, all of which will be confirmed on the IPv6 mailing list.
> One point in particular seems to be the source of discussion
> on our list and elsewhere, so we will check this consensus on the
> mailing list now. Specifically, we would like to check the consensus
> of the IPv6 WG regarding the deprecation of site-local addresses.
>
> This email asks those that were NOT present at the Thursday IPv6
> meeting in SF to express their opinions on a question that was
> asked of the room. If you expressed an opinion on this issue in
> SF you can skip this message; in any case you MUST NOT respond to
> this query.
>
> By now, all of you have heard about the IPv6 meeting held on
> Thursday, March 20th, where we discussed what to do about
> IPv6 site-local addressing.
>
> At the meeting, the chairs (Bob Hinden and Margaret Wasserman)
> changed the agenda to include a joint presentation by the
> chairs on various options for site-local usage. There were
> no objections to the agenda change.
>
> The chairs' joint presentation can be found at:
>
> http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt
>
> After the chairs' joint presentation, there was over an hour of
> lively discussion that covered many aspects of site-local
> addressing. Draft minutes of the discussion can be found at:
>
> http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt
>
> These minutes are a summary of the discussion, and they did
> not capture every detail of the discussion.
>
> During the discussion, it became clear that the "exclusive" model
> proposed by the chairs had some fundamental flaws and was not
> a viable option. The WG was unwilling to choose between the three
> options presented for site-local usage ("limited", "exclusive" or
> "moderate"), believing that all three models represented a poor
> cost vs. benefit trade-off. And, as the discussion developed, it
> became clear that there was growing support for deprecating
> site-local addressing.
>
> After the usual discussion regarding the phrasing and meaning
> of the question (not all of which was captured in the minutes),
> the chairs asked a yes/no question: "Should we deprecate IPv6
> site-local unicast addressing?" There was clear consensus in the
> room to deprecate site-local addressing. So, now it is time to
> check that consensus on the mailing list.
>
> In order to get a good read for consensus on this point, PLEASE
> adhere to the following rules:
>
> NOTE: DO NOT reply if you already expressed an opinion during
> the IPv6 WG meeting in SF!
>
> - Make your response very clear (YES or NO).
> - Respond by Monday, April 7th, 2003 at 5pm EST.
> - Do NOT respond if you were physically present
> in SF and participated in the consensus
> call at that time (We are trusting you!).
> - Respond to this thread with the subject intact.
> - Respond only once.
> - Clearly identify yourself (in the From: line or
> inside your message).
> - Include the IPv6 WG mailing list in your response
> ([EMAIL PROTECTED]).
> - PLEASE do NOT start any discussion in this thread
> (Discussions are encouraged in other threads).
>
> Any responses that do not adhere to these rules may not be counted.
>
> The question is:
>
> Should we deprecate IPv6 site-local unicast addressing?
>
> Valid responses are:
>
> "YES -- Deprecate site-local unicast addressing".
> "NO -- Do not deprecate site-local unicast addressing".
>
> If you express an opinion not to deprecate site-local addressing, it
> would be helpful if you would provide a reason. Providing a reason
> is completely optional, but it may help us to determine how to move
> forward if the consensus to deprecate site-locals does not hold.
> Possible reasons include:
>
> - Site-locals should be retained for disconnected sites.
> - Site-locals should be retained for intermittently
> connected sites.
> - Site-locals should be retained for their access control
> benefits.
> - Site-locals should be retained as a means for internal
> connections to survive global prefix renumbering.
> - Other (please specify).
>
> Please, make your response _very_ clear (either YES or NO), or it will
> not be counted.
>
> Please Note: DO NOT respond if you already participated in the
> consensus call at the meeting in SF. At the meeting, there were
> 102 people who raised their hands for YES (deprecate site-locals)
> and 20 people who raised their hands for NO (do not deprecate
> site-locals). We will add the responses received on the mailing
> list to the hands counted at the meeting,
RE: A use for site local addresses?
Michel Py writes: > >> Pekka Savola wrote: > >> People didn't see the need for RFC1918 space in IPv6. > > Because of site-locals. With site-locals gone it is an entirely new ballgame. There > is a need for private addresses, people will use them no matter if they are > site-locals, 6to4 addresses with a v4 RFC1918 address or plain hijack of a global > prefix like in the good old days. Then someone will write an RFC to try to contain > the hijacks into a well-known range. I have a sense of déjà vu. There is some appeal to 6to4 and 1918... it keeps the problem within the cesspool of current usage and doesn't try to rationalize it any further. A maze of twisty addresses, all alike... Mike 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]
renumbering/multi-addressing [Re: Enforcing unreachability of sitelocal addresses]
Pekka, It seems to me that you left out the most nettlesome problem about why people want address stability: name mappings, both in the form of DNS and everywhere else you find raw IP addresses floating around. In many ways, this mimics the Y2K problem in that it's very hard to gauge _what_ exactly might break until you do a complete assessment. And the complete assessment is enough to scare the timid woodland creatures away. Until there's a realistic way for people to pull the lever and make a switch, there's going to be a lot of back pressure to keep address stablity regardless of how harmful their means of keeping stablity is to the net at large. Mike Pekka Savola writes: > Hello, > > I added multi6 on Cc: list for this particular piece of the thread. > > On Sun, 26 Jan 2003, Margaret Wasserman wrote: > [...] > > 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. > > There are multiple reasons why people want PI addresses. Renumbering and > multi-addressing has multiple different models. Some are easy and some > are very difficult. We should develop at least the _easy_ solutions > because they are probably useful too. For now, it's enough to manage the > first 80% of the problem. > > Consider four reasons why people might want PI, routable addresses: > > - "I don't want to be in problems if my ISP goes bankrupt!" > ==> multiple addresses are just fine here (deploy them before the ISP > goes down, but use only one set of them etc.) > > - "I want to be able to change ISP's at will reasonably easily, to keep an > edge" > ==> multiple addresses are fine here too! > > - "I want to be able to protect against failures in my link(s) to my ISP > and problems in our router(s)" > ==> multiple addresses can deal with that too, with some added glue! > > - "I want to be able to protect against failures in my upstream ISP" > ==> tough cookie, no solution here! > > Get the picture? Greedy folks want it all, but actually we _can_ provide > quite a bit of it already! > > > Choices seem to be: > > > > (A) Continue with PA addressing, and accept that enterprises will > > use IPv6 NAT to get provider-independence. > > (B) Allocate PI addresses, and trust that we can determine a > > scalable PI routing scheme before we hit route scaling > > issues in the IPv6 backbone. > > I don't comment on these except that you seem to be making some > conclusions I don't agree on. I don't think PA equals IPv6 NAT, not at > all. There are solutions there. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oykingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > 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: Taking two steps back (Was: Re: one question...)
Michel Py writes: > There is no relation. What we are trying to do here is to remove the > ambiguity of site-local addresses, not to create globally routable PI. > These are different topics. This is not entirely clear. There seems to be a fair amount of cake-and-eat-it-too going on here when people start talking about interconnecting different sites. Mike 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: Taking two steps back (Was: Re: one question...)
Pekka Savola writes: > But this discussion is pretty much useless until we have a draft about the > problem statement, as it affects which kind of properties are useful. I agree with this. I'm having a *real* hard time figuring out the set of problems that people are claiming could be solved. Mike 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: even one reason why provably unique SL is needed?
Steven M. Bellovin writes: > Don't forget mergers and private interconnects. The latter are *very* > common, even without counting telecommuters. One shouldn't use > site-local there, but it's a path that often bypasses firewalls and > other official demarcation points. > > If interconnections never occur, we don't need to worry about the > problems that can happen. My fear is that they occur all too often. > (What percentage of queries to the root name servers come from 1918 > addresses?) Am I the only one that finds the term "private interconnect" somewhat specious? As in, if people make larger x-realm internets by plumbing their own wires instead of through an ISP, why should that be thought of differently than the Internet? Maybe that's why this entire concept is so unsettling to me. Mike 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]
one question...
[] So I've been watching this debate about globally ~unique site locals and I don't understand how the end node knows whether a particular destination address is in scope (reachable) or not. The old way, it just matched it to its own scoped prefix and was done with it. What I've been hearing is some desire to be able to patch together other sites (extranets)... how would a node know which scope address to use in that case? Mike 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: MIPv6 and ND value changes
So I listened to this argument for a very long time (too long) yesterday wondering what on earth the big deal was. I still don't get it. If people want to dial up the ND rate, it only hurts their link. There's no greater internet impact that I can see. If it's taking up too much bandwidth, a sniffer would show it pretty quickly and you turn the knob down, so wo cares? That said, I do think this is a pretty poor substitute for L2 information which probably should be making its way up the driver. Mike Erik Nordmark writes: > > MIPv6 does not say router should send RAs more frequently. it > > just says access routers SHOULD be configurable to send RAs > > more frequently. this is to be used in the absense of any L2 > > help. > > Vijay, > > One part of the problem I see is that your last sentence above doesn't > appear in the draft. Getting the applicability of the frequent unsolicited > RAs stated is important. > Doing this in a short separate draft doesn't have to delay the mipv6 > spec, but working out the text before the mipv6 spec get last called > will add delay as far as I can tell. > > Erik > > > 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] > 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
Richard Draves writes: > > > Yes, needless complexity is bad. But site-locals don't add any > > > significant complexity to applications (which I think I've > > demonstated > > > enough in too many emails already). > > > > this is only true if globals are always available to any node > > that potentially participates in an application that > > communicates off-site - > > which essentially means any node in any network which has an > > external connection. > > So to restate - Keith, it sounds like you now agree, that with a > reasonably small amount of additional complexity, apps can function in a > network environment that has both globals & site-locals - subject to > your condition about globals being available for apps that communicate > off-site? > > Certainly - if a node is going to run an application that communicates > off-site then it needs a global address. I mostly agree with the second > part - I would say any general-purpose node in any network which has an > external connection should have a global address. > > However I think we will have limited-function nodes, which run a fixed > set of applications, and if those applications do not need globals then > the node does not need a global address. I think the vendor of one of > these devices should have the freedom to determine the device's "out of > the box" configuration, based on expected usage patterns. I find this kind of thinking rather suspect. The question in my mind shouldn't be "why global", but "why not global". There seems to an underlying assumption that site locals would give better security properties due to their global inaccessibility. I find that rather uncompelling and misguided as this is just carrying forth the broken assumption that barriers (firewalls, etc) can do an adequate job of protecting things. Anything which propogates that sort of thinking is, IMO (and almost certainly not in my employer's) bogus and needs to checked. We need keep beating the strong auth/authz drum here. So, let's just take that off the table for this discussion. Mike 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
Tony Hain writes: > Michael Thomas wrote: > > So I have a question for those who support > > connected site locals: what would prevent a new > > RFC from updating Brian's wording for site locals > > (if that's the right thing)? > > > > I say this because it seems to me that there's a > > lot of issues being conflated in these arguments > > and what's sort of frightening to me is that they > > need to be teased apart. In particular, the desire > > for provider independent addressing seems to > > factor in here fairly largely too, and I wonder if > > the better part of valor might not be to get > > together a BOF which focuses on the actual real > > life requirements here. It's possible that site > > locals in the end might make sense here, but it's > > also possible that it can be done other ways too > > (or that the entire problem is totally intractable > > which is the way it looks to me now). > > > > Some of the uses for SL would be better served by PI addresses, but not > all. Well, that's sort of my point. The fact these are intertwined in many cases seems like a good reason for prudence. If PI addresses could be made to work, a *lot* of the motivators for SL would go away and we could then consider the remaining cases independently. However, if we allow the current language it's going to be even more tangled up if we ever get PI's with an even bigger mess to sort through, not to mention the spectre of real deployment too. > Take the case of a 20,000 node network where half are allowed global > access and half are not. It is much more complex to sort through a > 10,000 node list per packet for access filtering than it would be to > have two entries, SL deny & PA allow. Yes the list of which 10,000 nodes > are allowed the global prefix has to be maintained, but it can be > applied according to allocation policy rather than per packet > processing. Why couldn't you use a reverse VPN? Ie, an SA is required between you and the inside edge for external access? Mike 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
Mohan Parthasarathy writes: > > > > > Personally, I don't have a big problem with the suggestion > > itself, but I do not agree with it, simply because it's a > > meaningless restriction. I'd rather see a > > separate BCP for this, or at least say should not and > > explain why. > > > I agree with Hesham here. Should we not explain why we are taking this > stance instead of just saying MUST NOT ? It might prevent another 500+ > emails > in the future. Doubtful. Trying to capture those 500+ emails worth of justificatin sounds doomed to failure. Brian's simple modification leaves everybody convinced that it was their own nuace on the justification that put it over the top. So much the better. Mike 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 selection and site local addresses
Keith Moore writes: > > What I want to know is why the concept "local" in > > the absense of enforceability (cf strong auth) > > isn't a thoroughly bogus concept. > > for the purpose of security, in any network of significant size, > it certainly is. > > if site-locals are useful at all it is not because of security. Well then, I guess I'm at a loss about why people would want to use site-locals for local services. If it's not for the possibility of access control, then what else is it? Mike 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 selection and site local addresses
What I want to know is why the concept "local" in the absense of enforceability (cf strong auth) isn't a thoroughly bogus concept. Site-locals seem to be trying to cling to that discredited bogosity. Mike Keith Moore writes: > > Here are three models for address selection when both site-local and global > > addresses are available. Which (if any) is preferred: > > fourth model: > > discourage use of site-locals when stable global addresses are available: > > Pros: drastically reduces complexity of applications that would otherwise > have to deal with site-locals > > doesn't artifically split the problem of apps dealing with > renumbering into local vs. non-local applications. > > Cons: does not permit use of site-locals for avoiding the effects > of renumbering for local applications. > > 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] > 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
Count me in on agreeing with Brian too. Mike Pekka Savola writes: > On Tue, 12 Nov 2002, Brian Haberman wrote: > > Margaret Wasserman wrote: > > > > > >> > > >> Current text: > > > > > > > > > Hi Brian, > > > > > >> >Site-local addresses are designed to be used for addressing > > >> inside of > > >> >a site without the need for a global prefix. Although a subnet ID > > >> >may be up to 54-bits long, it is expected that globally-connected > > >> >sites will use the same subnet IDs for site-local and global > > >> >prefixes. > > >> > > >> Proposed new text: > > >> > > >>Site-local addresses are designed to be used for addressing inside of > > >>a site which is not connected to the Internet and therefore does not > > >>need a global prefix. They must not be used for a site that is > > >> connected > > >>to the Internet. Using site-local addresses, a subnet ID may be up to > > >>54-bits long, but it is recommended to use at most 16-bit subnet IDs, > > >>for convenience if the site is later connected to the Internet using a > > >>global prefix. > > > > > > > > > I would support this change. However, I doubt that we will get > > > consensus to make this change before the addressing architecture > > > is issued as an RFC. I guess we'll see how things develop in > > > Atlanta. > > > > > >> Alternatively, we could spend the next 5 years discussing the > > >> unnecessary complexities of using site-locals on connected sites. > > > > > > > > > This is _exactly_ what I am hoping to avoid. > > > > > > Let's limit site-locals to the well-understood case, and focus on > > > solving the real problems: > > > > > > - Getting IPv6 finalized and ready for wide-scale deployment > > > - Multi-homing > > > - Renumbering > > > - Security model for shared IPv4/IPv6 networks > > > > I agree with Brian and Margaret. > > Also totally agree. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > 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] > 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)
Brian E Carpenter writes: > David Conrad wrote: > > > my personal opinion is that the only people who feel any possessive > > > instinct towards 2002:d90d:1cca:2:210:dcff:fe5a:f1fd are the people who > > > have to reconfigure other stuff when it changes. > > > > Or the people who are affected when reconfiguration occurs. > > > > Welcome to NATv6. > > It's our job to stop that happening. > > Also, the vast majority of Internet users are not in the least > possessive about their IP address; it's different every time they > connect. Those who are possessive are those who run services of one > kind or another. It's our job to make that possible without forcing > them down the NAThole. Internet users, or people who make decisions for those internet users? I think the "possessiveness" is directly related to the desire for stability, so Joe Webpack probably doesn't care too much about this, but his employer's IT department cares a whole lot. Also: we haven't seen the fully impact of Joe Peerpack (esp VoIP), so it's a bit premature to guess, I'd think. Mike 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]
Address allocation schemes (Re: Naming and site-local)
Harald Tveit Alvestrand writes: > 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. > > stable addresses for the lifetime of your ISP service contract seems like a > not too terrible deal, if renumbering is easy. > > for IPv6 address allocation schemes, check out > http://www.ripe.net/ripe/docs/ipv6-sparse.html for some recent thoughts. 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", I suspect that they are viewed more as possessions which is an obvious problem. The only question that remains is whether we are -- as they say -- pissing up a rope. If we are, we just need to accept reality and move on from there. Mike 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: MIPv6 issue: HAO keyword
Jari Arkko writes: > Michael Thomas wrote: > > > On the requirement for HAO in all IPv6 nodes... is > > this actually necessary? That is, if I do not > > implement a binding cache (which is not a > > requirment), the only processing the node would > > need to do is inform the mobile node that it can > > not/will not process the HAO because it's not > > legal to interpret it as a home address without a > > binding entry. Likewise, a MN shouldn't be sending > > a HAO until it establishes a binding, thus there > > shouldn't be a possibility for missynchronization > > there either. > > Right. And that's what we are recommending. We > are saying that the current HAO requirement for all > nodes should be removed. > > CN has no clue about HAO, MN sends anyway => ICMP Par.prob. code 2 > MN tries to establish RO, no CN support => ICMP Par.prob. code 1 Good. Then I'm cool with the recommendation. Mike 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]
MIPv6 issue: HAO keyword
Gabriel,
On the requirement for HAO in all IPv6 nodes... is
this actually necessary? That is, if I do not
implement a binding cache (which is not a
requirment), the only processing the node would
need to do is inform the mobile node that it can
not/will not process the HAO because it's not
legal to interpret it as a home address without a
binding entry. Likewise, a MN shouldn't be sending
a HAO until it establishes a binding, thus there
shouldn't be a possibility for missynchronization
there either.
What am I missing?
Mike
gabriel montenegro writes:
> This is an attempt to close issue 53 in the MIPv6 draft
> ("HAO keyword"):
>
> http://www.piuha.net/~jarkko/publications/mipv6/issues/issue53.txt
>
> We're cross-posting to both IPv6 and MobileIP as this concerns both lists.
> I'm sending this on behalf of Jari Arkko and the Mobile IP chairs. Please
> send any issues to the lists.
>
> tnx,
>
> -gabriel
> --
> In July we had a big discussion around the right keyword for the
> Home Address destination option support in IPv6 nodes. This e-mail
> reviews the issue and makes a recommendation.
>
> Unless otherwise specified, section numbers refer to rev 18
> of the draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt
>
> BACKGROUND
>
> In the new security design for Mobile IPv6 (adopted to the
> base specification over the course of the last year), we
> allow two modes of operation for communicating with the
> correspondent nodes:
>
> 1. Tunneling via the home agent (also called "reverse tunneling" in
>section 11.2.1).
> 2. Route Optimization (also called "direct delivery" in section 11.2.1):
>routing directly from the mobile node to the correspondent
>node (using a "home address option"), and from the
>correspondent node to the mobile node (using a "routing
>header - type 2").
>
> Note that tunneling happens in *both* directions and that optimal
> routing can *only* be performed if a binding cache entry has
> been established. The mobile node can't send a packet directly to
> the correspondent node until it has completed return routability
> procedure and sent a binding update. This is a change from previous
> versions of the protocol and was done in order to guard against
> certain reflection attacks. (But see below for a special case.)
>
> The return routability procedure and binding updates are carried
> by the Mobility Header protocol (a new IPv6 protocol). According
> to RFC 2463, any node that doesn't recognize a specific "next header"
> protocol value will return ICMP Parameter Problem, Code 1 to the
> sender. The MIPv6 specification requires that the reception of
> such a message is taken as an indication that the peer does not
> support Route Optimization.
>
> Furthermore, even nodes that support MIPv6 may decline requests
> for Route Optimization due to temporary lack of resources, for
> instance. This happens via an error response within the Mobility
> Header protocol itself.
>
> The new version of MIPv6 protocol is therefore capable of operating
> both with nodes that support this specification (regardless of any
> temporary inability to accept requests) and with nodes that do not
> support MIPv6 (such as nodes that have already been deployed).
>
> The current MIPv6 specification lists the benefits of route
> optimization (Section 8.2) but does not state whether it is
> mandatory or not for all IPv6 nodes. The plan is to leave that for
> the IPv6 node requirements document to decide.
>
> THE PROBLEM
>
> Even though it does not mandate route optimization itself, the
> current MIPv6 spec does mandate that two items MUST be implemented
> by *all* IPv6 nodes (section 8.1):
>
> 1. All IPv6 nodes MUST recognize the Home Address destination
>option and,
>
> 2. All IPv6 nodes MUST be able to return Mobility Header error
>messages.
>
> However, several people have complained that in the current
> state of IPv6 deployment, they do not wish to add new
> requirements for all nodes.
>
> As explained above, this isn't technically necessary as the ICMP
> Parameter Problems (or the lack of response) is adequate to keep
> the mobile node using tunneling. No payload packets will be sent to
> the wrong place, and no packets are lost.
>
> However, these two requirements relate to a special case
> we currently allow in the specification: direct delivery from the
> mobile node to the correspondent node (which uses a home address
> destination option) is allowed not just when a binding exists but
> also if the packets have been protected by IPsec. This constitutes
> "triangular routing": whereas the mobile node can directly deliver
> packets to the correspondent node by virtue of IPsec, the opposite
> is not true: the reverse direction cannot be optimi
Re: Flow label draft issues & new text
Margaret Wasserman writes:
>
> >
> >Maybe I'm in left field here, but I thought that a
> >transmitter who didn't mark packets' flow label
> >was supposed to set it to zero. In that case, the
> >router could conceivably resort to classifying packets
> >the old fashioned way -- eg transport headers.
>
> The problem is that the current specification allows information other
> than a flow label, such as a packet classifier to be placed in the
> flow label field. So, a router cannot know that a non-zero value labels
> a flow (i.e. one direction of a TCP connection).
I guess I don't understand why that's a bad thing.
Routers currently classify flows with transport headers,
etc, but that's because it's the only thing they _can_
classify with. The flow label pushes classification
back to the host which, IMO, is where it really
belongs since it's the only that that _really_
knows what constitutes a "flow".
> > > It would be very bad, though, if the flow label were used, for example,
> > > to tag packets that contain a TCP SYN, or packets that contain IP options,
> > > or all HTTP packets, or packets that want a certain class of services,
> > etc.
> >
> >Er, why would this be bad?
[much elided]
> What doesn't work is if there may be non-zero values in the flow label
> that actually don't label flows. How is a load-balancing or load-spreading
> router supposed to know that this isn't a flow label?
Er, well, it _doesn't_. I guess I just don't
attach any special meaning to the word "flow";
that is, a flow is whatever the host says is a
flow. If it's bizarre, then well, why should
the router care? Again, other than maybe gaming
fair queuing algorithms[*], why do routers
actually care about what constitutes the
sematics of the flow? It's really in the host's
best interest to be network friendly, right? To
give routers information which increases the
probability of forwarding its packets in the
manner it hopes for, right?
> I gave two examples which Brian Carpenter said he specifically had in
> mind for possible uses of the flow label:
>
> - All HTTP packets get the same flow label.
>
> How would this work with a load spreader that is
> trying to spread connections between a group
> of web servers?
Well assumedly the server farm wouldn't all
have the same IP address, so they'd be different
flows.
> - The flow label contains a packet classifier.
Er, but the flow label *is* an element of a
packet classifier, or rather perhaps a
replacement for the current method of classifying
packets. I thought as far as routers are
concerned, flow label were opaque and that no
internal semantics were visible.
> But, Brian specifically stated that he wants finer-grained control over
> flow label values than a per-connection value. How would that work with
> load-spreaders?
This seems to me to be a self-healing problem:
if it screws up load balancers by using strange
definitions of flow, hosts are probably what
will notice via reduced throughput and... stop
doing that ("Doc it hurts when I hit myself in
the head..."). Though I must say that I still
don't see that it would hurt them.
> If the WG really wants to define the flow label so that it can be used
> for signalling-based mechanisms like RSVP, NSIS and diffserv, with the
> clear understanding that this makes the value _USELESS_ for the types
> of applications I've described above, that is fine with me.
I'm still completely lost. How does it make it
useless?
Mike
[*] this could conceivably be mitigated by first
classifying by IP address and then draw down
each different flow from its own token bucket,
thus a host would only be screwing itself.
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: Flow label draft issues & new text
Margaret Wasserman writes: > > > > >Jarno answered this one I think, but my point is that *they don't need to > >know*. They just behave the same way in all cases, and the traffic that > >doesn't carry fine-grain flow labels will just not get load balanced. > > The problem is that the traffic that "doesn't carry fine-grain flow labels" > will still get sent through the load balancing mechanics, and packets with > the same flow label will still get forwarded the same way. Margaret, Maybe I'm in left field here, but I thought that a transmitter who didn't mark packets' flow label was supposed to set it to zero. In that case, the router could conceivably resort to classifying packets the old fashioned way -- eg transport headers. > It would be very bad, though, if the flow label were used, for example, > to tag packets that contain a TCP SYN, or packets that contain IP options, > or all HTTP packets, or packets that want a certain class of services, etc. Er, why would this be bad? Are you thinking of the possibility of a host gaming a router's fair queuing by changing the flow label on packet by packet basis? Mike 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: [mobile-ip] Re: HAO and BE processing will be mandated
[EMAIL PROTECTED] writes: > If the intent is to support mobility in IPv6 networks as an integral > aspect of the protocol, I believe the HAO processing is a MUST. I > believe the Mobile IP WG is of this opinion. That sure hasn't been my read of the consensus. In fact, the consensus seems to be exactly opposite. Mike 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: [mobile-ip] Re: HAO and BE processing will be mandated
Vijay Devarapalli writes: > RO is a SHOULD, it is not a MUST in the current draft. we were > not talking about route optimization. we were talking about > processing a HAO. in the current spec HAO MUST be processed but > not accepted if it cant be verified. verification can be in the > form of checking for a valid BCE (created securely), IPsec > protected data session, same trusted domain (where you dont > expect people to do reflection attacks), the tagging proposal > from Rajeev and Charlie, smart ingress filtering from Francis > Dupont, etc... Oh, OK. Sorry about that. Still if the code isn't in the CN, the MN should still be able to operate correctly, right? That still seems to me to be a SHOULD rather than a MUST for the same reasons in my reply to John. I guess the long and short of this is that I'm somewhat skeptical of putting general node requirements in the MIP draft since it's probably not the first place one would be looking to figure out if they were an IPv6 compliant node. If it's really, really vital for the health of the net, yadda, yadda, it would be better to put it in a general v6 node requirements RFC, don't you think? Mike 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: [mobile-ip] Re: HAO and BE processing will be mandated
[EMAIL PROTECTED] writes: > > Given that MIPv6 will interoperate without binding > > code in CN's, it looks pretty much like a SHOULD > > to me. Indeed, the protocol would not be robust if > > it didn't consider the case of a non-conformant CN. > > I think we want to ask is, is it the right thing to do? For > proper protocol functioning, will this lead to the correct > behavior. If we think it is important, the MUST is OK. The > spec does contain a mechanism to support existing implementations > of IPv6, which means the protocol designers are doing their > jobs. I think we're straying into a "good" as in "good for the overall health of the Internet" kind of good, rather than a "good" as in will the protocol operate correctly. For the former, I think you need to have extremely compelling motivation, as well as a lot of evidence that the health of the net will be imperiled if *all* nodes don't implement a particular function, which is what is at issue here. Frankly, I don't think that there is any evidence that the net would be substantially harmed if RO wasn't widely implemented and/or enabled. Indeed, I think there's good reason to believe that many/most nodes will not enable RO even if their kernel implements it. In some cases, it's likely to be a nice and useful optimization, but I really don't see it as a "if we don't do this the net will fall apart". As such, SHOULD seems like it strikes the right balance. Mike 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: [mobile-ip] Re: HAO and BE processing will be mandated
[EMAIL PROTECTED] writes: > >it is. if a CN does not support HAO, it will send an ICMP error message > >pointing to the offending octet. when the MN receives this message, it > >starts reverse-tunneling through the Home Agent. where is the problem? > >if this is not clearly specified in the MIPv6 draft, it can be. the > >binding error functionality can also be substituted by an ICMP error. > >Binding Error was specified so that it is easier for the MN to figure > >out whats going on. > > then I see no reason for the MUST. Sez RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Given that MIPv6 will interoperate without binding code in CN's, it looks pretty much like a SHOULD to me. Indeed, the protocol would not be robust if it didn't consider the case of a non-conformant CN. Mike 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 Flow Label Specification
Brian E Carpenter writes: > All of which tells me that if we define a requirement for the flow label > allocation process to survive reboots, it will be a SHOULD not a MUST. > A toaster would provide a compelling argument for overriding the SHOULD. > > But right now we have enough dispute about it that I'd rather leave it > open in the spec, i.e. no change to the draft. FWIW, I agree with Brian. Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Keith Moore writes: > >Define "public". Given the peerwise distribution > >of routes, isn't the distinction of "public" > >rather arbitrary? If I convince my provider to > >route my site local prefix across their backbone > >(but not leaked outside their AS's), is that a > >violation? What about if my provider then convinces > >their upstream provider to do likewise to extend > >my reach? Is that public? And how likely is it that > >ISP's would pay attention to any such strictures if > >they figured it was an easy way to build what is > >for all intents and purposes a VPN of the MPLS > >variety? > > my opinion is that the space in an ISP's routing tables > and the cpu time of their routers belongs to the ISP and > the ISP can (and will) do whatever it wishes with it, as > long as they keep their agreements. the fact that these > are limited resources will quite naturally result in > pressure to limit the scope of advertisement of > non-aggregatable addresses. Right -- unless they can make a buck off of it. As I understand it, we don't have anything that really approaches a "public network" where global routes are just advertised. Whether routes are advertised or not is much more of a business decision than a common weal obligation. If the business pressures are such that with stupid router tricks(tm) you can make more money on less infrastructure even though it's not a globally healthy thing to do, I think we better not delude ourselves. Site locals definitely toe this line. Alas, the urge to overlay networks seems too strong. "What holds up the network? Why, it's networks all the way down!" Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Keith Moore writes: > > I've been staring at this for three days, and I think the > > answer (in the current state of the BGP art) is "yes", or > > at least the risk that it is "yes" is unacceptably high. > > Just stuffing some probably-unique bits into a SL is not > > going to generate aggregatable addresses; it's going to > > generate entropy in the routing table. > > the premise has to be that SL + site-ids are NOT going to > get advertised to the public routing tables. if there's not > a mechanism for preventing this now, we need to invent one. > but that's not a reason to force or even encourage sites > to use non-unique prefixes, especially when SLs without > site-ids cause problems for distributed applications. Define "public". Given the peerwise distribution of routes, isn't the distinction of "public" rather arbitrary? If I convince my provider to route my site local prefix across their backbone (but not leaked outside their AS's), is that a violation? What about if my provider then convinces their upstream provider to do likewise to extend my reach? Is that public? And how likely is it that ISP's would pay attention to any such strictures if they figured it was an easy way to build what is for all intents and purposes a VPN of the MPLS variety? Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Keith Moore writes: > > I agree 100% with Micehls' point - assigning unique IDs to sites for use in > > site-local addresses moves the site-local addresses into a globally > > routable address space, with the additional feature that those addresses > > are provider independent. The result would be an address space that is > > site-local by (potentially unenforceable) executive fiat rather than by > > technical design. > > this sounds like a feature to me, because it would allow hosts using > such addresses to have their traffic routed between sites without NAT. > > private addresses were a bad idea; we should not repeat them in v6. So it seems to me that what's at issue here is what is the lesser of evils. I think one thing which we should all be able to agree about is that local addresses regardless of original intent will be used to access global address space. The basic problem here is renumbering -- and the fact that people don't want to do that. Since, its a tragedy of the commons problem, there is simply nothing we can do about this unless we create the Address Police who can arrest and execute those recalcitrant addressing scofflaws. Thus, we have the two options: site locals which are actually globally unique could relatively easily be made globally routable by simply advertising the prefix. The downside here is prefix aggregation doesn't happen. For large sites, this is probably not a big problem, but for small sites it could be a huge issue. The other alternative is essentially NAT/ALG's. We all know how that works, and what it does to the net. The thing I don't understand is whether the address aggregation problem introduced by a new class of globally unique addresses is really any worse than the existing problems with route aggregation, and specifically about mobility and multihoming. It's quite possible that we could make things significantly worse by introducing a new class of routing prefixes, but as far as I understand, the ultimate fix for routing table explosion isn't especially well understood, and it may require its own set of draconian measures *regardless* of site locals. On the other hand, we know for absolute certain that NAT's completely pooch the end to end principle and are well known evil. I guess I come down slightly in favor of avoiding the known evil in favor of the potentially unknown evil, but as they say, ignorance is bliss. Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Robert Elz writes: > The global addr model though makes apps lifes more difficult, in that > it is then no longer immediately obvious which addresses are stable, > and which are not. Given two addresses, which should I use if I want > a stable connection (assuming I somehow know that both work) ? This is just the tip of the iceberg of what hosts don't know about addresses. The problem is that it is definitionally *unknowable* to the host since only thing that has that knowledge of those sort of topology goodies are routers, perhaps transported by routing protocols. This, to my mind, is the very basic reason why SL addresses are a generally Bad Idea. Requiring hosts to have knowledge of network topology is a bug, not a feature. Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Robert Elz writes: > Date:Fri, 14 Jun 2002 10:26:44 -0700 (PDT) > From: Michael Thomas <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > |But the real problem was renumbering. That > |still hasn't gone away. > > No, and that's why we need these things - so when renumbering happens, > our internal addresses (the ones I use to mount my filesystems from > the fileserver, etc, which stay in use for months or years between > reboots) don't alter. I guess I get off the merry-go-round here because I'm having a hard time imagining a deployment where it's OK to hose general internet connectivity, so long as other local services are kept up. Somehow I don't expect that the user population counting on their pr0n will be mollifed to find out that they can still download their PHB's powerpoints. YMMV. Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Robert Elz writes: > It was this kind of thing that led to 1918 addresses - the IETF > invented (allocated) them precisely because of the problems that > this (and other number "borrowing") caused. But the real problem was renumbering. That still hasn't gone away. > |Assuming that you _never_ want to globally > |advertise that prefix -- which is what site > |locals are intended for -- does it actually > |make any difference which prefix you choose? > > Yes. Because if you happen to choose a prefix that is someone > else's globally allocated prefix, you can never talk to them. > Or more likely, you find you have to renumber because you want > to talk to them (if you're lucky, and never do, there's no issue). Uh, except you can't talk to them anyway because all you have is a non-globally-routable address, right? > If you're ever going to be in the position of having to renumber > then the address you have isn't stable. See above. > |Why does IETF have to sanction one? > > One, as distinct from two or three or ... it doesn't. One as > distinct from zero, so you know the address that you're going to > be using will never be one that someone else uses (and you might > need to use to communicate with them - their using it as a private > address is harmless of course). Except you can't communicate with them unless you renumber or NAT anyway. > |Why not just let people make their own decisions? > > They don't have enough information to make a good decision. > Allocate several prefixes (like was done in 1918) and allow > people to choose which they want to use if you like, that's > fine - but they need to be prefixes reserved for the purpose. Except neither does IETF, it seems. There's no such thing as an long term stable globally routable prefix. If you want a globally routable address, you have to deal with renumbering, regardless of whether you got your "private" prefix from RFC 1918, or the back of an old Ultrix manual. > |BTW: isn't there already an implicit "site local" > |address space for v6 with net 10 v4 mapped > |address? > > If you mean the ::/80 address space (::/96 and :::/96) then [] > If you mean 2002:0A00::/24 (which aren't usually called v4 mapped [] I'm not sure which one I mean, honestly, and am too lazy to look it up. However, it seems that if you have any v6 prefix which maps the v4 space, you automatically get net 10's for the bargain, and all of the hassles they entail, including dealing with the v4 overlay network routing. Keeping "private" addresses as a v4 artifact -- which are still accessible to v6 if you are so inclined -- may be a way out of this... Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Robert Elz writes: > Addresses there are still constrained - I don't get allocated one which > I get to keep forever, no matter what, which is what SL addresses give me > (with or without some higher layer identifier embedded in them). > So, as an alternative to SL, they don't work, regardless of how good > they may be as global addresses. Of course, they also weren't designed > (I believe) as an alternative to SL, so this is probably no surprise. In the good old days, wasn't it rather common for clueless newbies to slavishly number their networks 192.6 or somesuch which was what they found in the network administrator manual examples? They worked just great up until the time they wanted to connect to the real net, right? Assuming that you _never_ want to globally advertise that prefix -- which is what site locals are intended for -- does it actually make any difference which prefix you choose? Why does IETF have to sanction one? Why not just let people make their own decisions? It's not like there's any more or less work if they change their minds, right? BTW: isn't there already an implicit "site local" address space for v6 with net 10 v4 mapped address? Mike 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]
Scoped Addresses and Renumbering
Thomas Narten writes: > If the real feeling here is that site locals are bad if they end up > reproducing some of the same problems as private addresses, then we > should produce documents that explain when site-locals can safely be > used (i.e., an applicability statement that describes when the IETF > recommends their use). For other uses that people imagine (or that we > expect they will imagine), but for which we think is a bad idea, we > should say *why* its a bad idea *and* we should suggest a better way > of doing it, so that folks who have a particular problem can choose an > appropriate solution. To my mind, one of the key failure modes of overlay addressing is collisions when the original assumptions of the overlay cease to be true -- like when you get two companies who merge, say, and their net 10 address spaces collide. This drives integration attempts to a great deal of distraction and a Quick Fix NAT(tm) is almost certainly the result. What you'd really like in that situation is to renumber, but color me skeptical that renumbering will ever be "easy" or "automatic", especially when you consider the widespread conflation of addresses as routing tags and as identity. Thus, I think site locals will still beg the Quick Fix NAT(tm). Badness. If we instead say that you should just blackhole otherwise globally routed prefixes at the site boundary, we don't run into this problem. If you have a change of policy, you just change some or all of the prefix that gets blackholed instead of renumbering. Just as easy, if not easier than setting up NAT's, IMHO. Mike 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: Fwd: IPv6 Scoped Addresses and Routing Protocols
Robert Elz writes: > At MU, we have undergrad student labs, that we basically filter from > the world - they have no end to end connectivity at all. And that has > nothing at all to do with NAT (of which we have none at all) nor with > 1918 addressing (of which we also have none at all). Nor will it have > anything at all to do with site local addresses. Robert, Color me clueless, but why can't you give them a global prefix, but just not advertise their route past the administrative boundary you choose (eg, the lab)? Why is an IETF sanctioned "don't route this prefix beyond where you should route it -- which, by the way, you decide where ``beyond'' is" better than just blackholing the actual prefixes you want to contain? To my mind that seems easier in some sense because it's reactive: ie globally number first, determine who the l00zers are later -- a capability you probably need to have anyway. I guess I don't see what being proactive with special addresses really buys since it's _your_ definition of site -- and its containment thereof that's important. Indeed, site-locals don't really seem to buy much on the manageability front since you still need to decide who gets them and why, and where the boundaries of the site are. And of course, if you ever decide to change your policy (or part of your policy), you don't need to renumber with global prefixes (eg, you want to allow part of your lab to be global visible so they can show the world their new cold fusion results). Mike 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: Securing Neighbor Discovery BOF
James Kempf writes: > So is it the case then that there would be no change in IPsec policy > required for doing AAA-based or roaming consortia-based key management? > Is so, then perhaps this problem is fairly straightforward to solve. Which working group has this in their charter? Mike 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: Mandating Route Optimization
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: [eminently reasonable assessment of why SHOULD is more appropriate] I'd add tht MUST is primarily a tool for insuring that different implementations will interoperate. Route optimization doesn't meet that criteria since it is, after all, an optimization. If it's a MUST, it would be for, essentially, global policy reasons (death of net, film at 11...). I don't think we have enough information to really make that kind of pronouncement though. MIP isn't the only one creating dog-leg routing on the net these days: VPN's do the same thing. Indeed, VPN+MIP seems like it would be a fairly common deployment scenario. Does route optimization even buy you anything in that case? Mike 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: Mandating Route Optimization
I don't know if this has been mentioned, but regardless of whether implementation of RO for CN's is a MUST/SHOULD, there should be text in the draft that "RO MUST have a means to be administratively disabled on the CN." I hope it's obvious why. Mike Samita Chakrabarti writes: > > > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to > [EMAIL PROTECTED] using -f > > From: [EMAIL PROTECTED] > > X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 > > content-class: urn:content-classes:message > > > > please be aware of already-deployed IPv6 codebase. WinXP is shipping, > > > MacOS X will be shipping soon, and mobile-ip6 is not yet an RFC. > > > even home address option (which is a MUST) is changing. > > > i don't think it a good situation for implementers. > > > > I think that this will not be a significant problem - I assume that > > there will be more IPv6 implementations coming than what what > > exists already. Of course, the existing implementations may not > > support Mobile IP and I think that will be something that we have > > to live with. > > > I agree with John completely. We don't have enough IPv6 deployment > yet and it's good time to make the decision whether Route Optimization > should be MUST in MobileIPv6. I think, it makes more sense to have > Route Optimization a 'MUST' in MobileIPv6 draft now than in future, > when we might have significant backward compatibility problems. > > > -Samita > > > 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] > 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: Should IP Security be Optional?
[EMAIL PROTECTED] writes: > Just to add onto Jari - it would be a no-brainer to > state that IPsec (AH & ESP) MUST be supported, > IKE MAY/SHOULD be supported. However, does this > give users anything? Will it increase security for > these devices, or is it just something that will make > folks happy? The authors prefer to have a reasonable > discussion on security within the draft. Knowledge of > the field of Internet Security has increased since > some of the initial IPv6 documents were published ... It categorically depends on what you're trying to do. Frankly, this entire line of discourse seems a little bizarre to me. What is the point of a set of must implement protocols where on the one hand it's intended for fixed function device without easy upgradability, etc, and on the other hand wanting to insure some amount of future proofing. Future proofing for *what*? Maybe I have this all wrong, but it seems that what's going on here is an architecture that's not an architecture. It makes my head hurt. Mike 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: Should IP Security be Optional?
Jari Arkko writes: > As we point out in section 3.8 the current > cellular networks sometimes have dynamic IP > address changes, and therefore manually keyed IPsec > isn't going to work as such and key management is > needed. While there might be multiple options > here, interoperability is a concern and hence > I feel that we must have a mandated key management > scheme. In the cellular host requirements draft, we > have chosen to say that IKE is a MUST in those > cases where we mandate IPsec. Do you disagree? I don't know; it depends on what you're trying to accomplish. Is there a reason that you must choose one? I agree that dynamic addresses makes manual keying problematic, but I'm not sure that it follows that you need to pick one keying scheme. Even with IKE, there's room for interoperability issues (some might say far too much room, but I digress). > (In a way you could say that the cellular draft goes > *beyond* what the current IETF MUSTs are, given > that we mandate a full security solution in all cases, > though at the same time we don't mandate the current > requirement of AH and ESP in all cases.) Well, at its base it's about what needs to be implemented, right? > Anyway, this is just *our* proposal on what we think > would make sense. But the document is controlled by the > WG; please state your proposed security MUSTs for > IPv6 hosts, cellular or otherwise. Mike, what would you > like to have there, for instance? My personal feeling is that the ng working group has the consensus about right. We need a base level set of mechanisms for protecting IP packets. Since this is normally kernel level work, having a strong statement here is useful. And while I think there's pretty good consensus that IPsec (eg, not IKE) is a a stable and mature, there's equally good consensus that IKE is not. Given KINK and JFK/IKEv2 -- not to mention how widespread transport mode keying really gets deployed -- I'm not sure that I'd want to choose any one at this point. I personally think that the Kerberos based keying is well suited to high fan out kinds of applications like telephony, but I wouldn't claim that it is the only way (or The Way) to approach the problem of keying. Mike 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: Should IP Security be Optional?
Hesham Soliman (ERA) writes: > Mike, > > Good points. So are you saying we should > mandate ESP and AH but it's ok not to mandate > IKE? and perhaps use something else for > key distribution? I think the v6 host requirements struck the right balance: require the IP packet layer transforms, and be silent on key distribution. Key distribution is clearly a huge problem, but IPsec doesn't mandate a single solution so I don't see why the cellular requirements draft should either. You can run IPsec with manually configured keys, after all, so at a base level you can get interoperability. This is foward progress IMO, even though we clearly need more going forward. Mike 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: Should IP Security be Optional?
So, talking about making exceptions to the MUST IMPLEMENT aspect of ipsec on v6 strikes me as a really poor idea. First of all, a minimum implementation of IPsec to fulfill the mandatory requirements is quite small -- we're not talking about IKE here. Far more problematic, however, is the lack of a common security substrate on the net. We know what that means in practice: no security at all in the vast majority of cases. Requiring IPsec at least gets us to the point where two nodes can have a secure conversation with any mix of traffic instead of the current mishmash of incomplete and often insecure other mechanisms (read: nothing in many important cases). I think I also disagree with Jari's characterization of fixed-purpose devices. The net is not the PSTN with exactly one application. Once you've enabled IP, you have instant access to zillions of applications, and a zillion more to come. While small boxen certainly will only implement a small fraction of those applications, we have not one clue *which* ones they'll be! Some may very well be UDP based, and thus TLS won't be of any use. So we'll be back to the same state of trying to shoe-horn protocols to meet security requirements via unnatural acts with TLS, often ill-conceived application layer security, or just plain ignoring the problem and hoping for the best. *Please* let's not go there. For the scant amount of flash and ram that IPsec requires we get a common baseline. This is desparately needed so that we at least have something to proceed from rather than the current chaos. IPsec is the security analog to TCP's reliable transport. Without TCP, protocol and application development would have been severely hampered. TCP's utility amongst other things was to simplify networking so that people other than net weenies could write applications. The same, I'm afraid, is true of crypto -- maybe even worse, because a cursory understanding of transport wasn't all that hard to come by even 20 years ago, whereas there's not a surer way of getting people's eyes to glaze over faster than talking about crypto in my experience. We really, really need some commonality. Let's not backtrack. Mike OKABE Nobuo writes: > Thank you for your many feedbacks. > > From: Jari Arkko <[EMAIL PROTECTED]> > Subject: Re: Should IP Security be Optional? [Was RE: >draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > Date: Mon, 04 Mar 2002 15:03:00 +0200 > > > Francis Dupont wrote: > > > > > => yes, ICMP is hard to protect and to use it for small services > > > does not make things simpler... > > > > So, we agree on this at least... > > > > > => there is an IAB statement about security. IPsec support was > > > made mandatory according to this statement and IMHO this was > > > a big step forward. There are other security mechanisms, > > > including some at the transport layer (SSL/TLS, IMHO IPsec > > > is better but real world considerations have to be considered :-) > > > and some at the application layer, with in some cases a very > > > different usage (PGP). > > > I have in favor of to make all core security mechanisms mandatory > > > (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only > > > the first in the list. > > > > I'm partially in favor of this approach, but not entirely. > > I'd be much more comfortable with trying to make a detailed > > recommendation on where different mechanisms are applicable > > and mandated, than try to mandate them all everywhere (likely > > with less than 100% success among implementors). > > > > I think the general approach should be that security > > is mandatory, but not necessarily same type of security > > under all circumstances. > > I agree. > > If a very small host has single application (ex. web), > the implementer will want to implement an appropriate > security mechanism only (ex, TLS) because of fitting > its cost. > > It should be our further work to make detailed > guideline for LCNA part. > > nobuo > > 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] > 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: [mobile-ip] How to move forward in the HAO & ingress filter discussion
Francis Dupont writes: >If we (the IETF) really care about security we need to make sure >that we don't create holes in the set of standards track RFCs we >issue. > > => I agree but in this case the target is explicitely "not introduce > significant new vulnerabilities that are not present in IPv4 today". > The new vulnerability has not be proved to be significant and the > proposed reply is designed to get back to the IPv4 situation (where > the reply to the threat, I have to say it again, is a BCP). Positing AAA as the necessary band-aid is a non-starter. Positing the kind of fix I proposed as a "crazy idea" runs into problems with middle of the network RPF checking and will, in practice, sink any use of route optimization. HAO's cannot defeat ingress filtering. That is distinctly worse than the current net. I think we seriously need to consider whether we should sever route optimization from this draft. Sigh. Mike 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: [mobile-ip] How to move forward in the HAO & ingress filter discussion
Pekka Savola writes:
> On Fri, 18 Jan 2002, Jari Arkko wrote:
> > > I looked at a lot of stuff, but that's the only one I saw,
> > > even though it can be dressed up in different ways.
> > > What else is there?
> >
> > I think you are right Charlie, that is the only downside.
> > (There's a bunch of other downsides related to fixing
> > with AAA the hole HAO leaves in ingress filtering, but
> > that's another issue.)
> >
> > The primary danger of unconstrained HAO is having even a small
> > number of attackers spoof HAOs and use a large
> > number of CNs as reflectors to attack a specific
> > target even if your network has ingress filtering.
> > Basically, it voids ingress filtering.
> [snip]
>
> There is a downside: destination site's filtering ("spoofing protection"
> from the direction of the Internet) is nullified!
Thank you. That was exactly what my point was.
It's not just the reflector attack; the HAO
nullifies all of the ingress filtering present
on the net right now. That is distinctly worse
than the status quo.
Mike
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: [mobile-ip] How to move forward in the HAO & ingress filter discussion
Erik Nordmark writes: > For the IETF I think this means that we should not issue a proposed standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). If we want to go this path I think we need a community > supported ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. I agree 100% with Erik here, and add this: security needs to be thought of in terms of layers. Ingress filtering is a useful, but incomplete layer. Ultimately hosts need a means to defend themselves too since we can't assume that anything will have complete coverage. Mike 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: [mobile-ip] How to move forward in the HAO & ingress filter discussion
Charles E. Perkins writes: > Hello folks, > > I'm pretty far behind on reading these voluminous e-mails, but > I would at least like to express again my belief that we could > go forward with the HAO as it is. If the downside is that then > there is vulnerability to (single!) packets being reflected back > to an unsuspecting home address, then: [] That is not the only downside. The primary downsides have been discussed here ad nauseum. Mike 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: Flow Label
Steven M. Bellovin writes: > In message <[EMAIL PROTECTED]>, Brian E Carpenter writes: > >Indeed. All of this is the same for the DSCP actually, and the > >assumption is that operators will protect themselves with > >admission control. > > > >(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion) > > > > Right. The question now is how to do that. I was about to agree > strongly with the "must send as zero if not a flow, routers must not modify" > until I started thinking along these lines. What should a border > router do with a packet that doesn't meet its constraints? I only see > three choices: reset the flow label to something locally acceptable, > drop the packet, or tunnel. But dropping the packet means that flow > labels can only be used for flows that stay within a particular flow > label domain, and the tunneling path leads to madness. (Well, perhaps > to MPLS, but I don't think we want to go down that rathole now.) I'm > forced to conclude that we have two choices: either we give up on flow > labels entirely, or we permit them to be modified en route. First of all, there's nothing that is defined from which to take action based on the flow label, so I think this is largely an academic question. If we suspend some disbelief and posit an edge device which, say, polices a flow to a particular rate, why does it follow that the router would need the ability to rewrite the label? Certainly in the Intserv case, policers don't rewrite the 5 tuple. Their only option is to change the PHB or drop it. In diffserv style, it can in addition to dropping and changing its queuing characteristics, rewrite the DSCP. So I guess I just don't see where a policer would need the ability to alter it. Also: pragmatically, we can alway change our mind on the mutability front if it starts life as *immutable*. Mike 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: [mobile-ip] Re: IPv6 ingress filtering early access
As originally advertised, I am now convinced that this was indeed a crazy idea -- a bit too good to be true. Thanks for the link on the "loose" RPF checking; I wasn't aware of that. Having to signal many routers in the path would be a non-starter, and ISP's certainly have incentive to perform the loose RPF, therefore this is an insurmountable obstacle. Oh well. Mike Francis Dupont writes: > In your previous mail you wrote: > >[Phil suggested I add mobileip back which was > dropped somewhere along the way] > >I'm not sure we're communicating, so let me be a little >more explicit with what I had in mind: > >1) MN arrives on new AR > > => many (academic or R&D) sites I know don't use firewalls > (they use a router for filtering) but have a passive management box > which detects new addresses and builds a database with MAC, IP, > name, location, etc, something very useful in case of problems. > So even if classical network access control is not performed on 1) > at the first packet, unusual behaviors are detected (i.e. there is > a passive and without automatic reaction kind of network access control). > At the opposite I know some (commercial) ISPs which use the (traditional) > network access control to punch holes in the firewall for outbound > traffic, i.e. all source addresses are blocked by default and > network access control is used to open some of them (in AAA term > the authorized resource is the Internet access): this is ingress > filtering at the address level, usually it is done at the access > device (e.g. modem) level too. > >2) It sends a packet using its home address as the > *source* address -- no HAO at all. > > => I propose that the packet is sent to the home agent (or something > similar). > >3) AR recognizes that the source address is not one of > the subnets it subtends and sends an ICMP message > to MN which explains the problem > > => perhaps I should add a statement in the draft with a requirement > (modulo ICMP rate limitation) for ICMPs when a HAO is filtered out. > I believe a router should implement this by default but a detailed > text should help. > What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option), > as the router is not the destination of the packet the MN should > understand what's happened. Note that 1 (Destination Unreachable) - > 1 (administratively prohibited) is too ambiguous. > >4) MN sends AR a normal CN binding update > > => 4) is what I consider as a kind of network access control. > >5) AR lifts the restriction for that source address > > => the difference with my proposal is here, I propose to accept > corresponding HAOs, you propose to directly open the ingress filtering. > See more comments after. > >6) MN now sends packets as in (2), but unimpeded > >If MN knows that there is likely to be a source >address check on AR, it can delete steps 2 and 3. > > => i.e. active/reactive modes. > >ICMP seems like a natural here because the router >really is reporting a network problem back to MN >(or not MN if a host were incorrectly configured, >etc). > > => in any case ICMP errors have to be sent when packets are dropped, > I believe we can reach a consensus about this very quickly. > >If this is a subset of your proposal, fine. It >does seem that what I propose gets rid of the HAO >altogether which you don't seem to agree with. > > => in order to get rid of the HAO your proposal has to be > supported on every ingress filtering devices where a packet > from the MN can go though. This is not in fact like path MTU > discovery (which is already difficult to get in the real world) > because your proposal uses a signaling with all the usual > problems of signaling (scalability, security, ...). > Even if to get rid of the HAO would be very nice, I don't > believe this will work in practice. To summary this has the > same kind of problems (i.e. limitations) than micro-mobility > (i.e. mobility based on host routing). > >However, may I suggest that it's the AAA part that > > => I insist about AAA: AAA is not an essential part of > my proposal, it only brings extra goodies: > - an instance of network access control which is well known >and already has proposed extensions for (mobile) IPv6 > - remote network access control > - a connection between local and remote access control. > >has become the lightning rod? And that maybe it >shouldn't be quite so ambitious? :-) > > => too ambitious for a global deployment, and for local/special cases > I am afraid that micro-mobility is more attractive (it gets rid > of the routing header too). > > Regards > > [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page:
Re: [mobile-ip] Re: IPv6 ingress filtering early access
[Phil suggested I add mobileip back which was dropped somewhere along the way] Francis, I'm not sure we're communicating, so let me be a little more explicit with what I had in mind: 1) MN arrives on new AR 2) It sends a packet using its home address as the *source* address -- no HAO at all. 3) AR recognizes that the source address is not one of the subnets it subtends and sends an ICMP message to MN which explains the problem 4) MN sends AR a normal CN binding update 5) AR lifts the restriction for that source address 6) MN now sends packets as in (2), but unimpeded If MN knows that there is likely to be a source address check on AR, it can delete steps 2 and 3. ICMP seems like a natural here because the router really is reporting a network problem back to MN (or not MN if a host were incorrectly configured, etc). If this is a subset of your proposal, fine. It does seem that what I propose gets rid of the HAO altogether which you don't seem to agree with. However, may I suggest that it's the AAA part that has become the lightning rod? And that maybe it shouldn't be quite so ambitious? :-) Mike Francis Dupont writes: > In your previous mail you wrote: > > No, actually, it was to have the MN send the > BU's directly to the access router. On a router > the BU just has an additional effect of removing > any restrictions on source addresses it will > let through. > > => I believed your proposal was BU snooping. But you can name it > as you'd like, the purpose is to provide the knowledge of bindings, > so there is no deep difference with my proposal (i.e. I can say > you use a non-standard network access control device, as I don't > specify one (I only give an example with AAA because it is the best > on the paper) I could argue your proposal is included in mine :-). > > Hence Pekka's question about use of ICMP was correct. > > => I am reluctant to define new ICMPs for anything. There is already > a format for BUs, why a new thing? > > Another point: HAOs are inside packets, to look at them is legitimate > for my firewall but not for any router on the path, i.e. I'd like > to have the check done once and others to trust it (this idea is > exactly the network access control). > > Regards > > [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: [mobile-ip] Re: IPv6 ingress filtering early access
Francis Dupont writes: > In your previous mail you wrote: > >Also, this would get more difficult in the case of multiple, changing >paths (multihoming). > > => as multi-homing is a place we could want to use home address options > this is a real issue... I think we need to take a step back here. If you could do route optimization effectively and use the "home address" you started a session with, there isn't any motivation for a separate identifier in the packet, right? CoA would always be a routing construct. Mike 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: [mobile-ip] Re: IPv6 ingress filtering early access
Francis Dupont writes: > In your previous mail you wrote: > >> So here's a most-likely crazy idea: why can't we >> treat the ingress filtering router like a CN which >> must first be sent a BU which it verifies in >> whatever manner the CN would? This already has a >> requirement to not be bound to mythical PKI's, >> etc. Given FMIP, the access routers are probably >> going to end up having to process things like BU's >> anyway. > >I was drifting into this direction myself. But how? >Introduce a new ICMP message saying: send me a BU >if you want to use HAO? > > => no, Michael's idea is to look at packets going through > access routers in order to find BUs (i.e. this is passive). > And if you'd like to use an active scheme, why not the > network access control? No, actually, it was to have the MN send the BU's directly to the access router. On a router the BU just has an additional effect of removing any restrictions on source addresses it will let through. Hence Pekka's question about use of ICMP was correct. Mike 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: [mobile-ip] Re: IPv6 ingress filtering early access
Pekka Nikander writes: > Michael Thomas wrote: > > > So here's a most-likely crazy idea: why can't we > > treat the ingress filtering router like a CN which > > must first be sent a BU which it verifies in > > whatever manner the CN would? This already has a > > requirement to not be bound to mythical PKI's, > > etc. Given FMIP, the access routers are probably > > going to end up having to process things like BU's > > anyway. > > > I was drifting into this direction myself. But how? > Introduce a new ICMP message saying: send me a BU > if you want to use HAO? Sounds good to me. This also takes care of the case where somebody has RPF checks running farther into the network. I would expect that a MN would always send the BU to its access router. Making this a MUST implement for a v6 router would probably be a good thing too. > > Also: if we have ingress filtering taken care of > > directly, is there any reason to preserve the HAO > > at all? I thought its entire raison d'etre was to > > provide a means of coexisting with ingress > > filtering -- which we've already proven is just > > shifting the problem around instead of providing > > something useful. > > Now THAT sounds like the most reasonable thing that > I have heard about ingress filtering for a long > time! Heavens. Didn't mean to scare anybody :-) > To me, it seems like combinding RR and CGA, the > ingress filtering router can fairly easily determine > that the MN really "owns" the home address, and > thereafter pass it. As an immediate reaction, the > only problem seems to be that CGA requires fairly > heavy CPU load. Could RR be enough in this case, > since the CoA and HoA are on the different sides > of the router? I think that if RR is viable for anything, it's probably fine for lifting RPF checks. Mike 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: [mobile-ip] Re: IPv6 ingress filtering early access
Pekka Savola writes: > On Mon, 7 Jan 2002, Pekka Nikander wrote: > > Michael Thomas wrote: > Moreover, ingress filtering is usually performed at more than one router. > > The network manager of the LAN might perform it. The network manager of > the site should perform it. The network manager of the ISP should also > perform it. Etc. > > Therefore, this "notification" or "ingress filtering registration" would > have to operate a bit like path MTU discovery or a router alert option. > Also, this would get more difficult in the case of multiple, changing > paths (multihoming). > > Certainly an interesting idea, though. This entire question is being begged by multihoming which RPF checks fail at pretty miserably. And of course, asymmetric routes. We need something better. Essentially, I think what I'm proposing is something in lieu of RPF checks. The open question is whether we can make this pervasive too. If we can, we can safely turn off RPF checks. Mike 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: [mobile-ip] Re: IPv6 ingress filtering early access
So here's a most-likely crazy idea: why can't we treat the ingress filtering router like a CN which must first be sent a BU which it verifies in whatever manner the CN would? This already has a requirement to not be bound to mythical PKI's, etc. Given FMIP, the access routers are probably going to end up having to process things like BU's anyway. Also: if we have ingress filtering taken care of directly, is there any reason to preserve the HAO at all? I thought its entire raison d'etre was to provide a means of coexisting with ingress filtering -- which we've already proven is just shifting the problem around instead of providing something useful. Mike Francis Dupont writes: > In your previous mail you wrote: > >> => this (to use AAA everywhere where there are mobile nodes) is the price >> to pay to have an alternative to bidirectional tunnels with home agents, >> i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling >> (i.e. real world mobile IPv4). > >This seems like a bad design tradeoff to me. We already have a >highly optimised mode of operation in MIPv6 (RO), > > => no, we have not this until the security problem is solved, > i.e. it works but we may not deploy it... > In fact (you sent this mail to the IPv6 WG mailing list only > so I can say that without being nuke in some minutes) if Mobile IPv6 > is expensive for CNs and only at the benefit of MNs it is in a real trouble. > IMHO Routing Optimization has this problem, obviously not the > bidirectional tunneling and not the triangular routing *if* > the reply to the ingress filtering problem is not the burden of CNs. > I disagree with most of the IESG security concerns with MIPv6 but > the statement "This has negative implications for larger servers that > process many 100s of thousands of connections at a time" is true, > not only for AH/IPsec SAs. > I think we must put the responsability of using HAOs to senders! > >and if you're >not using it you are falling back to something less efficient. Your >tradeoff improves the fallback solution a bit, but doesn't improve >the optimised solution. And the cost is extreme: > > => I disagree, and the cost of RO is really extreme for CNs so if > most of CNs just deny BUs we'll be happy to have a better fallback > solution. > >we need a new >global infrastructure (though I admit some of it will be built anyway), > > => first the implementation of smart ingress filtering and AAA is not > even a SHOULD (RFC 2827 is a BCP), it seems you believe it is a MUST. > Second the ingress filtering and HAOs is not a major security threat > (like unprotected BUs in an open network is). > To summary your argument would be valid if ingress filtering was mandatory > and efficient, but today ingress filtering is not used by every ISPs > and unfortunately to know where are the attackers is not enough to > stop DDoS. > >MIPv6 deployment is delayed, > > => no, the only possible effect on deployment is another argument is > favor of a better/real AAA. > >most if not all small sites and homes >will not be able to benefit from RO, etc. > > => I agree that to ask for a better network access control in general > stresses the trust/responsability problem. > > Regards > > [EMAIL PROTECTED] > > PS: don't forget that the BCE check solution has many drawbacks: > - it doesn't work with not-MIPv6 uses of HAOs > - it doesn't work without routing optimization > - it makes CNs processing more complex/expensive > - BCEs should be hard state. > > 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] > 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 ingress filtering early access
I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. RPF checks "work" mainly because they are so painless for ISP's to implement. Anything beyond that is likely to be a complete non-starter. Mike Francis Dupont writes: > In your previous mail you wrote: > >However, I'm concerned about the "applied allover" >part. Specifically - while I'm very much fond of the AAA solutions - >I'm concerned whether we can expect all parts of the Internet to have >an infrastructure that really can figure out the home addresses. What >if there's a coin-operated (or Visa-) airport WLAN? > > => this is a problem of trust in the local/visited domain *and* in the > remote/home domain. In your example if I understand the issue is the lack > of trust in the local/visited domain, so one may reject traffic with > home address options from it. > >Finally, I seem to remember there was a discussion a long time ago whether >we could somehow provide automatic, mandatory, ingress filtering in IPv6. > > => my concern is that the "mandatory" term in a RFC is not enough to > enforce it in the real world. > >Currently, we are headed towards the same situation as in IPv4 >where ingress filtering is only partially applied, and we keep coming >up with "patch" solutions such as I-trace to help the situation. > > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). > >Interestingly, these solutions typically need changes to a large >fraction of the routers in the Internet which we already are doing >anyway to move to IPv6... > > => we can expect to avoid the same errors with IPv6. Unfortunately > ingress filtering (like network management) is something where IPv6 > is not yet at the same level than for IPv4 today. We hope this situation > will be improved very fast. > > Regards > > [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] > 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: Flow Label
Randy Bush writes: > I do not believe that there is currently any way to deal with the > *business* and *operational* issues of asking some remote ISP > to provide QoS service for you in any sort of scalable way > >>> Fine, but that's completely orthogonal to whether the flow label is > >>> a good idea or not. > >> we don't care that no one can operationally use it. if it might sell > >> one more router, let's kludge up the net a bit more. > > Oh, please. There is a very straighforward tweak to RSVP to support > > this > > i anxiously await a description the tweak which will provide "any way to > deal with the *business* and *operational* issues of asking some remote > ISP to provide QoS service for you in any sort of scalable way." Different problem. No cigar. This bait and switch reminds me of the same sort of tactics of those who endlessly pointed out that ip6 didn't solve the route explosion problem. As in, duh. Mike 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: Flow Label
Randy Bush writes: > >> I do not believe that there is currently any way to deal with the > >> *business* and *operational* issues of asking some remote ISP > >> to provide QoS service for you in any sort of scalable way > > Fine, but that's completely orthogonal to whether the flow label is > > a good idea or not. > > we don't care that no one can operationally use it. if it might sell > one more router, let's kludge up the net a bit more. Oh, please. There is a very straighforward tweak to RSVP to support this, and this is an *anti*-kludge since the original kludge was overloading the use of L4 information for QoS. I'm not aware of anybody at my employer salivating at the revenue potentials for a newly defined flow label. Mike 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: Flow Label
Scott Bradner writes: >all you're saying >here is that you don't believe in Intserv/RSVP. > > I did not say that at all > > I do not believe that there is currently any way to deal with the > *business* and *operational* issues of asking some remote ISP > to provide QoS service for you in any sort of scalable way Fine, but that's completely orthogonal to whether the flow label is a good idea or not. Only by placing a value judgement on the supposed intractability of that problem does it effect the outcome here. As in, if you don't think it's solvable, it would obviously be throwing good bits after bad. If you're in the "don't know" camp -- as I suspect many people are -- I think we can easily reserve a few bits and state that the flow label only applies when the reserved bits are zero and that all other combinations must be ignored. Mike 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: Flow Label
Scott Bradner writes: > Brian sez: > > In the intserv case, it is no different. In the diffserv case, the presumption > > is that we would use IANA-assigned, globally meaningful values, that are > > specific to a desired QOS treatment rather than to any individual traffic flow. > > The implementation details (including the DSCP value and router configurations) > > may differ from ISP to ISP, but the flow label bits convey end to end > > semantics. This is more powerful than port numbers whose semantics are poor at > > best for QOS purposes, and it works when the port numbers are invisible. > > > this still begs the question > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS? > > at least in the case of difserv if an ISP gets a DSCP there is some > implied authorization by the previous network (ISP or enterprise) - how > does authorization happen in the case of imutable globally meaningful > values? > > I see no reason to believe that such a field will be any use whatsoever > in providing QoS in the Internet - and it is redundant in an enterprise > because the enterprise can decide to not change the DSCP field > > unless there is some hint of a way for this change to serve any useful > purpose we should just leave things as they are Since you can make the identical argument about 5-tuple based classification, all you're saying here is that you don't believe in Intserv/RSVP. Fine. There's a lot of people who disagree. With the current wording, a new flow spec for RSVP can be created ala RFC 2207 and we can all agree to disagree. Mike 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: Flow Label
Scott Bradner writes: >Are you claiming that RFC 3182 (nee 2752) is >inadequate for interdomain? > > for telling someone who you are its fine but that does not even > start to address teh operational issues of how an ISP would make use > of the information There is already an existence proof: cellular. Nobody's claiming that this is easy though. Mike 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: Flow Label
Scott Bradner writes: > > > why do folk think that ISPs half way around the world would find it useful > > > to know what the sending computer wanted for QoS? > > > because the sending computer (application) knows the nature of the traffic? > > without a way for the remote ISP to get paid for treating the traffic in > some way other then best-effort I do not see that this helps Are you claiming that RFC 3182 (nee 2752) is inadequate for interdomain? Mike 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: Flow Label
Scott Bradner writes: > >Yes, and it almost always means "let's ignore > >admission control" too. > > yes, and that will be a real problem wherever the level of priority > traffic approaches the size of the links (which could easily happen > if video traffic gets prioritized) And?? The hard part of all of this is that e2e signaling for QoS is a genuine Hard Problem. Here you seem to acknowledge that it's needed, but you also seem to be saying that you can ignore if you drink the class based QoS Kool Aide. Mike 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: Flow Label
Perry E. Metzger writes: > > Michael Thomas <[EMAIL PROTECTED]> writes: > > Perry E. Metzger writes: > > > Michael Thomas <[EMAIL PROTECTED]> writes: > > > >Bzzt. You're overloading semantics. SPI's enumerate > > > >the set of packets for which a given security policy > > > >applies. That may have exactly zero to do with the > > > >QoS policies you'd like to apply. > > > > > > In the scheme proposed, flow labels just enumerate a set of packets > > > that a host has chosen to designate as a "flow" because, say, they're > > > all using the same TCP socket -- which may also have exactly zero to > > > do with the QoS policies you'd like to apply. How is it any different > > > than the SPI situation? > > > >Again, security policy is not identical to > >QoS policy. The only way to make them identical > >is to have separate IPsec SA's for each QoS flow. > >This would be a huge waste, both on the signaling > >front as well as the SADB cost. > > Er, you already in practice have an SPI for every flow. See my other > message on this subject. Uh, no. In practice there's a single SPI for all of the traffic. Also: in practice the cross product of QoS and IPsec is pretty rare. I expect that will change with the advent of lots of IP phones going across VPN's, but when that happens you want hard coupling of QoS and Security even less: VPN concentrators have finite memory/hardware for SA's. Since there's no security benefit, you're just adding cost to achieve feature parity. This would not be the case with the flow label. Mike 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: Flow Label
Perry E. Metzger writes: > Michael Thomas <[EMAIL PROTECTED]> writes: > >Bzzt. You're overloading semantics. SPI's enumerate > >the set of packets for which a given security policy > >applies. That may have exactly zero to do with the > >QoS policies you'd like to apply. > > In the scheme proposed, flow labels just enumerate a set of packets > that a host has chosen to designate as a "flow" because, say, they're > all using the same TCP socket -- which may also have exactly zero to > do with the QoS policies you'd like to apply. How is it any different > than the SPI situation? Again, security policy is not identical to QoS policy. The only way to make them identical is to have separate IPsec SA's for each QoS flow. This would be a huge waste, both on the signaling front as well as the SADB cost. And I don't see what TCP sockets have to do with anything; how a host OS allows packets to be marked is an API issue just like setting the DSCP. > >By all means, let's just ignore silicon considerations. > >Moore's Law trumps all, obviously. > > If they have to build tuple extraction into the hardware anyway to > deal with the implementations that don't do flow labels (i.e any > deployed in the next few years), how can we claim that we're going to > get around people having to build hardware? Given that several vendors > have already designed the hardware, how are we going to be helping? There's a huge difference between "building it in hardware" and "building it in hardware at speed". I have infinite optimism in the creativity of hardware geeks except for one thing: they always tell you what set of things fit into a die and that you get to choose which ones to delete when they don't all fit. The bigger you make certain modules the less you have for other things. In this case, fixed fields are good; linked lists are bad. Doable but bad is still bad. Also: you seem to be under the illusion that QoS classifiers are set in stone. They are not. I just took a quick look at SCTP: its ports are not in the same place as TCP/UDP; hence, hardware change. Each new IP protocol that we come up with will have the same problem. The flow label has the potential to stop that problem now and forever. Mike 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: Flow Label
Perry E. Metzger writes: > > Sorry, the SPI is no good for diffserv classification > > because it has no semantics. > > Neither does the flow label. Both are just a number that can be used > to distinguish a bunch of traffic flowing between two hosts from other > traffic flowing between two hosts. Neither has any semantics beyond > that. Bzzt. You're overloading semantics. SPI's enumerate the set of packets for which a given security policy applies. That may have exactly zero to do with the QoS policies you'd like to apply. > > I didn't say it makes no difference. I said that the difference is more > > likely to be in cost and waste heat than in speed. > > Given that the manufacturers who are doing this are already building > the transistors in to walk the header chain... By all means, let's just ignore silicon considerations. Moore's Law trumps all, obviously. 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: Flow Label
Perry E. Metzger writes: > Michael Thomas <[EMAIL PROTECTED]> writes: > > Perry E. Metzger writes: > > > I'm looking for statements from several router vendors that look much > > > like this: > > > >I don't speak for Cisco. I speak for myself. > > > >Sorry. > > Well, speaking for yourself, can you describe your simulations of > hardware performance with and without the flow label? I'm not especially interested in this game because some hardware geek somewhere is bound to throw enough transistors at the problem and claim that it doable. Big deal. It's an empty claim because it doesn't say what was given up in the process. I have witnessed firsthand hardware engineers on high end platforms react somewhere between disbelief and outright hostility at the prospect of chasing down header chains at line rate. CAM's -- as I've mention three times now -- are especially sensitive to bone headed standards potato blunders of this kind; I forget, but the transistor count is O(n^2) or maybe worse with the number of bits needed to form the key. IP6 is already at a big disadvantage given the need to key off of ~256 bits vs. 64 bits just for addresses. And lest you think that I'm just concerned about CAM based forwarding planes, think again; they all need to view enough of the header to classify, and that always impacts silicon as it gets bigger. Thus you get these choices: pay more than you should have, get worse performance, or delete other features you might have liked to go faster on a finite transistor budget. Oh, and you might ask your hardware vendors who claim to do this whether they can deal with flow classification of mobile IP with route optimization at line rate. And since MIPv6 route optimization is about as stable as jello, will they have the resilience to change their flow classier if it changes too? Mike 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: Flow Label
Scott Bradner writes: > > The traffic field gives the classification. The flow label > > could serve as a proxy for the port number and > > protocol type, > > the whole point of class-based QoS is to not have to deal at the > port and protocol level Yes, and it almost always means "let's ignore admission control" too. Just to make things clear, are you thinking of RFC 2996 style reservations or none at all. If the latter, all I can say is heaven help us if 911 happened on an uncontrolled diffserv cloud. Mike 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: Flow Label
Perry E. Metzger writes: > I'm looking for statements from several router vendors that look much > like this: I don't speak for Cisco. I speak for myself. Sorry. Mike 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: Flow Label
Perry E. Metzger writes: > >Indeed, > >it's seems to be all of the hangwringing over > >the obvious definition for these bits that > >has managed to shoot IPv6 in the foot, re > >fast flow clasification. > > There isn't a flow label in IPv4 and it seems > to be well deployed. Uh, make up your mind. Flow classification for QoS is not well deployed. If your entire point is that signaled QoS is a load of hooey, state that so we can all save time. > >But I'm not sure what you're asking for. > >Do you really have any doubt that forming > >the flow key from fixed postions in the > >IP6 header is going to not kick butt on > >chasing down header chains with a half > >dozen different rules dependent on protocol > >value to hopefully find a 5 tuple? > > Yes, I have substantial doubts on this. First of all, people already > have silicon that does this astonishingly fast. Define "astonishingly"; I don't know of anything that does IP6 vaguely approaching "astonishingly" except in slideware. IP6 adds the concept of header chaining which, though possible in IP4, is not common, and the cross product with QoS is even less supported (if at all). This is a substantial source of heartburn for ASIC designers, and is problematic for CAM based designs -- which are astonishingly fast -- where every bit is precious. > Second of all, they > don't yet have silicon that will do anything with the "flow label" and > it will be years before they could have deployed hardware like > that. ::snort:: What is absolutely for certain is that each new protocol and/or tunnel combination will be years away each time somebody decides that that combination is vital to existence as we know it. > Third, they'd have to chase down the header chains anyway, > because stuff like XP isn't going away. (In other words, we've > deployed, it is too late.) As if XP is the only thing that will require elevated QoS. In fact, I expect that if signaled QoS is deployed at all, it will be for voip, etc, widgets. Somebody sitting at a PC already has low expectations. > Fourth, I have yet to see any real > explanation of what this is going to do for people in > practice. Repeating my earlier request: Then you're hearing what you want to hear. > When I hear folks at Juniper mumbling that they already have their > hardware v6 support out in the field in their existing router line, > and I hear folks from Extreme mumbling that they have their packet > classifiers built (and they're hardly the only ones), Astonishingly fast, no doubt. Look, you can make just about anything go "astonishingly fast" with enough NRE + RE. The question is whether we should keep the IETF QoS full employment act fully funded by ignoring the layer violation. It seems that you're saying that it's a done deal therefore ignore it. What you're not fessing up to is that the reality is that NAT's have *really* won and that IP6's future is still very much uncertain. So, IMO, we either continue with this possible fantasy that we can engineer a clean new version of IP, or we chuck it all and give in to the least common denominator of hacks upon hacks upon hacks. There are lots of other things in this class too; my favorite bit of suspended disbelief is renumbering. > and I look at > the fact that there are a whole lot of v6 enabled systems already out > there in the field that aren't going away, I feel like I have to start > asking hard questions. "Whole lot"? Please. And adding a flow label to the kernel is *hardly* rocket science. > If we're going to start mandating people do something new at this late > stage of the game, we'd better have a good engineering rationale for > it, along with good measurements to back up that rationale. Nobody's "mandating" anything any more than "mandating" DSCP marking. If you don't want elevated QoS, you are completely at liberty to ignore all of this nonsense. Mike 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: Flow Label
Perry E. Metzger writes: > > Michael Thomas <[EMAIL PROTECTED]> writes: > > If you don't believe in signaled QoS, you don't > > believe in any use of a flow label qua flow label. > > I thought we had a "traffic class" to permit "signaled QoS" for some > value of "signaled QoS". I was unaware flow labels were intended for > this purpose. DSCP's aren't guaranteed to be end to end. > > And XP can make flow labels along with DSCP's as > > soon as the current or next gen worm is done > > rewriting their kernels. > > I'm an old fashioned kind of engineer. I'd like to see some folks from > router vendors give us precise information about the *exact* use > they'll put the flow label information to, and quantitative > information about how much better it will be for them to have the flow > label than not to have it. Engineering by committee is bad enough -- > engineering by committee and by hearsay simultaneously is far worse. If we want to future proof some of the bits, we can reserve 2 or 4 bits and make 0 be this definition. This is *hardly* a new and unexpected semantics fo the flow label. Indeed, it's seems to be all of the hangwringing over the obvious definition for these bits that has managed to shoot IPv6 in the foot, re fast flow clasification. But I'm not sure what you're asking for. Do you really have any doubt that forming the flow key from fixed postions in the IP6 header is going to not kick butt on chasing down header chains with a half dozen different rules dependent on protocol value to hopefully find a 5 tuple? Yeah, yeah, some (edge) routers will have to do that anyway, but this is *such* a no-brainer for the host that they deserve lousy (degraded) service if they can't be bothered to implement either diffserv or setting flow labels. Mike 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: Flow Label
If you don't believe in signaled QoS, you don't believe in any use of a flow label qua flow label. Fine; many people don't. For those people, you have the DSCP and the luck of the draw. It's infinitely mutable, etc, etc. Be happy because there's nothing to be done here. And XP can make flow labels along with DSCP's as soon as the current or next gen worm is done rewriting their kernels. Mike Perry E. Metzger writes: > > Michael Thomas <[EMAIL PROTECTED]> writes: > > > One must ask what kind of layer violations this is intended to > > > stop, and what the purpose of those layer violations is. Generally > > > speaking, routers only reach in to the lower layers to determine how > > > to differentiate traffic between two hosts for purposes of > > > prioritization. > > > >UDP ports in ESP encrypted payloads. Tunnels inside > >tunnels inside tunnels inside tunnels. New protocols > >which may not even have abstracted ports. New Protocols > >period. TCAM widths that lose to Moore's Law. > > > >Need I go on? > > Yes, you need to go on. For the most part, I'm not sure this is going > work out. As I note, we've already deployed. Windows XP and such > aren't going to be obeying any of this, so the routers have to look at > the contents of the packets anyway. For many of the protocols we're > dealing with here (such as tunnels inside tunnels) it isn't clear > there is a clean way for the mechanisms to actually extract an > appropriate flow label under the new definition, and, most > importantly, as I noted earlier, you can't figure out how to > prioritize traffic using the flow label anyway. > > > > If it is intended to stop routers looking at the different layers to > > > prioritize traffic, it is a failure, since the flow label tells an > > > intermediate router nothing it needs to know to prioritize traffic > > > other than "this is flow #N". You can't decided "hmm, interactive > > > traffic -- better bump that above bulk file transfer" based on the > > > flow label. At best, you can use the flow label for doing something > > > like penalizing flows with non-friendly flow control > > > characteristics. > > > >RSVP is your friend. > > The century that RSVP is implemented and deployed I'm sure it will be > used, at least once in a while. (I don't expect our descendants to see > that day, but...) > > Meanwhile, in practice what people tend to do on things like congested > leaf routers is prioritize based on traffic type. > > -- > Perry E. Metzger [EMAIL PROTECTED] > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.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]
Flow Label
Perry E. Metzger writes: > > Am I correct in saying that, at this point, the flow label is at most > a way for intermediate routers to avoid layer violations, since a flow > is immutable and is properly given as a tuple? Yes. > One must ask what kind of layer violations this is intended to > stop, and what the purpose of those layer violations is. Generally > speaking, routers only reach in to the lower layers to determine how > to differentiate traffic between two hosts for purposes of > prioritization. UDP ports in ESP encrypted payloads. Tunnels inside tunnels inside tunnels inside tunnels. New protocols which may not even have abstracted ports. New Protocols period. TCAM widths that lose to Moore's Law. Need I go on? > If it is intended to stop routers looking at the different layers to > prioritize traffic, it is a failure, since the flow label tells an > intermediate router nothing it needs to know to prioritize traffic > other than "this is flow #N". You can't decided "hmm, interactive > traffic -- better bump that above bulk file transfer" based on the > flow label. At best, you can use the flow label for doing something > like penalizing flows with non-friendly flow control > characteristics. RSVP is your friend. Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Robert Elz writes: > Date:Fri, 21 Dec 2001 08:56:26 -0800 (PST) > From: Michael Thomas <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > |I sure see a difference. If my stack does that for me > |I always have the option to cd /usr/src/linux/net/ipv6 > |and make it stop doing that; YMMV. In a router, I stop > |having that option. > > If your router does it, and you don't want it to, you reconfigure the > router, or if that's not possible, you replace it. If it isn't your > choice to change that, then you're probably attempting to defeat the > policies of your local net. Um, no. I don't want my telephant's local policy -- which is largely to be as inflexible as possible -- to effect end to end semantics. I also don't want them to install net nanny's or other intelligent network junk either. > |I can. It's the slippery slope to MIDCOM. > > I have learned to largely ignore slippery slope arguments. They're > mostly FUD. By all means, ignore away. Lots of people think that it's a bunch of FUD about NAT's too. They're by and large completely ignorant. > |If we *really* want to preserve options here, > |let's incoprorate Christian's suggestion that > |we save a couple of bits out of the field which > |define the sematics of the flow lable. > > Are you paying any attention to what is being suggested? Really? > What I have been describing ie *exactly* what is in their draft > (as it stands now, before any input from the SLC meeting, or this > discussion on the list has had a chance to affect it). Yes, yes, big deal. They wanted to support first hop rewrite, it got a negative reaction and from what I can tell they're not wedded to that piece. Do you actually disagree, or are you just being argumentative? Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Robert Elz writes: > | Alternatively another part of the stack may also choose to set it. > > Yes. But don't you see how similar this is to having a router set it? > In either case, it won't (shouldn't) be altered if it has been explicitly > set by the application, but assuming the existence of a "not set to anything" > or if you like "I don't care" value (which is the 0 value currently), > if there some particular reason it makes a big difference whether something > down the stack change it, or whether a router does? In either case, when > the packet arrives at the destination application, it has been changed. I sure see a difference. If my stack does that for me I always have the option to cd /usr/src/linux/net/ipv6 and make it stop doing that; YMMV. In a router, I stop having that option. > | => So I guess you're arguing for allowing the > | case where routers can modify the flow label > | from zero to X. But should we then force them > | to set it back to Zero again ? > > Yes, that's it - though "arguing for" is perhaps too strong, > "arguing against prohibiting" would be better. > > And I can't imagine why. I can. It's the slippery slope to MIDCOM. If we *really* want to preserve options here, let's incoprorate Christian's suggestion that we save a couple of bits out of the field which define the sematics of the flow lable. The beauty of Alex and Jarno's proposal is it's simplicity. Mucking with that isn't likely to provide anything new, IMO. Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Francis Dupont writes: > => I didn't say that dumb host/smart router is good, I did say this is > a common scenario. But I am tired of flow label discussions, usually > they go nowhere. Please count me as a "keep current (non) specs" supporter. So here's the end-game for the flow label allowing for dumb hosts/smart routers: MIDCOM. Can we just say no? Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Francis Dupont writes: > In your previous mail you wrote: > >The current draft states that a non-zero label could be changed by an >intermediate node to a non-zero value. However, during the discussion on the >topic in SLC it was concluded (IMO) that this is undesirable, and it would >be more useful (and sound) to keep the value always immutable (end-to-end). > > => I disagree: if the end node is too dumb to set itself the label > (i.e. just uses in any case the zero value) and the first router > for instance sets the label when needed then the zero value should > not be immutable. I don't use dumb hosts (:-) but it seems this kind of > things already commonly happens for RSVP in the real world so we should > keep the door open... So I fully share Robert Elz's opinion. I'm afraid this brings us back to the slippery slope of edge-remarkers and the layer violation of routers wanting to look at L4+ headers, and the inherent difficulty/impossibility. Please, let's not go there again. >AH: It could be possible to change AH, but it might not be worth it. > > => Robert Elz has just explained why we must not change AH... > And it seems you don't understand that AH can't really help to protect > something in transit, i.e. intermediate routers have not the key and > can't verify the AH MAC. If there's a change that will happen to AH it will be moving it to Historic. Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Brian E Carpenter writes: > Yes, the flow label is explicitly excluded from AH. So it could be modified > en route and you can't authenticate its value. Assuming we decide to use > it as an end2end value, that could be viewed as a bug. That would be a pretty funny view. The only way to make it immutable would be to share a security association with each participating router along the way. I don't think we want to even vaguely contemplate going there. Mike 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: draft-rajahalme-ipv6-flow-label-00.txt
Margaret Wasserman writes: > If I seem to be missing an important point or concept, please send > some hints or pointers. Margaret, I don't think you're alone wondering what all the fuss is about with the flow label since it's fairly obvious that normal Intserv classifiers function equivalently. However, there's two fairly important things that the flow label brings to the party: 1) Speed Speed is primarily due to the fact that the flow's tag is in the IP header itself at a fixed location. This simplifies the processing -- helpful for ASIC's -- as well allowing classification of problematic flows, such as IPsec and flows which contain destination options or other things which require that the header list be traversed. 2) Protocol independence RSVP normally uses a 5 tuple which implicitly expect a source and destination port. Other protocols either disagree (IPsec which requires classification based on SPI) or are undefined (SCTP...). Use of the flow label will allow us to deploy new protocols without having to come up with new RFC's to describe how to create its own flow classifier. Better, it will not require software/hardware upgrades in routers to be able to give QoS treatment to new IP protocols. Mike 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]
