RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
> Pekka Savola wrote: > Then you have to first compromise the system concerned, going > through all the other protections. > Before you hack the box to circumvent the hosts.allow you still have > to ... well, hack the box! An interesting chicken and egg problem, no? Never heard of a joe-job from the inside? You might have a 30-second window at the host console while nobody is looking, enough to vi the hosts.allow file, not enough to reconfigure the system. I have seen a case of someone that got hired as a janitor and that spent weeks typing a file one line per day. Hacking a network is 50% social engineering and penetrating the physical defenses, 45% luck, 5% technical; most of the time the moles you get in the inside are not top-notch engineers. > In the same vein, one could say that using local addresses gives > no protection because you could just (as root) add a global address > on the box. Does not do any good if you don't reconfigure the router. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
> Pekka Savola wrote: > Incorrect. Have you even used hosts.allow? What makes you > think it's easily hackable, instantly abusable by a vaguely > clued low-level thief? Gee, even I could use vi. As soon as you have root access, what is your problem? I can vi the hosts.allow file, I don't know how to create a tunnel. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
> Pekka Savola wrote: > For example, for some services I maintain, I have: > - TCP wrappers configuration in the host/service itself, > using /etc/hosts.allow > - The local host firewall settings, doing similar > restrictions as above > - Missing default route on the host, only some selected > routes used > - The first hop router/firewall settings > - A configuration at the site border router To beat you with your own argument: all of these things can be easily hacked, therefore there are no reasons to use them. Why are your security precautions this different than localized addresses? It is as easy to hack the hosts.allow than it is to create a tunnel outside. Remember the car lock analogy: your host.allow trick is no better than the typical car lock: a vaguely clued low-level thief will open it in a matter of seconds. And still you use it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
>> Brian E Carpenter wrote: >> There is no defence against misconfigured routers, except >> for well configured routers elsewhere. > Pekka Savola wrote: > For example, for some services I maintain, I have: > - TCP wrappers configuration in the host/service itself, > using /etc/hosts.allow > - The local host firewall settings, doing similar > restrictions as above > - Missing default route on the host, only some selected > routes used > - The first hop router/firewall settings > - A configuration at the site border router This is not good enough, because it assumes that all hosts have been hardened. A good security must prevent data to be sent out even is the host has a dumb setup and even if the firewall/SBR has been compromised. > Five layers of security should be enough, you'd think? > Even a couple of them might be OK. Wrong. I have seen multiple times five to six layers of firewalls just in the DMZ, plus all the host hardening that you mentioned below. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: A roadmap for end-point identifiers? (was Re: where the indirection layer belongs)
Pekka, >> Iljitsch van Beijnum wrote: >> Are you saying that we should make a clear distinction >> between identifiers and locators, and not have any values >> that are valid in both realms? > Pekka Nikander wrote: > Yes, in the long run. Would that include going to identifiers that are longer than 128 bits? > In the short run, we probably have to continue living in a > world where there is no clear distinction between the two. Sorry if I ask a stupid question, but the main issue deployment issue HIP has is basically that every host would need an HIP stack. Since there is not much you can't do about this, why haven't you pushed the reasoning further and opted for an extended HIT that would not have some of the current limitations (background: we did discuss the issue in Atlanta and one of the things I recalled is that we both wished we had more bits). > I do understand your point about the benefits of an > identifier also being a locator, but I also believe > that the benefits of clean separation will more than > pay the drawbacks in the long run. (I don't have any > analysis or data to support this belief, though.) I'd be interested in some vague rationale about this. > Nodes with well-known addresses, such as servers and those > using stateful configuration, are most vulnerable. Nodes > that are a part of the network infrastructure, such as DNS > servers, are particularly interesting targets for attackers, To put this in context, the paragraph above assumes that the server is being accessed using the identifier, and that the hackers targets the id/loc mapping mechanism in order to map the id to _his_ locs, not the legit ones. Did I get this right? And if I did, what difference does it make if the locators and the identifiers are segregated? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
> Pekka Savola wrote: > Do you also want your domain name for free? It _is_ free and so is my SSL certificate and my DNS hosting, if you must know. Just because you have never seen something does not mean it does not exist. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
>>> Pekka Savola wrote: >>> Sure, but there are also other ways to obtain addresses. >> Michel Py wrote: >> Really? Would you care naming one available today? > a) talk to your ISP (or one of its upstreams), which his > hopefully a LIR, or b) talk to any LIR, and pay him e.g. > 100$/mo. He'll gladly give you address space even though > you don't want physical connectivity at all. Is that what you call a solution available today? You have not been listening. 1. I don't want to pay for it. 2. I don't want that space to be reallocated to someone else if the LIR I got it from goes belly up. Hijacking is less risky. Now, it a part of each LIR space was earmarked for that purpose and if there was a RIR policy that says that if LIR space is reallocated to a new LIR the new LIR has to honor address assignments made by the old one that would be another story. jj, where's your draft? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing
> Mark Smith wrote: > I do like the idea of autoconfiguration, but in larger networks, > it can start to work against you - your network can start doing > things behind your back that make it terrible to diagnose faults. Indeed. Trouble is with all automated systems is that the engineer that troubleshoot will at some point make assumptions about what the automated system does, often based on the premise that it always does the same and that there might not be anything to check or do anyway. I'm not saying it's bad, but the common practice of autoconfiguration mechanisms is that they are not included in the engineer's team and don't talk to each other Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Solving the right problems ...
> Jeroen Massar wrote: > My current idea puts it at the resolver level. The > application gets the 128bits identifier, which > actuall is a IPv6 address, either given out from a > special registry or simply from an /48 that is > already assigned to you. This address can be used > for both routing and identification purposes and > can easily be assigned to hosts by using RA. Jeroen's idea is MHAP-lite; differences are that it works on the hosts not on the routers and uses DNS as the ID/LOC mapping mechanism. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, > Pekka Savola wrote: > Do you mean that folks who hijacked the address space deployed > NAT to be able to continue using their hijacked space inside > their network but do one-to-one conversion at the border? Yes. Today it is extremely common to see this with RFC1918 addresses in the inside, but there still are a handful of networks that have hijacked non-RFC1918 space that don't see why they should bother renumbering, going by the rule if it ain't broke don't fix it. There is a chicken-and-egg argument on the timing, which is "did people use NAT to do this because NAT was available" or "was NAT developed for that purpose" but in the end the result is there. >>> On the other side, I fail to see the need to hijack a >>> prefix for your running system. IPv6 addresses are quite >>> obtainable nowadays if you're an equivalent of LIR. >> Doubly irrelevant to the discussion: first, you can't ask >> every network to become a LIR; second, the need for public >> addresses and local addresses is totally different, so >> even if one enterprise has become a LIR to obtain public >> addresses it does not remove the need for private ones. > Sure, but there are also other ways to obtain addresses. Really? Would you care naming one available today? > So, what you're really saying that folks would hijack > prefixes to be used internally (instead of trying to use > them externally). I wonder if that was the case of > prefix hijacking by-and-then. When I did hijack prefixes in the early 90's it was mostly a matter of convenience for internal use. > My (and others) goal is to show that the use of local > addressing is not the right approach in many cases, and show > some alternative means to achieve the same ends. It does not work that way. First, network administrators for the most part don't read this. Second, you have not been an enterprise network administrator for any significant time so they're not going to listen to you anyway. Third, the reasons enterprise network administrators make decisions are for a significant part based on experience; in other words the reason to use local addresses is either because some day one did not use them and got shot, or because some day one did use then and it saved one's butt so one keeps using them. What you have is untested theories about network design, what they have is years of experience that built a sense of what works and what does not. > I do not see the need to repeat IPv4's mistakes in IPv6. The mistake would be not to provide a local addressing solution and have to do RFC1597 for IPv6 again. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
> Brian E Carpenter > [large snip] Completely agree with your latest post, save for this: > So it's simply inevitable that enterprises will use > private (i.e. non-PA, non-routeable) space. Our > challenge is to make it as good as we can. Not good enough. Our challenge is to make it to reach the same sex-appeal, level of comfort or whatever you want to call it than what the enterprise network administrator can do with a combination of vendor proprietary support and some homebrewing. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
> Leif Johansson wrote: > Sigh. This is almost to dumb to respond to and I'll be kicking > myself when the next stats come out ;-) It is possible to build > a good car lock (I claim) and some day someone will find the > economic incentive to do so. Since I'm so dumb explain me why isn't the good car lock installed on every car yet? It's not like the car lock problem is new. And why isn't your miracle security setup installed on every network? We have a word for people such as yourself that claim things that they don't have: vaporware. If you were an experienced network administrator you would have plenty of opportunities to appreciate how close the bullet passed and how this little extra step saved you precious butt big time. So far, all my car lock did for me is prevented me to get into my own car, but that's not a reason not to use it. Pray you don't get hacked, because when you do your senior management will get an external consultant to assess your network, and good security consultants will google your name and find your postings; in the US, you would be not only fired but sued by your former employer for negligence. The fact that the lock does suck is not an excuse not to use it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]
> Leif Johansson wrote: > The added protection you get from a private address space > is isn't worth the bits the configuration is stored in. Exactly the same as saying that car locks are not worth having because they're so easy to open that they don't stop anybody. It is true indeed that any amateur with a coat hanger will open a car in a matter of seconds. As a matter of fact, I locked my keys in my car a while ago and I had to call AAA to let me back in. It took more time to the driver of the AAA truck to fill the paperwork than it did to open the door. Guess what: cars have locks anyway and nothing you can say about car locks being a joke is going to change it. If you don't like it, you can leave your car open. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, > Pekka Savola wrote: > What I'm trying to say is that we need to first figure out > where we need local-use applications -- and, as an interim > feature, maybe reword the current draft so that it's > apparent which current perceived local-use scenarios > require specific requirements. This appears to me the opposite of what is generally done within the IETF. First we write requirements then we look at specific scenarios, not the opposite. Besides, at this stage of things it is generally admitted that a broader view is useful in describing the problem in context. >> which is one of the reasons that eventually led to RFC1597. >> What makes you believe that the reasons they did it in the >> past do not exist anymore? > And what problems has this caused that are really, really > problematic? NAT, in the first place. > On the other side, I fail to see the need to hijack a > prefix for your running system. IPv6 addresses are quite > obtainable nowadays if you're an equivalent of LIR. Doubly irrelevant to the discussion: first, you can't ask every network to become a LIR; second, the need for public addresses and local addresses is totally different, so even if one enterprise has become a LIR to obtain public addresses it does not remove the need for private ones. > In addition, compared to the situation back in 1994 (and > earlier), people actually use Routing Registries to check > advertisements. You really cannot assume that you could > hijack a prefix and have it work in the Internet. I have live examples that use NAT for that purpose and some other people have contributed the same here. You did not answer the question. The question is not why network administrators are wrong to use local addresses. Wrong or not, and whether you like it or not, they have, do and will use them. Putting your head in the sand or stating that there are no reasons to use local addressing is not going to change it. There are extremely large numbers of networks that currently use local addressing; RFC1918 is not what created this situation: to the contrary it is a by-product of their widespread use and created well-known prefixes for them. What makes you thing that the requirements of all these networks have changed? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]
Pekka, > Pekka Savola wrote: > 1. Shouldn't we first see the requirements for site-local > replacement (and other issues) and not jump straight to the > requirements for local addressing? Do you mean that the Hain/Templin draft is too generic, or not specific enough? >> 3.1 -- "Network managers have stated, and historical >> experience has shown, that there is a need for addresses >> that do not require public registration." > ==> there is no supporting evidence of this expect vague > statements. Please be more explicit as I don't see how we > can take this for given. Maybe you are too young to remember but network administrators have hijacked addresses for ages, which is one of the reasons that eventually led to RFC1597. What makes you believe that the reasons they did it in the past do not exist anymore? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
>>> Tony Hain Wrote: >>> If an address does not meet the needs of the application, >>> use the provided flag to ignore it. Trying to prevent others >>> from using a technology that solves their problem is simply >>> being obstructionist. >> Michel Py wrote: >> A tactic often used to stall a technology by people or >> organizations that can't deliver when there is ample evidence >> on the market place that other people or organizations can >> indeed deliver it. > Keith Moore wrote: > And if you are claiming that I have ANYTHING at all to do with > promoting ANY vendor's products, then you are WAY out of line, > and I demand an apology. As always you don't read what other people post. Read my text again and explain me where you find the words "promoting" or "endorsement"? these are YOUR words, not mine. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
> If an address does not meet the needs of the application, use the > provided flag to ignore it. Trying to prevent others from using a > technology that solves their problem is simply being obstructionist. A tactic often used to stall a technology by people or organizations that can't deliver when there is ample evidence on the market place that other people or organizations can indeed deliver it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
Jim, > Jim Bound wrote: > But seriously. When the parts get built as engineers we > have the responsibility to support the technical criteria > for what the user don't see in implementation and > architecture. In fact they trust us to do that. And > incorrect use of LLs I strongly believe can hurt users > as an engineer/architect and SLs are well... That's the kind of reasoning that got you playing in the junior league and forced you to adopt your competitor's proprietary protocols. Have you configured an HP ProCurve L3 switch recently? The CLI is a very incomplete and pale attempt at copying IOS and it even incorporates some Cisco proprietary protocols such as CDP (Cisco Discovery Protocol). Your company completely missed the boat on routers and switches, please enlighten us why you think you are right this time? > But I am here to make folks like you totally miserable :--) I have a few dispositions for that myself. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
> Jim Bound wrote: > What was my point of compromise for SLs in that past > discussion before this wise WG consensus deprecated > them? Ok age happens I will respond :--). PUT > CONTROLS ON THEM SO THEY DON'T EVER LEAVE A SITE AND > AGREE TO THE RULES FOR THE SITE BORDER ROUTERS. But > nooo...folks wanted to > leave that open "just in case" ergo support for > free-for-all (I was never sure just in case for what) > and I will stop there. > There are times we need to leave things open ended > SLs or LLs are not one of them in my opinion. I agree, but this does not justify using a cure that is worse than the disease. SLs are bad, what are we getting insead? IPv6 swamp and NAT. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
Jim, > Jim Bound wrote: > 100% agree. I was stating the tremor before IPv4 NAT actually > happened not why they are using it. I also don't think users > are stupid but maybe far to trusting of vendors and the IETF > like MObile IPv6 WG was of IPsec :--) What drives me nuts with you is that although you have a far-better-than-average understanding on how the market works you have failed to realize that users ultimately drive the market and these users don't actually give a hoot to LLs but do to SLs. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Some IPv6LL operational experience
> Jim Bound wrote: > The reason NAT got away with what it did is the users got > blind sided and then IETF got sucked into building a special > NAT working group (which I objected to at Munich) and look > at the mess we have out there today. At least to me it's a > complete mess. I have to disagree with this. The reason NAT is popular is not because users are stupid. Users indeed are stupid (count me in, I use NAT) but they will continue using NAT as long as the pros outweigh the cons. It is too late to do anything about IPv4 NAT, but if we see IPv6 NAT happening it will be our collective failure to provide solutions that are better. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
>>> Erik Nordmark wrote: >>> FWIW, I think a multi6 solution with id/loc separation will >>> make the local addressing concerns go away. If it provides something that is almost as good as PI. >> Tony Hain wrote: >> Any separation will require a mapping infrastructure to >> dynamically bind the values back together. > Keith Moore wrote: > agreed. Ditto. >> Such a mapping infrastructure >> will have all of the scaling concerns of DNS, > Nor is there any inherent reason that propagation of updates > has to be like DNS. Agree. > plus the constraint that its convergence times are extremely short. > There is no well-known technology for running a global multi-master, > cross trust boundary, database, with appropriate caching for scale, > and convergence times that are useful for application failover. It is not needed as long as the id/loc system does not need the full database to be fully replicated all over the world at all times. In other words, the requirements for that global multi-master, cross trust boundary database can be lessened by an id/loc system that could accommodate a partial picture as a bootstrap phase for its own mapping, and the convergence time can be brought by the id/loc protocol instead of database convergence. > What would you call BGP then? Granted, it's not exactly a database, > but it's certainly "multi-master" and "cross trust boundary" and it > at least attempts to converge within a timeframe in which apps can > fail over. I think that for practical purposes it's close enough of the definition of a database. Granted, it is not nearly as complex as OSPF but it could be called a database. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: IPv6 Link-Local Use Issue for Applications
> Do you have any first hand experience of this happening? > I have heard the story several times, but I would like > to see something definitive. I have seen it 10+ years ago with a batch of NE2000 clones. They were perfect copies of the Novell model (including the logo) but they all had the same MAC address. For what I remember they were made by a large scale copy facility in HK and the guys there had never done a serialized card before, so they all came out the same. > Does anyone have in their possession two or more NICs > with the same MAC address? I have stopped using 16-bit ISA cards a while ago. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: site-local observations from the outside
Jim, > Jim Bound wrote: > Valid. If it goes to RFC status will that make > you comfortable? Nope. The very point I am trying to make is that RFC != enforcement mechanism. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: local addresses, 6to4 and 2002:RFC1918 [Re: Moving forward onSite-Local and Local Addressing]
Brian, > Brian E Carpenter wrote: > RFC 3056 says: > [SNIP] > Now, which word in "MUST NOT" is hard to understand? I think you give way too much importance to what a MUST NOT in an RFC can achieve. - As seen with the Elz appeal recently, the IETF is not interesting in forcing users to configure their networks in the IETF way. - Even if there was some sanity check code, I work for a few organizations that would easily twist their vendor's arm in order to provide a special flag to bypass the check. - Not to mention that some people won't find difficult to pad the check with NOPs. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Tim, >> Michel Py wrote: >> - If globally unique IPv6 address space is free, I am willing >> to give these $2.5k/yr to my ISP to announce my /48. > Tim Chown wrote: > Well, the ISP announces it, but how far does it get? It gets to you, where you filter it but it does get to you. You filter it and here's why: as a NREN, your "customers" don't come to you and say "you have 2 solutions: 1. you keep my business and here's extra cash to "forget" to filter prefixes; 2. someone else will be happy to have both my business and the extra cash. So you do have the luxury to do things the right way, which we thank you for. However, for for-profit ISPs that do not have the taxpayer's money to create a network, the choice is not as easy and will be choosing between a) do things right and don't capture the emerging IPv6 market and b) look the other way and get extra cash much needed to finance building the IPv6 infrastructure. There is a critical mass factor in this. Sure, if it's only one guy trying to get his prefix announced, it goes nowhere. Trouble is that announcing prefixes, although it does create problems in the long run, solves so many issues in the short term that every enterprise is going to do it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: 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]
RE: apps people?
> Would you say that your network is a typical representation of > a future Joe Six- Pack network with IPv6? With the eBGP peers > and all? A little overkill for Joe Six-Pack, but the eBGP peering is already available for free from several providers, I don't see why it would change for power users. > With that setup I think you are competent enough to handle your > IPv6 internal network, and filtering (routing, access-lists and > what not) without relying on site locals for any of it. I always like that people that haven't even seen a diagram of my network teach me how I should operate it. > So the people in whos homes these devices are installed have > several subnets internally Not internal to their home. Their home subnet is part of the corporate address plan. > and therefore needs to run a dynamic routing protocol within their > home as well as extending it to the service provider upstream? No relation with the former paragraph but yes. Static routes suck. > Is NAT involved here somewhere? Most of the time. > Or do you mean that there are VPNish configurations over which > the dynamic routing is run with an internal corporate network > but still a static configuration for the defaultroute to the > service provider and vice verse? For v4, mostly. There are three types of config. On one the default route comes from the dynamic routing and goes across the tunnel; the only routes in the home router are two /32 routes to the corporate VPN endpoints (pointing to the default gateway of the ISP). This ensures that even regular web surfing is encrypted on the last mile. On the other one the tunnel is used to access the corporate network only and the regular Internet traffic goes over the default route to the ISP. On another one there is no public Internet access and the network is used to access corporate assets only (typically there will be another PC to access the net). For v6 there is no clear picture. > Does the people in their home manage their configuration and > routers themselves or is that provided as part of the service? No, heaven forbid. Done by corporate IT and/or consultants. > In my view the "consumer" is the average user connecting > the home to the Internet by some form of broadband access > to get access to triple-play services etc. Perhaps that > connection is also used for telecommuting. But I do not > see the requirement for dynamic routing and through that > route filtering with the upstream service provider(s). How do you configure multiple links? A T1 with ISDN as a backup (from the same provider) is a very common config. > Running a VPN tunnel and routing over that to the job > over the broadband access is a different thing, most likely > not involving the service provider at all except for > carrying tunnel packets. Correct it's a different animal. > I commented on route filtering in combination with security. > I argue that route filtering for security to prevent hacking > is neither common ridiculous > nor encouraged. There are many valid uses of route filtering > in networks with routing requirements. I do not think the > average consumer network will be of such complexity to require > filtering of routes, and I do not think that site locals would > add anything if route filtering would be used for security to > prevent hacking. You certainly are entitled to an opinion, but the bottom line is that it is my call and I decided otherwise. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Geoff Huston's draft and the intended use of the hinden/templin address space
Nir, > Nir Arad wrote: > I would like to point out again, that as per my suggestion, nodes > MUST NOT send, receive or forward traffic in which the source and > destination addresses are not of the same scope. That would some problems but appears to be unworkable to me. It's not flexible enough. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Geoff Huston's draft and the intended use of the hinden/templin addressspace
Brian, > Brian E Carpenter wrote: > I kept reading, because if these things are created they *will* > certainly end up being used as end point identifiers. Can you develop why? In the absolute I can find lots of reasons but I don't see why the identifier/locator solution would prefer using these vs. having its own prefix. I agree that they would be used for NAT though, because NAT does not need anything to be invented. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: PI, routable PI,
Margaret, >> Michel Py wrote: >> - Whatever we can say about it, the network administrator gets >> to pick what becomes of the Hinden/Haberman draft, globally >> routable PI _or_ >private address. The prefix can't serve both >> purposes at the same time for reasons explained 20 times on >> this list already. > Margaret Wasserman wrote: > You may think you've explained this 20 times, but I still > don't agree with it... > If you don't pay your ISP to route _your_ Hinden/Haberman > prefix, it won't be routed. Voila! Private addressing. Trouble is, I _want_ to pay my ISP to route my Hinden/Haberman prefix, for three reasons: 1. (legitimate) I want to communicate with the Hinden/Haberman prefix of another enterprise. I could use a VPN/tunnel solution, but it is a lot simpler to do end-to-end IPSEC, which means routing the prefix. 2. It solves my multihoming problem. If the IETF had done anything about multihoming in IPv6 I would not have to pervert the Hinden/Haberman draft. 3. It solves my renumbering problem: I "own" the Hinden/Haberman prefix, and I keep it forever. When I have my IETF hat on, I understand that these solutions are short-sited, but when I have my network manager hat on, I'd do anything that works when I need it. I can always upgrade to a better solution when the IETF comes up with one (wishful thinking). > Why do you care about whether someone else's prefix is > globally routed? Because everyone is going to try doing what I described above, I hope this much is clear given recent postings. Guaranteed. a) It leads to routing table explosion and all the stability issues we are having with v4 today. b) Re-using Bob's terms, this would become a self-regulated system, meaning that in the long run only the rich would be entitled to announce their prefix. Putting aside the ideological debate about the money, this leads us directly to NATv6, because when the money threshold is reached, people that have been using their Hinden/Haberman prefix will keep it and turn to NAT as a replacement of announcing their prefix. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]
On Behalf Of Brian E Carpenter > I think it does, because it makes "less than global" ambiguous. > Does it mean "my intranet", "my intranet plus a VPN to company > X", "a VPN to company X but not my intranet", "my VPNs to > companies X and Y plus a secure subset of my intranet", or a > combinatorial number of similar choices? I would be open to accept the idea that it means "my intranet" and that we would need to use global addresses for the rest of the scenarios you mentioned. It's not as flexible as it-could-be-if-we-lived-in-a-perfect-world, but will address the bulk of the needs. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
> Eliot Lear wrote: > The question isn't whether you *can* do it but whether > it's a good and scalable approach. There was code > *before* this debate started. Indeed. And people were deploying before this debate started as well. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
> [EMAIL PROTECTED] wrote: > Among who? You continue to talk about consumers and how > things would be easier for them with site-locals. No > consumers are using route filtering today. No consumers > will need to use route filtering. On which planet are you living? I have seen hundreds of consumer networks that use route filtering. Even on my home router I have a dozen of route-maps. Get real. > ISPs use route filtering. People with corporate networks > use route filtering. But they do it for the other reasones > (see above), not for security. That is blatantly false. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: PI, routeable PI,
Brian, >> Michel Py wrote: >> Because then the addresses used on the private network would be >> routable PI, which is exactly what network designers don't want >> when they design a private network with private addresses. > Brian Carpenter wrote: > I still don't understand the difference between using a > Hinden/Haberman address or a hijacked address as a routeable > prefix. Fundamentally, not much and I do agree that the Hinden/Haberman draft is preferable in any "localized" situation, but I see you still are not getting my point, likely due to my poor wording, I apologize being so heavy. Allow me to try in other words: Short try at it: For local use only, it is less risky to hijack a random prefix than to use Hinden/Haberman, not because Hinden/Haberman is inherently risky, but because the risk that it will be used for another purpose than local use is high. Long try at it: - The enterprise has two unfulfilled needs: globally routable PI and private addresses. - Whatever we can say about it, the network administrator gets to pick what becomes of the Hinden/Haberman draft, globally routable PI _or_ private address. The prefix can't serve both purposes at the same time for reasons explained 20 times on this list already. - Since the only thing that can solve the PI need short term is Hinden/Haberman, that's what it becomes, leaving the network administrator with no other choice but to hijack for private address use. This is doubly crappy, but perverting Hinden/Haberman is a whole lot better than no PI at all, and the ugliness of hijacking as long as it is contained within the private network does not exist because nobody can see it :-) I'm not saying hijacking is good, what I'm saying is that it's not ugly enough. Look at it this way: hijacking a random IPv6 prefix is a lot safer (WRT collision risk) than using RFC1918. So yes, the network administrator would rather use Hinden/Haberman as private addresses instead of hijacking, but this is overruled by the PI need. In short: the Hinden/Haberman draft does not solve the private address need because what it creates is globally routable PI, whether we like it or not. > There's a 100% probability it will be used for inter-enterprise > routing (i.e. exceptions such as VPNs to normal routing). Routing it over the Internet (without a VPN) for inter-entrerprise communication would also be perfectly legitimate, host-to-host IPSEC for example. Then the line between it and global PI ceases to exist. > There's probably a 100% probability that some enterprises will > pay ISPs to announce /48s into the DFZ (as mentioned above). > But I don't think that is a characteristic of the > Hinden/Haberman draft. It will happen whatever we define. The > trick is to make it an exception rather than the rule. What do we have WRT this except a MUST or MUST NOT in a draft? >> As so, it can't be used for private addresses. I'm not the >> only one that says this. > No, you're not, but it doesn't follow. It can be used for > private addresses by default. But there is no enforcement > mechanism. If you prefer; that's because we took out the two known enforcements mechanisms: ambiguity and scope. We all agree that ambiguity is bad and I would not have too many problems letting scope go if we had a replacement enforcement mechanism, but the bottom line is that we don't have one. >>> and why random hijacking is less risky than a >>> pseudo-random generator? >> It's not; it has everything to do with the purpose of the prefix, >> not with the way the address was picked. The risk of collision >> for an address that does not get out of the site is a lot less >> (specifically, a merge) than for an address that reaches the >> outside. > That's certainly true, but I think the risk is negligible anyway. Let's say it's acceptable, I agree. >>> Brian E Carpenter wrote: >>> I kept reading, because if these things are created they *will* >>> certainly end up being used as end point identifiers. >> Michel Py wrote: >> Can you develop why? In the absolute I can find lots of reasons >> but I don't see why the identifier/locator solution would prefer >> using these vs. having its own prefix. > If I have an IP address for my machine that is > FC00::1:1: > why wouldn't I use that as a transport address in a multihomed > session? I can't see a downside. There are two, a big one and a small one. The big one: that space is not aggregatable. Save for id/loc solutions that use DNS as the locator-to-identifier mapping mechanism, there is a long-term scalability need for aggregation, the id/loc mechanism being the extra redirection layer that makes it possible to ha
RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]
Brian, > Brian E Carpenter wrote: > Quite correct. What I'm pushing back on is the idea that three > levels of scope (link, local, global) capture much of anything > useful. If we were talking about scope between say 0 and 255, > where 0 means link, 255 means global, and 1..254 are user > defined, we might be able to define something of value to > enterprise network operators. Sounds good, but do you think that moving the scope definition to the user will bring any breakthrough in getting this new scoped architecture doc out of the door though? I have not thought much about it but the initial reaction is that it would make things even worse. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
> Aidan Williams wrote > The current drafts look like progress to me and > remove the biggest wart of SL: ambiguity. It's a distraction. The reason SLs are still ambiguous is because of the deprecation process, not because ambiguity could not be removed. As a matter of fact, this document is a direct descendant of drafts to remove ambiguity in SLs. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: local vs. nonlocal address stability ( was Re: apps people? )
> Jim Bound wrote: > Putting on deployment hat and all this discussion from > the most knowledgeable people on this issue here SLs must > die and new pheonix is required. Easier said than done. > But to tell a customer to use these is not honorable at > this point. My input now as individual person when asked > is DO NOT USE SLs at ALL. Then don't whine about the market being in limbo because by your own admission it is in limbo precisely because of the deprecation. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Geoff Huston's draft and the intended use of the hinden/templin address space
Eliot, > Eliot Lear wrote: > Subject: Geoff Huston's draft and the intended use of > the hinden/templin address space > If the sole purpose of these addresses is for layer 3 > connectivity as envisioned for LOCAL USE, then I would > agree with Nir Arad that we do not have a problem. Same here, however I do not think we can talk in terms of purpose. The peril of these addresses is precisely that they will be used to ways contrary to their purpose, which needs to be taken into account. > If on the other hand, as Geoff states in his draft, and some > people seem to be implying, that these addresses could be used > as some sort of end point identifier outside of the routing > system, then we do have a problem. Note that as author of a two-space locator/identifier protocol I do not share this point of view. There is a need for a private address prefix that is completely separate from the prefix used for end-point identifiers. Among other things, I fear that using private addresses as end-point identifiers for global traffic will lead directly to NAT. Conceptually, the endpoint identifier is like a PI address, which it targets to replace. The only reason for the separation between endpoint identifiers and locators is that it enables a reduction in routing table size, _not_ because it wants to blend the identifier with the private address. These are separate animals. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Geoff Huston's draft and the intended use of the hinden/templin address space
> Nir Arad wrote: > Excellent scenario, and a simple solution: > The administrator needs to define 2 address scopes. > The control device has an address in scope 1. > The host has addresses in both scopes 1 and 2, as well as a global > unicast address. The DFZ host has an address of scope 2, and a > global unicast address. > All requirements met. Then unless each host has two NICs (which is not acceptable as it doubles the size of the local network) the host interface is in two scopes simultaneously which means the entire VLAN spans two scopes which makes your proposal that scopes don't communicate together void. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Eliot, > Eliot Lear wrote: > I guess my concern is that ISPs end up routing the address > space in Bob's proposal and that we'll have another PI problem. > So while there's nothing wrong with Bob's proposal in theory > (indeed I prefer it vastly to the other SL approaches), if > customers believe they have stable addresses we could end up > right back where we were in the early '90s. I don't see this > happening for DSL customers but it could happenfor medium to > large size businesses who have the power of the purse. I raised this very issue a long time ago, but that is not the worst problem we have. Finish the reasoning down that same path: - Sites will get unaggregatable portable /48s. - Their wallet will get them routed. - Everyone is happy, no renumbering issues, multihoming is possible. So, everyone will spend 5 bucks registering their /48, some (the ones that currently have an AS or will request one) will actually announce it, and we're all fat and happy. Until the GRT reaches 10k (and probably until it reaches 50k by the time that happens given better hardware) it won't be a concern. What happens next is more interesting. Re-using some wording I have read yesterday, this will become a self-regulating system, meaning that only those who can afford it will be able to announce their /48 after some time. The question is: in 5 or 10 years, what are these people that are running production networks configured with addresses that they own going to do when they can't announce their prefix anymore? Bingo, welcome to NATv6. Replacing site-locals with NATv6. Think about it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: 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. >> Michel Py wrote. >> I'm ok with that. Not only never leave the site but >> making >sure that they can't. > Even better yes. They "can't". You can't guarantee that for the Hinden/Haberman draft, which is the reason I will not use it until we have a solution on a PI-like setup. It's a matter of risk: If I use the Hinden/Haberman draft as private addresses, and if it ends up being perverted as PI, my entire network design goes to the trash. If I hijack a random prefix for private addresses, the risk of collisions although not null is a lot less. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
Tony, > Tony Hain wrote: > Insisting on a single address per interface is the only > way to avoid address selection. There are ample comments that a lot of enterprise managers will be favorable to that concept. > This whole discussion is about multihoming It has always been the sticking point. > which points out the failure of the approach to move the > multihoming discussion into a separate WG. Multi6 should > be closed NOW. As a matter of fact, by reading its charter it should have been rechartered or shutdown in September 2001, almost two years ago. But I hear that being two years behind objectives without any result is not a big deal in the IETF. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
> Mark Smith wrote: > The security paranoid, at least in an government environment, > would *like* to perform route filtering as part of a defense > in depth strategy in addition to filtering, but end-user > access requirements usually put an end to that idea. All government networks that I have worked on use route filtering: they have static routes on some parts and especially at the edge. That's the ultimate form of route filtering. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multi-homing (was RE: Moving backward [Re: Fourth alternative [was Re: Moving forward ....]])
> Alain Durand wrote: > So what we have here is a case where you are multihomed > with one side that is permanently unreachable from a large > portion of the universe. This is a feature, not a bug. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
Eliot, > Eliot Lear wrote: > If you look at most of the home "routers", they have more > of a notion of "inside" and "outside" interfaces. > Even the HOME router doesn't build an assumption along > the lines you are discussing. It doesn't look at the > bits in the address field, other than to NAT permitted > stuff through. I regret to say that you are wrong here as what you say is mostly the way things appear to be but not the way they really work. In at least one example that I have seen recently myself, the router does indeed look at the address only. A DSL/NAT box, whatever/29 on the DSL interface, 192.168.1.1/24 on the Ethernet interface, NAT enabled, no RFC1483 bridging. I found a host plugged a host with a public IP from the /29 on the Ethernet interface, works fine. I agree it's crappy code, but it does happen. A Cisco example? here's one: route-map ROUTE-MAP-CYMRUBOGONS permit 10 description Filter the bogons from the Cymru.com route-server match community STD-COMM-LIST-CYMRU set ip next-hop 10.x.y.z ! ip route 10.x.y.z 255.255.255.255 Null0 name BLACKHOLE Question: why can't I just do: route-map ROUTE-MAP-CYMRUBOGONS permit 10 description Filter the bogons from the Cymru.com route-server match community STD-COMM-LIST-CYMRU set interface null0 Educated guess: because for a gazillion of reasons including existing code and the way hardware can assist in processing the traffic, it works by IP address and not by a more abstract concept like an interface. And frankly, as a CCIE I prefer having to deal with the way it is today because at least I understand what the router does, rather than a "magic" script that would in my back transform the "set interface null0" into "set ip next-hop 10.x.y.z" + "ip route 10.x.y.z 255.255.255.255 Null0 name BLACKHOLE" without telling me. > Now let's look at the enterprise case. Unless you claim > you are going to do away with the OTHER access-lists, > then this is just another bit pattern for an ACL and > there is no architectural need, and there is some peril > as Michel has described. I'm not quite sure how to parse this. The peril is because there is no architectural limitation (these addresses have public scope; if they had restricted scope the peril would be less). > We do need to handle the disconnected and intermittently > connected network carefully and in a reasonable way. Here > I don't think we have good answers -- YET. I do not wish > to sweep this one under the rug. Agree here. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: site-local observations from the outside
Brian, >> Michel Py wrote: >> It's a matter of risk: If I use the >> Hinden/Haberman draft as private addresses, and if it ends up >> being perverted as PI, my entire network design goes to the >> trash. If I hijack a random prefix for private addresses, the >> risk of collisions although not null is a lot less. > Brian E Carpenter wrote: > I am puzzled by your last two sentences. Can you be more > precise about why your design would be trashed Because then the addresses used on the private network would be routable PI, which is exactly what network designers don't want when they design a private network with private addresses. >From another post: > If by PI you mean *globally routeable* PI, I am not holding > my breath, and I believe it would be a serious mistake to > delay any decisions while waiting for PI. > If you mean non-globally-routeable PI, Hinden/Haberman is a > fine solution. What you refuse to acknowledge is that there is a high probability that the Hinden/Haberman draft will be misused as globally routable PI. As so, it can't be used for private addresses. I'm not the only one that says this. Network administrators don't buy that addresses in the Hinden/Haberman draft will remain non-routable because they will be the first jumping in the train to make them routable in the first place. > and why random hijacking is less risky than a > pseudo-random generator? It's not; it has everything to do with the purpose of the prefix, not with the way the address was picked. The risk of collision for an address that does not get out of the site is a lot less (specifically, a merge) than for an address that reaches the outside. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]
Brian, > Brian E Carpenter > My bottom line on this, I think, is that this version > of scope has very limited use - it doesn't deal with the > situations that my services colleagues see every day, > and it is not something that middleware can make any use > of. At most, it allows for some defaults in firewall > rules and address selection rules, but those can be set > up on well-known prefixes just as easily as on a scope > value. Although could agree with some of this, you are missing the point. This would be if we had a PI solution, which we don't. In the lack of it, the benefits of perverting the Hinden/Haberman draft into PI and do whatever works for private addresses (such as hijacking) are _greatly_ superior to using the Hinden/Haberman draft for private addresses and have no PI and no multihoming solution. No matter how infortunate, it is scope that could lesser the risk of this happening, which is why making SLs unambiguous was possible, and also what makes the Hinden/Haberman draft such a peril as the only significant difference is that now these addresses have a global scope. _IF_ we had a deployed solution that would bring the advantages of PI, _then_ the Hinden/Haberman draft would be a no-brainer. I am not opposed to abolishing scope, but we need to solve the PI issue first. If it never crossed your mind, abolishing scope and slightly revamping SLs would make their deprecation un-necessary as all the problems associated with them would be gone. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: draft-hain-templin-ipv6-limitedrange-00.txt
Brian, > Brian E Carpenter wrote: > And the fact is that enterprise network managers are > very happy to have a class of addresses that cannot be > globally routed and are filtered by default as bogons > by all ISPs. You forget that the very reason RFC1918 addresses are filtered as bogons is precisely because they are ambiguous. > So they just love RFC 1918 addresses for that, and > hate them for their ambiguity (since that creates a > mess when they have to be routed anyway, e.g. on VPNs). > The main point of this draft, as far as I'm concerned, > is to convey this requirement, which isn't met either > by PA prefixes or the old SL prefix. The requirement was met fine by the SL prefix; the only reason they still are ambiguous is because both Bob and I put our drafts to remove ambiguity from SLs on the back burner due to the deprecation situation. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]
Brian, > Brian E Carpenter wrote: > I think we'd be better off to simply forget > about address scope. At last, the real question. Well, this could be both the best thing we could do for IPv6 and the worst thing we could do for IPv6. It would be the best thing we could do for IPv6 because for numerous reasons it would simplify it and could allow for a faster deployment. It would be the worst thing we could do for IPv6 because that would be a tacit admission that we have failed to deliver on the promises for IPv6, and are settling for IPv6 being IPv4 with more bits. This could mean the death of IPv6 as enhancements in NATs are way cheaper than building a native v6 internet, and as long as the v4 internet is not on the verge of collapse (which is going to take some years at best) IPv6 would not take off. There are three things that could make IPv6 take off: 1) A killer app, which we still have to see. 2) The v4 address space _really_ getting full, which will eventually happen but we simply don't know when (as the time frame keeps being pushed) and certainly not tomorrow morning. 3) IPv6 being a lot more powerful than IPv4. > Well, here's my attempt at becoming flame bait :-) This was a sound question to ask. However, what you propose is giving up on item 3) above, and since there is nothing we can to rush the invention of a hypothetical killer app it actually jeopardizes the deployment of IPv6. When time for 2) is around the corner, IPv6 will be deployed no matter what, quick and dirty. Instead of settling for what we can deliver today, why don't we use the remaining time to try to make it better? Might not produce anything else, but at least we would have tried until the last minute. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Jim, > Jim Bound wrote: > But what we cannot do is discuss it for the > next year leaving the market in limbo? The reason the market is in limbo in the first place is deprecation without a replacement. If the market did not need SLs it would not have gone in limbo over the issue. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Geoff Huston's draft and the intended use of the hinden/templin address space
>>> Nir Arad wrote: >>> I would like to point out again, that as per my suggestion, nodes >>> MUST NOT send, receive or forward traffic in which the source and >>> destination addresses are not of the same scope. >> Michel Py wrote: >> That would some problems but appears to be unworkable to me. It's >> not flexible enough. > Could you please give a scenario that breaks it? < Global Addresses ><- Local addr -> +-+ | ISP |: +--+--+: ! : +--+-+ +--+ +--+ +--+ | Router A : +--|< Firewall+--+--|< Firewall+--+--+ Router B ++ ++ +--+ | +--+ | +--+| : || | : +---+--+ +--+---+ +++ : | DFZ | | Host | | Control | : | Host | +--+ | Device | : +--+ +-+ ---Site -->:<-- Site --> : - Router A is the SBR. - DFZ hosts need to be able to talk to hosts between the internal firewall and router B, but not to the control devices. - DFZ hosts need to be able to talk to the outside. - Hosts between the internal firewall and router B need to be able to talk to everybody. - Control devices are accessible only from hosts between the internal firewall and router B. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Jim, >>> Jim Bound wrote: >>> But what we cannot do is discuss it for the >>> next year leaving the market in limbo? >> The reason the market is in limbo in the first place >> is deprecation without a replacement. If the market did >> not need SLs it would not have gone in limbo over the >> issue. > Agreed. But we had a bug and a big one. You are awfully cavalier with taking such risks with the market. What if the market does not like the replacement? The market will stay in limbo. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
> [EMAIL PROTECTED] wrote: > Please describe for me what consumer networks (a home connection > to an ADSL provider for example) that have dynamic routing with > their service providers? Mine, for example. I have a residential SBC aDSL line, single static IP, 256kbit up / 1mbit down for $49/mo which is mainstream in California. I have two IPv4 eBGP peers, three IPv6 eBGP peers (not the same ones as v4), six EIGRP neighbors across IPSEC tunnels and I also do VOIP across tunnels, p2p file sharing (for educational purposes only, you understand) and some other stuff. For customers I have installed lots of Cisco 800 series for ISDN, IDSL and ADSL, some of which with built-in voice such as the 827-4V for aDSL or the uBR924/925 for cable and they all have dynamic routing and route-maps, and these are at people's homes, but part of their business network. Just because you've never seen any does not mean it does not exist. > Ok, so you mean that people like Sprint and Telia doesn't use > route-filtering on their BGP peers in order to allow only paying > customers transit? And that they doesn't use route-filtering on > their incoming BGP peers from multihoming customers to ensure > that those customers do not announce the Internet back to them? Yes they do and so do I, what is your point? Your view appears to be limited to a very small fraction of the Internet and appears to stop at the border router of the enterprise. Beyond these border routers, there are hundreds and sometimes thousands of routers in the private network. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
Tim, > Tim Chown wrote: > I like the method Alcatel use on my combined 802.11/DSL > home router. If I want to add a new wireless device for > home access, rather than having anything able to > associate, or a manual/web configuration of MAC address, > I only need press an "allow association" button that > will for 20-30 seconds let any device attach, from which > point that MAC address is remembered. Of course not > ideal security, but a nice solution for the home user. A little reckless IMHO, if your neighbor's wireless is up there is a strong risk of allowing association. > Similar approaches could be adopted for the types > of scenarios here. Indeed. My point was that Joe Six-Pack can eventually push a button, but not remove a default route. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
> Mans Nilsson wrote: > I fail to see why you need scoped addresses for this. > When I want my printer to stay off the net, I remove > the default route. Done. This does not work because Joe Six-Pack does not know how to remove the default route, so the printer will indeed acquire a default gateway by DHCP or RA. Not good enough. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Let's abolish scope [Re: Unicast scope field (was: Moving forward on Site-Local and Local Addressing)]
Brian, > Brian E Carpenter wrote: > I don't recall that we ever promised to support scoping > of unicast addresses. Not explicitely, but the idea about IPv6 has been since the beginning that it would better than IPv4 with more bits (which we could have delivered years ago). One of these things that could make it better is scoping for unicast addresses. Specifically, I do not see how we could remove ambiguity of private addresses at this time without something like scoping. > RFC 1752 refers to the scope field in multicast addresses, > which I certainly don't propose to abolish. Separate issue; I was not thinking about multicast at all. > I don't see why the lack of explicit scope for IPv6 > unicast is an inhibitor. See above. As I said earlier, it has good sides and bad sides. From the enterprise network manager point of view, I do think that many actually care a lot about what kind of simplification scoping can bring in terms of access-control and security. Specifically, although the routers will continue to think in terms of IPO addresses, scoping could bring some automation in building default access-lists that would be nice to have. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: apps people?
Eliot, > Eliot Lear wrote: > I was referring to the smaller devices a'la Linksys, > DNET, etc. The first part of my post also did. When you scratch the surface it works on an IP address basis, the rest is GUI paint to make it easy on Joe. > With ciscos you pretty much run sed on the header > if you want to In the example I pasted it was not my choice; there was no other way. > - not that I think it's a good idea. Well, if there is a good reason for it which I am confident there is, it's ok. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Michael, For a change I mostly agree (will detail below what I don't like) with what you just posted, especially: > Michael Thomas wrote: > so even these small sensible steps that you propose > nonetheless seem grave in their global implications. and > 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. The same is true if we create a swamp again and allow individual /48s in the global routing table. Then IPv6 will become IPv4 with more bits, and in the current economy the net result will be more NAT-aware apps. I'm sorry to say it bluntly, but today IPv4 is unavoidable and if the only edge IPv6 has is a bigger address space I'm afraid it won't be enough to cut it. I welcome some debunking on the following assertions: 1. Even if we say that NATv6 is evil, there is little we can do to prevent it from happening except providing a solution that would bring somehow similar advantages. 2. Even if we say that individual /48s in the global routing table are evil, there is little we can do to prevent it from happening except providing a solution that would bring somehow similar advantages. However, 3. If we say that NAT is acceptable, half-acceptable, maybe OK in the short term (or whatever) it WILL happen and there will be no way back. 4. If we say that individual /48s in the global routing table are acceptable, half-acceptable, maybe OK in the short term (or whatever) they WILL happen and there will be no way back. In other words, it IPv6 becomes IPv4 with the same NAT crap and the same BGP stability issues due to an oversized routing table, it ain't part of my network designs. Back to what I disagree with, you seem to blend the PI issue and the SL issue into the same problem. They are unrelated. Michel IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
Eliot / Bob, >> Bob Hinden wrote: >> Is this sufficient? Would it better to also include an >> "operational considerations" or similar section? More text >> on why this is important? > Eliot Lear wrote: > Venders speak the language of money, So do operators and so do enterprises. Allow me to share the way it works for enterprises: - I am already paying $2.5k/yr to ARIN for portable IPv4 address space. - Although I could do without, I am ready to pay another $2.5k/yr for portable IPv6 address space (when IPv6 takes off, that is). - If globally unique IPv6 address space is free, I am willing to give these $2.5k/yr to my ISP to announce my /48. - On top of that, if doing so also solves the IPv6 multihoming issue, where do I sign? On the operator side, I do acknowledge that we have some of them around that do what they are supposed to and filter, thanks to people that promote routing table health such as Jeroen and Gert. That being said, the hard facts are that a) as of today 42% of my IPv6 BGP routing table is made of /48s, /64s and other crud and b) lots of ISP will think twice before refusing my $2.5k/yr to announce my prefix. > and that overrides whatever language is in the draft :-( Which is doubly lame, because 1) I should not offer the money and 2) they should not accept it; bottom line though is that both them and I run a business, not a charity. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Jeroen, > Jeroen Massar wrote: > At this moment you can announce almost anything > you want apparently. Yep I see /32 /33 /35 /40 /41 /42 /44 /48 /64 from some peers, Including some interesting ones such as: 2001:530:DEAD:BEAD::/64 This is the very reason we have to be very careful with any kind of globally unique address that has a global scope, because it can really quickly degenerate into having clueless ISPs that don't care to clueful salespersons that see an opportunity. As a few thousand prefixes would not be a problem at the beginning, it might take of really quick leaving a big mess to clean up some years later. > Fortunatly there are clued ISP's who do > filter accordingly to: > http://www.space.net/~gert/RIPE/ipv6-filters.html NRENS do filter too for what I have seen. > As you are probably one of the many people who really > knows that we need is: Multihoming ;) How did you guess that? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
> Todd T. Fries wrote: > What requirement of site-local does provider > independent addressing not provide? We do not have PI addresses for IPv6, to begin with. And the reason we don't is that as soon as you begin to think about them I can already hear screams about having to carry an individual /48 in the routing table for each home. Yes, we need a PI-like solution but is has nothing to do with site-local addresses; they are complementary not competing. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Jordi, > Jordi wrote: > I see your point, but my feeling is that we can only go to > the last step (of the IETF process) IF it make sense (running > code, and then it means no-brainer), that means that B is > fine, but for the same reason, I can live with C (in theory, > B and C are then the same solution) ;-). I see your point too; however, The difference between B and C is: - with B, if the solution proves impossible to develop, we have a failure. - with C, if the solution proves possible to develop, we have wasted time. As many things, it's a matter of risk management, speed with a risk or slowness without one. The reason I like C better is because I have the feeling that if there was a no-brainer solution that would make B worth the risk someone would have invented it a long time ago. If we were not able to fix site-locals I wonder where the silver bullet to replace them is. As Tony pointed out, design engineers for large networks do not design on vaporware. If I can't simulate a solution on a 20-router lab, it ain't going in my network design and I stick with site-locals. Which also means that once the design goes to large-scale deployment there is no way back for at least 5 years, which in turn means that router vendor "C" (yes, the one you are thinking about) is going to keep supporting site-locals because they want to keep my business. The question is, do we want to define standards or to we want to encourage the development of proprietary standards? For the record, I use ISL, EIGRP and HSRP; I won't have a problem using vendor "C" site-locals. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
> Dan Lanciani wrote: > It occurs to me that if we are going to start actually > counting again (picking the option with the most votes) > the options offered will tend to skew the result towards > A by splitting the site-local support between B & C. > Therefore I wish to cast my vote against A more than > for C... Alike other opinion polls, the way the question is asked can make a big difference indeed. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Bob, > Bob Hinden wrote: > Please respond to the list with your preference I would prefer C. "Rough consensus and running code". Possibly I could live with B, but it greatly depends on how difficult the new solution is to implement. If everyone agrees that implementing the new solution is a no-brainer, then B would be fine. However, if the new solution requires significant coding that many people don't feel too good about it, C is required. We don't want to deprecate for a solution that looked good on paper but proved impossible to implement and be left with zip. I have trouble understanding why the issues that applied to site-locals would not apply as well to the new solution until I have seen the new solution. IMHO the choice between B and C is premature until we have a clearer view of the alternatives. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: site-local observations from the outside
Todd, > Todd T. Fries wrote: > Either you have link-local addresses, or you have > global routable addresses. >From a transit provider point of view this is true, but not for the enterprise. There are lots of large networks that require private addresses and use RFC1918 today. Examples that have been discussed before are a large cruise ship and utility companies. Part of the requirements is that private addresses must not be routed on the public Internet. > Any attempt at providing something that is site local suggests > to me that you open the doors wide for something like NAT, > which of course none of us wants. There is some truth to this, but in the end avoiding NAT will not be achieved by not providing site-local addresses, as they are not required per say; people that need them will simply hijack an unused block in the middle of nowhere in the IPv6 address space, like they did for IPv4 pre RFC1597/RFC1918. A good hijack candidate is 2002:RFC:1918, for example. The only way to avoid NAT is to provide what NAT does, which is portable, globally unique, globally routable addresses, which we don't have today. > There is enough address space in the global table, Wrong. There is enough address space today, but the global routing table cannot handle billions of entries, at least not with BGP4+. It's not a matter of memory, it's a matter of stability. > why can we not have some sort of free reservation system > (the free tunnel brokers would suggest it is economically > feasible) for sites that want local addresses but do not > intend on globally routing them. jj has proposed something like this not too long ago. A draft soon? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: AD response to Site-Local Appeal
Brian, > Brian E Carpenter wrote: > Personally, I'd advise customers who believe they need local > addresses to continue using FEC0 until the addressing > architecture is revised and products catch up. Oops I goofed. s/incertitude/uncertainty Customers don't like uncertainty when designing networks and will delay IPv6 deployment until this is settled. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: AD response to Site-Local Appeal
Brian, > Brian E Carpenter wrote: > Personally, I'd advise customers who believe they need local > addresses to continue using FEC0 until the addressing > architecture is revised and products catch up. Customers don't like incertitude when designing networks and will delay IPv6 deployment until this is settled. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: AD response to Site-Local Appeal
Steve, > Steven M. Bellovin wrote: > Tony -- to make life easier for all concerned, please state > explicitly what recourse you're asking for from the IESG. > As things stand now, even if we agreed with everything you say, > we wouldn't know exactly what you want us to do. IMHO the ultimate goal is to handle the deprecation situation by having the IESG make a decision that will lead the ipv6 WG into taking the appropriate path towards it. IMHO, this path is: 1. The WG will publish a document describing the requirements to replace site-local addresses. 2. The WG will publish one and possibly/preferably more than one document(s) describing solutions to replace site-locals that meet the requirements (it could be a good idea to merge close-enough drafts at some point). 3. The WG will publish a deprecation proposal document. This document will mostly propose to deprecate existing site-locals and develop one of solutions issued from 2. THEN, having provided enough time to review the deprecation proposal and the merits of the proposed replacement(s) the WG will be able to make an educated decision whether or not deprecating site-locals in appropriate (one criteria being that the proposed replacement has less problems than the current site-locals), and if yes which one(s) of the proposed replacement(s) is to be developed. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: AD response to Site-Local Appeal
[SNAP] I totally agree with the beginning of Tony's post. > Tony Hain wrote: > Until the WG agrees on the requirements, there is no > possibility for the group to evaluate the utility of > the current SL or other approaches. I would go further than this and say that requirements alone are not enough to evaluate what to do WRT this issue, as requirements could be impossible to meet (as seen with multi6, for example). Requirements are good but must be complemented by looking at _solutions_ as well and as of today we don't have any solution to replace site-locals. An imperfect solution is better than no solution and until we find a better mouse trap it is harmful to deprecate the running code deployed by multiple vendors that we currently have. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: state-of-art SLs
> Bhaskar S wrote: > The document mentioned below, has it been published? > If yes please could you send me the link? Ditto. 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: Same global address on Multiple Interface of an IP6 node
Todd, > Todd T. Fries wrote: > I understand there are tricks for faster thoroughput on > IPv4 with regards to multiple interfaces (network cards) > and a single IP address. Say, two 100mbit cards plugged > into the same 100mbit switch. Is this `trick' available > with IPv6 in any fashion? There would be interesting issues with having two interfaces with the same IPv6 address on a switch related to the switch's CAM table, I doubt it could work without channelizing at a lower layer. For what I have done, these tricks are not specific to IPv4 but lower in the stack by combining several physical interfaces into a single logical bundle at the data link layer; the IPv6 address is applied to the newly created logical interface. I mostly use Fast or Gigabit Etherchannel. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Taking two steps back (Was: Re: one question...)
> Keith Moore wrote: > Even then, there will still be cases where the right thing to do > is to talk directly to a locator. And there will also be lots > of apps for which a locator is "good enough" that probably > shoudn't be made dependent on the mapping service. Agree. > So I lean towards a view where you can use identifiers or > locators interchangeably Also agree. > Which further implies that identifiers and locators look a lot > like IP addresses. Yeah. Or actually _are_ IPv6 addresses. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Multihoming on IPv6 ?
> I would like to know about the minimum prefix of IPv6 that > can be announced by Customer-Site when they are Multihomed > with another ISP's ? There is currently no multihoming for IPv6. Customer-site prefixes are not to be seen in the global IPv6 routing table. > Is there any RFC's regarding on this one ? RFC2772; although it was written for the 6bone it is also used by many people on the production IPv6 network especially NRENs that have the closest thing to a native IPv6 backbone today. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
Bill, > Bill Manning wrote: > that still does not let the IETF determine when/if any > organization has a production ipv6 service. the IETF can > define specs and recommend practice and thats as far as > it goes, IMHO. Agree. But back to your original text: > perhaps my issue is that your original note > used the term "production", while now you use the > term "operational". they are different words w/ > distinct meanings. Without getting in the definition of what is a production network, what I meant is this: IMHO, it is reasonable to assume that the majority (literally: more than 50%) of IPv6 operators are considered reasonably competent to the extent that they operate their networks in a fashion compatible with having customers and provide them that commodity called "IPv6 service", regardless of what the precise definition of what "IPv6 service" really means at a certain point in time. In other words: If IPv6 is operational, and if we assume that most operators operate their networks within reasonable limits of what should be done, this leads to IPv6 being in production. I apologize for using two different words, but for all practical purposes what is the difference? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
> Bill Manning wrote: > ah.. perhaps my issue is that your original note > used the term "production", while now you use the > term "operational". they are different words w/ > distinct meanings. Would you mind sharing these meanings? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
Bill, > Bill Manning wrote: > what an odd point of view. if, as is asserted, the > IPv6 is "production" then why are we still seeing > drafts changing the address format? You are making my point. I am not the one that states that v6 is operational, BTW. http://ops.ietf.org/lists/v6ops/v6ops.2002/msg0.html Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
> Fred Templin wrote: > Loses to the proposal that best satisfies the requirements. No more comments. The appeals will proceed as documented. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
Eliot, >> Michel Py wrote: >> We don't throw away a published standard with running code >> from multiple vendors in exchange for the promise that >> _maybe_ someone will be able to produce a replacement that >> meets the requirements. > Eliot Lear wrote: > It is true that we should not make standards where there is no > running code. However, Running code != good practices or even > good ideas. And we do have running code (with both good and > bad ideas) for now while we figure out this question- it's > called IPv4. I will remind you that the official IETF position is that IPv6 is in production, which led to the creation of the v6ops WG. IPv6 is no longer a prototype we can tinker with. Or maybe you recommend a gracious restart? Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
> bring RFC 3513 site-locals as a candidate scheme if you'd like, > but it loses based on ambiguity and non-portability (to name > just two) straight out of the barrel. Loses to what? Since when requirements equates a solution? Requirements are wishful thinking, no more. We don't throw away a published standard with running code from multiple vendors in exchange for the promise that _maybe_ someone will be able to produce a replacement that meets the requirements. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
> Fred Templin wrote: > True, this is a -00 document, And an attempt to legitimize the deprecation by trying to put the horse back in front of the car, the problem is that you still don't have a horse. This document is further proof that there is nothing to replace site-locals, which is the reason there is no ground to deprecate them in the first place. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Requirements for Limited-Scope Unicast Addressing in IPv6
> Fred Templin wrote: > A limited-scope addressing scheme is needed to replace the > now-deprecated site-local scheme from [RFC3513] The site-local scheme is not deprecated until there is a published document that states otherwise which will not happen until all the outstanding appeals have been resolved. Therefore the site-local scheme from RFC3513 which is in the standards track is still valid. Should you push this text to be published I can assure you that it will be appealed as well all the way to the IAB. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Document Action: IPv6 Global Unicast Address Format to Informational
Thomas, > The global routing prefix is designed to be hierarchically > structured by the RIRs and ISPs, and the subnet field is > designed to be hierarchically structured by site administrators. > Is this OK with everyone? I'm OK with it, but I'll make a quick comment: One (it not the) reason why the routing prefix appears as one field in the diagram is because we removed the TLA and NLA boundaries in it. A twisted mind could read the additional text quoted above as an attempt to return to a more rigidly structured routing prefix. That being said, ship it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt
Brian, > If you are correct, exactly the same will happen with > PA space. [I assume that you are referring to jj's proposal] In the "putting the RIRs out of business" dept, no (because LIRs would still pay to obtain PA space). In the "explosion of the routing table" dept, the risk is a lot lesser for three reasons: - No matter what the "guarantees" that a LIR would give about the allocating permanently a block to a site, it still remains PA which means that the incentive to get it routed globally is not nearly as strong. - NRENs and some other organizations will likely continue filtering long PA prefixes. - In case a LIR provides addresses and not transit, they will likely blackhole the block they allocated to that purpose (because of economic reasons, not because the IETF says so), making routing longer prefixes within that block moot. In other words: - There is a strong and unfulfilled demand for globally routable PI. - Neither Bob or jj's proposals are aimed at providing it. However, - jj's proposal does not make it as globally routable PI. Simply does not work. Yes it could eventually be perverted into that, but as the "consumer" I am not buying it as a good enough PI solution. - There is nothing that stands between Bob's proposal and the PI swamp except an IETF edict that says "don't do it because it's the wrong thing to do" which does not stand against any money argument. As we have seen with the Elz appeal recently, it is none of the IETF's business to prevent users to misconfigure networks nor to force vendors to release products that can't be misconfigured. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt
Bob, You could as well call this draft the IPv6 swamp creation act. If these addresses can be routed on point-to-point links or VPNs between sites, they can be routed on the public Internet and since everyone wants portable PI they will. >From the site's point of view, this is an easy decision: if the site wants portable address space, first they will get this for $10 one-time, then instead of paying the RIR $2.5k/year for the space, the site will simply allocate this money paying $2.5k/year to their ISP to leak their /48 in the GRT and $2.5k/year is enough for ISPs to leak it. Not only this creates the IPv6 swamp but it also puts the RIRs out of business. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: null-routed aggregated global unicast (was: another viewoffc00::/7)
Benny, > Benny Amorsen wrote: > It seems to me that having a global blackholed /10 is a lot > nicer to the routing table than a lot of blackholed /36's. No argument about this, but the catch is that this /10 being blackholed relies on the cooperation of lots of people, and this won't hold against pressures to break aggregation. We can't assume than everyone is going to play ball just because we say it. > Perhaps routers have advanced to the state where this is no > longer a significant concern. Have a look at this: http://arneill-py.sacramento.ca.us/ipv6mh/j.ppt http://arneill-py.sacramento.ca.us/ipv6mh/j.pdf (I isolated that one slide part of a much larger presentation) http://arneill-py.sacramento.ca.us/ipv6mh/IPv6%20Transition.ppt Vendor "J" says they can't guarantee that throwing more memory and CPU in the routers is going to be enough. When I design a large network, I like guarantees and not "perhaps". Michel IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: null-routed aggregated global unicast (was: another view of fc00::/7)
> jj wrote: > Several people such as yourself (e.g. Michele Py) have > suggested that "local" addresses will be advertised no > matter what. _IF_ they have a global scope or are handled as global. > My solution simply takes the lemons and makes lemonade. That's why I like it. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: null-routed aggregated global unicast (was: another view offc00::/7)
Benny, >> jj wrote: >> Outsiders can't even tell it's not a normal prefix (which is >> a blessing and a curse), let alone state that they also >> purchased the prefix from some other ISP. > Benny Amorsen wrote: > I think that is a curse. It means that in normal circumstances > I can expect to see what was supposed to be my unique addresses > advertised by routing protocols as part of a larger aggregated > space. A curse it is but a blessing it is also. Look from the other prospective: I'm the ISP that provides you the block: - I give you a /48 out of my /32. The /32 costs me 2.5k/yr so the /48 costs me $0.04/yr plus overhead. BFD. - When we get out of this "everyone-gives-free-transit-to-everyone" business model which does not make sense, I don't want to pay for your traffic because what I sold you or gave you is the address, not the bandwidth. So I reserved a /36 out of my /32 for people like you and I route it directly to null0. - Why is this a blessing? Because there will be enough people that filter longer prefixes. What we are talking here is private addresses. So if you peer with a business partner and they get a specific route to the /48 I gave you, fine. Otherwise, it does not matter if the traffic goes into an unreachable or if it goes into my null0, and there are a fair amount of people that says it's preferable to route traffic that you want to go nowhere into a blackhole instead of bouncing it. > I would just prefer that /my/ non-routable addresses stayed > out of the global routing tables. Look back from your own prospective again: What you want is your /48 not to be there; if a /32 that encompasses your /48 is announced and if the /36 that encompasses your /48 is routed to null0 at the destination, it's a blessing. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Status of
kre, | Alain Durand wrote: | Reachability os one thing, but you may have to wait for TCP timeouts. | RFC1122, section 4.2.3.5 TCP Connection Failures | Says that the initial SYN has to wait at least 3 minutes... > kre wrote: > You're assuming that I am actually using a TCP SYN to > detect reachability. That isn't the way it is done. We want > to make things work well, not arbitrarily slow them down. The problem is that the only way to _really_ test reachability is to actually try. For example, if you can successfully ping a host it does not mean that you can telnet to it (or the opposite: ICMP might be blocked and it might be the best path). Or if you can open an http connection on port 80 it does not mean that you can open an https one on port 443 (because someone forgot to open the port) or the opposite (because the network administrator wants to enforce an https-only web server). Note that I am not suggesting that the reachability discovery should be application specific, but OTOH I don't really see how it can't be. There might be a slippery slope that says to reduce the SYN delay, but I'm not buying into it. Look at SMTP for example: if you open a connection on port 25 to my mail server it is going to check your IP against a number of spam lists before returning the ACK. This takes time; if we put 100ms here it is broken. What Alain refers to is one of the reasons I stated earlier that we will continue to see split or dual-headed DNS, because if an app uses TCP as the transport mechanism, we are looking at either a SYN to detect reachability or at an app failure because the reachability detection mechanism used ICMP or UDP. In either case, we are looking at unacceptable delay. Delay leads to frustration. Frustration leads to split-DNS. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: null-routed aggregated global unicast (was: another view of fc00::/7)
jj, > Earlier, I suggested that an ISP could delegate addresses > out of its existing aggregated, global unicast address block > for free without providing connectivity. Having seen all of > the email on this subject, I believe that such an ISP could > actually sell prefixes for which it doesn't provide direct > connectivity. Such addresses could be used for VPN's, etc. > without fear of collision. Traffic destined to such addresses > on the Internet would be aggregated to the ISP, and probably > sent to /dev/null. I like this better than anything else I have seen to date. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: another view of fc00::/7
Kre, > Robert Elz wrote: > So, you mean there's a need to have address stability > inside the VPN? On some, more than anything else. For example, if the VPN is used as part of a supply chain, there are access-lists on both ends and a lot of other manual config all over the place because this involves getting access into some protected areas of the system. > I always thought a VPN was more about access control, > rather than anything else. Access control means access-lists and similar annoyances and they don't change dynamically. This blends with the renumbering issue that I don't want to open again but a perfect example of "un-renumberable" network is a large, multi-company VPN setup. > I can't see any particular reason why address stability is > any more required there than the internet at large. Because VPN configurations are sometimes a lot more complicated than Internet configurations. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: another view of fc00::/7
Zefram,
>> Robert Elz wrote:
>> What we're lacking is any way to make a globally-scoped
>> non-routable address. That is, what gives us global
>> scoping in 2000::/3 (and most other unallocated spaces,
>> one presumes) is the routability - the two go hand in
>> hand.
> Zefram wrote:
> Here we're talking about two different things due to the
> two meanings of "scope". You're using the definition where
> scope = domain of routability. I should perhaps have
> clarified, I was using the meaning scope = domain of
> meaningfulness. Let's not rehash the debate about whether
> these are really distinct in {theory,practice}.
You just can't have two definitions and use one or the other depending
on convenience. Although it is true that in theory scope of
meaningfulness is not the same as scope of routability, unless you have
a proposal to make this happen they're the same for all practical
purposes. So I fully agree with kre when he says that what we're lacking
is any way to make a globally-scoped non-routable address.
I have said in the past that the only way we can "guarantee" that unique
addresses won't be transformed into PI is scope. In theory this is not
true as one might invent a scopeless mechanism to achieve this, but
without seing any signs or ideas about one it remains true for all
practical means.
Any attempt to remove ambiguity in private addresses that have a global
scope will be perverted into wild unaggregated PI which is not
acceptable.
Michel.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
RE: Status of
> Ole Troan wrote: > I agree with kre, stick to fec0::/10. Me too. A scheme with the lower part of it for random and the upper part of it for a fee would work too. Although this would represent only 15 prefixes per person in the long run (that's only 4 million subnet for a family of 4, way to small to design a home network :-) let's keep in mind that these are private addresses and not everyone would need one. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Status of
>> Andrew White wrote: >> - A network with access to the global internet via >> more than one independent path. > Pekka Savola wrote: > In some cases, it's more detailed than that, but yes. Agree. >> Andrew White wrote: >> - A node with more than one usable address (having addresses >> in more than one logical subnet simultaneously). > Pekka Savola wrote: > That's "multi-addressing". (Note that there's a significant > overlap with the two definitions above.) I don't even think that there is a need for a word; the capacity of a host to have multiple addresses has been built into IPv6 for a long time. In my experience, "multi-addressing" is generally used for a form of multihoming where a host that has multiple global PA addresses form multiple providers to connect to the global Internet via multiple paths. IMHO, a host that has a global address and a local address is neither multihomed nor multi-addressed. It's just a regular IPv6 host. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Draft on Globally Unique IPv6 Local Unicast Addresses
> Hans Kruse wrote: > I actually see a lot of value in the /56 proposal I will side with Brian Carpenter on this one: we have RFC3177 and I do not see enough reasons to re-visit it at this time. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Draft on a V6 documentation prefix
Tim, >> Michel Py wrote: >> The trouble with using things such as :::/32 and >> :::/32 is that they can't be configured on a router and >> won't prevent the hijacking of a real prefix when labing the >> case, which is what the documentation prefix tries to prevent >> from happening. > Tim Chown wrote: > So if we do create this prefix, what's the difference between > this and an allocated prefix for private use in networks? Basically none. > You're suggesting it's not a documentation prefix, Not _only_ a documentation prefix. > but a prefix for use in (disconnected) networks. Throw in > v6 NAT and... ;) This is a very valid point that has been made several times before. It is clear that the documentation prefix is a prime candidate for hijacking for NAT purposes. That being said, there are plenty of other good candidates such as returned prefixes of 3ffe::/16, the entire 3ffe::/16 space after 6/6/6, 2002:RFC:1918::, a random prefix out of unallocated space in the C000::/16 range, etc. IMHO a _few_ /32 prefixes would be preferable for lab scenarios (for reasons outlined earlier) and would not encourage NAT more than a single one. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Globally Unique Private Addresses and Scoped Architecture
Harald, >> Michel Py wrote: >> Example that works (WRT to being un-routable on the public >> Internet that is): RFC1918. Although we occasionally see >> these on the public Internet, it's due to misconfiguration. >> No customer is going to see their upstream and offer them >> money to leak or route RFC1918 addresses, because it >> achieves nothing (because RFC1918 addresses are ambiguous). >> No demand, no routing. Since what we are talking about here >> is to remove ambiguity, we must provide a replacement for >> what ambiguity provides in terms of enforcing the non >> -public-routability. > Harald Tveit Alvestrand wrote: > when IPv4 customers come to their ISP and offer them money > in order to route RFC 1918 addresses to places the customer > is not directly connected to, we usually call the result a > provider provisioned VPN. > Demand seems widespread. > So if we roll out globally unique non-routable addresses, > we should not be at all surprised to see that ISPs will > actually route them if offered enough money; it's simpler > (and therefore cheaper) for them than configuring a VPN. Agree. What would be a surprise is if they would not try. > (of course this only works in v4 if the two ends have > coordinated their RFC 1918 deplyment plans. There are > a lot of cases when they do.) Which is why we need to reduce the odds of what you described two paragraphs ago happening in v6 as much as we possibly can. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve
Margaret, > Margaret Wasserman wrote: > Tony, allowing an interface to have two addresses: > - One that is globally routable and globally accessible, > and > - One that is stable and local, > is _exactly_ what I am proposing. > However, I am proposing that there is _no reason_ why > the stable, local addresses have to be ambiguous. These are worthy goals and I like them very much. However, given the history, I think you put them in the wrong order. I would like to see: 1. - One that is stable and local and not ambiguous. then 2. - One that is globally routable and globally accessible. Although there is nothing that says that 1 needs to be delivered before 2, I will remind everyone that the quest for 2 has started 10 years ago and that we still have to see a result. As of 1, it has its own set of challenges, one being that there must be some kind of architectural limitation to prevent it to become 2 with a routing table explosion. I will post soon more details about what I think is required to achieve 1. 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]
Consensus on vaporware (was RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
Folks, Here is exactly why I say that this is a consensus on vaporware: > Harald Tveit Alvestrand wrote: > Note: By "Deprecate Site-Local", I mean [snip] Everyone has their own definition about what "Deprecate Site-Local" means. Michel. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: My Thoughts on Site-Locals
Alex, > Alex Zinin wrote: > The problem or rather inconvenience with tieing site > boundaries and area/domain boundaries is that they > are driven by different factors. Imagine, for instance, > that your site that is currently implemented as an OSPF > area is growing so big that you need to split it into > multiple areas to give your routers a break. Because > your site boundaries are driven by non-routing > considerations (you just want your network to continue > working as it used to), you don't want to split the site > into two, so what you end up with is removing that big > site from the OSPF domain in a separate one and splitting > it into its own areas, while normally you would just have > one more area in the OSPF domain. Operationally, this > might be a headache. Agreed. I don't like the word "area" myself in this context; I was simply quoting Margaret's words. There are plenty of other cases like this, for example using two different IGPs as the result of a merger-never-finished-the-cleanup or related; I have seen a site where half of it was EIGRP the other half OSPF with mutual bidirectional redistribution and eBGP in the middle. :-( Mmmm thinking about it, :-) job security. Anyway, I suggested earlier that the site boundaries should be the administrative control boundaries of the organization. It might not be the correct wording, but my feeling is that we could come with some text that will detail the position of site boundaries. I have made the point earlier many times that the definition of "site" is ambiguous and/or imprecise, there is some geographical connotation attached to the word, we need a good definition anyway. >> This is the way I would do it anyway. I understand that we >> should not put restrictions when there is no need for them, >> but if putting a restriction allows something to work there >> is nothing wrong with it. > I don't think this is _the_ problem. This only contributes > to the list of complications. Also count modifications to > RIB, FIB management, the forwarding process, making pings, > traceroutes, etc site-aware... It's not impossible, in fact > we know exactly how to do this, it just that complexity adds > up to one side of the equation, and you really want to avoid > extra complexity in routing and below... I agree, but the other side of this coin is that if the feature is not implemented in the architecture it will be implemented by the configuration at the site. In other words, if as a site administrator I am not happy about the way the site-local traffic flows I am going to tweak it using route-maps, prefix-lists, route tags and whatever I feel like doing for my intra-site traffic engineering. Each site will end up being configured differently. Although there still is a lot of work to be done on the topic, I think that the convexity of the site is a good idea to incorporate in the architecture. In short: - If site convexity is not built-in the architecture, it might or might not work depending on implementation, network topology, etc. This will lead in many cases to manual policy routing config to make it work the may it should. - If site convexity is built-in the architecture, the only case where it would require manual policy routing config is if the site administrator wants to break convexity. I can't think of a reason but I'm sure they are some valid ones. As some others have commented, IPv6 is not only IPv4 with more bits. The issue of "automatic site convexity" is definitively a pain to implement in router code, but is also a feature that simplifies the life of network administrators and as such a factor of success for IPv6. 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]
