Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
On Mon, 6 Mar 2006 11:24:59 +0100, Kurt Erik Lindqvist [EMAIL PROTECTED] said: [snip] Ok, so shim6 doesn't require a change to the transport layer and it doesn't change the forwarding plane. It does create a mapping state at the end-nodes. So claiming it to be either is probably wrong. I stand corrected. Was commenting from a flawed perspective. The most correct is probably to consider it a sub-layer to the existing L3. //per -- Per Heldal http://heldal.eml.cc/
Re: Shim6 vs PI addressing
Roland Dobbins wrote: On Mar 3, 2006, at 10:50 AM, Stephen Sprunk wrote: OTOH, hosts go a lot longer between upgrades and generally don't have professional admins. It'll be a long, long time (if ever) until shim6 is deployed widely enough for folks to literally bet their company on host-based multihoming. This issue alone means that shim6 isn't viable. Besides the already- mentioned security and complexity issues, enterprise IT departments - i.e., the customers who need multihoming and cannot live without it - are not going to be amused when told that the tens and hundreds of thousands of desktops, laptops, PDAs, and other IP-enabled devices on their networks are now essentially routers, with multiple IP addresses and complex middleware required to simply access 'the Internet' . . . We've been here before; we shift a lot of data in the content arena, and our web-head loadbalancers, installed only a year ago, don't even support ipv6 in the current software build. -a
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
On Sat, 4 Mar 2006 13:35:02 +0100, Kurt Erik Lindqvist [EMAIL PROTECTED] said: On 2 mar 2006, at 21.42, Andre Oppermann wrote: Putting routing decisions into the transport layer (4) as it is done or proposed with SCTP and SHIM6 is Total Evilness(tm) in my book. Not that shim6 is a change to transport though, but a change at layer 3... Isn't the fact that shim6 doesn't affect the forwarding-plane of routers an argument that is used to its advantage? It seems more like something mingling the transport and session layers if anyone ask me (not that the old iso-model is all that relevant anymore imho). //per -- Per Heldal http://heldal.eml.cc/
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
On 6 mar 2006, at 11.10, Per Heldal wrote: On Sat, 4 Mar 2006 13:35:02 +0100, Kurt Erik Lindqvist [EMAIL PROTECTED] said: On 2 mar 2006, at 21.42, Andre Oppermann wrote: Putting routing decisions into the transport layer (4) as it is done or proposed with SCTP and SHIM6 is Total Evilness(tm) in my book. Not that shim6 is a change to transport though, but a change at layer 3... Isn't the fact that shim6 doesn't affect the forwarding-plane of routers an argument that is used to its advantage? It seems more like something mingling the transport and session layers if anyone ask me (not that the old iso-model is all that relevant anymore imho). Ok, so shim6 doesn't require a change to the transport layer and it doesn't change the forwarding plane. It does create a mapping state at the end-nodes. So claiming it to be either is probably wrong. - kurtis -
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
On 3-mrt-2006, at 4:54, Marshall Eubanks wrote: I've talked long and hard about why it's bad to have nearly unrestricted PI in IPv6 because the routing system can't scale (either at all or at reasonable cost) to accommodate this, but apparently this argument isn't universally convincing among operators. However, within the IETF there is reasonable consensus that there is enough of a risk to warrant efforts to provide multihoming benefits that don't impact routing. The IETF is at serious risk of being overtaken by events here, in my humble opinion. I have just returned from China, where there is a serious effort focused on deploying IPv6, and where there are 111 million Internet users, most with broadband, according to government statistics. I do not think that they and the other people waiting on IPv6 are going to wait a decade for this to be sorted out. There are currently 265 AS numbers assigned in China (9 more than what Sweden has) so apparantly multihoming isn't too high on their list of priorities. There haven't been any developments the last few years that warrant such a policy change. Yes, some people are saying that they won't deploy IPv6 without easy multihoming, but I've yet to hear someone say that they WILL deploy IPv6 within a year WITH easy multihoming. For instance, Google has had 2001:4860::/32 since april but I've yet to see any of their services work over IPv6. Yes, there are problems with the current policy. For instance, if you're a large transit ISP and your customers all have their own address space, you're not going to assign address space to them so you don't qualify for IPv6 address space. However, it would be nice to be able to give your routers addresses. Why not create a policy that addresses these issues, rather than try to do a full 180 on what's been in place for years? Last but not least, a /48 isn't going to give large hosting companies and large enterprises what they want/need, which is generally multiple address blocks for multiple locations. We can debate whether deagregating a /32 in IPv6 is going to work well (I say: don't count on it), but nobody in their right mind is going to accept prefixes longer than a /48. So this policy will allow creating a swamp in IPv6 and still not address the needs it is supposed to address. Deaggregating a /32 into /48s has the potential to increase the global routing table by 65000 routes. Such an event will almost certainly overload routers that don't filter those prefixes out. This to be honest sounds like the sort of thing that router vendors would love to build filters for, much like dampening routing flaps or rate limiting MSDP storms. I don't think creating a potential problem just so vendors can have a crack at trying to solve it is a good use of our collective time. After all, an ASN going from one address block to 65,000 should be detectable automatically. Not very easily. It means keeping statistics on the number of prefixes per origin AS, which is additional work and additional knobs that can be turned into the wrong direction. I see no reason why this will lead to the filtering of all IPv6 /48's. A couple of years ago I discovered that the F root server has an IPv6 address: 2001:500::1035. This was assigned as a /48 by ARIN even though their IPv6 policy (still) says: [wait wait wait until I fall back to IPv4 because www.arin.net is currently unreachable over IPv6] 6.4.3. Minimum Allocation RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. The ISP that I used at the time installed prefix length filters accordingly so I couldn't reach the F root server over IPv6. Moral of the story: if you build in a way for people to screw up, they'll do it. After that, they'll start throwing out some babies with the bath water.
Re: Shim6 vs PI addressing
On Wed, 1 Mar 2006, Iljitsch van Beijnum wrote: 3. Route processing and FIB lookups scale worse than linear 6. Moore can't go on forever, there are physical limitations The funny part: Those on this list who have cited Moore's Law don't seem to have an understanding that it does not directly apply to custom routing logic (since general-purpose CPUs are no longer fast enough to do the lookups on the high end). In addition, GP CPUs are no longer scaling exponentially, but rather closer to quadratically and approaching linear. In short, Moore's Law is dying, and even if it weren't, it is not a valid argument for let the swamp in. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Shim6 vs PI addressing
Thus spake Todd Vierling [EMAIL PROTECTED] On Wed, 1 Mar 2006, Iljitsch van Beijnum wrote: 3. Route processing and FIB lookups scale worse than linear 6. Moore can't go on forever, there are physical limitations The funny part: Those on this list who have cited Moore's Law don't seem to have an understanding that it does not directly apply to custom routing logic (since general-purpose CPUs are no longer fast enough to do the lookups on the high end). In addition, GP CPUs are no longer scaling exponentially, but rather closer to quadratically and approaching linear. In short, Moore's Law is dying, Moore's Law says nothing about performance; it only refers to transistor densities. In fact, current CPUs are still following the predicted curve, but they're turning fewer and fewer of those transistors into actual performance improvements. That's what the move to dual-core is about: finding more productive ways to use the wealth transistors now available. However, I agree that custom logic for routers does not necessarily follow the same curve; the volume is still low enough that vendors can't (or don't) use the best processes available. Heck, even the best available main CPUs are several years behind what's available in the PC market (why ship a 2GHz CPU when you can ship a 500MHz one at ten times the price?). and even if it weren't, it is not a valid argument for let the swamp in. One of the key attributes of the v4 swamp is that most orgs got more than one assignment (aka routing slot), often dozens to hundreds; the proposed policies for a v6 swamp do not allow that. S Stephen SprunkStupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them. --Aaron Sorkin
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] On 3-mrt-2006, at 4:54, Marshall Eubanks wrote: I've talked long and hard about why it's bad to have nearly unrestricted PI in IPv6 because the routing system can't scale (either at all or at reasonable cost) to accommodate this, but apparently this argument isn't universally convincing among operators. However, within the IETF there is reasonable consensus that there is enough of a risk to warrant efforts to provide multihoming benefits that don't impact routing. The IETF is at serious risk of being overtaken by events here, in my humble opinion. I have just returned from China, where there is a serious effort focused on deploying IPv6, and where there are 111 million Internet users, most with broadband, according to government statistics. I do not think that they and the other people waiting on IPv6 are going to wait a decade for this to be sorted out. There are currently 265 AS numbers assigned in China (9 more than what Sweden has) so apparantly multihoming isn't too high on their list of priorities. There's a general lack of competition over there; remember, it's a communist country, not a capitalist one. If one _wanted_ to multihome in China, there's a limited business possibility of doing so. That's changing slowly, but it's still the reality today. There haven't been any developments the last few years that warrant such a policy change. Yes, some people are saying that they won't deploy IPv6 without easy multihoming, but I've yet to hear someone say that they WILL deploy IPv6 within a year WITH easy multihoming. For instance, Google has had 2001:4860::/32 since april but I've yet to see any of their services work over IPv6. That's particularly telling. Of all companies, I'd have expected Google to go IPv6 long before there was a compelling business reason. It'd be interesting to hear from someone there why they haven't rolled it out yet. Yes, there are problems with the current policy. For instance, if you're a large transit ISP and your customers all have their own address space, you're not going to assign address space to them so you don't qualify for IPv6 address space. However, it would be nice to be able to give your routers addresses. Why not create a policy that addresses these issues, rather than try to do a full 180 on what's been in place for years? Current ARIN policy allows assigning a /32 to an LIR if they're merely a known ISP in the ARIN region. The 200 site requirement is only for new entrants to the ISP world, or for enterprises that want to pretend to be an LIR. Last but not least, a /48 isn't going to give large hosting companies and large enterprises what they want/need, which is generally multiple address blocks for multiple locations. We can debate whether deagregating a /32 in IPv6 is going to work well (I say: don't count on it), but nobody in their right mind is going to accept prefixes longer than a /48. So this policy will allow creating a swamp in IPv6 and still not address the needs it is supposed to address. I'm not sure it'll create a swamp, but at least one (I don't have both in front of me) of the proposals allows for assignment of a shorter prefix if it is justified. One could make a reasonable case that announcing /48s in four locations justifies a /46 (or even /45). Conversely, one could convince their upstream(s) to accept longer prefixes as long as they're tagged no-export. That keeps the routing tables at other ISPs to a minimum, but still gets you the majority of the benefit of deaggregating. Either way, be sure to announce the agregate in all locations as well. Deaggregating a /32 into /48s has the potential to increase the global routing table by 65000 routes. Such an event will almost certainly overload routers that don't filter those prefixes out. This to be honest sounds like the sort of thing that router vendors would love to build filters for, much like dampening routing flaps or rate limiting MSDP storms. I don't think creating a potential problem just so vendors can have a crack at trying to solve it is a good use of our collective time. This is why we've proposed assigning mainly /48s to end-user orgs: ISPs can easily filter at the /48 boundary. These assignments should be out of a single block, which would make it easy for ISPs to set different limits on the PI block (just like the microallocation block(s)) and, if necessary, drop all routes from it if it actually turns into a swamp. I see no reason why this will lead to the filtering of all IPv6 /48's. A couple of years ago I discovered that the F root server has an IPv6 address: 2001:500::1035. This was assigned as a /48 by ARIN even though their IPv6 policy (still) says: [wait wait wait until I fall back to IPv4 because www.arin.net is currently unreachable over IPv6] 6.4.3. Minimum Allocation RIRs will apply a
Re: Shim6 vs PI addressing
Owen DeLong wrote: Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Full ACK! For the IDR we then can use perfect match lookups which scale very well and pretty cheaply to many millions of table entries. BGP scales very well too if you've got a decent cpu in your router. Our OpenBGPD easily does 30 flapping constandly full-feeds with 1 million routes each. Lets get pragmatic and realistic! -- Andre
Re: Shim6 vs PI addressing
[Pekka, thanks for the Shim6 Summary paper ;) ] On Wed, 2006-03-01 at 14:58 -0800, Owen DeLong wrote: Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Vaporware part is true, upto now, operational value is to be seen. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Greets, Jeroen (who simply would like a policy where endsites that want it could request a /48 or /40 depending on requirements from a dedicated block which one day might be used for identity purposes and not pop up in the bgp tables or whatever we have then anymore) I would, for one. Policy proposal 2005-1 (I am the author) comes reasonably close to that. It will be discussed at the ARIN policy meeting in Montreal in April. Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing address space now while being able to use it differently later when it is needed. Though as Joe Abley also mentioned (and I also quite a number of times already ;) anyone with even a vague definition of a plan for 200 customers can get a /32 IPv6 without a problem. Just check the GRH list for companies in your neighbourhood who did get it. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Vaporware part is true, upto now, operational value is to be seen. Well... I can only go based on the existing drafts since there's no running code to base an opinion on, but, my opinion of the drafts is that it will provide minimal operational value. It's the wrong answer to the wrong question, in my opinion. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Yes, I am well aware of 32bit ASNs. However, some things to consider: 1. Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. 2. In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing address space now while being able to use it differently later when it is needed. Though as Joe Abley also mentioned (and I also quite a number of times already ;) anyone with even a vague definition of a plan for 200 customers can get a /32 IPv6 without a problem. Just check the GRH list for companies in your neighbourhood who did get it. True, but, until recently, I was being told that ARIN insisted that the 200 customers had to be non-related third parties. E.g. Chevron couldn't use all their different business units as 200 customers of Chevron Corporate IT. It appears based on some recent allocations that they may have relaxed that stance. Regards, Owen pgpJQC40MCVGM.pgp Description: PGP signature
Re: Shim6 vs PI addressing
On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote: Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Yes, I am well aware of 32bit ASNs. However, some things to consider: 1.Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. True. If we would take the 170k routes that are in BGP at the moment then a 18bits address space is enough to give every route a dedicated ASN. The issue is that there are way more people who might want to multihome than that, just take the number of businesses on this planet, add some future growth and we'll end up using the 24th bit too quite quickly. Which is, according to some people who do routing code, no problem at all. Like shim6, see first then believe. 2.In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. Paper/draft/description/website? :) Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing address space now while being able to use it differently later when it is needed. Though as Joe Abley also mentioned (and I also quite a number of times already ;) anyone with even a vague definition of a plan for 200 customers can get a /32 IPv6 without a problem. Just check the GRH list for companies in your neighbourhood who did get it. True, but, until recently, I was being told that ARIN insisted that the 200 customers had to be non-related third parties. E.g. Chevron couldn't use all their different business units as 200 customers of Chevron Corporate IT. It appears based on some recent allocations that they may have relaxed that stance. It might have been that ARIN was a bit stricter, the other RIR's though have never given any real problems as far as I know. The few ones that I heared of that couldn't get it, either didn't try or didn't want to lie about their plans. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
On Thu, Mar 02, 2006 at 02:21:45AM -0800, Owen DeLong wrote: Yes, I am well aware of 32bit ASNs. However, some things to consider: 1. Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. It's probably worth using this juncture to point out that exactly the same principle applies to the bit-width gap between IPv4 and IPv6: the fact that IPv6 gives 128 bits doesn't mean we're going to allocate all of them right away. The number of networks in use is not driven by the size of the address space; it's driven by the number of enterprises who wish to connect to the Internet, the number of sites at which they wish to connect, the number of interfaces they wish to use to carry out their interconnections, and the number of hosts they're bringing along with each connection. Notice that none of that has anything to do with the version number of the protocol which those hosts are speaking. By any way you measure it, Internet growth is a function of end-user demand, not a function of the number of bits in an IP address. We can spend another decade talking about how to manage routing table growth if we really want to, but during that decade the routing table is going to *keep growing anyway*. If we want to prevent it from growing, the only real way to do it is going to be at the demand side -- which is another way of saying that we'd need to address and control all of the clauses I iterated through two paragraphs ago. When you distill *that* message to its essence, you can restate it like this: We can control the growth of the IP routing table by making it harder for people to connect their networks to the Internet. Because that's what the advocates for IPv6 universal PA space are *really* saying, once you remove all the smoke and mirrors. ... which neatly explains a major reason for why IPv6 hasn't taken off, and why shim6 remains vapourware despite many years of discussion and the presence of a clear, unambiguous demand for a solution to the multihoming problem. What's the way out? Acknowledgement of the fact that the size of the routing table is a function of the size of the Internet. Y'know, one of those duh! statements. If we expect the Internet to grow past 32-bit limitations, we're going to have to expect the routing table to grow past the constraints which that 32-bit world has imposed upon it. Solving *that* problem is, IMHO, overwhelmingly preferable to breaking multihoming and handing routing policy decisions over to the viruses and worms which control each host. (note that I'm not pretending that solving the routing table growth problem is -easy-, it's just plainly obvious to me that it'll need to be solved anyway, and the IPv6 PA advocacy that keeps coming up seems to be an exercise in denial...) - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
On Thu, 2 Mar 2006, Owen DeLong wrote: I think that is overly pessimistic. I would say that SHIM6 _MAY_ Yes, I am well aware of 32bit ASNs. However, some things to consider: 1. Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for Probably 20 bits or 24 bits rather then 18. It maybe worth it to reserve top 8 bits for some experimental future use. the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. 2. In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. I thought of something of this sort some time ago but never got around to full proposal on it (maybe somebody else did?). I'm trying to go through my notes now - maybe it could prove useful if research or engineering people do indeed want to work on something like that. My thinking was that its a big waste of memory (in the global bgp table) to announce every IPv6 route in full in particular for cases when its sub-allocation and aggregate is already being announced. As an example lets take some ip block like say A100:1000::/32 that is allocated to an ISP 'A' by RIR. Now lets say that this ISP 'A' (AS1) has a customer who received A100:1000:0010::/48 and later same customer got connection from ISP 'B' (AS2) as well and wants to multihome. For normal BGP that would mean that full route of A100:1000:0010::/48 would appear in BGP and increase its size quite a bit. But it maybe possible to do limited bgp multi-homing by having such /48 and similar routes included as attributes of the main route, i.e. A100:1000::/32 route would appear with extended attributes like Subroutes: 0010/16 (2) Where 0010/16 indicates subroute as seen within A100:1000::/32 ip block (i.e. netmask here is added to netmask of A100:1000 route to get full netmask on the internet) and (2) is an additional ASN that such subroute can also be found through. Now if properly designed, such subroute attribute can be compacted to be around 64 bits extra each (slightly more if multihoming is through more then one ASN and subblock is smaller size then /16) and 64bits data for each multi-homed customer in BGP appear to me something that we can deal with. Unfortunately with this design, the issue then becomes how some AS10 (the end-site) knows how to get to AS2 (one way maybe to do ASN routes as part of BGP in addition to ipv4 and ipv6 routes). As well as what to do if connection from customer to AS1 or from AS1 to internet drops since its AS1 that announces such subroutes as part of its aggregate and purpose of multi-homing it to let it work without it (this can be done with AS2 also announcing A100:1000::/32 but with special attribute indicating its valid only for subroutes and such route should not be propagated if same ASN also sees primary AS1 direct route). Another possibility of similar design (kind-of already mentioned above) is to allow AS2 to announce A100:1000::/32 on the internet as it would its own route but indicate that it is valid only for specific subroutes and not as an aggregate (in fact in this design AS1 would not even have subroutes in its main route announcement). While this means entire full route on the net, the hope is that if AS1 and AS2 have number of common multi-homed customers, the net would be spared from separate BGP routes for each one and the end-site AS10 would only see something like: BGP routing table for A1000:1000::/32 9 8 7 6 1 Origin IGP 5 4 3 2 Origin IGP, Subroutes-Only Subroutes: 0010/16 0101/16 So from above if router needs to send data to either A1000:1000:0010::/48 or A100:1000:0101::/48 it would choose 2nd path through peer AS5 as having smaller as-path. All these approaches (especially second one) however certain problems when you have to consider route security authorization (i.e. SIDR/SBGP space) as its necessary to convey that AS2 is to be allowed to announce A100:1000: block for specific subroutes. But I think these issues can be worked out like having AS2 sendscertificate request for subblock to AS1 which it then signs and gives new certificate authorizing announcement with specific subblock attribute to AS2. More general issues with these approaches is obviously that there is no possibility of PI space as customers that need multi-homing would have to get space from one of its ISPs (well, actually it is still possible to do PI - it is just that multiple ISPs would be expected to announce large aggregate of the PI block with bunch of subroutes on equal basis). Anyway, if you have comments or if something like this has
Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
On 2-mrt-2006, at 13:44, william(at)elan.net wrote: 2. In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. Yes, we wouldn't want to run out of AS numbers just now we're creating 4.29 billion new ones... My thinking was that its a big waste of memory (in the global bgp table) to announce every IPv6 route in full in particular for cases when its sub-allocation and aggregate is already being announced. Yes, it would be cool if the routers or route servers could automatically detect this and clean up the routing table. Unfortunately: A --- B / \ X Y \ / C --- D If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or B could decide to suppress the /24. However, Y will see the /24 through D and C but not through B and A, so Y will now send all of its traffic to X through C and D. But it maybe possible to do limited bgp multi-homing by having such /48 and similar routes included as attributes of the main route, i.e. A100:1000::/32 route would appear with extended attributes like Subroutes: 0010/16 (2) Some years ago, I suggested doing this by adding a bitmap to the aggregate route: a single bit is enough to convey holes in the aggregate, with two or three bits you can also do some traffic engineering. This will get you from a /16 aggregate to individual / 24s with 32 bytes (1 bit per more specific) or a /32 to /48s with 8 kilobytes. Such an approach does depend on relatively tight packing of end-users that share the same ISPs, though. All these approaches (especially second one) however certain problems when you have to consider route security authorization (i.e. SIDR/SBGP space) IDR security doesn't come cheap anyway: be prepared to double or quadruple your router's memory and install crypto hardware.
Re: Shim6 vs PI addressing
On Wed, Mar 01, 2006 at 03:01:22PM -0800, Owen DeLong wrote: I think you're missing that some people do odd things with their IPs as well, like have one ASN and 35 different sites where they connect to their upstream Tier69.net all with the same ASN. This means that their 35 offices/sites will each need a /32, not one per the entire asn in the table. People who are doing that have not read the definition of the term ASN and there is no reason that the community or public policy should concern itself with supporting such violations of the RFCs. An AS is a collection of prefixes with a consistent and common routing policy. By definition, an AS must be a contiguous collection of prefixes or it is not properly a single AS. Using the same ASN to represent multiple AS is a clear violation. It doesn't fit the RFC definition of AS. Therefore, there is no reason to support such usage on a continuing basis. You violate the RFC's you takes your chances. I guess all those root servers that use the same asn but connect to different networks (anycast) should get shut down quickly. This is a part of networking life today in the v4 space, and without any current changes, it will (is) the same in v6 routing as there is nothing different except a few more bits 32 = 128. No new routing protocol, nothing, except this shim6 thing which people don't seem interested in because it means network operators can't do the traffic engineering they need to. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)
On Thu, 2 Mar 2006, Iljitsch van Beijnum wrote: My thinking was that its a big waste of memory (in the global bgp table) to announce every IPv6 route in full in particular for cases when its sub-allocation and aggregate is already being announced. Yes, it would be cool if the routers or route servers could automatically detect this and clean up the routing table. Unfortunately: A --- B / \ X Y \ / C --- D If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or B could decide to suppress the /24. However, Y will see the /24 through D and C but not through B and A, so Y will now send all of its traffic to X through C and D. If you read through my design, it would be that Y should assume that aggregate as seen from B is always valid path even if it is not directly indicated by inclusion of special subroute attribute. This maybe both good and bad as far as such design goes. But it maybe possible to do limited bgp multi-homing by having such /48 and similar routes included as attributes of the main route, i.e. A100:1000::/32 route would appear with extended attributes like Subroutes: 0010/16 (2) Some years ago, I suggested doing this by adding a bitmap to the aggregate route: a single bit is enough to convey holes in the aggregate, with two or three bits you can also do some traffic engineering. This will get you from a /16 aggregate to individual /24s with 32 bytes (1 bit per more specific) or a /32 to /48s with 8 kilobytes. Can be done with bitmaps, but unless aggregate is very well filled with sub-allocations, this would be waste of memory too. I think individual subroutes is more reasonable as long as each one can be well compacted (0010/16 is 16-bits for netblock, max 7 bits for netmask). Such an approach does depend on relatively tight packing of end-users that share the same ISPs, though. All these approaches (especially second one) however certain problems when you have to consider route security authorization (i.e. SIDR/SBGP space) IDR security doesn't come cheap anyway: be prepared to double or quadruple your router's memory and install crypto hardware. Yes, most likely it will require dedicated box to process the security data and verify ip routes (Note: in usual way dedicated box might be represented as being separate card in the router). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Shim6 vs PI addressing
Does this mean that you support 2005-1, or do you think a new ARIN proposal is needed ? Regards Marshall Eubanks On Mar 2, 2006, at 4:28 AM, Andre Oppermann wrote: Owen DeLong wrote: Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Full ACK! For the IDR we then can use perfect match lookups which scale very well and pretty cheaply to many millions of table entries. BGP scales very well too if you've got a decent cpu in your router. Our OpenBGPD easily does 30 flapping constandly full-feeds with 1 million routes each. Lets get pragmatic and realistic! -- Andre
2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
Marshall Eubanks wrote: Does this mean that you support 2005-1, or do you think a new ARIN proposal is needed ? What I'm saying is that we should reconsider parts of IPv6' design decisions and fix stuff while we can. Opening the floodgates right now, which 2005-1 will do, will only cement the current IPv4 way of doing things with longest-prefix match. Doing longest-prefix match for high pps rates and high prefix counts in hardware is complex and expensive. Way more so than doing perfect match on 32 bits (giving 4bn routeable slots). To answer your question: I do support the rationale behind 2005-1 to allow for PI address space according to current IPv4 rules but I think it is premature right now to make the decision in this way. Once the first /48 according to it went out we have to support and carry it forever in the DFZ. Right now I'm against 2005-1. We should take a hard look at the current customer requirements and market drivers and look at either adjustments to current policies or even certain changes to IPv6 itself to align them. IMHO we have to find the best cross-section satisfying the following requirements: ) PI space to avoid renumbering when switching ISP's (independence) ) PI space to multi-home with two or more ISP's (performance/redundancy) ) PA space for ISP's to hand out to single-homed customers/consumers ) Efficient and cost-effective implementation of DFZ packet forwarding I'm a strong supporter of the original layered approach where different functionality resides on different levels of the stack and is not or only to least possible extent intermixed. Putting routing decisions into the transport layer (4) as it is done or proposed with SCTP and SHIM6 is Total Evilness(tm) in my book. Topology and such should be of no concern to transport. The network layer (3) must handle that in a transparent and independent fashion. This allows for future changes and improvements without having to change everything everywhere. And to make it clear I'm totally against geo-addressing finer than the size of RIR regions. Why should anyone take me seriously? Well, I'm running a genuine 4-digit AS number for as long as the RIR assigned it to me amost a decade ago. And I'm an operating system developer (FreeBSD) working on the network stack. This way I can claim to see all sides of the dice which helps a lot for the Big Picture(tm). -- Andre Regards Marshall Eubanks On Mar 2, 2006, at 4:28 AM, Andre Oppermann wrote: Owen DeLong wrote: Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Full ACK! For the IDR we then can use perfect match lookups which scale very well and pretty cheaply to many millions of table entries. BGP scales very well too if you've got a decent cpu in your router. Our OpenBGPD easily does 30 flapping constandly full-feeds with 1 million routes each. Lets get pragmatic and realistic! -- Andre
Re: Shim6 vs PI addressing
--On March 2, 2006 11:31:51 AM +0100 Jeroen Massar [EMAIL PROTECTED] wrote: On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote: Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Did you notice that 32bit ASN's are coming and that IPv4 addresses are 32bits? :) Which effectively means that we are going to route IPv6 with an IPv4 address space. Or when one would use the 32bit ASN for IPv4: routing a 32bit address space with an 32bit routing ID. The mere difference Yes, I am well aware of 32bit ASNs. However, some things to consider: 1. Just because ASNs are 32 bits doesn't mean we'll instantly issue all 4 billion of them. The reality is that we probably only need about 18 bits to express all the ASNs well need for the life of IPv6, but, 32 is the next convenient size and there's really no benefit to going with less than 32. True. If we would take the 170k routes that are in BGP at the moment then a 18bits address space is enough to give every route a dedicated ASN. The issue is that there are way more people who might want to multihome than that, just take the number of businesses on this planet, add some future growth and we'll end up using the 24th bit too quite quickly. Which is, according to some people who do routing code, no problem at all. Like shim6, see first then believe. 2. In my current thinking on how to achieve ASN based IDR, we would not need ASNs for every organization that multihomes, only for each organization that provides transit. This would greatly reduce some of the current and future demand for ASNs. Paper/draft/description/website? :) Paper: Haven't gotten that far yet. Draft: Haven't gotten that far yet. Description: See below Website: Haven't gotten that far yet. Description: This is still knocking around in my head so far. I've discussed and described it to a few folks, but, there are lots of details to work out yet. So, this will require a fair amount of imagination on your part, and, it will require letting go of a lot of assumptions built on the current dogma and paradigm. This is in many ways a completely different paradigm for interdomain routing. Basically, internet routers would come in three flavors: 1. Intradomain Routers -- Routers which have a default route and limited or no detailed knowledge of topology beyond the local ASN. 2. DFZ Edge Routers -- Routers which participate in the IDR process (full BGP feeds) which have adjacencies with Intradomain Routers. 3. DFZ Core Routers -- Routers which participate in IDR as in 2 above, but, which do not have any adjacencies with routers from category 1 above. In the long run, routers in category 2 and 3 would only carry prefix information for routes terminating in the local AS. For all exterior routes and peering sessions, only AS PATH data would be exchanged, without any prefix information. (In the interim, BGP would be unchanged and routing table bloat would continue to be an issue, but, the routing process could change on a router-by-router basis without requiring a flag day conversion). Routers in category 2 would insert an IPv6 extension header of type 53 with a new subtype (yet to be defined, probably 1) which would contain the Destination ASN for the packet. The lookup of Prefix-ASN mapping would be accomplished by a process similar to DNS (See Route Resolvers below). Routers in category 2 and 3 would forward packets by the following ruleset: Is extension header present? Yes: Is it my local ASN? (A) Yes: -- Prefix route available? Yes: Route packet by IGP No: Perform exterior resolution and rewrite ASN header if possible. Otherwise, drop packet. (see loop prevention below for details) (B) No: -- Forward based on ASPATH data to reach AS No: Resolve ASN -- Local? Yes: -- Continue process from (A) above No: -- Insert Extension header and continue from (B) above. Unresolvable: -- Drop packet, send Unreachable no route Route Resolver: Two new RR types and one new hierarchy would need to be added to DNS. The RR types would be AS and SIG, which would provide AS data similar to MX records and Cryptographic Signature data which could be used to trace the delegation of authority for the prefix back to IANA. The new hierarchy would be something like in-as.inet. and
Re: Shim6 vs PI addressing
--On March 2, 2006 9:37:12 AM -0500 Jared Mauch [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 03:01:22PM -0800, Owen DeLong wrote: I think you're missing that some people do odd things with their IPs as well, like have one ASN and 35 different sites where they connect to their upstream Tier69.net all with the same ASN. This means that their 35 offices/sites will each need a /32, not one per the entire asn in the table. People who are doing that have not read the definition of the term ASN and there is no reason that the community or public policy should concern itself with supporting such violations of the RFCs. An AS is a collection of prefixes with a consistent and common routing policy. By definition, an AS must be a contiguous collection of prefixes or it is not properly a single AS. Using the same ASN to represent multiple AS is a clear violation. It doesn't fit the RFC definition of AS. Therefore, there is no reason to support such usage on a continuing basis. You violate the RFC's you takes your chances. I guess all those root servers that use the same asn but connect to different networks (anycast) should get shut down quickly. No... In the case of anycast, there is a consistent routing policy for the address. There are services that don't work because of that routing policy, but, that's a decision of the service provider in question. However, they are using the equivalent of one /32 per entire ASN, not one per site. If they are advertising different prefixes from different sites in an inconsistent manner using the same ASN, that is broken. That's not what anycast does. This is a part of networking life today in the v4 space, and without any current changes, it will (is) the same in v6 routing as there is nothing different except a few more bits 32 = 128. Anycast is part of networking life today. What you described initially is _NOT_ how anycast works. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp6jhsnZoR8o.pgp Description: PGP signature
Re: Shim6 vs PI addressing
--- Jared Mauch [EMAIL PROTECTED] wrote: I think you're missing that some people do odd things with their IPs as well, like have one ASN and 35 different sites where they connect to their upstream Tier69.net all with the same ASN. This means that their 35 offices/sites will each need a /32, not one per the entire asn in the table. No, that's an argument for a /32 and a bunch of /48 allocations heard by a single provider, who's getting paid to carry them, but are not advertised to the rest of the Internet. And they may use different carriers in different cities. Obviously this doesn't fit the definition that some have of autonomous system, as these are 35 different discrete networks that share a globally unique identifier of sorts. Well, wait a minute - what would these people do TODAY? Some build tunnel backbones, some use one ASN per city, some do allowas-in or other things of that nature. I would venture to say that most medium to large enterprises don't use straight-Internet with no VPN of any kind to support their enterprise backbones anymore, simply for security reasons. My argument still stands - if having an ASN is equated with having a routable netblock, then each of those cases results in the enterprise being able to pass packets, and only the one ASN per city approach requires multiple netblocks. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
On Mar 2, 2006, at 2:06 PM, Iljitsch van Beijnum wrote: The IETF is making good progress with its multihoming in IPv6 efforts: implementable RFCs should be forthcoming within a year. Which proposals do you consider to be implementable? -- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Everything has been said. But nobody listens. -- Roger Shattuck
Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]
Hello; On Mar 2, 2006, at 5:06 PM, Iljitsch van Beijnum wrote: On 2-mrt-2006, at 21:42, Andre Oppermann wrote: To answer your question: I do support the rationale behind 2005-1 to allow for PI address space according to current IPv4 rules but I think it is premature right now to make the decision in this way. Once the first /48 according to it went out we have to support and carry it forever in the DFZ. Right now I'm against 2005-1. This is in and of itself enough to reject 2005-1, and I urge the ARIN constituency to do exactly that. We've had restrictive policies around the world for many years now, and so far we've been able to live with it. The IETF 2005-1 is fairly close to 2002-3, which has been in place for almost 3 years, and so far we've been able to live with it. is making good progress with its multihoming in IPv6 efforts: implementable RFCs should be forthcoming within a year. Currently, IPv6 deployment is not such that lack of multihoming is creating big problems. If this situation changes, a policy proposal like this one can presumably be adopted fast enough to avoid significant problems. I've talked long and hard about why it's bad to have nearly unrestricted PI in IPv6 because the routing system can't scale (either at all or at reasonable cost) to accommodate this, but apparently this argument isn't universally convincing among operators. However, within the IETF there is reasonable consensus that there is enough of a risk to warrant efforts to provide multihoming benefits that don't impact routing. The IETF is at serious risk of being overtaken by events here, in my humble opinion. I have just returned from China, where there is a serious effort focused on deploying IPv6, and where there are 111 million Internet users, most with broadband, according to government statistics. I do not think that they and the other people waiting on IPv6 are going to wait a decade for this to be sorted out. Also, having /48s for PI is a bad choice as it procludes easy filtering of accidental deaggregated PA prefixes. ISPs are getting / 32s or larger, and customers often get a /48. Deaggregating a /32 into /48s has the potential to increase the global routing table by 65000 routes. Such an event will almost certainly overload routers that don't filter those prefixes out. Experience in IPv4 shows us that accidental deaggregation is relatively common. The easiest way to avoid problems when this happens is filter out all /48s. Today, there must already be exceptions for root server /48s, but as the number of exceptions grows the filtes will become more fragile and the risk of deaggregation that isn't caught by filters increases. This to be honest sounds like the sort of thing that router vendors would love to build filters for, much like dampening routing flaps or rate limiting MSDP storms. After all, an ASN going from one address block to 65,000 should be detectable automatically. I see no reason why this will lead to the filtering of all IPv6 /48's. Finallly, allow me to observe that deciding on this issues regionally while the resulting routes must be carried world wide doesn't make sense. We really need a global forum for this. I fully agree here. Maybe a meeting should be organized in the fall of 2006 or early 2007 to discuss this, either under the auspices of the NRO (http://www.nro.net) or independently. Regards Marshall
Re: Shim6 vs PI addressing
On Wed, 2006-03-01 at 09:05 -0800, David Barak wrote: [..] Is it easier to scale N routers, or scale 1*N hosts? If we simply moved to an everyone with an ASN gets a /32 model, we'd have about 30,000 /32s. It would be a really long time before we had as many routes in the table as we do today, let alone the umpteen-bazillion routes which scare everyone so badly. Today indeed, but you are missing the point that IPv6 should last for the couple of next decennia. In IPv4 the starters also got a nice /8 as a bonus and the result: new small entities complaining that the first ones got the cool stuff and they can't have any. You might have noticed the 32-bit ASN talk. This is there for a reason: ASN's will go to 32bit mode. Can you say 4 million routes? :) Simple isn't always good. The KISS principle doesn't always work... The current 30k in-use ASN's (afaik they are even less) will and can explode when that means you can get easy address space. Btw, this is policy talk, you might want to bring that to ARIN PPML or the various other lists. If you want to propose a PI policy, then please make a decent proposal and send the relevant RIR group. That endsites require PI is inevitable, but the way those routes end up in the routing tables and the amount of address space each endsite is getting should be relevant to need, not to the fact that you got an ASN. (Which would mean I would qualify for 2x /32's... which is very silly as the couple of /48's I use is way more than enough. Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. Greets, Jeroen (who simply would like a policy where endsites that want it could request a /48 or /40 depending on requirements from a dedicated block which one day might be used for identity purposes and not pop up in the bgp tables or whatever we have then anymore) signature.asc Description: This is a digitally signed message part
Re: Shim6 vs PI addressing
On Wed, Mar 01, 2006 at 09:05:17AM -0800, David Barak wrote: --- Joe Abley [EMAIL PROTECTED] wrote: On 1-Mar-2006, at 11:22, David Barak wrote: As far as I can tell, the whole reason for these discussions is the insistence on the strict PA-addressing model, with no ability to advertise PA space to other providers. The whole reason for the strict PA-addressing model is concern over whether open-slather on PI address space will result in an Internet that will scale. Is it easier to scale N routers, or scale 1*N hosts? If we simply moved to an everyone with an ASN gets a /32 model, we'd have about 30,000 /32s. It would be a really long time before we had as many routes in the table as we do today, let alone the umpteen-bazillion routes which scare everyone so badly. I think you're missing that some people do odd things with their IPs as well, like have one ASN and 35 different sites where they connect to their upstream Tier69.net all with the same ASN. This means that their 35 offices/sites will each need a /32, not one per the entire asn in the table. And they may use different carriers in different cities. Obviously this doesn't fit the definition that some have of autonomous system, as these are 35 different discrete networks that share a globally unique identifier of sorts. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Shim6 vs PI addressing
On 1-mrt-2006, at 18:05, David Barak wrote: Is it easier to scale N routers, or scale 1*N hosts? Is it easier for the government to make a 5 year plan or for everyone to spend time and energy finding the best deal for everything? Every router has to search through its FIB tables for every packet it forwards. That's something like 10 FIB lookups for every packet flowing between two hosts. The hosts only have to search through their TCBs for every packet. Number of TCBs in nearly all hosts is smaller than the average FIB size (even if you consider that many routers don't have a full table). 2 x relatively small is a lot less than 10 x relatively large. Or, in other words: on the host you only pay if you actually communicate. In routers, you pay more as there is more routing information, whether the extra information is used or not. If we simply moved to an everyone with an ASN gets a /32 model, we'd have about 30,000 /32s. It would be a really long time before we had as many routes in the table as we do today, let alone the umpteen-bazillion routes which scare everyone so badly. 1. We've already walked the edge of the cliff several times (CIDR had to be implemented in a big hurry, later flap dampening and prefix length filtering were needed) 2. We'll have to live with IPv6 a long time 3. Route processing and FIB lookups scale worse than linear 4. If the global routing table meltdown happens, it will be extremely costly in a short time 5. Even if the meltdown doesn't happen a smaller routing table makes everything cheaper and gives us more implementation options (5000 entry TCAM is nice, 50 entries not so much as it basically uses 100 times as much power) 6. Moore can't go on forever, there are physical limitations But the most important thing we should remember is that currently, routing table growth is artificially limited by relatively strict requirements for getting a /24 or larger. With IPv6 this goes away, and we don't know how many people will want to multihome then.
Re: Shim6 vs PI addressing
Please don't mix up addressing and routing. PI addressing as you mention is addressing. SHIM6 will become a routing trick. I think that is overly pessimistic. I would say that SHIM6 _MAY_ become a routing trick, but, so far, SHIM6 is a still-born piece of overly complicated vaporware of minimal operational value, if any. Personally, I think a better solution is to stop overloading IDR meaning onto IP addresses and use ASNs for IDR and prefixes for intradomain routing only. Greets, Jeroen (who simply would like a policy where endsites that want it could request a /48 or /40 depending on requirements from a dedicated block which one day might be used for identity purposes and not pop up in the bgp tables or whatever we have then anymore) I would, for one. Policy proposal 2005-1 (I am the author) comes reasonably close to that. It will be discussed at the ARIN policy meeting in Montreal in April. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpadaQxSQlNp.pgp Description: PGP signature
Re: Shim6 vs PI addressing
I think you're missing that some people do odd things with their IPs as well, like have one ASN and 35 different sites where they connect to their upstream Tier69.net all with the same ASN. This means that their 35 offices/sites will each need a /32, not one per the entire asn in the table. People who are doing that have not read the definition of the term ASN and there is no reason that the community or public policy should concern itself with supporting such violations of the RFCs. An AS is a collection of prefixes with a consistent and common routing policy. By definition, an AS must be a contiguous collection of prefixes or it is not properly a single AS. Using the same ASN to represent multiple AS is a clear violation. And they may use different carriers in different cities. Obviously this doesn't fit the definition that some have of autonomous system, as these are 35 different discrete networks that share a globally unique identifier of sorts. It doesn't fit the RFC definition of AS. Therefore, there is no reason to support such usage on a continuing basis. You violate the RFC's you takes your chances. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp5GsDd6XvvY.pgp Description: PGP signature
Re: Shim6 vs PI addressing
--- Iljitsch van Beijnum [EMAIL PROTECTED] wrote: But the most important thing we should remember is that currently, routing table growth is artificially limited by relatively strict requirements for getting a /24 or larger. With IPv6 this goes away, and we don't know how many people will want to multihome then. So why not approach Shim6 as something for basement multihomers rather than enterprises? Honestly, the cost of the second connection is the limiting factor in most decisions not to multihome today, not the difficulty of getting BGP, an ASN, or a /24 from a provider... For your I have a cablemodem AND a DSL folks, Shim6 sounds like exactly what they need. However, once you start talking about enterprise-wide policies, etc, Shim6 starts to look like a really heavy hammer. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
