Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
* Owen DeLong [EMAIL PROTECTED] [2004-11-28 19:51]: there are a lot of organizations now having PI without having an ASN and beeing multihomed. a transition to v6 with this policy would make things much worse for them, so why should they? They shouldn't unless they need features that are available in v6 that are not available in v4. Where's the harm in this? The v6 stack provides for encapsulating v4 addresses in v6 easily enough and the v6 specs already make allowance for this. I don't see any reason we need to get such a site over to v6. ehm the v4-in-v6 mapping is a gigantic security issue. this is nothing but establishing tunnels automagically and extremely dangerous. v4-in-v6 is not supported on purpose or at least disabled by default on many OSes, and that is a good thing. How is this any more of a security hole than address-based trust in the first place. As near as I can tell, the 6-to-4 mapping is simply a legitimate form of address spoofing more than what I would call dynamic tunnels. As I understand it, there's some magic IPv6 prefix which since I don't remember what it is, I'll call pfx and your V4 address simply gets mapped to pfx::v4addr and away it goes. so you say they should just keep v4 - that does not really help in getting v6 deployed. You keep talking like getting v6 deployed for the sake of getting v6 deployed is some sort of goal that I should have. I don't. I don't care if v6 ever gets deployed. I care about being able to reach the parts of the internet I care about being able to reach. I suspect you will find that to be the case among most people. If you want to deploy v6 so you can play with v6, do it in your lab. If you want to show the world reasons they should deploy v6, go for it. If you expect a company that has v4 addresses and will get shafted by v6 policies to convert to v6 just for the sake of converting to v6, then, I think you need to take fewer drugs. The convenience factor _is_ already outlawed. true for new allocations, but there is a gigantic installed base, and making their situation worse isn't exactly helping in getting v6 deployed. As near as I can tell, there's very little reason for such a site to ever adopt v6 and very little reason for the world to care that they didn't. i think there's many many many more of those sites than you think. and we really don't want to run in two parallel universes for longer than it has to be... I think there are thousands of those sites and we _WILL_ run in two parallel universes until such time as v6 offers those sites some reason to convert. Hint: Shafting them on being able to get PI space in the v6 world is the opposite of a reason to convert. As such, I'm not sure I understand why this is a significant issue. Is there some reason it's important for these sites to go to v6 instead of using 4-to-6 address encapsulation at their border? 4-to-6 is a horrible mess. So you say, but, from the perspective of one of those sites that can't get PI space for v6, and, has v4 swamp space, I have to say, it looks like less of a mess than v6. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpZt66MW9JuD.pgp Description: PGP signature
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
Reclaiming AS numbers is a waste of time. We need to move beyond 16 bits at some point anyway. I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. I think that so much will change before we exhaust 4 billion ASNs that reclaiming them between now and then is really a waste of time. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpQPZuzauKyL.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. This makes some sense, however, how does the client system know which address it should use? what lets the client know that the path from client-server-address-ATT is better/worse/same as the path from client-server-address-MFN or client-server-address-uu ? I would think that the 'best' solution for all parties would be 'one' address for an end system, or one path to the end system. Because when it matters, the administrator of the zone has the option of removing the DNAME records for the provider that is sucking at the moment. Not a panacea, but, at least help. Single address may or may not be the best solution. One path to end system is definitely NOT the right answer for everyone. More paths is less failure. Perhaps this is just 'normal' technology acceptance process, and perhaps I'm missing a great many things in 'the v6-way', but if the multihoming can't be worked out in a sane manner I can't see rollout and acceptance of v6 coming any time soon. Apparently, you are, because, the whole DNAME/A6 thing was deprecated and we were lamenting that it's existence would have made this somewhat simpler to administer. there are, and will be in the future, folks that WANT NAT, regardless of the perceived 'badness' of it... Why? You still have yet to justify this position. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpenVqEaJqQC.pgp Description: PGP signature
RE: ULA and RIR cost-recovery
--On onsdag 24 november 2004 11.40 -0800 Tony Hain [EMAIL PROTECTED] wrote: The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Do note that, IIRC, RIPE had this up for discussion some time ago and opted in-session for an one AS -- one global prefix solution which was then overridden because APNIC and ARIN weren't as impressed by that solution. Don't blame Europe ;-) -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE pgp8Zh7NoCaFG.pgp Description: PGP signature
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
I suspect that it is now time to agree to disagree. I have said before and will say again: 1. IPv4 is fundamentally flawed in that we are using a single resource as both an end-point identifier and a routing identifier. The phone companies figured out that these must be separate years ago. 2. IPv6 took some steps to solve this by making this division somewhat artificially through the use of A6/DNAME, but, later backed off from this practice. 3. IPv6 then completely failed to address issue 1 in any other way, and, so, we have, as near as I can tell, essentially come full circle to TUBA which we initially rejected largely because of issues like number 1 above. To further paraphrase Randy: 'Swamp: do not drink.' Owen --On Monday, November 29, 2004 8:53 AM +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Sun, 28 Nov 2004, Owen DeLong wrote: Except that A6/DNAME also supported your upstream being able to initiate prefix renumbering without having to involve the end customer... [...] Sure. But draft-ietf-v6ops-renumbering-procedure-03.txt says it IMHO well: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. Their comments, if they result in improved address management practices in networks, may be the best contribution this note has to offer. The main thrust of A6/DNAME is adding hooks for handling so-called 'rapid renumbering' and 'not-user-initiated-renumbering' scenarios. That seems unfeasible and unreasonable. Renumbering cannot be prevented. And we should take all the reasonable actions to make sure it's manageable, because otherwise we'll end up with PI/ULAs and NATs. But AFAICS, obtaining a level of 'manageability' should be sufficient. We don't necessarily want or need to solve the most tricky renumbering problems here (e.g., rapid renumbering, automatic renumbering or large sites without any actions from the administrators, etc.). To paraphrase Randy from a couple of years ago: 'Ocean: do not drain.' -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- If it wasn't crypto-signed, it probably didn't come from me. pgpGcHC3BDRKF.pgp Description: PGP signature
Instant IPv6 PI solution for everyone (Was: BBC does IPv6 ;) (Was: large multi-site enterprises and PI)
On Mon, 2004-11-29 at 01:11 -0800, Owen DeLong wrote: SNIP How is this any more of a security hole than address-based trust in the first place. As near as I can tell, the 6-to-4 mapping is simply a legitimate form of address spoofing more than what I would call dynamic tunnels. As I understand it, there's some magic IPv6 prefix which since I don't remember what it is, I'll call pfx and your V4 address simply gets mapped to pfx::v4addr and away it goes. :::a.b.c.d., eg :::192.0.2.42, but that is mostly (or entirely?) deprecated. The IPv4 mapped addresses give a range of nice security problems where people forget to close down their IPv6 firewall for this and thus allow IPv4 addresses into the IPv6 world and there where some other reasons. 2002:AB:CD::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends. The Instant IPv6 solution for anyone (Reading Material: RFC3068 RFC3056) Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks. Tada, because you have one single IPv4 address, that is most likely already PI in IPv4, you also have a IPv6 prefix that is PI. Now can everybody stop complaining that the installed IPv4 base already has PI and needs it too for IPv6, use above solution and get it over with. Also if you are multihomed by multiple IPv4 prefixes you can do that with the above too, just RA multiple prefixes on your network. There is one catch-22 though, according to RFC3056 Section 2.2: 8--- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ---8 Because it would introduce a lot of IPv4 routes into the IPv6 routing tables... As at the moment most ISP's don't filter /48 this should not be much of a problem. And folks, don't forget to setup your _own_ 6to4 relay otherwise your connectivity will be terrible. Note also that Windows XP SP1 etc support the above per default after one has typed 'netsh interface ipv6 install', though when behind a NAT it will try Teredo where possible to get out of that bubble. Thus while everybody is waiting for multi6 to solve it, see above ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: A6/DNAME not needed for v6 renumbering [Re: who gets a /32 [Re: IPV6 renumbering painless?]]
--On Sunday, November 28, 2004 11:35 PM -0800 william(at)elan.net [EMAIL PROTECTED] wrote: On Mon, 29 Nov 2004, Pekka Savola wrote: 6. Acknowledgments [...] Some took it on themselves to convince the authors that the concept of network renumbering as a normal or frequent procedure is daft. [Note: check spell error - draft not daft] No, I think daft is the word intended in this case. It is a synonym for incompetent or stupid. I don't happen to agree with it, but, I think that is what was intended. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpZC65kjIC5I.pgp Description: PGP signature
Re: ULA and RIR cost-recovery
On Sat, Nov 27, 2004 at 02:42:55PM +0100, Måns Nilsson wrote: The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Do note that, IIRC, RIPE had this up for discussion some time ago and opted in-session for an one AS -- one global prefix solution which was then overridden because APNIC and ARIN weren't as impressed by that solution. Don't blame Europe ;-) This is interesting, didn't know about that. Can you provide any reference (WG minutes, mailing list archive URL or so)? That'd be a good starting point to re-visit this. Best regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Instant IPv6 PI solution for everyone (Was: BBC does IPv6 ;) (Was: large multi-site enterprises and PI)
:::a.b.c.d., eg :::192.0.2.42, but that is mostly (or entirely?) deprecated. The IPv4 mapped addresses give a range of nice security problems where people forget to close down their IPv6 firewall for this and thus allow IPv4 addresses into the IPv6 world and there where some other reasons. Huh? A badly run firewall is a badly run firewall. 6-to-4 mapping doesn't really change this. So, I don't buy that reason. However, if it's deprecated, then, I guess it's deprecated so no need to go into the other reasons. 2002:AB:CD::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends. OK... Seems a bit messier, and more wasteful of address space, but, if we want to blow away 4 billion /48s to accomodate v4 connectivity, it's not like we'll miss them. Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks. Actually, I think that would be 2002:c000:0200::, but, that's not a /48, it's a /40 (2002:c000:0200:: to 2002:c000:02ff::). One of us must be confused. Tada, because you have one single IPv4 address, that is most likely already PI in IPv4, you also have a IPv6 prefix that is PI. Agreed... That's pretty much what I've been saying (sort of). Now can everybody stop complaining that the installed IPv4 base already has PI and needs it too for IPv6, use above solution and get it over with. Also if you are multihomed by multiple IPv4 prefixes you can do that with the above too, just RA multiple prefixes on your network. I'm perfectly willing to live with that, but, a bunch of people are saying that that's Not deployment of v6, an ugly hack, and, we don't want to keep that alive any longer than we have to. As such, there needs to be some other solution. Also, eventually, there will need to be a solution for organizations that don't have and can't get v4 space but still have the same requirements and meet the same criteria as orgs that can get v4 space today. There is one catch-22 though, according to RFC3056 Section 2.2: 8--- On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain. ---8 Because it would introduce a lot of IPv4 routes into the IPv6 routing tables... Then that isn't really a solution. As at the moment most ISP's don't filter /48 this should not be much of a problem. And folks, don't forget to setup your _own_ 6to4 relay otherwise your connectivity will be terrible. So I don't understand how this ends up actually working. How does the rest of the world know which 6to4 relay to send which IPv4 prefixes to? Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgp0ckNvzzsps.pgp Description: PGP signature
Re: Instant IPv6 PI solution for everyone (Was: BBC does IPv6 ;) (Was: large multi-site enterprises and PI)
On Mon, 2004-11-29 at 01:59 -0800, Owen DeLong wrote:
2002:AB:CD::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4,
quite in use and works fine when the 6to4 relays are close-by for both
ends.
OK... Seems a bit messier, and more wasteful of address space, but, if we
want to blow away 4 billion /48s to accomodate v4 connectivity, it's not
like we'll miss them.
2002::/16 is used as a transition mechanism as such it should go away at
one point, also it would only reach maybe the ~160k IPv4 routes that
already exist in IPv4 space _if_ people would use it and ignore the RFC.
Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then
you thus also have 2002:c000:22a::/48 or larger of course, depending on
your IPv4 space, though a /48 should be enough for most folks.
Actually, I think that would be 2002:c000:0200::, but, that's not a /48,
it's a /40 (2002:c000:0200:: to 2002:c000:02ff::). One of us must be
confused.
Cut and pasto from the above, forgetting to strip the .42 and making it
a /40 indeed.
Tada, because you have one single IPv4 address, that is most likely
already PI in IPv4, you also have a IPv6 prefix that is PI.
Agreed... That's pretty much what I've been saying (sort of).
Now can everybody stop complaining that the installed IPv4 base already
has PI and needs it too for IPv6, use above solution and get it over
with. Also if you are multihomed by multiple IPv4 prefixes you can do
that with the above too, just RA multiple prefixes on your network.
I'm perfectly willing to live with that, but, a bunch of people are saying
that that's Not deployment of v6, an ugly hack, and, we don't want to
keep that alive any longer than we have to. As such, there needs to be
some other solution. Also, eventually, there will need to be a solution
for organizations that don't have and can't get v4 space but still have
the same requirements and meet the same criteria as orgs that can get v4
space today.
It is not real IPv6, only sort of, it is transition, but it can be
abused for some setup like this too ;) There are quite a number of
organizations who simply are using 6to4 addresses because this way they
don't have to go to the RIR's and the prefixes also work behind a NAT.
For that matter, next to ULA, one could use the IPv6 doc prefix
internally, but you will get clashes when joining organizations, it
really is not allowed in the global routing table and effectively you
are stealing address space. Then again, anyone could setup his/her own
registry, it would be totally not Internet related then though ;)
If they can meet the v4 requirement, get some v4 space and use it for
IPv6 too, two flies in one go. Note that many resources (read: google,
cnn, ebay, itunes, kazaa and all your favorite nature sites) are not
available in IPv6 unless using some proxy method anyway, thus you will
need IPv4 at the moment for one reason or another.
There is one catch-22 though, according to RFC3056 Section 2.2:
8---
On its native IPv6 interface, the relay router MUST advertise a route
to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix
on that interface. Routing policy within the native IPv6 routing
domain determines the scope of that advertisement, thereby limiting
the visibility of the relay router in that domain.
---8
Because it would introduce a lot of IPv4 routes into the IPv6 routing
tables...
Then that isn't really a solution.
One can ignore it, it has been done and people keep doing it.
There is also a one should not announce a prefix longer than the
allocation rule, but there are ISP's announcing /64's etc also.
As at the moment most ISP's don't filter /48 this should not be much of
a problem. And folks, don't forget to setup your _own_ 6to4 relay
otherwise your connectivity will be terrible.
So I don't understand how this ends up actually working. How does the
rest of the world know which 6to4 relay to send which IPv4 prefixes to?
See the RFC3056 and more relevant RFC3058.
In short:
* 2001:db8:300:42a:202:55ff:fe2a:580c ('real' ipv6, doc prefix) wants to
send a packet to 2002:c000:22a:202:55ff:fe74:c924
Packet find a route to the router that announces 2002::/16 or longer.
This box knows the 6to4 trick and deducts: 2002:c000:22a::/48 -
192.0.2.42 and send the packet using proto-41 to that IPv4 address. That
machine receives it and forwards it to the real endhost.
* 2002:c000:22a:202:55ff:fe74:c924 replies packet to
2001:db8:300:42a:202:55ff:fe2a:580c
Sends packet to default router, which has a default route to IPv6
prefixes and forwards it.
Greets,
Jeroen
signature.asc
Description: This is a digitally signed message part
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On 29-nov-04, at 7:45, Pekka Savola wrote: I think it's not. The problem will not go away then, it will just take longer before it appears again. The policies have to get stricter, there is no point in 'fixing' your problems by not fixing the issue that created them in the first place. Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. Well, as I have said... having to go to 32 bit AS numbers shows that we've failed at ASN policy-making and failed at creating a scalable multihoming solution. I can see where you're coming from, but I have to disagree. We are now more than halfway through the AS number space. If we extrapolate current consumption we'll be flat out in 5 to 10 years. That is current consumption, which presumably doesn't include any IPv6 multihomers. It also doesn't include a significant amount of latent demand, as there are lots of PI or PI-like block in the routing table without an AS number to go with them. Now reclaiming may put off the inevitable for a few years, but what good does this do? We only need one or two years to implement 32 bit AS numbers, so spending all this effort and time to gain extra time that we don't need (if we start implementing 32 bit AS numbers in the not too distant future) is just a waste of resources. We don't _want_ to have to give out thousands of AS numbers per month or even a year. We'd (well, I at least :) would rather that that the endsites had other means to do multihoming which wouldn't require such global resources. A few thousand AS numbers per year can easily be consumed by new ISPs, and new multihoming mechanisms are probably not going to work with IPv4 or require too many additional addresses to be practical in IPv4, so we'll still see AS numbers be consumed by IPv4 multihomers. ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse. The symptom of the real problem would be _excessive_ AS number consumption. My argument is that _normal_ AS number consumption in itself warrants the upgrade. And there is nothing wrong with treating symptoms, by the way. We really don't want to arrive at a situation where it becomes increasingly difficult to obtain an AS number for those who legitimately need one.
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, Nov 29, 2004 at 11:13:55AM +0100, Iljitsch van Beijnum wrote: We really don't want to arrive at a situation where it becomes increasingly difficult to obtain an AS number for those who legitimately need one. What will be interesting is the definition of legitimate in this context. I'm sure the ISPs will push for rising the monetary bar to regulate their market. See e.g. the inherent anti-competetive billing policy at RIPE where every year, a newcomer has to pay more for allocated/assigned resources. So I guess they will make it just more expensive. This is btw the major flaw I see with Pekka's ASN-derrived PI prefix draft which limits it to the first 32K ASNs. This just makes those ASN golden and thus open to $BIGNUM $$$ on the grey market. Seen that way, it's again just another attempt on make it more expensive (as in real money!) to be able to multihome. Not that I say that this is Pekka's intention. Regards, Daniel -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: Instant IPv6 PI solution for everyone
On 29-nov-04, at 10:59, Owen DeLong wrote: 2002:AB:CD::/48, eg, 192.0.2.42 becomes 2002:c000:22a::/48, 6to4, quite in use and works fine when the 6to4 relays are close-by for both ends. OK... Seems a bit messier, and more wasteful of address space, but, if we want to blow away 4 billion /48s to accomodate v4 connectivity, it's not like we'll miss them. :-) Say, you currently have 192.0.2.0/24 (IPv4 doc prefix, can't use ;) then you thus also have 2002:c000:22a::/48 or larger of course, depending on your IPv4 space, though a /48 should be enough for most folks. Actually, I think that would be 2002:c000:0200::, but, that's not a /48, it's a /40 (2002:c000:0200:: to 2002:c000:02ff::). One of us must be confused. 2002:c000:0200:: is a single IPv6 address. Since last 1 bit is bit 38, it _could_ be the address part for a /40, but the 6to4 prefix for 192.0.2.0 is 2002:c000:0200::/48 = 2002:c000:0200:0:0:0:0:0 (generally written as 2002:c000:0200::) - 2002:c000:0200:::::. Use http://www.bgpexpert.com/ipv6tools/ to save yourself the headache. (-: So I don't understand how this ends up actually working. How does the rest of the world know which 6to4 relay to send which IPv4 prefixes to? There are four cases: 1. regular IPv6 host to regular IPv6 host 2. 6to4 host to 6to4 host 3. 6to4 host to regular IPv6 host 4. regular IPv6 host to 6to4 host Case 1 will work through normal native IPv6 connectivity or configured tunnels. In case 2, the sending host will take the IPv4 address from the destination IPv6 address and slap on an IPv4 header with this address in it so the packet is tunneled directly from host to host without involvement from relays. In case 3 the 6to4 host has an IPv6 default route towards a 6to4 relay so the packet are tunneled towards the relay. There is a well known anycast address for this, which is 2002:c058:6301:something in IPv6 which resolves to 192.88.99.1 in IPv4. In case 4 the packet will be forwarded across the IPv6 internet towards the closest place where a 6to4 gateway announces 2002::/16, and there the gateway performs the 6to4 tunneling. Of course in Windows all of this is much more complex but figuring that out is left as an exercise for the reader... I wouldn't recommend using 6to4 to leverage IPv4 multihoming as an IPv6 multihoming solution though, since the extra detour to find a 6to4 relay may be significant. On the other hand, we could allow 2002:: more specifics in the IPv6 routing table as PI, because filtering those out doesn't immediately break connectivity.
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, Nov 29, 2004 at 08:45:17AM +0200, Pekka Savola wrote: Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse. And this is exactly my point. -- Cliff Albert [EMAIL PROTECTED]
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 2004-11-29 at 12:11 +0100, Cliff Albert wrote: On Mon, Nov 29, 2004 at 08:45:17AM +0200, Pekka Savola wrote: Well, how many AS numbers would you like to give out? 3 in 20 years? 100k a year? A million in a month? 32 bits will then give you 2863 millennia, 429 centuries or 357 years, respectively. ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse. And this is exactly my point. Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. 32bits ASN would thus just mean the end of BGP... Greets, Jeroen signature.asc Description: This is a digitally signed message part
Intelsat Americas-7 satellite lost in space
Geekzone reports that Intelsat, Ltd. said that its Intelsat Americas-7 satellite experienced a sudden and unexpected electrical distribution anomaly that caused the permanent loss of the spacecraft on 28 November 2004 at approximately 2:30 am EST. ref: http://www.geekzone.co.nz/content.asp?contentid=3728 - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: (catching up) (you missed some stuff.) On 2004-11-22, at 18.52, Paul Vixie wrote: (let me put it this way: A6/DNAME was shot down because of complexity, and it was simpler than this.) I am not convinced A6/DNAME would have solved all problems, not even all of the ones you pointed out. the property of a6/dname that wasn't widely understood was its intrinsic multihoming support. the idea was that you could go from N upstreams to N+1 (or N-1) merely by adding/deleting DNAME RRs. so if you wanted to switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect ISP1. the DNAME was expected to be inside your own zone. presto, no lock-in. my theory at the time, bitter and twisted i admit, was that we had too many ISP employees in positions of power inside IETF, and that A6/DNAME was seen as shifting too much power to the endsystems. i've since learned that it was just another case of FID (fear, ignorance, and doubt). naturally this presumed that you could add and delete ipv6 supernets from a LAN, which appeared to be the case at that time, though now with dhcp6 and static addressing making a comeback that's no longer clear. in any case there was a need for a TCP option for endpoint-renumber, which was killed in a committee somewhere (i don't know which one, or where or when.) As someone actively working on maintaining an TCP stack (FreeBSD 5.x and 6.x) I can tell you this is a blessing. Throwing more stuff into TCP is only making matter worse and leads to lots of really buggy and non-working implementations. TCP is pretty complex already and only a few people are really up to it. given that ipv6 is now somewhat deployed without rapid renumbering, and that rapid renumbering could have required logic in both endpoints of every flow, but that there are now a lot of other endpoints without any such logic, it seems to me that MULTI6's only option is to make NAT work, even if you call it site local addressing or even ULA's. (show me.) If you want that, then go for SCTP. And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. -- Andre
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On Sat, Nov 27, 2004 at 06:25:52PM +0100, Iljitsch van Beijnum wrote: While IPv6 is still IP, it's not just IPv4 with bigger addresses. We have 128 bits, so we should make good use of them. One way to do this is to make all subnets and 99% of end-user assignements the same size. Yes, this wastes bits, but the bits are there anyway so not wasting them really doesn't buy you anything at this point. The advantage of I believe this is exactly the thinking that produced the completely pointless /8 and /16 Assignments in IPv4. That is a real waste. All I hear is how this company or that enterprise should qualify for PI space. What I don't hear is what's going to happen when the routing tables grow too large, or how to prevent this. I think just about I said it before and I'll say it again: I believe it is easier to build routers that can handle bigger routing tables than it is to tell large companies to make their IP-Addresses Provider dependent. Or Universities for that matter. Or research facilities. etc. Nils
Re: Make love, not spam....
Fergie (Paul Ferguson) wrote: I'd be curious to hear what NANOG readers thoughts are on this. It would be interesting to see how this fares when faced with a whole lot of router acls that got put in to filter out nachi srs
Re: who gets a /32 [Re: IPV6 renumbering painless?]
And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events.
RE: Best way to get of Bogon list?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters. http://puck.nether.net/~jared/papers/69-paper.html I can rewrite this slightly and post it on slashdot and other places again.. I think it would be useful. The Bogon Team implemented several changes after 69/8 to make change management easier. This included maintain objects at Merit RADB, RIPE NCC RADB, and a way to track via DNS (see the details on http://www.cymru.com/Bogons/index.html). Of course the biggest service CYRMU added to help people with change management was the Bogon Route Server (http://www.cymru.com/BGP/bogon-rs.html). So with all these change management tools done for the operations community, it looks like we still need some policing service. Note from mine and Hank's CIDR Police Experiment, we know that have a list of shame is not effective. The only way it works is if you have people who act as 'police,' use the list of shame, and knock on people's door. 90% of the time, people eventually respond and make the changes. But the impact only remains as long as you have people to go knocking on the doors. -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQas4TL/UEA/xivvmEQIf9gCcCGMjrDGhKvOGMAtXoOhYy/J/CcgAniBM zT0m/7YQhl7z+qjlbqaTNXWs =dA2u -END PGP SIGNATURE-
Re: Public Interest Networks (try UCLP)
Date: Wed, 24 Nov 2004 21:33:24 -0500 From: Gordon Cook [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Public Interest Networks (try UCLP) [ ... ] In Europe Kees neggers with Surfnet6 is doing the same thing. Well, some people over here in .NL might take offense ;) If you're interested, check out http://www.gigaport.nl/info/en/home.jsp Kees Neggers and Boudewijn Nederkoorn are the directors of SURFnet, the party which is basically the educational ISP, where educational should be viewed (nowadays) from K12 to Academic levels ;) SURFnet6 is the next version of the SURFnet network over here in Holland. It is developed through a partnership comprising Universities research institutes etc. That partnership is called GigaPort, and the new effort is called GigaPort NG (Next Generation - we're not that imaginative over here ;D). [ ... ] As I understand it Internet 2 and Dante/Geant in europe are primarily carrier dependent and therefore for the most part onlookers. I believe that Dante/Geant are looking at the model which is at the core of SURFnet5 and SURFnet6. SURFnet5 (the current network) already incorporates a lot of dark-fiber. But it's only used at L3. SURFnet6 will basically make the ISP (SURFnet) also the carrier operating at L2 and semi-L1 (the cable is still rented via IRU). [ ... ] This stuff is not yet well understood outside these research network circles. I believe that it is hugely important and I will be devoting most of my time in december and january to explaining to a broader audience what these folk are doing. Well, apart from high-volume data-sets like LOFAR (check out http://www.lofar.org/), having 30+ 10G paths at your disposal as an ISP would make for interesting cases ;) Look at the DSL oversubscription model. Over here consumer DSL is usually 1/40. Business DSL can be had from 1/20 to 1/1. For an ISP that could allow for a much more flexible differentiation within it's backbone resources. Another much cited possibility was that in case of an overcrowded pipe, connections could be moved to another lightpath; alleviating the pressure of a bandwith-usurping event on the regular path it would travel... (DoS, severe Slashdotting etc.) Or implementing QoS on a L1/L2 level ;) to the world of the best effort public internet it is utterly ALIEN. but my understanding is that it works. NOW. That it is a walled garden and that a big unknown is how long it will remain a walled garden. GigaPort (which resulted in SURFnet5) had a bunch of RD labs from commercial companies on board. I believe they're also on board for GigaPort NG. The usefulness of such a network, or better formulated the results from all the research on / with / about these types of networks is clear from a scientific point. From a ISP World point it is definitely something for the larger carriers. But for all ISP's of Network Operators (getting back to the 'NOG'-part of NANOG) it's definitely worth keeping tabs on. To quote Erik-Jan Bos of SURFnet: The Paradigm Shift is upon us. Kind Regards, JP Velders (working at a GigaPort NG partner ;D)
Re: Make love, not spam....
At 09:39 AM 29/11/2004, Suresh Ramasubramanian wrote: Fergie (Paul Ferguson) wrote: I'd be curious to hear what NANOG readers thoughts are on this. It would be interesting to see how this fares when faced with a whole lot of router acls that got put in to filter out nachi Although I generally like spamcop (one of the sources for determining spamvertised websites) for use with SpamAssassin in scoring, its not the most conservative list e.g. http://www.spamcop.net/w3m?action=blcheckip=198.108.1.41 list Merit as a spam source...) and the accidental listing or potential for abuse could be nasty. What about the case where the spammer gets black listed, traffic starts pounding the rouge site and then the spammer changes the A record to be www.example.com instead. Now all of a sudden www.example.com is being pounded by all those screen savers. ---Mike
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. Unfortunately this sounds like a good target for people to mess up implementations and introduce huge security issues into TCP stacks. (along the theme of the one which started the recent MD5 discussion) But obviously, implemeted properly that would be very useful. The problem then becomes, how an ISP can signal a renumber. Pete
Re: ULA and RIR cost-recovery
In a message written on Wed, Nov 24, 2004 at 11:40:50AM -0800, Tony Hain wrote: The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). I don't think this statement is true on its face. Regardless, if it is true the end users have no one to blame but themselves. The policy process (at least for the past several years) has been an open, public process. You don't have to be a member to show up and make policy. The big ISP's do not dominate the discussions. You need look no further than than those elected for proof. The ARIN Advisory Council is elected by the membership. The members are at http://www.arin.net/about_us/ab_org_ac.html. If you look close you'll see that of the 15 members only 3 work for large ISP's. If you look closely at recent events, you'll see a number of proposals all for small ISP's or for end users. The members passed 2003-15, a relaxation of the rules in Africa to help small ISP's in Africa. The members passed the six months rule, to insure growing ISP's would always have plenty of addresses on hand. The members passed a policy to allow end users to always get a /24 from their upstream if they are multi-homed. The members moved the minimum allocation size from a /20 to a /22 for multi-homed sites. Did we experience some growing pains in the past? Sure. There were technological and political issues in the past that caused some people some pain. However, the process that came out of all of that is fair and open. Almost all the IP Allocation issues in the past 2-3 years have been issues that the small guy faces, and have generally been passed to help them grow. So, I don't know where your statement comes from. When end sites can get a /22 directly from ARIN so they can multi-home, I wonder how we are locking end-sites into their providers address space. Since you can get a /22 with a 50% justification you only have to show a need for 512 IP's to be provider independent. I would love to know how that is an unreasonable barrier. Note, there is also talk of ARIN extending this boundary to a /24. This will be tackled in upcoming meetings. The membership decided we would go to a /22, collect data, and evaluate the impact of moving to a /24. While we only have 6 months of data so far, the current trend does not indicate a land rush, which makes it much more likely the boundary will go to a /24 within the next 12-18 months. So, it seems like in IPv4 land we're making it quite easy for end-sites to get PI space. It also seems like, even with end sites getting PI space, and everyone announcing cutouts of provider blocks we don't have a global routing table that's too large. We're at ~140,000 routes now, and that's with the mess of the swamp and other poor past decisions floating around. To bring us full circle back to IPv6, if we don't do stupid things like create a swamp (which in my mind includes ULA), the table should not be any bigger (by number of routes) than with IPv4, and in fact should be smaller. Many companies today have several IPv4 prefixes in the swamp, non-aggregateable, and all of the proposed IPv6 schemes would prevent that from ever happening. I firmly expect the IPv6 table would be around half the size of the IPv4 table were similar allocation rules to be applied. That's something we can manage, and it gives all the end sites a shot at PI space as well. If we cut the table size in half, even with addresses that are 4x the size, we only double memory requirements. Given where routers are going with memory that doesn't seem like a big issue in the timeframe that we are talking about. There was a time when people were running AGS+'s that needed to filter routes to get them to stay up. There was a time when people ran 7513's with 128M of RAM and they were falling over due to too many routes. There are important lessons to learn from those experiences. Operators and vendors took away a lot of knowledge from those incidents, and started to produce boxes that didn't have those limits. While we need to learn from those mistakes and not repeat them they do not lead to such draconian moves such as NO PI SPACE!, such as those in the IPv6 working group want to push. So, in summary, you state end sites have no alternative but to use their upstreams addresses. Nothing could be further from the truth with IPv4, with the RIR's currently bending over backwards to make it easier for small sites to be provider independent. At the same time you want to push an IPv6 proposal that specifically excludes all PI space. Hipocracy at its best. The IPv6 working
FW: Make love, not spam....
Scratch that... Yes, the A record. You are right. I need coffee or something... :-) -Original Message- From: Miller, Mark Sent: Monday, November 29, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: RE: Make love, not spam Not the A, the PTR... But yes, that could be a nasty retaliation by spammers with control of their DNS. I would hope, however, that the screen saver's target would be an IP address instead of a FQ mnemonic hostname. From the article, I understand that Lycos will be manually watching the list of targets and pushing updates to the users. Although I have traditionally been in favor of low bandwidth fixes, this kind of appeals to my sense of poetic justice. -mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Monday, November 29, 2004 9:12 AM To: Suresh Ramasubramanian Cc: [EMAIL PROTECTED] Subject: Re: Make love, not spam ... What about the case where the spammer gets black listed, traffic starts pounding the rouge site and then the spammer changes the A record to be www.example.com instead. Now all of a sudden www.example.com is being pounded by all those screen savers. ---Mike
RE: Make love, not spam....
Not the A, the PTR... But yes, that could be a nasty retaliation by spammers with control of their DNS. I would hope, however, that the screen saver's target would be an IP address instead of a FQ mnemonic hostname. From the article, I understand that Lycos will be manually watching the list of targets and pushing updates to the users. Although I have traditionally been in favor of low bandwidth fixes, this kind of appeals to my sense of poetic justice. -mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: Monday, November 29, 2004 9:12 AM To: Suresh Ramasubramanian Cc: [EMAIL PROTECTED] Subject: Re: Make love, not spam ... What about the case where the spammer gets black listed, traffic starts pounding the rouge site and then the spammer changes the A record to be www.example.com instead. Now all of a sudden www.example.com is being pounded by all those screen savers. ---Mike
RE: Make love, not spam....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Re: Make love, not spam The BBC also has an article this morning about this: http://news.bbc.co.uk/2/hi/technology/4051553.stm - ferg -- Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: Techdirt has an article this morning that discusses how Lycos Europe is encouraging their users to run a screensaver that constantly pings servers suspected to be used by spammers and also suggests that In other words, it's a distributed denial of service attack against spammers by Lycos. The Techdirt article referenced is on Heise Online: http://www.heise.de/english/newsticker/news/53697 I'd be curious to hear what NANOG readers thoughts are on this. Techdirt is located at http://www.techdirt.com/ - ferg It's a DDOS. The risk of collateral damage is high. I won't discuss the RBL aspect of it because it can't be legitimized past the first sentence. -M
Re: Make love, not spam....
On Mon, Nov 29, 2004 at 02:14:01PM +, Fergie (Paul Ferguson) wrote: Techdirt has an article this morning that discusses how Lycos Europe is encouraging their users to run a screensaver that constantly pings servers suspected to be used by spammers and also suggests that In other words, it's a distributed denial of service attack against spammers by Lycos. Already noted as unbelievably stupid and dissected on Spam-L, but: getting into a bandwidth contest with spammers is a guaranteed loss, as they have an [essentially] infinite amount available to them for free. Apparently Lycos is unaware of zombies (including those hosting web sites), HTTP redirectors, rapidly-updating DNS, throwaway domains, and other facts of life in the spam sewer. ---Rsk
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. Have you ever worked in luser techsupport? I did for the fun of it. It's not pretty. And that's why IPv6 is not going to fly. It's broken by design in so many places that it's impossible to explain it by phone to Joe Average (with IQ100, I'm not even talking about the average US high school dropout flipping burger in your favorite fast food chain). -- Andre
Re: Make love, not spam....
Rich Kulawiec [EMAIL PROTECTED] wrote: Already noted as unbelievably stupid and dissected on Spam-L, I'm inclined to agree... but: getting into a bandwidth contest with spammers is a guaranteed loss, as they have an [essentially] infinite amount available to them for free. Apparently Lycos is unaware of zombies (including those hosting web sites), HTTP redirectors, rapidly-updating DNS, throwaway domains, and other facts of life in the spam sewer. ... but this screensaver means that Lycos *also* have a botnet available to them. -- The advice given me about Maglites is to hold it out sideways from yourself but at shoulder height, this makes the opponent think you are standing 3 foot to one side of reality. - Rob Adams in the Monastery
Re: Make love, not spam....
In message [EMAIL PROTECTED], Peter Corlett writes: Rich Kulawiec [EMAIL PROTECTED] wrote: Already noted as unbelievably stupid and dissected on Spam-L, I'm inclined to agree... but: getting into a bandwidth contest with spammers is a guaranteed loss, as they have an [essentially] infinite amount available to them for free. Apparently Lycos is unaware of zombies (including those hosting web sites), HTTP redirectors, rapidly-updating DNS, throwaway domains, and other facts of life in the spam sewer. ... but this screensaver means that Lycos *also* have a botnet available to them. Yah -- imagine what happens if Lycos' control machine gets hacked... --Steve Bellovin, http://www.research.att.com/~smb
RE: Make love, not spam....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 11:00 AM To: [EMAIL PROTECTED] Subject: Re: Make love, not spam Rich Kulawiec [EMAIL PROTECTED] wrote: Already noted as unbelievably stupid and dissected on Spam-L, I'm inclined to agree... but: getting into a bandwidth contest with spammers is a guaranteed loss, as they have an [essentially] infinite amount available to them for free. Apparently Lycos is unaware of zombies (including those hosting web sites), HTTP redirectors, rapidly-updating DNS, throwaway domains, and other facts of life in the spam sewer. ... but this screensaver means that Lycos *also* have a botnet available to them. That means they are subject to the same sanctions as a botnet. This isn't a new issue to the operator community. We have a consistent opinion of this type of actvity going as far back as Green Card Lawyers and Sanford Wallace/Cyberpromo. The risks are too high for this to be anything but a publicity stunt. I can't read any German other than bier. Is the utility up there? I'd love to take a look at it. -M
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, 2004-11-29 at 16:58 +0100, Andre Oppermann wrote: Paul Vixie wrote: And please don't add any more layering violations. It makes implementors life painful and kills any architectual cleaniess in operating systems. i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. Full Ack. IMHO SCTP and HIP are the way to go at the moment. Both support both IPv4 and IPv6 btw. New technologies are required to solve old problems, which is not that odd now is it ? :) SNIP Have you ever worked in luser techsupport? I did for the fun of it. Most people would refuse it :) It's not pretty. And that's why IPv6 is not going to fly. It's broken by design in so many places that it's impossible to explain it by phone to Joe Average (with IQ100, I'm not even talking about the average US high school dropout flipping burger in your favorite fast food chain). I am not flipping burgers, but did once work in a cheese factory (Gouda cheese anyone? :), I am wondering how you could keep this piggie from flying though. Could you elaborate or point me to a doc where you most likely already did? Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 2004-11-29 at 08:35 -0800, Owen DeLong wrote: Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. Only if EVERY ASN were allocated and active. *BUZZZ* ASN's are a globally unique resource, you not seeing it does not mean that it is not in use. For that matter anything from a prefix to a ASN that any of the RIR's hands out does not have to show up on the public internet, it could even be used by a single company internally, just like RFC1918 prefixes, or on a VPN etc. SNIP 32bits ASN would thus just mean the end of BGP... ULA will do much more damage than 32 bit ASNs. Which damage might that be? The prefixes are not supposed to be put in the global routing table and even if people did, with 16bit ASN you only allow 65536 routes, which is less than current IPv4... oops let's disable repeat mode... also see my nice comment on 6to4, that is more useful if you want a globally unique /48 for sure, that is if you really 'own' the IPv4 space of that prefix. For that matter Ford and some other /8's are only 2002:13::/24, which is the same size as the 6bone space that was handed out early on. Do also realize that if this all becomes a peep-up and the RIR's (or actually IANA) runs out of space that they can try all over 7 more times, *that* is how much IPv6 space is available. Greets, Jeroen signature.asc Description: This is a digitally signed message part
RE: Make love, not spam....
It's a DDOS. The risk of collateral damage is high. I won't discuss the RBL aspect of it because it can't be legitimized past the first sentence. -M From what limited information is available in the articles, it doesn't sound that way. It's not really a DDoS attack, but more of a distributed web surfing bot. The point isn't to generate a ton of false requests to overload the web servers, the point is to send a controlled amount of requests to cause the target websites to generate a lot of http traffic. One that's not meant to knock the sites off line, but just consume their bandwidth through real http use. *IF* their screen saver is written correctly, the sites should never go down, but at worst, just slow down. That's a big *IF*. I understand this as more of a Distributed Consumption of Service attack. (Is the acronym DCoS used yet?) Real requests, downloading real data, to real computers. A lot of them. The same effect could be had by having those websites being requested by the Lycos mail users by clicking on a link to their web site, except that would be more prone to cause operational problems with target sites being overloaded. Also, if the target web servers are set up right, they should protect themselves in all the normal ways an http server under load does. If you still think it's a DDoS, then they're only as guilty as Slashdot. The big difference between Lycos Europe, and a script kiddie with zombies is that Lycos is mature enough to use restraint and not knock down websites with brute force. They're attempting to use the politically correct grown up way to attack someone: economics. How is giving the spammers what they want (real web site traffic) an attack? That doesn't even qualify! Would a huge advertising effort to get users to visit every spammer web site they get, and click reload a few times also qualify as an attack? Remember: I'm assuming a properly written client. -Jerry
Re: who gets a /32 [Re: IPV6 renumbering painless?]
i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. Unfortunately this sounds like a good target for people to mess up implementations and introduce huge security issues into TCP stacks. (along the theme of the one which started the recent MD5 discussion) of course. and if endpoint-renumber were possible, it would also be used in load-balancing handoffs (similar to the thing that goes under the trade name 3TCP), clustering, failover... plus things we havn't even thought of yet. of course there would be security problems, and just knowing the current sequence numbers wouldn't be enough proof, and there's an interesting question of whether both directions would have to renumber at the same time. this is a nec'y enabling technology for so many things that calling it a layering violation is outrageous. But obviously, implemeted properly that would be very useful. The problem then becomes, how an ISP can signal a renumber. as it turns out, there is no silver bullet -- no single thing that if we could just to that then we'd be done, roll credits. same thing for spam, as it turns out. it's going to take a lot of little things, which amounts to a lot of hard work by a lot of people, some of whom won't even know eachother or about eachother's work, to get ipng done. real time tcp session renumberability is on the list, but it's a big list. what i DON'T like is having the future of ipng decided in star chambers where things like A6/DNAME can be killed without transparency or accountability.
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 29 Nov 2004, Pekka Savola wrote: ASN exhaustion is IMHO just a symptom of the real problem. Enlarging the ASN space does not cure the disease, just makes it worse. Uhm... because you DON'T want customers to multihome and do so with multiple providers for their own safety?
Re: ULA and RIR cost-recovery
I don't think this statement is true on its face. Regardless, if it is true the end users have no one to blame but themselves. Agreed... Although I think ARIN could do better outreach to the broader community. I think there are perceptions out there that differ from reality, and, blaming people for their perceptions is never effective at bringing them into the process. What is needed is outreach and education. The policy process (at least for the past several years) has been an open, public process. You don't have to be a member to show up and make policy. The big ISP's do not dominate the discussions. This is absolutely true. I can vouch for it from the meetings I have attended in the last two years, and, I will say that I have watched ARIN become progressively LESS ISP centric. So, I don't know where your statement comes from. When end sites can get a /22 directly from ARIN so they can multi-home, I wonder how we are locking end-sites into their providers address space. Since you can get a /22 with a 50% justification you only have to show a need for 512 IP's to be provider independent. I would love to know how that is an unreasonable barrier. Perhaps it is because they can't get any v6 allocation from ARIN unless they claim they want to go into the LIR business and not be an end site and propose a plan to assign addresses to 200 additional organizations. So, it seems like in IPv4 land we're making it quite easy for end-sites to get PI space. It also seems like, even with end sites getting PI space, and everyone announcing cutouts of provider blocks we don't have a global routing table that's too large. We're at ~140,000 routes now, and that's with the mess of the swamp and other poor past decisions floating around. I will point out, however, that if the boundary moves to /24, there's not much difference between the allocation policy of the past that created the swamp and current allocation policy. I'm not saying I think this is a bad thing (I don't). I think that CIDR was important in its day, and, I think it is important today. However, I think that now, CIDR is only important in so far as it promotes aggregation where it makes sense. Deaggregating where it matters is a valid and necessary thing. # 3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. They have ahold of it now. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpDS56xVphOD.pgp Description: PGP signature
RE: Make love, not spam....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: RE: Make love, not spam [ SNIP ] The big difference between Lycos Europe, and a script kiddie with zombies is that Lycos is mature enough to use restraint and not knock down websites with brute force. They're attempting to use the politically correct grown up way to attack someone: economics. I didn't know there was a politically correct way to create a BotMonster and rule the Internet by emminent domain. -M
Re: Make love, not spam....
For residential users on cable-modem, the plan will deplete a scarce resource: upstream transmit opportunities. The DOCSIS MAC layer imposes an upper limit on the quantity of upstream transmissions (essentially PPS limitation, unless concatenation is employed, and concatenation is probably moot if standard ping with 1-second minimum transmit intervals is the upstream payload). If the load actually causes a problem in upstream operation, then folks using TCP for downstream service (e.g. surfing) will see their throughput cut. Regardless, the cable companies will probably try to disable this service, so they can avoid the financial impact of improving their infrastructure. They need to conserve the money in order to launch new unsolicited bids for Disney... At 09:14 AM 11/29/2004, you wrote: Techdirt has an article this morning that discusses how Lycos Europe is encouraging their users to run a screensaver that constantly pings servers suspected to be used by spammers and also suggests that In other words, it's a distributed denial of service attack against spammers by Lycos. The Techdirt article referenced is on Heise Online: http://www.heise.de/english/newsticker/news/53697 I'd be curious to hear what NANOG readers thoughts are on this. Techdirt is located at http://www.techdirt.com/ - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
--On Monday, November 29, 2004 5:41 PM +0100 Jeroen Massar [EMAIL PROTECTED] wrote: On Mon, 2004-11-29 at 08:35 -0800, Owen DeLong wrote: Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. Only if EVERY ASN were allocated and active. *BUZZZ* ASN's are a globally unique resource, you not seeing it does not mean that it is not in use. For that matter anything from a prefix to a ASN that any of the RIR's hands out does not have to show up on the public internet, it could even be used by a single company internally, just like RFC1918 prefixes, or on a VPN etc. SNIP Duh... You're making my point for me. There won't be 2^32 routes from 1 route per ASN unless ALL 2^32 ASNs are assigned. Further, lots of ASNs get used for things that don't put routes in the global table. (If I can't see it, it's not in the global table). Which damage might that be? The prefixes are not supposed to be put in the global routing table and even if people did, with 16bit ASN you only allow 65536 routes, which is less than current IPv4... oops let's disable repeat mode... also see my nice comment on 6to4, that is more useful if you want a globally unique /48 for sure, that is if you really 'own' the IPv4 space of that prefix. But, that should becomes a purely artificial barrier which will be eliminated by market economics. Finally, with the limitations of 16 bit ASNs (which we will surpass regardless of reclamation), we won't likely end up with 1 prefix per ASN. The prefixes will be out there regardless of the number of ASNs that end up originating them. For that matter Ford and some other /8's are only 2002:13::/24, which is the same size as the 6bone space that was handed out early on. Do also realize that if this all becomes a peep-up and the RIR's (or actually IANA) runs out of space that they can try all over 7 more times, *that* is how much IPv6 space is available. And? Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpPGMlJxZm2K.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. as i told someone in private e-mail earlier this morning, tcp's notion of a flow-identifying tuple includes network addresses, and so, the ability to change these on the fly will absolutely affect tcp. when you bind a session to an address, as tcp currently does, you cause the community to waste ipv4 /32's or ipv6 /128's as loopback aliases just to have something they can virtualize, manage, move around, play with. let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. see above. we do that now. however, it limits the scope of mobility to same autonomous system and often same campus so it's not useful for any wide area purpose. the internet's target area is very wide indeed. Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. where i come from that's called the fallacy of the straw man and is not a well respected technique for debate or discussion. the process i'm thinking of would take years to reach deployability, and more years to reach wide scale deployment. KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. i guess i was expecting smart people to write kernels and lusers to just run working code. this seems to work for apple and suse and redhat and sun and microsoft. or is this another straw man thing? certainly my kids think their mac/os/x machine is as easy to use as a telephone, and if you asked them how the routing table worked they wouldn't care. -- Paul Vixie
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 2004-11-29 at 09:58 -0800, Owen DeLong wrote: --On Monday, November 29, 2004 5:41 PM +0100 Jeroen Massar [EMAIL PROTECTED] wrote: On Mon, 2004-11-29 at 08:35 -0800, Owen DeLong wrote: Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. Only if EVERY ASN were allocated and active. *BUZZZ* ASN's are a globally unique resource, you not seeing it does not mean that it is not in use. For that matter anything from a prefix to a ASN that any of the RIR's hands out does not have to show up on the public internet, it could even be used by a single company internally, just like RFC1918 prefixes, or on a VPN etc. SNIP Duh... You're making my point for me. There won't be 2^32 routes from 1 route per ASN unless ALL 2^32 ASNs are assigned. You should indeed stop the droolduh part as that is exactly not what I wrote ;) Further, lots of ASNs get used for things that don't put routes in the global table. (If I can't see it, it's not in the global table). Which damage might that be? The prefixes are not supposed to be put in the global routing table and even if people did, with 16bit ASN you only allow 65536 routes, which is less than current IPv4... oops let's disable repeat mode... also see my nice comment on 6to4, that is more useful if you want a globally unique /48 for sure, that is if you really 'own' the IPv4 space of that prefix. But, that should becomes a purely artificial barrier which will be eliminated by market economics. Finally, with the limitations of 16 bit ASNs (which we will surpass regardless of reclamation), we won't likely end up with 1 prefix per ASN. The prefixes will be out there regardless of the number of ASNs that end up originating them. Which should might that be, you most likely cut it. For that matter Ford and some other /8's are only 2002:13::/24, which is the same size as the 6bone space that was handed out early on. Do also realize that if this all becomes a peep-up and the RIR's (or actually IANA) runs out of space that they can try all over 7 more times, *that* is how much IPv6 space is available. And? Stop the duh and read again ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part
RE: Make love, not spam....
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 12:45 PM
To: [EMAIL PROTECTED]
Subject: RE: Make love, not spam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 11:54 AM
To: [EMAIL PROTECTED]
Subject: RE: Make love, not spam
[ SNIP ]
The big difference between Lycos Europe, and a script kiddie with
zombies is that Lycos is mature enough to use restraint
and not knock
down websites with brute force. They're attempting to use the
politically correct grown up way to attack someone: economics.
I didn't know there was a politically correct way to create a
BotMonster and rule the Internet by emminent domain.
-M
Yeah, that's exactly what they're doing! It's a plot to TAKE OVER
THE WORLD. You figured it out!
It's about giving the spammers what they want: More traffic to their
websites. How can it be wrong when they send out 1 million emails
that all say click on this link and 1 million computers actually
click the link? Who's in the wrong there?
Besides: rule the Internet by emminent domain. Isn't' that
Verisign's job?
For all who are interested, the controller appears to live at
230.136.241.83
Interesting. I started it up and it immediately attacked
Yahoo/Akamai: premium3.geo.yahoo.akadns.net
Then it went and attacked a slew of other sites and had nothing
but errors coming back.
It also appears to attack sequentially from the top each time the dll
loads. They've miscalculated the speed at which spammers relocate.
RBL's aren't realtime. Spammers are near real time.
makeLOVEnotSPAM(bhGBX5Und`p\|kr3D4=RfF#o:4F'^!?)TC:[EMAIL
PROTECTED])hmtw!g;E6=uaKe
.a*iNb/makeLOVEnotSPAM
/D4=RfF#o:4F'^!?)TC:[EMAIL
PROTECTED])hmtw!g;E6=uaKe.a*iNb/makeLOVEnotSPAM/makeLOV
EnotSPAM.!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE403 Forbidden/TITLE
/HEADBODY
H1Forbidden/H1
You don't have permission to access /
on this server.P
/BODY/HTML
makeLOVEnotSPAM@1w0tu|aG/)*kzM*Lquot;8xbj{GNy/ZZA\5zg('PIM`6MD$+VTa8fh
M3lQvAWZ}iv/makeLOVEnotSPAM
/y/ZZA\5zg('PIM`6MD$+VTa8fhM3lQvAWZ}iv/makeLOVEnotSPAM/makeLOVEnotSPAM
.!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
HTMLHEAD
TITLE501 Method Not Implemented/TITLE
/HEADBODY
H1Method Not Implemented/H1
lt;makeLOVEnotSPAMgt;@1w0tu|aG/)*kzM*Lamp;quot;8xbj{GNlt;y/ZZA\5zg('PIM`
6MD$+Vamp;Ta8fhM3lQvAWZ}ivlt;/makeLOVEnotSPAMgt; to / not supported.P
Invalid method in request
lt;makeLOVEnotSPAMgt;@1w0tu|aG/)*kzM*Lamp;quot;8xbj{GNlt;y/ZZA\\5zg('PIM
`6MD$+Vamp;Ta8f\hM3lQvAWZ}ivlt;/makeLOVEnotSPAMgt;P
/BODY/HTML
-Jerry
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface?
Re: ULA and RIR cost-recovery
In a message written on Mon, Nov 29, 2004 at 09:09:08AM -0800, Owen DeLong wrote: I will point out, however, that if the boundary moves to /24, there's not much difference between the allocation policy of the past that created the swamp and current allocation policy. I'm not saying I think this is a bad thing (I don't). I think that CIDR was important in its day, and, I think it is important today. However, I think that now, CIDR is only important in so far as it promotes aggregation where it makes sense. Deaggregating where it matters is a valid and necessary thing. I think Owen is well aware of the differences, but for the list's archive... I think a major difference is that the current policy requires you to be multihomed. Another difference is that you have to pay a maintenance fee. There are a lot of blocks in the swamp where end sites received space because they could, and the lack of fees was a motivator. There are also a lot of blocks given out to entities that were then, and are now single homed. It's also the case that the industry as a whole has progressed. With ISP's having good processes to give the customers the space they need, and with technologies like DHCP and the like it is much easier for many end users to live with IP's from their upstream, even if they change once in a while. Couple that with a (very small) amount of paperwork and fees and you do cut out many of the frivolous uses. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpEox03tePp9.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. Owen --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface? -- If it wasn't crypto-signed, it probably didn't come from me. pgpb0oDVdCiSH.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 13:36, Owen DeLong wrote: ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. If the old address is removed, then TCP sessions established with the old address as an endpoint will break; hence plumbing TCP sessions to loopback addresses is not a solution to TCP survival over renumbering attempts. That was my point. --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface?
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Right... Well... The point of the loopback thingy was that you don't renumber the loopback. The address assigned to the loopback is used as the session endpoint identifier, while, the address assigned to the network interface is used as the routing endpoint identifier. So, BGP takes care of deailing with the consequences of renumbering the routing endpoint identifier, and, lo0 remains a consistent session endpoint identifier. This will not scale, but, it does work (e.g. anycast). Owen --On Monday, November 29, 2004 1:39 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 13:36, Owen DeLong wrote: ifconfig le0:1 newaddr netmask newmask YMMV depending on your operating system. If the old address is removed, then TCP sessions established with the old address as an endpoint will break; hence plumbing TCP sessions to loopback addresses is not a solution to TCP survival over renumbering attempts. That was my point. --On Monday, November 29, 2004 1:28 PM -0500 Joe Abley [EMAIL PROTECTED] wrote: On 29 Nov 2004, at 10:58, Andre Oppermann wrote: You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. So how do you renumber the loopback interface? -- If it wasn't crypto-signed, it probably didn't come from me. pgpTF6njmCshK.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. But doesn't HIP fix that in a way that is already specified and it just needs to be pushed forward if the community feels it fixes the next generation TCP issue? Pete
Re: Best way to get of Bogon list?
On Sat, 27 Nov 2004 18:03:28 +0100, Iljitsch van Beijnum said: To some extent this is correct, but these users really need to learn to effectively protect themselves. In the long term atleast. Never teach a pig to sing: it wastes your time and annoys the pig. I've always wondered whether said pig needs pilot training when it gets the RFC1925 rocket packs attached. The lack of adequate pilot and flight safety training for the victims(*) is a deployment issue for any reasonable firewall/security scheme - either it really *does* have to be victim is along for the ride, or we're going to be sitting in the control tower talking them through the landing (*) victims - sometimes the users, sometimes the ISP pgpCg4RHoz0TB.pgp Description: PGP signature
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On 29 Nov 2004, at 13:50, Owen DeLong wrote: Right... Well... The point of the loopback thingy was that you don't renumber the loopback. This is not any kind of answer to the problem of TCP session survivability across renumbering events; it's an answer to the non-problem of TCP session survivability when there are no renumbering events. [how to suck eggs] Joe
Re: ULA and RIR cost-recovery
On Mon, 29 Nov 2004, Leo Bicknell wrote: #1 Set aside a block for local use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes. FWIW, site-locals were dropped (among others) due to concerns about sufficient guarantee of uniqueness. ULA started by having only a local generation mechanism, no central allocation at all. Would that allay your concerns? #3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. I think we all know there's going to be _some_ form of PI space. Whether that's realized by making the policies weaker, by end-sites lying in their address applications, or end-sites providing interesting interpretation for other organizations, or a number of different mechanisms, the fact is that some form of PI addressing is going to be there. The question just is, what kind, how much of it, and to whom it's available. #4 Drop the absolutely stupid notion that one size fits all. A /32 for everyone makes no sense. VLSM was a good idea. Below. #5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be fixed. The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis. The history also tells us that being too stingy when there is no need to be stingy will result in useless fragmentation of the addressing, and therefore results in the fragmentation of routing advertisements. A minimum of /32 per ISP IMHO makes very much sense, because that's so small amount that we aren't going to run out. On the other hand, I agree that one size does not fit all, and larger blocks will also need to be provided. Oops, they already have! -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Make love, not spam....
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hannigan, Martin Sent: Monday, November 29, 2004 1:16 PM To: [EMAIL PROTECTED] Subject: RE: Make love, not spam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 12:45 PM To: [EMAIL PROTECTED] Subject: RE: Make love, not spam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, November 29, 2004 11:54 AM To: [EMAIL PROTECTED] Subject: RE: Make love, not spam [ SNIP ] The big difference between Lycos Europe, and a script kiddie with zombies is that Lycos is mature enough to use restraint and not knock down websites with brute force. They're attempting to use the politically correct grown up way to attack someone: economics. I didn't know there was a politically correct way to create a BotMonster and rule the Internet by emminent domain. -M Yeah, that's exactly what they're doing! It's a plot to TAKE OVER THE WORLD. You figured it out! It's about giving the spammers what they want: More traffic to their websites. How can it be wrong when they send out 1 million emails that all say click on this link and 1 million computers actually click the link? Who's in the wrong there? Besides: rule the Internet by emminent domain. Isn't' that Verisign's job? For all who are interested, the controller appears to live at 230.136.241.83 That would be the in-addr folks. 83.241.136.230 -M
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 29 Nov 2004, Owen DeLong wrote: Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. Only if EVERY ASN were allocated and active. You and I both know this doesn't begin to approach reality. Slightly more than half of current ASNs are actually in the routing table. The ASN issuance rate is not likely to go up simply because we go to 32 bit ASNs. Probably we are really talking about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more convenient boundary for lots of code implementations and lots of hardware, so, 32 bits is the chosen number for the sake of simplicity. Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be no need (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Make love, not spam....
- Original Message - From: Miller, Mark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 29, 2004 10:27 AM Subject: RE: Make love, not spam Although I have traditionally been in favor of low bandwidth fixes, this kind of appeals to my sense of poetic justice. spammer buys hosting account, pays with fraudulent credit card, spams, provider gets ddos'ed and ends up paying for all the bandwidth because you can't well charge some unsuspecting grandma in alabama for it. i don't like this kind of justice. -p --- paul galynin
Re: who gets a /32 [Re: IPV6 renumbering painless?]
Paul Vixie wrote: i have long wished for and sometimes needed a way to renumber a host w/o killing or restarting its active tcp flows. this isn't a layering violation. tcp should be able to know about endpoint-renumber events. This is a layering violation and has endless security implications. as i told someone in private e-mail earlier this morning, tcp's notion of a flow-identifying tuple includes network addresses, and so, the ability to change these on the fly will absolutely affect tcp. when you bind a session to an address, as tcp currently does, you cause the community to waste ipv4 /32's or ipv6 /128's as loopback aliases just to have something they can virtualize, manage, move around, play with. So? let me put that another way, in case it's not clear enough as stated: tcp's existing reference to network addresses are a layering violation, and so anything we do to improve the situation will also be a layering violation, but what of it? deciding against making tcp less pure is not going to meet the needs and demands of the community -- and those needs and demands WILL be met, and probably in even less pure ways. google for a product or feature called 3TCP to see what i mean. Instead of hacking the nice and working TCP we have now you should move on to greener grass and use SCTP instead. It does what you want, at least in the specification. I don't know how many implementors have managed to code it properly. You can solve the renumber thingie by having all TCP connecting to/from an official IP on the loopback interface. Then the routing code could do its work and route the packets through some some other or renumbered interface. see above. we do that now. however, it limits the scope of mobility to same autonomous system and often same campus so it's not useful for any wide area purpose. the internet's target area is very wide indeed. Yea, but what is a surviving TCP good if you put your laptop to sleep and wake it up somewhere else? It can't pre-announce the next IP address it will use. Instead at the new location it will have to convince somehow the remote host that he is he indeed. No way without cryptography. IPSEC will break too. Oops, the remote end switched IP addresses too and you are lost. The question is whether renumbering while moving active TCP sessions to the new IP address is a problem at all other than a nice-to-have dream of 'propellerhead' Paul? ;) And the other, more serious, question is whether IP addresses are something that you only use temporarily or permanently? Try to get your TCP automatic renumbering stuff implemented from spec by five different people in five different codebases in a compatible way within two month time... No way. where i come from that's called the fallacy of the straw man and is not a well respected technique for debate or discussion. the process i'm thinking of would take years to reach deployability, and more years to reach wide scale deployment. Nonetheless having a simple and easily implementable spec is key to success and compatibility. I know you can write, hmm, interesting and complex code... KISS KISS KISS KISS !!! Why is the telephone (POTS/Mobile) so popular? Easy answer: Even the most stupid person on earth capable of correctly reading digits is able to punch in a number. As simple as it gets. i guess i was expecting smart people to write kernels and lusers to just run working code. this seems to work for apple and suse and redhat and sun and microsoft. or is this another straw man thing? certainly my kids think their mac/os/x machine is as easy to use as a telephone, and if you asked them how the routing table worked they wouldn't care. No, they don't mind just using the computer because you set up the internet connection. Have them call your favorite ADSL provider and order an ADSL line and then have them set up some DSLWLAN thingie plus a printer connected via ethernet. And using the Apple offerings is cheating, take the average cheap windooze stuff. Because all this worked so well they want to run their own webserver on their computer and others from the internet should be able to connect... You see? -- Andre
Re: ULA and RIR cost-recovery
--On Monday, November 29, 2004 21:35 +0200 Pekka Savola [EMAIL PROTECTED] wrote: On Mon, 29 Nov 2004, Leo Bicknell wrote: # 1 Set aside a block for local use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes. FWIW, site-locals were dropped (among others) due to concerns about sufficient guarantee of uniqueness. ULA started by having only a local generation mechanism, no central allocation at all. Would that allay your concerns? No. In that case, it makes things even worse because it creates the promise and illusion of uniqueness without actually delivering uniqueness. Worst of both worlds... Bigger address-waste (not that it really matters), non-uniqueness, and the expectation of uniqueness. To some small extent, this might (_MIGHT_) reduce the pressure on ISPs to route these prefixes, but, that is the only improvement over a central registry. # 3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. I think we all know there's going to be _some_ form of PI space. Whether that's realized by making the policies weaker, by end-sites lying in their address applications, or end-sites providing interesting interpretation for other organizations, or a number of different mechanisms, the fact is that some form of PI addressing is going to be there. The question just is, what kind, how much of it, and to whom it's available. Ideally, I'd like to see us address this up front in a clear and open manner instead of using nudge-nudge and wink-wink encouragement to make creative applications for space. The former can be done fairly. The latter insures that the only organizations that have any sort of advantage are the ones willing to lie to get it. This tends to happen by accident often enough. Creating the situation deliberately is, IMHO, absurd. # 5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be fixed. The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis. The history also tells us that being too stingy when there is no need to be stingy will result in useless fragmentation of the addressing, and therefore results in the fragmentation of routing advertisements. Actually, that fragmentation was primarily the result of being insufficiently stingy early on. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgp0TDYA197uE.pgp Description: PGP signature
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be no need (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. People might argue it, but, I am not convinced they would succeed in that argument. If you want an ASN for something other than connecting to the internet for multihoming or other unique routing policy, then, make one up. Doesn't matter whether it's 16 or 32 bits. Also, there are a whole slew of private ASNs reserved for just such a purpose if you want to retain compatibility with existing ASN numbering. As such, I think that argument becomes specious in general. OTOH, I have a SOHO with a legitimate ASN and protable IPv4 space. Who are you to tell me that it isn't legitimate for me to use it in this manner? Why do you get to decide that my SOHO is less worthy of PI space and the ability to reliably multihome just because my organization is small? Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. So we return to the need to separate the end-point identifier from the routing identifier and come up with a routing scheme that allows routing assignments to be dynamic and flexible independent of the layer 3/4 endpoint identifier. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. No, it's not. It's better to expand to 32 bit ASNs now and realize that this is really just the most convenient way to get the necessary 20 bit ASNs that will happen whether we reclaim or not. Think about the difference between coding 20 bit ASNs and 32 bit ASNs and then ask yourself is there really any legitimate technical reason to code 20 bits instead of 32? Obviuosly, you don't subscribe to the premise that regardless of reclamation, we will run out of 16 bit ASNs soon enough. That's fine, you may be right. However, from where I'm sitting, I think we will. I also think that the $500 up front cost and $100 annual renewal associated with an ASN are decent incentive for people not to get them unless they have a legitimate use for them. Private ASNs are too easy and cost nothing. Owen pgpxYsytkYQNV.pgp Description: PGP signature
Re: Make love, not spam....
I agree and I'm surprised you even mentioned the wordt justice...since when is retaliating bad practices with more bad practises that are hardly likely to take out the real target considered a good idea..? Erik Paul G wrote: spammer buys hosting account, pays with fraudulent credit card, spams,provider gets ddos'ed and ends up paying for all the bandwidth because youcan't well charge some unsuspecting grandma in alabama for it. i don't likethis kind of justice. --- paul galynin
Re: Make love, not spam....
- Original Message - From: Erik Haagsman [EMAIL PROTECTED] To: Paul G [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 29, 2004 4:30 PM Subject: Re: Make love, not spam I agree and I'm surprised you even mentioned the wordt justice...since when is retaliating bad practices with more bad practises that are hardly likely to take out the real target considered a good idea..? 'justice' was mentioned in the message i quoted. it appears i was not remiss - i got an email from a guy running a small town isp telling me, essentially, that: 1. if i get hit with cc fraud, it is my own darn fault for not asking every single $9.99/mo customer to fax me their retina scan. 2. incurring a humongous bandwidth bill instead of being out said $9.99 is adequate punishment for my 'stupidity' 3. he likes the kind of justice where a provider gets harmed instead of the abusive customer, because Good ISPs Recognize Bad Guys On Sight. i've got news for you: 1. when you run a sufficiently large operation, credit card fraud is approached as a risk mitigation excercise - you find a golden middle in terms of verification which is cost-effective, ie reduces the incidence of fraud to an acceptable level while not costing an arm and a leg in terms of labour costs and encumbrance to the very large majority of legitimate customers placing an order. the problem with getting ddosed is that this cost-effectiveness calculation goes out the window because your risk is no longer a measure of the price a customer is paying for the service, but rather a measure of how much traffic lycos' botnet can direct at you. for you, it may be bounded by the single t1 termed in your basement, while for me it may be bounded by a gig-e feed i get from my upstream. 2. cc fraud was just an example, and probably a bad example at that, since you can come up with a holier than thou argument against the example rather than the practice of shoving traffic my way that neither i nor my clients asked for. let's try again. customer pays for a dedicated server with a valid credit card. we charge them the monthly fee and keep the credit card on file. customer proceeds to spam, or better yet installs an insecure formmail script, or his box gets owned. he gets ddosed by lycos, racks up large overage bill and gets terminated by us for breach of AUP. we notify the customer and try to bill him for the overage charges. lo and behold, customer put a Do Not Honor request on transactions initiated by us. we're stuck with the bw bill. alternatively, customer charges back and their issuing bank is braindead and we lose the chargeback. or customer was paying by check. whatever. see the point? while we may be willing to risk the monthly charge because we won't ask customers paying by check for a large security deposit, we aren't willing to risk an arbitrarily high bw bill from folks who think they're doing the 'net a favour by ddosing For Our Own Good. consumption is equivalent to denial, the only difference being in the reason the service will no longer be available - administrative (ie financial) and technical respectively. while we all would like to see spam-related services not being available, there exist means to that end that are not acceptable, such as hunting spammers with shotguns or ddosing their (in many cases unknowing) providers. -p --- paul galynin
RE: Best way to get of Bogon list?
72.0.0.0/8 as well :) Will send you a private email once I get the IP going :-) -- Majid. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Mauch Sent: Monday, November 29, 2004 5:08 PM To: Barry Raveendran Greene Cc: 'Jared Mauch'; 'Jon Lewis'; [EMAIL PROTECTED] Subject: Re: Best way to get of Bogon list? On Mon, Nov 29, 2004 at 07:04:28AM -0800, Barry Raveendran Greene wrote: Jared Mauch: jlewis: If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net into 70box, 71box, etc. and come up with a large (fairly comprehensive) list of IPs behind broken bogon filters. http://puck.nether.net/~jared/papers/69-paper.html I can rewrite this slightly and post it on slashdot and other places again.. I think it would be useful. The Bogon Team implemented several changes after 69/8 to make change management easier. This included maintain objects at Merit RADB, RIPE NCC RADB, and a way to track via DNS (see the details on http://www.cymru.com/Bogons/index.html). I'll write up a new version of this. Can those of you that are having problems in the 70/8 and 71/8 space write me a snippet in private email saying how this is impacting them? One paragraph please, also include your full name and employer or whom you represent. this way i can include the impact seen in it so people *may* wake up and realize the impact of lack of maintence of these filters. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Make love, not spam....
Ah, but I said poetic justice. Like for like. I am hearing DDoS over and over. As I understand it, the application will throttle to prevent Denial of access. It just causes additional GB to be used and paid for. Fraudulent CC use is an entirely different issue... -m -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Haagsman Sent: Monday, November 29, 2004 3:30 PM To: Paul G Cc: [EMAIL PROTECTED] Subject: Re: Make love, not spam I agree and I'm surprised you even mentioned the wordt justice...since when is retaliating bad practices with more bad practises that are hardly likely to take out the real target considered a good idea..? Erik Paul G wrote: spammer buys hosting account, pays with fraudulent credit card, spams,provider gets ddos'ed and ends up paying for all the bandwidth because youcan't well charge some unsuspecting grandma in alabama for it. i don't likethis kind of justice. --- paul galynin
Re: Make love, not spam....
Once upon a time, Miller, Mark [EMAIL PROTECTED] said: Ah, but I said poetic justice. Like for like. I am hearing DDoS over and over. As I understand it, the application will throttle to prevent Denial of access. It just causes additional GB to be used and paid for. For sites set up with a monthly bandwidth quota, that _is_ a denial of service. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: Make love, not spam....
Your argument seems to assume a T1 garage operation co-lo that is perpetually out to lunch. Provided Lycos delivers the restrictions on bandwidth they are stating, why would it exceed capacity? Come on, kids. If you can't deliver to begin with, don't sell it. I am not saying that the proposal is intrinsically right or wrong, I am saying it could have merit if just in waking up a brain-dead co-lo facility operator to deal with spamming clients. -mm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul G Sent: Monday, November 29, 2004 4:11 PM To: [EMAIL PROTECTED] Subject: Re: Make love, not spam - Original Message - From: Erik Haagsman [EMAIL PROTECTED] To: Paul G [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 29, 2004 4:30 PM Subject: Re: Make love, not spam I agree and I'm surprised you even mentioned the wordt justice...since when is retaliating bad practices with more bad practises that are hardly likely to take out the real target considered a good idea..? 'justice' was mentioned in the message i quoted. it appears i was not remiss - i got an email from a guy running a small town isp telling me, essentially, that: 1. if i get hit with cc fraud, it is my own darn fault for not asking every single $9.99/mo customer to fax me their retina scan. 2. incurring a humongous bandwidth bill instead of being out said $9.99 is adequate punishment for my 'stupidity' 3. he likes the kind of justice where a provider gets harmed instead of the abusive customer, because Good ISPs Recognize Bad Guys On Sight. i've got news for you: ... *Abbreviated*
Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI
On 27-nov-04, at 22:45, [EMAIL PROTECTED] wrote: the short version of my rebuttal is: those are not your bits to waste. They are if my ISP assigns them to me. :-) er... not really. they are the ISPs. Well, the ISP doesn't own them either. But they're assigned to me, which gives me the right to waste them as I see fit within the limits of the address assignment policy. (Which allows considerable leeway towards bit wasting in IPv6.) second, let me add, and it's not your routing table, either. I have no idea what this means. if you have no idea aobut the impact of address assignment on routing tables, I think anyone who has been present during the address policy sessions in the last few RIPE meetings can testify to the fact that I certainly have ideas about this. What I mean is that the remark that something is not my routing table makes no sense to me. Nobody owns the abstract global routing table. On the other hand, obviously I own the memory in my private box that happens to have a particular instance of the global routing table in it. then you really should spend some time implementing routing policies -before- you burn cycles telling others about how they should run their networks. no one is stoping you from implementing whatever prefix acceptance/forwarding policy you may chose to implemenet for -YOUR- customers. it is a -local- effect. just stop trying to tell others how to manage their routign tables. Unless I'm experiencing blackouts, I haven't been telling people how to manage their routing tables. The trouble with the routing table is that it's not really manageable: in theory, you can filter out the stuff that you don't like, but in practice this can't be done without breaking reachability, so we're all forced to live with the sum of all crap that anyone feels fit to inject in BGP on some corner of the planet. That has been my point all along: we should empower operators to make reasonable tradeoffs between optimum path selection and routing resource consumption.
Re: Make love, not spam....
I am not saying that the proposal is intrinsically right or wrong, I am saying it could have merit if just in waking up a brain-dead co-lo facility operator to deal with spamming clients. -mm How would this method be more effective than the e-mails, faxes, blocklists, and phonecalls that have been used in the past ? James H. Edwards Routing and Security Administrator At the Santa Fe Office: Internet at Cyber Mesa [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cybermesa.com/ContactCM (505) 795-7101
RE: Make love, not spam....
It's a DDOS. The risk of collateral damage is high. snip From what limited information is available in the articles, it doesn't sound that way. It's not really a DDoS attack, but more of a distributed web surfing bot. snip I understand this as more of a Distributed Consumption of Service attack. (Is the acronym DCoS used yet?) Real requests, downloading real data, to real computers. A lot of them. T snip The big difference between Lycos Europe, and a script kiddie with zombies is that Lycos is mature enough to use restraint and not knock down websites with brute force. They're attempting to use the politically correct grown up way to attack someone: economics. How is giving the spammers what they want (real web site traffic) an attack? That doesn't even qualify! How many bogus URLs are embedded into spam content? A: Lots. They are used to obscure words to get past filters, or as red herring targets or joe-jobs. A DDoS is a DDoS, no matter how benign one might think it is, or how evil/deserving the target is perceived to be. The risk of collateral damage is way too high. -- Chuck Goolsbee V.P. Technical Operations _ digital.forest Phone: +1-877-720-0483, x2001 where Internet solutions grow Int'l: +1-425-483-0483 celebrating ten years of service 7/12/1994 - 7/12/2004 19515 North Creek ParkwayFax: +1-425-482-6871 Suite 208 http://www.forest.net Bothell, WA 98011email: [EMAIL PROTECTED]
RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
These are the same arguments that are presented each time something new comes along to replace something old. When IPv4 first came along nobody thought all of the 4 billion plus address could ever be used; but we were wrong. 16-bit ASNs have served their place and will continue to serve for the time being. Those who fail to plan, plan to fail. It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses. As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now. I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Savola Sent: Monday, November 29, 2004 11:41 AM To: Owen DeLong Cc: Jeroen Massar; Cliff Albert; [EMAIL PROTECTED] Subject: Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI] On Mon, 29 Nov 2004, Owen DeLong wrote: Also, with 32bit ASN's, also expect upto 2^32 routes in your routing table when each and every ASN would at least send 1 route and of course there will be ASN's sending multiple routes. Only if EVERY ASN were allocated and active. You and I both know this doesn't begin to approach reality. Slightly more than half of current ASNs are actually in the routing table. The ASN issuance rate is not likely to go up simply because we go to 32 bit ASNs. Probably we are really talking about a need for 20 bit ASNs or so, generally, but, 32 bits is a much more convenient boundary for lots of code implementations and lots of hardware, so, 32 bits is the chosen number for the sake of simplicity. Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be no need (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. It's better to try to stick to 16 bit ASNs for now, and make stricter policies and reclaim the space if needed. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Make love, not spam....
The servers targeted by the screensaver have been manually selected from various sources, including Spamcop, and verified to be spam advertising sites, Lycos claims. I'd like to know how will they manually choose which spammers they'll go after? Personal e-vendetta? It'll just cause the spammers to use the zombie networks more and more. It seems to me to just be an advertising gimmick, not a solution. scott
Re: size of the routing table is a big deal, especially in IPv6
On 28-nov-04, at 5:20, Daniel Roesen wrote: I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view. ACK. All the oh our IPv4 DFZ table explodes today is similarily unfounded as far as I'm aware. I have not heard of anybody being able to crystal-ball the scaling limits of BGP4 yet, and currently used BGP implementations seem to cope quite well with 150k routes (set aside the notorious vendor C artificial RAM limits in older gear to make you buy new gear when table gets bigger). Ok, I'll do this one more time. There are basically two issues: the forwarding table and BGP processing. Information in the forwarding table needs to be found *really* fast. Fortunately, it's possible to create datastructures where this is possible, to all intends and purposes, regardless of the size of the table. However, memory is a concern here, as you only have a few hundred nanoseconds to look up something in the routing table at 10 Gbps speeds. When the forwarding table gets too large and the packets rates too high, you may run into memory bandwidth problems and/or have to use much more expensive memory. On any line card, but especially on a fast one, a bigger fdb simply costs more money. For the BGP routing information base this isn't much of a problem, as you can use much cheaper and slower memory. Unfortunately, there is also the processing. Because of stuff like the longest match first rule and the presence of multiple BGP routes towards the same destination, it's much harder to use very efficient data structures for this. And to add insult to injury, the contents of the BGP table changes all the time. Now this appears to be a linear problem, but it isn't: when the routing table gets twice as big, generally this means twice as many updates (probably more, as deaggregated routes tend to flap more) but you also need to search through twice as many routes in the routing table to process each update. So the work doesn't increase as O(n) but either O(n*n) or O(n*log(n)). Now all of this doesn't mean we can't have any growth in the global routing table, but it does mean that such growth must be considerably below the Moore's Law rate (a factor 2 in 18 months or about a factor 10 in 5 years). Over the past few years the routing table growth has been very modest, but it looks like it's picking up speed again. This isn't good, although we're certainly not at dangerous levels yet. 8 years too late guys. We've figured out table management. ACK, looks like that. Yes, it's surprising how effective hoping for the best can be sometimes. And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. big deal. I have a slightly bigger deal for you. Unfortunately, I can't find the current number right now, but the number of individual /24s in the BGP table was always something like half the table when I looked. Now for an ISP, a /24 is small change, so it's likely that most of those /24s are real or defacto PI blocks that are often announced under the AS of the ISP of the week rather than under the AS of the holder of the block. If you take this number you're at around 50k. I'm not sure about how this works out in actual implementations, but it's likely a 50 to 75 k IPv6 table takes the same amount of memory as a 150k IPv4 table. Next step. In IPv4, there is downward pressure on multihoming because you can't get a route advertised that's longer than a /24. And yes, even a /24 is somewhat hard to get for most people. In IPv6, _everyone_ can get a /48. So if we allow /48 PI blocks in the routing table, how do we make sure we only allow legitimate PI users and not ISPs deaggregating a /32 into 64k /48s or people announcing PA /48s? This deal is getting bigger by the minute. In IPv4 it took a while before we managed to get it right, resulting in the 192.x.x.x swamp and lots of address space and AS numbers that are as good as unreclaimable. And this was all before 1993, before pretty much anyone had even heard of the internet. If we get it wrong to the same degree in IPv6 it will be much worse because the potential influx of new IPv6 users in a week is larger than the influx of new IPv4 users in any year before 1993. (For instance, if there is a land rush on AS numbers because they are a free ticket towards an IPv6 PI prefix.) Now I'm not saying that all kinds of bad things are going to happen. I'm just saying we should be very conservative in allowing unreversible changes in unscalable aspects of IPv6.
Re: Make love, not spam....
On Mon, Nov 29, 2004 at 10:54:03AM -0600, Jerry Pasker wrote: The big difference between Lycos Europe, and a script kiddie with zombies is that Lycos is mature enough to use restraint and not knock down websites with brute force. I have no idea whether they're mature enough. They're most certainly not knowledgeable enough, as they appear to have failed to account for: - zombie'd end-user systems (some of which will no doubt download this DoS tool) - web sites hosted on zombies (and serving requests sent to them either by rapidly-updating DNS or redirectors) - throwaway domains - hijacked ASNs among other standard spammer tricks, all of which can be used to deflect the attack or redirect it against third parties. But beyond that: this is a silly tactic. Spammers have as much [free, to them] bandwidth as they want. They're trying to drown people who own the ocean. ---Rsk
Re: size of the routing table is a big deal, especially in IPv6
At 06:33 PM 11/29/2004, Iljitsch van Beijnum wrote: On 28-nov-04, at 5:20, Daniel Roesen wrote: I find it interesting that no operators are screaming that there will be too many routes, but that all the IPv6 researchers are bringing forth this view. ACK. All the oh our IPv4 DFZ table explodes today is similarily unfounded as far as I'm aware. I have not heard of anybody being able to crystal-ball the scaling limits of BGP4 yet, and currently used BGP implementations seem to cope quite well with 150k routes (set aside the notorious vendor C artificial RAM limits in older gear to make you buy new gear when table gets bigger). Ok, I'll do this one more time. There are basically two issues: the forwarding table and BGP processing. Information in the forwarding table needs to be found *really* fast. Fortunately, it's possible to create datastructures where this is possible, to all intends and purposes, regardless of the size of the table. However, memory is a concern here, as you only have a few hundred nanoseconds to look up something in the routing table at 10 Gbps speeds. This is a solvable problem. Hardware lookups are quite sufficient. Forwarding bases stored in line cards can be aggregated to the extent the data permits. Any router with 10GigE interfaces that's going to care about actually filling such pipes will have advanced hardware forwarding technology and a price tag to support the development of same. When the forwarding table gets too large and the packets rates too high, you may run into memory bandwidth problems and/or have to use much more expensive memory. On any line card, but especially on a fast one, a bigger fdb simply costs more money. Right. And anyone on the edge just needs enough memory to hold the table in their software-based routers that have little or no lookup assistance. For the BGP routing information base this isn't much of a problem, as you can use much cheaper and slower memory. Unfortunately, there is also the processing. Because of stuff like the longest match first rule and the presence of multiple BGP routes towards the same destination, it's much harder to use very efficient data structures for this. And to add insult to injury, the contents of the BGP table changes all the time. Now this appears to be a linear problem, but it isn't: when the routing table gets twice as big, generally this means twice as many updates (probably more, as deaggregated routes tend to flap more) but you also need to search through twice as many routes in the routing table to process each update. So the work doesn't increase as O(n) but either O(n*n) or O(n*log(n)). Even 10 years ago it was evident the routing table structures chosen by different manufacturers had significantly different performance characteristics. As there is no single data structure to define the storage of this information, it may follow that there is no singular formula for the impact of scaling. Now all of this doesn't mean we can't have any growth in the global routing table, but it does mean that such growth must be considerably below the Moore's Law rate (a factor 2 in 18 months or about a factor 10 in 5 years). Over the past few years the routing table growth has been very modest, but it looks like it's picking up speed again. This isn't good, although we're certainly not at dangerous levels yet. Over the past several years, the CPUs in routers have been considerably below the speediest on the market. I suspect there's a fair bit of headroom at present between the route processing engines in core routers and the fastest CPUs presently offered for sale. As such, I have to wonder just how much growth we could handle instantaneously, and still stay within the CPU capabilities of today's available processors. Also consider that CPU power is far from the only issue. Higher speed memory continues to be developed along with higher speed bus architectures. System performance is made up of many factors. 8 years too late guys. We've figured out table management. ACK, looks like that. Yes, it's surprising how effective hoping for the best can be sometimes. And even if all active ASses would immediately adopt IPv6, we would land at about 18k IPv6 routes. big deal. I have a slightly bigger deal for you. Unfortunately, I can't find the current number right now, but the number of individual /24s in the BGP table was always something like half the table when I looked. Now for an ISP, a /24 is small change, so it's likely that most of those /24s are real or defacto PI blocks that are often announced under the AS of the ISP of the week rather than under the AS of the holder of the block. If you take this number you're at around 50k. I'm not sure about how this works out in actual implementations, but it's likely a 50 to 75 k IPv6 table takes the same amount of memory as a 150k IPv4 table. Deaggregating the entire IPv4 space into /24's is today the worst case design for the
New IANA IPv6 allocation for APNIC (2001:8000::/23 - 2001:AE00::/23)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to inform you that the IANA has allocated the following twenty-four (24) IPv6 /23s blocks to APNIC: 2001:8000::/23 APNIC 2001:8200::/23 APNIC 2001:8400::/23 APNIC 2001:8600::/23 APNIC 2001:8800::/23 APNIC 2001:8A00::/23 APNIC 2001:8C00::/23 APNIC 2001:8E00::/23 APNIC 2001:9000::/23 APNIC 2001:9200::/23 APNIC 2001:9400::/23 APNIC 2001:9600::/23 APNIC 2001:9800::/23 APNIC 2001:9A00::/23 APNIC 2001:9C00::/23 APNIC 2001:9E00::/23 APNIC 2001:A000::/23 APNIC 2001:A200::/23 APNIC 2001:A400::/23 APNIC 2001:A600::/23 APNIC 2001:A800::/23 APNIC 2001:AA00::/23 APNIC 2001:AC00::/23 APNIC 2001:AE00::/23 APNIC For a full list of IANA IPv6 allocations please see: http://www.iana.org/assignments/ipv6-tla-assignments - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBq7nryIakK9Wy8PsRAkXKAKDt5e51TRqDOP04sSgvN76NyrIlWACg5hcV e+9tLEhXv99J5t9l9eY2kMg= =SODE -END PGP SIGNATURE-
Re: size of the routing table is a big deal, especially in IPv6
Daniel Senie wrote: There are basically two issues: the forwarding table and BGP processing. Information in the forwarding table needs to be found *really* fast. Fortunately, it's possible to create datastructures where this is possible, to all intends and purposes, regardless of the size of the table. However, memory is a concern here, as you only have a few hundred nanoseconds to look up something in the routing table at 10 Gbps speeds. This is a solvable problem. Hardware lookups are quite sufficient. Forwarding bases stored in line cards can be aggregated to the extent the data permits. Any router with 10GigE interfaces that's going to care about actually filling such pipes will have advanced hardware forwarding technology and a price tag to support the development of same. The bottom line in this discussion is all about cost. Technology can be had to do many things that are physically possible, but as you get closer to the limits of the physics, the costs go up. Further, the marginal costs (i.e., $/packet per second) go up quite rapidly. If the size of the FIB exceeds Moore's law (and BTW, for memory it's more like 2x every 3 years), then the costs go nuts as you have to scale up from hardware parts that can't keep up. That also adds complexity. All of these costs end up factored into the cost of routers, which the ISPs must in turn factor into the costs of providing service if they are to stay in business. The problem is that the decisions to advertise a global prefix must be paid by users around the globe. If there was a way that these costs were reallocated to the site that decided to be multihomed, then the economics of the situation would balance. Imagine paying US $10K/yr to advertise a single prefix and you would get to a point where people would make some more rational decisions that didn't pollute the global table. Even 10 years ago it was evident the routing table structures chosen by different manufacturers had significantly different performance characteristics. As there is no single data structure to define the storage of this information, it may follow that there is no singular formula for the impact of scaling. In fact, almost all implementations now use some form of radix trie. Over the past several years, the CPUs in routers have been considerably below the speediest on the market. I suspect there's a fair bit of headroom at present between the route processing engines in core routers and the fastest CPUs presently offered for sale. As such, I have to wonder just how much growth we could handle instantaneously, and still stay within the CPU capabilities of today's available processors. Also consider that CPU power is far from the only issue. Higher speed memory continues to be developed along with higher speed bus architectures. System performance is made up of many factors. Do you really want to keep all routers in the world on the CPU growth curve? Do you really want the cost of replacing all of that hardware every time Intel comes out with a new processor? Again, yes, this is technically possible, but it comes with a cost. In an ideal world, the cost of running the routing subsystem would be linear only in the amount of transit bandwidth at each hop. Unfortunately, the reality is that table growth and prefix flap drive costs up faster than that and ISPs are being squeezed between costs and prices. In the long run, these costs will be passed on to the end user, or all of the ISPs will end up out of business. Lookout above! The sky is falling. Not at all. It will be propped up by router prices. ;-) I'm just saying we should be very conservative in allowing unreversible changes in unscalable aspects of IPv6. I'd sure like to see a lot more thorough analysis than what you provided above before reaching that conclusion. History has certainly not sided with you. Back in the mid-1990s, we were told routers wouldn't scale, so we needed MPLS. While MPLS has found useful roles in the network, it wasn't needed as a replacement for IPv4 routing in the core. Several companies, including some startups, figured out ways to route packets quite quickly. In the long run, I'd rather provide the ability to offer the services needed. This permits the companies looking for those services to flourish and help the economies of the world. While there are challenges to be addressed, I belive those challenges will be well met by the equipment marketplace, and that innovation also will help the economies of the world. Artificial restraint does not result in expanded services or product innovations. If I had a way to vore on this, I'd vote to let the markets work. Letting the markets work is a fine thought, but there are a few issues that will not be addressed. The global DFZ routing table is a common resource, shared and polluted equally by everyone around the world. In a purely free market world, Adam Smith suggests
RE: size of the routing table is a big deal, especially in IPv6
Snip My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony /snip What happens to non-member states? What happens to Taiwan, who has not been a part of the UN for decades? Does the island nation of Togo get a prefix, but not Taiwan. Also, what about North Korea? Only South Korea is a member state in the UN. Next thing you know, they'll be trading prefixes for kick-backs . . .
Re: who gets a /32 [Re: IPV6 renumbering painless?]
It would have been nice to make sctp be the standard stream protocol for ipv6. yup. or at any rate, SOME kind of improvement in this area. For most nanog customers, there's still time. nope. Those places that have already seen significant ipv6 adoption may need to upgrade again. If we wait much longer, of course, the opportunity will be lost. that opportunity was lost when the preponderance of the iab and iesg was refilled by folks who didn't know or care why TUBA hadn't been selected. To argue that it's already too late, when ipv6 is a small fraction of all traffic and an infinitesmal fraction of future traffic is, imho, foolish. and yet it is. to declare that ipv6 will can have more than one flag day is to declare that there could be more flag days which would have what the law people call a chilling effect. that can't be allowed to happen. this is why the decision to kill a6/dname was so evil. not that it was wrong, or made in a star chamber without consensus or transparency, but that it was so perfectly timed to be irreversable. it's review-proof.
RE: size of the routing table is a big deal, especially in IPv6
I'm sorry, North Korea is in the UN. My mistake. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Johnson Sent: Monday, November 29, 2004 10:25 PM To: Tony Li; [EMAIL PROTECTED] Subject: RE: size of the routing table is a big deal, especially in IPv6 Snip My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony /snip What happens to non-member states? What happens to Taiwan, who has not been a part of the UN for decades? Does the island nation of Togo get a prefix, but not Taiwan. Also, what about North Korea? Only South Korea is a member state in the UN. Next thing you know, they'll be trading prefixes for kick-backs . . .
Re: size of the routing table is a big deal, especially in IPv6
Tony Li [EMAIL PROTECTED] writes: My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. ... and once the Internet's effectiveness and usefulness is dropped to a level comparable to that of the IAEA, nobody will care anymore. Presto, problem solved! ---Rob
Re: size of the routing table is a big deal, especially in IPv6
Tony Li wrote: If there was a way that these costs were reallocated to the site that decided to be multihomed, then the economics of the situation would balance. Imagine paying US $10K/yr to advertise a single prefix and you would get to a point where people would make some more rational decisions that didn't pollute the global table. Now there's a thought, and a pretty darned good one. But, where would the money go? Upstream(s)? It would certainly encourage more forethought into advertisements and aggregation. But it leaves a lot of room for the economics to click. Jeff
RE: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 29 Nov 2004, Chris Burton wrote: It is highly doubtful that the policies in place will become more relaxed with the introduction of 32-bit ASNs, the more likely scenario is that they will stay the same or get far stricter as with assignments of IPv4 or IPv6 addresses. I find this hard to believe. When there is 64K times as much the resource, there is no way the policies would get stricter, because it can easily and logically be argued that they don't need to be stricter. As you had mentioned though, in the near term this definitely would not be scalable, but who knows what is going to happen 10, 15, or more years from now. So, let's delay the move until we know how to make it more scalable. I think your numbers may be a little off 2^32 = 4,294,967,296; current world population give or take a few million is hovering around 6,300,000,000 according to the US Gov. If everyone and the mother would like an ASN (Which is highly unlikely) you would need just a few more to make that work. Yeah, I know the calculations :). Everyone can already get an IPv4 address too, right? All we need is an AS number NAT.. oops, it's there already. Face it, with 32 bit ASNs, pretty much anyone could have an ASN if they wanted to unless the policies were very strict, and it would be very difficult to justify why it would have to be strict because there is so vast resource to be used. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: size of the routing table is a big deal, especially in IPv6
On Mon, Nov 29, 2004 at 08:14:27PM -0800, Tony Li wrote: My preferred solution at this point is for the UN to take over management of the entire Internet and for them to issue a policy of one prefix per country. This will have all sorts of nasty downsides for national providers and folks that care about optimal routing, but it's the only way that I can see that will allow the Internet to continue to operate over the long term. Tony Unfortunately, the U. N. is full of people representing countries whose only concern is their own petty self-interests, not the larger good of the world community as a whole. The end result of this would be arguing and bickering and delaying in any governance decision until it's past the point where it matters and new problems have surfaced. (It's like a room full of 4 year olds all screaming MINE!) With market interests, at least, there is a driving force to solve various problems in a timely manner. Eventually, the governance of the internet will have to be done in some sort of global forum but I don't really think that particular body is the right place. -Wayne (Yes, I realize that finding lawmakers or the like who actually ARE interested in the good of the community is like trying to find water in the desert but you get the idea...)
Re: size of the routing table is a big deal, especially in IPv6
At 12:00 AM 11/30/2004, Jeff Kell wrote: Tony Li wrote: If there was a way that these costs were reallocated to the site that decided to be multihomed, then the economics of the situation would balance. Imagine paying US $10K/yr to advertise a single prefix and you would get to a point where people would make some more rational decisions that didn't pollute the global table. Now there's a thought, and a pretty darned good one. But, where would the money go? Upstream(s)? It would certainly encourage more forethought into advertisements and aggregation. But it leaves a lot of room for the economics to click. If we're going to entertain a settlement-based approach, why stop there? We should add settlements to traffic, so the ISPs of end users pay content providers for the content, rather than the present system where content providers and end users all pay the folks in the middle (who still seem unable to make any money). As Tony noted elsewhere in his note, the Internet doesn't have a central authority to impose the fees. It's a cooperative environment. We all advertise routes that we need, and hope others will take them. Just like we all filter traffic entering our networks at our borders so everyone else won't have to deal with spoofed traffic injected elsewhere (what? do something that helps the community as a whole?). Keeping the Internet functional is a community, cooperative effort. The fee Tony proposes likely will just result in only the larger companies being able to connect to the Internet, and would put a lot of smaller companies out of business. But that'd be best for the Internet, perhaps?
Re: ULA and RIR cost-recovery
On Mon, 29 Nov 2004, Owen DeLong wrote: On Mon, 29 Nov 2004, Leo Bicknell wrote: # 1 Set aside a block for local use a-la RFC1918. This set aside should make no recommendations about how the space is subdivided for used for these local purposes. FWIW, site-locals were dropped (among others) due to concerns about sufficient guarantee of uniqueness. ULA started by having only a local generation mechanism, no central allocation at all. Would that allay your concerns? No. In that case, it makes things even worse because it creates the promise and illusion of uniqueness without actually delivering uniqueness. Worst of both worlds... Bigger address-waste (not that it really matters), non-uniqueness, and the expectation of uniqueness. To some small extent, this might (_MIGHT_) reduce the pressure on ISPs to route these prefixes, but, that is the only improvement over a central registry. OK, I understand with this sentiment. It's easier for the ISPs to fend off (there's no uniqueness, we can't route this stuff!). # 3 Drop the absolutely stupid notion that there should be no PI space. There will be PI space, either by people using ULA for that purposes, or by the RIR's changing this stupidity after they get ahold of it. I think we all know there's going to be _some_ form of PI space. Whether that's realized by making the policies weaker, by end-sites lying in their address applications, or end-sites providing interesting interpretation for other organizations, or a number of different mechanisms, the fact is that some form of PI addressing is going to be there. The question just is, what kind, how much of it, and to whom it's available. Ideally, I'd like to see us address this up front in a clear and open manner instead of using nudge-nudge and wink-wink encouragement to make creative applications for space. The former can be done fairly. The latter insures that the only organizations that have any sort of advantage are the ones willing to lie to get it. This tends to happen by accident often enough. Creating the situation deliberately is, IMHO, absurd. Sure, I invite discussion on this in the open. The best place would probably be the global-v6 list at: http://www.apnic.net/mailing-lists/global-v6/ # 5 Stay out of the allocation details. The RIR's have been allocating addresses for years. The RIR's have people, from small to large ISP's and everything inbetween solving real world allocation problems every day. The history tells us is the policy will change over time. History also tells us being too liberal early on can never be fixed. The RIR's will change policy as time goes on to fit the changing IPv6 world. Let them deal with the policy on a going forward basis. The history also tells us that being too stingy when there is no need to be stingy will result in useless fragmentation of the addressing, and therefore results in the fragmentation of routing advertisements. Actually, that fragmentation was primarily the result of being insufficiently stingy early on. There are many kinds of fragmentation. When you only get (e.g.,) a v4 /24 for a start, and when you need more, you'll have to get a new non-adjacent /24, there's going to be fragmentation. For v6, you can just look at below to see what is the result of unnecessary stinginess causing fragmentation of allocations (though luckily not advertisements): http://www.iana.org/assignments/ipv6-tla-assignments We _don't_ want to get to a point where each IPv6 ISP or end-site will have to have dozens of IPv6 prefixes, just because they outgrew the previous ones. There are enough bits to play around. It's not as we are carving out v4 /8's (1/256 of space) for early adopters. Or even /16's. More like the equivalent space of a host address. That's hardly too much. In fact, it's way too little for those ISPs which have home customers like DSL, and it's going to be a a pain because they either must get a new prefix or give their customers a /64 instead of /48. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
APNIC New IPv6 address block(s)
Dear colleagues APNIC received the following IPv6 address blocks from IANA today and will be making allocations from this range in the near future. 2001:8000::/19 2001:A000::/20 This announcement is being made for the information of the Internet community, and so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son Resources Services Manager [EMAIL PROTECTED] Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: [EMAIL PROTECTED] Please send Internet Resource Requests to [EMAIL PROTECTED] _ -- This is the SANOG (http://www.sanog.org/) mailing list.
Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]
On Mon, 29 Nov 2004, Owen DeLong wrote: Of course, every ASN would not be active. But if we'd have 32 bit ASNs, there would be no need (or so folks would argue) to be strict in the policies -- everyone and their uncle could have one. Folks could even get ones for their homes, theis SOHO deployments, or their 3-person, on-the-side consulting companies. And logically, each of these should have their own PI prefixes and a slot in the global routing table. People might argue it, but, I am not convinced they would succeed in that argument. If you want an ASN for something other than connecting to the internet for multihoming or other unique routing policy, then, make one up. Doesn't matter whether it's 16 or 32 bits. Also, there are a whole slew of private ASNs reserved for just such a purpose if you want to retain compatibility with existing ASN numbering. Multihoming can be such a reason. Get DSL and cable to your home, request an AS number, request PI space, run BGP to multihome, etc. OTOH, I have a SOHO with a legitimate ASN and protable IPv4 space. Who are you to tell me that it isn't legitimate for me to use it in this manner? Why do you get to decide that my SOHO is less worthy of PI space and the ability to reliably multihome just because my organization is small? Because I have a similar organization myself, and I'm unselfish enough to realize that the organization is not sufficiently relevant in the global scale to be using such a mechanism. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god. So we return to the need to separate the end-point identifier from the routing identifier and come up with a routing scheme that allows routing assignments to be dynamic and flexible independent of the layer 3/4 endpoint identifier. Yes. You seem to be arguing that because we don't have such identifier split _today_, we must open the doors to give _everyone_ PI and ASN and to pollute the global routing table. I say we must close the doors even more, so that those who would need multihoming solution would pick the one based on identifier split, instead of getting the one which pollutes the global resource. If we make getting PI/ASN too cheap (using various metrics for cheap), nobody wants to get an identifier split solution. Obviuosly, you don't subscribe to the premise that regardless of reclamation, we will run out of 16 bit ASNs soon enough. That's fine, you may be right. However, from where I'm sitting, I think we will. I also think that the $500 up front cost and $100 annual renewal associated with an ASN are decent incentive for people not to get them unless they have a legitimate use for them. Private ASNs are too easy and cost nothing. if the prices were one or two orders of magnitude higher, that might be true. That's way too cheap as it is. 1$ upfront, 5000$/yr for renewal might scare away who _really_ don't need them. Have the RIRs donate the markup to ISOC or whoever and we're done. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
